Interfaces to objects

[Bill Spitzak]

On 08/09/2014 02:21 AM, Pekka Paalanen wrote:

> You may be confusing wl_shell with wl_shell_surface.

Indeed I am. Sorry about that.

> And in Weston's case, if a client does not create a
> wl_shell_surface, the shell specific data for the wl_surface really
> does not exist inside Weston, literally.

The wl_surface representation still has a pointer to the 
wl_shell_surface (set to null) so it sort of always contains it.

More to the point, I believe it would be perfectly valid for a 
compositor to be implemented as I said. I think that makes it easier to 
describe what the API is doing.

>> The client asks Wayland to create a wl_shell object, passing it an
>> existing wl_surface object. If the compositor supports wl_shell, this
>> will work. If it does not it will not work and the client gets an error.
>
> No. If the compositor does not support wl_shell, there is no
> global of kind "wl_shell" advertized, and the client simply cannot
> even attempt to use it. The error case does not exist.

You are right. Again I confused wl_shell with wl_shell_surface. And the 
"error" is that the wl_shell does not exist and is needed as an argument 
to the wl_shell_surface constructor.

>> This did not really create a new object.
>
> All that depends on what you mean by "object". It does create new
> protocol objects. It does allocate new structs inside Weston. It
> does not create a new conceptual object but just assigns more
> meaning and methods to "a surface".

Yes I meant a "conceptual object".

>> The advantage of this is that existing machinery in the Wayland API is
>> reused, rather than adding an interface query api. Keeping the low-level
>> api as simple as possible is a big win for IPC and for writing backends
>> in multiple languages.
>
> Yes, and the fundamental problem with query type of APIs is that it
> requires a round-trip.

Well you could cache the result if it is always true or false (ie it is 
known that *all* wl_surface have wl_shell_surface api). This is what is 
being done by the existence of the wl_shell object. Wayland still has 
the advantage of not adding api to support this.

I would think that if only a subset of wl_surfaces can provide the 
wl_shell_surface api then a round trip would be needed.

>> The disadvantage of this is that both the client and compositor have to
>> keep track of several id's for the same object.
>
> Again depends on what you mean by "object". The id's are always 1:1
> corresponding to the protocol objects, and libwayland-server does
> all the tracking for you. As a compositor developer, you do not
> deal with ids in 99% of the cases, and people are looking to remove
> even that remaining 1% in the libwayland-server API.

My concern is on the client end, somebody may make some useful utilities 
that need to use more than one api to a wayland object. Either it will 
create and destroy additional api objects which seems wasteful, or 
something more complex than the id has to be passed to it. This will 
probably make utilities toolkit-specific since they will probably take a 
pointer to their internal representation of a wayland object that 
includes the cached ids for all the api objects that have been created.

I don't think this is a problem that needs to be addressed yet. It is 
possible that most such utility functions only need one api. Or 
something is added to the client lib so that creation of these reuses 
existing ones so nothing is sent over the protocol except when the first 
one is created or destroyed. Or everybody will agree on a cross-platform 
data structure containing the id's.