[PATCH wayland v4 1/5] protocol: define the concept of wl_surface role

[Jasper St. Pierre]

On Thu, Aug 21, 2014 at 9:29 PM, Bill Spitzak <spitzak at gmail.com> wrote:

> On 08/21/2014 04:30 PM, Jasper St. Pierre wrote:
>
>  How do you create more than one copy of the role object in the first
>> place?
>>
>
> I thought you could create any number of wl_shell_surface objects for the
> same wl_surface.
>

No, you cannot. You get an error. Source code ref:

http://cgit.freedesktop.org/wayland/weston/tree/desktop-shell/shell.c#n3415


>     May also be really nasty if a former object-less role is updated
>>     with a new api that returns a role object. Now all users of that
>>     role have to be updated to store this object they didn't use to need
>>     so it won't get deleted...
>>
>> Methods don't return parameters. Clients allocate new object IDs and
>> then pass those to the server. You cannot add new API that returns a
>> role object without breaking API in the first place, since it's
>> modifying the number of parameters of the method.
>>
>
> 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.
>
> 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).
>
> 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.


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.


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

Throwing away the object means you will leak it. Do not leak objects.


>     A client subroutine that uses a role the caller does not know about
>>     will have to use a static map to look up cached role objects by
>>     wl_surface id. And some scheme has to be figured out to delete them
>>     when the wl_surface is deleted.
>>
>> That doesn't make any sense. What kind of client subroutine are you
>> talking about?
>>
>
> 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.
>
>
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?

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.

I'm getting really frustrated with you Bill. Have you written any Wayland
code yet?

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