To support both `ext-workspace-v1` and `cosmic-workspace-unstable-v1`,
the API exposed by `wayland/protocols/workspace` now uses the ext
workspace `State` and `GroupCapabilties` bitfields, and converts them to
the cosmic types for the cosmic implementation.
`WorkspaceCapabilities` is a custom type that has cosmic-specific and
ext-specific variants, and is mapped on both backends.
The ext protocol adds an `.assign` request on workspaces, which is
added here, though not currently used.
It also adds an `.id` event. Which we'll probably want when we have
persistent workspaces, but it isn't needed currently.
We still need to add an extension protocol of ext-workspaces to replace
a couple cosmic protocol features.
If the window is part of a stack, remove it then map it outside of the
stack, before calling `Shell::move_window.` Somewhat similar to the code
in `Shell::move_request`.
It would be more elegant if `move_window` handled this in some way, but
I can't think of a way to change the API there that would be better than
this.
(Perhaps some of the naming of methods could also be updated, given
"window" in functions like this means a `CosmicMapped`.)
Protocol support for moving workspaces would also be useful, but should
involve a new protocol object representing the stack.
Fixes https://github.com/pop-os/cosmic-workspaces-epoch/issues/41.
Iterating over `.windows()` for each workspace does not iterate over
`minimized_windows`, so `from_workspace` was not found. Simply changing
this to use `element_for_surface` and `space_for` (like `fullscreen` and
`unfullscreen`) fixes this.
Addresses https://github.com/pop-os/cosmic-workspaces-epoch/issues/89.
Though it does unminimize the window, which we may also want to change.
This is imported given how
https://github.com/pop-os/cosmic-protocols/pull/39 uses this event.
But the protocol spec also states the event "is emitted on creation" so
this is seemingly incorrect regardless.
This should fix an issue where output hotplug can sometimes cause
clients (including XWayland) to crash with a protocol error trying to
bind the output.
Using a timer doesn't seem ideal, but seems to be the correct way to do
this at present. Wlroots `wlr_global_destroy_safe` is basically the same
as this.
Adding a `LoopHandle` argument to `OutputConfigurationState::new` seems
awkward, but maybe better than a handler method for removing globals.
(`IdleNotifierState::new` also takes a `LoopHandle`). Perhaps Smithay
could provide some kind of helper for this.
Having if conditions for these is unnecessary when they should never be
reached. (This is commonly unwrapped in `smithay`.)
Some of these else conditions fail to call `data_init.init` with a new
id, so they'd result in a crash later anyway.
This meant that, for windows that were not fully opaque, there was no
way to capture their transparency. No way to put a window with
transparency on top of a background in OBS, for example.
`Output` in Smithay doesn't track if the output still exists, other than
based on whether or not it has strong references. Which doesn't seem to
be working correctly.
There may be leaked strong references to `Output`s somewhere, and maybe
Smithay should track if an output is still valid, generally when it is
exposed as a Wayland global
(https://github.com/Smithay/smithay/issues/1584). But a check like this
works for now.
Addresses https://github.com/pop-os/cosmic-comp/issues/985.
`from_raw_parts()` is only sound if the alignment is the same, so it
can't be used to covert to a `Vec<u8>` from a type with a greater
alignment.
This isn't hard to avoid, luckily.