<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 21, 2014 at 9:29 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/21/2014 04:30 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">
How do you create more than one copy of the role object in the first place?<br>
</blockquote>
<br></div>
I thought you could create any number of wl_shell_surface objects for the same wl_surface.<br>
</blockquote><div><br></div><div>No, you cannot. You get an error. Source code ref:<br><br><a href="http://cgit.freedesktop.org/wayland/weston/tree/desktop-shell/shell.c#n3415">http://cgit.freedesktop.org/wayland/weston/tree/desktop-shell/shell.c#n3415</a><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"><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

    May also be really nasty if a former object-less role is updated<br>
    with a new api that returns a role object. Now all users of that<br>
    role have to be updated to store this object they didn't use to need<br>
    so it won't get deleted...<br>
<br>
Methods don't return parameters. Clients allocate new object IDs and<br>
then pass those to the server. You cannot add new API that returns a<br>
role object without breaking API in the first place, since it's<br>
modifying the number of parameters of the method.<br>
</blockquote>
<br></div>
I am adding a new global object. Lets say that new api is added to cursors. To support this add a new wl_cursor global object that you use to create wl_cursor_surface api objects from wl_surfaces.<br>
<br>
Right now a client that uses a surface as a cursor only has to store the wl_surface (and the wl_pointer that it calls set_cursor on).<br>
<br>
But as soon as any part of the client wants to use the new wl_cursor_surface api, it creates an object that must remain in existence (and thus stored somewhere) until the wl_surface is destroyed, otherwise it will "lose the cursor role". This may require considerable rewriting of existing client code since it currently does not store this object.</blockquote>
<div><br></div><div>To use a cursor, you must already store a wl_buffer and a wl_surface, and presumably also your SHM data of the cursor. You have to put that in a struct somewhere. If you're already storing three things, storing four should not be harder.<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">It would be much easier if the client could throw away the api object after using it, the same way I throw away the result of dynamic_cast after using it. In particular if it is only going to call the api once.<br>

</blockquote><div><br></div><div>Throwing away the object means you will leak it. Do not leak objects.<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">
<div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    A client subroutine that uses a role the caller does not know about<br>
    will have to use a static map to look up cached role objects by<br>
    wl_surface id. And some scheme has to be figured out to delete them<br>
    when the wl_surface is deleted.<br>
<br>
That doesn't make any sense. What kind of client subroutine are you<br>
talking about?<br>
</blockquote>
<br></div>
One that knows about xdg_shell or ivi_shell while the caller only knows about wl_shell or wl_surface. Or knows about this new wl_cursor_surface api.<br>
<br>
</blockquote></div><br></div><div class="gmail_extra">xdg_shell, ivi_shell and wl_cursor_surface are three separate APIs for three separate purposes: that's why they're separate APIs. What kind of client API are you imagining that could act on xdg_shell and ivi_shell, but not on wl_cursor_surface?<br>
<br></div><div class="gmail_extra">I have a hard time imagining these hypothetical client APIs that you always bring up in opposition to everything, because I can't honestly imagine what you could expect them to do.<br>
<br></div><div class="gmail_extra">I'm getting really frustrated with you Bill. Have you written any Wayland code yet?<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">-- <br>  Jasper<br>
</div></div>