On Tue, Apr 21, 2020 at 11:50:27AM +0300, Pekka Paalanen wrote: [...] > > > If you're asking if the implementation for version < N could be > > > deleted or avoided, then I'd say no. Definitely no for desktop > > > compositors, probably no for anything else public. > > > > The sub-interfaces are inseparable from the seats, that's set in stone. The > > question here is less about mixing versions within the seat but more > > about skipping versions without harm. Let's say wl_pointer version 9 > > introduces wl_pointer.pressure, something independent of anything else > > else in the wl_pointer interface. Qt (iirc) never implemented axis_discrete > > handling but it let's say it wants support for pressure. > > > > Guaranteed backwards compatibility means Qt can bump to version 9, implement > > noop functions for axis_source and axis_discrete and done. > > > > Allowing events to change between versions means that Qt now also needs to > > update its handling of whatever changed between those versions, e.g. > > wl_pointer.axis. A direct jump past versions you don't care about isn't > > possible. > > I would say that the direct jump past versions is never possible. Like > you said, Qt still needs to implement the noop functions. If it > doesn't, it will crash when those events get sent. The fact that making > those new functions noop is ok is just a detail, an accident of design. > Qt must come with a valid implementation - what a valid and workable > implementation is, is just a detail. > > > Also, having written the patches to change wl_pointer.axis_discrete to a 120 > > base value there's another issue: no auto-generated FOO_SINCE_VERSION > > because this doesn't show up in the protocol itself. So this really flies > > under the radar and you just have to know about it by reading the > > documentation. > > Was that one of the breaking changes already done in the past?
so, checking the two examples Simon mentioned: - wl_data_offer.accept: semantics changed from "yes, I can receive this type" to "I have received and processed this type and I'm done now". - xdg_output.description: event was only sent once, changed to sent multiple times. Notable: xdg_output is still officially unstable anyway. So a change in message semantics and how often a message can be received but not in the actual data delivered. Not directly comparable to a potential change in the value ranges of an event. > Sounds to me like it's just one more reason to not change existing > message semantics, and add new messages instead. > > Maybe one possibility with e.g. wl_pointer, if you actually want to > shed the old cruft, is to create interface wl_pointer2 and add > get_pointer2 request to wl_seat. We will never be able to get rid of > the original wl_pointer interface or its implementations, but at least > it would be clearly separate. Good point, but I don't think it's worth it. For something that's moving more frequently this may help, but I don't anticipate a lot of wl_pointer changes. So this would require double the boilerplate everywhere whith very little benefit. Cheers, Peter _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
