On Wed, 17 Sep 2014 22:35:40 +0200 Jonas Ådahl <[email protected]> wrote:
> On Wed, Sep 17, 2014 at 11:16:06PM +0300, Giulio Camuffo wrote: > > 2014-09-17 23:11 GMT+03:00 Jonas Ådahl <[email protected]>: > > > On Wed, Sep 17, 2014 at 10:56:13PM +0300, Giulio Camuffo wrote: > > >> I haven't looked at the implementation yet, just at the protocol, but > > >> isn't _wl_pointer_lock.lock_pointer() returning a new wl_pointer a > > >> problem? Objects should have a unique factory interface, or else the > > >> version of the interface can't be determined. > > > > > > Is it really? In the implementation below, the wl_pointer object gets > > > the same version as the wl_pointer object that is locked. It is also > > > specified in the last paragraph of _wl_pointer_lock.lock_pointer. > > > > Mmh, then maybe it is fine. I'm not convinced actually, but I'm too > > tired now. :) No, it's not fine. You cannot define exceptions to the versioning rules in a protocol spec. We have common code in libwayland handling all runtime versioning, and you just cannot implement any exceptions. > > > Also, this would not be the first interface that creates objects that > > > other interface do as well. For example wl_shm_pool.create_buffer and > > > wl_drm.create_buffer both create wl_buffer's. > > > > Yes, indeed wl_buffer and wl_callback version can't be increased, afaik. wl_buffer and wl_callback are indeed the special cases, the version of these interfaces can never be bumped, which means they are frozen for all eternity. That is somewhat of a design mistake. You definitely do not want to be repeating that mistake. > Then, another example, (of a non-final protoc though): > wl_input_method_context.grab_keyboard vs wl_seat.get_keyboard, both > creating wl_keyboard objects. I think that is a protocol design bug. wl_keyboard in core is already at version 4, but you can only create wl_keyboard version 1 via wl_input_method_context. You cannot bump wl_input_method_context version without starting to get wl_keyboards of higher version. The actual problem comes, when you bump input-method interface version beyond what is currently the highest version of wl_seat, and then someone adds a new thing to wl_keyboard. Input-method would start dealing out wl_keyboard automatically with the new wl_keyboard thing without clients or servers ever implementing the support for the new thing. Thanks for pointing it out, bug filed: https://bugs.freedesktop.org/show_bug.cgi?id=84034 Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
