diff options
Diffstat (limited to 'protocols')
| -rw-r--r-- | protocols/ext-workspace-unstable-v1.xml | 306 | ||||
| -rw-r--r-- | protocols/meson.build | 1 |
2 files changed, 0 insertions, 307 deletions
diff --git a/protocols/ext-workspace-unstable-v1.xml b/protocols/ext-workspace-unstable-v1.xml deleted file mode 100644 index 24410b62..00000000 --- a/protocols/ext-workspace-unstable-v1.xml +++ /dev/null @@ -1,306 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<protocol name="ext_workspace_unstable_v1"> - <copyright> - Copyright © 2019 Christopher Billington - Copyright © 2020 Ilia Bozhinov - - Permission to use, copy, modify, distribute, and sell this - software and its documentation for any purpose is hereby granted - without fee, provided that the above copyright notice appear in - all copies and that both that copyright notice and this permission - notice appear in supporting documentation, and that the name of - the copyright holders not be used in advertising or publicity - pertaining to distribution of the software without specific, - written prior permission. The copyright holders make no - representations about the suitability of this software for any - purpose. It is provided "as is" without express or implied - warranty. - - THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS - SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND - FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY - SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES - WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN - AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, - ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF - THIS SOFTWARE. - </copyright> - - <interface name="zext_workspace_manager_v1" version="1"> - <description summary="list and control workspaces"> - Workspaces, also called virtual desktops, are groups of surfaces. A - compositor with a concept of workspaces may only show some such groups of - surfaces (those of 'active' workspaces) at a time. 'Activating' a - workspace is a request for the compositor to display that workspace's - surfaces as normal, whereas the compositor may hide or otherwise - de-emphasise surfaces that are associated only with 'inactive' workspaces. - Workspaces are grouped by which sets of outputs they correspond to, and - may contain surfaces only from those outputs. In this way, it is possible - for each output to have its own set of workspaces, or for all outputs (or - any other arbitrary grouping) to share workspaces. Compositors may - optionally conceptually arrange each group of workspaces in an - N-dimensional grid. - - The purpose of this protocol is to enable the creation of taskbars and - docks by providing them with a list of workspaces and their properties, - and allowing them to activate and deactivate workspaces. - - After a client binds the zext_workspace_manager_v1, each workspace will be - sent via the workspace event. - </description> - - <event name="workspace_group"> - <description summary="a workspace group has been created"> - 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 - zext_workspace_group_handle_v1. - </description> - <arg name="workspace_group" type="new_id" interface="zext_workspace_group_handle_v1"/> - </event> - - <request name="commit"> - <description summary="all requests about the workspaces have been sent"> - 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 zext_workspace_handle_v1 objects, for example, deactivating one - workspace and activating another. - </description> - </request> - - <event name="done"> - <description summary="all information about the workspace groups has been sent"> - This event is sent after all changes in all workspace groups have been - sent. - - This allows changes to one or more zext_workspace_group_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 - zext_workspace_group_handle_v1 objects in question. The compositor sends - the done event only after updating the output information in both - workspace groups. - </description> - </event> - - <event name="finished"> - <description summary="the compositor has finished with the workspace_manager"> - This event indicates that the compositor is done sending events to the - zext_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. - </description> - </event> - - <request name="stop"> - <description summary="stop sending events"> - 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. - </description> - </request> - </interface> - - <interface name="zext_workspace_group_handle_v1" version="1"> - <description summary="a workspace group assigned to a set of outputs"> - A zext_workspace_group_handle_v1 object represents a a workspace group - that is assigned a set of outputs and contains a number of workspaces. - - The set of outputs assigned to the workspace group is conveyed to the client via - output_enter and output_leave events, and its workspaces are conveyed with - workspace events. - - For example, a compositor which has a set of workspaces for each output may - advertise a workspace group (and its workspaces) per output, whereas a compositor - where a workspace spans all outputs may advertise a single workspace group for all - outputs. - </description> - - <event name="output_enter"> - <description summary="output assigned to workspace group"> - This event is emitted whenever an output is assigned to the workspace - group. - </description> - <arg name="output" type="object" interface="wl_output"/> - </event> - - <event name="output_leave"> - <description summary="output removed from workspace group"> - This event is emitted whenever an output is removed from the workspace - group. - </description> - <arg name="output" type="object" interface="wl_output"/> - </event> - - <event name="workspace"> - <description summary="workspace added to workspace group"> - This event is emitted whenever a new workspace has been created. - - All initial details of the workspace (name, coordinates, state) will - be sent immediately after this event via the corresponding events in - zext_workspace_handle_v1. - </description> - <arg name="workspace" type="new_id" interface="zext_workspace_handle_v1"/> - </event> - - <event name="remove"> - <description summary="this workspace group has been destroyed"> - This event means the zext_workspace_group_handle_v1 has been destroyed. - It is guaranteed there won't be any more events for this - zext_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. - </description> - </event> - - <request name="create_workspace"> - <description summary="create a new workspace"> - 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. - </description> - <arg name="workspace" type="string"/> - </request> - - <request name="destroy" type="destructor"> - <description summary="destroy the zext_workspace_handle_v1 object"> - Destroys the zext_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. - </description> - </request> - </interface> - - <interface name="zext_workspace_handle_v1" version="1"> - <description summary="a workspace handing a group of surfaces"> - A zext_workspace_handle_v1 object represents a a workspace that handles a - group of surfaces. - - Each workspace has a name, conveyed to the client with the name event; a - list of states, conveyed to the client with the state event; and - optionally a set of coordinates, conveyed to the client with the - coordinates event. The client may request that the compositor activate or - deactivate the workspace. - - Each workspace can belong to only a single workspace group. - Depepending on the compositor policy, there might be workspaces with - the same name in different workspace groups, but these workspaces are still - separate (e.g. one of them might be active while the other is not). - </description> - - <event name="name"> - <description summary="workspace name changed"> - This event is emitted immediately after the zext_workspace_handle_v1 is - created and whenever the name of the workspace changes. - </description> - <arg name="name" type="string"/> - </event> - - <event name="coordinates"> - <description summary="workspace coordinates changed"> - This event is used to organize workspaces into an N-dimensional grid - within a workspace group, and if supported, is emitted immediately after - the zext_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. - </description> - <arg name="coordinates" type="array"/> - </event> - - <event name="state"> - <description summary="the state of the workspace changed"> - This event is emitted immediately after the zext_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. - </description> - <arg name="state" type="array"/> - </event> - - <enum name="state"> - <description summary="types of states on the workspace"> - The different states that a workspace can have. - </description> - - <entry name="active" value="0" summary="the workspace is active"/> - <entry name="urgent" value="1" summary="the workspace requests attention"/> - <entry name="hidden" value="2"> - <description summary="the workspace is not visible"> - The workspace is not visible in its workspace group, and clients - attempting to visualize the compositor workspace state should not - display such workspaces. - </description> - </entry> - </enum> - - <event name="remove"> - <description summary="this workspace has been destroyed"> - This event means the zext_workspace_handle_v1 has been destroyed. It is - guaranteed there won't be any more events for this - zext_workspace_handle_v1. The zext_workspace_handle_v1 becomes inert so - any requests will be ignored except the destroy request. - </description> - </event> - - <request name="destroy" type="destructor"> - <description summary="destroy the zext_workspace_handle_v1 object"> - Destroys the zext_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. - </description> - </request> - - <request name="activate"> - <description summary="activate the workspace"> - 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. - </description> - </request> - - <request name="deactivate"> - <description summary="activate the workspace"> - Request that this workspace be deactivated. - - There is no guarantee the workspace will be actually deactivated. - </description> - </request> - - <request name="remove"> - <description summary="remove the workspace"> - Request that this workspace be removed. - - There is no guarantee the workspace will be actually removed. - </description> - </request> - </interface> -</protocol> diff --git a/protocols/meson.build b/protocols/meson.build index 02e0c95a..60ae20cb 100644 --- a/protocols/meson.build +++ b/protocols/meson.build @@ -29,7 +29,6 @@ protocols = [ ['wlr-layer-shell-unstable-v1.xml'], ['wlr-output-power-management-unstable-v1.xml'], ['wlr-screencopy-unstable-v1.xml'], - ['ext-workspace-unstable-v1.xml'], ['pointer-constraints-unstable-v1.xml'], ['tablet-unstable-v2.xml'], ['idle.xml'], |