Two independent bugs prevented tab drag-and-drop reorder from working
on cosmic-comp (and likely other compositors):
1. allow_reorder required DndAction::Move to be negotiated via
OfferEvent::SelectedAction, which cosmic-comp does not always emit
for self-drops (the SelectedAction event either never arrives or
arrives with DndAction::empty()). Add a fallback: accept self-drops
whenever state.dragging_tab is set. dragging_tab is only populated
by start_tab_drag on this same widget, so this is safe; mime match
and on_reorder presence are checked below.
2. reorder_event_for_drop preferred drop_hint.side over positional
swap, producing counter-intuitive no-ops: dropping A (pos 0) on the
left half of B (pos 1) resolved to "Before B" which, after removing
A, lands at pos 0 again — the tab appeared not to move. Always use
default_insert_position, which derives direction from dragged vs
target positions (Konsole/Firefox/Chrome-style swap semantics).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Fires in addition to on_activate when the same entity is left-clicked
twice within 400 ms. Lets applications bind quick actions (e.g. rename
a tab) without blocking the normal single-click activation path.
- New Widget::on_double_click builder mirroring on_activate/on_close.
- last_click field on LocalState for timestamp tracking.
- Detection branch in the mouse handler after on_activate fires, so the
target entity is already focused when the callback runs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Model::clear() cloned the entire order VecDeque to iterate while
remove() mutated it, producing an O(n) allocation proportional to the
number of items — needless on a clear() which is going to drop all of
them anyway.
Replace the clone with std::mem::take(&mut self.order): we iterate the
taken VecDeque (transferring ownership), and the inner self.order.remove(index)
in each remove() call now finds position()==None and no-ops, since
self.order has been swapped with an empty default.
Same semantics, zero allocation. Noticeable on large nav/table models
(>100 items) and on apps that reset state frequently (settings pages,
file lists, context menus).
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.
