Inter-client surface embedding

[Mark Thomas]

As part of my current attempts to get MATE fully working on Wayland, I was 
planning to take a look at porting mate-panel this weekend.  However, I 
pretty quickly hit the first snag, which is that Gtk on Wayland doesn't 
support the GtkSocket/GtkPlug interface, which mate-panel relies heavily 
upon.

This is because Wayland doesn't understand the idea of linking different 
clients' surfaces together, so I've had a first pass at implementing an 
interface that lets you do that.

My changes are available in github at

 	https://github.com/markbt/weston/tree/embed

I'd be interested to hear what people think.

I've got it working with a couple of toy clients, so I think the theory is 
sound, but there are a few niggles to work through.

What works:

   - Clients can create one or more "hole" objects on a surface.  This 
gives them a "uid" (32-bit number) which they can pass to other clients of 
the same wayland server (e.g. via a socket, D-Bus, etc.).  For the toy 
apps you do this manually.

   - Other clients with the uid in hand can create a "plug" that attaches 
to that hole.  This effectively creates a subsurface of the other client's 
surface.  (In fact, internally a plug is a weston_subsurface with a couple 
of extra fields in use).

   - The hole can have a position and size set.  The size is notified 
to the "plug" client who is expected to conform to it.  Currently there's 
no policing of this, but I expect a more robust implementation would want 
to.

   - Either side can tear down the connection between the two.  If the 
hole goes away, or the hole's client calls "remove" on the hole, then the 
plug client receives a "removed" event.


What needs some work:

   - The subsurface has to be unsynchronized, otherwise the plug client's 
updates don't render unless the hole client is also updating.  Not sure 
how this will work with nested subsurfaces if synchronization is 
inherited.

   - The subsurface has separate focus from the main window surface.  For 
the usual use cases of embedding like this, you'd prefer the parent 
surface to remain focused (or at least, appear focused) while the embedded 
surface is being interacted with.   Not sure if this is a general feature 
of subsurfaces, nor what could be done about it.

   - The toy examples are quite rapidly thrown together and so aren't 
particularly good.  Improvements gladly welcomed.

   - The interfaces are incomplete (and undocumented, sorry).

   - There's probably a bunch of other things I've not thought about.

-- 
Mark.