Commit graph

18 commits

Author SHA1 Message Date
Ian Douglas Scott
2b4890c550 protocols/workspace: Track group a workspace is on, and update
It seems previously, workspace migration due to output add could result in
a workspace being removed from a group, but not added to the new group
for existing clients, because the workspace group creation didn't happen
until `done`. And `send_workspace_to_client` didn't send
`workspace_enter` except when a workspace instance is newly created.

That logic worked with the old protocol, but now a workspace can be
moved to a different group.

Seems to fix the issue with workspaces disappearing from the workspaces
view in https://github.com/pop-os/cosmic-comp/issues/1470. I don't seem
to be able to reproduce the panel auto-hide issue, but have seen it in
the past. So it may or may not be prevented from happening now.
2025-07-03 14:25:49 +02:00
Ian Douglas Scott
42c6a3729a Fix compiler warnings 2025-05-19 21:29:51 +02:00
Ian Douglas Scott
96e9bf3b81 Initial support for workspace pinning and moving
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.
2025-04-24 12:45:50 +02:00
Ian Douglas Scott
d1f4e7b12d protocols/workspace: Make move_workspace_to_group move existing handle
The older protocol didn't have a way to do this, but ext-workspace-v1
supports it. And it should be the correct way to do things.
2025-04-22 07:48:23 -07:00
Ian Douglas Scott
e944ee9b2f 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.)
2025-04-22 07:48:23 -07:00
Ian Douglas Scott
2f6d600502 protocol/workspace: Store manager as part of workspace/group udata 2025-04-22 07:48:23 -07:00
Ian Douglas Scott
2d4912bd20 protocol/workspace: Move WorkspaceGroupData to ext.rs
More consistent to have this here next to `WorkspaceData`, now it isn't
shared with cosmic workspace v1.
2025-04-22 07:48:23 -07:00
Ian Douglas Scott
dc67db9a5d protocol/workspace: Remove type bounds that aren't required
It seems at least with Rust 1.82 (the version in `rust-toolchain.toml`)
these bounds are inferred from the `D: WorkspaceHandler` bound, so they
can be specified only there.
2025-04-22 07:48:23 -07:00
Ian Douglas Scott
85254b47d6 protocol/workspace: Drop support for cosmic v1 protocol
Clients have been updated to use ext-workspace-v1 and
cosmic-workspace-v2.

Removing this should save some duplication of having to update both
cosmic workspace v1 and ext workspace code, and should help with things
like using the same workspace handle when a workspace moves to a
different group (which is something that was changed before the final
version of the ext-workspace-v1 protocol.)
2025-04-22 07:48:23 -07:00
Ian Douglas Scott
8d6bd47bc4 Take slice instead of array in set_workspace_coordinates
As far as I can tell this is equivalent, and there's no particular
reason to use an array. Arrays of options for variable-length arrays are
awkward.
2025-03-17 12:00:17 -07:00
Ian Douglas Scott
f9dd922af3 protocol/workspace: Store ext/cosmic specific capabilities
This means a change to an ext capability will not send a redundant
cosmic capability event, and vice versa.

This will be more important when cosmic-specific states are added. Since
those may change often.
2025-03-12 15:44:35 +01:00
Ian Douglas Scott
dea7f2f825 protocol/workspace: Split ext/cosmic-v1 workspace data into two types 2025-03-12 15:44:35 +01:00
Ian Douglas Scott
8b63e09ddc fix(protocol/workspace): Handle cosmic-workspace-v2 destroy requests
I forgot to handle these after I added them to destructors to the
protocol.

I wish we had exhaustiveness checking here...
2025-03-03 13:21:36 -08:00
Ian Douglas Scott
aac8166962 Add cosmic-workspace-v2, image source, toplevel info changes
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.
2025-03-03 12:30:25 +01:00
Ian Douglas Scott
1f2434e590 protocol/workspace: Fix initial sending of states and capabilities
The protocol states that these should always be sent, but this was
not initially sending bitflags if they were empty. That works, but isn't
what the protocol states.

Not wrapping the bitflag fields in options works well for `Workspace`,
but not for `WorkspaceDataInner`.
2025-03-03 12:30:25 +01:00
Ian Douglas Scott
2728a9ee71 protocol/workspace: Fix behavior with multiple manager instances
Similarly to https://github.com/pop-os/cosmic-comp/pull/1061, track a
weak reference to the manager each workspace/group instance was created
from, instead of just matching by client.
2025-02-13 11:31:38 +01:00
Ian Douglas Scott
723f758439 protocol/workspace: Add support for ext-workspace-v1
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.
2025-02-13 11:31:38 +01:00
Ian Douglas Scott
aa15c00d12 protocol/workspace: Move cosmic dispatch code to seperate file 2025-02-13 11:31:38 +01:00