Desktop Components for Qt 5

Published Wednesday June 6th, 2012
117 Comments on Desktop Components for Qt 5
Posted in KDE, macOS, Qt, Windows

According to this recent poll, Desktop Components is one of the most desired add-ons for Qt Quick 2. To help make this a reality we have moved the Desktop Components project over to and are now accepting contributions, for both the Qt Quick 1 & 2 versions. Several good contributions have been made already, and at the same time a few of us here at Nokia have been working on bringing the components up to speed on Qt 5.

The components are hosted as a Qt Playground project and won’t be a part of the 5.0 release. They will instead have separate releases, most likely in sync with the Qt 5 releases. At some point we will look at making them a proper part of Qt 5.

Project details are available at the wiki. Here’s a quick getting started script:

git clone qtdesktopcomponents
git checkout qt5
make install
cd qmldesktopviewer; qmake; make; cd..
qmldesktopviewer/qmldesktopviewer examples/TopLevel.qml

Do you want to contribute? There are several open tasks, including:

  • Add a menu bar component
  • Add support for mouse wheel events
  • Style polishing on your favorite platform
  • Update: Tree View!

Finally, screenshot time (all on Qt 5):


Mac OS X



Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in KDE, macOS, Qt, Windows


Albert Astals Cid says:

How does one create a style for this? Or is it using QStyle under the hood?

vpicaver says:


@Albert: the original (Qt 4) version was using QStyle. I haven’t looked at the Qt 5 code, but I don’t imagine that has changed at this stage.

Jens says:

Albert, Robin:

It is indirectly using QStyle. The components are using their own QML styling API, “StyledItem” which happens to wrap QStyle right now but it is an abstraction layer so it could wrap other styling API’s as well.

QStyle gives us parity with Widgets, but I don’t want us to commit to using that in the future. I have been toying with the idea of forking the built-in QStyles and optimizing them for QML as we right now have a lot of widget specific things in them. If we completely want to break free of widgets, that would be the next logical step.

Mad says:

Why do the compile steps never work in qt ? 🙂

Morten Johan Sørvig says:

Mad: Added more qmake, tested on Mac OS X, should work better now.

Jens: have you been following the work of the INdT guys? they’ve been contemplating a world with different styling, though I haven’t had much time to read up on their ideas.


Scorp1us says:

Thank Gawd! I was getting worried that Qt was going out the door without parity here.

So is there any reason why I can’t use OSX components on Windows?

Adam Higerd says:

@Scorp1us: Because it uses native rendering APIs.

sergeant says:

I remember some time ago Trolltech announced that they were using native widgets wherever possible.
Did that change since?

The reason I am asking, is that the toolbar items (folder-like) look so weird on Mac.

air-dex says:

It would be a nonsense if Qt Quick, the new preferred way to design UI of Qt, didn’t have got basic components for Desktop UIs.

Awesome. I was concerned that only mobile platforms would see widgets for QtQuick.

snowpong says:

How tied are the different styles to their platforms?

For example, if I was a perverted soul and wanted to run Qt Desktop Components with the Mac look in Windows – could I? I’m guessing not, but it would be cool to see what the different styles depend on.

Nils says:

@robin: That were my thoughts too. Do we now have two competing Qt Quick Desktop components projects? Both affiliated with Nokia?

charley says:

@Robin, @Nils, totally agree about the INdT guys: I’ve been following their desktop components, and their components-styling (my biggest wish/want/need), and they are doing good work:

I’d *prefer* one “standard-components-approach-with-styling”, but don’t mind today’s temporary flirtation with multiple approaches (as we seek understanding). (The QML paradigm is new, and we need to understand what options exist, and their pro/con implications.)

However, at present, I’d lean towards the INdT guys’ design: It does not lean on QStyle, it has better re-factoring for inheritance hierarchy support of styling, and IMHO it seems more “complete” and “future-proof”.

Thanks to @Morten and this post, I think these exploration-efforts are very important, and we won’t know “what-works-best” until after we see some implementations/designs and can play-with/understand them better.

Too bad I still see no treeview and that it seems really hard to implement in QML

Sup says:

Looking good! Have you ever thought in funkiest dreams to style components with CSS, or would it be even possible?

Cristian Adam says:

I’ve build Desktop Components for Qt5 on Windows 7 using MinGW 4.6.2. Unfortunately some controls have blurry text, as you can see in this screen shot:

Text looks fine in the screenshot taken on Windows in the blog article 🙁

Mark Turney says:

Thanks for all the hard work! There are many daily QWidget users that are looking forward to the desktop components as a first foray into QML.

qtnext says:

I am developing a desktop quick2 only application (complex application … not a toy) and it seems very promising : it breaks the problem of qwidget rectangular area, performance is good … I am very happy ! deskop components are missing but more than simple widget (easy to do from scratch in qml) :
– tree is missing
– menu bar : have you in mind to have an application menu bar for qml that works on multiple platform: for example integration of the menu in the mac menu ?
– I need to have an equivalent of qdockwidget to move and arrange widget in the application … What can I have do to have multiple floating dockwidget that I can move on multiple screen on the desktop ?

OtherDavid says:

This. Is. Awesome. Thank you, Nokia!

My wish: Use the widget rebuilding effort as an opportunity to refine the Qt MVC “Interview” framework.

I recall hearing that certain Trolls had some really good ideas for improvement.

This way, contributions could come from both the Mobile and Desktop sides of the Qt community.

Well, that’s my wish anyway. What do you guys think?

d3fault says:

>According to this recent poll, Desktop Components is one of the most desired add-ons for Qt Quick 2.
It should read: According to this recent poll, Desktop Components are the obvious next logical step in the [necessary] reinventing of the wheel / duplicating of QWidgets [desktop] functionality (since QWidgets are now done/obsolete).

The ‘most desired add-on’ to Qt Quick is, as other [biased, yet still not as bad as this one] polls have shown ( ), a full C++ front-end to Qt Quick. Comparing C++ API and Desktop Components (as was done in the poll linked) is very misleading.

The question on everyone’s mind:
-Interfacing with Qt Quick-
a) QML
b) C++

When that poll tries to make it:
-Qt Quick Priorities-
a) QML Desktop Components
b) C++ API
c) lots of other random noise, some of which fall under the category of “C++ API” anyways (and so detracts votes)

Why am i still typing? QML camp just hears what they want to hear (can’t see past the end of their nose etc). I’ve processed plenty of logical arguments made by my side on the subject (declarative? easy. bindings? easy. animations/states already have C++ api. memory management? ever heard of QObject::setParent?), and the only argument made by the QML side is essentially: “Yea, QML is elegant. We made it and love it”. After all, we’re talking about a project that’s been worked on for multiple years by hundreds of full time employees. And everybody knows, time + money = great product. There’s no way they could make cruft after working so hard for so long. It just wouldn’t be fair.


abdallah says:

very good

suy says:

d3fault: Your post is very interesting. The problem with it is simply this: most people being paid to work on Qt (on the development of Qt, not Qt-using applications), are still Nokia employees. And employers work on whatever management has told them to work on. If more Qt-using developers stand up and start working in a pure C++ based solution, that would be great, but if management of Qt-developing companies don’t think is the right approach, we will have to do it ourselves.

Personally, I think that BOTH of you have a pretty valid point. Lately I’ve been revamping a Dialog that was fully created with Qt Designer. I had to move many hardcoded stuff to the C++ side of things, and I’ve been tempted to scrap the Designer file completely, and do it everything in C++. My boss, however, thought it would be ideal if it weren’t because we have the is UI completely defined by the client’s designer.

I personally think that QML is a very nice succinct language, that allows me to state how I want the UI to look declaratively, so I really don’t see it as interpreted JavaScript, because I still make almost everything in C++. An alternative would be nice to have for comparison, and to have more choices, but I’m fine with the state of things right now.

Morten Johan Sørvig says:

Thanks for the comments! I’ll try to cover as much as possible here:

INdT: We are exchanging opinions and want to collaborate. As long as there are different views on how the styling etc should be done I think it’s natural to have separate projects. What I want to avoid is having two projects implementing the same solution – that would be silly.

Practically speaking I think it makes sense to go with the QStyle and QtWidgets dependent approach now. (Even though Jens wants to liberate QStyle from QtWidgets). This allows us to re-use the current style code (including custom styles and style sheets) and also other parts of QtWidgets such as file dialogs and popup menus.

Blurry text on Windows: There are still some issues with fonts on Windows. I don’t know the details, but I would say it’s something we want to fix for 5.0. All screenshots except OS X were taken on virtual machines, so I would not use them as absolute references.

Tree View is missing. (updated the TODO list in the post)

Menu(Bar)s works as expected on OS X. (Which is in fact the only platform where menus currently work, since we don’t have a component for drawing them ourselves yet.)

qdockwidget equivalent: I’m not a fan of docking windows, can I convince you to use Qt::Tool windows instead? 🙂

Marvin says:

@d3fault: Your statement that “QML camp just hears what they want to hear” just pretty much sums up your “arguments” (*shrug*/collection of fallacies) as well. If you want to have any hope of being taken seriously, please mind your attitude and start using proper arguments instead of throwing insults and accusations left and right.

Bernhard says:

Does ist in any way support dynamic Layout Managers (Grid, [VH]Box) or will we get shitty “Big text does not fit into Button/Label” Applications now with Qt too?

Bernhard: I don’t quite understand why you’d need layouts to avoid text not fitting, QML’s Text element also supports eliding (naturally) and there’s also a fontSizeMode property new to Qt 5, which will allow your text to paint itself to best fit the room you’re giving it (

Regardless, QML has its own positioners (the Grid, Row, Column and Flow elements – maybe I’m missing others), and writing your own custom layout element if you need something specialised or more controlled is really not that difficult – see for a very short/simplistic approach at getting started.

JubiluM says:

“According to this recent poll, Desktop Components is one of the most desired add-ons for Qt Quick 2.”

Take a notice also on the second most desired add-on for Qt Quick2 – Full C++ API


I also share d3fault’s concern on widgets, there are many of us out here. Many big projects, that for a reason or another, simply can not or do not want to port to qml. And I know that it frustrates people to see a fine, well tested and working solution to fall into a category “done”. Well really everybody knows that nothing is “done” if you talk about software or a software framework. Politics has decided that it is done and there is nothing one can do about it. Despite the “open” governance…planning of the roadmaps is not open for the record.

Good news is, at least for now, Digia treats and serves also widget users right. They understand the importance of widget Qt and why wouldn’t they, most of the customers are widgeters. Wish to see that good spirit last, but nothing is sure when it is about politics.

My opinion is that there is an equal need for qml and widgets. And, I think that desktop should be provided for the quick by wrapping the widget-api. No duplicate work, no re-inventing the wheel, natural look etc.

Anyway, cheers!

Marvin says:

@JubiluM: It is not the concerns, but the way they are portrayed/communicated. I’d like to see full a C++ API for QtQuick as well, but the way d3fault (+others) puts it, it’s C++ or the high way. And IMHO “done” is, like it or not, a quite accurate description of current style desktop widgets (and not isolated to just Qt).

Jason says:

The windows version of the the QNetworkAccessManager can not save cookies with spaces .
Qt5 can not solve this problem?

JubiluM says:

@Marvin: You’re right. But I understand why some feel frustrated when you face a situation where a political decision has been laid out, there is no intellectual argument in the world that could affect it. When the roadmap says that it is done, it is done! The talented people behind the scenes, who actually know the code by heart will not work very actively on the “done” part. The open governance is also a partial illution… contributions and new features on the “done” part might not get accepted without considerable friction if at all. We’re basically in the hands of Digia…so far they have been doing a tremendous job!

You’re so wrong about the mindset of C++ programmers…99% of us, many whom also use qml, think that there is a place and purpose for both widgets and quick/qml.

Chris W says:

@Cristian Adam: If the sample executable is carries no manifest and Windows’ display scaling feature is in effect then Windows may be scaling the UI and causing this blurring. Don’t know this for sure, just a possibility.

Jason says:

The new version of QNetworkAccessManager does not exist the problem of the cookie .
I use Qt4.7.3 link library have this problem .
Sorry, please ignore my question .

7 says:

Way to go, keep reinventing the wheel instead of putting development efforts in a more innovative direction. I thought QtGui was for desktop components and widgets, QML was for custom user interfaces, and now QML gets desktop components, the push continues to be away from C++, which I think is simply wrong considering Qt has been and made its name for being a C++ framework…

Marvin says:

@JubiluM: The decision is not purely political (unless you also want to start throwing accusations), and most of the “intelectual arguments” I’ve heard hasn’t really been all that compelling.

And when you assume that I mean there’s no place for widgets in the future, I’ll have to disappoint you and say that you’re wrong. Widgets have and will always have a place, but the graphics model is outdated (in a 2D/3D HW accelerated world) and needed fresh thinking, which the Trolls have done.

As I see it, the issue is that there’s a lot of people not being satisfied about progress going fast enough (you just want it all finished and can’t stand waiting for API’s and intermediary to materialize and stabilize). If there is a meaningful life for a C++ declarative API to QtQuick it will come, either from you (as in you, the community) or from the Trolls themselves.

JubiluM says:


No no, you got me wrong, I did not assume your opinion on widgets to be the way or the other. And you do not disappoint me, it is really good to hear that you understand the importance of the widgets :). You’re right…it might be so that many aspects of the widgets be outdated and considering that you can see what the problem is….if the roadmap says that the status is done, no considerable effort will be thrown in to develop things. It is not all about performance either, mostly Qt widgets perform extremely well in the solution space they’re supposed to work, namely desktop. What I think is that it is just insane to re-invent the working desktop. Why not wrap it and provide it for the quick to consume? Win-win for everybody and without re-inventing the wheel.

The issue is not at all about the speed of progress, it is about the roadmap and the obvious decision to freeze the state of widget Qt. You surely do know what the “done” – badge means in the software development process?

QtDev says:

What is QtQuick ?

Marvin says:

@JubiluM: You mean mixing widgets into QtQuick? That is already possible.

When it comes to reinventing: As has been stated on this blog and elsewhere many times – the widget model in Qt is B.A.D. and therefore needs major rework, stubbornly keeping a broken design and trying to fix it just to avoid “reinventing” (innovating as some call it) would get us nowhere.

JubiluM says:

Well actually what I meant is to further develop the widget Qt as a backbone of desktops, also use it as basis of quick desktop. That would be co-existing development of the both.

If someone states that the widget model is bad, it is ok. That is just an opinion. There are plenty of different opinions on the subject. Bottom line is that it is the best availlable for C++ and really, it is flexible and good enough to be used and called from other languages…Python, Ruby…actually might be the ui-toolkit to be used with the widest spectrum of programming languages. So it would make a lot of sense to make the widget Qt the backbone of desktop QtQuick.

So…my opinion is that the widget model is not that bad at all and actually there is not a toolkit that can beat Qt if you consider desktop development. This is from the user (programmer) perspective. Another perspective is the toolkit programmers perspective.

There are many justified arguments also on the subject why qml sucks and why it is really B.A.D. Still, people who find it useful and find a suitable use case for it use it happily. That is nothing off from the C++ developer. But as the widget Qt has been set to category “done”, you will never see that “major rework” you pointed. Even if someone outside would contribute it, you could not be be certain for the contribution to be ever accepted. Why….because of the roadmap which states “done”.

Domino says:

That’s great to see that the Desktop Components project is still alive, I was afraid the project was dead because there was no activity on the old repository. Maybe it would be a good idea to close the previous repository (qt-components/desktop) or at least provide a hint that the project has been moved to qtplayground/qtdesktopcomponents. What about previous merge requests?

Anyway, this project is a very important step to be able to create next-generation desktop applications with Qt. The combination of Quick and desktop components is very promising. I am already using the desktop components for an internal project and I am looking forwards to a great future for desktop UI developers/designers!

Another important step is the improvement of the model/view support and I really hope that there will be some good news in that area!

Cristian Adam says:

@Chris W I’m running Windows 7 at 1600×900 with normal fonts (96 dpi), there should be no scaling involved.

Fritz says:

Thank you Nokia. Now please make a Tablet available where I can use Qt. I don’t care if it’s Windows or Linux as long as I can use QML/C++.

Is the GNOME style at the bottom GTK3-based? Will a GTK3 style ever be ported to Qt 4?

Marvin says:

@JubiluM: No, it is not a matter of “just” opinions. There are many tell tale signs, benchmarks and metrics one can use for telling a bad design from a good one, and the Widget model (seen in a post software painting world where utilizing 2D/3D HW for drawing is important and where dynamic ui and smooth animations is a factor) is quite simply a bad design.

I’ve seen a lot of criticism of QML, but little to none of it (of which can loosely be called valid arguments) has been directly related to it being a bad design (other than “not being C++” being bad, which _is_ an opinion, not a metric), most of it has been “I’d do it differently” and a lot of it has been name calling and accusations of decisions being purely based on politics. Sure, there’s bad things with QML, but B.A.D. (as in: Completely useless for further development)?! I can’t shake the feeling that someone is exaggerating grossly.

These desktop components is part of forming a bridge between the “old” desktop widgets and QML (being “native” QML widgets), and since you already can mix widgets into your QML apps I’m struggling to see what you’re missing? Or is your point that QML should have been more or less directly based on the Widget model?

muenalan says:

I love C++ and I love QtQuick .. it is so much cleaner/faster to develop. Cannot be stressed enough, after seeing so many broken-hearted C++ dev comments. It is really the next level. Thank you for that !

d3fault says:

@Marvin, do you not consider requiring a VM & JS Interpretter to be loaded into memory (regardless of whether you use them or not) to be a B.A.D. design decision? What about the forced JIT parsing/processing of .qml files? What do either of them have to do with Hardware Accelerated GUI, Bindings, States/Animations, and Memory Management?
The answer: Nothing. They are all just the benefits of using QML… and QML is the requirer of such stupid dependencies (this will hopefully change in the future, as some have noted (but will not change in time for 5.0)).

QWidgets is obsolete not because that style of design/coding/GUI is dead… but because Qt needs to maintain backwards compatibility with itself. It is (I assume… at least from what I’ve heard [from QML camp]) impossible to add to the existing QWidgets infrastructure the hardware acceleration, bindings, states/animations,etc… WITHOUT breaking backwards compatibility.

For this reason, I don’t want the functioniality added to QWidgets… but I [we] want something along the lines of QWidgets2. The use should be a hybrid between what QML is today and QWidets1… but breaking backwards compatibility where needed to add all the benefits of QML/QtQuick: Declarative, Hardware accelerated, Easy use of bindings, Easy use of States/Transitions/Animations. QWidgets1 already has memory management through the use of QObject::setParent.

QWidgets1: Raster/Software
QWidgets2 (and QML currently): Vector/Hardware

Where in that do you see the implicit need for an entirely new langauge?

QWidgets1: developer has to use signals/slots for bindings
QWidgets2 (and QML currently): bindings are built in and easy to use

Where in that do you see the implicit need for a javascript interpretter? We have the entire C/C++ runtime at our disposal and now we need Javascript? This was definitely a B.A.D. design decision (or politics ;-)).

Our arguments are falling on deaf ears, so I am assuming my ‘insults’ are as well. What do you care? Instead of pointing out that I’m hurting their feelings, how about trying to provide a rebuttal based on technical merit? I have seen no such justification in the continued development of QML, and have laid out the reasons directly above.


Dave says:


You’ve consistently ignored technical rebuttals, or handwaved them away as “discussed elsewhere” when that hasn’t been the case. At this point you’re basically a pest.

d3fault says:


Please provide said technical rebuttals, as I am very interested in reading them. Certain points which I’ve referenced have been discussed elsewhere, but I’ve yet to see any technical rebuttals. Link?

Re: Pest
The squeaky wheel gets the grease
…except in this case the wheel is probably going to have to grease itself (sounds erotic imo). This isn’t so much of a problem until you consider that all such squeaky wheels will probably have to be greased from outside contributors from now on. Did Nokia move Qt to open governance so it would flourish…. or so they can opt-out of their responsibilities to Qt? To quote Lars Knoll (paraphrasing): “we welcome anyone to step up to the plate to improve QWidgets”.


JubiluM says:


Considering desktop development, it is “just” an opinion. And in many cases what is gained in 2D/3D HW, will be lost in using interpreted language so an “opinion” in that sense also. And really, the performance of Qt widgets in developing desktop software is excellent….why wouldn’t it be since in each platform the widgets are (mostly) platforms’ “native” animals. So…as we’re talking about desktop development it is plain simple re-inventing the wheel and duplicate work to try to bake quick desktop components into similar cakes that existing widgets are. What is important for desktop development is the native look and feel in each platform, fancy effects is not on top of the priority list of requirements (still it is relatively easy to customize widgets if there is need for that). And claiming that widgets were B.A.D (as in: Completely useless for further development), is an epic exaggeration in the true meaning of the expression.

So my poin that you keep deliberately missing is, that widgets and quick satisfy different use cases, but still, widgets could and should be utilized as basis of quick, in the desktop development. Discussing on the subject is nearly impossible if a straw man is thrown back on each and every justified argument. So, I’ll be repeating myself by saying that quick should be based on the widgets, on desktop components/development. So I hope you get my point right this time :).

I wish that some day we will see an incarnation of the second most desired add-on of the recent poll, “Qt Quick2 – Full C++ API” so that people developing software in C++ (and why not other languages) and using tools other than Qt Creator could utilize the progress of Qt development. In an “open governance” votes are taken into account, right?

Marvin says:

Ah, the classic “any form of VM is intrinsicly evil” fallacy/”argument”, founded on false assumptions, bad comparisons and lacking knowledge of the underlying SW platform you’re using 😛

But slagging aside, what do the declarative part (ie: QtQuick) bring to Qt 5.0? Everything. And since the declarative in the declarative is a dynamic setup language (ie: Not staticly compiled, and not running the application logic) you need some form of compiler or parser to make it work. Without it it would simply not be declarative. Theres’s a lot of alternatives out there, and the Qt team settled on JS/JSON instead of eg XAML which used XML/JS. It can’t be done purely in C++ because that would mean it wouldn’t be declarative (C++ is as you might now a static compiler that produces (mostly) static binaries)! They could have created a C++ compiler that ran as an interpreter but if you have any knowledge of how the C++ compiler works you’d know how silly that would be.

You could just skip the declarative part, but that would put Qt at a serious dissadvantage since _all_ serious new toolkits have a declarative component. Even you 3D Graphics hardware have a declarative part (heard of shaders?), your OS (.NET,Cocoa) and the most used tool on any platform is _entirely_ declarative (you browser). The previous itteration of Qt has an XML semi declarative part, but it has some serious limitations (like simple programming logic, dynamics (it is purely static), flexibility, etc).

So to sum things up, it doesn’t seem you even know what declarative means, or has any knowledge how other toolkits work or are heading, and since that means you’re very likely absolutely clueless about what you want in QWidgets2, the Qt Team (and quite a few others, me included) struggle to take you seriously. And since you’re obviosly absolutely cluesless about the _current_ technicals, how can I (nor anyone else for that matter) expect to have a meaningfull discussing on _future_ technicals with you?!

And with a good declarative design you can do really fancy stuff like this:

Marvin says:

QtQuick is not “run” in an interpreter, it has a _setup_ language (JS/JSON QML) which is interpreted. This has been repeated, reiterated and explained in much detail many times over, please stop ignoring it.

The performance of Widgets for any serious (ie BIG) application is not very good, albeit good compared to some of the alternatives of the same technological era, it is useless in the new setting I described (HW accelerated dynamic, animated UI). ie: B.A.D. They work well for current software, but not for where “we” (obviously not you it seems) want to be in the future.

I’m not missing your point (and ignoring your attempt at an insult), I’ve repeatedly tried to rehash that QtQuick is made for future trends and that the development (ie new trends) within Widgets style UI (ie current desktop) has stalled, and therefore safely can be considered to be more or less “done”.

Basing QtQuick on Widgets would not be a good idea because basing a new design on something already known to be B.A.D. is a bad idea.

And regarding polls: Science isn’t a democracy.

d3fault says:

I believe you’re guilty of your own accusation: incompetents thinking they’re awesome. Sure this JubiluM guy doesn’t make any sense, but neither do you.

Re: VM intrinsicly evil
There are plenty of places to use a virtual machine… but alongside a C++ application (read: _EVERY_ C++ application made with qml/qtquick (for now))? No thanks. The cost is too great for the benefits provided.
The only reason there’s a VM is to support the JS… and the only reason there’s JS is to support bindings.
I have already demonstrated a [hacky] method to use “non-trivial bindings” (lol buzzword) here: . Here’s a C++11 alternate using lambdas:

Unless you want to allow the USER of the application to be the one to set the dynamically bound string/statement (rare use case), there is no reason we can’t compile to binary whatever the designers/coders want the binding to be. I’m sure this won’t come as a shock to you, but compiled C/C++ is faster than interpretted JS. Sure, we’re talking about relatively small statements so performance isn’t that big of a deal… but requiring a VM/JS Interpretter be compiled (and included with distributions/zips in windows apps, since windows fails when it comes to using shared libraries) + loaded into memory = huuuuuge overpayment, in terms of design… “for such small statements” ;-). The precompiler/compiler can take care of it and thus no VM/JS Interpretter is needed.

Re: declarative
Last I checked (I could be wrong), QtQuick is not the declarative part. If you had read my post thoroughly before responding, you would have noted that I never once put QtQuick down. In fact it’s just the opposite. QtQuick is the collection of superior technologies (to QWidgets/raster-based painting) that we want access to (without the overpaid-in-design qml,vm,jsi).
QML is the declarative part. It is interpretted (at runtime -_-) and the qml interpretter generates structure/POD that drives the QtQuick back-end (which is pure C++) imperatively. <- see that, imperative. aka not declarative.
So since it's structure/POD that drives QtQuick, what makes QML a requirement (aside from the fact that QtQuick was designed with QML 'in mind'. Hooray for future efforts wasted on decoupling the two)?

You value declarative so much? Great. I'm sure others do too, but does that mean it should be forced and the only way to access newer high performance Qt technologies such as QtQuick. (And this is where a QML pundit chimes in and says "but it isn't forced! you can still use QWidgets!". Use an obsolete/'done' api over a newer more efficient one (I'm referring to QtQuick, not to QML)? Great plan)
QML is fine and should exist… but it should exist as an optional extension to Qt… just like the xml/.ui files in QWidgets (albeit more powerful).

Comparing QML to Graphics Shaders is just dumb. UI is, for the overwhelming vast majority of use cases, not going to change once the designer/programmer presses compile (except in the case where a designer is developing a GUI, in which case the dynamic loading of .qml files is handy (but this, like UILoader, should NOT be forced on the rest of us)).
The reason Graphics Shaders are declarative is because you're applying changes to app 'content' and/or user data (ex: 3d models/textures) in a grossly parallel manner and declarative happens to fit that environment perfectly. The shaders are processed at runtime because the app content / user data does not have to be (read: should not have to be) present at the time of compiling. Are you, or anyone else, going to try to make the argument that a UI doesn't need to be present at the time of compiling? Sure, you could successfully make that argument… but what's left is called a 'library', not an application. Google it.

.Net is a piece of crap (compared to Qt; it still beats Java (imo) despite them both being interpretted), I've never used Cocoa (but according to wikipedia, it's Native… not run on/through/requiring a VM), and I really don't think Qt is targetting web page developers or even web browser developers (yes it has some of each, but they are not the core Qt _user_. And further if HTML5 was forced as the 'next gen' GUI creation method for Qt (forced by being the only way to access superior technologies), we'd be complaining up a storm about that as well).

I (we) have made it very clear what a QWidgets2 can/should provide, even going so far as to provide sample code/designs ( [QWidgets] is useless in the new setting I described (HW accelerated dynamic, animated UI)
QWidgets1 may be useless for HW accelerated GUI (lol “dynamic”? next are you going to say “fluid”? rofl) + smooth animations
but that’s where your argument ends
There’s no reason why a QWidgets-like api couldn’t provide “HW accelerated dynamic, animated UI”, along with easier use of bindings, states/transitions/animations.
QML/QtQuick may bring those features.. but it brings in lots of additional and unnecessary dependencies. Software is supposed to be modular and to perform a specific job and perform it really well. QML/QtQuick is a giant bundle of co-depending technologies that somehow ends up requiring a virtual machine, javascript interpretter, and an entirely new declarative language. The pieces are modular in theory, but in practice (current git) they depend on each other too much.
Hardware Acceleration (<<<—the main goal, but not the only one) requires Declarative (lol wut? it most certainly does not. but for QML/QtQuick it does) requires (well, maybe not 'requires') new/custom Bindings mechanism requires JavaScript requires Virtual Machine requires more hdd space, application startup time, and memory footprint. Or you can use QWidgets -_-, which is raster/software based (read: outdated) and you have to do your own bindings (not that big of a deal imo, those things called signals/slots make it ridiculously easy).

So to sum things up, you've managed to bring no tecnhical arguments to the table (quote yourself) and have successfully served as an example of an incompetent thinking they're awesome (perhaps I am the incompetent… in which case please hand me a gun).


d3fault says:

test: are these comments closed or is my comment too big (already tried splitting it… twice. rofl)?

asdf says:

yolo i like visual basic the best seriously you guys visual studio 6.0 is all you’ll ever need

d3fault says:

cool, Nokia appears to have shrunk the comments size to be unusable for discussion.
@asdf: Yes I Agree Visual Studio 6.0 Is Perfection And Is Powerful Enough For Everyone

Dave says:

By “pest” I didn’t mean “squeaky wheel”. I meant that you’re acting in a way that’s harmful to the community.

Your unwillingness to actually listen to other people’s points combined with the way you attempt to make your own points means that it’s pretty much futile to try to have a rational back and forth discussion on this topic, and so we’re left with some pretty negative and uninformed comments filling various forums.

I hope if I ever get as wound up about something as you are that I’m able to take a step back and actually see how I’m coming across.

JubiluM says:


I would like to see a desktop application where the performance of the widget Qt ui components is the bottleneck. It’s been used in thousands of commercial and open source applications and never ever have I heard of such issues. How many widgets is considered serious (ie BIG), 10 000 000? You obviously can provide me information or link to a such application?

First of all, show me a big and serious desktop application that has been made using QtQuick? Trolltech used to lead the fleet by showing an example of consuming the dogfood…Qt Designer, Assistant, Linguist and Creators can be considered as serious (great) applications in my opinion, so when I see them built as QtQuick applications, I’ll believe you. Untill then it’ll consider it just daydreaming.

Remember that the requirements of desktop development, it is rather conservative, native look and feel, functional components etc. If something else is wanted, one could use QtQuick. And my point that you deliberately keep on missing and twisting is that I do not mean the QtQuick to be based on widgets, just the desktop part. That would support both the widget and quick users’ needs. You’re making a circular argument of the development status of the widgets, it is stalled or “done” because of the roadmap, which is politics.

In general, if your idea is to go after the new trends and there is nothing that the current desktop could provide for future interfaces, why make QtQuick desktop components in the first place? After all, the final result will be a copy of widgets in the look and feel sence ie. “native” on each platform.

If we go into what is really B.A.D in QtQuick and personally a showstopper, is that it will produce a serious toolkit and a language lock in. it is actually the way MS and other big players tie their customers into golden chains. It’ll be interesting to see what will happen to Qt in the future, I fear the worse with the current approach.

P.S. Don’t be evil and call it open or a democracy if it is not.

vida18 says:

I really like Qt but I find that the system of triple license LGPL2.1/GPLv3 /proprietary is very complicated. Is it not possible to make the future as LibreOffice 4.0 which will be dual-licensed LGPLv3/MPLv2 ? The new license MPLv2 is compatible with the BSD and Apache as the MPL 1.1 but also with the LGPL and GPL v2 and v3. I really think if Qt could be triple licensed under LGPLv3/MPLv2 /proprietary or dual licensing MPLv2/proprietary could be beneficial to his community.

someone says:

I can’t understand this, I really think that they are reinventing the wheel.

I started using Qt because of C++/QWidgets, this is the identity of Qt, now for several time ago they gone crazy and had a vision with things like QML, come on!

But even with that path they could still have good C++/QWidgets, but:
– It’s clear that C++ for end using for them is to forget
– QWidgets will simple be “done” and will not be updated

So QWidgets could not support the required changes, why not QWidgets2? Yeah that simple!

But no, it would be to easy, they needed to break everything.

So now I simple try to not start any project with Qt and and I’m testing/searching for real alternatives.

I think that Qt5 will never exist, they can name it Qt5 but it will never be Qt, because it will not have the Qt identity (C++/QWidgets).

This is just my opinion and my vision, nothing more, they had a different one for what they will call Qt5, only future will tell if that vision is the right or not.

Sunny Oberoi says:

I gonna miss Qt, wish it wouldn’t have been bought by Nokia,
time to move on now, may be towards C++ builder or WPF (i hated wpf), becuase i want to see my application supported next 5 years.

really Qt was the bestest Framework ever.

Sunny Oberoi says:

And thank you for working on QML desktop components but can they be good for enterprise scale desktop application? highly doubtfull
i like QML as an addition but not as a replacement to QWidgets.

I am always been a big fan of Trolls and i belive in qt community, and will love to see Qt grow more robust and multiplatform.

JubiluM says:

@Sunny Oberoi:

You can count your application being supported 5 years if you use Qt/widgets, that is not the problem. Qt5 will include widgets (hopefully without considerable amputation) as well. I think Qt4 will be the main platform on widget side in the production use in near future, supported and updated both commercially and by the community.

The problem is that the politics have decided that widget Qt should be “done” and that’s it. Qt Modules Maturity Level shows the status of the modules:

So, no progress expected on widgets and total reluctance to offer any new features for C++ programmers. You’ll have to cry for the api for any new goodies and still you’ll probably crying for deaf ears. A recipe for a failure in the future. Many Qt users (programmers, projects) do not even know of the change of the wind in the development of Qt. That’s why it is important to discuss of the subject.


Both widgets and quick have their natural domains where they fit well. But re-inventing the desktop is what I consider a bad decision as the widget desktop could be used as basis of quick desktop. And really, it is not about performance…it’ll be fast enough for the end user whether it were the existing widget solution or HW rendered. And speaking of the (far) future (QT6?), throwing the possibility to make pure C++ software over aboard, would be a nasty decision for countless projects so I just hope there would be some sense on the matter.


Dewell says:

This is great! I have partly moved away from desktop applications because writing UIs with QML is so much more fun & productive than with QWidgets… Thanks for bringing QML to desktop, can’t wait for Qt 5.0!

wish nokia sell the qt widget part to someone like it says:

It’s simple, Nokia buy qt and modify qt to fit mobile device because it is a mobile phone company.Desktop is not the main focus from Nokia, so i wish some third org(kde?) can buy the qt/widget part to do better work on widget。
On the another hand, i don’t think qml have a good future, iphone/ipad have object c/html5, android have java/c++/html5…, why these mobile device should use qml?
And MeeGo is dead, Tizen use html5 also, so why should we study/use qml, a useless language, not a standard language, not widely support by industry companies language?

d3fault says:

Hardware Accelerated GUI requires a brand new language, which requires a brand new binding mechanism, which requires javascript, which requires a virtual machine.

At least, this is what Nokia’s trying to convince us…

When you start with a Native/C++ framwork and end up with an interpretted hybrid, you know you’ve designed something wrong.


d3fault2 says:


How often will you parrot yourself?

mgran says:

@d3fault: Comments with multiple links are held for moderation to keep this blog spam free, sorry about the delay. It’s not about the size of the comments though, you should be able to write a novel.

-mariusg (blog admin)

CodeMonkey says:

It would be really interesting to know if the “oh my god it has a vm inside” fraction is the actual majority or just a vocal minority.
I for one _hate_ to imperatively construct UI’s, it’s always messy and hard to maintain. Everything that can be done declaratively should be done declaratively.
And coming from an HPC background, I have to add that optimizing anything besides the inner loop is a waste of time anyway.

David Johnson says:

My two cents from the C++ side of the argument:

I think QML is an elegant technology, but it is not a one-size-fits-all solution. I think it should be related to the role of defining the interface, and nothing more. It should be a descriptive language, without the pretense of being true declarative language (which it is not). Define the properties, states, hierarchy, etc, and leave everything else up to the C++ (or python, java, etc). Avoid adulterating it with imperative javascript. In short, make it the next generation UI file.

I think this will ultimately be the best practice for QML. It will describe the interface, but all program logic will done in C++. Not just the business logic, but the interface logic as well. To get there though we need help from QtQuick. We need better C++ bindings to start. And better ways for C++ to acess QML elements. On the flip side, QML needs to be better at describing the interface as well. The inability to define one’s own group property for a element in QML bit me in the ass hard last week. One should not have to create a new QDeclarativeItem to do this.

There should be only two basic layers to an application: the front end and the back end. You should not have to write a huge fat bridge layer in between.

p.s. Desktop components will of course help with this, when they finally reach QWidget parity. But beyond desktop components we also need *generic* components. One should not have to reinvent the push button for every new platform. Having to build everything up from three basic visual primitives (rectangle, text, image) is tedious.

David Johnson says:

I have one large client with a major app written in Qt4 with QWidgets. Their app was even showcased by Nokia at a recent DevDays. They have told me that there are no plans to move to Qt5, that if widgets are “done” then they will stick with Qt4 for the lifespan of their product.

David: The grass is always greener – when it matures properly, Qt 5 (as it stands today, feature-wise) should be Qt 4 with a faster, more solid foundation. “Porting” is minimally painful, and there shouldn’t be too many unexpected surprises around the corners, thanks partly to this “done” state, where stability is the primary focus.

That said, if they are happy with what they are using now, then of course, there is no compelling reason to move. Qt 4 won’t be going anywhere. It’ll just be even more “done” 🙂

Unrelatedly, what do you mean by a “group property”?

tada says:

Nokia is not interested in the desktop. The Qt guys has to do something to get paid by Nokia and QtQuick+javascript is easier to sell to Nokia than Qt&C++. I can not see any reason why would they concentrate on the desktop. For them QtQuick is the saviour (reinventing the wheel pays well if you can sell it as new and exciting technology).

But! Qt is open source, anyone can pick the desktop side and improve it. So if something doesn’t work, don’t be afraid to use the debugger and submit a patch.

Hampton says:

David Johnson: You’ve addressed the issues exactly.

I would also add that the lack of meaningful new innovation on the Desktop side of things, either in classic QWidgets or some QWidgets2 spiritual successor, means choosing to stay with the Qt platform may be a distinct _disadvantage_ for new product development.

That Nokia, a company that employees 134,171 people, chooses not to allocate even a handful R&D engineers to drive forward the technology the core customers of a $153 million acquisition care about speaks volumes.

I hope this changes.

The world of UIs is changing and this is exactly why we need more innovation for Dekstop UI toolkits, not less.

A side point: Not to discount some of talented engineers Digia has employed, but from my limited interactions with Digia, the current attitude is one of a company whose leadership’s vision is limited to sucking dry the purchased “golden egg” of captive Qt Commercial clients and nothing more. They no longer even publicly list pricing for new Qt Commercial licenses. Maybe we’ll be pleasantly surprised gong forward, but I doubt it.

Hampton says:

The point of my above “side point”: Don’t expect innovation to come from Digia. They don’t have the incentive.

A sobering article:

I hope Nokia management wises up before it’s too late.

Chris Adams says:

@David Johnson: no technology is a one-size-fits-all tool, in my opinion. Use whichever tool solves the problem at hand the best. I disagree with your comment about JavaScript in QML, however: using complex expressions in property bindings allows for great flexibility and dynamicity. Furthermore, being able to quickly prototype functionality and business logic without needing to dive into C++ is a huge advantage, for all developers (not merely developers and designers who have existing HTML5 and JavaScript skills), in my opinion.

However I do agree that for applications with tight performance constraints, business logic is best separated into C++ implementation. This, however, is one of the major advantages of QML and Qt Quick: it allows a very maintainable separation between UI and business logic, as is. The fact that it also allows people to implement business logic in JavaScript functions or imports, is merely a bonus, for those applications and use-cases where the separation into C++ implementation is overkill for the effort required.

Of course QML and Qt Quick are not perfect; they are evolving technologies. They are being improved every day. With the upcoming Qt 5.0 release, we’ll have a solid and stable basis from which to make further improvements. Feedback from the community has played and will continue to play a huge role in the development of Qt, and in my opinion, that will only improve and increase going forward.

@Hampton: there has been a huge amount of innovation in the desktop area. Have you seen the things that the Qt3D team has done, for example? It has never been easier to embed 3d content into desktop applications with Qt, than it is in Qt 5, in my opinion. Furthermore, the UI design considerations which lie at the heart of QML and Qt Quick are applicable to desktop application user-interfaces as well as user-interfaces intended for other form factors. If you have further ideas for how the technologies in Qt could evolve to better serve the desktop, please raise them with engineers and other members of the community, at the Qt Contributor Summit. Perhaps you could excite enough people about your ideas that there’ll be positive momentum behind them to contribute an implementation to the Qt Project.

JubiluM says:

“A side point: Not to discount some of talented engineers Digia has employed, but from my limited interactions with Digia, the current attitude is one of a company whose leadership’s vision is limited to sucking dry the purchased “golden egg” of captive Qt Commercial clients and nothing more. They no longer even publicly list pricing for new Qt Commercial licenses. Maybe we’ll be pleasantly surprised gong forward, but I doubt it.”

Really totally opposite, they have a good, innovative spirit going on and they honestly support and serve both C++ and quick users. Qt Commercial Blog remains me of how labs blog used to be….you check out what is going on yourself, f.ex. Qt3D available both for C++ and quick, Qt Commercial charts for both C++ and quick, etc. etc. etc.

That’s the way to go and do it….Digia has taken the place and spirit of Trolltech. As they work with thousands of paying customers they have a true understanding of what is going on in the field and what is needed. And what is important for the projects.

Only negative is that some of the Digia contribution will be available only for the paying customers, which is understandable in a way.

Hampton says:

Chris Adams said:

“Perhaps you could excite enough people about your ideas that there’ll be positive momentum behind them to contribute an implementation to the Qt Project.”

This is exactly the problem. Why should anyone, outside of the limited Qt fan-base, invest time or money in a project whose owners have declared themselves to be “done” with.

QML has some great ideas at it’s core, and Desktop does need to migrate to a HW-accelerated render stack, but Nokia’s steadfast insistence to ignore the needs of it’s long-time user base during the transition is what the whole uproar is about.

Nokia basically saying “leave us alone and do it yourself if you care so much about it” is no way to make any friends and attract new developers.

To quote from “How Yahoo killed Flickr” the article I linked to in my previous post:
“We [Yahoo] didn’t give a sh*t about the community”

( )

Think about it: This whole blog post is about how an engineer’s “Qt Quick for Desktop” side-project got some updates and moved to gerrit. This should have been part of the official project charter from day one.

Hampton says:

@JubiluM: I’m not a statistically significant sample. I can only report my own experience and impression.

In any case, it’s really Nokia that needs to be seen as supportive and innovative since Nokia ultimately owns Qt.

David Johnson says:

Group property: A property that has sub-properties within it. Somewhat analogous to a struct. Example is the font property of Text., font.pixelsize, font.bold, etc. The problem is that there is no way to create your own in QML, they have to be created in the element’s internal C++ implementation.

p.s. It’s also strange in that “font” is documented to be a basic type of QML, yet it’s impossible to declare a font property in your own element, which is what I was trying to do. Ditto for some other complex types, such as rect, size, etc.

David Johnson says:

I don’t have a problem with simple javascript expressions for QML bindings. And I don’t have a problem with javascript functions that are purely functional without side effects. But when you go beyond this then the QML stops being declarative. Which is a sure sign that something in your design is wrong.

Just because QtQuick makes it easy to cobble something together does not mean cobbling is desirable. It’s okay to mock something up quickly, but don’t get lazy and think that big ball of bailing wire and duct tape is your finished product.

d3fault says:

re: David Johson^

The argument “QML enforces the boundary between front-end and back-end” falls apart completely when you can shove back-end code into the front-end. Nokia’s driving a wedge between it’s [Qt] user base. Even though they don’t officially recommend putting business logic in front-end, it’s not going to stop waves of future amateur developers from doing exactly that.

These “future amateur developers” are who Nokia is trying to appeal to with QML. Nokia wants an app store like iOS/Android and knows it has to appeal to a wider (read: less intelligent) audience to achieve it. Now, how they’re going to get Qt on their phones in the first place is beyond me, since Elop killed MeeGo/Tizen and there’s practically no support for Qt on any of the mobile platforms that people actually use (not that I don’t appreciate the effort <3 Necessitas).

You aren't less intelligent because you use QML, but QML is easier to use and so would appeal to those less intelligent. QML is easier to use, but is a lot less powerful than full C++. Is Qt a tool for amateurs or a tool for professional engineers? Appealing to both, especially when that means allowing both to use the Framework in different ways, splits the community in half.

It's often mentioned in these comments/forums/mailing-list that an engineer will "choose the right tool for the job". Well first of all, that analogy doesn't fit because we're creating a tool, not using one. And second, QML is like hitting a nail into a piece of wood using a car. Sure it works, but it's overkill for the problem.

Did I mention that I'm not particularly fond of the bloated QML experiment and the resources it is stealing from the Qt Project? Polly want a cracker?

Good read, thanks for the link. I wonder if QML is a deliverable that the Trolltech employees (now Nokia employees) have to finish before they get all their cash. In any case, Qt now has to 'integrate' into Nokia's core business (mobile phones), which leaves little room for 'Qt Innovation'.

I find it baffling the amount of people in denial there are in the QML camp. Requests for a proper poll are repeatedly ignored, and the one linked to in this article is referred to as being sound in the first sentence of a front page post on -_- (through the blog feed). It wasn't explicitly described as being sound, but referencing it in a blog post such as this pretty much says the same thing.

Perhaps I'm the one in denial? Maybe in fact there are more developers wanting to use this new experimental hybrid language for their business operations than there are developers wanting to stick with trusty/stable/long-standing C++?


Riaan Kruger says:

I love Qt and the potential of QML but …

Without Desktop components for QML, QML is near useless on the desktop. I cannot recommend QML for any projects we are busy with or intend using in the future unless the desktop components are there and usable.

So it is a shame that it is not part of Qt already. It is a manually painful process to get it to a point where I can use it in a project from qtcreator. There are many different recipes on the net of how to use it but most seem like a mere after thought unless you know qt very well. These recipes seem incomplete and varying.

I believe: If Qt is still serious about the desktop, desktop components would have been easier to integrate into your development environment by now. By now desktop components should have been integrated into qt or at least had a “forehead” type deployment.

David Johnson says:

QML certainly has it’s place, and is a useful tool in a variety of situations. My objections are not against QML per se, but against the arrogant attitude that widgets, painting, and C++ are all “last century’s technology”.

JubuluM says:

“In any case, it’s really Nokia that needs to be seen as supportive and innovative since Nokia ultimately owns Qt.”

That is the ultimate problem. What Qt needs is a good home and a sensible management…under Nokia’s influence Qt will always be in danger of deadly, splitting hugs and lousy decisions.

Andrey says:

QML, Qt Quick, API and so on.. Somebody could imagine people need games and animated buttons only.
Most of business applications and much of home tasks need to deal with tables and DBMS. Very simple grid (yes, i know – several hours, and you can almost use it in real application), poor db abilities, underdone drivers (postgresql is lack of numerics!!! (QTBUG-12477)). Who needs QML? You’d better buy rc helicopter to play with 🙁

Dream on says:

The joy ride is over

Qter says:

The most important thing for QT project is improving portability of apps. Not UI, Not QML, it’s already good enough and easy enough. That’s just an extra bonus….That means Lighthouse is the key which determines destiny of Qt(Survive OR DEAD). My suggestion is bring Qt-android and Qt-ios to main stream immediately, and make it mature ASAP.

Thomas Führinger says:

And no MDI functionality?

EE says:

Next billion strategy is based on Java?? @eeropenttinen said on twitter.

Santa says:

@EE Qt is dead within Nokia with all Qt staff in Europe/Oz laid off. I doubt they’d stop dev completely though, if they did then Qt could be re-licensed under BSD which neither Nokia or MS want as a threat to their future strategy. I wonder if Trolltech had a contract that they had first refusal on any sale so they could do a management buy-out?

Joe says:

If Nokia abandoned QT, that’s great news! Actually, Qt lost its way for years. Qt need a wiser management and clear target. But in my point of view, I don’t like to see Qt bought by Google , Apple or M$, because they may bind Qt to their own devices, even change it to commercial licensed only.

QPlace says:

“…all Qt staff in Europe/Oz laid off”.

Is that really true?

QInformation says:

Somebody from inside, information please!

That’s not a secret, MS hates Qt to the bone, it is a threat for them and they want it dead. Nokia’s obviously off the course and is just about to get sliced (as planned?). There is not ever going to be Meltemi etc.

What kind of legal tie does Nokia hold on Qt? There is the Qt project which is not owned by Nokia, right? Digia holds the commercial rights to Qt, right. So if and when Nokia gets slaughtered, are we safe?

Anan says:

Only known thing that future Linux/Qt based platform for cheap smartphones was cancelled.

Nokia left with MS WP 7/8 for smartphones and S40 (with J2ME API for 3rd party apps.) for cheap devices (~less then 100 Eur).

What’s the Nokia plans for Qt – no official statement. I think we’ll see within next few weeks.

7 says:

^^Nokia seems to plan on cutting Qt funding off completely and looking to sell it, which could end up either a great or a terrible thing.
As of Qt staff being laid off – at this point I haven’t heard such a thing, but some Qt people are looking for or have already fled the sinking ship so to speak.

Santa says:

The “Domain Lead, Qt for MeeGo R&D at Nokia” tweeted that Qt dead inside Nokia.

Also a little twitter browsing finds tweets from Qt people at Nokia from eg Ulm, Brisbane, etc looking for new jobs. Nokia will either skeleton crew it so that they don’t have to BSD the code or find someone to buy it who will not compete against them. So for either of those options I think we should be glad a lot of the mobile work has already been done for Qt5.

Sad says:

This is really sad news. I guess everyone has sensed this the day Nokia announced going to WP8, but when it finally comes its still overwhelmingly sad.

Here in Canada I know the Ovi store folks are been given until end of 2013, not sure what the deal is for Qt guys, is Qt 5 still on track for August? Can we count on it?

screwed says:

Nokia plans to sell off the Qt division to whoever is interested. That’s the only thing known; the rest is under planning.

Qt as we know it is over. Qt5 given it’s very mobile centric direction will be a toolkit that nobody wants. Even RIM if it were a prospective buyer would not want QML in it’s current form. They have their own version of QML (based on cascades) and has a C++ api. And I am sure if Samsung purchases Qt, the developers are going to have a tough time.

The Qt developers are partly to blame. They built Qt5 completely assuming Nokia as the only customer. Now their main customer is gone; who really wants Qt? i.e a business that can somehow fund over 200’s of developers. We are looking at > 100m USD business here. Even in trolltech times, it wasn’t that much.

qtnext says:

@screwed: I don’t agree with you … Qml is a fantastic technology (I am a full C++ developer since 12 years) and not only for toy application … It just need more maturity (desktop components for example) … I am sure that a lot of company will use Qt5 qml..
I hopes that Qt will be selled to one or more company that like Qt !

7 says:

“It just need more maturity (desktop components for example) …”

Did you notice the title of the blog entry you can commenting on?

As I already said in another place, the problem of QML is not immaturity, the problem of QML is its fundamental design, which will not change as it matures. QML will never be what it wasn’t designed to be in the first place. It is a very good tool for many tasks, useless in other tasks. The biggest mistake was not developing QML but focusing entirely on it, stealing resources from the native APIs, not creating new features for the native APIs and effectively doing literally NOTHING for all the developers, whose needs exceed what QML offers.

serkol says:

I was wondering for a long time: what are Nokia Qt devs paid for? For making tools for cheap phones (Meltemi)? That sounded stupid. Cheap phones have very low profit margins. Nobody can make money making and/or selling them, especially if your pay European salaries. Why would one start developing a new platform for this junk? That’s a lot of expenses for nothing.

Now Meltemi is cancelled, and somebody wrote that all or most Qt devs will be fired by the end of 2013. Now I wonder even more: what will Nokia Qt devs paid for until the end of 2013 ??? Am I missing something big here?

d3fault says:

“Nokia plans to sell off the Qt division to whoever is interested. That’s the only thing known”

Source? …. or is that your opinion?

My opinion is that it’s against Microsoft’s best interests to let Nokia (“let” because Microsoft has Nokia by the balls) sell off Qt to a third party. They’d either want Nokia to do nothing with it, or would purchase Nokia themselves and then do nothing with it. They (Microsoft) want to stop Qt development in it’s tracks because it is a huge threat to their business model of selling operating systems and development kits that only work on their operating systems (vendor lock-in).


Domino says:

I somehow hope that Nokia employees will react a little bit more on and protest against those decisions. The recent news are so obviously Microsoft-oriented that nobody can negate that they were planned from the beginning of the new Nokia+Microsoft era…

But independently of that, Qt developers have been doing an excellent job, even during Nokia’s ownership. Thanks to Nokia, at least before the arrival of the new CEO, Qt had valuable resources to be prepared for the future and that was a great chance. The mobile technology is, in many aspects, the base for the next-generation graphical applications and that’s also true for the desktop of the future. Now let’s hope that Nokia’s people will be strong enough to sell Qt to the right company. Even if it is not necessary the best deal for Microsoft…

someone says:

Domino June 17, 2012 at 5:19 pm: “Now let’s hope that Nokia’s people will be strong enough to sell Qt to the right company. Even if it is not necessary the best deal for Microsoft…”

I wish, but I don’t believe, the hard true is that Microsoft already control Nokia, and if I was Microsoft one thing I’m sure, I will have at least one developer tasked for Qt, so Nokia will never lost the control over Qt.

Remember that when Nokia bought Qt the contract said that they needed to have active work on Qt or they will lose it.

As for Microsoft, Qt at least was a big, let me say it again, a BIG threat in the desktop and even in the mobile(in the future).

When I still used Windows I started using Qt because I didn’t to develop something that will be locked to a specific OS.
And also because I wanted C++ and a GUI framework that generated native code, but Qt5 don’t go that direction…

And I really fear that Nokia/Microsoft will kill Qt and if in the future, someone pick it, will never be with lots of paid programmers 🙁

vida18 says:

If Nokia were to abandon Qt, it would make it his interest in donating its intellectual property to the Apache Software Foundation. This is a license similar to the BSD license with a strong community.

Cuke says:

TableView is incomplete, TreeView is missing…these components are far from being complete

JubiluM says:


I think that no one has argued that quick would be even close to complete. However, the widget Qt has tested and tried components for desktop development.

Jan says:


after reading this discussion, as a Qt user (currently 4.8) on three platforms: Win32/64, Linux, MacOS X, I would like to contribute my view on this current discussion:

To be honest I’m a bit concerned about the direction that Qt is heading. We decided to use Qt as a toolkit due to it’s easy usage, good documentation, support for plugins/XML/printing and graphics output (SVG, PDF, PS, …) and compatibility with several C/C++ libraries for scientific computing (data fitting, optimization etz.). Also the compatibility of the codebase on several platforms and easy setup with QtCreator on ALL of these platforms (we have people working and developing on all 4 mentioned platforms!!!). We built a huge application that is used for high-performance data evaluation and also instrument control. In both functionalities (implemented as plugins) we do NOT need any fancy user interface features, but just plain and simple widgets is just perfect for us. I’m quite sure that many other projects from the scientific community that use Qt have the same requests, so it would be a shame to see QWidgets beeing deprecated and more-or-less going out of support and update (which can be seen on about 5-7 bugs that I posted on the bugtracker and that were never even evaluated/looked at?).

So I share the view of some commenters on this list: QtQuick is a nice-to-have it OPTION and please treat it as such … If I’ll build a fancy program for a cell phone or tablet that’s mostly about the looks in future, maybe that’s the road I’ll be heading by then, but for now I want to use all the special QWidgets (e.g. plotter widgets) we implemented without fear that I developed for a platform that will die within two years. I’m not completely convinced that forcing a JavaScript interpreter/parser/VM/JIT-Compiler into a program just for the sake of a nice GUI is the way to go. To me also it seems like a bit of overkill … but on the other hand I didn’t have a close look at Qt Quick so far, only a very faint, so don’t see me as over-informed on that topic 😉 … why is it so hard to make the object tree that’s built from the QML code accessible via a pure C++ API (you are using one internally I suspect)? Then I could choose whether I want QML+the overhead or just go for the plain C++ (and save the VM/… and all the binding logic).

But also I do see the point that sometimes it makes sense to start all over again to be ree of old code and compatibility-requests … so could you PLEASE simply come up with a plan that gives us (as developers/users) both:
1. a nice and new Qt Quick with OPTIONAL QML
2. good support for QWidgets … i.e. go on implementing features that do not kill the API completely, but allow us to write good and well-performing applications, that still run on most platforms (I think for the forseeable future most of the PCs will still have a screen+mouse+keyboard, so support for this is essential!!!


PS: Please! No political and Nokia-bashing answers to this, just technical ones … 😉 … I’d like to discuss …

Domino says:

@Jan: you said it yourself: you only need the existing widget functionalities. Providing that Q t Widgets are still available and supported, the discussion about QML and Qt-Quick is irrelevant for you. Sure, there will probably not be any major enhancement to Qt Widgets (except for bug fixes) but you can be sure that it will still work at least as good as before.

So the answers are:
1. If you do not need the Qt Quick module you consider as “fancy” and if you want to use “plain and simple widgets” only, whether the API is in C++ or in QML does not have any impact on your projects
2. All the widget functionalities are there, if you need any new widget (a fancy one?), you can rely on a third-party implementation or use the facilities provided by QPainter to implement your own widgets. There is absolutely no limitation and, to be honest, I do not see the need for any new widget in the framework (unless we are talking about a next-generation applications which anyway need something like Qt Quick…).

In my opinion, an improvement of the model-view(-controller) framework is the only change which would really make sens for Qt Widgets. For the rest, it is time to look a little further and understand that we need an evolution in graphical applications. ASCII art and static widgets are not the keys for the future and it is great that Qt did not miss the train.

faldżip says:

@Domino: you said it yourself: if we need only existing functionality, then there is no need to switch to Qt5. In our company, where we are developing desktop application we don’t see any advantage in switching to Qt5. We don’t use QGraphicsView, we don’t have any problems w graphics performance and so on. We don’t need any evolution in in graphical interface, as mainly we present lots of data in table views and tree views. But we would like to see some evolution in QtSql module (working on higher level than queries – i bet it can be possible with all this moc or maybe some QML/QtScript use there…), better support for XSLT so we can get rid off some 3rdparty dependencies and so on… But it looks like it is not going to happen.

Javi Moya says:

“QtQuick is a nice-to-have it OPTION and please treat it as such … If I’ll build a fancy program for a cell phone or tablet that’s mostly about the looks in future, maybe that’s the road I’ll be heading by then”

this is the key… ¿why so much effort in qt quick + qml? We can’t deploy in any alive ecosystem !!!! Nobody wants to learn qml!!! because there is no where to target !!!¡ ¿old nokia mid -range smartphones?? No!

Javi Moya says:

these widgets are ridiculous.
If you need a widget-based application… you are doing it wrong if you go to the qml way.

/mode ironic on
Qt Creator is going to look amazing ported to qml.

Domino says:

@faldżip: Well, you are not forced to upgrade to Qt5. But besides Quick 2 and possible new bug fixes for widgets, Qt5 Core also contains many interesting changes, such as the moc improvements, C++11 support and the new regular expression engine. The Qt team has done a very good job but if you don’t need it, that’s also fine: that argument is valid for any software update. For the moment, be happy with Qt 4 and be also happy that some people innovate, we would otherwise still use Qt1 or MFC…

faldżip says:

@Domino: I know I’m not forced to upgrade to Qt5, but my point was that they focus mainly on QtQuick2 which is maybe innovative, but they forgot about desktop developers. The thing is, that without Nokia’s phones with MeeGo or Meltemi there are really not many devices where you can use this innovative QtQuick2. Maybe this way: You want to make apps for smartphones? Then take Java and write for Android or Objective-C and write for iOS, because you will have more users buying your app then all users of Symbian with Qt. But if You want to make applications for desktop – then choosing C++/Qt is really good idea. But they are focused on QtQuick like it would solve all world’s problem and the truth is that it is a nice feature – but useless in many cases where Qt is used now.

bhaskar says:

I want to use QML versioon of MapRoute API in my application,So could you please let me know if any work is going on this API or this development is completed also when is Beta version is going to be released.


waydayEtemy says:

Живопись холста всегда поражала воображения людей, великие художники вдыхали души в картины, отображая эмоции и чувства, передавая окружающую атмосферу происходившего. Сама живопись очень древнее искусство, оно берёт начало с основанием цивилизации, на ряду с разнообразием культуры и обычаев. Первые рисунки живописи были найдены ещё на стенах пещер, где жили доисторические люди, на этих изображениях были отображены в основном вымершие животные и охотники. В дальнейшем с развитием человечества, художники сами изготовляли краски и избирали компоненты, тем самым став первооткрывателями и основопологателями данного направления искусства. Многое для живописи

Commenting closed.

Get started today with Qt Download now