This makes the `workspace_bar` more responsive to different child sizes, which enables fixing the size of the smaller dimension of the screencopy, while allowing it to expand unrestricted in the larger dimension (to match the aspect ratio).
This tries to find a split point in the list of toplevels to maximize
the scale factor when calling `RowColToplevelLayout` twice. If it
doesn't get a better scale factor, it just uses a single row/column.
Some things don't seem quite right, but the existing layout is not
perfect, and this can help.
Without the added cross axis spacing, there's overlap, so there may be
something wrong with the requested sizes...
Previous definition assumed the cross axis of a single window would not
need more downscaling than the total main axis of all children. But that
doesn't always work out.
https://github.com/pop-os/cosmic-workspaces-epoch/issues/66. If we want
to hide the workspaces overlay when a popup is opened, that still needs
to be done, but using the same layer as the panel should be good in
general. There's no clear reason to have it on the `Overlay` layer.
Works, I'm not sure how many pixels to interpret as a change to the
workspace, and perhaps it should accumulate multiple deltas with a
timer. Assuming some lower level of the stack isn't doing that already.
I only see `ScrollDelta::Pixels` events, not `Lines`, though maybe
that's relevant with a different type of input device.
The behavior would also be clearer with animation, though it doesn't
seem to bad
(https://github.com/pop-os/cosmic-workspaces-epoch/issues/32).
Fixes https://github.com/pop-os/cosmic-workspaces-epoch/issues/34.
I guess some change is needed for handling workspaces that span outputs
(can't encode both the workspace and output id in less than 64 bits, and
need bits for discriminant as well). But that's an issue with the
previous workspace index based approach.
I wonder if `drag_id` is really needed; libcosmic could check if the
drag is in bounds of the widget, if drag surfaces can't overlap...
This should probably be faster, but it's good for things like this to
not block the UI thread regardless.
We could probably also cache for multiple apps with the same ID. Not
sure if there's a good way to detect changes to the icon for an app id
(Not really needed, probably?)
