From a2b924d7e9492b978ad6dc33b6c1ffcb304b4bc5 Mon Sep 17 00:00:00 2001 From: Nippy Date: Sat, 9 May 2026 13:33:09 +0200 Subject: raveos update --- .../internal/proto/xml/dwl-ipc-unstable-v2.xml | 252 --------- .../internal/proto/xml/ext-data-control-v1.xml | 276 ---------- .../core/internal/proto/xml/ext-workspace-v1.xml | 422 -------------- .../xml/keyboard-shortcuts-inhibit-unstable-v1.xml | 143 ----- .../proto/xml/wlr-gamma-control-unstable-v1.xml | 126 ----- .../proto/xml/wlr-layer-shell-unstable-v1.xml | 407 -------------- .../xml/wlr-output-management-unstable-v1.xml | 611 --------------------- .../wlr-output-power-management-unstable-v1.xml | 128 ----- .../proto/xml/wlr-screencopy-unstable-v1.xml | 234 -------- 9 files changed, 2599 deletions(-) delete mode 100644 raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/dwl-ipc-unstable-v2.xml delete mode 100644 raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/ext-data-control-v1.xml delete mode 100644 raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/ext-workspace-v1.xml delete mode 100644 raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/keyboard-shortcuts-inhibit-unstable-v1.xml delete mode 100644 raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-gamma-control-unstable-v1.xml delete mode 100644 raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-layer-shell-unstable-v1.xml delete mode 100644 raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-output-management-unstable-v1.xml delete mode 100644 raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-output-power-management-unstable-v1.xml delete mode 100644 raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-screencopy-unstable-v1.xml (limited to 'raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml') diff --git a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/dwl-ipc-unstable-v2.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/dwl-ipc-unstable-v2.xml deleted file mode 100644 index a4e0b49..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/dwl-ipc-unstable-v2.xml +++ /dev/null @@ -1,252 +0,0 @@ - - - - - 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. - - - - - 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. - - - - - Indicates that the client will not the dwl_ipc_manager object anymore. - Objects created through this instance are not affected. - - - - - - Get a dwl_ipc_outout for the specified wl_output. - - - - - - - - This event is sent after binding. - A roundtrip after binding guarantees the client recieved all tags. - - - - - - - This event is sent after binding. - A roundtrip after binding guarantees the client recieved all layouts. - - - - - - - - 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. - - - - - - - - - - - Indicates to that the client no longer needs this dwl_ipc_output. - - - - - - Indicates the client should hide or show themselves. - If the client is visible then hide, if hidden then show. - - - - - - Indicates if the output is active. Zero is invalid, nonzero is valid. - - - - - - - Indicates that a tag has been updated. - - - - - - - - - - Indicates a new layout is selected. - - - - - - - Indicates the title has changed. - - - - - - - Indicates the appid has changed. - - - - - - - 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. - - - - - - - Indicates that a sequence of status updates have finished and the client should redraw. - - - - - - - - - - - - The tags are updated as follows: - new_tags = (current_tags AND and_tags) XOR xor_tags - - - - - - - - - - - - This request allows clients to instruct the compositor to quit mango. - - - - - - - - - - - - - - - - Indicates if the selected client on this output is fullscreen. - - - - - - - Indicates if the selected client on this output is floating. - - - - - - - Indicates if x coordinates of the selected client. - - - - - - - Indicates if y coordinates of the selected client. - - - - - - - Indicates if width of the selected client. - - - - - - - Indicates if height of the selected client. - - - - - - - last map layer. - - - - - - - current keyboard layout. - - - - - - - current keybind mode. - - - - - - - scale factor of monitor. - - - - - - diff --git a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/ext-data-control-v1.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/ext-data-control-v1.xml deleted file mode 100644 index 37ee577..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/ext-data-control-v1.xml +++ /dev/null @@ -1,276 +0,0 @@ - - - - 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. - - - - 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. - - - - - This interface is a manager that allows creating per-seat data device - controls. - - - - - Create a new data source. - - - - - - - Create a data device that can be used to manage a seat's selection. - - - - - - - - All objects created by the manager will still remain valid, until their - appropriate destroy request has been called. - - - - - - - This interface allows a client to manage a seat's selection. - - When the seat is destroyed, this object becomes inert. - - - - - 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. - - - - - - - Destroys the data device object. - - - - - - 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. - - - - - - - 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. - - - - - - - This data control object is no longer valid and should be destroyed by - the client. - - - - - - 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. - - - - - - - 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. - - - - - - - - - - - - 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. - - - - - - - - - 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. - - - - - - - Destroys the data source object. - - - - - - Request for data from the client. Send the data as the specified MIME - type over the passed file descriptor, then close it. - - - - - - - - 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. - - - - - - - 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. - - - - - 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. - - - - - - - - Destroys the data offer object. - - - - - - Sent immediately after creating the ext_data_control_offer object. - One event per offered MIME type. - - - - - diff --git a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/ext-workspace-v1.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/ext-workspace-v1.xml deleted file mode 100644 index 134b729..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/ext-workspace-v1.xml +++ /dev/null @@ -1,422 +0,0 @@ - - - - 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. - - - - - 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. - - - - - 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. - - - - - - - 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. - - - - - - - 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. - - - - - - 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. - - - - - - 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. - - - - - - 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. - - - - - - - - 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. - - - - - - - - - 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. - - - - - - - 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. - - - - - - - This event is emitted whenever an output is removed from the 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. - - - - - - - This event is emitted whenever a workspace is removed from this group. - - - - - - - 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. - - - - - - 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. - - - - - - - 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. - - - - - - - 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). - - - - - 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. - - - - - - - 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. - - - - - - - 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. - - - - - - - The different states that a workspace can have. - - - - - - - The workspace is not visible in its workspace group, and clients - attempting to visualize the compositor workspace state should not - display such workspaces. - - - - - - - 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. - - - - - - - - - - - - - - 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. - - - - - - - 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. - - - - - - 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. - - - - - - Request that this workspace be activated. - - There is no guarantee the workspace will be actually activated, and - behaviour may be compositor-dependent. For example, activating a - workspace may or may not deactivate all other workspaces in the same - group. - - - - - - Request that this workspace be deactivated. - - There is no guarantee the workspace will be actually deactivated. - - - - - - Requests that this workspace is assigned to the given workspace group. - - There is no guarantee the workspace will be assigned. - - - - - - - Request that this workspace be removed. - - There is no guarantee the workspace will be actually removed. - - - - diff --git a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/keyboard-shortcuts-inhibit-unstable-v1.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/keyboard-shortcuts-inhibit-unstable-v1.xml deleted file mode 100644 index 2774876..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/keyboard-shortcuts-inhibit-unstable-v1.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - 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. - - - - 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. - - - - - A global interface used for inhibiting the compositor keyboard shortcuts. - - - - - Destroy the keyboard shortcuts inhibitor manager. - - - - - - 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. - - - - - - - - - - - - - - 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. - - - - - Remove the keyboard shortcuts inhibitor from the associated wl_surface. - - - - - - 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. - - - - - - This event indicates that the shortcuts inhibitor is inactive, - normal shortcuts processing is restored by the compositor. - - - - diff --git a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-gamma-control-unstable-v1.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-gamma-control-unstable-v1.xml deleted file mode 100644 index 16e0be8..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-gamma-control-unstable-v1.xml +++ /dev/null @@ -1,126 +0,0 @@ - - - - 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. - - - - 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. - - - - - This interface is a manager that allows creating per-output gamma - controls. - - - - - Create a gamma control that can be used to adjust gamma tables for the - provided output. - - - - - - - - All objects created by the manager will still remain valid, until their - appropriate destroy request has been called. - - - - - - - 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. - - - - - Advertise the size of each gamma ramp. - - This event is sent immediately when the gamma control object is created. - - - - - - - - - - - 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. - - - - - - - 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. - - - - - - Destroys the gamma control object. If the object is still valid, this - restores the original gamma tables. - - - - diff --git a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-layer-shell-unstable-v1.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-layer-shell-unstable-v1.xml deleted file mode 100644 index e9f27e4..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-layer-shell-unstable-v1.xml +++ /dev/null @@ -1,407 +0,0 @@ - - - - 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. - - - - - 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. - - - - - 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. - - - - - - - - - - - - - - - - - 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. - - - - - - - - - - - - - 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. - - - - - - - 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. - - - - - 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. - - - - - - - - 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. - - - - - - - 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. - - - - - - - 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. - - - - - - - - - - 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. - - - - - 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. - - - - - 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. - - - - - 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. - - - - - - - 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. - - - - - - - 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. - - - - - - - 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. - - - - - - - This request destroys the layer surface. - - - - - - 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. - - - - - - - - - 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. - - - - - - - - - - - - - - - - - - - - - - - Change the layer that the surface is rendered on. - - Layer is double-buffered, see wl_surface.commit. - - - - - - - - - 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. - - - - - diff --git a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-output-management-unstable-v1.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-output-management-unstable-v1.xml deleted file mode 100644 index 541284a..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-output-management-unstable-v1.xml +++ /dev/null @@ -1,611 +0,0 @@ - - - - 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. - - - - 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. - - - - - 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. - - - - - 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. - - - - - - - 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. - - - - - - - Create a new output configuration object. This allows to update head - properties. - - - - - - - - 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. - - - - - - 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. - - - - - - - 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. - - - - - 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. - - - - - - - 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. - - - - - - - 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. - - - - - - - - This event introduces a mode for this head. It is sent once per - supported mode. - - - - - - - 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. - - - - - - - This event describes the mode currently in use for this head. It is only - sent if the output is enabled. - - - - - - - This events describes the position of the head in the global compositor - space. It is only sent if the output is enabled. - - - - - - - - This event describes the transformation currently applied to the head. - It is only sent if the output is enabled. - - - - - - - This events describes the scale of the head in the global compositor - space. It is only sent if the output is enabled. - - - - - - - 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. - - - - - - - - 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. - - - - - - - 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. - - - - - - - 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. - - - - - - - - - This request indicates that the client will no longer use this head - object. - - - - - - - - - - - - - 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. - - - - - - - - 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. - - - - - 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. - - - - - - - - This event describes the mode's fixed vertical refresh rate. It is only - sent if the mode has a fixed refresh rate. - - - - - - - This event advertises this mode as preferred. - - - - - - 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. - - - - - - - - This request indicates that the client will no longer use this mode - object. - - - - - - - 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. - - - - - - - - - - - Enable a head. This request creates a head configuration object that can - be used to change the head's properties. - - - - - - - - Disable a head. - - - - - - - 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. - - - - - - 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. - - - - - - 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. - - - - - - 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. - - - - - - 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. - - - - - - 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. - - - - - - - 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. - - - - - - - - - - - - - - This request sets the head's 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. - - - - - - - - - This request sets the head's position in the global compositor space. - - - - - - - - This request sets the head's transform. - - - - - - - This request sets the head's scale. - - - - - - - - - This request enables/disables adaptive sync. Adaptive sync is also - known as Variable Refresh Rate or VRR. - - - - - diff --git a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-output-power-management-unstable-v1.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-output-power-management-unstable-v1.xml deleted file mode 100644 index 20dbb77..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-output-power-management-unstable-v1.xml +++ /dev/null @@ -1,128 +0,0 @@ - - - - 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. - - - - 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. - - - - - This interface is a manager that allows creating per-output power - management mode controls. - - - - - Create an output power management mode control that can be used to - adjust the power management mode for a given output. - - - - - - - - All objects created by the manager will still remain valid, until their - appropriate destroy request has been called. - - - - - - - This object offers requests to set the power management mode of - an output. - - - - - - - - - - - - - - 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. - - - - - - - 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. - - - - - - - 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. - - - - - - Destroys the output power management mode control object. - - - - diff --git a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-screencopy-unstable-v1.xml b/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-screencopy-unstable-v1.xml deleted file mode 100644 index 8b20661..0000000 --- a/raveos-hyprland-theme/theme-data/DankMaterialShell/core/internal/proto/xml/wlr-screencopy-unstable-v1.xml +++ /dev/null @@ -1,234 +0,0 @@ - - - - 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. - - - - 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. - - - - - This object is a manager which offers requests to start capturing from a - source. - - - - - Capture the next frame of an entire output. - - - - - - - - - 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. - - - - - - - - - - - - - All objects created by the manager will still remain valid, until their - appropriate destroy request has been called. - - - - - - - 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. - - - - - 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. - - - - - - - - - - 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. - - - - - - - - - - - - - - - - Provides flags about the frame. This event is sent once before the - "ready" event. - - - - - - - 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. - - - - - - - - - This event indicates that the attempted frame copy has failed. - - After receiving this event, the client should destroy the object. - - - - - - Destroys the frame. This request can be sent at any time by the client. - - - - - - - Same as copy, except it waits until there is damage to copy. - - - - - - - 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. - - - - - - - - - - - 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. - - - - - - - - - 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. - - - - -- cgit v1.3