On 12/13/2012 05:38 AM, Pekka Paalanen wrote:
On Wed, 12 Dec 2012 13:26:33 -0200
Tiago Vignatti <[email protected]> wrote:
X11 apps use global coordinates most of the time for window placement and the
current approach we have, where transient windows is placed parent relative,
is not sufficient. IOW we can't use the relation of parent <-> child
coordinates because we can't go out there and fix all the clients to place
subwindows relative.
Besides, it has to be a separate wl_shell_surface request specifically for
XWayland because we don't want stock Wayland applications using global
coordinates either.
At the moment only one method for XWayland windows was implemented, which is
the 'inactive' to not set focus when the window is configured. Later we will
want to add a few more methods for dealing with different types of windows.
Signed-off-by: Tiago Vignatti <[email protected]>
---
protocol/wayland.xml | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 0ce68ef..e6df6f3 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -683,6 +683,26 @@
<arg name="output" type="object" interface="wl_output"
allow-null="true"/>
</request>
+ <enum name="xwayland">
+ <description summary="XWayland surface types">
+ </description>
+
+ <entry name="inactive" value="0x1" summary="do not set keyboard focus"/>
So the only supported type of xwayland windows is the "inactive" one?
I.e. no "normal" windows at all? Or are normal X windows realised by not
using set_xwayland at all?
No. The approach I'm using is a bit confusing indeed: X top-level
windows use set_toplevel, while X override-redirected windows use
set_xwayland.
So at the moment with this patch, I'm assuming that *all*
override-redirected windows are transient and inactive. That being said,
by no means this is enough for mapping all types of X windows on
Wayland, but is definitely better than the previous approach where we
relied on the parent <-> child for placement. Eventually we'll need to
extend the xwayland methods accordingly to support popup and other types.
+ </enum>
+
+ <request name="set_xwayland">
+ <description summary="make the surface a X11 type of surface">
+ X11 apps use global coordinates most of the time for window placement
+ and this request has to be used only for X Windows. Hence, the
+ coordinates 'x' and 'y' that are global, ie relative to window output
+ dimensions.
+ </description>
+
+ <arg name="x" type="int"/>
+ <arg name="y" type="int"/>
+ <arg name="method" type="uint"/>
+ </request>
+
I wonder, why is this request part of wl_shell_surface? Here it is
available to all normal Wayland clients which in my opinion is
undesireable. If we later add more wl_shell_surface features, those
features cannot be implemented without also implementing and offering
this one, because we have monotonic interface versioning (no pick and
choose).
set_xwayland is part of wl_shell_surface because we're re-using the
existent *desktop* methods of the wl_shell; namely the move, resize and
toplevel ones. And the map & configure of desktop shell makes sense on
most of the cases also, so for convenience I opted for reusing it.
About the availability of it to regular Wayland clients, I agree, it's a
problem. Bill Spitzak pointed this out on the previous set. It sets a
bad example because it exposes global position to all regular clients
and we don't want this.
Why is it not in the xwayland specific protocol extension?
Hooking it up inside Weston might be a little ugly, but I think that
would be much better and less impact than exposing it in public
protocol.
...
Besides the obvious of exposing a global coordinate system, this will
also tie xwayland support to the wl_shell protocol, i.e. desktops.
Other public shell protocols would then have to copy this request, if
they were to support xwayland. Therefore I would prefer to keep all
xwayland specific protocol in the xwayland protocol extension.
I don't see a problem on having xwayland typical applications linked
with "desktop" style of interfaces. X11 and its WM standards are
flexible enough for building different graphics interfaces and the
wl_shell is the best at the moment to fitting them.
But yeah, I think we'll eventually have to go for a specific xwayland
extension only for the sake of having a private interface for XWayland
only, ie not let regular clients see it.
Thanks,
Tiago
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
