Inter-client surface embedding
Jasper St. Pierre
jstpierre at mecheye.net
Mon Feb 17 15:41:43 PST 2014
GtkPlug and GtkSocket are really implemented in terms of XEmbed. As we've
found, XEmbed has a surprising number of problems in real-world use cases,
so it's considered deprecated.
Building something special-case for panels seems much better than trying to
implement something generic like WaylandEmbed.
On Mon, Feb 17, 2014 at 5:59 PM, Mark Thomas
<mark-wayland-devel at efaref.net>wrote:
> On Mon, 17 Feb 2014, Pekka Paalanen wrote:
> On Mon, 17 Feb 2014 00:04:19 +0000 (GMT)
>> Mark Thomas <mark-wayland-devel at efaref.net> wrote:
>> - 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
>>> surface is being interacted with. Not sure if this is a general feature
>>> of subsurfaces, nor what could be done about it.
>> set an empty input region, and the input events will fall through the
>> surface. So you intend that the embedded client never gets input for
>> the embedded surface directly?
> I think that the embedded client should still get input as normal, however
> the surface that it's embedded within should still appear to be focussed. I
> guess this is a shell interface question, and will probably need a shell
> interface extension. I'll think about this more later on when I come round
> to writing the shell plugin that I'll undoubtedly need.
> Did you know about the earlier attempts on this? I think you should be
>> able to find some discussion or a proposal by searching the
>> wayland-devel@ archives for "foreign surface" protocol, IIRC. At that
>> time, the conclusion was to use a nested mini-compositor approach
>> instead, which is demoed in weston clients as weston-nested.
> I did not. That's quite frustrating, I could have saved myself some time.
> I went back and looked and none of the posts mentioned "embed" or
> "plug/socket" so that's why I didn't find them. :(
> Do you know if any code came about from the foreign surface proposals?
> The nested mini-compositor example doesn't build for me as I don't have
> working EGL, so I never even noticed it! Reading about it the approach
> seems to be more suited to nested application situations, e.g. a web
> browser embedding a document viewer.
> For the panel use case it seems like the wrong approach, as the embedded
> panel objects are merely fastened to the panel like badges, rather than
> part of the panel itself. It seems a shame to reimplement a compositor in
> the panel when we've already got a perfectly good compositor to use.
> I see your protocol definition lacks all documentation on how it is
>> supposed to be used and implemented. A verbal description would be nice,
>> giving an overview.
> I did try to give a quick overview in the email, but it was late last
> night and I may not have been clear.
> I've pushed some doc updates to the protocol.xml file my git repo. But
> in terms of Jonas Ådahl's proposal, my protocol works the other way round:
> A creates a main surface
> A creates a "hole" on that surface and sets its position and size
> A gets the uid (handle) from the server
> A passes that uid to B via IPC
> B creates a surface
> B creates a "plug" on that surface with the uid it got from A
> B receives a configure event from the server with the size of the hole
> B creates a buffer of the correct size and renders its image to the
> How do you handle glitch-free resizing? Sub-surfaces handle glitch-free
>> resizing by temporarily changing the sub-surface into synchronized
>> mode, assuring the sub-surface has new content in the correct new size,
>> and then atomically commits the whole tree of sub-surfaces with a
>> commit to the root wl_surface. Do you have any synchronization
>> guarantees like that? With separate processes cooperating to create a
>> single window it will be even more important than with the
>> existing sub-surfaces case, and you will need more IPC between the two
>> clients. Using client1<->client2 IPC would be more efficient than
> I don't. Sorting out glitch-free interactive resizing is delegated to the
> clients, although you can get pretty good glitchy resizing by B repainting
> whenever it receives the configure event.
> My anticipated use case is applets inside panels, which aren't typically
> resized, so this implementation should be sufficient.
> Have you considered if your use case could be better served by
>> moving some functionality into a special DE-specific client (e.g.
>> weston-desktop-shell) and having separate protocol (an alternative
>> "shell" interface) for panel clients to tell their wl_surface needs to
>> be embeded into the panel, rather than implementing a generic
>> mechanism where you need to solve all corner-cases in a generic way?
>> If the protocol extension was designed particularly for panels, you
>> might have an easy way out by defining special resize behaviour which
>> would avoid most client<->client negotiation.
> My plan was to patch Gtk3 to implement GtkPlug and GtkSocket in terms of
> this new interface and see how far that got me, so I hadn't considered that
> as an alternative. I could see that working.
> I'm going to see exactly how much mate-panel and its applets are wedded to
> the idea of using GtkPlug and GtkSocket. If I can do it with a
> mate-desktop-shell protocol extension, with minimal additional support from
> weston core, that would be ideal.
> Thanks for your feedback.
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel