diff options
Diffstat (limited to 'raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml')
9 files changed, 2599 insertions, 0 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 new file mode 100644 index 0000000..a4e0b49 --- /dev/null +++ b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/dwl-ipc-unstable-v2.xml @@ -0,0 +1,252 @@ +<?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 new file mode 100644 index 0000000..37ee577 --- /dev/null +++ b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/ext-data-control-v1.xml @@ -0,0 +1,276 @@ +<?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 new file mode 100644 index 0000000..134b729 --- /dev/null +++ b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/ext-workspace-v1.xml @@ -0,0 +1,422 @@ +<?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 new file mode 100644 index 0000000..2774876 --- /dev/null +++ b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/keyboard-shortcuts-inhibit-unstable-v1.xml @@ -0,0 +1,143 @@ +<?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 new file mode 100644 index 0000000..16e0be8 --- /dev/null +++ b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-gamma-control-unstable-v1.xml @@ -0,0 +1,126 @@ +<?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 new file mode 100644 index 0000000..e9f27e4 --- /dev/null +++ b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-layer-shell-unstable-v1.xml @@ -0,0 +1,407 @@ +<?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 new file mode 100644 index 0000000..541284a --- /dev/null +++ b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-output-management-unstable-v1.xml @@ -0,0 +1,611 @@ +<?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 new file mode 100644 index 0000000..20dbb77 --- /dev/null +++ b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-output-power-management-unstable-v1.xml @@ -0,0 +1,128 @@ +<?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 new file mode 100644 index 0000000..8b20661 --- /dev/null +++ b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-screencopy-unstable-v1.xml @@ -0,0 +1,234 @@ +<?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> |