X-Git-Url: https://gerrit.automotivelinux.org/gerrit/gitweb?a=blobdiff_plain;f=protocol%2Fagl-shell.xml;h=8057387a3f2bbd08ff76ec81ad492ae0e25d0832;hb=HEAD;hp=1096c6461190a26b0927bdfcc5b4ea0d94e0a0dc;hpb=2d7243208d3e455decd730e7e33ab2452b1a0508;p=src%2Fagl-compositor.git diff --git a/protocol/agl-shell.xml b/protocol/agl-shell.xml index 1096c64..f392691 100644 --- a/protocol/agl-shell.xml +++ b/protocol/agl-shell.xml @@ -1,7 +1,7 @@ - Copyright © 2019 Collabora, Ltd. + 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"), @@ -22,8 +22,29 @@ 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. @@ -39,12 +60,27 @@ + + + + + + + + + + + + + + + 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 oppurtunity to set up and configure several + 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 @@ -76,7 +112,7 @@ 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 - correponding width/height that the client should use, and 0 for 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. @@ -113,5 +149,334 @@ + + + + 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. + + + + + + + + + + + Informs the client that an application has changed its state to another, + specified by the app_state enum. Client can use this event to track + current application state. For instance to know when the application has + started, or when terminated/stopped. + + + + + + + + A hint for the compositor to use a custom area, rather than + inferring the activation area. If any panels are used + the compositor computes the activation area by subtracting the + panels geometry area. If no panels are used then the entire output + is being used. This request changes that as to hint the compositor + to use the supplied rectangle and ignore any potential panels + that might been set-up previously. + + In order for this request to take effect it will need to happen + before the 'ready' request in order for the compositor to make use of it. + Note that any 'set_panel' request be will not be honored, if this request + has been called. + + The x and y coordinates use the top-left corner as the origin. The + rectangle area shouldn't exceed the output area, while an area smaller + than the output, would basically result in showing up the background + surface. + + + + + + + + + + + Ask the compositor to hide the toplevel window for window + management purposes. Depending on the window role, this request + will either display the previously active window (or the background + in case there's no previously active surface) or temporarily (or + until a 'activate_app' is called upon) hide the surface. + + All the surfaces are identifiable by using the app_id, and no actions + are taken in case the app_id is not/was not present. + + See xdg_toplevel.set_app_id from the xdg-shell protocol for a + description of app_id. + + + + + + + Makes the application identified by app_id as floating. If the + application's window is already mapped, in a maximized, normal state, + it would transition to the float state. + + For applications that want to modify their own state, this request + must be done before the initial surface commit in order to take effect. + + If the application is already in floating state, this request wouldn't + do anything. + + There's no persistence of this request, once the application terminated + you'll to issue this request again for that particular app_id. + + The x, and y values would be initial position of the window where the + window surface will be placed. + + See xdg_toplevel.set_app_id from the xdg-shell protocol for a + description of app_id. + + + + + + + + + Returns the application identified by app_id as it was in the normal state. + This is useful to come back from other states to the maximized state, the + normal state applications are started. + + + + + + + Makes the application identified by app_id as fullscreen. If the + application's window is already mapped, in a maximized, normal state, + it would transition to the fullscreen state. + + For applications that want to modify their own state, this request + must be done before the initial surface commit in order to take effect. + + If the application is already in fullscreen state, this request wouldn't + do anything. + + There's no persistence of this request, once the application terminated + you'll to issue this request again for that particular app_id. + + See xdg_toplevel.set_app_id from the xdg-shell protocol for a + description of app_id. + + + + + + + this would allow the compositor to place an application on a particular + output, if that output is indeed available. this can happen before + application is started which would make the application start on that + particular output. if the application is already started it would + move the application to that output. + + there's no persistence of this request, once the application terminated + you'll need to issue this request again for that particular app_id. + + see xdg_toplevel.set_app_id from the xdg-shell protocol for a + description of app_id. + + + + + + + + Clients can use this event to be notified when an application + wants to be displayed on a certain output. This event is sent in + response to the set_app_output request. + + See xdg_toplevel.set_app_id from the xdg-shell protocol for a + description of app_id. + + + + + + + + Clients can inform the compositor to position a floating type of window + at the specific location, pointed by x and y value. If the window is + not a floating type, the request will be discarded. Note that + positioning doesn't take output into consideration nor does orientation + of the outpus. It is expected that the client knows already where the + position is localed in global coordonate space. If the window doesn't + exist the compositor will ignore the request. For this request to + function properly the window would first to be set as floating and then + it can be moved using this request. + + see xdg_toplevel.set_app_id from the xdg-shell protocol for a + description of app_id. + + + + + + + + + Clients can inform the compositor to scale a floating type of window + to the values specified in width and height. If the window is + not a floating type, the request will be discarded. If the window + doesn't exist the compositor will ignore the request. For this request + to function properly the window would first to be set as floating + and then it can be moved using this request. + + + see xdg_toplevel.set_app_id from the xdg-shell protocol for a + description of app_id. + + + + + + + + + This requests asks the compositor to change the application from the + original mode (whatever that might be) to a split, tiled orientation + mode defined in the tile orientation enum. + Clients need to implement resizing (to 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. The client can verify this request succeed by checking the + xdg-shell configure event and with it, the states sent + by the compositor. + + If there's no app_id with the supplied name, the compositor will add + the app to a pending list in order to be applied when an application + gets started, or if the application sets its application after the + initial wl_surface.commit request. + + Applications can use this approach if they want to be started in a + tiled orientation 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. A + horizontal and vertical tile orientation simultaneously is not + 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. + + A width size can also be specified for the split window. Note that this + width can't exceed the output width value, or the compositor can choose + to ignore this value. + + Making the split window sticky would inform the compositor that the + window should always be active when switching or when activating between + other windows. This would allow navigating, starting and activating other + windows while keeping the current window always in a split state. + + See xdg_toplevel.set_app_id from the xdg-shell protocol for a + description of app_id. + + + + + + + + + + + + This interface allows another client bind to the agl_shell interface, + while there's another shell client already present. + + The client should first bind to this interface and then inform the + compositor with the 'doas_shell_client' request and it wants to bind to + the agl_shell interface. The client is still expected, if using a new + version of the agl_shell interface, to wait for the 'bound_ok' and + 'bound_fail' events before issueing any other requests/events. + + Note that this interface has its limitations, and the compositor would + still refuse the act for 'set_panel' or 'set_background' requests + of the agl_shell interface if there's already a client that used them. + + Any other requests or events should be delievered and handled as it would + a client bound to the agl_shell interface. + + + + + + + + + + Call the destructor once you're ready with agl_shell_ext interface. + This would reset the state and would make any requests made + on the agl_shell interface be terminated. The client would need + to bind again the agl_shell_ext and issue a 'doas_shell_client' + request. + + + + + + Prior to binding to agl_shell interface, this request would inform + the compositor that it wants to gain access the agl_shell interface. + The client is expected to wait for 'doas_shell_client_done' event and + check for a successful status before going further with binding to + the agl_shell interface. + + + + + + The client should check the status event to verify that the + compositor was able to handle the request. + + +