The initial hard rename (255cf7cc) broke because Cargo's [patch] with
`package = libcosmic-yoda` does NOT unify across the transitive graph.
cosmic-files (still upstream) asks for "libcosmic"; patched with a
renamed package it ends up as a separate crate, leading to two copies
of cosmic::Theme/Action with incompatible types.
Soft fork keeps the yoda identity where it counts and stays compatible:
- Cargo name : libcosmic (for patch/unification)
- Version : 1.0.0 (same major as upstream so [patch] semver-accepts it)
- Lib name : cosmic (unchanged)
- Repo : leyoda/libcosmic-yoda on Forgejo (yoda lineage)
- Branch : main (vs upstream master)
Revert parts:
- examples/*/Cargo.toml dep refs back to libcosmic
- i18n/*/libcosmic_yoda.ftl renamed back to libcosmic.ftl
Added:
- Compat stub features: winit = [], x11 = [] — empty so Cargo can satisfy
upstream deps asking for these, but no code is actually gated on them
any more (all removed in Phase 2).
Ungates done to make the Wayland path self-sufficient after winit removal:
- src/lib.rs: pub mod app + pub use Application/ApplicationExt no longer
gated on winit; prelude exports ApplicationExt unconditionally
- src/surface/action.rs: 6 functions had #[cfg(all(wayland, linux, winit))]
triple-gates; simplified to #[cfg(all(wayland, linux))] since winit is
no longer a meaningful gate (wayland is now the only shell)
- 12 standalone #[cfg(feature = "winit")] annotations removed from src/
(their gated code is now always compiled)
cargo check --lib + cargo check in cosmic-yoterm both pass with a single
libcosmic v1.0.0 in the tree.
This also changes `widget::column::with_children` and
`widget::row::with_children` to take an `impl IntoIterator` instead
of a `Vec`, like the `iced` variants of these functions do.
This shouldn't be a breaking change since passing in a `Vec` will still
compile and function exactly as before.
(Using `iced::widget::Column::from_vec` or
`iced::widget::Row::from_vec` isn't possible, since the elements of the
`Vec` aren't checked, so the size of the resulting `Column` or `Row`
won't adapt to the size of its children. Perhaps a new function could
be added to mirror `iced`'s?)
To reduce compile-times and avoid some overhead to binary size, this will modify some of our
generic functions to use non-generic inner functions where possible. The inner functions are
marked carefully with `#[inline(never)]` to prevent being inlined by LLVM at their callsites
While looking for generic functions to optimize, I have also taken the opportunity to annotate
public non-generic getters and setters with `#[inline]` to ensure that LLVM will inline them
across crate boundaries. By default, only generic functions are automatically inlined, and
only when enabling fat LTO are constant functions reliably inlined across crate boundaries.
