[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