Everything implementing `AsGlowRenderer` implements `Renderer` and various
other traits, and by making `AsGlowRenderer` depend on these trait,
things requiring `AsGlowRenderer` can avoid listing those traits as
well.
Looks like implied trait bounds still won't work for the
`Self::TexutureId` and `Self::Error` requirements? So those are not
included here.
Everything implementing `AsGlowRenderer` implements `Renderer` and various
other traits, and by making `AsGlowRenderer` depend on these trait,
things requiring `AsGlowRenderer` can avoid listing those traits as
well.
Looks like implied trait bounds still won't work for the
`Self::TexutureId` and `Self::Error` requirements? So those are not
included here.
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
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.
This fixes several things:
- The xwayland code previously incorrectly used the SSD_HEIGHT (for Windows) even when the X11 surface was in a stack
- The SSD_HEIGHT was defined in surface.rs, even though rendering serverside decorations is done in the window/stack
Rename (min|max)_size to (min|max)_size_without_ssd in CosmicSurface and make it act accordingly
Add a new (min|max)_size() in CosmicWindow and CosmicStack, which takes the surface's (min|max)_size and adds the decorations.
Change all callers to use (min|max)_size() from the window or stack respectively, except is_dialog() where it does not matter.
It would make sense to have a bound like
`for<'frame> R::Frame<'frame>: AsGlowFrame<'frame>`. But that appears to
not behave properly due to current limitations of the borrow checker:
https://blog.rust-lang.org/2022/10/28/gats-stabilization.html#implied-static-requirement-from-higher-ranked-trait-bounds
Instead, this makes `glow_frame` and `glow_frame_mut` associated
functions of the `AsGlowRenderer` trait. Then it is pretty
straightforward to make the `RenderElement` implementations generic
using that and `FromGlesError`.
It would make sense to make `Self::Error: FromGlessError` a requirement
of the `AsGlowRenderer` trait, but due to the lack of implied bounds
support, that produces a bunch of errors about missing bounds. If Rustc
improves that eventually, some bounds could be cleaned up a bit:
https://github.com/rust-lang/rust/issues/44491
`(w_elements, p_elements)` tuples are used in a bunch of places. A
struct with named fields is generally an improvement just due to the
fact the order is non-obvious.
But we can also add methods. In particular,
`extend_from_workspace_elements` abstracts out some of the more
redundant code in `workspace_elements`.
It would be nice to avoid allocation everywhere, but iterators would
complicate lifetimes, run into issues with needing multiple mutable
borrows to things like the `Renderer`, and be awkward in certain
functions without generator syntax. In any case, cosmic-comp already
relies on allocating vectors here.
If this abstraction is commonly useful in compositors, perhaps it could
be moved to Smithay.
Setting the clipboard is only allowed when the keyboard focus is the
same client as the client trying to set the clipboard. We shouldn't
allow background windows in stacks to set the clipboard.
I don't know if anything else expects `same_client_as` to have this `any`
behavior.
