[Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Alejandro Exojo]

El Tuesday 26 April 2016, Shawn Rutledge escribió:
> Personally I think event compression should be a cross-platform feature if
> we’re going to have it.  The event-pileup problem can happen also on
> Windows for example, but it seems that we never implemented event
> compression on any platform other than X11.  I’m not sure why.  But we
> don’t plan to do that in the 5.6 series, anyway.

Are you thinking in a generic event compression feature, not only for input 
events? For example, I emit a signal with a "last value" parameter with a 
queued connection (or I just post the event manually), and the receiver can 
discard previous values that it did not have time to process because it was 
slower than the sender. That's not an input event, but it happens through the 
event system anyway.

Now I would think of reimplementing QCoreApplication::notify, but there is the 
warning about Qt6 change, and there is no way to access the already posted 
events (that I know of). There are some reports asking for the feature, BTW:

https://bugreports.qt.io/browse/QTBUG-2688
https://bugreports.qt.io/browse/QTBUG-44293

I suppose if notify() was "soft deprecated" there is not that much 
time/interest in doing this?

> I was told to request this exception on the mailing list, because we
> usually try to maintain source compatibility between releases.

This change being added doesn't worry me much (I don't think it will set my 
computer on fire), so I'm not opposing to it (honestly!) but I don't think the 
issue is source compatibility. It's adding features on already released 
branches. There is a process to ensure that code released has gone through a 
testing procedure. Adding this is bypassing it, while other much innocent 
changes have to wait.

Let me point at some examples, for illustration purposes:

A one line change that fixes QPalette::resolve. It's an obvious fix, but it 
wasn't unit tested, and it changes behaviour, so who knows what might break:

https://codereview.qt-project.org/148552

A microoptimization that looks entirely safe to everyone, but it's not 
critical, so it wasn't committed to the stable branch:

https://codereview.qt-project.org/138746

A simple setter/getter/member addition to QIcon and one line addition to the 
OS X platform plugin to make the system tray icons look properly on Yosemite 
and newer. It's trivial, but it was new API, so it could not go in the stable 
branch:

https://codereview.qt-project.org/115120

Again, honestly, I don't have an axe to grind. Two of this issues affected me, 
but not a lot, and it's already solved, so no big deal now. I'm just a bit 
confused when I see this differences in interpretation of the rules, because I 
don't know what to expect and what not.

Thanks.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net