[PATCH 2/2] protocol: add state set functions for maximized and fullscreen.

Rafael Antognolli antognolli at gmail.com
Wed Oct 16 16:56:46 CEST 2013


On Wed, Oct 16, 2013 at 2:53 AM, Kristian Høgsberg <krh at bitplanet.net> wrote:
> On Tue, Oct 15, 2013 at 8:05 AM,  <antognolli at gmail.com> wrote:
>> From: Rafael Antognolli <rafael.antognolli at intel.com>
>>
>> These functions only differ from the previous one because they request
>> that the given state is set, without changing the surface type, thus
>> removing any previously state that was set on it.
>>
>> Both states can be used at the same time, and the states can be set or
>> unset independently.
>>
>> NOTE: The original surface_set_maximized and surface_set_fullscreen
>> requests were removed.
>
> Hi Rafael,
>
> Just to keep the list in the loop - we talked about how to send out
> these patches and I think it's clearer if we just work on one patch
> that adds the xdg-shell.xml file in one go instead of these two
> patches.

OK, I merged the patches and sent them again, along with some other
changes that you mention below. Some comments follow:

> Much of the discussion on the list around xdg_shell has been about the
> surface states and how the server can initiate maximize or minimize
> etc.  I think we mostly have consensus there, so I want to bring up a
> few other points/ideas for xdg_shell.  These are a little un-edited,
> but it's late here and I just want to start the discussion:
>
>     - move/resize needs cursor_surface arg to avoid mismatch between
> hover cursor and resize/move cursor.

I don' t understand exactly why, but I added a cursor_surface arg to
them anyway.

>     - transient for shouldn't take position.

Same here. Why shouldn't t it take the position? How are we supposed
to set the transient surface position then? Another method?

>     - We should add a _NET_WM_STATE_DEMANDS_ATTENTION equivalent

Ack, I added a "demands_attention" request. Is that enough, or do we
need more parameters?

>     - New keyboard focus protocol: instead of active surface meaning
> "has keyboard focus" we need something that works in a touch-only
> environment and we need a more generic way to create surfaces that
> don't take keyboard focus.  I propose a new xdg_surface.activate event
> that indicates that the surface has been activated (by clicking or
> touching or alt-tabbing to it (or hovering in case of sloppy focus)).
> When a surface is "the active surface", the client can choose to
> assign kb focus (xdg_surface.take_keyboard_focus) to any of its
> surfaces.

Ack. I added both the event and the request that you mention. Please
see if they are enough.

>     - We need to solve stacking - how does a wayland shell raise an
> applications and all its surfaces correctly.  The two ideas I have are
> either 1) let the client raise its surfaces when it's active (uses the
> same xdg_surface.activate event as above) and just let the client
> control which surfaces to raise and in which order in response to
> being activated or 2) let the client describe above/below relation
> between its surfaces and make sure the shell respects these
> constraints when raising a surface (eg, toolbars above documents, but
> no relation between individual toolbar surfaces or doc surfaces.
> Raising a document raises all the toolbox surfaces to be on top, but
> doesn't affect other documents and preserves the stacking order of the
> toolbox surface).

OK, this is really complex. I'm going to think about it too, but the
second approach seems to complicate things a lot from the
client/toolkits point of view, IMHO. I left it out for now, so we can
discuss it better.

>     - always on top, sticky; I think these are straight forward,
> they're just flags an application can set.

Done, and also added the minimized state. I changed always on top to a
layer thing, so one can set (depending on the parameter) if it's
always on top or always below.

I also added the events for these statuses. Accepting suggestions for
better names.

>     - If a compositor initiates a maximize, it should immediately
> followed the event by a configure event so that the client does not
> need to wait for a configure event in response to set_maximized.  just
> a subtle tweak to avoid eliminate roundtrip.

OK, but this is just an implementation thing, right? Do I have to
change anything in the protocol for this?

Thanks for the review,
Rafael

>
>>  protocol/xdg-surface.xml | 149 ++++++++++++++++++++++++++++-------------------
>>  1 file changed, 89 insertions(+), 60 deletions(-)
>>
>> diff --git a/protocol/xdg-surface.xml b/protocol/xdg-surface.xml
>> index 4d2cc1b..b224fee 100644
>> --- a/protocol/xdg-surface.xml
>> +++ b/protocol/xdg-surface.xml
>> @@ -170,47 +170,6 @@
>>        <entry name="fill" value="3" summary="no upscaling, center on output and add black borders to compensate size mismatch"/>
>>      </enum>
>>
>> -    <request name="set_fullscreen">
>> -      <description summary="make the surface a fullscreen surface">
>> -       Map the surface as a fullscreen surface.
>> -
>> -       If an output parameter is given then the surface will be made
>> -       fullscreen on that output. If the client does not specify the
>> -       output then the compositor will apply its policy - usually
>> -       choosing the output on which the surface has the biggest surface
>> -       area.
>> -
>> -       The client may specify a method to resolve a size conflict
>> -       between the output size and the surface size - this is provided
>> -       through the method parameter.
>> -
>> -       The framerate parameter is used only when the method is set
>> -       to "driver", to indicate the preferred framerate. A value of 0
>> -       indicates that the app does not care about framerate.  The
>> -       framerate is specified in mHz, that is framerate of 60000 is 60Hz.
>> -
>> -       A method of "scale" or "driver" implies a scaling operation of
>> -       the surface, either via a direct scaling operation or a change of
>> -       the output mode. This will override any kind of output scaling, so
>> -       that mapping a surface with a buffer size equal to the mode can
>> -       fill the screen independent of buffer_scale.
>> -
>> -       A method of "fill" means we don't scale up the buffer, however
>> -       any output scale is applied. This means that you may run into
>> -       an edge case where the application maps a buffer with the same
>> -       size of the output mode but buffer_scale 1 (thus making a
>> -       surface larger than the output). In this case it is allowed to
>> -       downscale the results to fit the screen.
>> -
>> -       The compositor must reply to this request with a configure event
>> -       with the dimensions for the output on which the surface will
>> -       be made fullscreen.
>> -      </description>
>> -      <arg name="method" type="uint"/>
>> -      <arg name="framerate" type="uint"/>
>> -      <arg name="output" type="object" interface="wl_output" allow-null="true"/>
>> -    </request>
>> -
>>      <request name="set_popup">
>>        <description summary="make the surface a popup surface">
>>         Map the surface as a popup.
>> @@ -242,9 +201,34 @@
>>        <arg name="flags" type="uint"/>
>>      </request>
>>
>> -    <request name="set_maximized">
>> -      <description summary="make the surface a maximized surface">
>> -       Map the surface as a maximized surface.
>> +    <request name="set_title">
>> +      <description summary="set surface title">
>> +       Set a short title for the surface.
>> +
>> +       This string may be used to identify the surface in a task bar,
>> +       window list, or other user interface elements provided by the
>> +       compositor.
>> +
>> +       The string must be encoded in UTF-8.
>> +      </description>
>> +      <arg name="title" type="string"/>
>> +    </request>
>> +
>> +    <request name="set_class">
>> +      <description summary="set surface class">
>> +       Set a class for the surface.
>> +
>> +       The surface class identifies the general class of applications
>> +       to which the surface belongs. A common convention is to use
>> +       the file name (full path if non-standard location) of the
>> +       applications .desktop file as the class.
>> +      </description>
>> +      <arg name="class_" type="string"/>
>> +    </request>
>> +
>> +    <request name="state_set_maximized">
>> +      <description summary="set the surface maximized state">
>> +       Set the surface state as maximized.
>>
>>         If an output parameter is given then the surface will be
>>         maximized on that output. If the client does not specify the
>> @@ -262,33 +246,78 @@
>>         fullscreen shell surface.
>>
>>         The details depend on the compositor implementation.
>> +
>> +       This state can be set while other surface states are still set,
>> +       and it won't unset them.
>>        </description>
>>        <arg name="output" type="object" interface="wl_output" allow-null="true"/>
>>      </request>
>>
>> -    <request name="set_title">
>> -      <description summary="set surface title">
>> -       Set a short title for the surface.
>> +    <request name="state_unset_maximized">
>> +      <description summary="unset the surface maximized state">
>> +        Unset the surface as maximized.
>>
>> -       This string may be used to identify the surface in a task bar,
>> -       window list, or other user interface elements provided by the
>> -       compositor.
>> +       The surface will be mapped to the corresponding state that has
>> +       more precedence (e.g. if fullscreen is still set, the surface
>> +       will be mapped as fullscreen, otherwise as a simple toplevel
>> +       surface).
>> +      </description>
>> +    </request>
>>
>> -       The string must be encoded in UTF-8.
>> +    <request name="state_set_fullscreen">
>> +      <description summary="set the surface fullscreen state">
>> +       Set the surface state as fullscreen.
>> +
>> +       If an output parameter is given then the surface will be made
>> +       fullscreen on that output. If the client does not specify the
>> +       output then the compositor will apply its policy - usually
>> +       choosing the output on which the surface has the biggest surface
>> +       area.
>> +
>> +       The client may specify a method to resolve a size conflict
>> +       between the output size and the surface size - this is provided
>> +       through the method parameter.
>> +
>> +       The framerate parameter is used only when the method is set
>> +       to "driver", to indicate the preferred framerate. A value of 0
>> +       indicates that the app does not care about framerate.  The
>> +       framerate is specified in mHz, that is framerate of 60000 is 60Hz.
>> +
>> +       A method of "scale" or "driver" implies a scaling operation of
>> +       the surface, either via a direct scaling operation or a change of
>> +       the output mode. This will override any kind of output scaling, so
>> +       that mapping a surface with a buffer size equal to the mode can
>> +       fill the screen independent of buffer_scale.
>> +
>> +       A method of "fill" means we don't scale up the buffer, however
>> +       any output scale is applied. This means that you may run into
>> +       an edge case where the application maps a buffer with the same
>> +       size of the output mode but buffer_scale 1 (thus making a
>> +       surface larger than the output). In this case it is allowed to
>> +       downscale the results to fit the screen.
>> +
>> +       The compositor must reply to this request with a configure event
>> +       with the dimensions for the output on which the surface will
>> +       be made fullscreen.
>> +
>> +       This state can be set while other surface states are still set,
>> +       and it won't unset them. It has precedence over maximized, and
>> +       the surface will be kept fullscreen until unset.
>>        </description>
>> -      <arg name="title" type="string"/>
>> +      <arg name="method" type="uint"/>
>> +      <arg name="framerate" type="uint"/>
>> +      <arg name="output" type="object" interface="wl_output" allow-null="true"/>
>>      </request>
>>
>> -    <request name="set_class">
>> -      <description summary="set surface class">
>> -       Set a class for the surface.
>> +    <request name="state_unset_fullscreen">
>> +      <description summary="unset the surface fullscreen state">
>> +        Unset the surface as maximized.
>>
>> -       The surface class identifies the general class of applications
>> -       to which the surface belongs. A common convention is to use
>> -       the file name (full path if non-standard location) of the
>> -       applications .desktop file as the class.
>> +       The surface will be mapped to the corresponding state that has
>> +       more precedence (e.g. if maximized is still set, the surface
>> +       will be mapped as maximized, otherwise as a simple toplevel
>> +       surface).
>>        </description>
>> -      <arg name="class_" type="string"/>
>>      </request>
>>
>>      <event name="ping">
>> --
>> 1.8.3.1
>>
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



-- 
Rafael Antognolli


More information about the wayland-devel mailing list