[RFC] Declare enumeration wl_output.transform as bitfield.

[Bryce Harrington]

On Wed, Nov 25, 2015 at 03:25:55PM +0000, Daniel Stone wrote:
> Hi,
> 
> On 25 November 2015 at 14:17, Auke Booij <auke at tulcod.com> wrote:
> > On 25 November 2015 at 13:43, Daniel Stone <daniel at fooishbar.org> wrote:
> >> Warnings aren't harmless though; there's a reason we don't (shouldn't)
> >> have any in our build. Every 'oh, just ignore that' warning drowns out
> >> legitimate compiler warnings, and dumping warnings on our users
> >> because we broke a stable API isn't really acceptable. So, sorry, but
> >> NAK from me. :(
> >
> > Note that this these warnings are resolvable: e.g. the weston code can
> > be fixed so that it does not generate warnings under this change.
> > (Although I understand that that is not quite sufficient.)
> 
> Sure, we can fix Weston, and with a strict version requirement on the
> protocol, we can make sure it doesn't come back. But what about
> XWayland, Mesa, GTK+, Qt/KDE, Clutter/Cogl/Mutter, GStreamer,
> Ozone/Chromium, Firefox, LibreOffice, and all the others?
> 
> > Under what conditions would you agree to this protocol change? E.g.
> > would more documentation towards developers regarding the warnings
> > help? Or some sneaky way to avoid compiler warnings?
> 
> I can't really think of a sneaky way, in all honesty: we're changing a
> prototype. Even some clever #define / #ifdef dance to opt in to the
> new behaviour doesn't help, because a protocol header may well be
> included before the #define gets set. When you consider mixing and
> matching various modules, some of which are aware of the new type
> signature, some of which aren't, there's basically no way to do it
> cleanly.
> 
> Unfortunately I can't really think of a situation where I would find
> it palatable. It is a good and correct change on the face of it, but
> unfortunately we've already encoded this bad API, and changing it will
> infuriate everyone using it downstream. I'd say just accepting that we
> can't make it a bitfield because legacy, and encoding all possible
> combinations for languages which won't let you do arbitrary binary
> operations, would be a less-bad solution.

I agree that right now is not a good time to be taking needless risks
with the API stability, especially with so many new users starting to
kick the tires and start using it for various things.

That said, it seems senseless to leave ourselves painted into a corner
for making good and correct changes to the core API.  Particularly
because a part of the reason for doing Wayland was to escape certain
painted-in legacy restrictions from X11.  I seem to recall there being
previous episodes of good ideas that couldn't be taken due to legacy
stability requirements.

Could we perhaps consider planning for some future Wayland release (like
maybe a couple years down on the roadmap?) where we can introduce some
"safe" breaks such as this?  Then we could queue them up, have plenty of
time to explore alternatives, folks can test against the changes,
etc. etc.  No surprises, no discarding good ideas, no having to endure
interface buglets in perpetuity...

Bryce

> Cheers,
> Daniel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel