Sub-surface protocol

[Pekka Paalanen]

On Wed, 05 Dec 2012 15:43:18 -0200
Tiago Vignatti <tiago.vignatti at linux.intel.com> wrote:

> Hi,
> 
> On 12/05/2012 12:32 PM, Pekka Paalanen wrote:
> >
> > I have not even thought about sub-surfaces' implications to input
> > handling or the shell yet. Sub-surfaces probably need to be able to
> > receive input. The shell perhaps needs a bounding box of the set of
> > surfaces to be able to pick an initial position for the window, etc.
> 
> indeed. On my "less intrusive" draft of subsurface, I've first started 
> brainstorming the input focus behavior [0]. That's quite useful for the 
> video player example that wants some kind of input control or a dialog 
> stick window that might not. So we'll need a way to tell which 
> subsurface gets the input focus. The way I did was enumerating methods 
> for the subsurface, like "transient" for passing away the focus and 
> "child" for a regular surface that wants it.. not a nice name, I agree.
> 
> That being said, I'm afraid that the input focus together with the 
> configuration, positing and stacking, belongs more to the shells than 
> the compositor itself, which should only control the attach -> damage -> 
> commit. Just the concept of "windows" itself doesn't sound that good for 
> a simple shell for instance, so at the moment it's being hard for me
> draw the picture why this is not an extension of the shell_surface. 
> That's why I started drafting from this other direction.

Well, my first attack on the input management would be to do nothing
special. :-)

I.e. a sub-surface and a parent surface are all just wl_surfaces, and
would not differ at all from a "window in a single wl_surface" case. On
the input side, the client would just deal with a set of surfaces
instead of one surface. It would get leave and enter events as usual,
when the pointer or kbd focus changes from sub-surface to another. If a
sub-surface wants or does not want input, the client sets the input
region accordingly. The client (toolkit) just needs to be prepared to
combine input events from the sub-surfaces, and e.g. direct keyboard
events to the "whole window" first, rather than starting with just the
one wl_surface.

On the compositor side, I would not have to modify the input code at
all.

Weston's core would not need to deal much with "composite windows", i.e.
a collection of a parent wl_surface and a set of sub-surfaces. It only
needs to maintain the associations, and maybe offer helpers like the
bounding box computation. Therefore it should not really need the
concept of a window. Window management is the shell's job, and for
instance the force-move binding is a shell feature, which can look up
and move the whole composite window, when the user tries to move a
sub-surface.

So, instead of trying to be smart about input foci between the
sub-surfaces and the parent, I would just punt that to the clients'
input handling.

I hope that works also in practice.

> Anyways, nice write-up and summary Pekka. Thanks for bringing this up!

Thank you!

> [0] http://cgit.freedesktop.org/~vignatti/wayland/commit/?h=xwm-client-OLD
>      http://cgit.freedesktop.org/~vignatti/weston/commit/?h=xwm-client-OLD

I see, right.


Thanks,
pq