On Thu, Aug 21, 2014 at 9:29 PM, Bill Spitzak <spit...@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
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
