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