I hoped to split this up into multiple commits, but the api
changes to `shell/workspace.rs` were to invasive to feasibly do this.
Here is a rough list of changes:
- Fullscreen windows aren't mapped to other layers anymore
- This they need their own logic for:
- Sending frames
- Dmabuf Feedback
- Primary outputs
- On commit handlers
- cursor tests
- They get their own unmap/remap logic
- They get a new restore state similar to minimized windows
- Refactored the minimized window state to reuse as much as possible
here
- They need to be part of focus stacks, which means adjusting them
to a new type `FocusTarget` as they previously only handled
`CosmicMapped`.
- Various shell handlers (minimize, move, menu) now have dedicated
logic for fullscreen surfaces
- This was partially necessary due to relying on CosmicSurface now,
partially because they should've had their own logic from the
start. E.g. the context menu is now reflecting the fullscreen
state
- Fullscreen windows may be rendered behind other windows now, when they
loose focus.
- This needed changes to input handling / rendering
A solution for https://github.com/Smithay/smithay/issues/1714.
With this, the lock screen is able to get keyboard focus normally, but
focus then reverts to the XWayland grab surface. This can be tested with
the example client from the issue.
Adding a new variant of `KeyboardFocusTarget` is annoying. Maybe it
could map to a different variant of the enum. But it presumably needs to
handle any `wl_surface` XWayland uses. (Override redirect surfaces?
Subsurfaces?) This seems as good as anything for now.
This ensures that a commit to a cursor or drag surface will queue a
redraw, even if nothing else has changed on screen.
This can be tested by running `vkgears` in an otherwise empty
cosmic-comp instance, and dragging it.
Adds support for cosmic-workspace-v2 pin, unpin, move_after, and
move_before requests.
Both features need some work with workspaces span displays mode, so that
will need more fixes later.
We also want to generate a unique id for pinned workspaces to send in
the ext-workspace-v1 protocol. But that isn't a strict requirement for
anything. So I haven't yet fully implemented that. We'll also want to
persist other things, like workspace naming when that's added.
Overall, though, with separate workspaces per display, this is working
pretty well.
If two displays have the same edid (which shouldn't happen, since edid
includes a serial number, but is somewhat common in practice with
identical monitors), match output stack by comparing both edid and
connector name.
If we get the same edid but a different connector, `set_output`
truncates but also adds the new one. (Before adding edid matching, this
would have just added to the output stack.)
`prefers_output()` will requrire a connector name match if the edid of
the current output is the same as that of the output being compared.
If the user explicitly moves a workspace to an output, assume that is
where the user wants it, so it shouldn't be moved back to a different
output in the future.
For persistent workspaces, the explicitly set workspace is the one that
will be stored, instead of trying to track an unbounded list of outputs
persistently.
This was mapping `UnderlyingStorage::Memory` to `None`. I don't see any
reason for this. Though this also shouldn't change behavior since
`TextureRenderElement` doesn't provide `underlying_storage` currently.
Previously, this was not updating the workspace indices on either the
old or new set, and left no workspace on the old set with `Active`
state. It also didn't add a workspace if the last workspace was removed.
`ext_workspace_handle_v1::coordinates` defines the coordinate as
"an N-dimensional grid within a workspace group". So it is not
expected that the coordinates are unique between different groups, or
establish any geometry between different groups.
Whether we use one workspace per output or allow workspaces to span
outputs in the protocol, the whole workspace group is on the same set of
outputs. So I think this holds in any case.
I don't think we rely on this anywhere.
