COSMIC workspace

The client must send this request after it has finished sending other requests. The compositor must process a series of requests preceding a commit request atomically.

This allows changes to the workspace properties to be seen as atomic, even if they happen via multiple events, and even if they involve multiple zcosmic_workspace_handle_v1 objects, for example, deactivating one workspace and activating another.

Indicates the client no longer wishes to receive events for new workspace groups. However the compositor may emit further workspace events, until the finished event is emitted.

The client must not send any more requests after this one.

This event is emitted whenever a new workspace group has been created.

All initial details of the workspace group (workspaces, outputs) will be sent immediately after this event via the corresponding events in zcosmic_workspace_group_handle_v1.

This event is sent after all changes in all workspace groups have been sent.

This allows changes to one or more zcosmic_workspace_group_handle_v1 properties and zcosmic_workspace_handle_v1 properties to be seen as atomic, even if they happen via multiple events. In particular, an output moving from one workspace group to another sends an output_enter event and an output_leave event to the two zcosmic_workspace_group_handle_v1 objects in question. The compositor sends the done event only after updating the output information in both workspace groups.

This event indicates that the compositor is done sending events to the zcosmic_workspace_manager_v1. The server will destroy the object immediately after sending this request, so it will become invalid and the client should free any resources associated with it.

Request that the compositor create a new workspace with the given name.

There is no guarantee that the compositor will create a new workspace, or that the created workspace will have the provided name.

Destroys the zcosmic_workspace_group_handle_v1 object.

This request should be called either when the client does not want to use the workspace object any more or after the remove event to finalize the destruction of the object.

This event advertises the capabilities supported by the compositor. If a capability isn't supported, clients should hide or disable the UI elements that expose this functionality. For instance, if the compositor doesn't advertise support for creating workspaces, a button triggering the create_workspace request should not be displayed.

The compositor will ignore requests it doesn't support. For instance, a compositor which doesn't advertise support for creating workspaces will ignore create_workspace requests.

Compositors must send this event once after creation of an zcosmic_workspace_group_handle_v1 . When the capabilities change, compositors must send this event again.

The capabilities are sent as an array of 32-bit unsigned integers in native endianness.

This event is emitted whenever an output is assigned to the workspace group.

This event is emitted whenever an output is removed from the workspace group.

This event is emitted whenever a new workspace has been created. A workspace can only be a member of a single workspace group and cannot be re-assigned.

All initial details of the workspace (name, coordinates, state) will be sent immediately after this event via the corresponding events in zcosmic_workspace_handle_v1.

This event means the zcosmic_workspace_group_handle_v1 has been destroyed. It is guaranteed there won't be any more events for this zcosmic_workspace_group_handle_v1. The zext_workspace_group_handle_v1 becomes inert so any requests will be ignored except the destroy request.

The compositor must remove all workspaces belonging to a workspace group before removing the workspace group.

Destroys the zcosmic_workspace_handle_v1 object.

This request should be called either when the client does not want to use the workspace object any more or after the remove event to finalize the destruction of the object.

Request that this workspace be activated.

There is no guarantee the workspace will be actually activated, and behaviour may be compositor-dependent. For example, activating a workspace may or may not deactivate all other workspaces in the same group.

Request that this workspace be deactivated.

There is no guarantee the workspace will be actually deactivated.

Request that this workspace be removed.

There is no guarantee the workspace will be actually removed.

Request that this workspace is renamed.

There is no guarantee the workspace will actually be renamed.

Request that this workspace's tiling state is changed.

There is no guarantee the workspace will actually change it's tiling state.

This event is emitted immediately after the zcosmic_workspace_handle_v1 is created and whenever the name of the workspace changes.

This event is used to organize workspaces into an N-dimensional grid within a workspace group, and if supported, is emitted immediately after the zcosmic_workspace_handle_v1 is created and whenever the coordinates of the workspace change. Compositors may not send this event if they do not conceptually arrange workspaces in this way. If compositors simply number workspaces, without any geometric interpretation, they may send 1D coordinates, which clients should not interpret as implying any geometry. Sending an empty array means that the compositor no longer orders the workspace geometrically.

Coordinates have an arbitrary number of dimensions N with an uint32 position along each dimension. By convention if N > 1, the first dimension is X, the second Y, the third Z, and so on. The compositor may chose to utilize these events for a more novel workspace layout convention, however. No guarantee is made about the grid being filled or bounded; there may be a workspace at coordinate 1 and another at coordinate 1000 and none in between. Within a workspace group, however, workspaces must have unique coordinates of equal dimensionality.

This event is emitted immediately after the zcosmic_workspace_handle_v1 is created and each time the workspace state changes, either because of a compositor action or because of a request in this protocol.

This event advertises the capabilities supported by the compositor. If a capability isn't supported, clients should hide or disable the UI elements that expose this functionality. For instance, if the compositor doesn't advertise support for removing workspaces, a button triggering the remove request should not be displayed.

The compositor will ignore requests it doesn't support. For instance, a compositor which doesn't advertise support for remove will ignore remove requests.

Compositors must send this event once after creation of an zcosmic_workspace_handle_v1 . When the capabilities change, compositors must send this event again.

The capabilities are sent as an array of 32-bit unsigned integers in native endianness.

This event means the zcosmic_workspace_handle_v1 has been destroyed. It is guaranteed there won't be any more events for this zcosmic_workspace_handle_v1. The zext_workspace_handle_v1 becomes inert so any requests will be ignored except the destroy request.

This event is emitted immediately after the zcosmic_workspace_handle_v1 is created and each time the workspace tiling state changes, either because of a compositor action or because of a request in this protocol.

The different states that a workspace can have.