Hi Jason, we have a single process managing all the tabs so this is not an option in this case. Thanks for the suggestion though. Regards, Iago
On Thu, 2014-01-30 at 05:39 -0600, Jason Ekstrand wrote: > Yeah, Pekka pretty much covered it. I've just got one more > observation to add. Are you doing one process per tab? Or do you have > one process handling multiple tabs? If you have one process per tab, > then you can easily differentiate by which wl_client the surface is > attached to. You can know which client is which because (I assume) > you should be launching them privately and manually creating the > wl_client objects. > > Thanks, > --Jason Ekstrand > > On Jan 30, 2014 5:35 AM, "Pekka Paalanen" <ppaala...@gmail.com> wrote: > On Thu, 30 Jan 2014 10:32:03 +0100 > Iago Toral <ito...@igalia.com> wrote: > > > Hi, > > > > in the process of porting webkitgtk+ to wayland and > following advise > > provided here, I implemented a nested compositor to share > surfaces > > between the two processes that do the rendering. This works > fine with > > a single widget/surface, but things get a bit more > complicated when > > dealing with various widgets (browser tabs, windows). > > > > I am trying to understand if I can solve my problem, which > is > > basically a problem of matching wayland surfaces created in > the > > nested compositor with their corresponding widgets in the > UI, within > > the scope of the wayland protocol or if I need to resort to > ad-hoc > > communications between the two processes outside the > protocol. Below > > I describe the problem in more detail together with the > possible > > solutions I looked into and my conclusions. I'd appreciate a > lot if > > someone could confirm whether these are correct: > > > > As far as I understand the code in the nested client example > from > > Weston, when there is need to repaint the UI it goes through > all the > > surfaces in the compositor and paints them one by one. In > our case, > > when GTK needs to repaint it will go through the widgets in > the UI > > and ask them to repaint as needed. This means that we need > to know, > > for a given widget, which is the surface in the nested > compositor > > that provides the contents for it. > > > > However, when the nested compositor receives a request to > create a > > surface it will not know for which widget it is creating it > (obviously > > information on things like UI widgets is outside the scope > of the > > wayland protocol), and as far as I can see, there is no way > for the > > client to provide this info to the compositor either when > the surface > > is created or after it has been created. > > > > Assuming that this is not something I can so using available > APIs, I > > looked into adding this API to my nested compositor > implementation, > > so I can have a surface constructor like this: > > > > wl_compositor_create_surface_for_widget(struct > wl_compositor*, int); > > > > where that additional 'int' parameter would be used on the > > compositor's side to associate the new surface with a > specific UI > > widget. > > > > Unfortunately, for this I would really want to reuse > existing code and > > APIs from wayland to do message communication between client > and > > compositor, but a good part of this is private to wayland > (the > > wl_closure stuff for example) so it feels like I would end > up having > > to duplicate quite some code from Wayland in WebKit, which I > think is > > really not a good idea. Also, the fact that these APIs have > been kept > > internal to Wayland means that this is not something that > developers > > are expected to do. > > > > If the above is not a good solution either, I understand > there would > > be no solution for my problem within the wayland protocol > and I would > > need to add additional messages between the two processes > outside the > > protocol after the surface is created in order to associate > the > > surface and the widget on the compositor's side. In that > case, I > > would need to communicate the widget ID and the ID of the > Wayland > > object representing the surface (which I understand I'd get > by > > calling wl_proxy_get_id on the client for the surface). > > > > Is my analysis of the problem correct or is there some way > in which I > > can achieve my objective within the wayland protocol? > > Hi, > > the short answer to your solution is "write a custom shell > extension". > > That means that you would be writing your own private Wayland > protocol > extension in the same XML format as all Wayland protocol is > already > defined. Let's take xdg_shell as an example: > http://cgit.freedesktop.org/wayland/weston/tree/protocol/xdg-shell.xml > > A compositor advertises a global object of type xdg_shell. The > xdg_shell interface has two requests that allow you to add > meaning to > wl_surfaces: get_xdg_surface and get_xdg_popup. These requests > associate additional information to the given wl_surface, and > create a > new protocol object to allow manipulating the new features > added to the > wl_surface object. > > If all you need to do is to associate an integer ID to a > wl_surface, > you could define a new global interface with a single request, > that has > a wl_surface and the ID as arguments. If you need more, you > can add > more like xdg_shell does. There are also many other examples > of how > wl_surface can be extended with the help of a new global > interface. > > This new global interface would be advertised by the nested > compositor > only, and the clients of that compositor would be using it. > No-one else > would ever see it. The clients would use the standard > wl_compositor to > create standard wl_surface objects, and then add new meaning > to them > with your extension. > > Does this help? > > Btw. do not write an extension that has a new request to > create > wl_surface objects, or any objects that are already creatable > via other > interfaces. Doing so would lead to interface versioning > problems, as > explained in: > http://wayland.freedesktop.org/docs/html/sect-Protocol-Versioning.html > > > Thanks, > pq > _______________________________________________ > 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