<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 11, 2014 at 5:05 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">On 08/09/2014 02:21 AM, Pekka Paalanen wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You may be confusing wl_shell with wl_shell_surface.<br>
</blockquote>
<br></div>
Indeed I am. Sorry about that.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
And in Weston's case, if a client does not create a<br>
wl_shell_surface, the shell specific data for the wl_surface really<br>
does not exist inside Weston, literally.<br>
</blockquote>
<br></div>
The wl_surface representation still has a pointer to the wl_shell_surface (set to null) so it sort of always contains it.<br>
<br>
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.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

The client asks Wayland to create a wl_shell object, passing it an<br>
existing wl_surface object. If the compositor supports wl_shell, this<br>
will work. If it does not it will not work and the client gets an error.<br>
</blockquote>
<br>
No. If the compositor does not support wl_shell, there is no<br>
global of kind "wl_shell" advertized, and the client simply cannot<br>
even attempt to use it. The error case does not exist.<br>
</blockquote>
<br></div>
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.<br></blockquote><div><br></div>
<div>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.<br><br>Please write some software that uses Wayland before you say wrong stuff 
on the mailing list. Otherwise, you're just embarrassing yourself, here.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

This did not really create a new object.<br>
</blockquote>
<br></div><div class="">
All that depends on what you mean by "object". It does create new<br>
protocol objects. It does allocate new structs inside Weston. It<br>
does not create a new conceptual object but just assigns more<br>
meaning and methods to "a surface".<br>
</div></blockquote>
<br>
Yes I meant a "conceptual object".<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

The advantage of this is that existing machinery in the Wayland API is<br>
reused, rather than adding an interface query api. Keeping the low-level<br>
api as simple as possible is a big win for IPC and for writing backends<br>
in multiple languages.<br>
</blockquote>
<br>
Yes, and the fundamental problem with query type of APIs is that it<br>
requires a round-trip.<br>
</blockquote>
<br></div>
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.<br>
</blockquote><div><br></div><div>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.<br>
<br>Please write some software that uses Wayland before you say wrong stuff 
on the mailing list. Otherwise, you're just embarrassing yourself, here.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

The disadvantage of this is that both the client and compositor have to<br>
keep track of several id's for the same object.<br>
</blockquote>
<br></div><div class="">
Again depends on what you mean by "object". The id's are always 1:1<br>
corresponding to the protocol objects, and libwayland-server does<br>
all the tracking for you. As a compositor developer, you do not<br>
deal with ids in 99% of the cases, and people are looking to remove<br>
even that remaining 1% in the libwayland-server API.<br>
</div></blockquote>
<br>
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</blockquote><div>
<br></div><div>Why are additional objects more expensive?<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">, or something more complex than the id has to be passed to it.</blockquote>
<div><br></div><div>I don't know what this means.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
</blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

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.<br>
<div class=""><div class="h5"></div></div></blockquote><div><br></div><div>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.<br>
<br>Please write some software that uses Wayland before you say wrong stuff 
on the mailing list. Otherwise, you're just embarrassing yourself, here.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><div class="h5">
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.<u></u>freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>  Jasper<br>
</div></div>