Interfaces to objects

[Jasper St. Pierre]

On Mon, Aug 11, 2014 at 5:05 PM, Bill Spitzak <spitzak at gmail.com> wrote:

> 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.
>

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.

Please write some software that uses Wayland before you say wrong stuff on
the mailing list. Otherwise, you're just embarrassing yourself, here.


>  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.
>

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.

Please write some software that uses Wayland before you say wrong stuff on
the mailing list. Otherwise, you're just embarrassing yourself, here.


> 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


Why are additional objects more expensive?

, or something more complex than the id has to be passed to it.


I don't know what this means.


> 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.
>

What? The ID is what's spoken over the wire. All a wl_proxy is is an ID,
the type of object that you have, and the listener for events.


> 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.
>

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.

Please write some software that uses Wayland before you say wrong stuff on
the mailing list. Otherwise, you're just embarrassing yourself, here.

_______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140811/d2155054/attachment-0001.html>