Inter-client surface embedding

[Mark Thomas]

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 embedded
>> 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
     surface

> 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
> client1<->server<->client2.

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.

-- 
Mark.