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
