agl-shell: Add an explicit set_app_split

[src/agl-compositor.git] / protocol / agl-shell.xml

<?xml version="1.0" encoding="UTF-8"?>
<protocol name="agl_shell">
  <copyright>
    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.
  </copyright>
  <interface name="agl_shell" version="6">
    <description summary="user interface for Automotive Grade Linux platform">
      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 delivered. It is assumed that it can
      infer that information through other means/other channels.
    </description>

    <request name="destroy" type="destructor" since="2">
      <description summary="destroys the factory object">
      </description>
    </request>

    <enum name="error">
      <entry name="invalid_argument" value="0"/>
      <entry name="background_exists" value="1"/>
      <entry name="panel_exists" value="2"/>
    </enum>

    <enum name="edge">
      <entry name="top" value="0"/>
      <entry name="bottom" value="1"/>
      <entry name="left" value="2"/>
      <entry name="right" value="3"/>
    </enum>

    <enum name="app_state" since="4">
      <entry name="started" value="0"/>
      <entry name="activated" value="1"/>
      <entry name="deactivated" value="2"/>
      <entry name="destroyed" value="3"/>
    </enum>

    <enum name="split_orientation" since="6">
      <entry name="none" value="0"/>
      <entry name="top" value="1"/>
      <entry name="bottom" value="2"/>
      <entry name="left" value="3"/>
      <entry name="right" value="4"/>
    </enum>

    <enum name="app_role" since="4">
      <entry name="float" value="0"/>
      <entry name="remote" value="1"/>
      <entry name="split" value="2" since="6"/>
    </enum>

    <request name="ready">
      <description summary="client is ready to be shown">
        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.
      </description>
    </request>

    <request name="set_background">
      <description summary="set surface as output's background">
        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.
      </description>
      <arg name="surface" type="object" interface="wl_surface"/>
      <arg name="output" type="object" interface="wl_output"/>
    </request>

    <request name="set_panel">
      <description summary="set surface as panel">
        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.
      </description>
      <arg name="surface" type="object" interface="wl_surface"/>
      <arg name="output" type="object" interface="wl_output"/>
      <arg name="edge" type="uint" enum="edge"/>
    </request>

    <request name="activate_app">
      <description summary="make client current window">
        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)
      </description>
      <arg name="app_id" type="string"/>
      <arg name="output" type="object" interface="wl_output"/>
    </request>

    <request name="deactivate_app" since="3">
      <description summary="de-activate/hide window identified by app_id">
        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.
      </description>
      <arg name="app_id" type="string"/>
    </request>

    <event name="bound_ok" since="2">
     <description>
        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.
     </description>
    </event>

    <event name="bound_fail" since="2">
      <description>
        Informs the client that binding to the agl_shell interface was
        unsuccesfull. Clients are required to wait for this event for
        continuing further.
      </description>
    </event>

    <event name="app_state" since="4">
      <description summary="event sent when application has suffered state modification">
        Notifies application(s) when other application have suffered state modifications.
      </description>
      <arg name="app_id" type="string"/>
      <arg name="state" type="uint" enum="app_state"/>
      <arg name="role" type="uint" enum="app_role"/>
    </event>

    <request name="set_app_float" since="5">
      <description summary="set the application floating">
        The agl-shell protocol makes the windows by default maximized to the
        output area, taking into consideration the panel sizes.

        If certain client would want be behave like a pop-up type, always sticky
        window, when switching between applications, it can use this request
        to do so.

        If the application, specified with the app_id string,
        is not currently running, it will be added it to a pending list.

        If, at a later point in time, that application does come up it will
        apply the floating state to it. Note that once that happens, and a later
        point in time that application is stopped, these changes will not apply
        anymore. To keep a permanent state see also set_app_property_mode().

        Another use-case is for applications that want to be started from the
        beginning as floating, so they the client must call this request before
        doing the initial wl_surface.commit().

        Application can also transit from float to maximized and vice-versa
        using this request or the set_app_unfloat to go back to an
        initial maximized state.

        See xdg_toplevel.set_app_id from the xdg-shell protocol for a
        description of app_id.
      </description>
      <arg name="app_id" type="string"/>
      <arg name="x" type="int"/>
      <arg name="y" type="int"/>
    </request>

    <request name="set_app_unfloat" since="5">
      <description summary="set the application back to maximized mode">
        This undoes the effect of the 'set_app_float' request
        in case the client wants to go from floating back to the maximized
        state. If there's no app_id present this request will obviously do
        nothing.

        See xdg_toplevel.set_app_id from the xdg-shell protocol for a
        description of app_id.
      </description>
      <arg name="app_id" type="string"/>
    </request>

    <request name="set_app_remote" since="5">
      <description summary="set the application remoting on another output">
        See xdg_toplevel.set_app_id from the xdg-shell protocol for a
        description of app_id.
      </description>
      <arg name="app_id" type="string"/>
      <arg name="output" type="object" interface="wl_output"/>
    </request>

    <request name="set_app_property_mode" since="5">
      <description summary="Request to change the application properties lifetime">
        Use this request to inform the compositor to maintain a pending state
        for an app_id being set with set_app_float/set_app_remote request.

        Any subsequent application matching that app_id would survive a
        potential application destruction. Note that this request will
        take effect globally on all applications.

        To turn it on, or off, use the 'permanent' argument. Initially,
        the compositor will have this option set to off. Note that it
        doesn't matter the order of this request with respect to
        set_app_property() request, as the changes will only take effect
        when the application itself does the commit with an app_id set,
        therefore the only requirement is to call this request before
        the app_id client does its first commit.
      </description>
      <arg name="permanent" type="uint"/>
    </request>

    <request name="set_app_split" since="6">
      <description summary="set the application split">
        Request changes the application from the original mode (whatever that
        might be) to a split, tiled orientation mode defined in the orientation
        split_orientation enum. This request only handles a single level of
        orientation for practical reasons.

        If there's no app_id with the supplied name this request does nothing.

        A none orientation type would make the window go back to the original
        maximized mode. This implies that either the background surface will
        displayed or in case there are more than one applications being
        shown, the other application will 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. Any other window already present would switch places with
        the currently one being changed.

        In case there's already a client that's already 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, which means we can't have a top left orientation, or
        any combination like that.

        See xdg_toplevel.set_app_id from the xdg-shell protocol for a
        description of app_id.
      </description>
      <arg name="app_id" type="string"/>
      <arg name="orientation" type="uint" enum="split_orientation"/>
    </request>

  </interface>
</protocol>