Eike Ziller wrote: > Another good question to ask when introducing source incompatible changes, is > “how hard does it make supporting building with both Qt 5 and Qt 6 from the > same code base”. We did that for Qt Creator for quite some while, and it makes > the transition process much smoother than doing a big jump with no way back.
Agreed. You also risk ending up with a growing amount of "junk DNA" but I concur that's a lesser issue. (Thinking of that other framework known with the same 2- letter acronym which in the end was replaced by a completely new and clean "slate"). > Not sure what kind of hacks could be done for that specific case (maybe adding > a funny custom QObjectTimer class for the Qt 5 build). That was my thought too. If Qt6 moves startTimer() and killTimer() to a dedicated QObjectTimer class, code wanting to support Qt5 can simply introduce a bogus QObjectTimer class. (The Qt5 LTS releases might even do that too.) Anyway, I drop my idea of adding some kind of protection to QObject's timerEvent() method. I added a qWarning() probe to the method and realised that evidently I had forgotten that one can also handle timer events in a QObject::event() override... R. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
