[RFC] Declare enumeration wl_output.transform as bitfield.

[Nils Chr. Brause]

Hi,

On Wed, Nov 25, 2015 at 10:01 PM, Bryce Harrington
<bryce at osg.samsung.com> wrote:
> 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?

They will continue to work just fine. Eventually their respective
developers will
notice a warning and correct their code. If not, the harmless warning does
absolutely nothing. I don't see a problem with that. :)

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

Well, better now than later. ;)

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

You mean something like Wayland 2.0?

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

Cheers,
Nils