Adds a new public enum `WindowControlsPosition { Start, End }` and a
matching field on `HeaderBar`, allowing window controls (close / minimize
/ maximize) to be packed on the start side of the headerbar (macOS
style, icon order close → minimize → maximize) instead of the default
end side (Linux / GNOME style, minimize → maximize → close).
Wiring:
- `crate::widget::WindowControlsPosition` re-exported alongside
`HeaderBar`.
- `HeaderBar::controls_position(Option<WindowControlsPosition>)` setter;
when left unset, falls back to `crate::config::window_controls_position()`
(reads `CosmicTk.window_controls_position`), mirroring how `density`
falls back to `header_size()`.
- New `CosmicTk.window_controls_position` field with default `End` for
backwards compatibility; serde-friendly enum so existing configs keep
working via `#[serde(default)]` semantics.
Tested with cosmic-yoterm, cosmic-settings, cosmic-edit, cosmic-files
rebuilt against this libcosmic via a local `[patch]` override. Config
changes picked up live through the existing cosmic-config subscription.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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?)