Inter-client surface embedding

Tue Feb 18 01:01:17 PST 2014

On Mon, Feb 17, 2014 at 10:59:11PM +0000, Mark Thomas 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 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?

Hi,

I did the previous proposal first called "logical surfaces" and then
"foreign surfaces". I had a proof-of-concept implementation, but did not
finalize nor publish it as the discussion concluded that it was not the
way forward, instead favoring the nested compositor approach.

Jonas

> 
> 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.

> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel