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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
