When I first got to know Qt, it was a cross platform tool. That was really the reason for me to start using Qt. It was a great cross platform tool. At the time, I was using a Tru64 based system with real X-terminals. You know, the ones where the screen really is a stupid terminal connected to the network. Tru64 meant a real Unix, as in non-Linux, setup alongside Alpha CPUs. Great for what the school wanted us to do, i.e. use Matlab and latex.
In this setting, I wanted to program something with a user interface. My experiences from the time was GEM, from the good old Atari ST range, VisualBasic, I’ve used 1.0, 2.0, 3.0, 4.0 and 6.0 – without liking a single version, and some plain win32 from C. I did try MFC a couple of times, but I never grew fond of it. So, the first thing that I tried was xlib, which isn’t fun to use. So, along came Qt (and KDE). I believe that it was Qt 1.42 or something like that. One forgets as years passes by.
Qt configured and built beautifully, and the cannon tutorial had me hooked. Standard widgets, custom widgets, user driven, timer driven… this toolkit could do anything. And it was easy to use.
Years pass and the chronology gets mixed up. I met some fellow Qt users at QtForum. I made my way from a common user to moderator. Then, in a series of sad events, the site was sold and the old owner simply vanished from the Internet. The reaction was to start QtCentre together with the rest of the moderators and build a proper community. I cannot thank Witold enough for all the energy he still puts into this site. He really should get more credit for his work. There are other people there too who work hard, but Witold has been there from day one.
Qt progressed, the X11 version was GPLed. So was the OS X version. So was the win32 version. Qt 4 brought many goodies: modularization, webkit, graphicsview, model-based viewing widgets, etc. The toolkit embraced all platforms and is really a great tool for cross platform desktop development.
My self, I wrote the Independent Qt Tutorial for Qt 3, then the Foundations of Qt Development for Qt 4. I started working with Qt as my day time job. I started speaking about Qt at conferences and user group meetings. What I spoke of was the ultimate cross platform toolkit. My favorite example was that Qt tries to integrate well with Gnome – it does not even pick sides in the KDE vs Gnome competition. The whole root of Qt is its cross platform abilities, and there Qt excels.
Then came changes. Trolltech grew. Nokia bought them. The big fish eat the small.
With the Nokia acquisition came a great energy. Qt was put in the limelight. This was the technology that Nokia would base its future on. Developers were attracted to Qt. Qt DevDays had to move to a larger venue to fit them all in, and it still was crowded.
There where some big company things going on. Name changes – Trolltech, Qt Software, Qt Development Frameworks. Anything works. For me, personally, Trolltech had charm. Bug big companies sometimes act in strange ways. They don’t always agree with themselves and they might have contradicting policies and whatnot.
With Nokia came the push of Qt as a platform of its own. Qt on Harmattan/MeeGo and Qt on Symbian where all of a sudden the core focus of all Qt development. This is not surprising, given that this is where Nokia could apply Qt. The focus of Qt Developer Days changed. Out with the widgets, in with QtQuick and bling. The cross platform nature and roots of Qt where seemingly forgotten.
Do not get me wrong. QtQuick is a great piece of technology and something that I use daily in my job. It helps me be real productive and saves me from writing tons of code to drive rich user experiences.
Then came changes. The Qt strategy of Nokia was replaced with a WP7 strategy.
Not only was WP7 the official way forward. The Qt-based N9 is not to be sold in large markets. Despite positive reviews it looks like it will be a sad tribute to what Qt and QtQuick can do. The question is, who will pick up the ball again? Will there ever be another MeeGo handset? Most likely not, as Intel just pulled out of MeeGo, or just renamed it Tizen. The focus seems to have shifted from QtQuick to HTML5. The big question at the time of writing is what will be the underlaying engine. I’m sure everyone agrees that it will be WebKit, but will it be hosted by Qt or something else?
But now Qt has started to find its roots again. Lighthouse made porting easy. Necessitas puts Qt on Android. Qt for iOS is an ongoing community port. Qt will once again excel as the cross platform solution of choice. The question here is if it is wise to merge the desktops into the QtQuick API. I’m not convinced yet. Being cross platform on desktop also means integrating with the desktops. Current desktops are widget based, and to be true, widgets rock on desktop things. When controlling a machine or writing a mail I don’t want bling, I want predictable, stable widgets that looks like they are supposed to.
Compare this to common device user interfaces. Here there is a difference between applications such as mail and todo apps. Here you want common components that integrate with the platform – much like widgets. These elements usually fit into the limitations of widgets as well. Square, non-overlapping, etc.
Then you have completely custom applications, think Angry Birds, where QtQuick is the ultimate tool. As QtQuick can encapsulate both these user interfaces, it is the ideal tool for this type of device user interfaces.
And the current hype – HTML5? I believe that QtWebkit is the best system for building hybrid web/native applications out there. And integrating QObjects with the JavaScript space much resembles integrating them into QML space.
After chaos; Metamorphosis
I look forward to a new spring for Qt. Having a common Qt core for all applications. QtQuick for device user interfaces and QtWidgets for desktop. The QObject model that we have learned to love and the power of C++ will be available to all. Still, the user interface can be integrated with the platform of choice or fully customized with QtQuick. Code less, create more, deploy everywhere.
“I did try MFC a couple of times, but I never grew fond of it.”
I think nobody does. People who program(med) MFC do (did) so either because there was no other choice, or for a living maintaining existing MFC code.
I agree with everything in this post.
I hope the Android and iOS ports reach production quality. “Write once, run anywhere – except on Nokia phones.”
Great post, although I wonder what you really mean when you say “Current desktops are widget based, and to be true, widgets rock on desktop things.”
What really is a widget? In Qt, a widget represents a (rectangular, unless masked) area on the screen that can receive events and that can draw itself. What makes them rock is years of knowledge (and bug-fixing) poured into the implementation, and that they render through a style that makes them highly integrated with the desktop environment.
Conceptually, the “area on screen that can receive events” aspect is identical for rectangular QML element, isn’t it? There is nothing fundamentally different that would stop anyone from pouring the knowledge and the styling into a QML element, but I believe the positioning of QtQuick vs QtWidgets is based on a perception that I don’t agree with.
Ultimately it’s IMHO about “declarative UI development in QML” vs “imperative UI development in C++”. That’s where QtQuick and traditional widget-based UI development are fundamentally different. I don’t believe the logic will be “imperative is better for stable end predictable desktop UIs, declarative is better for dynamic *bling* UIs on devices”. If QtQuick makes UI development more productive, then desktop-UI developers should get and use that tool.
@Volker sure, if declarative UI makes desktop more productive, then that is the tool to use. I just don’t think that it is the case right now. It might be my bias, based on experience, that widgets Just Work(tm). But adding another layer (QtQuick) to widgets, just to integrate better with non-widget-UIs kind of spoils the ease of cross platform desktop development that Qt offers right now.
Agree too (except that I was a VB fan before being a Qt fan, but that was a long time ago ;) ).
The main problem with QML is not QML itself – if one can build nice UI without knowning C++ the target is reached – but the fact that Widgets, the basics have been completely forgotten – at least it seems so.
In the same way as mobile platforms have eaten Trolltech power, QML has eaten classic UI.
Our application is a classic business application, we choose Qt to be on all possible platforms. But during the last years, Qt has been ported on Symbian (wow, nice, who plans to buy a symbian phone today ?), MeeGo (RIP), QML has been developped (but I don’t care in my application). It really looks like “old” Qt developpers have been just there to pay their commercial license (and I’m not talking about the support quality which was sometimes pretty bad, either due to bad guy or, when you’re lucky to reach Andy, you end with a bug id which is never fixed) so a bunch of brand new – but useless for them – features have been developped.
Adding a webkit widget is perfect. adding animations to your existing applications with a few lines of code, brilliant. Add multimedia quickly too. But rewriting your UI because all new features are now QML based, sorry, that’s nonsense.
“I look forward to a new spring for Qt. Having a common Qt core for all applications. QtQuick for device user interfaces and QtWidgets for desktop. The QObject model that we have learned to love and the power of C++ will be available to all.”
amen.
@Volker
Why shouldn’t declarative GUI use traditional widgets? Would it be that hard to allow usage of standard QWidgets from QML?
I agree.
QML completely destroy the cross plateform part of Qt. The plan was to make an ui for each plateform * device type. Qml Components on differents plateform didn’t have the same api.
Finally this WP7 move from Nokia, and Intel moving to HTML will probably be a good things.
@Benoit
Huh? Of course QML is cross platform. ???
QtWebKit is great for hybrid applications, but it will be declared “done” in Qt5. The development will focus on QtWebKit 2. I doesn’t allow hybrid html/native application anymore.
I think that with all this mobile / Quick hype going on, and with Qt now being commercial, owned by a company that has clear intentions of turning Qt into a mobile toolkit and doing it for free, it’s time for the community to fork Qt. This fork will be maintained by the Qt and KDE community, and will integrate the KDE 4 libraries as it is planned for KDe 5, thus forming a coherent and unified platform for cross-platform development. Nokia isn’t going to do Qt any good.
On the other hand, I see they’re giving Qt away to the community. Does this mean that they’re effectively throwing it away now that they got WP7? Like, we don’t need t anymore, it’s yours now. If this is the case, then it’s definitely time for the community to *completely* take over and develop Qt on a free software basis.
@thorGT I would strongly be opposed to forking Qt. Open Governance, the modularity of the toolkit (you can add your own module, instead of forking) and the actual license choosen by Nokia speak against it.
Nokia had (has?) the clear intention to turn into a mobile toolkit, but here, the key factor is if they want it to be a cross platform mobile toolkit, or a platform by itself.
I think Qt Quick (QML) will achieve “cross-platform” more easily. It’s the future of Qt 5.0. And after the Android OS and iOS were stable, Qt SDK should support both platform, that’s the Qt’s new spring. At that time, who care about Nokia’s Symbian.
@SL, I’m not as convinced. I believe that QML might not be the answer on the desktop. But, it also seems that the desktop is on its way to get replaced… just look at Windows 8.