Greenspun’s tenth rule of programming ( http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming [c2.com] ) says:
“Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of CommonLisp.”

From my point of view Qt with QML+javascript gets “a better implementation of CommonLisp”.
I wrote lots of stuff in lots of different programming languages and as soon as you develop something complex enough you end up having lots of high performance modules and “something to mix-match them on the flight” (macros, an interpreter, setup files for different configurations with their own “custom syntax and semantics”, etc. etc.).

QML+javascript is perfect for that; it allows to “script the GUI” and lots of other things without having to reinvent the wheel.
The only thing I think is still missing is the capability to “pre-optimize or compile to C++” QML and Javascript code to improve performance on embedded devices.

QML is not considered good for desktop apps yet, so don’t worry! QtWidgets remain available and functional in Qt5, and they are unlikely to ever go away. QtQuick gets much more attention, true, because it’s really new, shiny and powerful.

To be honest, I used to share your uneasiness about Qt’s direction, but it all vanished now – after I’ve tried QML and followed development discussions on Qt mailing lists. Qt in NOT becoming QML/JS framework, it’s just another tool made available to developers, as a parallel player to console and widgets. Also, it offers powerful connection of QML and C++, so not all logic has to be in JS. For Qt5, QML is not the only thing that gets an update – a lot of internals of QtCore are seeing big changes (new regexp engine, new QUrl implementation, full QPA integration, and many more), as well as other modules.

@L.MCH – sort of optimisation will come with Qt5, where V8 is used as JS engine (and that means JIT will be used).

Regarding C++/QWidgets I’m still not too optimistic. According to Qt Modules’ Maturity Levels in the wiki, the “widget classes like QPushButton, QLineEdit, etc.” are marked as done, meaning

Let me remind you that Done is not Deprecated! Done really means “stability and zero regressions are the most important things, so we are not adding features and we are not working on improving performance, but it’s fine to use this code”.
[emphasis by me, v.]

I cannot see a bright future for widget classes in that statement.

It reads to me: Ok, use it if you need, but don’t expect too much and basically you might be on your own some time in the future, when we loose interest in it as it’s not the hot new stuff, but the old crap… Let’s cross fingers that I’m wrong.

There were numerous discussions on mailing lists regarding module statuses. The general consensus is that… descriptions of maturity levels are not the most fortunately chosen! In most cases, “Done” was given just to show that:

• a module is feature-rich and more or less bug-free
• there is no active maintainer under Open Governance

That’s it. It does not mean “we will never going to do anything in this module, ever”. What it means is “it’s OK for now, but we don’t have anyone to take it further”. Time and time again, maintainers on MLs repeated: “if anyone with a good set of ideas, and nice record of positive contributions to the project steps up, we can change status from “Done” to “Active/Maintained”.” (OK, this is not an actual quote, but sort of a summary of what was being said).

Even “Deprecated” modules are not doomed. In most cases (QtSvg, for example) it’s just that module’s quality is not good enough to mark it as “Done”, but – again – if anyone willing to take the job volunteers, it may be brought back to life at any time.

I can post some links to relevant discussions, but that’s probably a bit too much (usually, they were very, very long ;) ).

It just adds my impression that, communication wise, the move to Qt 5 is a plain disaster. What has been announced more or less officially is old or outdated (cf. blogs on various sites) or scares the old and abiding developers (in the sense of using Qt, not developing the libs itself). The summary on the discussion of “done” just adds to that overall impression: there is plain no interest in further development of C++ based widgets.

Back to communications again: I don’t have time nor interest to follow the mailing lists, as have many other devlopers too. It’s up to the Qt Project to setup sufficient communication channels, it’s not the duty of the users to search for the bits and parts somewhere deep in the internets when a project changes processes, responsibilities and goals that much.

Back to widgets: Oh yes, someone can step up and take maintainership in that part. But who should take that enormous task? It’s a very big module where you need excellent knowledge of the internals to be able to fill that position properly. I cannot see anyone outside the current Nokia/Troll crew for that.

In the end, I have the fear that widgets support in Qt 5 takes the same way as Qt3Support took in Qt 4: It’s still there, but less than a second class citizen nowadays. Yes, I’m very pessimistic on that. And until the Qt Project takes efforts to prove the opposite, I continue to expect the worst. This way I won’t be disappointed.

Again: this is a communication disaster, lasting from before last years’ developers’ summit up to now…

Sadly, you are 100% right here, Volker. I’ve even raised the subject of outdated documents on ML once, but there was not much response. Recently, some new wikis are arriving on qt-project.org, though, so hopefully it will get better. Also, amount of approvers and maintainers from outside Nokia is on the raise, as well as amount of commits – projects seems to be gaining steam.

I don’t share the pessimism, but I might be proven to be very wrong here. We will see how it goes.

Absolutely agree with Volker! It will be really a shame if only QML with more high level languages gets a focus. Looks like focus have got a kiddie-coders for coding their shiny iThings… But what about real Tasks? Where is a lot(A LOT) code to be optimized and developed in Qt. IMHO ;)

While I agree with Volker I don’t feel pessimist about Qt and I don’t have doubts about C++ programming with Qt. C++ is a great language, one that has been used and will be for a lot of time. The way I understand QML is that it is a kind of very successful binding for Qt, but the core implementation remains C++ based. So, even if widgets are marked as done, I believe they will naturally evolve with the framework. Of course I could be wrong.
Now the real discussion seems to me if <commercial partner here> will lead the choice of the tools developers have to use. Do not forget that there are whole communities based on Qt efforts, like KDE, that even if are proposing QML approaches (e.g., Plasma Qhick), have their core still based on C++ and Qt. I think such communities should actively jump in in order to provide much more good reasons to choose one way or another or both.

I don’t talk about nuking away C++ entirely. That will be needed in the backend for QML/Quick applications too. It’s just about the standard QWidgets, as we all know it for ages now. I just have the fear that they don’t get that much love that they need to satisfy developers’ needs (in the sense of developers using Qt).

QML is really cool stuff, no doubt. But it is far away from being ready for the Desktop. And it will take years for QML Desktop Components to be as mature as the traditional widgets are nowadays. In the meantime, we have to bridge the gap, and for most big projects this will be using the old style widgets.

Yes, the code base out in the wild using Qt widgets/C++ is huge. Really huge. But what’s that worth if the hackers developing Qt don’t have interest to do more than bugfixes that make automatic testing shut up and some more or less critical bug once in a while? Are we developers using Qt supposed to support us ourselves? Here, you have the source code, we’re open government, you can submit a patch? That’s a bit too easy and lazy of a way to go. And I don’t want to talk about that patches being accepted in the end or not. That’s a different story that can lead to big frustration too, but that’s for a separate thread.

Volker wrote:

I don’t talk about nuking away C++ entirely. That will be needed in the backend for QML/Quick applications too. It’s just about the standard QWidgets, as we all know it for ages now. I just have the fear that they don’t get that much love that they need to satisfy developers’ needs (in the sense of developers using Qt).

QML is really cool stuff, no doubt. But it is far away from being ready for the Desktop. And it will take years for QML Desktop Components to be as mature as the traditional widgets are nowadays. In the meantime, we have to bridge the gap, and for most big projects this will be using the old style widgets.

Yes, the code base out in the wild using Qt widgets/C++ is huge. Really huge. But what’s that worth if the hackers developing Qt don’t have interest to do more than bugfixes that make automatic testing shut up and some more or less critical bug once in a while? Are we developers using Qt supposed to support us ourselves? Here, you have the source code, we’re open government, you can submit a patch? That’s a bit too easy and lazy of a way to go. And I don’t want to talk about that patches being accepted in the end or not. That’s a different story that can lead to big frustration too, but that’s for a separate thread.

Yes, Volker has some good points set here! As much as I love developing using C++/Qt and QWidgets, I am very sceptical on the above points as well!

Volker wrote:

Here, you have the source code, we’re open government, you can submit a patch?

I’ve tried to use one open-source dev tool/framework, and their attitude was exactly like you suggest. When I asked for a bug fix or a feature, to make that tool more compatible with Mac OS X, their response sounded more like “Would you shut up at last, please? You have the source code, do this yourself. Don’t bother us. We are happy drinking bear and coding the stuff that we want to code. We don’t care what you need.”

I don’t like bear, I like red wine. I don’t like open source dev tools, I like reasonably priced commercial tools :-)

serkol: I hope you did not get such a response from a troll!

No, it was not from a TROLL, neither from a troll :-)

This was before I looked at Qt. I hang out in that tool’s forum for a couple of months. It’s not a specific response, but their general attitude. They always sounded bothered when someone asked for a bug fix or a feature in some area that was not interesting for them. And they always gave the same response – you have the source code, do this yourself. Sometimes their response was more polite, sometimes less, but always the same meaning.

Well, you do have the option to stop whining and get a commercial Qt contract from Digia, or pay any of the Qt support-offering companies to maintain the parts of Qt that are critical for you. I really wonder why you ask Nokia to invest in supporting technology they have less interest in. Nokia’s stake is obviously in selling huge numbers of phones and perhaps other gadgets. That requires technolgies like QML, not widgets. Meantime, they are giving away a great toolkit that helps us all and provides many of us a decent income. I’m not complaining here.

Personally, I think that Digia will need to step up in the qt project. They are starting to, but I think they are the ones who should take up maintainership of Qt Widgets.

Andre wrote:

Well, you do have the option to stop whining and get a commercial Qt contract from Digia

This is exactly what I want to do, when/if they resolve the incompatibility with Mac App Store and Mac OS sandboxing, and if the price is reasonable. I haven’t even asked them about the price yet, because they have promised to resolve the App Store and sandboxing issues, but they have not done this yet.

Andre wrote:

stop whining

I immediately recognize the language from that tool’s user group. Are you involved into a open-source project by chance?

Andre wrote:

I really wonder why you ask Nokia

Who is talking about Nokia? I have shared my experience with some open-source project that is not related to Nokia. Did you read my post at all?