I don't see any significant risk there. QWidget has many large commercial as well as FOSS deployments that will see it stick around for many years to come, and Riverbank's PyQt Python bindings are likewise used by many large commercial and FOSS offerings, and very actively maintained, tracking upstream Qt quite closely. I've written some PyQt apps as well (alongside lots of C++ and Qt Quick) and I think it's a very nice way to use the toolkit (in fact I'm relieved C++11 added some of the things that made using PyQt so nice).
I've been a KDE developer for the last 8 years, and in that time I've seen Qt steadily improve as an open source project. When I started out using Qt, getting code into it was essentially impossible without becoming a Trolltech employee. Today it's quite open to its various stakeholders, who manage to collaborate constructively. My confidence in Qt's resilience has increased with our level of agency in making that resilience happen.
Aye, PyQt has recently also introduced some pretty interesting new Python integration bits with the new pyqt5qmlplugin that allow you to write QML extensions in pure Python without C++ boilerplate.
Completely misleading. Have you ported a Qt Widgets project to QML? Show me the code if you have done so and I would agree that I am wrong. They are completely different code bases.
You seem to be misunderstanding my argument, which is that there's no risk to writing a QWidget app because there's no need to stop using QWidget, as QWidget isn't going away. You've yet to produce any arguments for why this isn't correct.
I don't have a reply button anymore to sho_hn's comment. Take this as a reply to the adjacent comment :)
What I am saying is: if you have a new _native_ widget in a new OS release (layout spacing, new views, new controls, new features - there are so many), it won't be implemented in the Widget code base. The Qt project will tell you to use QML. How are you going to make your C++ Widget based app look modern now when all your code is QML based?
Answer: there is no answer. The Qt project has made it extremely difficult to decide for their existing users. For new users, it's a trivial task to choose QML but how many new desktop apps are being developed from scratch these days.
Several of the things you list are the duty of the platform plugin and the style engine plugin and don't actually require any changes to the core widgets. Yay layering.
Personally I think entirely new widget classes should be accepted into the QWidgets module, but you may be right that there's some resistance to that - but the bar for new widgets has always been fairly high actually, it was a rare occurence even before QML (neither Qt 3 or Qt 4 saw much in the way of new widgets during their respective lifetime). I think the case that a lot of the "new UI challenges" are better met by QML is also somewhat legitimate, in which case there's an incentive for porting to it.
I've been a KDE developer for the last 8 years, and in that time I've seen Qt steadily improve as an open source project. When I started out using Qt, getting code into it was essentially impossible without becoming a Trolltech employee. Today it's quite open to its various stakeholders, who manage to collaborate constructively. My confidence in Qt's resilience has increased with our level of agency in making that resilience happen.