On Mon, 06 Oct 2014 13:09:05 +0300 Rémi Denis-Courmont <[email protected]> wrote:
> Le 2014-10-06 12:52, Pekka Paalanen a écrit : > > Could this be solved (completely?) by saying that libraries that take > > existing wl_proxy objects such that they > > a) set up listeners, or > > b) create new wl_proxies from it and set their listeners; > > need to also offer API to tell which versions of the passed in > > wl_proxies they support? > > I think that works in principles. I am not sure how easy it would be to > convince all the toolkit vendors (GTK, Qt...) to support that though. > It's not so easy for the toolkit. Currently, I'd guess they just create > a surface. Instead they would have to: > - add a Wayland-specific version parameter to the widget/whatever > factory, then Dealing out wl objects is Wayland-specific, anyway. > - obtain desired surface version from the application, Yes. > - create a new registry object, The toolkit already has one, no need for another. > - bind a new compositor with the desired version, Yes, if there is not one already. > - destroy the registry object, Not needed. > - allocate the surface with the desired version, Yes. > - destroy the compositor object. If it wants to. Also, in addition to version, such API in toolkits should define also: - if listener is already set or not, and - which event queue the wl_proxy is on when delivered, and is it allowed to change that. Well, I think the API needs to define everything about the object: (when) will the toolkit touch it; if the toolkit sets the listeners how it handles events; etc. I believe it is far from simple. It's not limited only to the immediate properties, but also who is allowed to set a role for the wl_surface, who may create associate objects like wl_viewport, and so on. Whatever will be using the "exported" wl_proxy will likely have its own requirements on these things. Going on a bit of a tangent here: There is also a further complication with events like wl_surface.enter that carry an object as an argument. To handle the argument of wl_surface.enter, the client needs to have bound to the wl_output global. Then the wl_output proxy comes in as an argument of the event, and the code handling the event needs to detect if the proxy's user_data is set by this code or some other code. If it's not set by this code, then you don't know what it is, and cannot dereference it. It is possible to bind to the same global multiple times, so each code "module" can have its own if necessary, but everyone needs to be able to detect their own user_data. Input events may carry the targeted wl_surface as an argument. There it is even more important to detect "our own user_data" in case some 3rd party component creates its own wl_surfaces without telling the toolkit. Unless the toolkit simply forbids that. Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
