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 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.
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.
Requires https://github.com/Smithay/smithay/pull/1676.
This changes two things:
* `Workspace::is_empty` no longer checks if there are activation tokens,
but a separate `Workspace::can_auto_remove` checks if the workspace is
empty and has no activation tokens.
- When we add workspace pinning, that can also be checked there.
* `Workspace` no longer contains a `pending_tokens` list that is updated
on `refresh`. Instead, `can_auto_remove` takes the xdg activation
state as an argument.
Since `Workspace::refresh` normally is run for focused workspaces, this
fixes allowing non-focused workspaces to be removed when an activation
token expires. It seems generally good to avoid tracking the activation
tokens in two places, and this is probably more efficient than needing
to refresh in more places.
By splitting this, we still don't remove an empty workspace if it has a
pending activation token, but we also don't add an empty workspace for
an activation token.
This mitigates the confusing behavior with activation tokens that aren't
used, but having to wait a few seconds in some cases before a workspace
is removed is still a little confusing. (We probably want `cosmic-term`
and `cosmic-workspace` to either consume the activation tokens they are
passed, or not be passed tokens when started by keybinding?)
Fixes https://github.com/pop-os/cosmic-comp/issues/1099.
On `output_remove`, if the output a workspace is moved to had no
non-empty workspaces (or did, but had an empty one active), the empty
workspace would remain active, and the workspace that was active on the
removed output is no longer visible.
Instead, change the active workspace to the one that was active on the
removed output.
This addresses another edge case where hotplug results in an empty
workspace, followed by other non-empty workspaces, and generally seems
like a better experience.
This could be further restricted by only applying if `new_set` is not on
the active output (to not mess with what the user is interacting with,
even it's an empty workspace) or only if the old `set` was the active
output, etc. But it seems good without further restriction.
This new protocol extends `ext-workspace-v1` with the same additional
functionality `cosmic-workspace-v1` provided. Toplevel info and toplevel
management are also updated to use ext handles, and there's an image
source for ext workspaces.
For now, the old protocol is still supported.
