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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
