AGL shell

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)

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 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.

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.

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.

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.