On 3/11/18 9:49 PM, Simon Ser wrote:
[snip]
+
+ <interface name="zxdg_toplevel_decoration_manager_v1" version="1">
+ <description summary="window decoration manager">
+ This interface permits choosing between client-side and server-side
+ window decorations for a toplevel surface.
+
+ A window decoration is a user interface component used to move, resize
and
+ change a window's state. It can be managed either by the client (part of
+ the surface) or by the server.
You mention decorations only, but this (or some other text below maybe)
should mention shadows as well. You may consider them as part of the
decoration, but xdg_surface.set_window_geometry() is designed to include
decoration and exclude shadows. Yet, e.g. GTK+ allows to resize using
shadows IIRC.
Nit: I think GTK+ allows to move from any dead zone in the surface too. :-)
xdg-shell's wording includes drop-shadows as part of decorations:
Client-side decorations often have invisible portions like drop-shadows which
should be ignored for the purposes of aligning, placing and constraining
windows.
So "decorations" here stand for both visible parts such as the titlebar and
invisible parts such as drop-shadows. Do you think the protocol needs to
disambiguate these concepts?
You’re right, though I would rather be too precise (while not
exhaustive) that not enough, just in case. But others may have a
different opinion so let’s wait for more reviews here.
[snip]
+
+ <request name="set_mode">
+ <description summary="set the decoration mode">
+ Set the toplevel surface decoration mode.
+
+ After requesting a decoration mode, the compositor will respond by
+ emitting a xdg_surface.configure event. The client should then update
+ its content, drawing it with or without decorations depending on the
+ received mode. The client must also acknowledge the configure when
+ committing the new content (see xdg_surface.ack_configure).
+
+ The compositor can ignore this request.
+ </description>
+ <arg name="mode" type="uint" enum="mode" summary="the decoration mode"/>
+ </request>
This request I’m still not sure about it.
Why would an SSD-capable client would want to switch from CSD
back-and-forth? What is the use case here? (Preferably a user use case.)
One reason is consistency with xdg-shell.
Not all states can be client-initiated though.
But there are also real use-cases:
- A compositor might prefer SSDs or CSDs depending of the window container. For
instance, a tiled compositor might prefer SSDs for tiled windows and CSDs for
floating windows. Windows can be moved between a tiling and a floating
container at run-time.
That I’m 100% ok with, your point is clear and makes a lot of sense. I
would even object if someone wanted to remove that. :-)
- Clients might expose a user setting that allows toggling SSDs. For instance,
Chrome/Chromium already has such a feature. Requiring the user to restart the
app or to quickly close and reopen the main window offers poor UX.
I’m not convinced a client should have such a setting. For consistency
and UX, I would rather have a central point of setting (the compositor).
If we make it harder (though possible) to switch, then we can hopefully
limit the number of clients wanting to support such a setting.
Since we must have the destructor support anyway, on both sides, I think
it is enough for this feature.
[snip]
Last but not least: it should be much much clearer that the compositor
is in charge here. This is not about magic SSD, clients must support CSD
in all cases and should not error out if this global is not here. And
even then, it may want CSD in some cases.
I've added this in the protocol description:
Note that even if the server supports server-side window decorations, clients
must still support client-side decorations.
I think people already got that part, though it does no harm to say it
again, but I was speaking about the configure event. It may happen *at
any time* and the client must be prepared (e.g for the cases you mentioned).
Cheers,
--
Quentin “Sardem FF7” Glidic
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
