diff options
| author | Nippy <nippy@rp1.hu> | 2026-05-09 13:33:09 +0200 |
|---|---|---|
| committer | Nippy <nippy@rp1.hu> | 2026-05-09 13:33:09 +0200 |
| commit | a2b924d7e9492b978ad6dc33b6c1ffcb304b4bc5 (patch) | |
| tree | 1a8769217f84bfe9d6216fafaadaf8cdd876d457 /raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml | |
| parent | 34b9c34f982b2596cfa9e368a2d7f74e9a17477c (diff) | |
| download | RaveOS-PKGBUILD-a2b924d7e9492b978ad6dc33b6c1ffcb304b4bc5.tar.gz RaveOS-PKGBUILD-a2b924d7e9492b978ad6dc33b6c1ffcb304b4bc5.zip | |
raveos update
Diffstat (limited to 'raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml')
9 files changed, 0 insertions, 2599 deletions
diff --git a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/dwl-ipc-unstable-v2.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/dwl-ipc-unstable-v2.xml deleted file mode 100644 index a4e0b49..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/dwl-ipc-unstable-v2.xml +++ /dev/null @@ -1,252 +0,0 @@ -<?xml version="1.0" encoding="utf-8"?> -<!-- -This is largely ripped from somebar's ipc patchset; just with some personal modifications. -I would probably just submit raphi's patchset but I don't think that would be polite. ---> -<protocol name="dwl_ipc_unstable_v2"> - <description summary="inter-proccess-communication about dwl's state"> - This protocol allows clients to update and get updates from dwl. - - Warning! The protocol described in this file is experimental and - backward incompatible changes may be made. Backward compatible - changes may be added together with the corresponding interface - version bump. - Backward incompatible changes are done by bumping the version - number in the protocol and interface names and resetting the - interface version. Once the protocol is to be declared stable, - the 'z' prefix and the version number in the protocol and - interface names are removed and the interface version number is - reset. - </description> - - <interface name="zdwl_ipc_manager_v2" version="2"> - <description summary="manage dwl state"> - This interface is exposed as a global in wl_registry. - - Clients can use this interface to get a dwl_ipc_output. - After binding the client will recieve the dwl_ipc_manager.tags and dwl_ipc_manager.layout events. - The dwl_ipc_manager.tags and dwl_ipc_manager.layout events expose tags and layouts to the client. - </description> - - <request name="release" type="destructor"> - <description summary="release dwl_ipc_manager"> - Indicates that the client will not the dwl_ipc_manager object anymore. - Objects created through this instance are not affected. - </description> - </request> - - <request name="get_output"> - <description summary="get a dwl_ipc_outout for a wl_output"> - Get a dwl_ipc_outout for the specified wl_output. - </description> - <arg name="id" type="new_id" interface="zdwl_ipc_output_v2"/> - <arg name="output" type="object" interface="wl_output"/> - </request> - - <event name="tags"> - <description summary="Announces tag amount"> - This event is sent after binding. - A roundtrip after binding guarantees the client recieved all tags. - </description> - <arg name="amount" type="uint"/> - </event> - - <event name="layout"> - <description summary="Announces a layout"> - This event is sent after binding. - A roundtrip after binding guarantees the client recieved all layouts. - </description> - <arg name="name" type="string"/> - </event> - </interface> - - <interface name="zdwl_ipc_output_v2" version="2"> - <description summary="control dwl output"> - Observe and control a dwl output. - - Events are double-buffered: - Clients should cache events and redraw when a dwl_ipc_output.frame event is sent. - - Request are not double-buffered: - The compositor will update immediately upon request. - </description> - - <enum name="tag_state"> - <entry name="none" value="0" summary="no state"/> - <entry name="active" value="1" summary="tag is active"/> - <entry name="urgent" value="2" summary="tag has at least one urgent client"/> - </enum> - - <request name="release" type="destructor"> - <description summary="release dwl_ipc_outout"> - Indicates to that the client no longer needs this dwl_ipc_output. - </description> - </request> - - <event name="toggle_visibility"> - <description summary="Toggle client visibilty"> - Indicates the client should hide or show themselves. - If the client is visible then hide, if hidden then show. - </description> - </event> - - <event name="active"> - <description summary="Update the selected output."> - Indicates if the output is active. Zero is invalid, nonzero is valid. - </description> - <arg name="active" type="uint"/> - </event> - - <event name="tag"> - <description summary="Update the state of a tag."> - Indicates that a tag has been updated. - </description> - <arg name="tag" type="uint" summary="Index of the tag"/> - <arg name="state" type="uint" enum="tag_state" summary="The state of the tag."/> - <arg name="clients" type="uint" summary="The number of clients in the tag."/> - <arg name="focused" type="uint" summary="If there is a focused client. Nonzero being valid, zero being invalid."/> - </event> - - <event name="layout"> - <description summary="Update the layout."> - Indicates a new layout is selected. - </description> - <arg name="layout" type="uint" summary="Index of the layout."/> - </event> - - <event name="title"> - <description summary="Update the title."> - Indicates the title has changed. - </description> - <arg name="title" type="string" summary="The new title name."/> - </event> - - <event name="appid" since="1"> - <description summary="Update the appid."> - Indicates the appid has changed. - </description> - <arg name="appid" type="string" summary="The new appid."/> - </event> - - <event name="layout_symbol" since="1"> - <description summary="Update the current layout symbol"> - Indicates the layout has changed. Since layout symbols are dynamic. - As opposed to the zdwl_ipc_manager.layout event, this should take precendence when displaying. - You can ignore the zdwl_ipc_output.layout event. - </description> - <arg name="layout" type="string" summary="The new layout"/> - </event> - - <event name="frame"> - <description summary="The update sequence is done."> - Indicates that a sequence of status updates have finished and the client should redraw. - </description> - </event> - - <request name="set_tags"> - <description summary="Set the active tags of this output"/> - <arg name="tagmask" type="uint" summary="bitmask of the tags that should be set."/> - <arg name="toggle_tagset" type="uint" summary="toggle the selected tagset, zero for invalid, nonzero for valid."/> - </request> - - <request name="set_client_tags"> - <description summary="Set the tags of the focused client."> - The tags are updated as follows: - new_tags = (current_tags AND and_tags) XOR xor_tags - </description> - <arg name="and_tags" type="uint"/> - <arg name="xor_tags" type="uint"/> - </request> - - <request name="set_layout"> - <description summary="Set the layout of this output"/> - <arg name="index" type="uint" summary="index of a layout recieved by dwl_ipc_manager.layout"/> - </request> - - <request name="quit" since="2"> - <description summary="Quit mango">This request allows clients to instruct the compositor to quit mango.</description> - </request> - - <request name="dispatch" since="2"> - <description summary="Set the active tags of this output"/> - <arg name="dispatch" type="string" summary="dispatch name."/> - <arg name="arg1" type="string" summary="arg1."/> - <arg name="arg2" type="string" summary="arg2."/> - <arg name="arg3" type="string" summary="arg3."/> - <arg name="arg4" type="string" summary="arg4."/> - <arg name="arg5" type="string" summary="arg5."/> - </request> - - <!-- Version 2 --> - <event name="fullscreen" since="2"> - <description summary="Update fullscreen status"> - Indicates if the selected client on this output is fullscreen. - </description> - <arg name="is_fullscreen" type="uint" summary="If the selected client is fullscreen. Nonzero is valid, zero invalid"/> - </event> - - <event name="floating" since="2"> - <description summary="Update the floating status"> - Indicates if the selected client on this output is floating. - </description> - <arg name="is_floating" type="uint" summary="If the selected client is floating. Nonzero is valid, zero invalid"/> - </event> - - <event name="x" since="2"> - <description summary="Update the x coordinates"> - Indicates if x coordinates of the selected client. - </description> - <arg name="x" type="int" summary="x coordinate of the selected client"/> - </event> - - <event name="y" since="2"> - <description summary="Update the y coordinates"> - Indicates if y coordinates of the selected client. - </description> - <arg name="y" type="int" summary="y coordinate of the selected client"/> - </event> - - <event name="width" since="2"> - <description summary="Update the width"> - Indicates if width of the selected client. - </description> - <arg name="width" type="int" summary="width of the selected client"/> - </event> - - <event name="height" since="2"> - <description summary="Update the height"> - Indicates if height of the selected client. - </description> - <arg name="height" type="int" summary="height of the selected client"/> - </event> - - <event name="last_layer" since="2"> - <description summary="last map layer."> - last map layer. - </description> - <arg name="last_layer" type="string" summary="last map layer."/> - </event> - - <event name="kb_layout" since="2"> - <description summary="current keyboard layout."> - current keyboard layout. - </description> - <arg name="kb_layout" type="string" summary="current keyboard layout."/> - </event> - - <event name="keymode" since="2"> - <description summary="current keybind mode."> - current keybind mode. - </description> - <arg name="keymode" type="string" summary="current keybind mode."/> - </event> - - <event name="scalefactor" since="2"> - <description summary="scale factor of monitor."> - scale factor of monitor. - </description> - <arg name="scalefactor" type="uint" summary="scale factor of monitor."/> - </event> - - </interface> -</protocol> diff --git a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/ext-data-control-v1.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/ext-data-control-v1.xml deleted file mode 100644 index 37ee577..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/ext-data-control-v1.xml +++ /dev/null @@ -1,276 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<protocol name="ext_data_control_v1"> - <copyright> - Copyright © 2018 Simon Ser - Copyright © 2019 Ivan Molodetskikh - Copyright © 2024 Neal Gompa - - 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> - - <description summary="control data devices"> - This protocol allows a privileged client to control data devices. In - particular, the client will be able to manage the current selection and take - the role of a clipboard manager. - - Warning! The protocol described in this file is currently in the testing - phase. Backward compatible changes may be added together with the - corresponding interface version bump. Backward incompatible changes can - only be done by creating a new major version of the extension. - </description> - - <interface name="ext_data_control_manager_v1" version="1"> - <description summary="manager to control data devices"> - This interface is a manager that allows creating per-seat data device - controls. - </description> - - <request name="create_data_source"> - <description summary="create a new data source"> - Create a new data source. - </description> - <arg name="id" type="new_id" interface="ext_data_control_source_v1" - summary="data source to create"/> - </request> - - <request name="get_data_device"> - <description summary="get a data device for a seat"> - Create a data device that can be used to manage a seat's selection. - </description> - <arg name="id" type="new_id" interface="ext_data_control_device_v1"/> - <arg name="seat" type="object" interface="wl_seat"/> - </request> - - <request name="destroy" type="destructor"> - <description summary="destroy the manager"> - All objects created by the manager will still remain valid, until their - appropriate destroy request has been called. - </description> - </request> - </interface> - - <interface name="ext_data_control_device_v1" version="1"> - <description summary="manage a data device for a seat"> - This interface allows a client to manage a seat's selection. - - When the seat is destroyed, this object becomes inert. - </description> - - <request name="set_selection"> - <description summary="copy data to the selection"> - This request asks the compositor to set the selection to the data from - the source on behalf of the client. - - The given source may not be used in any further set_selection or - set_primary_selection requests. Attempting to use a previously used - source triggers the used_source protocol error. - - To unset the selection, set the source to NULL. - </description> - <arg name="source" type="object" interface="ext_data_control_source_v1" - allow-null="true"/> - </request> - - <request name="destroy" type="destructor"> - <description summary="destroy this data device"> - Destroys the data device object. - </description> - </request> - - <event name="data_offer"> - <description summary="introduce a new ext_data_control_offer"> - The data_offer event introduces a new ext_data_control_offer object, - which will subsequently be used in either the - ext_data_control_device.selection event (for the regular clipboard - selections) or the ext_data_control_device.primary_selection event (for - the primary clipboard selections). Immediately following the - ext_data_control_device.data_offer event, the new data_offer object - will send out ext_data_control_offer.offer events to describe the MIME - types it offers. - </description> - <arg name="id" type="new_id" interface="ext_data_control_offer_v1"/> - </event> - - <event name="selection"> - <description summary="advertise new selection"> - The selection event is sent out to notify the client of a new - ext_data_control_offer for the selection for this device. The - ext_data_control_device.data_offer and the ext_data_control_offer.offer - events are sent out immediately before this event to introduce the data - offer object. The selection event is sent to a client when a new - selection is set. The ext_data_control_offer is valid until a new - ext_data_control_offer or NULL is received. The client must destroy the - previous selection ext_data_control_offer, if any, upon receiving this - event. Regardless, the previous selection will be ignored once a new - selection ext_data_control_offer is received. - - The first selection event is sent upon binding the - ext_data_control_device object. - </description> - <arg name="id" type="object" interface="ext_data_control_offer_v1" - allow-null="true"/> - </event> - - <event name="finished"> - <description summary="this data control is no longer valid"> - This data control object is no longer valid and should be destroyed by - the client. - </description> - </event> - - <event name="primary_selection"> - <description summary="advertise new primary selection"> - The primary_selection event is sent out to notify the client of a new - ext_data_control_offer for the primary selection for this device. The - ext_data_control_device.data_offer and the ext_data_control_offer.offer - events are sent out immediately before this event to introduce the data - offer object. The primary_selection event is sent to a client when a - new primary selection is set. The ext_data_control_offer is valid until - a new ext_data_control_offer or NULL is received. The client must - destroy the previous primary selection ext_data_control_offer, if any, - upon receiving this event. Regardless, the previous primary selection - will be ignored once a new primary selection ext_data_control_offer is - received. - - If the compositor supports primary selection, the first - primary_selection event is sent upon binding the - ext_data_control_device object. - </description> - <arg name="id" type="object" interface="ext_data_control_offer_v1" - allow-null="true"/> - </event> - - <request name="set_primary_selection"> - <description summary="copy data to the primary selection"> - This request asks the compositor to set the primary selection to the - data from the source on behalf of the client. - - The given source may not be used in any further set_selection or - set_primary_selection requests. Attempting to use a previously used - source triggers the used_source protocol error. - - To unset the primary selection, set the source to NULL. - - The compositor will ignore this request if it does not support primary - selection. - </description> - <arg name="source" type="object" interface="ext_data_control_source_v1" - allow-null="true"/> - </request> - - <enum name="error"> - <entry name="used_source" value="1" - summary="source given to set_selection or set_primary_selection was already used before"/> - </enum> - </interface> - - <interface name="ext_data_control_source_v1" version="1"> - <description summary="offer to transfer data"> - The ext_data_control_source object is the source side of a - ext_data_control_offer. It is created by the source client in a data - transfer and provides a way to describe the offered data and a way to - respond to requests to transfer the data. - </description> - - <enum name="error"> - <entry name="invalid_offer" value="1" - summary="offer sent after ext_data_control_device.set_selection"/> - </enum> - - <request name="offer"> - <description summary="add an offered MIME type"> - This request adds a MIME type to the set of MIME types advertised to - targets. Can be called several times to offer multiple types. - - Calling this after ext_data_control_device.set_selection is a protocol - error. - </description> - <arg name="mime_type" type="string" - summary="MIME type offered by the data source"/> - </request> - - <request name="destroy" type="destructor"> - <description summary="destroy this source"> - Destroys the data source object. - </description> - </request> - - <event name="send"> - <description summary="send the data"> - Request for data from the client. Send the data as the specified MIME - type over the passed file descriptor, then close it. - </description> - <arg name="mime_type" type="string" summary="MIME type for the data"/> - <arg name="fd" type="fd" summary="file descriptor for the data"/> - </event> - - <event name="cancelled"> - <description summary="selection was cancelled"> - This data source is no longer valid. The data source has been replaced - by another data source. - - The client should clean up and destroy this data source. - </description> - </event> - </interface> - - <interface name="ext_data_control_offer_v1" version="1"> - <description summary="offer to transfer data"> - A ext_data_control_offer represents a piece of data offered for transfer - by another client (the source client). The offer describes the different - MIME types that the data can be converted to and provides the mechanism - for transferring the data directly from the source client. - </description> - - <request name="receive"> - <description summary="request that the data is transferred"> - To transfer the offered data, the client issues this request and - indicates the MIME type it wants to receive. The transfer happens - through the passed file descriptor (typically created with the pipe - system call). The source client writes the data in the MIME type - representation requested and then closes the file descriptor. - - The receiving client reads from the read end of the pipe until EOF and - then closes its end, at which point the transfer is complete. - - This request may happen multiple times for different MIME types. - </description> - <arg name="mime_type" type="string" - summary="MIME type desired by receiver"/> - <arg name="fd" type="fd" summary="file descriptor for data transfer"/> - </request> - - <request name="destroy" type="destructor"> - <description summary="destroy this offer"> - Destroys the data offer object. - </description> - </request> - - <event name="offer"> - <description summary="advertise offered MIME type"> - Sent immediately after creating the ext_data_control_offer object. - One event per offered MIME type. - </description> - <arg name="mime_type" type="string" summary="offered MIME type"/> - </event> - </interface> -</protocol> diff --git a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/ext-workspace-v1.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/ext-workspace-v1.xml deleted file mode 100644 index 134b729..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/ext-workspace-v1.xml +++ /dev/null @@ -1,422 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<protocol name="ext_workspace_v1"> - <copyright> - Copyright © 2019 Christopher Billington - Copyright © 2020 Ilia Bozhinov - Copyright © 2022 Victoria Brekenfeld - - 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="ext_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 ext_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 (outputs) will be - sent immediately after this event via the corresponding events in - ext_workspace_group_handle_v1 and ext_workspace_handle_v1. - </description> - <arg name="workspace_group" type="new_id" interface="ext_workspace_group_handle_v1"/> - </event> - - <event name="workspace"> - <description summary="workspace has been created"> - 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 - ext_workspace_handle_v1. - - Workspaces start off unassigned to any workspace group. - </description> - <arg name="workspace" type="new_id" interface="ext_workspace_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 ext_workspace_handle_v1 objects, for example, deactivating one - workspace and activating another. - </description> - </request> - - <event name="done"> - <description summary="all information about the workspaces and workspace groups has been sent"> - This event is sent after all changes in all workspaces and workspace groups have been - sent. - - This allows changes to one or more ext_workspace_group_handle_v1 - properties and ext_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 - ext_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" type="destructor"> - <description summary="the compositor has finished with the workspace_manager"> - This event indicates that the compositor is done sending events to the - ext_workspace_manager_v1. The server will destroy the object - immediately after sending this request. - </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 compositor is expected - to send the finished event eventually once the stop request has been processed. - - The client must not send any requests after this one, doing so will raise a wl_display - invalid_object error. - </description> - </request> - - </interface> - - <interface name="ext_workspace_group_handle_v1" version="1"> - <description summary="a workspace group assigned to a set of outputs"> - A ext_workspace_group_handle_v1 object represents 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> - - <enum name="group_capabilities" bitfield="true"> - <entry name="create_workspace" value="1" summary="create_workspace request is available"/> - </enum> - - <event name="capabilities"> - <description summary="compositor capabilities"> - 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 - ext_workspace_group_handle_v1. When the capabilities change, compositors - must send this event again. - </description> - <arg name="capabilities" type="uint" summary="capabilities" enum="group_capabilities"/> - </event> - - <event name="output_enter"> - <description summary="output assigned to workspace group"> - This event is emitted whenever an output is assigned to the workspace - group or a new `wl_output` object is bound by the client, which was already - assigned to this 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_enter"> - <description summary="workspace added to workspace group"> - This event is emitted whenever a workspace is assigned to this group. - A workspace may only ever be assigned to a single group at a single point - in time, but can be re-assigned during it's lifetime. - </description> - <arg name="workspace" type="object" interface="ext_workspace_handle_v1"/> - </event> - - <event name="workspace_leave"> - <description summary="workspace removed from workspace group"> - This event is emitted whenever a workspace is removed from this group. - </description> - <arg name="workspace" type="object" interface="ext_workspace_handle_v1"/> - </event> - - <event name="removed"> - <description summary="this workspace group has been removed"> - This event is send when the group associated with the ext_workspace_group_handle_v1 - has been removed. After sending this request the compositor will immediately consider - the object inert. Any requests will be ignored except the destroy request. - It is guaranteed there won't be any more events referencing this - ext_workspace_group_handle_v1. - - The compositor must remove all workspaces belonging to a workspace group - via a workspace_leave event 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 - and assign it to this group. - - 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 ext_workspace_group_handle_v1 object"> - Destroys the ext_workspace_group_handle_v1 object. - - This request should be send either when the client does not want to - use the workspace group object any more or after the removed event to finalize - the destruction of the object. - </description> - </request> - </interface> - - <interface name="ext_workspace_handle_v1" version="1"> - <description summary="a workspace handing a group of surfaces"> - A ext_workspace_handle_v1 object represents a workspace that handles a - group of surfaces. - - Each workspace has: - - a name, conveyed to the client with the name event - - potentially an id conveyed with the id 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. - Depending 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="id"> - <description summary="workspace id"> - If this event is emitted, it will be send immediately after the - ext_workspace_handle_v1 is created or when an id is assigned to - a workspace (at most once during it's lifetime). - - An id will never change during the lifetime of the `ext_workspace_handle_v1` - and is guaranteed to be unique during it's lifetime. - - Ids are not human-readable and shouldn't be displayed, use `name` for that purpose. - - Compositors are expected to only send ids for workspaces likely stable across multiple - sessions and can be used by clients to store preferences for workspaces. Workspaces without - ids should be considered temporary and any data associated with them should be deleted once - the respective object is lost. - </description> - <arg name="id" type="string"/> - </event> - - <event name="name"> - <description summary="workspace name changed"> - This event is emitted immediately after the ext_workspace_handle_v1 is - created and whenever the name of the workspace changes. - - A name is meant to be human-readable and can be displayed to a user. - Unlike the id it is neither stable nor unique. - </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 ext_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> - - <enum name="state" bitfield="true"> - <description summary="types of states on the workspace"> - The different states that a workspace can have. - </description> - - <entry name="active" value="1" summary="the workspace is active"/> - <entry name="urgent" value="2" summary="the workspace requests attention"/> - <entry name="hidden" value="4"> - <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="state"> - <description summary="the state of the workspace changed"> - This event is emitted immediately after the ext_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. - - Missing states convey the opposite meaning, e.g. an unset active bit - means the workspace is currently inactive. - </description> - <arg name="state" type="uint" enum="state"/> - </event> - - <enum name="workspace_capabilities" bitfield="true"> - <entry name="activate" value="1" summary="activate request is available"/> - <entry name="deactivate" value="2" summary="deactivate request is available"/> - <entry name="remove" value="4" summary="remove request is available"/> - <entry name="assign" value="8" summary="assign request is available"/> - </enum> - - <event name="capabilities"> - <description summary="compositor capabilities"> - 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 - ext_workspace_handle_v1 . When the capabilities change, compositors - must send this event again. - </description> - <arg name="capabilities" type="uint" summary="capabilities" enum="workspace_capabilities"/> - </event> - - <event name="removed"> - <description summary="this workspace has been removed"> - This event is send when the workspace associated with the ext_workspace_handle_v1 - has been removed. After sending this request, the compositor will immediately consider - the object inert. Any requests will be ignored except the destroy request. - - It is guaranteed there won't be any more events referencing this - ext_workspace_handle_v1. - - The compositor must only remove a workspaces not currently belonging to any - workspace_group. - </description> - </event> - - <request name="destroy" type="destructor"> - <description summary="destroy the ext_workspace_handle_v1 object"> - Destroys the ext_workspace_handle_v1 object. - - This request should be made 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="deactivate the workspace"> - Request that this workspace be deactivated. - - There is no guarantee the workspace will be actually deactivated. - </description> - </request> - - <request name="assign"> - <description summary="assign workspace to group"> - Requests that this workspace is assigned to the given workspace group. - - There is no guarantee the workspace will be assigned. - </description> - <arg name="workspace_group" type="object" interface="ext_workspace_group_handle_v1"/> - </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/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/keyboard-shortcuts-inhibit-unstable-v1.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/keyboard-shortcuts-inhibit-unstable-v1.xml deleted file mode 100644 index 2774876..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/keyboard-shortcuts-inhibit-unstable-v1.xml +++ /dev/null @@ -1,143 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<protocol name="keyboard_shortcuts_inhibit_unstable_v1"> - - <copyright> - Copyright © 2017 Red Hat Inc. - - Permission is hereby granted, free of charge, to any person obtaining a - copy of this software and associated documentation files (the "Software"), - to deal in the Software without restriction, including without limitation - the rights to use, copy, modify, merge, publish, distribute, sublicense, - and/or sell copies of the Software, and to permit persons to whom the - Software is furnished to do so, subject to the following conditions: - - The above copyright notice and this permission notice (including the next - paragraph) shall be included in all copies or substantial portions of the - Software. - - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - DEALINGS IN THE SOFTWARE. - </copyright> - - <description summary="Protocol for inhibiting the compositor keyboard shortcuts"> - This protocol specifies a way for a client to request the compositor - to ignore its own keyboard shortcuts for a given seat, so that all - key events from that seat get forwarded to a surface. - - Warning! The protocol described in this file is experimental and - backward incompatible changes may be made. Backward compatible - changes may be added together with the corresponding interface - version bump. - Backward incompatible changes are done by bumping the version - number in the protocol and interface names and resetting the - interface version. Once the protocol is to be declared stable, - the 'z' prefix and the version number in the protocol and - interface names are removed and the interface version number is - reset. - </description> - - <interface name="zwp_keyboard_shortcuts_inhibit_manager_v1" version="1"> - <description summary="context object for keyboard grab_manager"> - A global interface used for inhibiting the compositor keyboard shortcuts. - </description> - - <request name="destroy" type="destructor"> - <description summary="destroy the keyboard shortcuts inhibitor object"> - Destroy the keyboard shortcuts inhibitor manager. - </description> - </request> - - <request name="inhibit_shortcuts"> - <description summary="create a new keyboard shortcuts inhibitor object"> - Create a new keyboard shortcuts inhibitor object associated with - the given surface for the given seat. - - If shortcuts are already inhibited for the specified seat and surface, - a protocol error "already_inhibited" is raised by the compositor. - </description> - <arg name="id" type="new_id" interface="zwp_keyboard_shortcuts_inhibitor_v1"/> - <arg name="surface" type="object" interface="wl_surface" - summary="the surface that inhibits the keyboard shortcuts behavior"/> - <arg name="seat" type="object" interface="wl_seat" - summary="the wl_seat for which keyboard shortcuts should be disabled"/> - </request> - - <enum name="error"> - <entry name="already_inhibited" - value="0" - summary="the shortcuts are already inhibited for this surface"/> - </enum> - </interface> - - <interface name="zwp_keyboard_shortcuts_inhibitor_v1" version="1"> - <description summary="context object for keyboard shortcuts inhibitor"> - A keyboard shortcuts inhibitor instructs the compositor to ignore - its own keyboard shortcuts when the associated surface has keyboard - focus. As a result, when the surface has keyboard focus on the given - seat, it will receive all key events originating from the specified - seat, even those which would normally be caught by the compositor for - its own shortcuts. - - The Wayland compositor is however under no obligation to disable - all of its shortcuts, and may keep some special key combo for its own - use, including but not limited to one allowing the user to forcibly - restore normal keyboard events routing in the case of an unwilling - client. The compositor may also use the same key combo to reactivate - an existing shortcut inhibitor that was previously deactivated on - user request. - - When the compositor restores its own keyboard shortcuts, an - "inactive" event is emitted to notify the client that the keyboard - shortcuts inhibitor is not effectively active for the surface and - seat any more, and the client should not expect to receive all - keyboard events. - - When the keyboard shortcuts inhibitor is inactive, the client has - no way to forcibly reactivate the keyboard shortcuts inhibitor. - - The user can chose to re-enable a previously deactivated keyboard - shortcuts inhibitor using any mechanism the compositor may offer, - in which case the compositor will send an "active" event to notify - the client. - - If the surface is destroyed, unmapped, or loses the seat's keyboard - focus, the keyboard shortcuts inhibitor becomes irrelevant and the - compositor will restore its own keyboard shortcuts but no "inactive" - event is emitted in this case. - </description> - - <request name="destroy" type="destructor"> - <description summary="destroy the keyboard shortcuts inhibitor object"> - Remove the keyboard shortcuts inhibitor from the associated wl_surface. - </description> - </request> - - <event name="active"> - <description summary="shortcuts are inhibited"> - This event indicates that the shortcut inhibitor is active. - - The compositor sends this event every time compositor shortcuts - are inhibited on behalf of the surface. When active, the client - may receive input events normally reserved by the compositor - (see zwp_keyboard_shortcuts_inhibitor_v1). - - This occurs typically when the initial request "inhibit_shortcuts" - first becomes active or when the user instructs the compositor to - re-enable and existing shortcuts inhibitor using any mechanism - offered by the compositor. - </description> - </event> - - <event name="inactive"> - <description summary="shortcuts are restored"> - This event indicates that the shortcuts inhibitor is inactive, - normal shortcuts processing is restored by the compositor. - </description> - </event> - </interface> -</protocol> diff --git a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-gamma-control-unstable-v1.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-gamma-control-unstable-v1.xml deleted file mode 100644 index 16e0be8..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-gamma-control-unstable-v1.xml +++ /dev/null @@ -1,126 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<protocol name="wlr_gamma_control_unstable_v1"> - <copyright> - Copyright © 2015 Giulio camuffo - Copyright © 2018 Simon Ser - - 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> - - <description summary="manage gamma tables of outputs"> - This protocol allows a privileged client to set the gamma tables for - outputs. - - Warning! The protocol described in this file is experimental and - backward incompatible changes may be made. Backward compatible changes - may be added together with the corresponding interface version bump. - Backward incompatible changes are done by bumping the version number in - the protocol and interface names and resetting the interface version. - Once the protocol is to be declared stable, the 'z' prefix and the - version number in the protocol and interface names are removed and the - interface version number is reset. - </description> - - <interface name="zwlr_gamma_control_manager_v1" version="1"> - <description summary="manager to create per-output gamma controls"> - This interface is a manager that allows creating per-output gamma - controls. - </description> - - <request name="get_gamma_control"> - <description summary="get a gamma control for an output"> - Create a gamma control that can be used to adjust gamma tables for the - provided output. - </description> - <arg name="id" type="new_id" interface="zwlr_gamma_control_v1"/> - <arg name="output" type="object" interface="wl_output"/> - </request> - - <request name="destroy" type="destructor"> - <description summary="destroy the manager"> - All objects created by the manager will still remain valid, until their - appropriate destroy request has been called. - </description> - </request> - </interface> - - <interface name="zwlr_gamma_control_v1" version="1"> - <description summary="adjust gamma tables for an output"> - This interface allows a client to adjust gamma tables for a particular - output. - - The client will receive the gamma size, and will then be able to set gamma - tables. At any time the compositor can send a failed event indicating that - this object is no longer valid. - - There can only be at most one gamma control object per output, which - has exclusive access to this particular output. When the gamma control - object is destroyed, the gamma table is restored to its original value. - </description> - - <event name="gamma_size"> - <description summary="size of gamma ramps"> - Advertise the size of each gamma ramp. - - This event is sent immediately when the gamma control object is created. - </description> - <arg name="size" type="uint" summary="number of elements in a ramp"/> - </event> - - <enum name="error"> - <entry name="invalid_gamma" value="1" summary="invalid gamma tables"/> - </enum> - - <request name="set_gamma"> - <description summary="set the gamma table"> - Set the gamma table. The file descriptor can be memory-mapped to provide - the raw gamma table, which contains successive gamma ramps for the red, - green and blue channels. Each gamma ramp is an array of 16-byte unsigned - integers which has the same length as the gamma size. - - The file descriptor data must have the same length as three times the - gamma size. - </description> - <arg name="fd" type="fd" summary="gamma table file descriptor"/> - </request> - - <event name="failed"> - <description summary="object no longer valid"> - This event indicates that the gamma control is no longer valid. This - can happen for a number of reasons, including: - - The output doesn't support gamma tables - - Setting the gamma tables failed - - Another client already has exclusive gamma control for this output - - The compositor has transferred gamma control to another client - - Upon receiving this event, the client should destroy this object. - </description> - </event> - - <request name="destroy" type="destructor"> - <description summary="destroy this control"> - Destroys the gamma control object. If the object is still valid, this - restores the original gamma tables. - </description> - </request> - </interface> -</protocol> diff --git a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-layer-shell-unstable-v1.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-layer-shell-unstable-v1.xml deleted file mode 100644 index e9f27e4..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-layer-shell-unstable-v1.xml +++ /dev/null @@ -1,407 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<protocol name="wlr_layer_shell_unstable_v1"> - <copyright> - Copyright © 2017 Drew DeVault - - 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="zwlr_layer_shell_v1" version="5"> - <description summary="create surfaces that are layers of the desktop"> - Clients can use this interface to assign the surface_layer role to - wl_surfaces. Such surfaces are assigned to a "layer" of the output and - rendered with a defined z-depth respective to each other. They may also be - anchored to the edges and corners of a screen and specify input handling - semantics. This interface should be suitable for the implementation of - many desktop shell components, and a broad number of other applications - that interact with the desktop. - </description> - - <request name="get_layer_surface"> - <description summary="create a layer_surface from a surface"> - Create a layer surface for an existing surface. This assigns the role of - layer_surface, or raises a protocol error if another role is already - assigned. - - Creating a layer surface from a wl_surface which has a buffer attached - or committed is a client error, and any attempts by a client to attach - or manipulate a buffer prior to the first layer_surface.configure call - must also be treated as errors. - - After creating a layer_surface object and setting it up, the client - must perform an initial commit without any buffer attached. - The compositor will reply with a layer_surface.configure event. - The client must acknowledge it and is then allowed to attach a buffer - to map the surface. - - You may pass NULL for output to allow the compositor to decide which - output to use. Generally this will be the one that the user most - recently interacted with. - - Clients can specify a namespace that defines the purpose of the layer - surface. - </description> - <arg name="id" type="new_id" interface="zwlr_layer_surface_v1"/> - <arg name="surface" type="object" interface="wl_surface"/> - <arg name="output" type="object" interface="wl_output" allow-null="true"/> - <arg name="layer" type="uint" enum="layer" summary="layer to add this surface to"/> - <arg name="namespace" type="string" summary="namespace for the layer surface"/> - </request> - - <enum name="error"> - <entry name="role" value="0" summary="wl_surface has another role"/> - <entry name="invalid_layer" value="1" summary="layer value is invalid"/> - <entry name="already_constructed" value="2" summary="wl_surface has a buffer attached or committed"/> - </enum> - - <enum name="layer"> - <description summary="available layers for surfaces"> - These values indicate which layers a surface can be rendered in. They - are ordered by z depth, bottom-most first. Traditional shell surfaces - will typically be rendered between the bottom and top layers. - Fullscreen shell surfaces are typically rendered at the top layer. - Multiple surfaces can share a single layer, and ordering within a - single layer is undefined. - </description> - - <entry name="background" value="0"/> - <entry name="bottom" value="1"/> - <entry name="top" value="2"/> - <entry name="overlay" value="3"/> - </enum> - - <!-- Version 3 additions --> - - <request name="destroy" type="destructor" since="3"> - <description summary="destroy the layer_shell object"> - This request indicates that the client will not use the layer_shell - object any more. Objects that have been created through this instance - are not affected. - </description> - </request> - </interface> - - <interface name="zwlr_layer_surface_v1" version="5"> - <description summary="layer metadata interface"> - An interface that may be implemented by a wl_surface, for surfaces that - are designed to be rendered as a layer of a stacked desktop-like - environment. - - Layer surface state (layer, size, anchor, exclusive zone, - margin, interactivity) is double-buffered, and will be applied at the - time wl_surface.commit of the corresponding wl_surface is called. - - Attaching a null buffer to a layer surface unmaps it. - - Unmapping a layer_surface means that the surface cannot be shown by the - compositor until it is explicitly mapped again. The layer_surface - returns to the state it had right after layer_shell.get_layer_surface. - The client can re-map the surface by performing a commit without any - buffer attached, waiting for a configure event and handling it as usual. - </description> - - <request name="set_size"> - <description summary="sets the size of the surface"> - Sets the size of the surface in surface-local coordinates. The - compositor will display the surface centered with respect to its - anchors. - - If you pass 0 for either value, the compositor will assign it and - inform you of the assignment in the configure event. You must set your - anchor to opposite edges in the dimensions you omit; not doing so is a - protocol error. Both values are 0 by default. - - Size is double-buffered, see wl_surface.commit. - </description> - <arg name="width" type="uint"/> - <arg name="height" type="uint"/> - </request> - - <request name="set_anchor"> - <description summary="configures the anchor point of the surface"> - Requests that the compositor anchor the surface to the specified edges - and corners. If two orthogonal edges are specified (e.g. 'top' and - 'left'), then the anchor point will be the intersection of the edges - (e.g. the top left corner of the output); otherwise the anchor point - will be centered on that edge, or in the center if none is specified. - - Anchor is double-buffered, see wl_surface.commit. - </description> - <arg name="anchor" type="uint" enum="anchor"/> - </request> - - <request name="set_exclusive_zone"> - <description summary="configures the exclusive geometry of this surface"> - Requests that the compositor avoids occluding an area with other - surfaces. The compositor's use of this information is - implementation-dependent - do not assume that this region will not - actually be occluded. - - A positive value is only meaningful if the surface is anchored to one - edge or an edge and both perpendicular edges. If the surface is not - anchored, anchored to only two perpendicular edges (a corner), anchored - to only two parallel edges or anchored to all edges, a positive value - will be treated the same as zero. - - A positive zone is the distance from the edge in surface-local - coordinates to consider exclusive. - - Surfaces that do not wish to have an exclusive zone may instead specify - how they should interact with surfaces that do. If set to zero, the - surface indicates that it would like to be moved to avoid occluding - surfaces with a positive exclusive zone. If set to -1, the surface - indicates that it would not like to be moved to accommodate for other - surfaces, and the compositor should extend it all the way to the edges - it is anchored to. - - For example, a panel might set its exclusive zone to 10, so that - maximized shell surfaces are not shown on top of it. A notification - might set its exclusive zone to 0, so that it is moved to avoid - occluding the panel, but shell surfaces are shown underneath it. A - wallpaper or lock screen might set their exclusive zone to -1, so that - they stretch below or over the panel. - - The default value is 0. - - Exclusive zone is double-buffered, see wl_surface.commit. - </description> - <arg name="zone" type="int"/> - </request> - - <request name="set_margin"> - <description summary="sets a margin from the anchor point"> - Requests that the surface be placed some distance away from the anchor - point on the output, in surface-local coordinates. Setting this value - for edges you are not anchored to has no effect. - - The exclusive zone includes the margin. - - Margin is double-buffered, see wl_surface.commit. - </description> - <arg name="top" type="int"/> - <arg name="right" type="int"/> - <arg name="bottom" type="int"/> - <arg name="left" type="int"/> - </request> - - <enum name="keyboard_interactivity"> - <description summary="types of keyboard interaction possible for a layer shell surface"> - Types of keyboard interaction possible for layer shell surfaces. The - rationale for this is twofold: (1) some applications are not interested - in keyboard events and not allowing them to be focused can improve the - desktop experience; (2) some applications will want to take exclusive - keyboard focus. - </description> - - <entry name="none" value="0"> - <description summary="no keyboard focus is possible"> - This value indicates that this surface is not interested in keyboard - events and the compositor should never assign it the keyboard focus. - - This is the default value, set for newly created layer shell surfaces. - - This is useful for e.g. desktop widgets that display information or - only have interaction with non-keyboard input devices. - </description> - </entry> - <entry name="exclusive" value="1"> - <description summary="request exclusive keyboard focus"> - Request exclusive keyboard focus if this surface is above the shell surface layer. - - For the top and overlay layers, the seat will always give - exclusive keyboard focus to the top-most layer which has keyboard - interactivity set to exclusive. If this layer contains multiple - surfaces with keyboard interactivity set to exclusive, the compositor - determines the one receiving keyboard events in an implementation- - defined manner. In this case, no guarantee is made when this surface - will receive keyboard focus (if ever). - - For the bottom and background layers, the compositor is allowed to use - normal focus semantics. - - This setting is mainly intended for applications that need to ensure - they receive all keyboard events, such as a lock screen or a password - prompt. - </description> - </entry> - <entry name="on_demand" value="2" since="4"> - <description summary="request regular keyboard focus semantics"> - This requests the compositor to allow this surface to be focused and - unfocused by the user in an implementation-defined manner. The user - should be able to unfocus this surface even regardless of the layer - it is on. - - Typically, the compositor will want to use its normal mechanism to - manage keyboard focus between layer shell surfaces with this setting - and regular toplevels on the desktop layer (e.g. click to focus). - Nevertheless, it is possible for a compositor to require a special - interaction to focus or unfocus layer shell surfaces (e.g. requiring - a click even if focus follows the mouse normally, or providing a - keybinding to switch focus between layers). - - This setting is mainly intended for desktop shell components (e.g. - panels) that allow keyboard interaction. Using this option can allow - implementing a desktop shell that can be fully usable without the - mouse. - </description> - </entry> - </enum> - - <request name="set_keyboard_interactivity"> - <description summary="requests keyboard events"> - Set how keyboard events are delivered to this surface. By default, - layer shell surfaces do not receive keyboard events; this request can - be used to change this. - - This setting is inherited by child surfaces set by the get_popup - request. - - Layer surfaces receive pointer, touch, and tablet events normally. If - you do not want to receive them, set the input region on your surface - to an empty region. - - Keyboard interactivity is double-buffered, see wl_surface.commit. - </description> - <arg name="keyboard_interactivity" type="uint" enum="keyboard_interactivity"/> - </request> - - <request name="get_popup"> - <description summary="assign this layer_surface as an xdg_popup parent"> - This assigns an xdg_popup's parent to this layer_surface. This popup - should have been created via xdg_surface::get_popup with the parent set - to NULL, and this request must be invoked before committing the popup's - initial state. - - See the documentation of xdg_popup for more details about what an - xdg_popup is and how it is used. - </description> - <arg name="popup" type="object" interface="xdg_popup"/> - </request> - - <request name="ack_configure"> - <description summary="ack a configure event"> - When a configure event is received, if a client commits the - surface in response to the configure event, then the client - must make an ack_configure request sometime before the commit - request, passing along the serial of the configure event. - - If the client receives multiple configure events before it - can respond to one, it only has to ack the last configure event. - - A client is not required to commit immediately after sending - an ack_configure request - it may even ack_configure several times - before its next surface commit. - - A client may send multiple ack_configure requests before committing, but - only the last request sent before a commit indicates which configure - event the client really is responding to. - </description> - <arg name="serial" type="uint" summary="the serial from the configure event"/> - </request> - - <request name="destroy" type="destructor"> - <description summary="destroy the layer_surface"> - This request destroys the layer surface. - </description> - </request> - - <event name="configure"> - <description summary="suggest a surface change"> - The configure event asks the client to resize its surface. - - Clients should arrange their surface for the new states, and then send - an ack_configure request with the serial sent in this configure event at - some point before committing the new surface. - - The client is free to dismiss all but the last configure event it - received. - - The width and height arguments specify the size of the window in - surface-local coordinates. - - The size is a hint, in the sense that the client is free to ignore it if - it doesn't resize, pick a smaller size (to satisfy aspect ratio or - resize in steps of NxM pixels). If the client picks a smaller size and - is anchored to two opposite anchors (e.g. 'top' and 'bottom'), the - surface will be centered on this axis. - - If the width or height arguments are zero, it means the client should - decide its own window dimension. - </description> - <arg name="serial" type="uint"/> - <arg name="width" type="uint"/> - <arg name="height" type="uint"/> - </event> - - <event name="closed"> - <description summary="surface should be closed"> - The closed event is sent by the compositor when the surface will no - longer be shown. The output may have been destroyed or the user may - have asked for it to be removed. Further changes to the surface will be - ignored. The client should destroy the resource after receiving this - event, and create a new surface if they so choose. - </description> - </event> - - <enum name="error"> - <entry name="invalid_surface_state" value="0" summary="provided surface state is invalid"/> - <entry name="invalid_size" value="1" summary="size is invalid"/> - <entry name="invalid_anchor" value="2" summary="anchor bitfield is invalid"/> - <entry name="invalid_keyboard_interactivity" value="3" summary="keyboard interactivity is invalid"/> - <entry name="invalid_exclusive_edge" value="4" summary="exclusive edge is invalid given the surface anchors"/> - </enum> - - <enum name="anchor" bitfield="true"> - <entry name="top" value="1" summary="the top edge of the anchor rectangle"/> - <entry name="bottom" value="2" summary="the bottom edge of the anchor rectangle"/> - <entry name="left" value="4" summary="the left edge of the anchor rectangle"/> - <entry name="right" value="8" summary="the right edge of the anchor rectangle"/> - </enum> - - <!-- Version 2 additions --> - - <request name="set_layer" since="2"> - <description summary="change the layer of the surface"> - Change the layer that the surface is rendered on. - - Layer is double-buffered, see wl_surface.commit. - </description> - <arg name="layer" type="uint" enum="zwlr_layer_shell_v1.layer" summary="layer to move this surface to"/> - </request> - - <!-- Version 5 additions --> - - <request name="set_exclusive_edge" since="5"> - <description summary="set the edge the exclusive zone will be applied to"> - Requests an edge for the exclusive zone to apply. The exclusive - edge will be automatically deduced from anchor points when possible, - but when the surface is anchored to a corner, it will be necessary - to set it explicitly to disambiguate, as it is not possible to deduce - which one of the two corner edges should be used. - - The edge must be one the surface is anchored to, otherwise the - invalid_exclusive_edge protocol error will be raised. - </description> - <arg name="edge" type="uint" enum="anchor"/> - </request> - </interface> -</protocol> diff --git a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-output-management-unstable-v1.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-output-management-unstable-v1.xml deleted file mode 100644 index 541284a..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-output-management-unstable-v1.xml +++ /dev/null @@ -1,611 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<protocol name="wlr_output_management_unstable_v1"> - <copyright> - Copyright © 2019 Purism SPC - - 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> - - <description summary="protocol to configure output devices"> - This protocol exposes interfaces to obtain and modify output device - configuration. - - Warning! The protocol described in this file is experimental and - backward incompatible changes may be made. Backward compatible changes - may be added together with the corresponding interface version bump. - Backward incompatible changes are done by bumping the version number in - the protocol and interface names and resetting the interface version. - Once the protocol is to be declared stable, the 'z' prefix and the - version number in the protocol and interface names are removed and the - interface version number is reset. - </description> - - <interface name="zwlr_output_manager_v1" version="4"> - <description summary="output device configuration manager"> - This interface is a manager that allows reading and writing the current - output device configuration. - - Output devices that display pixels (e.g. a physical monitor or a virtual - output in a window) are represented as heads. Heads cannot be created nor - destroyed by the client, but they can be enabled or disabled and their - properties can be changed. Each head may have one or more available modes. - - Whenever a head appears (e.g. a monitor is plugged in), it will be - advertised via the head event. Immediately after the output manager is - bound, all current heads are advertised. - - Whenever a head's properties change, the relevant wlr_output_head events - will be sent. Not all head properties will be sent: only properties that - have changed need to. - - Whenever a head disappears (e.g. a monitor is unplugged), a - wlr_output_head.finished event will be sent. - - After one or more heads appear, change or disappear, the done event will - be sent. It carries a serial which can be used in a create_configuration - request to update heads properties. - - The information obtained from this protocol should only be used for output - configuration purposes. This protocol is not designed to be a generic - output property advertisement protocol for regular clients. Instead, - protocols such as xdg-output should be used. - </description> - - <event name="head"> - <description summary="introduce a new head"> - This event introduces a new head. This happens whenever a new head - appears (e.g. a monitor is plugged in) or after the output manager is - bound. - </description> - <arg name="head" type="new_id" interface="zwlr_output_head_v1"/> - </event> - - <event name="done"> - <description summary="sent all information about current configuration"> - This event is sent after all information has been sent after binding to - the output manager object and after any subsequent changes. This applies - to child head and mode objects as well. In other words, this event is - sent whenever a head or mode is created or destroyed and whenever one of - their properties has been changed. Not all state is re-sent each time - the current configuration changes: only the actual changes are sent. - - This allows changes to the output configuration to be seen as atomic, - even if they happen via multiple events. - - A serial is sent to be used in a future create_configuration request. - </description> - <arg name="serial" type="uint" summary="current configuration serial"/> - </event> - - <request name="create_configuration"> - <description summary="create a new output configuration object"> - Create a new output configuration object. This allows to update head - properties. - </description> - <arg name="id" type="new_id" interface="zwlr_output_configuration_v1"/> - <arg name="serial" type="uint"/> - </request> - - <request name="stop"> - <description summary="stop sending events"> - Indicates the client no longer wishes to receive events for output - configuration changes. However the compositor may emit further events, - until the finished event is emitted. - - The client must not send any more requests after this one. - </description> - </request> - - <event name="finished" type="destructor"> - <description summary="the compositor has finished with the manager"> - This event indicates that the compositor is done sending manager events. - The compositor will destroy the object immediately after sending this - event, so it will become invalid and the client should release any - resources associated with it. - </description> - </event> - </interface> - - <interface name="zwlr_output_head_v1" version="4"> - <description summary="output device"> - A head is an output device. The difference between a wl_output object and - a head is that heads are advertised even if they are turned off. A head - object only advertises properties and cannot be used directly to change - them. - - A head has some read-only properties: modes, name, description and - physical_size. These cannot be changed by clients. - - Other properties can be updated via a wlr_output_configuration object. - - Properties sent via this interface are applied atomically via the - wlr_output_manager.done event. No guarantees are made regarding the order - in which properties are sent. - </description> - - <event name="name"> - <description summary="head name"> - This event describes the head name. - - The naming convention is compositor defined, but limited to alphanumeric - characters and dashes (-). Each name is unique among all wlr_output_head - objects, but if a wlr_output_head object is destroyed the same name may - be reused later. The names will also remain consistent across sessions - with the same hardware and software configuration. - - Examples of names include 'HDMI-A-1', 'WL-1', 'X11-1', etc. However, do - not assume that the name is a reflection of an underlying DRM - connector, X11 connection, etc. - - If this head matches a wl_output, the wl_output.name event must report - the same name. - - The name event is sent after a wlr_output_head object is created. This - event is only sent once per object, and the name does not change over - the lifetime of the wlr_output_head object. - </description> - <arg name="name" type="string"/> - </event> - - <event name="description"> - <description summary="head description"> - This event describes a human-readable description of the head. - - The description is a UTF-8 string with no convention defined for its - contents. Examples might include 'Foocorp 11" Display' or 'Virtual X11 - output via :1'. However, do not assume that the name is a reflection of - the make, model, serial of the underlying DRM connector or the display - name of the underlying X11 connection, etc. - - If this head matches a wl_output, the wl_output.description event must - report the same name. - - The description event is sent after a wlr_output_head object is created. - This event is only sent once per object, and the description does not - change over the lifetime of the wlr_output_head object. - </description> - <arg name="description" type="string"/> - </event> - - <event name="physical_size"> - <description summary="head physical size"> - This event describes the physical size of the head. This event is only - sent if the head has a physical size (e.g. is not a projector or a - virtual device). - - The physical size event is sent after a wlr_output_head object is created. This - event is only sent once per object, and the physical size does not change over - the lifetime of the wlr_output_head object. - </description> - <arg name="width" type="int" summary="width in millimeters of the output"/> - <arg name="height" type="int" summary="height in millimeters of the output"/> - </event> - - <event name="mode"> - <description summary="introduce a mode"> - This event introduces a mode for this head. It is sent once per - supported mode. - </description> - <arg name="mode" type="new_id" interface="zwlr_output_mode_v1"/> - </event> - - <event name="enabled"> - <description summary="head is enabled or disabled"> - This event describes whether the head is enabled. A disabled head is not - mapped to a region of the global compositor space. - - When a head is disabled, some properties (current_mode, position, - transform and scale) are irrelevant. - </description> - <arg name="enabled" type="int" summary="zero if disabled, non-zero if enabled"/> - </event> - - <event name="current_mode"> - <description summary="current mode"> - This event describes the mode currently in use for this head. It is only - sent if the output is enabled. - </description> - <arg name="mode" type="object" interface="zwlr_output_mode_v1"/> - </event> - - <event name="position"> - <description summary="current position"> - This events describes the position of the head in the global compositor - space. It is only sent if the output is enabled. - </description> - <arg name="x" type="int" - summary="x position within the global compositor space"/> - <arg name="y" type="int" - summary="y position within the global compositor space"/> - </event> - - <event name="transform"> - <description summary="current transformation"> - This event describes the transformation currently applied to the head. - It is only sent if the output is enabled. - </description> - <arg name="transform" type="int" enum="wl_output.transform"/> - </event> - - <event name="scale"> - <description summary="current scale"> - This events describes the scale of the head in the global compositor - space. It is only sent if the output is enabled. - </description> - <arg name="scale" type="fixed"/> - </event> - - <event name="finished"> - <description summary="the head has disappeared"> - This event indicates that the head is no longer available. The head - object becomes inert. Clients should send a destroy request and release - any resources associated with it. - </description> - </event> - - <!-- Version 2 additions --> - - <event name="make" since="2"> - <description summary="head manufacturer"> - This event describes the manufacturer of the head. - - Together with the model and serial_number events the purpose is to - allow clients to recognize heads from previous sessions and for example - load head-specific configurations back. - - It is not guaranteed this event will be ever sent. A reason for that - can be that the compositor does not have information about the make of - the head or the definition of a make is not sensible in the current - setup, for example in a virtual session. Clients can still try to - identify the head by available information from other events but should - be aware that there is an increased risk of false positives. - - If sent, the make event is sent after a wlr_output_head object is - created and only sent once per object. The make does not change over - the lifetime of the wlr_output_head object. - - It is not recommended to display the make string in UI to users. For - that the string provided by the description event should be preferred. - </description> - <arg name="make" type="string"/> - </event> - - <event name="model" since="2"> - <description summary="head model"> - This event describes the model of the head. - - Together with the make and serial_number events the purpose is to - allow clients to recognize heads from previous sessions and for example - load head-specific configurations back. - - It is not guaranteed this event will be ever sent. A reason for that - can be that the compositor does not have information about the model of - the head or the definition of a model is not sensible in the current - setup, for example in a virtual session. Clients can still try to - identify the head by available information from other events but should - be aware that there is an increased risk of false positives. - - If sent, the model event is sent after a wlr_output_head object is - created and only sent once per object. The model does not change over - the lifetime of the wlr_output_head object. - - It is not recommended to display the model string in UI to users. For - that the string provided by the description event should be preferred. - </description> - <arg name="model" type="string"/> - </event> - - <event name="serial_number" since="2"> - <description summary="head serial number"> - This event describes the serial number of the head. - - Together with the make and model events the purpose is to allow clients - to recognize heads from previous sessions and for example load head- - specific configurations back. - - It is not guaranteed this event will be ever sent. A reason for that - can be that the compositor does not have information about the serial - number of the head or the definition of a serial number is not sensible - in the current setup. Clients can still try to identify the head by - available information from other events but should be aware that there - is an increased risk of false positives. - - If sent, the serial number event is sent after a wlr_output_head object - is created and only sent once per object. The serial number does not - change over the lifetime of the wlr_output_head object. - - It is not recommended to display the serial_number string in UI to - users. For that the string provided by the description event should be - preferred. - </description> - <arg name="serial_number" type="string"/> - </event> - - <!-- Version 3 additions --> - - <request name="release" type="destructor" since="3"> - <description summary="destroy the head object"> - This request indicates that the client will no longer use this head - object. - </description> - </request> - - <!-- Version 4 additions --> - - <enum name="adaptive_sync_state" since="4"> - <entry name="disabled" value="0" summary="adaptive sync is disabled"/> - <entry name="enabled" value="1" summary="adaptive sync is enabled"/> - </enum> - - <event name="adaptive_sync" since="4"> - <description summary="current adaptive sync state"> - This event describes whether adaptive sync is currently enabled for - the head or not. Adaptive sync is also known as Variable Refresh - Rate or VRR. - </description> - <arg name="state" type="uint" enum="adaptive_sync_state"/> - </event> - </interface> - - <interface name="zwlr_output_mode_v1" version="3"> - <description summary="output mode"> - This object describes an output mode. - - Some heads don't support output modes, in which case modes won't be - advertised. - - Properties sent via this interface are applied atomically via the - wlr_output_manager.done event. No guarantees are made regarding the order - in which properties are sent. - </description> - - <event name="size"> - <description summary="mode size"> - This event describes the mode size. The size is given in physical - hardware units of the output device. This is not necessarily the same as - the output size in the global compositor space. For instance, the output - may be scaled or transformed. - </description> - <arg name="width" type="int" summary="width of the mode in hardware units"/> - <arg name="height" type="int" summary="height of the mode in hardware units"/> - </event> - - <event name="refresh"> - <description summary="mode refresh rate"> - This event describes the mode's fixed vertical refresh rate. It is only - sent if the mode has a fixed refresh rate. - </description> - <arg name="refresh" type="int" summary="vertical refresh rate in mHz"/> - </event> - - <event name="preferred"> - <description summary="mode is preferred"> - This event advertises this mode as preferred. - </description> - </event> - - <event name="finished"> - <description summary="the mode has disappeared"> - This event indicates that the mode is no longer available. The mode - object becomes inert. Clients should send a destroy request and release - any resources associated with it. - </description> - </event> - - <!-- Version 3 additions --> - - <request name="release" type="destructor" since="3"> - <description summary="destroy the mode object"> - This request indicates that the client will no longer use this mode - object. - </description> - </request> - </interface> - - <interface name="zwlr_output_configuration_v1" version="4"> - <description summary="output configuration"> - This object is used by the client to describe a full output configuration. - - First, the client needs to setup the output configuration. Each head can - be either enabled (and configured) or disabled. It is a protocol error to - send two enable_head or disable_head requests with the same head. It is a - protocol error to omit a head in a configuration. - - Then, the client can apply or test the configuration. The compositor will - then reply with a succeeded, failed or cancelled event. Finally the client - should destroy the configuration object. - </description> - - <enum name="error"> - <entry name="already_configured_head" value="1" - summary="head has been configured twice"/> - <entry name="unconfigured_head" value="2" - summary="head has not been configured"/> - <entry name="already_used" value="3" - summary="request sent after configuration has been applied or tested"/> - </enum> - - <request name="enable_head"> - <description summary="enable and configure a head"> - Enable a head. This request creates a head configuration object that can - be used to change the head's properties. - </description> - <arg name="id" type="new_id" interface="zwlr_output_configuration_head_v1" - summary="a new object to configure the head"/> - <arg name="head" type="object" interface="zwlr_output_head_v1" - summary="the head to be enabled"/> - </request> - - <request name="disable_head"> - <description summary="disable a head"> - Disable a head. - </description> - <arg name="head" type="object" interface="zwlr_output_head_v1" - summary="the head to be disabled"/> - </request> - - <request name="apply"> - <description summary="apply the configuration"> - Apply the new output configuration. - - In case the configuration is successfully applied, there is no guarantee - that the new output state matches completely the requested - configuration. For instance, a compositor might round the scale if it - doesn't support fractional scaling. - - After this request has been sent, the compositor must respond with an - succeeded, failed or cancelled event. Sending a request that isn't the - destructor is a protocol error. - </description> - </request> - - <request name="test"> - <description summary="test the configuration"> - Test the new output configuration. The configuration won't be applied, - but will only be validated. - - Even if the compositor succeeds to test a configuration, applying it may - fail. - - After this request has been sent, the compositor must respond with an - succeeded, failed or cancelled event. Sending a request that isn't the - destructor is a protocol error. - </description> - </request> - - <event name="succeeded"> - <description summary="configuration changes succeeded"> - Sent after the compositor has successfully applied the changes or - tested them. - - Upon receiving this event, the client should destroy this object. - - If the current configuration has changed, events to describe the changes - will be sent followed by a wlr_output_manager.done event. - </description> - </event> - - <event name="failed"> - <description summary="configuration changes failed"> - Sent if the compositor rejects the changes or failed to apply them. The - compositor should revert any changes made by the apply request that - triggered this event. - - Upon receiving this event, the client should destroy this object. - </description> - </event> - - <event name="cancelled"> - <description summary="configuration has been cancelled"> - Sent if the compositor cancels the configuration because the state of an - output changed and the client has outdated information (e.g. after an - output has been hotplugged). - - The client can create a new configuration with a newer serial and try - again. - - Upon receiving this event, the client should destroy this object. - </description> - </event> - - <request name="destroy" type="destructor"> - <description summary="destroy the output configuration"> - Using this request a client can tell the compositor that it is not going - to use the configuration object anymore. Any changes to the outputs - that have not been applied will be discarded. - - This request also destroys wlr_output_configuration_head objects created - via this object. - </description> - </request> - </interface> - - <interface name="zwlr_output_configuration_head_v1" version="4"> - <description summary="head configuration"> - This object is used by the client to update a single head's configuration. - - It is a protocol error to set the same property twice. - </description> - - <enum name="error"> - <entry name="already_set" value="1" summary="property has already been set"/> - <entry name="invalid_mode" value="2" summary="mode doesn't belong to head"/> - <entry name="invalid_custom_mode" value="3" summary="mode is invalid"/> - <entry name="invalid_transform" value="4" summary="transform value outside enum"/> - <entry name="invalid_scale" value="5" summary="scale negative or zero"/> - <entry name="invalid_adaptive_sync_state" value="6" since="4" - summary="invalid enum value used in the set_adaptive_sync request"/> - </enum> - - <request name="set_mode"> - <description summary="set the mode"> - This request sets the head's mode. - </description> - <arg name="mode" type="object" interface="zwlr_output_mode_v1"/> - </request> - - <request name="set_custom_mode"> - <description summary="set a custom mode"> - This request assigns a custom mode to the head. The size is given in - physical hardware units of the output device. If set to zero, the - refresh rate is unspecified. - - It is a protocol error to set both a mode and a custom mode. - </description> - <arg name="width" type="int" summary="width of the mode in hardware units"/> - <arg name="height" type="int" summary="height of the mode in hardware units"/> - <arg name="refresh" type="int" summary="vertical refresh rate in mHz or zero"/> - </request> - - <request name="set_position"> - <description summary="set the position"> - This request sets the head's position in the global compositor space. - </description> - <arg name="x" type="int" summary="x position in the global compositor space"/> - <arg name="y" type="int" summary="y position in the global compositor space"/> - </request> - - <request name="set_transform"> - <description summary="set the transform"> - This request sets the head's transform. - </description> - <arg name="transform" type="int" enum="wl_output.transform"/> - </request> - - <request name="set_scale"> - <description summary="set the scale"> - This request sets the head's scale. - </description> - <arg name="scale" type="fixed"/> - </request> - - <!-- Version 4 additions --> - - <request name="set_adaptive_sync" since="4"> - <description summary="enable/disable adaptive sync"> - This request enables/disables adaptive sync. Adaptive sync is also - known as Variable Refresh Rate or VRR. - </description> - <arg name="state" type="uint" enum="zwlr_output_head_v1.adaptive_sync_state"/> - </request> - </interface> -</protocol> diff --git a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-output-power-management-unstable-v1.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-output-power-management-unstable-v1.xml deleted file mode 100644 index 20dbb77..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-output-power-management-unstable-v1.xml +++ /dev/null @@ -1,128 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<protocol name="wlr_output_power_management_unstable_v1"> - <copyright> - Copyright © 2019 Purism SPC - - Permission is hereby granted, free of charge, to any person obtaining a - copy of this software and associated documentation files (the "Software"), - to deal in the Software without restriction, including without limitation - the rights to use, copy, modify, merge, publish, distribute, sublicense, - and/or sell copies of the Software, and to permit persons to whom the - Software is furnished to do so, subject to the following conditions: - - The above copyright notice and this permission notice (including the next - paragraph) shall be included in all copies or substantial portions of the - Software. - - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - DEALINGS IN THE SOFTWARE. - </copyright> - - <description summary="Control power management modes of outputs"> - This protocol allows clients to control power management modes - of outputs that are currently part of the compositor space. The - intent is to allow special clients like desktop shells to power - down outputs when the system is idle. - - To modify outputs not currently part of the compositor space see - wlr-output-management. - - Warning! The protocol described in this file is experimental and - backward incompatible changes may be made. Backward compatible changes - may be added together with the corresponding interface version bump. - Backward incompatible changes are done by bumping the version number in - the protocol and interface names and resetting the interface version. - Once the protocol is to be declared stable, the 'z' prefix and the - version number in the protocol and interface names are removed and the - interface version number is reset. - </description> - - <interface name="zwlr_output_power_manager_v1" version="1"> - <description summary="manager to create per-output power management"> - This interface is a manager that allows creating per-output power - management mode controls. - </description> - - <request name="get_output_power"> - <description summary="get a power management for an output"> - Create an output power management mode control that can be used to - adjust the power management mode for a given output. - </description> - <arg name="id" type="new_id" interface="zwlr_output_power_v1"/> - <arg name="output" type="object" interface="wl_output"/> - </request> - - <request name="destroy" type="destructor"> - <description summary="destroy the manager"> - All objects created by the manager will still remain valid, until their - appropriate destroy request has been called. - </description> - </request> - </interface> - - <interface name="zwlr_output_power_v1" version="1"> - <description summary="adjust power management mode for an output"> - This object offers requests to set the power management mode of - an output. - </description> - - <enum name="mode"> - <entry name="off" value="0" - summary="Output is turned off."/> - <entry name="on" value="1" - summary="Output is turned on, no power saving"/> - </enum> - - <enum name="error"> - <entry name="invalid_mode" value="1" summary="nonexistent power save mode"/> - </enum> - - <request name="set_mode"> - <description summary="Set an outputs power save mode"> - Set an output's power save mode to the given mode. The mode change - is effective immediately. If the output does not support the given - mode a failed event is sent. - </description> - <arg name="mode" type="uint" enum="mode" summary="the power save mode to set"/> - </request> - - <event name="mode"> - <description summary="Report a power management mode change"> - Report the power management mode change of an output. - - The mode event is sent after an output changed its power - management mode. The reason can be a client using set_mode or the - compositor deciding to change an output's mode. - This event is also sent immediately when the object is created - so the client is informed about the current power management mode. - </description> - <arg name="mode" type="uint" enum="mode" - summary="the output's new power management mode"/> - </event> - - <event name="failed"> - <description summary="object no longer valid"> - This event indicates that the output power management mode control - is no longer valid. This can happen for a number of reasons, - including: - - The output doesn't support power management - - Another client already has exclusive power management mode control - for this output - - The output disappeared - - Upon receiving this event, the client should destroy this object. - </description> - </event> - - <request name="destroy" type="destructor"> - <description summary="destroy this power management"> - Destroys the output power management mode control object. - </description> - </request> - </interface> -</protocol> diff --git a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-screencopy-unstable-v1.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-screencopy-unstable-v1.xml deleted file mode 100644 index 8b20661..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-screencopy-unstable-v1.xml +++ /dev/null @@ -1,234 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<protocol name="wlr_screencopy_unstable_v1"> - <copyright> - Copyright © 2018 Simon Ser - Copyright © 2019 Andri Yngvason - - Permission is hereby granted, free of charge, to any person obtaining a - copy of this software and associated documentation files (the "Software"), - to deal in the Software without restriction, including without limitation - the rights to use, copy, modify, merge, publish, distribute, sublicense, - and/or sell copies of the Software, and to permit persons to whom the - Software is furnished to do so, subject to the following conditions: - - The above copyright notice and this permission notice (including the next - paragraph) shall be included in all copies or substantial portions of the - Software. - - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - DEALINGS IN THE SOFTWARE. - </copyright> - - <description summary="screen content capturing on client buffers"> - This protocol allows clients to ask the compositor to copy part of the - screen content to a client buffer. - - Warning! The protocol described in this file is experimental and - backward incompatible changes may be made. Backward compatible changes - may be added together with the corresponding interface version bump. - Backward incompatible changes are done by bumping the version number in - the protocol and interface names and resetting the interface version. - Once the protocol is to be declared stable, the 'z' prefix and the - version number in the protocol and interface names are removed and the - interface version number is reset. - - Note! This protocol is deprecated and not intended for production use. - The ext-image-copy-capture-v1 protocol should be used instead. - </description> - - <interface name="zwlr_screencopy_manager_v1" version="3"> - <description summary="manager to inform clients and begin capturing"> - This object is a manager which offers requests to start capturing from a - source. - </description> - - <request name="capture_output"> - <description summary="capture an output"> - Capture the next frame of an entire output. - </description> - <arg name="frame" type="new_id" interface="zwlr_screencopy_frame_v1"/> - <arg name="overlay_cursor" type="int" - summary="composite cursor onto the frame"/> - <arg name="output" type="object" interface="wl_output"/> - </request> - - <request name="capture_output_region"> - <description summary="capture an output's region"> - Capture the next frame of an output's region. - - The region is given in output logical coordinates, see - xdg_output.logical_size. The region will be clipped to the output's - extents. - </description> - <arg name="frame" type="new_id" interface="zwlr_screencopy_frame_v1"/> - <arg name="overlay_cursor" type="int" - summary="composite cursor onto the frame"/> - <arg name="output" type="object" interface="wl_output"/> - <arg name="x" type="int"/> - <arg name="y" type="int"/> - <arg name="width" type="int"/> - <arg name="height" type="int"/> - </request> - - <request name="destroy" type="destructor"> - <description summary="destroy the manager"> - All objects created by the manager will still remain valid, until their - appropriate destroy request has been called. - </description> - </request> - </interface> - - <interface name="zwlr_screencopy_frame_v1" version="3"> - <description summary="a frame ready for copy"> - This object represents a single frame. - - When created, a series of buffer events will be sent, each representing a - supported buffer type. The "buffer_done" event is sent afterwards to - indicate that all supported buffer types have been enumerated. The client - will then be able to send a "copy" request. If the capture is successful, - the compositor will send a "flags" event followed by a "ready" event. - - For objects version 2 or lower, wl_shm buffers are always supported, ie. - the "buffer" event is guaranteed to be sent. - - If the capture failed, the "failed" event is sent. This can happen anytime - before the "ready" event. - - Once either a "ready" or a "failed" event is received, the client should - destroy the frame. - </description> - - <event name="buffer"> - <description summary="wl_shm buffer information"> - Provides information about wl_shm buffer parameters that need to be - used for this frame. This event is sent once after the frame is created - if wl_shm buffers are supported. - </description> - <arg name="format" type="uint" enum="wl_shm.format" summary="buffer format"/> - <arg name="width" type="uint" summary="buffer width"/> - <arg name="height" type="uint" summary="buffer height"/> - <arg name="stride" type="uint" summary="buffer stride"/> - </event> - - <request name="copy"> - <description summary="copy the frame"> - Copy the frame to the supplied buffer. The buffer must have the - correct size, see zwlr_screencopy_frame_v1.buffer and - zwlr_screencopy_frame_v1.linux_dmabuf. The buffer needs to have a - supported format. - - If the frame is successfully copied, "flags" and "ready" events are - sent. Otherwise, a "failed" event is sent. - </description> - <arg name="buffer" type="object" interface="wl_buffer"/> - </request> - - <enum name="error"> - <entry name="already_used" value="0" - summary="the object has already been used to copy a wl_buffer"/> - <entry name="invalid_buffer" value="1" - summary="buffer attributes are invalid"/> - </enum> - - <enum name="flags" bitfield="true"> - <entry name="y_invert" value="1" summary="contents are y-inverted"/> - </enum> - - <event name="flags"> - <description summary="frame flags"> - Provides flags about the frame. This event is sent once before the - "ready" event. - </description> - <arg name="flags" type="uint" enum="flags" summary="frame flags"/> - </event> - - <event name="ready"> - <description summary="indicates frame is available for reading"> - Called as soon as the frame is copied, indicating it is available - for reading. This event includes the time at which the presentation took place. - - The timestamp is expressed as tv_sec_hi, tv_sec_lo, tv_nsec triples, - each component being an unsigned 32-bit value. Whole seconds are in - tv_sec which is a 64-bit value combined from tv_sec_hi and tv_sec_lo, - and the additional fractional part in tv_nsec as nanoseconds. Hence, - for valid timestamps tv_nsec must be in [0, 999999999]. The seconds part - may have an arbitrary offset at start. - - After receiving this event, the client should destroy the object. - </description> - <arg name="tv_sec_hi" type="uint" - summary="high 32 bits of the seconds part of the timestamp"/> - <arg name="tv_sec_lo" type="uint" - summary="low 32 bits of the seconds part of the timestamp"/> - <arg name="tv_nsec" type="uint" - summary="nanoseconds part of the timestamp"/> - </event> - - <event name="failed"> - <description summary="frame copy failed"> - This event indicates that the attempted frame copy has failed. - - After receiving this event, the client should destroy the object. - </description> - </event> - - <request name="destroy" type="destructor"> - <description summary="delete this object, used or not"> - Destroys the frame. This request can be sent at any time by the client. - </description> - </request> - - <!-- Version 2 additions --> - <request name="copy_with_damage" since="2"> - <description summary="copy the frame when it's damaged"> - Same as copy, except it waits until there is damage to copy. - </description> - <arg name="buffer" type="object" interface="wl_buffer"/> - </request> - - <event name="damage" since="2"> - <description summary="carries the coordinates of the damaged region"> - This event is sent right before the ready event when copy_with_damage is - requested. It may be generated multiple times for each copy_with_damage - request. - - The arguments describe a box around an area that has changed since the - last copy request that was derived from the current screencopy manager - instance. - - The union of all regions received between the call to copy_with_damage - and a ready event is the total damage since the prior ready event. - </description> - <arg name="x" type="uint" summary="damaged x coordinates"/> - <arg name="y" type="uint" summary="damaged y coordinates"/> - <arg name="width" type="uint" summary="current width"/> - <arg name="height" type="uint" summary="current height"/> - </event> - - <!-- Version 3 additions --> - <event name="linux_dmabuf" since="3"> - <description summary="linux-dmabuf buffer information"> - Provides information about linux-dmabuf buffer parameters that need to - be used for this frame. This event is sent once after the frame is - created if linux-dmabuf buffers are supported. - </description> - <arg name="format" type="uint" summary="fourcc pixel format"/> - <arg name="width" type="uint" summary="buffer width"/> - <arg name="height" type="uint" summary="buffer height"/> - </event> - - <event name="buffer_done" since="3"> - <description summary="all buffer types reported"> - This event is sent once after all buffer events have been sent. - - The client should proceed to create a buffer of one of the supported - types, and send a "copy" request. - </description> - </event> - </interface> -</protocol> |