GPU-accelerated UI toolkit (Vulkan)
git clone https://git.lucas.co/cce-ui.git
Implement standardized flex layouts (ColumnLayout, RowLayout) in cce-ui
protocol/cce-window-management-v1.xml | 1543 +++++++++++++++++++++++++++++++++
src/widget/layout_helper.rs | 63 ++
src/widget/mod.rs | 4 +-
3 files changed, 1609 insertions(+), 1 deletion(-)
diff --git a/protocol/cce-window-management-v1.xml b/protocol/cce-window-management-v1.xml
new file mode 100644
index 0000000..ad7d32d
--- /dev/null
+++ b/protocol/cce-window-management-v1.xml
@@ -0,0 +1,1543 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="cce_window_management_v1">
+ <copyright>
+ SPDX-FileCopyrightText: © 2024 Isaac Freund
+ SPDX-License-Identifier: MIT
+ 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 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="frame-perfect window management">
+ This protocol allows a single "window manager" client to determine the
+ window management policy of the compositor. State is globally
+ double-buffered allowing for frame perfect state changes involving multiple
+ windows.
+ The key words "must", "must not", "required", "shall", "shall not",
+ "should", "should not", "recommended", "may", and "optional" in this
+ document are to be interpreted as described in IETF RFC 2119.
+ </description>
+ <interface name="zcce_window_manager_v1" version="4">
+ <description summary="window manager global interface">
+ This global interface should only be advertised to the window manager
+ process. Only one window management client may be active at a time. The
+ compositor should use the unavailable event if necessary to enforce this.
+ There are two disjoint categories of state managed by this protocol:
+ Window management state influences the communication between the
+ compositor and individual windows (e.g. xdg_toplevels). Window management
+ state includes window dimensions, fullscreen state, keyboard focus,
+ keyboard bindings, and more.
+ Rendering state only affects the rendered output of the compositor and
+ does not influence communication between the compositor and individual
+ windows. Rendering state includes the position and rendering order of
+ windows, shell surfaces, decoration surfaces, borders, and more.
+ Window management state may only be modified by the window manager as part
+ of a manage sequence. A manage sequence is started with the manage_start
+ event and ended with the manage_finish request. It is a protocol error to
+ modify window management state outside of a manage sequence.
+ A manage sequence is always followed by at least one render sequence. A
+ render sequence is started with the render_start event and ended with the
+ render_finish request.
+ Rendering state may be modified by the window manager during a manage
+ sequence or a render sequence. Regardless of when the rendering state is
+ modified, it is applied with the next render_finish request. It is a
+ protocol error to modify rendering state outside of a manage or render
+ sequence.
+ The server will start a manage sequence by sending new state and the
+ manage_start event as soon as possible whenever there is a change in state
+ that must be communicated with the window manager.
+ If the window manager client needs to ensure a manage sequence is started
+ due to a state change the compositor is not aware of, it may send the
+ manage_dirty request.
+ The server will start a render sequence by sending new state and the
+ render_start event as soon as possible whenever there is a change in
+ window dimensions that must be communicated with the window manager.
+ Multiple render sequences may be made consecutively without a manage
+ sequence in between, for example if a window independently changes its own
+ dimensions.
+ To summarize, the main loop of this protocol is as follows:
+ 1. The server sends events indicating all changes since the last
+ manage sequence followed by the manage_start event.
+ 2. The client sends requests modifying window management state or
+ rendering state (as defined above) followed by the manage_finish
+ request.
+ 3. The server sends new state to windows and waits for responses.
+ 4. The server sends new window dimensions to the client followed by the
+ render_start event.
+ 5. The client sends requests modifying rendering state (as defined above)
+ followed by the render_finish request.
+ 6. If window dimensions change, loop back to step 4.
+ If state that requires a manage sequence changes or if the client makes
+ a manage_dirty request, loop back to step 1.
+ For the purposes of frame perfection, the server may delay rendering new
+ state committed by the windows in step 3 until after step 5 is finished.
+ It is a protocol error for the client to make a manage_finish or
+ render_finish request that violates this ordering.
+ </description>
+ <enum name="error">
+ <entry name="sequence_order" value="0" summary="request violates manage/render sequence ordering"/>
+ <entry name="role" value="1" summary="given wl_surface already has a role"/>
+ <entry name="unresponsive" value="2" summary="window manager unresponsive"/>
+ </enum>
+ <event name="unavailable">
+ <description summary="window management unavailable">
+ This event indicates that window management is not available to the
+ client, perhaps due to another window management client already running.
+ The circumstances causing this event to be sent are compositor policy.
+ If sent, this event is guaranteed to be the first and only event sent by
+ the server.
+ The server will send no further events on this object. The client should
+ destroy this object and all objects created through this interface.
+ </description>
+ </event>
+ <request name="stop">
+ <description summary="stop sending events">
+ This request indicates that the client no longer wishes to receive
+ events on this object.
+ The Wayland protocol is asynchronous, which means the server may send
+ further events until the stop request is processed. The client must wait
+ for a cce_window_manager_v1.finished event before destroying this
+ object.
+ </description>
+ </request>
+ <event name="finished">
+ <description summary="the server has finished with the window manager">
+ This event indicates that the server will send no further events on this
+ object. The client should destroy the object. See
+ cce_window_manager_v1.destroy for more information.
+ </description>
+ </event>
+ <request name="destroy" type="destructor">
+ <description summary="destroy the cce_window_manager_v1 object">
+ This request should be called after the finished event has been received
+ to complete destruction of the object.
+ If a client wishes to destroy this object it should send a
+ cce_window_manager_v1.stop request and wait for a
+ cce_window_manager_v1.finished event. Once the finished event is
+ received it is safe to destroy this object and any other objects created
+ through this interface.
+ </description>
+ </request>
+ <event name="manage_start">
+ <description summary="start a manage sequence">
+ This event indicates that the server has sent events indicating all
+ state changes since the last manage sequence.
+ In response to this event, the client should make requests modifying
+ window management state as it chooses. Then, the client must make the
+ manage_finish request.
+ See the description of the cce_window_manager_v1 interface for a
+ complete overview of the manage/render sequence loop.
+ </description>
+ </event>
+ <request name="manage_finish">
+ <description summary="finish a manage sequence">
+ This request indicates that the client has made all changes to window
+ management state it wishes to include in the current manage sequence and
+ that the server should atomically send these state changes to the
+ windows and continue with the manage sequence.
+ After sending this request, it is a protocol error for the client to
+ make further changes to window management state until the next
+ manage_start event is received.
+ See the description of the cce_window_manager_v1 interface for a
+ complete overview of the manage/render sequence loop.
+ </description>
+ </request>
+ <request name="manage_dirty">
+ <description summary="ensure a manage sequence is started">
+ This request ensures a manage sequence is started and that a
+ manage_start event is sent by the server. If this request is made during
+ an ongoing manage sequence, a new manage sequence will be started as
+ soon as the current one is completed.
+ The client may want to use this request due to an internal state change
+ that the compositor is not aware of (e.g. a dbus event) which should
+ affect window management or rendering state.
+ </description>
+ </request>
+ <event name="render_start">
+ <description summary="start a render sequence">
+ This event indicates that the server has sent all
+ cce_window_v1.dimensions events necessary.
+ In response to this event, the client should make requests modifying
+ rendering state as it chooses. Then, the client must make the
+ render_finish request.
+ See the description of the cce_window_manager_v1 interface for a
+ complete overview of the manage/render sequence loop.
+ </description>
+ </event>
+ <request name="render_finish">
+ <description summary="finish a render sequence">
+ This request indicates that the client has made all changes to rendering
+ state it wishes to include in the current manage sequence and that the
+ server should atomically apply and display these state changes to the
+ user.
+ After sending this request, it is a protocol error for the client to
+ make further changes to rendering state until the next manage_start or
+ render_start event is received, whichever comes first.
+ See the description of the cce_window_manager_v1 interface for a
+ complete overview of the manage/render sequence loop.
+ </description>
+ </request>
+ <event name="session_locked">
+ <description summary="the session has been locked">
+ This event indicates that the session has been locked.
+ The window manager may wish to restrict which key bindings are available
+ while locked or otherwise use this information.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ </event>
+ <event name="session_unlocked">
+ <description summary="the session has been unlocked">
+ This event indicates that the session has been unlocked.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ </event>
+ <event name="window">
+ <description summary="new window">
+ A new window has been created.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ <arg name="id" type="new_id" interface="zcce_window_v1" summary="new window"/>
+ </event>
+ <event name="output">
+ <description summary="new output">
+ A new logical output has been created, perhaps due to a new physical
+ monitor being plugged in or perhaps due to a change in configuration.
+ This event will be followed by cce_output_v1.position and dimensions
+ events as well as a manage_start event after all other new state has
+ been sent by the server.
+ </description>
+ <arg name="id" type="new_id" interface="zcce_output_v1" summary="new output"/>
+ </event>
+ <event name="seat">
+ <description summary="new seat">
+ A new seat has been created.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ <arg name="id" type="new_id" interface="zcce_seat_v1" summary="new seat"/>
+ </event>
+ <request name="get_shell_surface">
+ <description summary="assign the cce_shell_surface_v1 surface role">
+ Create a new shell surface for window manager UI and assign the
+ cce_shell_surface_v1 role to the surface.
+ Providing a wl_surface which already has a role or already has a buffer
+ attached or committed is a protocol error.
+ </description>
+ <arg name="id" type="new_id" interface="zcce_shell_surface_v1" summary="new river shell surface"/>
+ <arg name="surface" type="object" interface="wl_surface" summary="base surface"/>
+ </request>
+ <request name="exit_session" since="4">
+ <description summary="exit the Wayland session">
+ End the current Wayland session and exit the compositor.
+ All Wayland clients running in the current session, including
+ the window manager, will be disconnected.
+ Window managers should only make this request if the user explicitly
+ asks to exit the Wayland session, not for example on normal window
+ manager termination.
+ </description>
+ </request>
+ <request name="get_cce_toplevel">
+ <description summary="get a cce toplevel for a surface">
+ Create a zcce_toplevel_v1 object for a given wl_surface.
+ </description>
+ <arg name="id" type="new_id" interface="zcce_toplevel_v1"/>
+ <arg name="surface" type="object" interface="wl_surface"/>
+ </request>
+ </interface>
+ <interface name="zcce_window_v1" version="4">
+ <description summary="a logical window">
+ This represents a logical window. For example, a window may correspond to
+ an xdg_toplevel or Xwayland window.
+ A newly created window will not be displayed until the window manager
+ makes a propose_dimensions or fullscreen request as part of a manage
+ sequence, the server replies with a dimensions event as part of a render
+ sequence, and that render sequence is finished.
+ </description>
+ <enum name="error">
+ <entry name="node_exists" value="0" summary="window already has a node object"/>
+ <entry name="invalid_dimensions" value="1" summary="proposed dimensions out of bounds"/>
+ <entry name="invalid_border" value="2" summary="invalid arg to set_borders"/>
+ <entry name="invalid_clip_box" value="3" summary="invalid arg to set_clip_box"/>
+ </enum>
+ <request name="destroy" type="destructor">
+ <description summary="destroy the window object">
+ This request indicates that the client will no longer use the window
+ object and that it may be safely destroyed.
+ This request should be made after the cce_window_v1.closed event or
+ cce_window_manager_v1.finished is received to complete destruction of
+ the window.
+ </description>
+ </request>
+ <event name="closed">
+ <description summary="the window has been closed">
+ The window has been closed by the server, perhaps due to an
+ xdg_toplevel.close request or similar.
+ The server will send no further events on this object and ignore any
+ request other than cce_window_v1.destroy made after this event is
+ sent. The client should destroy this object with the
+ cce_window_v1.destroy request to free up resources.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ </event>
+ <request name="close">
+ <description summary="request that the window be closed">
+ Request that the window be closed. The window may ignore this request or
+ only close after some delay, perhaps opening a dialog asking the user to
+ save their work or similar.
+ The server will send a cce_window_v1.closed event if/when the window
+ has been closed.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <request name="get_node">
+ <description summary="get the window's render list node">
+ Get the node in the render list corresponding to the window.
+ It is a protocol error to make this request more than once for a single
+ window.
+ </description>
+ <arg name="id" type="new_id" interface="zcce_node_v1" summary="new node"/>
+ </request>
+ <event name="dimensions_hint">
+ <description summary="the window's preferred min/max dimensions">
+ This event informs the window manager of the window's preferred min/max
+ dimensions. These preferences are a hint, and the window manager is free
+ to propose dimensions outside of these bounds.
+ All min/max width/height values must be strictly greater than or equal
+ to 0. A value of 0 indicates that the window has no preference for that
+ value.
+ The min_width/min_height must be strictly less than or equal to the
+ max_width/max_height.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ <arg name="min_width" type="int" summary="minimum width"/>
+ <arg name="min_height" type="int" summary="minimum height"/>
+ <arg name="max_width" type="int" summary="maximum width"/>
+ <arg name="max_height" type="int" summary="maximum height"/>
+ </event>
+ <event name="dimensions">
+ <description summary="window dimensions">
+ This event indicates the dimensions of the window in the compositor's
+ logical coordinate space. The width and height must be strictly greater
+ than zero.
+ Note that the dimensions of a cce_window_v1 refer to the dimensions of
+ the window content and are unaffected by the presence of borders or
+ decoration surfaces.
+ This event is sent as part of a render sequence before the render_start
+ event.
+ It may be sent due to a propose_dimensions or fullscreen request in a
+ previous manage sequence or because a window independently decides to
+ change its dimensions.
+ The window will not be displayed until the first dimensions event is
+ received and the render sequence is finished.
+ </description>
+ <arg name="width" type="int" summary="window content width"/>
+ <arg name="height" type="int" summary="window content height"/>
+ </event>
+ <request name="propose_dimensions">
+ <description summary="propose window dimensions">
+ This request proposes dimensions for the window in the compositor's
+ logical coordinate space.
+ The width and height must be greater than or equal to zero. If the width
+ or height is zero the window will be allowed to decide its own
+ dimensions.
+ The window may not take the exact dimensions proposed. The actual
+ dimensions taken by the window will be sent in a subsequent
+ cce_window_v1.dimensions event. For example, a terminal emulator may
+ only allow dimensions that are multiple of the cell size.
+ When a propose_dimensions request is made, the server must send a
+ dimensions event in response as soon as possible. It may not be possible
+ to send a dimensions event in the very next render sequence if, for
+ example, the window takes too long to respond to the proposed
+ dimensions. In this case, the server will send the dimensions event in a
+ future render sequence.
+ Note that the dimensions of a cce_window_v1 refer to the dimensions of
+ the window content and are unaffected by the presence of borders or
+ decoration surfaces.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="width" type="int" summary="proposed content width"/>
+ <arg name="height" type="int" summary="proposed content height"/>
+ </request>
+ <request name="hide">
+ <description summary="request that the window be hidden">
+ Request that the window be hidden. Has no effect if the window is
+ already hidden. Hides any window borders and decorations as well.
+ Newly created windows are considered shown unless explicitly hidden with
+ the hide request.
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <request name="show">
+ <description summary="request that the window be shown">
+ Request that the window be shown. Has no effect if the window is not
+ hidden. Does not guarantee that the window is visible as it may be
+ completely obscured by other windows placed above it for example.
+ Newly created windows are considered shown unless explicitly hidden with
+ the hide request.
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <event name="app_id">
+ <description summary="the window set an application ID">
+ The window set an application ID.
+ The app_id argument will be null if the window has never set an
+ application ID or if the window cleared its application ID. (Xwayland
+ windows may do this for example, though xdg-toplevels may not.)
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ <arg name="app_id" type="string" allow-null="true" summary="window application ID"/>
+ </event>
+ <event name="title">
+ <description summary="the window set a title">
+ The window set a title.
+ The title argument will be null if the window has never set a title or
+ if the window cleared its title. (Xwayland windows may do this for
+ example, though xdg-toplevels may not.)
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ <arg name="title" type="string" allow-null="true" summary="window title"/>
+ </event>
+ <event name="parent">
+ <description summary="the window set a parent">
+ The window set a parent window. If this event is never received or if
+ the parent argument is null then the window has no parent.
+ A surface with a parent set might be a dialog, file picker, or similar
+ for the parent window.
+ Child windows should generally be rendered directly above their parent.
+ The compositor must guarantee that there are no loops in the window
+ tree: a parent must not be the descendant of one of its children.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ <arg name="parent" type="object" allow-null="true" interface="zcce_window_v1" summary="parent window, if any"/>
+ </event>
+ <enum name="decoration_hint">
+ <entry name="only_supports_csd" value="0" summary="only supports client side decoration"/>
+ <entry name="prefers_csd" value="1" summary="client side decoration preferred, both CSD and SSD supported"/>
+ <entry name="prefers_ssd" value="2" summary="server side decoration preferred, both CSD and SSD supported"/>
+ <entry name="no_preference" value="3" summary="no preference, both CSD and SSD supported"/>
+ </enum>
+ <event name="decoration_hint">
+ <description summary="supported/preferred decoration style">
+ Information from the window about the supported and preferred client
+ side/server side decoration options.
+ This event may be sent multiple times over the lifetime of the window if
+ the window changes its preferences.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ <arg name="hint" type="uint" enum="decoration_hint" summary="decoration hint"/>
+ </event>
+ <request name="use_csd">
+ <description summary="tell the client to use CSD">
+ Tell the client to use client side decoration and draw its own title
+ bar, borders, etc.
+ This is the default if neither this request nor the use_ssd request is
+ ever made.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <request name="use_ssd">
+ <description summary="tell the client to use SSD">
+ Tell the client to use server side decoration and not draw any client
+ side decorations.
+ This request will have no effect if the client only supports client side
+ decoration, see the decoration_hint event.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <enum name="edges" bitfield="true">
+ <entry name="none" value="0"/>
+ <entry name="top" value="1"/>
+ <entry name="bottom" value="2"/>
+ <entry name="left" value="4"/>
+ <entry name="right" value="8"/>
+ </enum>
+ <request name="set_borders">
+ <description summary="set window borders">
+ This request decorates the window with borders drawn by the compositor
+ on the specified edges of the window. Borders are drawn above the window
+ content.
+ Corners are drawn only between borders on adjacent edges. If e.g. the
+ left edge has a border and the top edge does not, the border drawn on
+ the left edge will not extend vertically beyond the top edge of the
+ window.
+ Borders are not drawn while the window is fullscreen.
+ The color is defined by four 32-bit RGBA values. Unless specified in
+ another protocol extension, the RGBA values use pre-multiplied alpha.
+ The valid range for the RGBA values is from 0x00000000 to 0xffffffff.
+ These values are interpreted as a percentage:
+ - 0x00000000 means 0% of the given color component
+ - 0xffffffff means 100% of the given color component
+ Setting the edges to none or the width to 0 disables the borders.
+ Setting a negative width is a protocol error.
+ This request completely overrides all previous set_borders requests.
+ Only the most recent set_borders request has an effect.
+ Note that the position/dimensions of a cce_window_v1 refer to the
+ position/dimensions of the window content and are unaffected by the
+ presence of borders or decoration surfaces.
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="edges" type="uint" enum="edges" summary="border edges"/>
+ <arg name="width" type="int" summary="border width"/>
+ <arg name="r" type="uint" summary="32-bit red value"/>
+ <arg name="g" type="uint" summary="32-bit green value"/>
+ <arg name="b" type="uint" summary="32-bit blue value"/>
+ <arg name="a" type="uint" summary="32-bit alpha value"/>
+ </request>
+ <request name="set_tiled">
+ <description summary="set window tiled state">
+ Inform the window that it is part of a tiled layout and adjacent to
+ other elements in the tiled layout on the given edges.
+ The window should use this information to change the style of its client
+ side decorations and avoid drawing e.g. drop shadows outside of the
+ window dimensions on the tiled edges.
+ Setting the edges argument to none informs the window that it is not
+ part of a tiled layout. If this request is never made, the window is
+ informed that it is not part of a tiled layout.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="edges" type="uint" enum="edges" summary="tiled edges"/>
+ </request>
+ <request name="get_decoration_above">
+ <description summary="create a decoration above the window in z-order">
+ Create a decoration surface and assign the cce_decoration_v1 role to
+ the surface. The created decoration is placed above the window in
+ rendering order, see the description of cce_decoration_v1.
+ Providing a wl_surface which already has a role or already has a buffer
+ attached or committed is a protocol error.
+ </description>
+ <arg name="id" type="new_id" interface="zcce_decoration_v1" summary="new decoration surface"/>
+ <arg name="surface" type="object" interface="wl_surface" summary="base surface"/>
+ </request>
+ <request name="get_decoration_below">
+ <description summary="create a decoration below the window in z-order">
+ Create a decoration surface and assign the cce_decoration_v1 role to
+ the surface. The created decoration is placed below the window in
+ rendering order, see the description of cce_decoration_v1.
+ Providing a wl_surface which already has a role or already has a buffer
+ attached or committed is a protocol error.
+ </description>
+ <arg name="id" type="new_id" interface="zcce_decoration_v1" summary="new decoration surface"/>
+ <arg name="surface" type="object" interface="wl_surface" summary="base surface"/>
+ </request>
+ <event name="pointer_move_requested">
+ <description summary="window requested interactive pointer move">
+ This event informs the window manager that the window has requested to
+ be interactively moved using the pointer. The seat argument indicates the
+ seat for the move.
+ The xdg-shell protocol for example allows windows to request that an
+ interactive move be started, perhaps when a client-side rendered
+ titlebar is dragged.
+ The window manager may use the cce_seat_v1.op_start_pointer request to
+ interactively move the window or ignore this event entirely.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ <arg name="seat" type="object" interface="zcce_seat_v1" summary="requested seat"/>
+ </event>
+ <event name="pointer_resize_requested">
+ <description summary="window requested interactive pointer resize">
+ This event informs the window manager that the window has requested to
+ be interactively resized using the pointer. The seat argument indicates
+ the seat for the resize.
+ The edges argument indicates which edges the window has requested to be
+ resized from. The edges argument will never be none and will never have
+ both top and bottom or both left and right edges set.
+ The xdg-shell protocol for example allows windows to request that an
+ interactive resize be started, perhaps when the corner of client-side
+ rendered decorations is dragged.
+ The window manager may use the cce_seat_v1.op_start_pointer request to
+ interactively resize the window or ignore this event entirely.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ <arg name="seat" type="object" interface="zcce_seat_v1" summary="requested seat"/>
+ <arg name="edges" type="uint" enum="edges" summary="requested edges"/>
+ </event>
+ <request name="inform_resize_start">
+ <description summary="inform the window it is being resized">
+ Inform the window that it is being resized. The window manager should
+ use this request to inform windows that are the target of an interactive
+ resize for example.
+ The window manager remains responsible for handling the position and
+ dimensions of the window while it is resizing.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <request name="inform_resize_end">
+ <description summary="inform the window it no longer being resized">
+ Inform the window that it is no longer being resized. The window manager
+ should use this request to inform windows that are the target of an
+ interactive resize that the interactive resize has ended for example.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <enum name="capabilities" bitfield="true">
+ <entry name="window_menu" value="1"/>
+ <entry name="maximize" value="2"/>
+ <entry name="fullscreen" value="4"/>
+ <entry name="minimize" value="8"/>
+ </enum>
+ <request name="set_capabilities">
+ <description summary="inform window of supported capabilities">
+ This request informs the window of the capabilities supported by the
+ window manager. If the window manager, for example, ignores requests to
+ be maximized from the window it should not tell the window that it
+ supports the maximize capability.
+ The window might use this information to, for example, only show a
+ maximize button if the window manager supports the maximize capability.
+ The window manager client should use this request to set capabilities
+ for all new windows. If this request is never made, the compositor will
+ inform windows that all capabilities are supported.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="caps" type="uint" enum="capabilities" summary="supported capabilities"/>
+ </request>
+ <event name="show_window_menu_requested">
+ <description summary="window requested that the window menu be shown">
+ The xdg-shell protocol for example allows windows to request that a
+ window menu be shown, for example when the user right clicks on client
+ side window decorations.
+ A window menu might include options to maximize or minimize the window.
+ The window manager is free to ignore this request and decide what the
+ window menu contains if it does choose to show one.
+ The x and y arguments indicate where the window requested that the
+ window menu be shown.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ <arg name="x" type="int" summary="x offset from top left corner"/>
+ <arg name="y" type="int" summary="y offset from top left corner"/>
+ </event>
+ <event name="maximize_requested">
+ <description summary="the window requested to be maximized">
+ The xdg-shell protocol for example allows windows to request to be
+ maximized.
+ The window manager is free to honor this request using
+ cce_window_v1.inform_maximized or ignore it.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ </event>
+ <event name="unmaximize_requested">
+ <description summary="the window requested to be unmaximized">
+ The xdg-shell protocol for example allows windows to request to be
+ unmaximized.
+ The window manager is free to honor this request using
+ cce_window_v1.inform_unmaximized or ignore it.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ </event>
+ <request name="inform_maximized">
+ <description summary="inform the window that it is maximized">
+ Inform the window that it is maximized. The window might use this
+ information to adapt the style of its client-side window decorations for
+ example.
+ The window manager remains responsible for handling the position and
+ dimensions of the window while it is maximized.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <request name="inform_unmaximized">
+ <description summary="inform the window that it is unmaximized">
+ Inform the window that it is unmaximized. The window might use this
+ information to adapt the style of its client-side window decorations for
+ example.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <event name="fullscreen_requested">
+ <description summary="the window requested to be fullscreen">
+ The xdg-shell protocol for example allows windows to request that they
+ be made fullscreen and allows them to provide an optional output hint.
+ If the output argument is null, the window has no preference and the
+ window manager should choose an output.
+ The window manager is free to honor this request using
+ cce_window_v1.fullscreen or ignore it.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ <arg name="output" type="object" allow-null="true" interface="zcce_output_v1" summary="fullscreen output requested"/>
+ </event>
+ <event name="exit_fullscreen_requested">
+ <description summary="the window requested to exit fullscreen">
+ The xdg-shell protocol for example allows windows to request to exit
+ fullscreen.
+ The window manager is free to honor this request using
+ cce_window_v1.exit_fullscreen or ignore it.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ </event>
+ <request name="inform_fullscreen">
+ <description summary="inform the window that it is fullscreen">
+ Inform the window that it is fullscreen. The window might use this
+ information to adapt the style of its client-side window decorations for
+ example.
+ This request does not affect the size/position of the window or cause it
+ to become the only window rendered, see the cce_window_v1.fullscreen
+ and exit_fullscreen requests for that.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <request name="inform_not_fullscreen">
+ <description summary="inform the window that it is not fullscreen">
+ Inform the window that it is not fullscreen. The window might use this
+ information to adapt the style of its client-side window decorations for
+ example.
+ This request does not affect the size/position of the window or cause it
+ to become the only window rendered, see the cce_window_v1.fullscreen
+ and exit_fullscreen requests for that.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <request name="fullscreen">
+ <description summary="make the window fullscreen">
+ Make the window fullscreen on the given output. If multiple windows are
+ fullscreen on the same output at the same time only the "top" window in
+ rendering order shall be displayed.
+ All cce_shell_surface_v1 objects above the top fullscreen window in
+ the rendering order will continue to be rendered.
+ The compositor will handle the position and dimensions of the window
+ while it is fullscreen. The set_position and propose_dimensions requests
+ shall not affect the current position and dimensions of a fullscreen
+ window.
+ When a fullscreen request is made, the server must send a dimensions
+ event in response as soon as possible. It may not be possible to send a
+ dimensions event in the very next render sequence if, for example, the
+ window takes too long to respond. In this case, the server will send the
+ dimensions event in a future render sequence.
+ The compositor will clip window content, decoration surfaces, and
+ borders to the given output's dimensions while the window is fullscreen.
+ The effects of set_clip_box and set_content_clip_box are ignored while
+ the window is fullscreen.
+ If the output on which a window is currently fullscreen is removed, the
+ windowing state is modified as if there were an exit_fullscreen request
+ made in the same manage sequence as the cce_output_v1.removed event.
+ This request does not inform the window that it is fullscreen, see the
+ cce_window_v1.inform_fullscreen and inform_not_fullscreen requests.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="output" type="object" interface="zcce_output_v1" summary="fullscreen output"/>
+ </request>
+ <request name="exit_fullscreen">
+ <description summary="make the window not fullscreen">
+ Make the window not fullscreen.
+ The position and dimensions are undefined after this request is made
+ until a manage sequence in which the window manager makes the
+ propose_dimensions and set_position requests is completed.
+ The window manager should make propose_dimensions and set_position
+ requests in the same manage sequence as the exit_fullscreen request for
+ frame perfection.
+ This request does not inform the window that it is fullscreen, see the
+ cce_window_v1.inform_fullscreen and inform_not_fullscreen requests.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <event name="minimize_requested">
+ <description summary="the window requested to be minimized">
+ The xdg-shell protocol for example allows windows to request to be
+ minimized.
+ The window manager is free to ignore this request, hide the window, or
+ do whatever else it chooses.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ </event>
+ <request name="set_clip_box" since="2">
+ <description summary="clip the window to a given box">
+ Clip the window, including borders and decoration surfaces, to the box
+ specified by the x, y, width, and height arguments. The x/y position of
+ the box is relative to the top left corner of the window.
+ The width and height arguments must be greater than or equal to 0.
+ Setting a clip box with 0 width or height disables clipping.
+ The clip box is ignored while the window is fullscreen.
+ Both set_clip_box and set_content_clip_box may be enabled simultaneously.
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="x" type="int" summary="x relative to top left window corner"/>
+ <arg name="y" type="int" summary="y relative to top left window corner"/>
+ <arg name="width" type="int" summary="clip box width"/>
+ <arg name="height" type="int" summary="clip box height"/>
+ </request>
+ <event name="unreliable_pid" since="2">
+ <description summary="unreliable PID of the window's creator">
+ This event gives an unreliable PID of the process that created the
+ window. Obtaining this information is inherently racy due to PID reuse.
+ Therefore, this PID must not be used for anything security sensitive.
+ Note also that a single process may create multiple windows, so there is
+ not necessarily a 1-to-1 mapping from PID to window. Multiple windows
+ may have the same PID.
+ This event is sent once when the cce_window_v1 is created and never
+ sent again.
+ </description>
+ <arg name="unreliable_pid" type="int" summary="unreliable PID"/>
+ </event>
+ <request name="set_content_clip_box" since="3">
+ <description summary="clip the window content to a given box">
+ Clip the content of the window, excluding borders and decoration
+ surfaces, to the box specified by the x, y, width, and height arguments.
+ The x/y position of the box is relative to the top left corner of the
+ window.
+ Borders drawn by the compositor (see set_borders) are placed around the
+ intersection of the window content (as defined by the dimensions event)
+ and the content clip box when content clipping is enabled.
+ The width and height arguments must be greater than or equal to 0.
+ Setting a box with 0 width or height disables content clipping.
+ The content clip box is ignored while the window is fullscreen.
+ Both set_clip_box and set_content_clip_box may be enabled simultaneously.
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="x" type="int" summary="x relative to top left window corner"/>
+ <arg name="y" type="int" summary="y relative to top left window corner"/>
+ <arg name="width" type="int" summary="clip box width"/>
+ <arg name="height" type="int" summary="clip box height"/>
+ </request>
+ <event name="presentation_hint" since="4">
+ <description summary="presentation hint set by the window">
+ This event communicates the window's preferred presentation mode.
+ This event will be followed by a render_start event after all other new
+ state has been sent by the server.
+ </description>
+ <arg name="hint" type="uint" enum="zcce_output_v1.presentation_mode" summary="presentation hint"/>
+ </event>
+ <event name="identifier" since="4">
+ <description summary="unique window identifier">
+ The identifier is a string that contains up to 32 printable ASCII bytes.
+ The identifier must not be an empty string.
+ It is compositor policy how the identifier is generated, but the following
+ properties must be upheld:
+ 1. The identifier must uniquely identify the window. Two windows must not
+ share the same identifier.
+ 2. The identifier must not be reused. This avoids races around window
+ creation/destruction when identifiers are used in out-of-band IPC.
+ If the compositor implements the ext-foreign-toplevel-list-v1 protocol,
+ the cce_window_v1.identifier event must match the corresponding
+ ext_foreign_toplevel_handle_v1.identifier event.
+ This event is sent once when the cce_window_v1 is created and never
+ sent again.
+ </description>
+ <arg name="identifier" type="string" summary="unique identifier"/>
+ </event>
+ <request name="set_dimension_bounds" since="4">
+ <description summary="recommend maximum dimensions to the window">
+ Recommend that the window keep its dimensions within a given
+ maximum width/height. This recommendation is only a hint and the window
+ may ignore it.
+ Setting the width and height to 0 indicates that there are no bounds
+ and is equivalent to having never made this request.
+ Setting width or height to a negative value is a protocol error.
+ The server should communicate this hint to an xdg_toplevel window with
+ the xdg_toplevel.configure_bounds event for example.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="max_width" type="int" summary="maximum width"/>
+ <arg name="max_height" type="int" summary="maximum height"/>
+ </request>
+ <request name="set_opacity" since="4">
+ <description summary="set the window opacity">
+ Set the window opacity, from 0 (fully transparent) to 0xffffffff (fully opaque).
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="opacity" type="uint" summary="opacity value from 0 to 0xffffffff"/>
+ </request>
+ <request name="set_circular" since="4">
+ <description summary="set whether the window is circular">
+ Set whether the window is circular (1 for circular, 0 for rectangular).
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="circular" type="uint" summary="1 if circular, 0 otherwise"/>
+ </request>
+ <request name="set_blur" since="4">
+ <description summary="set whether backdrop blur is enabled">
+ Set whether backdrop blur should be enabled for this window.
+ 1 to enable, 0 to disable.
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="blur" type="uint" summary="1 to enable, 0 to disable"/>
+ </request>
+ </interface>
+ <interface name="zcce_decoration_v1" version="4">
+ <description summary="a window decoration">
+ The rendering order of windows with decorations is follows:
+ 1. Decorations created with get_decoration_below at the bottom
+ 2. Window content
+ 3. Borders configured with cce_window_v1.set_borders
+ 4. Decorations created with get_decoration_above at the top
+ The relative ordering of decoration surfaces above/below a window is
+ undefined by this protocol and left up to the compositor.
+ </description>
+ <enum name="error">
+ <entry name="no_commit" value="0" summary="failed to commit the surface before the window manager commit"/>
+ </enum>
+ <request name="destroy" type="destructor">
+ <description summary="destroy the decoration object">
+ This request indicates that the client will no longer use the decoration
+ object and that it may be safely destroyed.
+ </description>
+ </request>
+ <request name="set_offset">
+ <description summary="set offset from the window's top left corner">
+ This request sets the offset of the decoration surface from the top left
+ corner of the window.
+ If this request is never sent, the x and y offsets are undefined by this
+ protocol and left up to the compositor.
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="x" type="int" summary="x relative to top left window corner"/>
+ <arg name="y" type="int" summary="y relative to top left window corner"/>
+ </request>
+ <request name="sync_next_commit">
+ <description summary="sync next commit with other rendering state">
+ Synchronize application of the next wl_surface.commit request on the
+ decoration surface with rest of the state atomically applied with the
+ next cce_window_manager_v1.render_finish request.
+ The client must make a wl_surface.commit request on the decoration
+ surface after this request and before the render_finish request, failure
+ to do so is a protocol error.
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <request name="set_blur" since="4">
+ <description summary="set whether backdrop blur is enabled">
+ Set whether backdrop blur should be enabled for this decoration.
+ 1 to enable, 0 to disable.
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="blur" type="uint" summary="1 to enable, 0 to disable"/>
+ </request>
+ </interface>
+ <interface name="zcce_shell_surface_v1" version="4">
+ <description summary="a surface for window manager UI">
+ The window manager might use a shell surface to display a status bar,
+ background image, desktop notifications, launcher, desktop menu, or
+ whatever else it wants.
+ </description>
+ <enum name="error">
+ <entry name="node_exists" value="0" summary="shell surface already has a node object"/>
+ <entry name="no_commit" value="1" summary="failed to commit the surface before the window manager commit"/>
+ </enum>
+ <request name="destroy" type="destructor">
+ <description summary="destroy the shell surface object">
+ This request indicates that the client will no longer use the shell
+ surface object and that it may be safely destroyed.
+ </description>
+ </request>
+ <request name="get_node">
+ <description summary="get the shell surface's render list node">
+ Get the node in the render list corresponding to the shell surface.
+ It is a protocol error to make this request more than once for a single
+ shell surface.
+ </description>
+ <arg name="id" type="new_id" interface="zcce_node_v1" summary="new node"/>
+ </request>
+ <request name="sync_next_commit">
+ <description summary="sync next surface commit to window manager commit">
+ Synchronize application of the next wl_surface.commit request on the
+ shell surface with rest of the rendering state atomically applied with
+ the next cce_window_manager_v1.render_finish request.
+ The client must make a wl_surface.commit request on the shell surface
+ after this request and before the render_finish request, failure to do
+ so is a protocol error.
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ </interface>
+ <interface name="zcce_node_v1" version="4">
+ <description summary="a node in the render list">
+ The render list is a list of nodes that determines the rendering order of
+ the compositor. Nodes may correspond to windows or shell surfaces. The
+ relative ordering of nodes may be changed with the place_above and
+ place_below requests, changing the rendering order.
+ The initial position of a node in the render list is undefined, the window
+ manager client must use the place_above or place_below request to
+ guarantee a specific rendering order.
+ </description>
+ <request name="destroy" type="destructor">
+ <description summary="destroy the decoration object">
+ This request indicates that the client will no longer use the node
+ object and that it may be safely destroyed.
+ </description>
+ </request>
+ <request name="set_position">
+ <description summary="set absolute position of the node">
+ Set the absolute position of the node in the compositor's logical
+ coordinate space. The x and y coordinates may be positive or negative.
+ Note that the position of a cce_window_v1 refers to the position of
+ the window content and is unaffected by the presence of borders or
+ decoration surfaces.
+ If this request is never sent, the position of the node is undefined by
+ this protocol and left up to the compositor.
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="x" type="int" summary="global x coordinate"/>
+ <arg name="y" type="int" summary="global y coordinate"/>
+ </request>
+ <request name="place_top">
+ <description summary="place node above all other nodes">
+ This request places the node above all other nodes in the compositor's
+ render list.
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <request name="place_bottom">
+ <description summary="place node below all other nodes">
+ This request places the node below all other nodes in the compositor's
+ render list.
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <request name="place_above">
+ <description summary="place node above another node">
+ This request places the node directly above another node in the
+ compositor's render list.
+ Attempting to place a node above itself has no effect.
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="other" type="object" interface="zcce_node_v1" summary="other node"/>
+ </request>
+ <request name="place_below">
+ <description summary="place node below another node">
+ This request places the node directly below another node in the
+ compositor's render list.
+ Attempting to place a node below itself has no effect.
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="other" type="object" interface="zcce_node_v1" summary="other node"/>
+ </request>
+ </interface>
+ <interface name="zcce_output_v1" version="4">
+ <description summary="a logical output">
+ An area in the compositor's logical coordinate space that should be
+ treated as a single output for window management purposes. This area may
+ correspond to a single physical output or multiple physical outputs in the
+ case of mirroring or tiled monitors depending on the hardware and
+ compositor configuration.
+ </description>
+ <request name="destroy" type="destructor">
+ <description summary="destroy the output object">
+ This request indicates that the client will no longer use the output
+ object and that it may be safely destroyed.
+ This request should be made after the cce_output_v1.removed event is
+ received to complete destruction of the output.
+ </description>
+ </request>
+ <event name="removed">
+ <description summary="the output is removed">
+ This event indicates that the logical output is no longer conceptually
+ part of window management space.
+ The server will send no further events on this object and ignore any
+ request (other than cce_output_v1.destroy) made after this event is
+ sent. The client should destroy this object with the
+ cce_output_v1.destroy request to free up resources.
+ This event may be sent because a corresponding physical output has been
+ physically unplugged or because some output configuration has changed.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ </event>
+ <event name="wl_output">
+ <description summary="corresponding wl_output">
+ The wl_output object corresponding to the cce_output_v1. The argument
+ is the global name of the wl_output advertised with wl_registry.global.
+ It is guaranteed that the corresponding wl_output is advertised before
+ this event is sent.
+ This event is sent exactly once. The wl_output associated with a
+ cce_output_v1 cannot change. It is guaranteed that there is a 1-to-1
+ mapping between wl_output and cce_output_v1 objects.
+ The global_remove event for the corresponding wl_output may be sent
+ before the cce_output_v1.removed event. This is due to the fact that
+ cce_output_v1 state changes are synced to the cce window management
+ manage sequence while changes to globals are not.
+ Rationale: The window manager may need information provided by the
+ wl_output interface such as the name/description. It also may need the
+ wl_output object to start screencopy for example.
+ </description>
+ <arg name="name" type="uint" summary="name of the wl_output global"/>
+ </event>
+ <event name="position">
+ <description summary="output position">
+ This event indicates the position of the output in the compositor's
+ logical coordinate space. The x and y coordinates may be positive or
+ negative.
+ This event is sent once when the cce_output_v1 is created and again
+ whenever the position changes.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ The server must guarantee that the position and dimensions events do not
+ cause the areas of multiple logical outputs to overlap when the
+ corresponding manage_start event is received.
+ </description>
+ <arg name="x" type="int" summary="global x coordinate"/>
+ <arg name="y" type="int" summary="global y coordinate"/>
+ </event>
+ <event name="dimensions">
+ <description summary="output dimensions">
+ This event indicates the dimensions of the output in the compositor's
+ logical coordinate space. The width and height will always be strictly
+ greater than zero.
+ This event is sent once when the cce_output_v1 is created and again
+ whenever the dimensions change.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ The server must guarantee that the position and dimensions events do not
+ cause the areas of multiple logical outputs to overlap when the
+ corresponding manage_start event is received.
+ </description>
+ <arg name="width" type="int" summary="output width"/>
+ <arg name="height" type="int" summary="output height"/>
+ </event>
+ <enum name="error" since="4">
+ <entry name="invalid_presentation_mode" value="0" since="4" summary="invalid presentation mode enum value"/>
+ </enum>
+ <enum name="presentation_mode" since="4">
+ <entry name="vsync" value="0">
+ <description summary="tearing-free presentation">
+ Output page-flips should be synchronized to the vertical blanking
+ period, eliminating tearing. This is the default presentation mode.
+ </description>
+ </entry>
+ <entry name="async" value="1">
+ <description summary="asynchronous presentation">
+ Output page-flips should not be synchronized to the vertical blanking
+ period, visual screen tearing may occur.
+ </description>
+ </entry>
+ </enum>
+ <request name="set_presentation_mode" since="4">
+ <description summary="set the preferred presentation mode">
+ Set the preferred presentation mode of the output. The compositor should
+ always respect the preference of the window manager if possible. If this
+ request is never made, the preferred presentation mode is vsync.
+ This request modifies rendering state and may only be made as part of a
+ render sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="mode" type="uint" enum="presentation_mode" summary="preferred presentation mode"/>
+ </request>
+ </interface>
+ <interface name="zcce_seat_v1" version="4">
+ <description summary="a window management seat">
+ This object represents a single user's collection of input devices. It
+ allows the window manager to route keyboard input to windows, get
+ high-level information about pointer input, define pointer bindings, etc.
+ For keyboard bindings, see the cce-xkb-bindings-v1 protocol.
+ Since version 4: The cursor surface/shape set by the window manager on the
+ wl_pointer of this seat is used when no client has pointer focus, for
+ example during a pointer operation. Since the window manager is allowed to
+ set cursor surface/shape even when it does not have pointer focus, the
+ compositor must ignore the serial argument of wl_pointer.set_cursor and
+ wp_cursor_shape_device_v1.set_shape requests made by the window manager.
+ The most recent cursor surface/shape set by the window manager is
+ remembered by the compositor and restored whenever no client has pointer
+ focus. If the window manager never sets a cursor surface/shape, the
+ "default" shape is used.
+ </description>
+ <request name="destroy" type="destructor">
+ <description summary="destroy the seat object">
+ This request indicates that the client will no longer use the seat
+ object and that it may be safely destroyed.
+ This request should be made after the cce_seat_v1.removed event is
+ received to complete destruction of the seat.
+ </description>
+ </request>
+ <event name="removed">
+ <description summary="the seat is removed">
+ This event indicates that seat is no longer in use and should be
+ destroyed.
+ The server will send no further events on this object and ignore any
+ request (other than cce_seat_v1.destroy) made after this event is
+ sent. The client should destroy this object with the
+ cce_seat_v1.destroy request to free up resources.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ </event>
+ <event name="wl_seat">
+ <description summary="corresponding wl_seat">
+ The wl_seat object corresponding to the cce_seat_v1. The argument is
+ the global name of the wl_seat advertised with wl_registry.global.
+ It is guaranteed that the corresponding wl_seat is advertised before
+ this event is sent.
+ This event is sent exactly once. The wl_seat associated with a
+ cce_seat_v1 cannot change. It is guaranteed that there is a 1-to-1
+ mapping between wl_seat and cce_seat_v1 objects.
+ The global_remove event for the corresponding wl_seat may be sent before
+ the cce_seat_v1.removed event. This is due to the fact that
+ cce_seat_v1 state changes are synced to the cce window management
+ manage sequence while changes to globals are not.
+ Rationale: The window manager may want to trigger window management
+ state changes based on normal input events received by its shell
+ surfaces for example.
+ </description>
+ <arg name="name" type="uint" summary="name of the wl_seat global"/>
+ </event>
+ <request name="focus_window">
+ <description summary="give keyboard focus to a window">
+ Request that the compositor send keyboard input to the given window.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="window" type="object" interface="zcce_window_v1" summary="window to focus"/>
+ </request>
+ <request name="focus_shell_surface">
+ <description summary="give keyboard focus to a shell_surface">
+ Request that the compositor send keyboard input to the given shell
+ surface.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="shell_surface" type="object" interface="zcce_shell_surface_v1" summary="shell surface to focus"/>
+ </request>
+ <request name="clear_focus">
+ <description summary="clear keyboard focus">
+ Request that the compositor not send keyboard input to any client.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <event name="pointer_enter">
+ <description summary="pointer entered a window">
+ The seat's pointer entered the given window's area.
+ The area of a window is defined to include the area defined by the
+ window dimensions, borders configured using cce_window_v1.set_borders,
+ and the input regions of decoration surfaces. In particular, it does not
+ include input regions of surfaces belonging to the window that extend
+ outside the window dimensions.
+ The pointer of a seat may only enter a single window at a time. When the
+ pointer moves between windows, the pointer_leave event for the old
+ window must be sent before the pointer_enter event for the new window.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ <arg name="window" type="object" interface="zcce_window_v1" summary="window entered"/>
+ </event>
+ <event name="pointer_leave">
+ <description summary="pointer left the entered window">
+ The seat's pointer left the window for which pointer_enter was most
+ recently sent. See pointer_enter for details.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ </event>
+ <event name="window_interaction">
+ <description summary="a window has been interacted with">
+ A window has been interacted with beyond the pointer merely passing over
+ it. This event might be sent due to a pointer button press or due to a
+ touch/tablet tool interaction with the window.
+ There are no guarantees regarding how this event is sent in relation to
+ the pointer_enter and pointer_leave events as the interaction may use
+ touch or tablet tool input.
+ Rationale: this event gives window managers necessary information to
+ determine when to send keyboard focus, raise a window that already has
+ keyboard focus, etc. Rather than expose all pointer, touch, and tablet
+ events to window managers, a policy over mechanism approach is taken.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ <arg name="window" type="object" interface="zcce_window_v1" summary="window interacted with"/>
+ </event>
+ <event name="shell_surface_interaction">
+ <description summary="a shell surface has been interacted with">
+ A shell surface has been interacted with beyond the pointer merely
+ passing over it. This event might be sent due to a pointer button press
+ or due to a touch/tablet tool interaction with the shell_surface.
+ There are no guarantees regarding how this event is sent in relation to
+ the pointer_enter and pointer_leave events as the interaction may use
+ touch or tablet tool input.
+ Rationale: While the shell surface does receive all wl_pointer,
+ wl_touch, etc. input events for the surface directly, these events do
+ not necessarily trigger a manage sequence and therefore do not allow the
+ window manager to update focus or perform other actions in response to
+ the input in a race-free way.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ <arg name="shell_surface" type="object" interface="zcce_shell_surface_v1" summary="shell surface interacted with"/>
+ </event>
+ <request name="op_start_pointer">
+ <description summary="start an interactive pointer operation">
+ Start an interactive pointer operation. During the operation, op_delta
+ events will be sent based on pointer input.
+ When all pointer buttons are released, the op_release event is sent.
+ The pointer operation continues until the op_end request is made during
+ a manage sequence and that manage sequence is finished.
+ The window manager may use this operation to implement interactive
+ move/resize of windows by setting the position of windows and proposing
+ dimensions based off of the op_delta events.
+ This request is ignored if an operation is already in progress.
+ The compositor must ensure that no client has pointer focus from this
+ seat during the pointer operation. This means that the window manager
+ has control over the pointer's cursor surface/shape during the pointer
+ operation. See the cce_seat_v1 description.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <event name="op_delta">
+ <description summary="total cumulative motion since op start">
+ This event indicates the total change in position since the start of the
+ operation of the pointer/touch point/etc.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ <arg name="dx" type="int" summary="total change in x"/>
+ <arg name="dy" type="int" summary="total change in y"/>
+ </event>
+ <event name="op_release">
+ <description summary="operation input has been released">
+ The input driving the current interactive operation has been released.
+ For a pointer op for example, all pointer buttons have been released.
+ Depending on the op type, op_delta events may continue to be sent until
+ the op is ended with the op_end request.
+ This event is sent at most once during an interactive operation.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ </description>
+ </event>
+ <request name="op_end">
+ <description summary="end an interactive operation">
+ End an interactive operation.
+ This request is ignored if there is no operation in progress.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <enum name="modifiers" bitfield="true">
+ <description summary="a set of keyboard modifiers">
+ This enum is used to describe the keyboard modifiers that must be held
+ down to trigger a key binding or pointer binding.
+ Note that cce and wlroots use the values 2 and 16 for capslock and
+ numlock internally. It doesn't make sense to use locked modifiers for
+ bindings however so these values are not included in this enum.
+ </description>
+ <entry name="none" value="0"/>
+ <entry name="shift" value="1"/>
+ <entry name="ctrl" value="4"/>
+ <entry name="mod1" value="8" summary="commonly called alt"/>
+ <entry name="mod3" value="32"/>
+ <entry name="mod4" value="64" summary="commonly called super or logo"/>
+ <entry name="mod5" value="128"/>
+ </enum>
+ <request name="get_pointer_binding">
+ <description summary="define a new pointer binding">
+ Define a pointer binding in terms of a pointer button, keyboard
+ modifiers, and other configurable properties.
+ The button argument is a Linux input event code defined in the
+ linux/input-event-codes.h header file (e.g. BTN_RIGHT).
+ The new pointer binding is not enabled until initial configuration is
+ completed and the enable request is made during a manage sequence.
+ </description>
+ <arg name="id" type="new_id" interface="zcce_pointer_binding_v1" summary="new pointer binding"/>
+ <arg name="button" type="uint" summary="a Linux input event code"/>
+ <arg name="modifiers" type="uint" enum="modifiers" summary="keyboard modifiers"/>
+ </request>
+ <request name="set_xcursor_theme" since="2">
+ <description summary="set the xcursor theme for the seat">
+ Set the XCursor theme for the seat. This theme is used for cursors
+ rendered by the compositor, but not necessarily for cursors rendered by
+ clients.
+ Note: The window manager may also wish to set the XCURSOR_THEME and
+ XCURSOR_SIZE environment variable for programs it starts.
+ </description>
+ <arg name="name" type="string" summary="xcursor theme name"/>
+ <arg name="size" type="uint" summary="cursor size"/>
+ </request>
+ <event name="pointer_position" since="2">
+ <description summary="The current position of the pointer">
+ The current position of the pointer in the compositor's logical
+ coordinate space.
+ This state is special in that a change in pointer position alone must
+ not cause the compositor to start a manage sequence.
+ Assuming the seat has a pointer, this event must be sent in every manage
+ sequence unless there is no change in x/y position since the last time this
+ event was sent.
+ </description>
+ <arg name="x" type="int" summary="global x coordinate"/>
+ <arg name="y" type="int" summary="global y coordinate"/>
+ </event>
+ <request name="pointer_warp" since="3">
+ <description summary="warp the pointer to a given position">
+ Warp the pointer to the given position in the compositor's logical
+ coordinate space.
+ If the given position is outside the bounds of all outputs, the pointer
+ will be warped to the closest point inside an output instead.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ <arg name="x" type="int" summary="global x coordinate"/>
+ <arg name="y" type="int" summary="global y coordinate"/>
+ </request>
+ </interface>
+ <interface name="zcce_pointer_binding_v1" version="4">
+ <description summary="configure a pointer binding, receive trigger events">
+ This object allows the window manager to configure a pointer binding and
+ receive events when the binding is triggered.
+ The new pointer binding is not enabled until the enable request is made
+ during a manage sequence.
+ Normally, all pointer button events are sent to the surface with pointer
+ focus by the compositor. Pointer button events that trigger a pointer
+ binding are not sent to the surface with pointer focus.
+ If multiple pointer bindings would be triggered by a single physical
+ pointer event on the compositor side, it is compositor policy which
+ pointer binding(s) will receive press/release events or if all of the
+ matched pointer bindings receive press/release events.
+ </description>
+ <request name="destroy" type="destructor">
+ <description summary="destroy the pointer binding object">
+ This request indicates that the client will no longer use the pointer
+ binding object and that it may be safely destroyed.
+ </description>
+ </request>
+ <request name="enable">
+ <description summary="enable the pointer binding">
+ This request should be made after all initial configuration has been
+ completed and the window manager wishes the pointer binding to be able
+ to be triggered.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <request name="disable">
+ <description summary="disable the pointer binding">
+ This request may be used to temporarily disable the pointer binding. It
+ may be later re-enabled with the enable request.
+ This request modifies window management state and may only be made as
+ part of a manage sequence, see the cce_window_manager_v1 description.
+ </description>
+ </request>
+ <event name="pressed">
+ <description summary="the bound pointer button has been pressed">
+ This event indicates that the pointer button triggering the binding has
+ been pressed.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ The compositor should wait for the manage sequence to complete before
+ processing further input events. This allows the window manager client
+ to, for example, modify key bindings and keyboard focus without racing
+ against future input events. The window manager should of course respond
+ as soon as possible as the capacity of the compositor to buffer incoming
+ input events is finite.
+ </description>
+ </event>
+ <event name="released">
+ <description summary="the bound pointer button has been released">
+ This event indicates that the pointer button triggering the binding has
+ been released.
+ Releasing the modifiers for the binding without releasing the pointer
+ button does not trigger the release event. This event is sent when the
+ pointer button is released, even if the modifiers have changed since the
+ pressed event.
+ This event will be followed by a manage_start event after all other new
+ state has been sent by the server.
+ The compositor should wait for the manage sequence to complete before
+ processing further input events. This allows the window manager client
+ to, for example, modify key bindings and keyboard focus without racing
+ against future input events. The window manager should of course respond
+ as soon as possible as the capacity of the compositor to buffer incoming
+ input events is finite.
+ </description>
+ </event>
+ </interface>
+ <interface name="zcce_toplevel_v1" version="2">
+ <description summary="toplevel window management controls">
+ An interface to control and listen to CCE-specific window management states
+ for a client surface.
+ </description>
+ <request name="destroy" type="destructor">
+ <description summary="destroy the cce toplevel object"/>
+ </request>
+ <request name="set_floating">
+ <description summary="request floating mode">
+ Explicitly request the compositor to place the window in floating mode.
+ </description>
+ </request>
+ <request name="unset_floating">
+ <description summary="unset floating mode">
+ Request the compositor to return the window to normal tiling mode.
+ </description>
+ </request>
+ <request name="set_maximized">
+ <description summary="request maximized state"/>
+ </request>
+ <request name="unset_maximized">
+ <description summary="unset maximized state"/>
+ </request>
+ <request name="set_fullscreen">
+ <description summary="request fullscreen state"/>
+ </request>
+ <request name="unset_fullscreen">
+ <description summary="unset fullscreen state"/>
+ </request>
+ <request name="set_minimized">
+ <description summary="request minimized state"/>
+ </request>
+ <request name="set_popup" since="2">
+ <description summary="request popup mode">
+ Explicitly request the compositor to place the window in popup mode.
+ </description>
+ </request>
+ <request name="unset_popup" since="2">
+ <description summary="unset popup mode">
+ Request the compositor to return the window to normal tiling mode.
+ </description>
+ </request>
+ <event name="floating_state">
+ <description summary="floating status event">
+ Sent by the compositor to inform the client of its current floating status.
+ </description>
+ <arg name="state" type="uint" summary="1 if floating, 0 otherwise"/>
+ </event>
+ </interface>
+</protocol>
diff --git a/src/widget/layout_helper.rs b/src/widget/layout_helper.rs
new file mode 100644
index 0000000..e1d086c
--- /dev/null
+++ b/src/widget/layout_helper.rs
@@ -0,0 +1,63 @@
+use crate::widget::{Element};
+
+pub struct ColumnLayout {
+ pub x: f32,
+ pub y: f32,
+ pub width: f32,
+ pub gap: f32,
+ pub margin: f32,
+ current_y: f32,
+}
+
+impl ColumnLayout {
+ pub fn new(x: f32, y: f32, width: f32, gap: f32, margin: f32) -> Self {
+ Self {
+ x,
+ y,
+ width,
+ gap,
+ margin,
+ current_y: y + margin,
+ }
+ }
+
+ pub fn add_widget(&mut self, widget: &mut dyn Element, height: f32) {
+ widget.set_rect(self.x + self.margin, self.current_y, self.width - 2.0 * self.margin, height);
+ self.current_y += height + self.gap;
+ }
+
+ pub fn current_y(&self) -> f32 {
+ self.current_y - self.gap + self.margin
+ }
+}
+
+pub struct RowLayout {
+ pub x: f32,
+ pub y: f32,
+ pub height: f32,
+ pub gap: f32,
+ pub margin: f32,
+ current_x: f32,
+}
+
+impl RowLayout {
+ pub fn new(x: f32, y: f32, height: f32, gap: f32, margin: f32) -> Self {
+ Self {
+ x,
+ y,
+ height,
+ gap,
+ margin,
+ current_x: x + margin,
+ }
+ }
+
+ pub fn add_widget(&mut self, widget: &mut dyn Element, width: f32) {
+ widget.set_rect(self.current_x, self.y + self.margin, width, self.height - 2.0 * self.margin);
+ self.current_x += width + self.gap;
+ }
+
+ pub fn current_x(&self) -> f32 {
+ self.current_x - self.gap + self.margin
+ }
+}
diff --git a/src/widget/mod.rs b/src/widget/mod.rs
index ce25503..4fe49db 100644
--- a/src/widget/mod.rs
+++ b/src/widget/mod.rs
@@ -537,9 +537,11 @@ pub mod input;
pub mod container;
pub mod display;
pub mod editor;
-
+pub mod layout_helper;
+
// Re-exports
pub use self::editor::TextEditorState;
+pub use self::layout_helper::{ColumnLayout, RowLayout};
pub use self::core::{Widget, focus, hover_animation, popovers, clipboard, context_menu, clear_widget_references};
pub use self::input::{
Button, TextBox, Spinbox, Dropdown, Checkbox, Toggle, Slider, RangeSlider,