Digia To Spin Off Qt Business Into Its Own Company

[pipe13]

You've misunderstood. Qt is all about C++, and also QML (the Javascript like part) is usually used together with C++ in all but the more simpler apps. What is meant is that Qt Widgets is stable, capable and does not need big new features by itself. Qt Core, Qt Gui and other core modules are continued to be heavily developed and their new features will be used also by Qt Widgets wielding apps. And of course nothing prevents bringing new features to Qt Widgets either, but maybe currently all desktop app developers are happy with the state of Qt 5, as many are porting to it now.

Correct me if I'm wrong.

Believe me, I would if you were but alas...
Compiled qtcreator against 5.3.1 from git after the 3.2 RC1 announcement, and grabbed EmacsKey.kms -- it isn't in git yet -- from http://vxlabs.com/2014/06/25/getting...creator-3-1-2/. It ain't Emacs (and ain't supposed to be) but at least I'm no longer stumbling over every key binding. Glad to have web services with similar API, IDE, and framework as desktop. Happy camper.

[JS987]

It doesn't mean abandoning C++. You still cannot do direct file IO in QML at all, for example - you only have localstorage. And TBH, the Qt version of localstorage sucks balls compared to the web one. One area of improvement I'd really like to see is implementing an abstraction layer so that array indexing a localstorage object transparently writes the data to disk just like the web version does.

It looks like there is target to convert Qt from toolkit for C++ developers to toolkit for web(Javascript) developers to make Qt more popular.

[Karl Napf]

One of the biggest problems Qt suffers from is that it is to much technology driven with software guys calling the shots as to where it goes. Being able to put QT /QML on every smart phone and mobile device gets away from Qt's core strength as a cross platform desktop framework. The desktop market may not be as sexy as the mobile market but thats where the money is.

Actually the biggest opportunity for Qt currently is in the embedded market. All those washing machines, cars, coffee makers, medical devices, etc. that need a touchscreen UI.

It bothers me that the head of Qt engineering said in his keynote address at the Qt Developers Conferense that Qt Widgets are done.

That was really poorly communicated. "Done" was supposed to mean "no exciting new features are expected to land in this module".

One of the first things Digia did when they took over was to try to communicate this better, pointing out that widgets are fully supported. In general Digia seems to be better at communication than Nokia was:-)

In software the only finished software is obsolete software. So no more work on the C++ framework ? Qt's strength was always in the big and mission critical app space - Orbital Mechanics, Oil & Gas, CAD, Wall Street, Movies, you get the idea.

That is exactly where you want a toolkit that is "Done" in the sense used by Lars. No exciting new features that break stuff, but all the bug-fixes you need!

Maybe I am old school as it is hard to imagine these bigs apps migrating to Javascript. I just can't see a nuclear power plant or glass cockpit running on Javascript.

Seeing that QML is used in medical devices I do not see why somebody hacking a UI for a nuclear power plant would not decide to have UIs in QML at some point.

To me QML is basically a UI description file that is more readable than the XML stuff Qt used to have. If you refrain from bogging that down with JS your QML basically gets turn into a data structure that is pushed into the graphics card and rendered there. No JS Engine involved in any of the critical paths whatsoever:-)

[Karl Napf]

It looks like there is target to convert Qt from toolkit for C++ developers to toolkit for web(Javascript) developers to make Qt more popular.

You are aware that Qt had Javascript for *years* before it was used in QML?

Check the QtScript module. In fact the reason why QML allows Javascript is because the engine was already in Qt. The Javascript engine got replaced a couple of times in the meantime, but that is just an implementation detail;-)

[JS987]

You are aware that Qt had Javascript for *years* before it was used in QML?

There is difference between supporting Javascript and using it as main language with C++ as 2nd class citizen.

[Karl Napf]

There is difference between supporting Javascript and using it as main language with C++ as 2nd class citizen.

Neither is Javascript the main language nor is C++ a second class citizen.

[Luke_Wolf]

It looks like there is target to convert Qt from toolkit for C++ developers to toolkit for web(Javascript) developers to make Qt more popular.

not really no, not anymore than WPF is targeted at web developers. What people like you don't seem to get is that this is literally the equivalent of WPF for Qt, just using JSON as opposed to XML because it's nicer for people who want to write this stuff by hand. Ultimately the WPF/QtQuick idea is more powerful and easier to do complex things with, than the traditional widget style development workflow. The real problem with QtQuick up until the recently has been that QtQuickControls hadn't been released as stable yet, which made it unsuitable at the time for desktop development.

[JS987]

Neither is Javascript the main language nor is C++ a second class citizen.

With Qt5, there is HW acceleration of GUI only with QML/Javascript because Digia want everyone to use QML instead of C++ Widgets. Gap between QML and Widgets is increasing with every Qt release.

[GreatEmerald]

That's some really good news Shows that Qt is really successful and will be even more so afterwards. Though I wonder, what else does Digia do, other than work on Qt?

[JS987]

not really no, not anymore than WPF is targeted at web developers. What people like you don't seem to get is that this is literally the equivalent of WPF for Qt, just using JSON as opposed to XML because it's nicer for people who want to write this stuff by hand. Ultimately the WPF/QtQuick idea is more powerful and easier to do complex things with, than the traditional widget style development workflow. The real problem with QtQuick up until the recently has been that QtQuickControls hadn't been released as stable yet, which made it unsuitable at the time for desktop development.

QtQuick idea isn't bad, but using Javascript is. Javascript is used because every web developer is forced to learn it.