On 2021 Jan 27, at 16:39, Volker Hilsheimer <volker.hilshei...@qt.io<mailto:volker.hilshei...@qt.io>> wrote:
On 10 Dec 2020, at 09:48, Lars Knoll <lars.kn...@qt.io<mailto:lars.kn...@qt.io>> wrote: On 9 Dec 2020, at 18:49, Thiago Macieira <thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>> wrote: On Wednesday, 9 December 2020 02:00:29 PST Benjamin TERRIER wrote: Back to the topic, wouldn't it be acceptable to break BC before 6.2 release? I mean Qt 6 isn't really complete until 6.2, so if a break is required it kind of makes sense to make it happen before everyone has made the switch from Qt 5 to Qt 6. That would effectively mean 6.0 and 6.1 are duds and should not be used. We should have called them 5.98 and 5.99 then. No, we either break BC before May 2021, before adoption really starts, or we wait until 2025. Anything in-between is not acceptable. I agree with that. If we have good enough reasons, we can consider this for 6.1, but I would not want to do it after that. But we can of course consider shortening our time between major releases. As Volker mentioned, we were doing major versions more often in the past, and 3-4 years instead of 7-8 is something we should really consider. Cheers, Lars Hey, Lars and I reviewed the issues that are linked to https://bugreports.qt.io/browse/QTBUG-89157 and we believe that none of those issues provide a strong enough reason for breaking binary compatibility in Qt 6.1: * QTBUG-89090: we have lived with those issues through Qt 5 * QTBUG-89423: breaking SC by marking QStandardItemModel::data (and other overrides where a multiData reimplementation exists) as final might be an option; that doesn’t break BC. Otherwise, documenting the issue in affected classes. * QTBUG-89428: not a new problem * QTBUG-89439: not a new problem; can be solved through an API that maps coordinate systems * QTBUG-89199: so far just a theoretical problem * QTBUG-87465: seems to be solvable by adding setters to the item-widget classes * QTBUG-89205: security relevant, but proposed “Take 2” solution seems adequate * QTBUG-90327: API convenience; it should be possible to solve this with documentation There’s no question that it would be nice if we could address all these issues. But as long as they are all just “nice to have’s”, it doesn’t seem justified to break our established BC promise with Qt 6.1. However, the discussion is still open, and if you disagree with our conclusion, please speak up soon, and ideally prepare a patch with a proposal that addresses the problem. Feature freeze is in a few days, and we’ll start the header review soon after that, by which time we need to close this discussion. I really want to get https://codereview.qt-project.org/c/qt/qtdeclarative/+/329814 in. If you subclass QQuickItem and want to handle mouse events, you need to override several virtual functions. Wheel events? One more. Touch events? One more. QTabletEvents? We didn’t add a new virtual function for those at all. But those events are enough alike that with the new QPointerEvent/QEventPoint API, you could deal with them in a mostly device-agnostic way in some cases (i.e. if you are trying to click a button, does it really matter which device the press and release come from?), and I’d like to encourage users to start doing that. QTBUG-86165 is a case like that: touch events are easy to deal with, and they didn’t want to override several virtual functions to handle mouse events, so they decided to rely on touch->mouse synthesis (!) which is rarely used, and stuff goes wrong. Yes you can subclass QQuickItem and override event(), and deal with all events in one place, but it’s probably hard to convince users to really do that: they will assume that it’s a niche solution, too much responsibility, too much of a firehose. QTBUG-90296 basically just states the same idea.
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
