[PATCH wayland] protocol: Add set_xwayland request for new shell surface type

[Pekka Paalanen]

Hi Tiago,

I have some questions below. Sorry for this being the only patch of the
series I can look at for now.

On Wed, 12 Dec 2012 13:26:33 -0200
Tiago Vignatti <tiago.vignatti at intel.com> 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 <tiago.vignatti at intel.com>
> ---
>  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?

> +    </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).

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.

Could we have the set_xwayland request in, for instance, the xwayland
"xserver" interface, with an additional wl_surface argument?
What is the difference between xserver:set_window_surface and
wl_shell_surface:set_xwayland?
Could the latter not be implemented with only the former?

>      <request name="set_title">
>        <description summary="set surface title">
>        </description>


Thanks,
pq