<div dir="ltr">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.<br><br>Building something special-case for panels seems much better than trying to implement something generic like WaylandEmbed.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 17, 2014 at 5:59 PM, Mark Thomas <span dir="ltr"><<a href="mailto:mark-wayland-devel@efaref.net" target="_blank">mark-wayland-devel@efaref.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Mon, 17 Feb 2014, Pekka Paalanen wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
On Mon, 17 Feb 2014 00:04:19 +0000 (GMT)<br>
Mark Thomas <<a href="mailto:mark-wayland-devel@efaref.net" target="_blank">mark-wayland-devel@efaref.net</a><u></u>> wrote:<br>
<br>
</div><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- The subsurface has separate focus from the main window surface. For<br>
the usual use cases of embedding like this, you'd prefer the parent<br>
surface to remain focused (or at least, appear focused) while the embedded<br>
surface is being interacted with. Not sure if this is a general feature<br>
of subsurfaces, nor what could be done about it.<br>
</blockquote>
<br></div><div class="">
set an empty input region, and the input events will fall through the<br>
surface. So you intend that the embedded client never gets input for<br>
the embedded surface directly?<br>
</div></blockquote>
<br>
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.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Did you know about the earlier attempts on this? I think you should be<br>
able to find some discussion or a proposal by searching the<br>
wayland-devel@ archives for "foreign surface" protocol, IIRC. At that<br>
time, the conclusion was to use a nested mini-compositor approach<br>
instead, which is demoed in weston clients as weston-nested.<br>
</blockquote>
<br></div>
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. :(<br>
<br>
Do you know if any code came about from the foreign surface proposals?<br>
<br>
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.<br>
<br>
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.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I see your protocol definition lacks all documentation on how it is<br>
supposed to be used and implemented. A verbal description would be nice,<br>
giving an overview.<br>
</blockquote>
<br></div>
I did try to give a quick overview in the email, but it was late last night and I may not have been clear.<br>
<br>
I've pushed some doc updates to the protocol.xml file my git repo. But<br>
in terms of Jonas Ådahl's proposal, my protocol works the other way round:<br>
<br>
A creates a main surface<br>
A creates a "hole" on that surface and sets its position and size<br>
A gets the uid (handle) from the server<br>
A passes that uid to B via IPC<br>
B creates a surface<br>
B creates a "plug" on that surface with the uid it got from A<br>
B receives a configure event from the server with the size of the hole<br>
B creates a buffer of the correct size and renders its image to the<br>
surface<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How do you handle glitch-free resizing? Sub-surfaces handle glitch-free<br>
resizing by temporarily changing the sub-surface into synchronized<br>
mode, assuring the sub-surface has new content in the correct new size,<br>
and then atomically commits the whole tree of sub-surfaces with a<br>
commit to the root wl_surface. Do you have any synchronization<br>
guarantees like that? With separate processes cooperating to create a<br>
single window it will be even more important than with the<br>
existing sub-surfaces case, and you will need more IPC between the two<br>
clients. Using client1<->client2 IPC would be more efficient than<br>
client1<->server<->client2.<br>
</blockquote>
<br></div>
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.<br>
<br>
My anticipated use case is applets inside panels, which aren't typically resized, so this implementation should be sufficient.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Have you considered if your use case could be better served by<br>
moving some functionality into a special DE-specific client (e.g.<br>
weston-desktop-shell) and having separate protocol (an alternative<br>
"shell" interface) for panel clients to tell their wl_surface needs to<br>
be embeded into the panel, rather than implementing a generic<br>
mechanism where you need to solve all corner-cases in a generic way?<br>
If the protocol extension was designed particularly for panels, you<br>
might have an easy way out by defining special resize behaviour which<br>
would avoid most client<->client negotiation.<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<br>
<br>
Thanks for your feedback.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Mark.</font></span><br>_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br> Jasper<br>
</div>