protocols/workspace: Store request queue in workspace manager udata

This is slightly simpler, if there's not some reason I'm missing to do
this as it was previously done. And in particular provides a cleaner
API (if we wanted to move this to Smithay; perhaps without the Cosmic
extension).

But it also should be more correct. Presumably if a client (unusually)
had multiple components with their own `ext_workspace_manager_v1`
instance, they should have their own queues, and
`ext_workspace_manager_v1::commit` should be independent.

Inevitably, there's a racy element to multiple components trying to
update the workspace state like this, but it should behave the same as
two clients with separate connections.

(This is different from `CompositorClientState`, since the commit queue
there is fundamentally tied to the client, and different components with
their own compositor instance way have related surfaces.)
This commit is contained in:
Ian Douglas Scott 2025-04-16 16:05:39 -07:00 committed by Ian Douglas Scott
parent 2f6d600502
commit e944ee9b2f
5 changed files with 106 additions and 113 deletions

View file

@ -2,24 +2,15 @@
use crate::{
shell::WorkspaceDelta,
state::ClientState,
utils::prelude::*,
wayland::protocols::workspace::{
delegate_workspace, Request, WorkspaceClientHandler, WorkspaceClientState,
WorkspaceHandler, WorkspaceState,
delegate_workspace, Request, WorkspaceHandler, WorkspaceState,
},
};
use cosmic_protocols::workspace::v2::server::zcosmic_workspace_handle_v2::TilingState;
use smithay::reexports::wayland_server::DisplayHandle;
impl WorkspaceClientHandler for ClientState {
fn workspace_state(&self) -> &WorkspaceClientState {
&self.workspace_client_state
}
}
impl WorkspaceHandler for State {
type Client = ClientState;
fn workspace_state(&self) -> &WorkspaceState<Self> {
&self.common.workspace_state
}