Interfaces to objects

[Pekka Paalanen]

On Mon, 11 Aug 2014 16:50:10 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> On 08/11/2014 04:19 PM, Jasper St. Pierre wrote:
> 
> >     What exactly happens if you call wl_shell::get_shell_surface with
> >     one of these? It does not do a round trip so it cannot fail.
> >
> > wl_display has an 'error' event which is required to be a fatal error to
> > the client. For subsurfaces, it will send out an error telling you that
> > the surface already has a role. I don't think Weston will send out
> > errors if you have a surface that has the role of the cursor, simply
> > because it's not really marked as a surface role internally. This is a
> > Weston bug that we should fix.
> >
> > We're talking about standardizing on role behavior in the xdg-shell thread.
> 
> That seems like it will work. The client is forced to keep track of the 
> subclass, but it appears the way things are being designed this is 
> always possible (there is no call that can return an unknown subclass of 
> surface). And it avoids the temptation to rely on round-trips to 
> implement this.
> 
> >     For utility functions that are used by more than one toolkit.
> >
> >
> > Can you give an example for this? We've talked about adding more utility
> > methods like libwayland-cursor. That we do without standardizing on
> > internal data structures right now.
> 
> void do_cool_thing_with_surface (???)
> {
>    wl_surface_foo(???, args);
>    wl_shell_surface_bar(???, args);
> }

That is simply a broken design of that helper function. It likely also
is an API layering violation. We need a real use case as an example
here, before discussing anything like that makes any sense. Not
something you can make up, but something that actually has a use.

The obvious solution to that is to pass all the related wl_proxies to
the function, not just wl_surface. That also explicitly documents, that
the function is messing with more than just the wl_surface state.

But this is also bad design from another point of view: there is no way
for the caller to query the state of the objects after the call. So if
both the caller and the callee manipulate the same set of state, there
can be clashes.

> It would be nice if the caller did not have to know whether this 
> function used wl_surface or wl_shell_surface api. Also an api that 
> forces both of them to refer to the same surface would help.
> 
> This might be clearer if wl_shell_surface was replaced with 
> wl_obscure_new_compositor_feature_that_caller_does_not_know_about.
> 
> I am being somewhat vague, as I am unsure if this is really a problem. 
> It is quite possible that all useful utilities only use a single api. My 
> preferred solution, if this is really a problem, is to add some kind of 
> caching of wl_proxy objects to the client library so you can always find 
> one created from another.

Such caching has so many nasty corner-case problems, that I will
outright NAK all attempts to add any such thing into libwayland-client.

It is *much* more clear, obvious, and reliable to just create a new
wl_registry when a library needs access to a global interface.
Caching actual protocol objects OTOH is simply a broken idea on more
than one way.

The preferred single API entity is defined by libwayland-client, i.e.,
all objects are wl_proxy behind an opaque typecast just for type safety.


Thanks,
pq