Copyright © 2019, 2022 Collabora, Ltd. 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. Starting with version 2 of the protocol, the client is required to wait for the 'bound_ok' or 'bound_fail' events in order to proceed further. In case the client gets a 'bound_fail' event then it should consider that there's another client already bound to the agl_shell protocol. A client that receives a 'bound_ok' event should consider that there's no other client already bound to the interface and can proceed further. If the client uses an older version of the protocol it will receive automatically an error and the compositor will terminate the connection, if there's another client already bound the interface. If the client receives the 'bound_fail' event and attempts to use the interface further it will receive an error and the compositor will terminate the connection. After the 'bound_fail' event was received the client should call the destructor, which has been added with version 2 of the protocol. The client is free to try at a later point in time to see if it will receive the 'bound_ok' event, but there's no explicit way of finding out when that event will be delivered. It is assumed that it can infer that information through other means/other channels. Tell the server that this client is ready to be shown. The server will delay presentation during start-up until all shell clients are ready to be shown, and will display a black screen instead. This gives the client an opportunity to set up and configure several surfaces into a coherent interface. The client that binds to this interface must send this request, otherwise they may stall the compositor unnecessarily. If this request is called after the compositor has already finished start-up, no operation is performed. Set the surface to act as the background of an output. After this request, the server will immediately send a configure event with the dimensions the client should use to cover the entire output. The surface must have a "desktop" surface role, as supported by libweston-desktop. Only a single surface may be the background for any output. If a background surface already exists, a protocol error is raised. Set the surface to act as a panel of an output. The 'edge' argument says what edge of the output the surface will be anchored to. After this request, the server will send a configure event with the corresponding width/height that the client should use, and 0 for the other dimension. E.g. if the edge is 'top', the width will be the output's width, and the height will be 0. The surface must have a "desktop" surface role, as supported by libweston-desktop. The compositor will take the panel's window geometry into account when positioning other windows, so the panels are not covered. XXX: What happens if e.g. both top and left are used at the same time? Who gets to have the corner? Only a single surface may be the panel for an output's edge. If a surface already exists on an edge, a protocol error is raised. Ask the compositor to make a toplevel to become the current/focused window for window management purposes. See xdg_toplevel.set_app_id from the xdg-shell protocol for a description of app_id. If multiple toplevels have the same app_id, the result is unspecified. XXX: Do we need feedback to say it didn't work? (e.g. client does not exist) Informs the client that it was able to bind the agl_shell interface succesfully. Clients are required to wait for this event before continuing further. Informs the client that binding to the agl_shell interface was unsuccesfull. Clients are required to wait for this event for continuing further. Request changes the application from the original mode (whatever that might be) to a split, tiled orientation mode defined in the orientation enum. Clients need to implement resizing (meaing handle xdg-shell configure events) for this to work correctly. This request only handles a single level of tiling for practical reasons: to keep implementation simple and straight forward. The compositor will ignore requests if there are already two windows present, and will terminate the client's connection with a protocol violation, if it detects more than one tiling level. If there's no app_id with the supplied name it will be added to a pending list in order to be applied when an application id gets started. Applications can use this approch if they want to be started in a tiled orientantion position, before creating the xdg-shell toplevel role. A none orientation type would make the window go back to the original maximized mode. If two windows are side by side, returning one of them back the original mode would mean the other one will be made hidden and the one doing the request for the none orientation will become the currently active window. A further activation, using activate_app request for the other window would make that one active. Closing the window in the tiled orientation state implies that either the background surface will displayed, or in case there was another applications being shown at that time, will make that application be returned to the original, maximized state. The tiled orientation could be applied independently of each other, such that a client can transition from one tiled orientation to another. Note that any other window already present would literally take the opposite orientation with the one currently being changed. So tiled orientation modification automatically implies a tile orientation for any other application already present/active at that time. In case there's already a client active at that time, it will be attributed automatically the opposite tiled orientation, such that two concurrent applications can be displayed at the same time. The orientation tiles can not be combined, and only state at a time can be active. Only horizontal and vertical tiling is possible. Input focus is being delivered to the last started/activated window, such that users can cycle between that one or the other, assumes there's another window in the first place. See xdg_toplevel.set_app_id from the xdg-shell protocol for a description of app_id.