Interfaces to objects

[Bill Spitzak]

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);
}

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.