<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 11, 2014 at 7:10 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>On 08/11/2014 03:03 PM, Jasper St. Pierre 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">
wl_shell does exist. It's a global object that is bound by the client,<br>
using wl_registry.bind. It's as real as any other object.<br>
</blockquote>
<br></div>
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.<br>


<br>
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.<br>
</blockquote><div><br></div><div>OK, sure. It's never going to come across as an error on the wire, though. It's just never going to find the global, and likely spew an error message to the user and die, or spin forever waiting for it to show up.<br>
<br></div><div>You weren't clear 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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


Even if wl_shell exists, that does not mean that all wl_surfaces are<br>
also wl_shell_surfaces. Cursor surfaces are also wl_surfaces, and those<br>
are not wl_shell_surfaces. Subsurfaces are also wl_surfaces, and those<br>
are not wl_shell_surfaces.<br>
</blockquote>
<br></div>
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.<br>
</blockquote><div><br></div><div>wl_display has an 'error' event which is required to be a fatal error to the client. For subsurfaces, it will send out an error telling you that the surface already has a role. I don't think Weston will send out errors if you have a surface that has the role of the cursor, simply because it's not really marked as a surface role internally. This is a Weston bug that we should fix.<br>
<br></div><div>We're talking about standardizing on role behavior in the xdg-shell thread.<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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Why are additional objects more expensive?<br>
</blockquote>
<br></div>
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.<br>
</blockquote><div><br></div><div>The expected use case for surface roles is to create them immediately after the wl_surface, as right now you cannot repurpose a surface as a different role.<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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Why would you need cross-platform data structures, and why do you<br>
believe that the internals of the data structure has anything to do with<br>
the wire format? Multiple toolkits and Wayland compositors exist, and<br>
they all have entirely different internal data structures. They all<br>
collaborate fine.<br>
</blockquote>
<br></div>
For utility functions that are used by more than one toolkit.<br>
</blockquote></div><br></div><div class="gmail_extra">Can you give an example for this? We've talked about adding more utility methods like libwayland-cursor. That we do without standardizing on internal data structures right now.<br>
</div><div class="gmail_extra"><br>-- <br>  Jasper<br>
</div></div>