[PATCH wayland] client: add wl_proxy_get_version function

[Pekka Paalanen]

On Mon, 06 Oct 2014 13:09:05 +0300
Rémi Denis-Courmont <remi at remlab.net> 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