`Action::Close` already used the keyboard focus target, but some other
bindings didn't. Presumably it's most intuitive if all "current window"
key bindings affect the window with keyboard focus.
These used the focus stack on the `focused_output()` (the one with
keyboard focus), so I guess the main impact is when the keyboard target
is a window being dragged? Then the binding will operate on that window,
or have no effect.
This seems related to some of the behaviors discussed in
https://github.com/pop-os/cosmic-comp/issues/453.
Tested on `SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS=1 supertux2`, using
XWayland. If the game starts with fullscreen configured, it minimizes
immediately on start. But after this change, this no longer happens.
This hopefully will improve behaviors with various X11/wine fullscreen
clients. It may fix
https://github.com/pop-os/cosmic-comp/issues/1510, though looking at the
video the behavior there may be a bit different.
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.
