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.
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.)
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.
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.
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`.
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.
