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