Interfaces to objects

[Bill Spitzak]

On 08/11/2014 03:03 PM, Jasper St. Pierre wrote:

> wl_shell does exist. It's a global object that is bound by the client,
> using wl_registry.bind. It's as real as any other object.

What I meant was that the wl_registry::global event with the wl_shell 
api was not sent if the compositor does not implement the 
wl_shell_surface api. This makes it impossible to bind an id to the 
wl_shell surface api.

Since there is no id that can be used in the wire protocol to get the 
wl_shell::get_shell_surface request, it is as though the wl_shell object 
does not exist.

> Even if wl_shell exists, that does not mean that all wl_surfaces are
> also wl_shell_surfaces. Cursor surfaces are also wl_surfaces, and those
> are not wl_shell_surfaces. Subsurfaces are also wl_surfaces, and those
> are not wl_shell_surfaces.

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.

> Why are additional objects more expensive?

Creation and destruction sends requests over the wire protocol. To avoid 
this you must keep them around after first creating them, rather than 
creating them when needed.

> Why would you need cross-platform data structures, and why do you
> believe that the internals of the data structure has anything to do with
> the wire format? Multiple toolkits and Wayland compositors exist, and
> they all have entirely different internal data structures. They all
> collaborate fine.

For utility functions that are used by more than one toolkit.