Qt 5, C++ and Qt Widgets

Published Wednesday April 18th, 2012 | by

We have seen the many questions and the concerns raised about our commitment to C++ and QWidget in Qt 5. I thought now would be a good time to address some of these concerns in this post.

The post on the Qt 5 alpha was focused on the new things we enable and add with Qt 5.

Let me just state it very clearly here:

QWidget and all derived classes are a core part of Qt 5 on the Desktop.

You can continue writing your application in exactly the same way as you have been doing with Qt 4.x.

We have promised to try to keep as much source compatibility with Qt 4.x as we can. And of course this includes QWidget and your application written in C++. This is not going away. Yes, the Qt Widgets module we have in Qt 5 is right now marked as ‘done’, which means we don’t have anybody actively working on new features for the module at this point in time. But this can change any day if someone has some interest or need to do more active development in this area.

What we did with Qt 5 is to add a new way to do applications with QML. I personally believe that over time we will see more and more apps being written that way, as I believe it is the better solution in the long term.

New user interfaces such as the Windows 8 Metro UI are not things we could simply add to our existing QWidget infrastructure. Adding support for the kind of animations used in these user interfaces is extremely difficult using QWidgets, as they were designed for the mostly static user interfaces that predominated until a couple of years ago.

The fluid animated user interfaces that are already there on Devices such as smartphones and tablets are now also starting to appear also on desktops. And they are simply not implementable using the QWidget infrastructure.

This implies that we needed to do something new here. And QML/Qt Quick was the answer we came up with to solve this problem. That’s why we’re investing in that area.

Our experience with QML over the last years has shown us that it is the superior technology for building UIs in the long term. If you want, you can simply use it as a more powerful replacement to .ui files. But you can also write some application logic in there using Javascript if you want.

It really is up to everybody what they make out of the options being given by Qt 5, and how they best like to use them.

C++ is and will stay our main programming language.

We have done significant work for Qt 5 adding many new C++ APIs. We have added support for C++11 in many places. And we’ll continue to do so, because larger scale applications written with Qt will be mostly written in C++ for a long time to come. And there’s nothing bad about this.

What we did with Qt 5 is to add another option into the mix. We want to make the usage of Javascript supported as well as C++ is supported. We are not making it the superior way or even the only way. That is a good thing, as it opens up new options for how you write your application.

If you want, you can do smaller pieces of application logic inside QML. It allows to do some rapid prototyping that can then be replaced by C++ in the final implementation. It gives you abilities to do application scripting. And for many apps it also gives you the option to write a big part of it in QML and Javascript.

Summary

With Qt 5, if you want to use Qt as you have always used it, please go ahead. It’s a fully supported way of doing things.

But I do believe that we will need more then what we have in Qt 4 for the longer term future. The expectations towards application UIs are changing drastically, especially when creating consumer-facing apps.

We need to have solutions available if we want Qt to stay relevant. That’s what Qt 5 is all about.

Cheers,
Lars

Did you like this? Share it:

Posted in C++, Contributors, Qt

246 comments to Qt 5, C++ and Qt Widgets

faenil says:

Very nice post, thanks for clearing things up Lars!

Christophe says:

To paint using the new scene graph engine (QtQuick 2), only the QQuickItem and QQuickPaintedItem primitives are available from C++. Other primitives like a rectangle, a text etc. which are available in QML aren’t available from c++.

So C++ is more restricted than QML on this subject or will the C++ API be made public when Qt5 gets released?

Albert says:

I guess you can’t comment on the rumours that say that the meltemi phones will be QML only (i.e. no C++ allowed at all) since meltemi doesn’t exist officially, right?

Nils says:

I just recently got started with Qt and I really enjoy working with it. However I still wonder about the Qt Motto

“code less
create more
RUN EVERYWHERE”

Android and iOS were left out so far and I really do not understand why. Having a cross platform, native guy toolkit with both mouse and touch input would really be great.

@Christophe: the problem with public API is that, after it’s made public, it’s very hard (or even impossible) to put the genie back in the bottle, because by making it public, you’re explicitly saying that this is ready for the ‘prime time’, you can go ahead and use it, it won’t change – in either API or ABI, close to forever (or at least 4-6 years, the length of a major release cycle of Qt, and even then – it can be impossible to deprecate/remove bad API if it is used a lot or it is only remembered too late, as recently happened to me when I noticed that QPaintEngine is still (unfortunately) public in Qt 5… :))

Said more simply: it’s really easy for you, as an application developer to say “make this public” – it’s a little harder for the people working on this stuff, as they need to balance a lot of different concerns (performance, usability of the API, flexibility of the API, …) to get all of this right when they don’t even know their full slate of requirements yet.

I’d wager that if the first incarnation of QML had exposed a lot of the private API details (as was repeatedly called for by some people), then the transition now coming to QtQuick 2 would probably have been a lot more painful than it will be – and it will still be painful, as QDeclarativeItem -> QSGPaintedItem (or QQuickPaintedItem, or whatever it’s called this week) is a little different in terms of operation. It’s easy to forget that QML is a new technology in many, many ways. It’s only shipped in two minor Qt releases so far (4.7, 4.8) and a few patch releases (4.7 went up to 4.7.4, 4.8 is about to release 4.8.2…). Other parts of Qt, like QWidget, that expose such a broad C++ API have been maturing for considerably longer than that.

Anyway, on a tangent to this discussion, *IF* you know what you’re doing, and you’re willing to accept the consequences (no source/binary compatibility promises), you can use Qt’s private APIs a lot easier in Qt 5, so you don’t necessarily need to wait for all the dust to settle before this can actually happen.

@Nils: there are people in the broader Qt community who are working to enable Qt on Android and iOS inside of the Qt Project as an open source project, and you (or anyone else) is welcome to join them. It’s important to remember that things don’t just appear from thin air – someone actually has to write the code to make that happen.

danny says:

Thank you for the clarifications.

While it’s obvious that *some* platforms are moving towards more fluid interfaces (I personally believe Windows Metro will flop), I don’t agree that creating a brand new, interpreted language to achieve it was the answer. OSX incorporated CoreAnimation into their existing ObjectiveC framework many years ago without the need to invent a new language. The same could have been done with Qt and that would have made more sense on power-restricted devices like smartphones.

The real issue I have with Quick is not the QML part (I can appreciate the state-based transitions, having done it in code), but the idea that non-programmers can produce decent applications without real code. Integrating a QML UI defined with properties and signals with a business back end is more complex than using standard widgets, not less. I know, I’ve tried it. It’s all about the backend and that’s where Qt is weak.

Other than in a trivial ‘lists’ app, using one of the pre-canned models, Qt-Quick is only good for building a UI and the customization that it provides for the UI is far, far more limited than a QWidget with custom a paint event or a graphics item.

Qt itself needs an overhaul beyond simply integrating C++11 features. For instance, the interview framework is overly complex and could really use a re-design. It doesn’t scale well and I’ve never found it useful in a real-world app. The undo framework, which should be the heart of any modern productivity app, is also really lacking. Qt doesn’t even have a basic document-project architecture, something that every other framework (MFC, PowerPlant, VB, AppKit…) has always had out of the box.

I can build a complete, *compiled* hierarchical database app in Cocoa, complete with multiple documents, saving, undo, search, sorting etc from simply using InterfaceBuilder and CoreData. Not *one* line of code. Can Qt-Quick do that?

Even basic classes like QVariant, fundamental to Qt, is seriously flawed, lacking the ability to work with custom types safely.

I guess the existing tools would be sufficient for the next Angry Birds, but real-world software incorporating the features that users expect these days, is a lot of work and Qt doesn’t really provide those tools.

Frerich Raabe says:

Lars writes:

> Yes, the Qt Widgets module we have in Qt 5 is right now marked as ‘done’, which means we don’t have anybody actively working on new features for the module at this point in time. But this can change any day if someone has some interest or need to do more active development in this area.

Does this mean that the QWidget-based code is frozen and won’t get maintained anymore (no bugfixes either)? Or does it mean “no new features, but we will do bugfixing”? In the former case, what he wrote earlier

> You can continue writing your application in exactly the same way as you have been doing with Qt 4.x.

…would only be half the truth: you can continue writing your applications as you have been doing with Qt 4.x *if* you are willing to not only maintain your application code but also the Qt widget code which you use.

@Frerich: It’s not frozen. Bugs are still taken, and fixes accepted. New features are also accepted. What it lacks is a large number of people working on this code. Take a look at the definition of module maturity at: http://labs.qt.nokia.com/2011/05/03/qt-modules-maturity-level/ – and keep in mind that module maturity levels _can_ change either up or down, depending on the effort expended.

As to the ‘half of the truth': someone still had to maintain that code in the past. Just because the code for Qt is available under a free license doesn’t mean that everything comes for free — there’s no such thing as a free lunch – if you encounter problems, you are going to be spending one of a few things to get those problems fixed:

– money (paying someone else to fix it for you – e.g. Digia, Nokia/Trolltech in the past, or one of many other consultancies)
– time (fixing it yourself)
– goodwill (finding someone who knows the relevant code, and convincing them to fix it for you – probably not going to happen unless you already have some kind of a relationship with this person, and this assumes that such a person exists)
– luck (that someone who is willing to spend one of the above runs into the same problem that you do :))

Akos says:

Just by announcing the QWidget toolkit is “done”, it will start deprecating itself. First, the apps start looking out-of-place and out-of-date on the modern desktop, then developers will stop using it for the same reason.

Note I’m not saying this is a bad thing, I also prefer QML for making UI. But let’s make it clear: QWidget is not a first-class toolkit anymore.

QML Desktop says:

What is the status of QML on the desktop?

Is there a full replacement of QWidgets now, or is QML support still incomplete?

ddriver says:

As the main provoker of this LABS post, here’s my 2 cents (already stated in a few other places)

The concern behind this post is totally missing the point, NO ONE is complaining from the lack of QWidget support in Qt5. The real reason behind my complains is actually stated in that post, which says modern, fluid type of UI are not possible with QWidget (well, it is possible, but tedious and not efficient).

So the real problem behind the direction of Qt is the solution to the outdated QWidget, namely Qt Quick is limited to only being available through QML, with the overhead of having to use QML, JS, interpreter, VM and glue code. What Qt needs is a native C++ api to use Qt Quick and the SceneGraph. QML needs to be OPTIONAL, and the possibility to keep it all native needs to exist without having to give up on all the improvements done to Qt’s UI capabilities done the last 2 years. Without that choice being available, intentionally or not, Qt Quick turns out to be an extortion scheme to enforce the adoption of QML.

In short, Qt needs a modern UI API for C++. And since Qt Quick is a C++ backend anyway, it won’t be THAT HARD to allow a native C++ frontend to use it and avoid all the overhead of QML.

SuperRocket says:

I use Qt Quick in C++. It rocks !

HollaDieWaldfee says:

Release the QtQuick desktop components with Qt 5.0 or your argument “If you want, you can simply use it as a more powerful replacement to .ui files” is invalid.

3DH says:

@Danny: I aggree with your opinion – for me as long term Qt developer (commercial customer developing industrial software for 12 years) the last “innovations” are just interesting for beginners to produce some not too descent end-customer apps.

But building complex commercial apps with Qt can be / is a pain – because no one of the Qt guys seems to know the problems and pitfalls of developing really hughe apps. E.g. my apps are > 250.000 lines (only the Qt part) and the QtCreator is crashing on loading the really big hierarchy of .pro files… and no one of the Qt guys thought about using more than one tft display – thus you only can use one screen for the sources (or resize them manually to fit two screens)…

So my tip: Pleas look left and right and get inspired by other SDKs like Microsoft, Apple & Co. – all of them have tools supporting hughe software projects and more than one screen – ah: and document architectures ;-)

I love developing in Qt, but reaching it’s limits is my daily pain. So it’s very annoying to see that each new development is just for polishing some animations or gui effects, instead of solving fundamental lacks of the toolkit.

Best regards,
Chris

Daniel says:

@3DH Please report every crash you encounter, we know about NO crash in the .pro file parsing.
I’m pretty sure that Qt Creator’s source code has more then 250 thousands lines and we are all using Qt Creator to edit that.

Aamir Maniar says:

Thank you very much Lars. Nice article…

Adam Higerd says:

@ddriver: Unless you work for Nokia, you can’t claim you’re the “main provoker”. >.>

You said “with the overhead of having to use QML, JS, interpreter, VM and glue code” — this is, simply, false. If you think this is overhead at run time, then you don’t understand what declarative means. As I’ve been saying in the comment thread of every relevant Labs post, declarative means that the JS is getting used to define the user interface — and then it GETS OUT OF THE WAY. It has no run-time overhead after the interface has been constructed, except for possibly some lingering RAM usage if the VM isn’t torn down. As Lars said in the post, you can use QML as a better .ui file.

The QML components are still QObjects implemented in C++. You can connect C++ signals to their slots. You can connect C++ slots to their signals. The performance of this will be no worse than signal dispatch in Qt4.

However, Qt Quick is *faster* than QWidget for most operations, even for the same kind of use cases. So not only do you not have this alleged JS overhead at run time, you actually have LESS overhead because it’s a more efficient underlying architecture.

Now, if I’m wrong about any of this, I’ll be standing right beside you complaining. I don’t like the idea of having to write my apps in Javascript either; I get enough of that in my other jobs. But everything I’ve seen so far indicates that my conclusions are sound, and posts like this one reinforce that. Nokia HAS been paying attention to the community; it just doesn’t have the manpower to have a QML-based desktop-QWidget replacement available by 5.0.

Dian says:

“We have promised to try to keep as much source compatibility with Qt 4.x as we can. And of course this includes QWidget and your application written in C++. This is not going away”

Who and when complained about QWidget going away? Did you even read those “concerns” before you rushed into “clarifying” by repeating what has already been said many times over?

///////////////////////

“New user interfaces such as the Windows 8 Metro UI are not things we could simply add to our existing QWidget infrastructure. Adding support for the kind of animations used in these user interfaces is extremely difficult using QWidgets.”

So why is the ease of Qt Quick exploited to enforce QML instead of simply making the new API open for native usage?

//////////////////////

“And QML/Qt Quick was the answer we came up with to solve this problem. That’s why we’re investing in that area.
Our experience with QML over the last years has shown us that it is the superior technology for building UIs in the long term”

QML is just the interface to that “superior technology” not the technology itself, the language to use that backend could be any of the existing languages, not nessesarely QML and surely not EXCLUSSIVELY QML
I like to keep it simple, and there is nothing simpler than using the Qt Quick C++ backend with a native C++ frontend, thus removing the need of QML, JavaScript, QML interpreter, JS virtual machine and glue code.
I do agree that the Qt Quick backend is SUPERIOR to the QWidget backend, that is why I feel its nessesary to insist on a native C++ frontend so that we can develop adequate to our time native C++ applications.

//////////////////////

“What we did with Qt 5 is to add another option into the mix”

The problem is you add the new optional GUI framework without providing an optional C++ frontend. So it is no longer “simply an option” as it has deeper implications. PySide is an option, and whether you pick C++ or Python, you get the same functionality, just different language to access it, with QML you must either settle for QML or miss out on the functionality of its backend, which is the result of most of the development efforts, dedicated to Qt the last 2 years.

//////////////////////

“The expectations towards application UIs are changing drastically, especially when creating consumer-facing apps.
We need to have solutions available if we want Qt to stay relevant.”

So where is the relevant native C++ UI framework? And again it boils down to this rather non-optional choice, adopt QML or get left behind with a dead end, last century UI API!

What a better way to keep Qt which made its name as a C++ framework by adding a modern UI C++ API, something you are not doing by exposing the SceneGraph exclusively to QML. And since we are at the subject of keeping Qt relevant, how about some official dedication to support RELEVANT MOBILE PLATFORMS, such as… iOS, Android and why not even WP7? It would certainly help Qt establish itself if those platform ports were not ran by a FEW VOLUNTEERS which don’t really have the capacity to move things. As Danny said – Symbian has been driven into the ground, Maemo was pretty much DOA, and with that rapsheet Meltemi is not looking that prospective either, Qt needs official support, at least for Android, and with that and the option of filly native development toolchain, it can easily blow Google’s own VM based solution away. Nativity is a huge advantage, this is not a fix idea but a fact, supported by performance profiling.

Point of the matter is, Qt is currently the best C++ framework, even with its C++ GUI API being an outdated dead end, but the best is not really enough IMO, considering there is not that much competition to begin with, and “the best” can get TREMENDOUSLY BETTER, and very close to PERFECT if those little additions of a contemporary native UI and official support for major mobile platforms are added, and if the SUCCESS OF Qt is really a PRIORITY to its managers, those decisions must be made, since apparently what’s best for Qt IS NOT EQUAL to what’s best for Nokia.

Andy says:

I have to throw in with danny, ddriver, 3DH, and Dian.

I started to use Qt in 2000 because it was a great C++ framework that fit my needs perfectly. I write desktop applications. While some people think they are going the way of the dodo next week in favour of mobile “touchy” apps, I think their assessment is premature. I think each platform has its strengths, but I really dislike this trend of bringing the mobile UI interaction to the desktop [Windows 8, Mac OS X 10.7].

I’m not the least bit interested in QML and I don’t want to be forced into it. I want a solid C++ UI framework. First and foremost, to me this means tracking changes in the current OS releases to make sure that applications developed with it look native and act natively.

With all this QML, javascript, and mobile distraction, it seems obvious that the desktop part of Qt is being left behind in pursuit of… something? This post doesn’t do anything to alleviate that feeling. And as Dian points out, Qt doesn’t even support the two mobile platforms I would even consider doing any development for – Android and iOS.

vpicaver says:

I’ve started using QtQuick back when it was first released in 4.7 to build a large application (currently only 40,000 lines). The app maps underground cave systems. It far far easier to write QML code than if I implemented my application in QWidgets. QWidgets don’t have the same fine grain control as QML. Compared to QML, QWidgets are very constraining, hard to extend, slow to write. QWidget shines if you’re going to write a boring, static, and unimaginative interfaces. I’ve written thousands of lines of QWidget code at work.

I find the hardest part of interface design is maintaining context (state changes) and interaction. Doing this in c++ requires you to implement several event handlers, create a state machine (these are always buggy), and write tons of gets and sets, to couple related classes together. The c++ code usually turns into a spaghetti of signals and slots and sometimes back-end logic makes its way into the QWidget code. In contrast, I find that implementing interactions, and creating states in QML is way faster to write. This allows me to provide a better experience to the user. I’ve also found that it’s way easier to glue c++ objects together in QML than it is in c++, which is surprising.

I like QtQuick, it rocks. :D

David Johnson says:

Wishlist: Update Graphics View for Qt 5. I would love to see it use the scene graph (even if it means changing the QGV API somewhat), and love to see more indexing models and even the ability to add your own indexer.

GentooXativa says:

Nice post, keep the good work!

Adam Higerd says:

@Dian:

“Who and when complained about QWidget going away?” — Plenty of people. Just not you. Don’t complain about what’s not being directed to you.

“So why is the ease of Qt Quick exploited to enforce QML instead of simply making the new API open for native usage?” — You haven’t been reading what people have been saying to you. It’s a UI definition, and you can still interact with it from C++; doubling up the API would be bad for everyone except rabid C++ zealots.

“thus removing the need of QML, JavaScript, QML interpreter, JS virtual machine and glue code” — Those components are going to exist whether you use them or not, and separating Qt Quick to be less coupled to the API designed for using it will only hurt performance, bloat the codebase, further increase the runtime RAM footprint, and increase maintenance burden. And what benefit do you gain? You can write your UI description in a more verbose way to shave off a couple milliseconds from application startup and accomplish exactly the same results.

“So why is the ease of Qt Quick exploited to enforce QML instead of simply making the new API open for native usage?” — Because it is, again, DECLARATIVE. Defining an animation by invoking a callback every frame is weighty stuff. Defining the animation up front so that it minimizes the per-frame work allows the animation to be done more smoothly with less CPU overhead as well as the possibility of GPU acceleration. So you want to pass exactly the same data to the animation declaration using C++ code instead of Javascript? This goes back to the “takes more code to accomplish EXACTLY the same task for no benefit except that you don’t have to dirty your hands with JS” argument.

“And again it boils down to this rather non-optional choice, adopt QML or get left behind with a dead end, last century UI API!” — Two words: So what? Evolution happens. Apple did the same thing with Carbon and Cocoa, and got much of the same complaints, but ultimately maintaining the older API wasn’t worth the costs, and Apple dropped support for Carbon-based UIs for x86_64. And before you call me out on making an Apple example, look at what Microsoft has done — they still support the Windows 3.x APIs now, and you can still write code using them if you want to, but they’ve evolved from that and implemented new tools, new libraries, and new APIs as the older stuff proved that it wasn’t going to be sufficient, and you can’t write a Windows application in C++ if you want to use the latest-and-greatest stuff which is only exposed through .NET — which means writing code in C#, because Managed C++ is full of problems; too bad if you like C++ and don’t like C#!

Dian, I’m a C++ fanboy myself. I’m most in my element in C++. But I’m a practical engineer. I realize that there are finite resources in play, from both technical and manpower perspectives. I accept that there are dramatic changes that have to be made to get away from the problems of the old way of doing things. There is no hope for fixing QWidget to have the kind of performance Qt Quick has (believe me, I’ve looked; I’ve been involved since Qt 4.0, and in 4.2 QGraphicsView showed just how slow QWidget really was, and the entire architecture just doesn’t scale) so that means that Qt Quick is where future development *needs to be*. And I accept that it just isn’t practical to maintain a C++ API for the few people who are just so disgusted by the thought of using an interpreted language that they refuse to use anything else. That means that I’ll deal with the minor ugliness of needing a .js file in my project if it means that my final result is better. I still get the full power of Qt and I can still write all of my application logic in C++ using all of the excellent tools provided by QtCore, QtNetwork, et al.

If anything, having to use QML just IMPROVES the quality of my code by making it even more valuable to use a good MVC design. With QWidget I could get away with being sloppy.

Adam Higerd says:

@Andy: I agree that it’s very frustrating that Qt 5.0 won’t have a first-class desktop UI toolkit. I won’t be migrating away from Qt4 until it does.

But it WILL have one. It’s been stated in multiple posts in the past that they ARE working on desktop components. They just won’t be done in time for the 5.0 release. The work has been being put on addressing the use cases that can’t be handled with the existing tools. Maybe YOU would be better served by having special attention given to YOUR use case, but you already have a solution that works! People who need high-performance mobile APIs, or people who aren’t well-served by static interfaces, or people writing apps that aren’t well-served by native-looking UIs did NOT have a satisfactory solution in Qt 4. (Solutions, yes. Satisfactory, no.)

With the release of Qt 5.0, the underlying implementation of Qt Quick will be essentially complete. At that point, Nokia can start working on providing a replacement for QtWidgets.

Dian says:

@Andy – Actually, by native I mean native binary, not OS native UI elements – if you want that, they by all means, QWidget suffices. I am not a huge fan of native interface thou, native UI does have its application but my problem with Qt is actually the other direction – custom, dynamic, interactive user interfaces, and the fact the API backend that makes those possible is exclussive to QML, under claims that a declarative language is a necessity, when in fact every UI structure can be expressed in a good old imperative way, with all the benefits of platform native code and none of the overhead introduced by QML. I really DO LIKE the concept behind the SceneGraph, it is more artist oriented (I am an artist doing some programming on the side), less constrained, that is why I insist on opening the API to a native (C++) frontend. Those who have problems expressing their designs in an imperative way – feel free to go for QML, I don’t find C++ limiting in this regard.

IMO it is a better thing to have your application look the same way you intended it to look across different platforms rather than have your application look different based on how someone else decided that OS elements should look like. And it is not just that, heck, that alone is totally possible and quite easy to do with QWidget, but the optimization for animations and states, the modularity and last but most certainly not least – the performance of the SceneGraph.

And.. it is not just that, I find the prospect of protecting the integrity of Qt attractive on its own, it is OK to offer new options, but I’d prefer the capabilities of Qt to be fully accessible through C++ frontends, with alternatives being optional, C++ is the sole reason I chose Qt to begin with, and with QML getting the SceneGraph based UI API exclusively, the next thing you know some other new API will be exclusive to QML or god forbid, some other language, and so on and before you know it, C++ will remain locked away in the low level backends just like it has been locked in so many other frameworks, and in that moment C++ will no longer be usable for developing applications, but for extending frameworks that use other languages without offering the option of keeping your code 100% native.

Adam Higerd says:

As an aside, to people talking about Android and iOS:

Honestly asking for Qt on these platforms is wishful thinking, but Qt Quick is going to be important to supporting them if it IS going to happen. Android didn’t have support for writing applications in C++ until fairly recently! And trying to provide a native-feeling experience on iOS with QtGui would be an exercise in tedium; QtGui’s support for gestures (multitouch or otherwise) exists, and it works, but it’s a lot of work to use it. Proper integration with the rest of iOS’s features is something that would be very difficult to provide with a generic cross-platform toolkit.

Given these challenges and the fairly narrow scope of applicability, it doesn’t seem to be in Nokia’s best interests to pursue them as first-party tier-one (or even tier-two) platforms.

But if you really want to know:

Qt on Android: http://labs.qt.nokia.com/2011/02/28/necessitas/
Qt on iOS: http://labs.qt.nokia.com/2011/08/09/update-on-uikit-lighthouse-platform/

Dian says:

@Adam Higerd – I am getting sick of you sounding like a broken record. If you cannot conceive a way to define a UI in C++, that is ENTIRELY YOUR OWN PROBLEM, I can. And if you are at least remotely familiar with the way interpreters work, they translate the declarative code to imperative to drive the imperative C++ backend. And since I have no problems describing UIs directly in imperative mode, I want the option to be able to skip the declarative part of it and all the overhead it introduces. In fact a C++ API with the capabilities of Qt Quick is quite easy to conceive, and with constructors and parameter passing and without extensive braces, the C++ core will be shorter and cleaner to the eye.

“Those components are going to exist whether you use them or not” – so you are saying, even if a native fronend to Qt Quick was avaiable, it would still include all the stuff that IS NOT NEEDED if you don’t use QML? This is pretty stupid…

“Apple did the same thing with Carbon and Cocoa” – this has nothing to do with the issue at hand, Apple introduces better backends that are still natively used, without extra languages, interpreters, virtual machines of whatsoever. I am NOT in favor of keeping the outdated QWidget backend, in fact all this time I’ve been complaining C++ developers are isolated to it, I am in favor of the new backend, I only want to use it natively, if you failed to understand this simple concept after so much repeating, then you are hopeless. The problem is not about the backend API, it is all about the front ends those APIs are exclusive to, without any necessity to be this way. The reason I never bothered with MS is exactly their PIMPAGE of C#, that is why I chose Qt, and how Qt is doing the same thing with QML, making the latest and greatest improvements only available through QML, well I am truly sorry that I have a problem with Qt marching the same moronic, motivated by corporate greed way as .NET

3DH says:

@Dian: Great post!

We use QWidgets for writing very complex GUIs for more than ten years. With the QtDesigner and the QUiLoader class this task got simple and with less C++ coding – just draw your UI inside the designer, manage your signals and some simple gui logic by simple mouse clicks, load that .ui file dynamically inside your C++ app with the QUIiLoader, add some handlers for the signals using the auto-connection feature of QMetaObject and: ready!

But: Introducing QML means: Glued language, need of OpenGL (cool: nearly all of our industrial embedded PCs don’t support that – ever thought about that?), shader language and a special syntax which is a pain to learn and a fully overload for the target audience: Our “designers”.

No one of our designers ever wanted to hack HTML, CSS and JavaScript – and now they must learn much mor to replace the formerly simple task of drawing some guis inside the Designer – they must learn different languages and have to learn how to code… It was quite shocking for some of them… but it seems that designers @ Nokia ever wanted to get programmers ;-) …our creative masterminds on the contrary not ;-)

It’s a fact that QML tries to beat the C++ native APIs (which are the base of Qt’s success – please don’t forget that!) in the point of functionality – simple to see, if you see how many functions are only accessable inside QML… So: The Qt guys have one viewpoint and this one doesn’t reflect the wishes, expectations and fears of the originally Qt users: C++ programmers!

As Dian mentioned, Qt is currently the cleanest and most well documented (platform independent) C++ API around – but it’s success is limited by the shrinking support (further development) of the native C++ APIs and the missing support of the market leader plattforms iOS and Android.

The last point is one result of Nokia’s role in the market and some (typical) wrong descisions, which already took Nokia the market leader position and decreases Nokia’s stock quotations for a long time.

Fact is: Meeting up in mailing lists and Qt events showed me, that the biggest part of all commercial customers and maintainers from the open source world need / work with the C++ API only. Just a small, but growing number of developers reduces the C++ part and concentrates on QML.

If we only concentrate on the QML audience, we risk to loose many long term customers/developers to other toolkits – e.g. because of missing target platforms and stopped development of C++ APIs.

I know Qt and all companies working on it for more than a decade: And all it’s good and bad descisions – QML is a good addition, but no point to only concentrate on. Currently it’s dangerous to ignore the C++ users and their fears – even I as commercial customer have growing concerns towards the stability and features of further Qt C++ APIs. Currently it seems that every C++ user has to handly many additional requirements and libs to get the native C++ app running – apps which now must have OpenGL (which is nor needed for fast QWidget GUIs) and QML – making binaries larger and deployment processes more complicated or impossible (see: indsutrial PCs without OpenGL).

In situations like this one I’m wondered where Nokia got it’s descision reasons and who is the new target audience for Qt? And what’s about the formerly so important Qt audience (C++ developers)? Are we not interesting for Qt any more?

Just my two cents…

Stephen Chu says:

All this is confusing and uncertain.

All I want to know is if QML is the way to go for UI in Qt, how (or even when) can I easily hook up my C++ backend with QML UI in my desktop application? And how easy can it be to create my own custom UI item like for example a high-performance large image viewer/editor? I have a custom QGraphicsItem for that and it’s pretty easy to do with all the tiling and threading function. How and when can I do that with QML?

3DH says:

@Stephen: Very good point! I’m developing industrial image processing applications and wrote a special QPainter to support hughe Images (16MB and more) to be displayed extremely fast on QWidgets – so: How to realize that in QML?

But: Who of the Qt guys already thought about seniour developers solving high performance issues? Currently they only focus on fancy looking end-customer apps for the masses – not a bad point, but one shouldn’t only focus on some end users while ignoring a big number of loyal longterm cutomers.

Qt guys: You made a good job with QML, but maybe it’s a little bit too early for Qt 5 and little shortsighted to ignore the C++ audience.

Stephen Chu says:

@3DG: You got off easy. Mine has to handle multi-channel images at hundreds of MBs with proprietary compressions. It overflows the 16-bit coordinate space I used to work with (QuickDraw) :)

Anyways. I like QML but Qt has remember it has to make it easy to use with serious applications which typically have huge C++ backend. Maybe I didn’t try hard enough. But I still can not figure out how to exactly use it with a sizeable C++ core, mobile or not.

Sam says:

3DH: No one of our designers ever wanted to hack HTML, CSS and JavaScript – and now they must learn much mor to replace the formerly simple task of drawing some guis inside the Designer

Designers in most companies won’t code in any declarative language. This quote by 3DH goes against the idea of workflow separation between coders and designers that QML is trying to achieve. This separation has been tried countless times in countless web frameworks before. And it constantly fails when put into practice.

Dian: I really DO LIKE the concept behind the SceneGraph, it is more artist oriented (I am an artist doing some programming on the side), less constrained, that is why I insist on opening the API to a native (C++) frontend.

On the other hand we have an artist (an artist!!!) wanting C++ imperative access to the SceneGraph backend. I think this proves that “There are more things in heaven and earth, Qt devs, Than are dreamt of in your philosophy.”. With this I mean: just provide the world with a single, powerful, neutral language. i.e. C++ (That’s what you did for over 10 years). People are going to use it in unexpected ways, so all assumptions about coders and designers are bound to fail.

Dian says:

@Sam – not only just an artist, but one who has written plenty of declarative HTML. What I mean is I am not in the dark, I am a designer, I have written web pages in declarative and applications in imperative, and I honestly prefer imperative for applications, and I want to distinguish APPLICATIONS from websites, claimed to be APPLICATIONS. A funny story – some guy from MS was bragging about some HTML application being cross platform like it is the greatest thing ever, well DO’H, it is HTML, it’s almost like saying “this .txt file is cross platform” just because you have text editors for different platforms. I accent on this because I am actually familiar with the atrocious performance and efficiency of web applications, and recently I even tasted a simple card game, written in HTML5 and JS vs the same version, written in C++, needless to say the C++ version got almost double time with a single battery charge, which is nothing to sneeze at, and memory footprint was much lower too.

That is why I insist on preserving the nativity of Qt, with the breaking of it only being optional, not mandatory.

Adam Higerd says:

@Dian: Pot, meet kettle. If I sound like a broken record, so do you. You’ve been rehashing the same points in every comment you make.

“If you cannot conceive a way to define a UI in C++, that is ENTIRELY YOUR OWN PROBLEM, I can.” — I don’t know what the bloody heck you’re talking about. I already DO define my UIs in C++, because I can’t stand visual UI editors. QML is by far the lesser of two evils; I at least still get to build my interfaces in CODE, where I have actual control over them. If there’s something I can’t conceive of, it’s a way for Nokia to add a C++ API to Qt Quick without hurting it in some fashion. It’ll increase the surface area for bugs, slow down the release cycle, increase compile times, and increase library size.

“so you are saying, even if a native fronend to Qt Quick was avaiable, it would still include all the stuff that IS NOT NEEDED if you don’t use QML? This is pretty stupid…” — That is exactly what I’m saying, and there’s no avoiding it. It is a literal fact. That’s just how dynamic-linked libraries work. The options are to either have it in one library, or to put a lot of work (and a lot of regression risk, and an increased surface area for bugs) into decoupling the code so that it can be separated out.

““Apple did the same thing with Carbon and Cocoa”” — It’s more similar than you realize, sir. It may be “native” in terms of being compiled mostly down to machine code, but Obj-C does have a dynamic runtime and garbage collection and all of those other things you associate with bytecode languages like Java, C#, or Javascript. The same arguments were made — people not wanting to use a new language when the existing system was working fine, people not wanting to move away from a feature-rich toolkit for one that hadn’t yet reached parity, people just plain not liking the API. Furthermore Cocoa recommends the use of declarative resources instead of instantiating UI components in code. It’s actually a rather apt comparison and I wouldn’t have brought it up if the metaphor broke down so quickly.

Dian, if you want people to take your arguments seriously (and I’m talking about more people than just me, I mean Nokia and the people making the decisions about what’s worth implementing), you need to make sure you’re coming off as something besides a pro-C++ anti-JS zealot. It’s already been established that there is no performance penalty to using Javascript to create a declarative UI. So if you want your argument to get anywhere, you need to give concrete reasons why a C++ API would be worth the time it would take someone to implement it, beyond just “I don’t want to write Javascript”. And remember that in this post Lars pointed out that using JS for functionality (as opposed to UI definition) is unnecessary if you don’t want to do it, so you don’t have runtime overhead.

Based on my understanding of the problem domain, the only remaining runtime overhead is the RAM usage of having the VM instantiated even if you’re not using it. Outside of the syntactic preference of language, this is the only thing that a pure-C++ implementation would gain you.

David Johnson says:

I want to back up what some others here have said. I think QtQuick is a great idea, but it’s not a one-size-fits all solution. The scenegraph is itself written in C++, so I’m having a hard time imagining why its design would preclude use from C++. I understand that scenegraph pretty much excludes QPainter, but I don’t understand why it should exclude C++ as well.

I haven’t played with QtQuick 2.0 yet, but I found it very cumbersome to use a C++ backend with QtQuick 1.0. I was constantly writing ad hoc abstract item models, subclassing standard Qt classes to expose new properties, etc. If I have to do that kind of stuff I’m wondering why not just use HTML5/WebKit instead of QML/QDeclarativeView.

Don’t get me wrong, I think adding QML to Qt was a great move. I’m even willing to graduate out of widget/painter school. But I want to code in one language, not three.

Dian says:

@Adam:

Qt Quick has a C++ backend, as mentioned over and over again. QML source gets interpreted and drives the backend. But why use QML if there is an option to do it directly? I don’t think it is an issue of hurting QML, it is more like an issue of not depriving QML of exclusive access to Qt Quick. And if the backend has been designed from the ground up to conform to QML, some redesigning might be needed, but it is not that much of a difference whether you parent components by nesting them in QML or by procedurally instantiating them and passing the parent as a constructor parameter, or by nesting the elements in a C++ class definition and doing some binding in the constructor.

Your argument on the inevitability of an interpreter and virtual machine does not stand, just because the API is currently designed that way, if native C++ frontend is to be added all those can easily be excluded, and glue code is automatically left out. If you have everything compiled to native machine code you don’t need an interpreter and a virtual machine, so those can be removed, as simple as that.

C++ also has dynamic runtime capabilities, even if minimized to the bare minimum, the same applies to garbage collection, which is simply user explicit explicit or object implicit instead of automatic, but so what? Objective-C is not the same league as C#, JS or Java just for sharing a similarity, heck even JS and Java are not in the same league even thou they share “java”. Objective C is still a compiled language, Apple are taking advantage of keeping their application chain native, which does result in better user experience and more efficient utilization of the underlying hardware. And this comes form someone who dislikes Apple with passion.

“Furthermore Cocoa recommends the use of declarative resources” – yep, RECOMMENDS, not MAKES MANDATORY. Again, that ocean of a difference I keep talking about.

Sure, you can keep JS to a bare minimum, in which case the overhead comes from all the glue code and having to design your objects with from the ground up with the idea of how to interface them to QML, you have to deal with limitations, abstract objects, proxy objects, loading stuff, exporting stuff – all this 100% avoidable by keeping development native. Also even rudimentary JS scripting can produce visible hiccups and if you ever bothered to take a look at the QML profiler, most of the processor time is being wasted by JS, which is avoidable too, it may not be much but it won’t hurt to avoid it. Many people make similar arguments “what do I care if a bit of logic takes 10 or 100 msec” but considering this bit of logic repeats over and over again, and millions of people do it, at the large scale that minimal waste grows to be considerable, and it is there whether you realize and acknowledge it or not. It can be avoided too.

And most certainly it is not just the resource overhead of the VM, there are many types of overhead that apply in different areas, some more prominent, some less, point of the matter is since it is technically possible to avoid it, there should also be an option to avoid it.

Dian says:

@Adam: Also, if your application has like 5 custom objects, then glue code is tolerable, but if your application has 50 or 100 or even more custom objects, then QML becomes a heavy burden. I don’t know what kind of applications you are developing, but my view of applications extend beyond lists of icons to twitter or other web services. There is this new trend of creating website interfaces for mobile devices, whose screens are too small to view websites normally, and calling those “application”, but those are “applications” with very limited application. I mean serious, productivity oriented software, with lots of custom objects and lots of logic, implementing those in JS is simply not an option, and doing it in QML is unnecessarily tedious due to all the interfacing you have to do to your objects so you can use them in QML, just to take advantage of an up-to-date GUI API.

Adam Higerd says:

@Dian:

“QML source gets interpreted and drives the backend” — This is false, and may be the entire problem underpinning your arguments. QML does NOT drive the backend. QML source is interpreted and is used to generate objects and data structures. After this is done, the QML source doesn’t drive anything; it never gets invoked again unless you intentionally do it (for example by defining an event handler in JS instead of in C++). You say you understand how declarative works yet you keep complaining that Qt Quick is making Javascript take over the application… and it doesn’t. As I keep repeating, QML sets it up and gets out of the way. It doesn’t drive anything.

“Your argument on the inevitability of an interpreter and virtual machine does not stand, just because the API is currently designed that way, if native C++ frontend is to be added all those can easily be excluded, and glue code is automatically left out. If you have everything compiled to native machine code you don’t need an interpreter and a virtual machine, so those can be removed, as simple as that.” — It is inevitable because people WANT the interpreter and VM to be there, because some people DO want to put UI logic in Javascript. If you want to remove the VM, it’s going to take more than just gluing on a C++ frontend, because the backend wasn’t DESIGNED for it. The code isn’t decoupled enough to be able to cleanly separate them without a substantial amount of effort. And it’s not decoupled because the advantage of decoupling it is… that you can write code in [insert favorite language here] without using Javascript. There’s not really any other advantage to it, and this is where you have to prove your case if you want to change anything.

“C++ also has dynamic runtime capabilities” — This paragraph is drifting pretty far off the topic of whether or not it’s appropriate to add a C++ frontend to Qt Quick. It’s not worth fighting about; it was only a supporting point, and being wrong about it doesn’t harm the rest of my argument. (Because whether I’m “right” or “wrong” about this depends on how you choose to classify some of the nitpicky details, and I never claimed it was a PERFECT metaphor, only an apt one. You can defeat any metaphor if you try to carry it far enough.)

“all this 100% avoidable by keeping development native” — I wouldn’t say 100% by any stretch, because a C++ front-end to the Qt Quick architecture is still going to use the Qt Quick architecture. Your profiling shows hotspots in the JS, but without actually TRYING it how can you be sure that you wouldn’t have hotspots in the same or similar places using a C++ front-end? Perhaps what you’re finding is parts of Qt Quick that needs to be optimized regardless of how you interface with it.

Technically possible doesn’t mean practically possible. The benefits and costs have to be weighed. It is Nokia’s opinion (and mine) that the costs aren’t worth the maintenance burden. If you want to expose a few private headers and implement a proof of concept that shows that the Qt Quick backend *CAN* be driven from C++ without loss of functionality and with a gain in performance, that would be the best argument of all, but right now the people who know how the code works aren’t considering it worthwhile.

Benoit Walter says:

It is true that people do not like changes. And if you already experienced bringing up a new project to a company, you know that there will be a huge resistance, whether the change makes sense or not… And that’s only much, much later that the benefits will start to be understood.

Now back to QML vs C++. Before criticizing the new approach, you should really understand that besides the mobile devices, the clear winner is the Desktop of Tomorrow. A modern Qt Desktop Application will have more animations, more contextual actions, more natural interaction. And the developers should have the proper tools to develop such applications.

The release of the QML Desktop Components is just one step that brings the traditional desktop UI functionalities to Qt Quick. But the next steps will be more interesting and there is no doubt that we will see new UI standards emerging. The new modern components will completely change the user experience that we currently know. And the superiority of QML for defining the UI logic will become obvious with the time.

Let’s take a simple example: enabling and disabling widgets depending on the state of other widgets (checkboxes, radiobuttons, …). Using an imperative language, you will need to manually connect signals and slots, implement a dedicated function which combines those states and explicitly enable or disable the dependent widgets. With QML, this process is pretty straightforwards, you just set the corresponding property for the respective UI elements.
Now if you go one step further and have even more interdependencies between UI elements, you will quickly understand that the imperative code will be almost impossible to maintain. And if you add animations or other visual effects, you will anyway switch to a declarative language or go back to the old standards (using something like Lotus Notes UI guidelines in your 22th century application ;)).

And again, everything will be obvious as soon as the next-generation UIs see the light.

Joe Blow says:

So where is the Qt Creator written in QtQuick? Seriously, where is it? And what about Qt Designer, QtLinquist, Qt Assistant? Surely Qt eats it’s own dogfood…

Dian says:

“You’ve been rehashing the same points in every comment you make.”
Well, DO’H, it is called consistency, should I come up with different points and different directions just to make you happy? I repeat the points, relevant to the issues at hand, and those will remain constant unless circumstances change.

“This is false, and may be the entire problem underpinning your arguments. QML does NOT drive the backend. QML source is interpreted and is used to generate objects and data structures”

Did it ever occur to you that by driving the backend I mean object instantiation and hierarchy construction? Naturally, after objects and structure is established it is the backend that drives itself. I didn;t assume I have to explain it in such a noobish way to you, just so that you don’t get the wrong idea of me having the wrong idea about how stuff works behind the scene (something that seems to fit your scheme of wishful thinking BTW).

Those who want to use QML use the QML runtime, those who want to use native C++ use the native runtime, which needs no extra stuff and thus has no extra stuff.

How can I tell JS hotspot logic wont result in native code hotspots? Well, I don’t think I can explain this without driving too deep into how interpreters, virtual machines and CPUs work. Just take it on trust – the majority of the hotspots created by JS can be totally eliminated, and the few that will remain due to logic complexity and extensive arithmetic will be significantly reduced. So technically you are correct, it is not 100%, more like 95+%. HOWEVER it would seem your attention skills need improving on, since this 100% figure was not aiming at the JS hotspot induced hiccups which CAME AFTERWARDS, the 100% figure was in regard to the numerous types of glue you have to use to expose C++ elements to QML. So my point remains valid, you are only correct on the incorrect point you made I claimed 100% of the JS hotspots were avoidable, which I did not claim, and if you look closer, for those I only used “avoidable” without any concrete numbers. PWNED ;)

And even if Nokia and you happen to share the same opinion, I doubt it comes through the same type of interests and motivation. And after all that lack of objectivity and lame attempts to make me look foolish I have a strong doubt in the validity of your statements, your claims of being unbiased and a C++ fan seem more like camouflage aiming to lubricate your opinion into establishing itself. Feel free to deny it, it is only natural behavior. Just know the directionality and bias of your responses has long deprived you of credibility in my eyes, so you can save yourself the efforts.

Adam Higerd says:

@Joe Blow: As mentioned, Qt Quick desktop components aren’t ready for 5.0; I’m sure Nokia WILL eat their own dogfood when the components are ready.

Adam Higerd says:

“Just know the directionality and bias of your responses has long deprived you of credibility in my eyes, so you can save yourself the efforts.” — That goes two ways, but I do at least thank you for giving some more concrete points than just “I don’t want to write in Javascript”.

stottle says:

@Dian,

I know there are silent masses who just read these posts and comments, and a small number of vocal participants. Your rants have now pulled me in with my first post. I think Qt’s approach is sound, and the idea of exposing it through C++ is, umm, silly.

It takes a paradigm shift to work in declarative code. I find I am still learning the paradigm. But QML breaks things down very well into basic building blocks to be combined into a UI. With (in my case) a C++ backend.

I don’t think it is possible to expose the new paradigm effectively in C++, unless you want to instantiate the objects and then call setProperty for every change from a default parameter, until you basically end up with an ugly, verbose C++ code that looks a lot like the QML you want so much to avoid. And instead of making changes in QtCreator or a text editor and reloading, you’d need to recompile to see any changes. Where does that make sense?

Do you also argue against using XML and JSON to store or pass data? It is useful, standard, but not C++. So must be bad, by your arguments. I can only speak for myself, but I appreciate what QML allows. QSGPaintedItem is not that hard to use if you need to run QPainter based code with QML, either.

Thanks Qt for all of the good work.

David Johnson says:

Benoit, you are making a common mistake, that most of a desktop UI is composed of widgets. This is not true. To look at the most common UI pattern, you have a main window: one central widget, one menu, maybe a toolbar, maybe a status bar. That central widget is primarily a custom view of the application data, and is very rarely a drop in component. Sometimes I’ve been called in to write a UI that is little more than a jumbled mess of widgets, but it’s very rare.

Your story about the horrors of managing widgets is mostly fiction. If it occurs it is due to bad UI design which no change in language is going fix. It also misses the point that I can already use the state machine and animation frameworks with widgets. No need to go to switch to a different language to get it.

David Johnson says:

Widgets as window system objects is outdated. The linear model of painting is outdated. I don’t think there is any argument at all on that point. But the reason we are supposed to use QML/Javascript instead of C++ is because of a *design* decision. There is nothing in the nature of fluid dynamic interfaces that precludes C++. Nokia/Qt has decided that there will be no C++ in the front end, and that is that. End of story.

Erik Schwartz says:

I have the feeling this whole Qt5 Qt Quick thingy is disruptive just for the sake of it.

We had QGraphicsView which was not perfect but ok. Now with Qt5 we get scenegraph which again is differrent and has a hard requirement on OpenGL. Graphicsview could at least proxy traditional widgets. I have yet to see a tree view in qml running on scenegraph.
Traditional widgets supported .css. The new Desktop components again seem to be styled in a completetly different way (again). The trolls might enjoy rewritting stuff over and over again (instead of improving). But we just cannot afford this. The costs are just too high.
And this kind of stuff makes migrating really hard and expensive.
Also what was not mentioned before: The complexity of Qt Quick is a magnitude higher than classical widgets. Do you know what this means for people who have to deliver bug free applications on time? We just do not have the resources to find arcane bugs related to JITs Java Script and scenegraph. With QWidgets it was still possible to even fix some of the framework bugs as a 3thrd party (thanks for Qt being open source).

Last but not least: Qt is considerable lacking in many other areas. The item view framework was already mentioned (and I remember some itemviews NG announced years ago…). Qt really sucks in regard to persistance and database backends. The Mac port is in a really questinable state… Qt should integrate a lot better with STL and Boost. The Qt containers are years behind the competition.
I could go on and on…

I understand that Qt Quick ist WPF, FLEX, JavaFX for Qt. But this (RAD, Webapps) never was Qts core business and JavaFX is already dead and I would not call FLEX a success, either.

I can understand the need for fluid uis, but I do not see the need for a VM with Java Script. A pure declarative format would have been sufficient and would have reduced the complexity and food print considerably.
I would understand making Java Script and option like QtScript but making it mandatory is suicide from a business perspective (In my eyes).

It is obvious that Qt Quick is a result of the aquisition, but since Symbian and Meego are dead this does not make sense anymore. No I do not believe in yet another magic platform from Nokia not even announced.

Dian says:

@Adam – It is more like “I don’t want to either write in JS or write glue code”

Qt NEEDS a native C++ and adequate to our time GUI API, even thou all the fuss is correctly about TOY APPS this is just a temporary trend that will soon vanish like Britney Spears did. I applaud the efforts to make Qt trendy, but application development is a serious discipline that shouldn’t succumb that easy to fashion trends driven by marketing campaigns motivated to milk stupid people out of their money.

Here you are concrete points:
1 – QML goes against the concept of Qt being “cute” – using glue code and glue proxy/abstract objects is UGLY and tedious, QML suffices for toy apps but offers more drawbacks that benefits to the development of serious and productive programs
2 – The decision to offer the new GUI API, adequate to our era, exclusively to QML ends up conforming serious application developers to a last century, completely out of date GUI API
3 – Neither point 1 nor point 2 benefit Qt in the long-term, surely, it will gain popularity in toy app developer circles, but it will chase away serious developers and BIG enterprise clients, who will have to do their own GUI APIs just to avoid looking outdated, which makes the usage of Qt pointless
4 – You need what you lack, and what Qt lacks is a modern C++ GUI API.
5 – Keeping it simple has its benefits, and surely, QML is simpler than C++, but anything out of the box you need C++ for, plus the extra glue, and C++ IS SIMPLER than C++, QML and glue in between.
6 – Keeping it native has its benefits, lightning speed execution, bare minimum runtime overhead, improved performance and efficiency and overall minimization of CPU cycles and memory wasted, which are more than welcome, not only on the mobile market but really everywhere considering the environmental condition of our planet and the financial outlooks of our civilization
7 – At this point it would seem no amount of concrete, reinforced steel, titanium, carbon fiber fabric, adamantium or unobtanium points can actually satisfy you, simply because you have no intent to even allow yourself that. You have countered many concrete points with attempts to cast doubt on my competence, with non-applicable and non-relevant statements, you haven’t agreed with even a tiny bit of those points, which would either mean I am 100.000000000%, absolutely wrong on everything, which is statistically improbable, or the more probable fact that you are prejudiced, predetermined and you blindly deny even the obviously valid because of your bias. So the final mystery is why I still act as if there is hope for the hopeless :)

@stottle:
“idea of exposing it through C++ is, umm, silly.”

Because? A bold statement like that is… umm… silly without serious argumentation to support it and give it weight.

Unlike QML, with a C++ frontend you can create and object and set its common parameters by passing them in the constructor of that object, so you don’t even need to do the extra step of setting properties. And for those, not supported by constructors, you can always set it by hand, which is not all that hard. But considering in 90% of the time it is the same parameters, those can be put directly in constructors, and as I’ve stated, a hypotetical C++ frontend for Qt Quick will actually be shorter, faster to write and more readable.

Sure, compilation takes time, but USUALLY the number of times an application is being compiled is lower than the number of times an application is being launched, and taking the penalty once during compilation more than makes up by producing a more efficient runtime for all users of your application. Better to take that overhead once, on a powerful developer workstation that passing that overhead to thousands of people that will be using you application thousands of times. If you prefer the other way around, it is just laziness, selfishness and total disregard for your species in collective, which leads to a waste, considerably larger than the one you will “suffer” having to compile your program.

For storing and passing data I prefer binary, since, as you might have guessed from the direction of my points, I am concerned about efficiency. XML is made so that it is easy to read for people, and also so that it is portable between applications, and on some occasions I DO USE XML, always as an optional alternative to binary, but XML is UTTERLY INEFFICIENT for large data storage, the structuring syntax often takes up more space than the data it contains, and parsing it is much slower too. However, XML is an open standard you can use in numerous places, whereas QML is proprietary and has very limited use, so you cannot really draw parallels between the two.

Adam Higerd says:

@Erik Schwartz: There comes a time when you have to get past the sense of “not invented here” and use existing, mature systems. QWidget has architectural problems that can’t be fixed in an evolutionary manner; there has to be a revolutionary change to get Qt un-stuck.

And for the record, unless something has changed, Qt Quick uses QGraphicsView ;) (it did in 4.8) so it’s not nearly as divergent as you think.

The OpenGL dependency is less onerous than it sounds, too. OpenGL ES 2.0 is available on basically any SoC made in the last 2-3 years, and it’s possible to use a software implementation of OpenGL to satisfy the dependency.

Erik Schwartz says:

> QWidget has architectural problems that can’t be fixed in an evolutionary manner; there has to be a revolutionary change to get Qt un-> stuck.

I agree. I just do not agree with the solution.

> And for the record, unless something has changed, Qt Quick uses QGraphicsView (it did in 4.8) so it’s not nearly as divergent as you
> think.

Qt Quick 2.0 (Qt 5) is based on scenegraph not graphicsview anymore. This is exactly what I am complaining about. Yet antoher disruption.

And OpenGL is an issue. Just think of nettbooks and crappy drivers!

stottle says:

@Dian,

I will grant you that XML is takes lot’s more space, and lot’s more cpu cycles to process than binary data. So given that, why would you ever use it? My answer is that in most cases the performance impacts are so far down in the noise that it just isn’t worth doing anything more complicated.

For the cases where it isn’t in the noise, it is worth the effort and the maintenance headache and the risk of bugs and validation to write the custom code.

So hopefully everyone agrees that there are times when XML is better, and times when it isn’t – although there are certainly differences of opinion on where that line is.

Back to QML. You make it sounds simple and straightforward to create constructors for the QML instances you want to implement. One thing I love about python is the list and keyword arguments you can pass. You don’t have that in C++. With four arguments to a constructor, you need 16 permutations of constructors in order to support all combinations of inputs in C++ (default constructor, any one parameter, etc). So take a look at the QSGRectangle and the number of properties it has, including those defined in QSGItem, etc.. You’re better off with a default constructor and using setProperty.

I don’t agree with your argument about the difficulty of having to make “glue” code either. Fact of the matter is, good code design uses decoupled elements that need to be combined. How is QML + QAbstractItemModel any different that QListView + QAbstractItemModel? Besides the fact that QML is much easier to write, update and maintain?

And if all of this is just to much overhead for you (too slow for whatever application) it is still opensource. Go into the C++ and optimize to your hearts content.

I should also mention, I’m pretty sure I’m not going to convince you. Part of my reason for posting was to help convince Qt devs that you are a vocal minority, maybe there is value in that.

Dian says:

@stottle – your effort to convince Qt developers that I am a vocal minority is admirable indeed. However, I fear it may be in vain, it is not like hordes of trolls are rushing to meet my demands ;) And it doesn’t seem I am the only one, there are still others, apart from the ones the politics of Qt has already chased away to loop elsewhere.

In C++ you can still pass a string as a parameter and parse it, allowing you to pass whatever you want in a constructor. Or a map or any complex data structure you want, it’s a world of possibility, surely it won’t be as straightforward as in Python, but you get like 50x better performance. And surely, objects have scores of properties, but if you were to chart their usage, you’d see the distribution is very uneven, there are a few that are used all the time, there are many that are occasionally used, and many which are extremely rarely used. That is why the most frequent get put in constructors, the rest you can set by hand if you need to, it is not all that hard, and if you write properties setters to return reference to the object you can chain them so that you can type the object instance only once and not for every property. Also, with constructors you get initialize lists, so you save by avoiding the creation of a default value parameter and then assigning it again. Not that you’ve given any hints of being concerned about performance and efficiency or whatsoever, but nevertheless.

Gluing C++ components is effortless, that is why there is like over an hour long tech talk on how to do it, irony aside, I agree it could become your second nature, but it is still ugly and only made necessary by the absence of a not-out-of-date GUI API for native C++ development. And once again, I don’t mind doing it once or twice, but doing it all the time is tedious and gets in the way of development.

I agree XML has its application just as I agree QML has its application. But XML is not mandatory, nor does it offer any exclusive benefits to any other data storage scheme you can suck out of your fingers. And even thou XML is a popular format for its portability and readability, if you take all the data storage on the planet, you will be surprised how little of it is stored in XML form. What I use XML for is never storage, it is exporting of data that needs to be accessed from an application that is not its original creator. Again, no parallels between XML and QML whatsoever, but since you keep on mentioning XML with such vigor, I will use it in an analogy at the end of my post.

You act like having the option to develop fully native apps will somehow hurt QML. I don’t see any logical reason for you or anyone else to be against the concept of keeping Qt dedicated to native C++, where QML is what it needs to be – an option. Will you share your motivation or are you just keen on being with the status quo. What you are doing is equal to pimping XML and claiming we don’t need any other, technologically superior solution, just like you claim all we need is QML and no native alternative to use the SceneGraph. It’s just foolish on its face. XML is just for trivial data storage, just as QML is for trivial application development, and developers need a modern C++ API for serious applications just as much as the enterprise needs all those data storage solutions that wipe the floor with XML. You don’t see me insisting we need to use only and exclusively C++, you see me requesting the option to use what is one of the best, most flexible and powerful languages out there. I don’t think I am asking for that much, neither for something as absurd as what you are calling for.

Ter says:

Well, here we have some C++ “specialists” (or fundamentalists). IMHO, QtQuick is a real good and promising technology (once we’ll have Desktop components and a better support of the model view framework), I use it everywhere I can for the frontend, even for small data storage. Of course my backend is C++. For information I use C++ and Qt for a long time and for advanced systems (GraphicsView, OpenGL, Network, ModelView, StateMachines, hundreds of thousands of lines of C++ code), and for me it is arrogant to say that it is only for beginners (@3DH). I love C++ and I love QML, yes it’s possible!

I agree with Benoit Walter, people do not like changes, it’s a bit sad.

Anyway, I want to say THANK YOU to all the Qt team (and open governance developers now ;) ) for the real good work. Keep the good work, long life to Qt, including QtQuick!

Dian says:

@Ter – I am astounded there are so many people like you, who manage to get it half way through, and by the time it is all through not get it at all.

I DO AGREE QtQuick is a good and promising technology, note I say QtQuick, not QML. QtQuick is a programming paradigm, a concept, which QML is only used to set up. I don’t want QML dead, I don’t want QtQuick dead, I want QtQuick, a C++ backend, opened for direct native C++ use without the numerous different types of overhead QML mandates. And that’s all there is to it.

Why is this simple concept so hard to get? It is not about fearing change, it is about the option of keeping it native and simple, native is good, simple is good. If you still want the QML route, then be my guest. My quarrel with QML is not its existence, but the vessel to downplay C++ its put in the position of by making the new GUI API exclusive available to it.

It is not about fearing change, I want a change in the C++ GUI API for something better. But QML makes no sense to me, I know it may sound like a very abstract analogy, but if I want to speak to a German person and I know German, then I’d like the option to just speak in German to him, not speaking in English to some voice recognition software, which then uses an online translator to translate into German and then synthesizes German speech I present to that German person, which is essentially what the QML, JS, interpreter, VM, glue code and objects do. I KNOW GERMAN, if you get my drift.

Fonzi says:

Qt Quick is the first technology I have been able to effectively use both for rapid prototyping and for more serious applications involving a C++ back-end. Every other framework available today that I’ve tried only delivers on one of those two aspects (and even then, it typically does not deliver as well in that aspect as Qt Quick). I agree Qt Quick needs time to mature (it is a relatively new technology as was pointed out), but I can’t see a reason why one wouldn’t want to develop UIs in a declarative environment (particularly once Qt Quick reaches a sufficient level of maturity to include desktop components and other additions).

As a few others have said, thank you Qt team for this effort. I am very excited for the Qt 5 release. :)

Ok, without getting into the whole complex argument that if QML is the best option or not for the Qt Quick framework…

As a commercial developer, how do you protect you code IP? if the code is interpreted, that means that you must include the code with your application, either through text files, internal database or compiled in as a resource, I can’t seem to find a method secure enough (like compiled binary code) to distribute my application without worrying about my code being stolen, or worse, my code being used to attack other users or my main infrastructure that the application connects to.

There was a really cool video from Qt Dev Days that mentioned that one of the biggest strengths of Qt in the enterprise arena is that its compiled and protects IP: http://qt-project.org/videos/watch/gaining-acceptance-for-qt-in-the-enterprise

Any thoughts on how that’s gonna be achieved with interpreted QML?

And please, on the IP thing, avoid saying that its just the same reverse engineering assembly code, because its not, let’s be realistic.

Dian says:

@Raul, you can add QML as a resource and compile it inside the binary of your application.

3DH says:

Hi again :)

as I’m called a C++ fundamentalist, I’m encouraged to add one more post ;-)

It’s right that I’m a C++ developer, but it’s wrong calling me a fundamentalist or someone who doesn’t like changes – the complete opposite is reality. As Qt introduced new models to develop apps (e.g. QSA, QtScript, dynamic .ui loading at runtime (it seems many ot the QML enthusiasts here just don’t ever heard of QUiLoader and it’s power)), I was one of the first testing and implementing them – into running industrial grade environments – no trivial toy apps ;-)

And as senior software engineneer it’s important for me to be open for new developments and to adopt these quickly – as long as they are economically and technically reasonable.

This is the point: The idea and requirement of solutions like QtQuick seems to be clear for everybody who posted here. I’m just seeing some technically and political pitfalls, which can have (economically) negative consequences for especially C++ developers.

Is it really not comprehensive that C++ devs ask for a native API to functionality which is part of a C++ toolkit? Sorry, this sounds like a comedy.

@Trolls: Continue your good work and deliver your customers the missing C++ APIs, and maybe don’t focus too much on this quick stuff, instead: do your household tasks, as promised the last years. Then everybody should be happy – guys loving glued incomplete ui languages and senior devs with requirements for industrial strength native APIs.

Currently Qt is on the way to move far away from industrial strength APIs (e.g. OpenGL isn’t supported on all (embedded/industrial) platforms).

As commercial customer I have to ask: Is Nokia / Qt Project willing to give up the long-cherished stability and reliability of their native APIs? Should professional customers switch to self written APIs based on old Qt versions? Did the Nokia management guys forget their big longterm customer base?

Sometimes the posts of Nokia and some of the users here miss the contact to real business world – a world were economical descisions, investment safety and industrial grade is much more important as fancy looking animations. The last mentioned are a benefit, not the center of life. Just think about it…

@Dian: still there are tools that get the resource files embedded in executables: http://www.angusj.com/resourcehacker/
So binary resources aren’t safe at all

@Dian there are ways to pull resources from binary files: http://www.angusj.com/resourcehacker
Resource files are not safe at all

David Johnson says:

I notice there was no religous war when Jambi came out, and not even a religious war when QML first came out. When it was stated at a DevDays that QWidget was deprecated, there was a lot of trepidation, but still no religious war, because we all thought there would be a replacement. After all, that was the direction many recent changes had been pointing at. Surely there would be a QWidget overhault or replacement of somekind, and it would coexist in harmony with this wet-behind-the-ears QML thingie.

No problem.

Then the Qt project did the one thing that guaranteed a religious war: They declared the One True Language. You might as well have declared the One True Text Editor. Sheesh.

stottle says:

@Dian,

There’s probably no good way to convince you in this venue, but I am very concerned about performance. It may not come across in this discussion, but it is true. Even a 500 MHz embedded system is still capable of running 500 million computations per second (or more with SIMD or chip optimization, plus whatever speed the GPU runs at). The issue isn’t processing xml or binary, but how often you need to process the data, how quickly you need the result and whether you can process it without blocking. I’ve been impressed with the optimizations Qt devs have done in C++, and from looking at the implementation, they’ve done a good job in QtQuick.

Which isn’t the point, admittedly, but I find it interesting that our points of view are not so different, even if our conclusions are. And I do hear that you aren’t criticizing QML, but just the lack of a C++ way of accessing it.

Which brings me back to my original point that QML is a paradigm shift. Maybe that isn’t the best way to describe it, but I see it as a hierarchy of basic shapes. Each instance inherits defaults from the originating class, and overrides whichever properties it wants, or adds its own properties. By adding a Rectangle and a MouseArea, you can get the effect of a button. By embedding this within a larger Rectangle, you can create a screen or composite object.

I’m not trying to be condescending here, but if you think of the task at hand as instantiating different objects and overidding their properties in a nested tree, what is the best way to define that tree? I think a new simplified language that brings it down to its essentials is exactly the right way to do that, and that is how I see QML. I can’t think of a better or more concise way of describing the tree. If you have a better way to describe the tree in C++, please share it. I can’t, so I argue the merits of QML.

I could maybe see an argument that QML should be compressible to some binary format, but I just don’t buy the argument that you need a C++ version of the language. There just isn’t a value add.

If you accept my assertion that QML is a more concise way of declaring the UI than could be achieved in C++, what is the value of making a C++ version that isn’t as succinct?

teki says:

This is not the first article which tries to say that QWidget is not going away, but all of them (this one too) reads as Nokia is not interested in Qt as a modern C++ cross platform application development framework.

I am not sure how much better of I am with QtQuick vs. HTML5.

The Sheriff says:

I know it’s been mentioned already that QtQuick desktop components are on their way, but I just want to add my voice and say that they really can’t come fast enough! I won’t be using QtQuick until this happens.

I want to be able to use a GroupBox, ComboBox, Menu, Toolbar, StatusBar, TabGroup etc. without developing a whole bunch of my own versions simply for QtQuick. I don’t have the time or the inclination to do so.

Get this done and I think QtQuick will look much more inviting.

Erik Schwartz says:

Could we stop resorting to ad hominem attacks?

Just because I favor a healthy doese of conservatism in software development I am not C++ fundamentalist missing any imagination.

Thank you.

So I have this application on Qt 4.7 running on graphicsview and displaying 50000 items at once. How do I port this to Qt Quick 2.0?
Scenegraph lacks a proper c++ api and Qml and Java Script is clearly not the way to handle 50000 items. Also I am not aware of any graphicsview proxy for the new scenegraph.
So honestly what do I do? (apart from just sticking with Qt 4.7 Qt 5 legacy QWidgets). There is defenitly no migration path and I do not even see a technically feasible solution.

Plus Desktop Components are not even in alpha status. So it is all promises.

Nokia needed an App development (App as in toy web custom web frontend) framework and we got it (Qt Quick). But all the spinning does not cover the fact that traditional Qt customers have limited use of Qt Quick and more importantly would have requested completely different Qt 5 features. Why cannot we all be open and honest about this clear fact?

Qt5User says:

QtQuick is meant primarily for mobile related UIs. It’s usage on the desktop is still to be established. For today, you have to use widgets to develop for the desktop. That’s all there is to is.

And all you people complaining about new document architectures and itemviews NG, what is stopping you guys from contributing to the qt-project? Have any of you even bothered to send an email to the development mailing list outlining your ideas? If you cannot take the time to contribute meaningfully, please just remain silent. Seriously, what is stopping Dian and 3DH from contributing their C++ based APIs based on scenegraph to Qt?

sekar says:

I second Qt5User here. Dian and 3DH should show us the way on how to create an equivalent C++ based API for scene graph. Dian, when do you plan to start contributing?

Jack says:

I’m fine with declarative UI and animations. What I don’t understand however is why would /declarative/ UI need JavaScript or any other scripting language at all. Is it really declarative then? Might as well write it in JavaScript or in HTML with JavaScript.

In addition, saying that “JavaScript runs one and that’s is” misses the point. It still runs. It’s like saying, hey, who cares this startup utility we’ve written in Java eats 500 MB and runs 5 minutes but it only does it once per run! That’s exaggeration of course, but the issue is the same.

Erik Schwartz says:

> Seriously, what is stopping Dian and 3DH from contributing their C++ based APIs based on scenegraph to Qt?

This is a very “special” question.
My answer: I do not have the time/resources to fix/extend other people´s code, which is by the way absolutely undocumented (on the level of internals). There is no documentation about the inernal architecture of scenegraph and Qt Quick/Qml. Only the public API is documented. This makes contributing virtually impossible for most people.
In the past I paied for a hight quality Qt. Doing it myself is not a very realistic alternative, since I have to earn money with my core business.
The only realistic option would be to raise money from people sharing my concern and pay a consultant/Digia to implement it.
Maybe this is what will really happen.
In the past Trolltech was the entity with exactly this business model. Nokia very obviosly has different goals and a very different business model.

Toni says:

I am gonna add point…

Why Javascript for QML and not C++? Good luck with micromanagement. Seriously.

Dian says:

@Qt5User

“Seriously, what is stopping Dian and 3DH from contributing their C++ based APIs based on scenegraph to Qt?”

http://qt-project.org/forums/viewthread/16321/P30/#82767
http://qt-project.org/forums/viewthread/16321/P30/#82769

“For today, you have to use widgets to develop for the desktop.”

That’s the whole point, it is not good enough for TODAY. Whatever choice you make, if you aim at serious application development you are faced with tediousness, if you chose QML you have the tediousness of interfacing and gluing your objects to QML, if you chose QWidget, you have the tediousness of making it look adequate to our time.

@stottle
“And I do hear that you aren’t criticizing QML, but just the lack of a C++ way of accessing it.”

You keep on getting it wrong. I don’t need a C++ way to access QML, this doesn’t even make sense, I need a C++ way to access QtQuick and the SceneGraph, which removes the need to use QML at all. What QML does is it gets parsed and used to set up a structure of objects, which is QtQuick, a C++ backend. QML is not the foundation of QtQuick, just a declarative language to describe structure, something I and many other people can do in C++, why using QML and all the bunch of overheads it requires when we can directly do everything ourselves? QML is made for people who don’t understand low level program structure, so that they can only describe the structure and the interpreter builds it for them following the guidelines established in the API interface, or in the spirit of my abstract analogy from earlier, English to German translators are only made for those who don’t know German, if you know German then the obviously better solution is to just speak in German instead of using a long and tedious toolchain to do that for you. So WHAT I WANT IS THE OPTION TO JUST SPEAK IN GERMAN, instead of using all those “fancy” tools to do that for me, an option that is missing. I have nothing against the tools, they have their application for people who don’t know better, but I have a thing against the extra tools being mandatory even if you don’t really need those training wheels to build program structure. My problem is with not been given an option, your problem is with giving the option to keep Qt what it has been for the last 20 (yes, TWENTY) years. So what are your motivations to be against developers having the option to chose? Conformism and Fanboyism? I honestly see no logical and reasonable motivation for you to want to convince me that I need to use extra tools for something I can do on my own, and that I don’t need the option of doing it on my own. You literally insist on and justify other people being deprived of choice to to things the most efficient way, I hope you do realize how stupid and ugly this is.

Albe says:

Perhaps I’m missing the point of all this complaining. I’m not a Nokia employee, I’m just a C++ coder and I’ve started a new Qt project months ago. I’m new to Qt and I found it much more confortable and efficient than other cross-platform tools I’ve used in the recent past. All this “no javascript” complaining does not make a lot of sense to me: we’re just talking about using a very simple tool, that produces efficient results and it’s quite easy to read, understand and learn. I consider it to be more of a simple syntactic tool as it doesn’t imply the need to learn how to code in javascript!
So, it’s just a tool, and I’m wondering how its introduction can produce such a strong reaction, considering that for any programmer with a decent level of C++ competence, learning those concepts shouldn’t result in any special kind of problem.
Most of all, Qt is around since a while and with good results, of course it’s not the perfect SDK, but it has a lot of strong points, so I really think that I can trust the engineers working on it to take a good decision on its development direction. I still belive that there is not a better toolkit for cross-platform development.

3DH says:

@Erik: Full ack!

I’m commercial customer paying tons of money for many many years to get a stable and reliable product: the C++ API. In the past I already contributed patches for QMatrix, QImage, the SQL driver plugins, QWidget etc. – long before Qt was going public / open source.

As Erik mentioned before, the internal Qt sources are a pain to read / to work with as external dev – it took me ages to understand the wide spread undocumented sources, missing the clean and continuous coding style we know and love of the public Qt API.

If it’s possible to improve and fix something, I’ll continue to contribute – but adding fundamental functionality like a C++ API for the (not yet finished) QML/QtQuick engine would be a fulltime job for multiple persons, not a task of a view hours for one single enthusiast.

So: Please be objective. I can understand and mostly agree to all viewpoints and arguments here. Everybody has a different user role – e.g. Dian and me have to develop hughe business/industrial grade apps, whereas other devs more focus on end-user apps, which profit more from the fast and fancy gui development QtQuick provides (which is a really good solution and further development of QWidget).

Summing up:
– QtQuick is needed and provides features, QWidget can’t/won’t provide ever
– QWidget is currently the only way to build fully integrated Desktop apps
– QtQuick more focuses on mobile UIs, less on performance and customization like QWidget/QGraphicsView
– C++ devs need stable APIs and a way to migrate to QtQuick – e.g. by new C++ bindings
– QtQuick has some architectural disadvantages due to the mangled language, which isn’t that easy as Nokia promotes
– in comparison to the clean Qt C++ API the new QtQuick seems to be premature and looks like hastily cobbled together
– Qt has to satisfy the needs of the open source scene, beginners and (long term) commercial users -> this is a really hard job!
– Nokia has it’s own focus on (their outdated) mobile platforms and thus doesn’t support market leader platforms – maybe this would be different, if Trolltech would exist till today

I can imagine how hard it is to be a Troll – changing management and business targets, sitting between the stairs (commercial and open source devs), raising pressure to develop new features.

So: You do a good job! Even if I’m sometimes more worried about future of Qt than during the Trolltech times and even the Qt support is now much slower than years before, I hope you keep Qt being the best C++ API! :-)

Hopefully a Troll reads our posts…

Kalileo says:

My wish list:
Qt5/QML for desktop OS (Mac/Linux/Win)
Qt5/QML for iOS/Android/Meego,
C++ Backend support for QML, MVC, no requirement to implement business logic in QML/javascript,
full QtMultimedia support for every desktop and mobile, including iOS/Android,
fast OpenGL support on every platform,
Qt to survive the current MS domination at Nokia!

And big thanks for all Trolls at Qt/Nokia for the great job you are doing, keep it coming!

Yogi says:

I’m surprised that none of the dissenters in these comments are willing to start a real discussion in the proper forum, the qt-project development mailing list: http://lists.qt-project.org/mailman/listinfo/development

Personally I think QML code is much cleaner than writing the same logic in verbose C++ by calling a bunch of setters and explicitly creating a bunch of connections. Performance-wise QtQuick in Qt 5 will pounce QGraphicsView, even for “industrial grade” applications. And if you have 50000 items it might be a good idea to consider a custom item / view written in OpenGL for the best performance. 50000 graphics items was a hog, with terrible performance, due to the nature of QPainter’s imperative API.

And please, instead of just complaining, try out and contribute to QML Desktop Components etc if you want desktop to get the same amount of attention and love as mobile. Qt is openly governed now, it’s up to each of us to make it great for the use cases we care about, and QML certainly has the potential to be a kick-ass solution on desktop as well.

smoggy says:

I believe you are doing great.

1) But i would use cmake instead of qmake. Integrating 3rd parties (QTwebkit, openssl, etc) will be a breeze. Today compilation is like
perl …. / configure / automake ..
it’s a mess.

sroedal says:

@Dian: For now QQuickItem and QSGNode / QSGMaterial / QSGGeometry are public API, so you are fully able to create your own quick items / scene graph nodes and populate the QQuickView with them. In addition, you could create a QQuickItem that creates QML items dynamically and proxies them.

It’s too easy to demand that the whole set of Quick items are exposed with an equivalent C++ API when you don’t have to maintain that API. Making an API public is not a trivial matter, as the cost of having to promise BC and SC is quite high, especially when it’s unclear whether there would really be a benefit for most of the users. I think a lot of the fear about the lack of a C++ API is coming from people who haven’t really given QML a proper try. It takes some time initially to learn the best patterns for interfacing C++ objects to QML, but it’s really not that hard.

stottle says:

@Dian,

“QML is made for people who don’t understand low level program structure, so that they can only describe the structure and the interpreter builds it for them”

“WHAT I WANT IS THE OPTION TO JUST SPEAK IN GERMAN”
This is where you are missing my point. It isn’t German vs. English, or C++ vs. javascript. QML is data, just like what you pass in XML is data. QML is simply a way of providing input to a program. If you want to use it in C++, make a QString and pass it to the engine for processing and you are technically using C++. But the fundamental problem, especially with dynamic UI’s, is to easily input all of the positions, sizes, colors, transparencies, motions, states, etc..

And supporting the input of this data by a simple markup language was essential. You keep talking about how repetitive it is to write the glue. Imagine has to write all of the code (1000s or 10,000s or more setProperties, then all of the connections, etc) yourself, and having to recompile for every change. First thing I would do would be to create my own parser and read in some text or binary format of input. But then everyone would have their own parser, and no one could share work.

QML is the right solution for this problem – data input. It’s basically a DSL optimized for the creation of the Quick components (which can be extended in C++). How do you optimize a language already tailored to the problem domain? Certainly not by trying to mimic the functionality through C++.

And when you understand that QML is the efficient way of describing the UI, you can decide how much javascript to use. I try not to use it for anything other than the initial data binding (i.e., connecting the signals to slots automatically).

So it comes across that you either think there is a better way to define the UI in C++ instead of using QML (which I obviously think is false) or you want another QML parser that doesn’t use javascript, just so you can create your own connections. Neither makes much sense to me.

A friend says:

I think the reason for all this mess is that the desktop side is neglected. That’s all, clear and simple.

I really wished that Qt 5.0 had the desktop components included as part of the release. This would clear up many many things. For the applications I do for work and for fun I need trees (and all the other widgets that are there), so I can’t even evaluate QML for my use cases. Including desktop components in the Qt 5.0 release would enable many experienced desktop developers to jump on board, provide feedback and even help.

At least we could try the technology. I can understand that QML is new and that Qt engineers want to establish a base to build upon, but the way I see things (as a desktop developer) is that _now_ Qt 5 has no real platforms. (This is mainly due to Nokia’s politics imho). QML, which is pushed as the main UI paradigm, can’t do full featured desktop applications (win, linux, mac).. heck it can’t do mobile apps neither (no symbian support, really?!??, no harmattan, no iOS, no Android)

To summarize, if it was my decision, I would postpone Qt 5 release and include the desktop components. Qt has many desktop developers, in part Qt owes it’s success to them and they shouldn’t be neglected for some “future desruptive meltemi” or whatever.

Ralin says:

Top QT5 issues for me:
– Build system, just adopt CMake FFS. No, I do not have Perl/Python/Ruby installed. The current state is terrible.
– JavaScript – Good luck maintaining the V8 and porting it to all the supported platforms. You should have chosen something like Lua/LuaJIT2.
– qmake – Pretty much unusable for bigger projects. See point 1.

Quim Gil says:

Ideally a thread like this would include a higher ratio of links to bug reports pointing to problems, links to patches showing the possibility and willingness to solve those problems and even a hint or two from developers potentially interested moving QWidget away fro its DONE status.

Without this the discussion might be interesting, but the actual progress will be limited.

And yes, the right place for Qt development discussion is the Qt Project [Development] list. Here we have a huge discussion while a post like The place of QML http://lists.qt-project.org/pipermail/development/2012-April/003250.html has got one direct answer so far.

You know Qt is and open source, and you know that there is no barrier for anybody with the skills and willingness to push any module further. Can the QWidget users and developers get organized, define priorities, get approvers and a maintainer? Isn’t this the core question?

Of course Quim answer will silence any Qt “freerider” like myself (i.e. Those using Qt without actually contributing code or paying). But I can see why the longtime paying customers that commented above may have something to say. I hope Digia has enough customers to continue working on Qt 4.8.x addressing the needs of Qt desktop users.

David Johnson says:

Erik: “So I have this application on Qt 4.7 running on graphicsview and displaying 50000 items at once. How do I port this to Qt Quick 2.0?”

This is my situation as well for three of my last four projects. The bottlenecks that I am finding in graphics view performance is the indexing, not the painting. Switching to QML doesn’t solve this. QML may be a more elegant solution to “dancing robots”, but it’s inappropriate for displaying 50,000 items.

Yogi: “50000 graphics items was a hog, with terrible performance, due to the nature of QPainter’s imperative API.”

Well of course! No one is denying this! But that does not explain why it is forbidden to access the scenegraph from C++. None of us C++ “fundamentalists” are asking anyone to stop using QML. All we are asking is that we can continue to use the most powerful programming language in common use.

And to all suggesting that we should SHUT UP AND CODE, that’s the oldest copout in the open source world. Congratulations for finally becoming a true open source project.

Samuel says:

@David: As I said, you can access the scene graph from C++, you just need to make your own items and nodes for now, or create your own C++ proxy objects for the existing items in QtQuick. But no matter whether you use QGraphicsView or scene graph you’ll not want to create one node per each of those 50000 items, you’ll probably want to represent them using one node, that does its own indexing if necessary, and batches the items in vertex buffer objects so that they can be rendered with just one or a few draw calls.

Erik Schwartz says:

@Samuel:

Yes, but this requires OpenGl (knowlegde) and is inferiour for pure 2d. We had a properly working 2d canvas (graphicsview). Why discontinue the support in conjunction with Qt Quick 2.0? This makes migration unecessary hard, which often mean impossible in an enviroment controlled by business needs (the nasty world of budgets and schedules).

> You know Qt is and open source, and you know that there is no barrier for anybody with the skills and willingness to push any
> module further

Sorry but there are at least two barriers not to be underestimated: Resources (personal and business wise) and lack of documentation of Qt internals.
The first one of course cannot be solved by Qt, but the second one really should. If yo guys really want outside contributions then please start to proerly document the Qt internals. Right now touching the internals of Qt or even Qt Quick has the smell of middle age alchemy all over it.

d3fault says:

These comments are amusing. Especially the back and forth between dian and Adam Higerd. I fukken lol’d. But I have to say I agree with dian and 3DH. Declarative/interpreted/QML shouldn’t be a requirement for a native/C++ toolkit.

Javascript hate aside (which I admittedly have), I don’t like the idea of my C++ apps requiring a JS interpreter/VM just for some modern UI effects. It adds unnecessary bloat to static builds as well as increasing startup time/memory consumption. QML is a great optional addition to the Qt family… but it’s taking valuable resources (read:manpower) that could be otherwise spent on improving the C++ aspects of Qt (a C++ toolkit first and foremost). All I ever read about lately is new QML/QtQuick functionality here and there and I read the descriptions to see if there’s any mention on how to use the new functionality from C++… and am then disappointed.

I don’t even mind using QML/declarative for UI definitions (though all this talk about ‘glue code’ does scare me away)… my main concern is the requirement of a JS interpreter/VM for every app. Static builds, or even dynamic builds on Windows (ick), require the application developer to now bundle a JS interpreter/VM along with their app(s), increasing the resulting binary/zip file. On any real OS this of course isn’t a problem because there are system wide libraries… but for Windows developers (and there are tons), this extra bandwidth per download will quickly add up.

Since it seems like we’re fighting an uphill battle agains the trolls (sort-of pun…), is it possible to re-arrange the usage of QML/QtQuick so that it does NOT require a JS interpreter/VM to be distributed along side the applications? I’m certainly no expert on the internals of Qt, QML, or QtQuick… but from what I understand from reading these comments, QML is interpreted/parsed _once_ at application startup to “generate objects and data structures” (-Adam Higerd), which is then fed into QtQuick. QtQuick is purely C++.

So my question/suggestion is this: couldn’t we move the one-time parsing/interpreting/data-structure-generation of the QML -> QtQuick to be compile (or pre-compile) time? Shit even putting a JS interpreter in the toolchain sounds better than putting it in the app runtime (or JIT). Qt apps already have to be compiled once per platform, so what is the point of embedding the QML inside the binary as a resource and re-interpreting it each time the application is run? Oh sure you get the ability to swap out GUIs at runtime… big friggin whoop. That’s nifty and all (and definitely helpful during development/debugging stages)… but I don’t think it justifies requiring C++ apps to bundle a JS interpreter/VM.

And of course there’s the people who want to write the functionality for their apps in JS… they couldn’t use such a solution. But fuck them anyways… this is a C++ toolkit… something Nokia seems to be forgetting. Sure am glad it’s open source/meritocratic now <3.

James Mansion says:

@Adam:

One of the concerns I have had is that we have gone from a situation where we needed a decent C++ compiler and could pretty much get by from there – too one where there is at least some emphasis of V8 and funky JIT behaviours to make JavaScript work decently quickly.

And that gives rise to portability concerns for those of us that aren’t necessarily using a V8 supported configuration. I haven’t written Solaris SPARC GUI code for a couple of years now – but that doesn’t mean that I want to be using technology that would prevent me from doing so, or which would mean that I would be unable to build for, say, DragoldFly BSD or some other BSD variant (which does have gcc and clang, but may or may not have supported build configs for a JIT). (Do I use non-portable tech? Yes, but then I just use what Microsoft say to use, and there is no pretence at, or requirement for, portability. Having said that I really wish you had a supported C# binding.)

If you had chosen to use a portable interpreter with a small footprint (ie Lua, in practice) then this would all be moot – but it seems you have chosen to include a lot of baggage, some of which seems to be a non-trivial port.

I can see how a phone manufacturer will view the world through requirements for creating UIs for end-users. But if you look at job adverts for programmers, most of us actually build line of business systems for trading (in the broad sense – from financial derivatives to handbags), accounting, and personnel/payroll. Or vertical apps for hotel management, PoS systems and the like.

Do you expect that these apps will transition to ones with an emphasis on UI effects? Some of them will move to GWT or similar, but I’m not convinced that the dev productivity for such applications is anything like as good as a more old-fashioned client app, and for intranet deployment that dev productivity can be more important than the zero-install of a web app: jnlp works, and so does automated MSI management. (And most web apps are to be frank pretty poor – I’ll bet most of us use corporate web apps for timesheet entry and expense systems, and I can’t say any of the ones I’ve used recently were half as usable as the old VB apps they replaced.)

Qt is a portable C++ toolkit; you can’t be surprised if C++ devs want to use it that way – and use it to support somewhat mundane applications that have no pretension to be the next FaceBook.

Aleksey Sidorov says:

@David Johnson

I think that if you have a need to place as many items on the scene, then you obviously want the strange

faldżip says:

I’ve read about new features in Qt5 and I must say that moving from Qt4 to Qt5 is for me a waste of time. I’m working in company making huge desktop apps with intense use of database, the MDI interface with lots of tableviews and so on. Qt5 do not offer anything worth switching to it.

And it states that with QPA and QtQuick it will be easy to port Qt apps to any platform. So what mobile platforms are worth writing apps for them? That’s right! It’s iOS and Android as they are the most popular ones. And I’m reading now that there are difficulties to port Qt for them, and what’s more – none of the Qt makers are bothering with it. If you want Android/iOS Qt port, then do it yourself. Thanks, but no thanks… There are some community projects, but yes, there are projects. I really appreciate that someone spend his time working on it, but I need to earn money and don’t want to spend nights trying to do (for free) something which should be the part of Qt.

Oh, but we have MeeGo which should work perfect with Qt. But wait, MeeGo? What is that? It’s is available on Nokia N9! Nokia N9? What is that?! I see advertisments of Nokia Lumia everyday, but did anyone of your non-programmers friends hear about Nokia N9? A guess not…

So it is really nice to have QtQuick and Qt5 to write apps on many devices, but it is pointless to develop the “mobile” features in Qt, as there are no popular mobile platforms supporting Qt. And desktop platforms seems not to be interesting anymore. It’s sad :(

Konstantin Tokarev says:

@stottle:
>QML is data, just like what you pass in XML is data.

Nope.

QML is not plain JSON or other established data format. It’s a brand new language[*]. And it’s certainly NOT a new data language because it allows embedded logic.

[*] IMO it’s obvious that language design is much more complex than software design so people should try to avoid inventing new languages where possible. sa qmake’s language as an example of badly designed language, and consequences of its existence (some folks suffer from its quirks but it’s impossible to fix language without breaking existing projects).

JubiluM says:

Many points addressed already. Haven’t seen any solution for the following: when will we be able to use ide other than QtCreator to develop and debug our programs supposed to be qml? Visual Studio, XCode, Eclipse, name it….can I use some dat an Ide that is my favorite? It’s very straightforward with widget Qt, it is very hard to beat widget Qt and qmake combination.

I think that this is an important lesson for all developers out there. You never know when a some kind of bad decision concerning the tools and/libraries is about to be made. If you’re not prepared when s*hit hits the fan, you’re screwed.

1) Always look for alternate solutions. Get familiar with different toolkits and libraries. Develop a skeleton of your ui’s with alternate solution as a hobby.

2) Leave your toolkit/ui-dependant code as thin as possible. Do not suck it into your application logic, even it might be a temptation to do so. For example, as little as using QStrings might not be a good idea…do not create dependencies. It might be nice and speed up temporarily but you’ll e crying blood when some day, somebody tells you that imperative is so yesterday, we’ve got this declarative quick qml-thing now…

Clemens says:

Full ACK to Dian.

Besides that:
Nokia loses market presence every year, and no Developer with a clear mind, really wants to develop for anything other than iOS or Android.
Nobody is interested in Nokia’s mobile phone stuff, it’s just not the way to go. It’s not fancy and it’s not a hype, it’s gonna flop, as the Metro UI of Win8 will, more or less, if you do not intend to use it for anything else as the most primitive tasks.

And in my opinion it’s an epic fail to not have at least some people continuing the work on the classic (static) Qt desktop. I mean, nobody can foresee the future and if it’s not gonna happen, that every Notebook, and every Desktop PC is gonna get a Touchscreen (because without that, these fancy new fluid interfaces are a pain in the ass to control), you have a big problem.

I guess it’s pretty clear and many have stated it before: Nokia’s interests don’t go along with the interests of the original Trolltech Qt. It’s changing more and more, but due to the fact, that Nokia is NOT famous for fancy new mobile stuff, no that’s Apple, it’s just extremely stupid to not care about the only segment which holds on to Qt, the static conservative desktop developers.

If your premises, Lars Knoll, are wrong, you are sitting between two stools.

Clemens says:

I forgot something:

Please get at least a hand of your developers to write better internal documentation, else external contributions will be as few as they ever were. Wouldn’t cost too much, but the Qt project would gain advantages due to the number of much more contributors.

Bernhard says:

Microsoft once crashed by trying to bring desktop interfaces to mobile device.
Microsoft will crash again when trying to bring mobile interfaces to desktop computers (Windows 8 will flop surely if MS does not adapt their stragety).
Qt will crash the same way if it does not respect the wishes of desktop developers too – this is where Qt comes from and what Qt keeps alive and prospering.

QML is ok. But don’t forget to provide an alternative in C++. And also do not forget to solve other more fundamental problems of Qt (a lot of people here already listed the most important of them. Maybe I could add template support for Qt classes).

@A friend, 3DH: You are totally right!

David Johnson says:

Aleksey: “I think that if you have a need to place as many items on the scene, then you obviously want the strange”

Not that strange. On a 900×900 window, you can draw them as 2x2px dots with spacing between them. Yeah it’s cluttered, but perhaps that’s the data you need to display. This kind of app would indeed be strange if it were on a smartphone. But it is not, it is on an engineering workstation with a 24″ monitor.

Dian says:

@To all those who want to see an up-to-date, customizable, fluid, dynamic and interactive hardware accelerated C++ GUI API – there is a poll in the Lounge area of the Qt developer forums. Not posting a link just to make sure I trigger no spam filters. The name of the poll thread is:

“Does Qt need a modern C++ GUI API?”

Perhaps if enough people vote Qt managers might consider listening to us. I know plenty of people express their requests here in the comment area, which is easy to ignore and doesn’t really give a full idea of the number of people who want a new C++ GUI API.

Thanks!

Dian says:

^^^Just to add, if for some twisted, illogical reason you are that much AGAINST developers having the choice to avoid QML and be able to easily develop adequate to our time native C++ apps, you can also vote against that idea.

Even thou I honestly can’t think of a reason why you would want others to be deprived of choice (unless there is something seriously wrong with you), but apparently, there are such people, which is kind of sad. I doubt any of us, who call for a Qt Quick C++ frontend or a similar alternative in Qt, want to see QML dead so you don’t have the choice of using it, so why do you want us to not be able to keep to our trusty, good old C++?

I honestly don’t get it, since when is having choices a bad thing? And for that matter, since when being forced into making a choice is something good?

Roland says:

The Trojan horse Elop continues to suck all blood from Nokia for the benefit of Microsoft. I recommend KDE to execute their right to get a BSD licensed Qt as soon as Qt5 is stable. On the desktop LGPL is fine, on iOS LGPL is virtually unusable. For the time being Nokia still invests heavily into Qt. Still Many of the investments are great for the C++ community. As soon as Meltemi was released we will see, if the platform is open for C++ development. If not there will be no more paid Qt development. This will be the time to fork a BSD version.

Dian says:

@Roland – I bet the moment Nokia turns in 1$ of profit, that “amazing recovery” will be credited all to Elop. And while it is true Nokia was on the downhill before he came in, he surely contributed as the final nail in the coffin. I honestly can’t tell whether the guy is just clueless or secretly working for Microsoft, who have interest in both clearing some mobile market to take over and driving Qt, a powerful C++ cross platform framework into the ground. On the latter – several leaders in professional software have already embraced Qt for their 4 digit+ priced workstation grade products, giving them access to operating systems other that Windows, after over a decade of using MS’s frameworks and staying exclusive to Windows (and to lesser extent Mac), and I am quite sure Microsoft doesn’t like that. So they do have interest if Qt shifting towards a toy app framework, while its serious and high performance oriented facilities get left behind without any significant development.

Just take a look at OpenCL – a technology allowing to tap in the tremendous power of GPUs – a technology immensely more important than eye candy – there was some involvement with OpenCL in Qt, but it was just a tiny effort that has been frozen ever since. Even thou OpenCL is largely available on desktops (and very soon will be on mobile platforms) and can offer 10-100 times performance boost in many computation intensive tasks, the main Qt development team is too busy with the momental fashion fad, eye candy toy app QML to pay attention to what is really important and beneficial to the developer and end user in the long run. It is LAME Qt is trying to imitate others and arriving late, when it could very well be leading the industry with innovation. Heck, I bet my balls (don’t have kids, so those are of very high value to me) if I was behind Qt’s direction decision making, the whole industry would tremble just by hearing the name Qt and significantly improve their own frameworks just to avoid lagging behind, and developer and user base would have been a few times over what it is today, from everyday users through workstations all the way to HPC. But no, it always has to be some questionably intelligent dude with a suit making the decisions, foolish enough to be entirely motivated by profit and still drive a company into losing billions. Amazing to say the least…

Ter says:

@Dian, QML, an eye candy technology… It’s a bit arrogant, isn’t it? The problem isn’t the lack of C++ API for QtQuick for you, the problem is that you hate QML, a thing that is easier to use than C++. The glue is hidden so you don’t have to manage it yourself. The thing I understand is you want to remain a specialist, but that will be the case, the most important thing is architecture, not the language. IMHO QML isn’t perfect, but it’s really promising and as a developer of C++ for decades I can say that in many cases (not all cases) it’s easier to maintain QML code than C++ code for UI. OK you have to learn another thing (quite simple) but it’s clearer and another time: the backend, the core is still in C++. If QML doesn’t fit your needs, well, you can still use QWidget and QGraphicsView as I do when it’s the best way.
So peace with the Qt team, there are not against you and for me they’re doing an amazing work and I really think that they believe in their work (there’s no conspiracy to impose QML).
So, thank you again Trolls! Once again Peace and long life to Qt!
PS: I’m not a Troll and I use Qt since 2.X

Ter says:

Another thing, Digia has just released Chart 1.0 preview technology, so they work for the Desktop (I’m a holder for years). OK you need a commercial license but it was the same when Qt was owned by Trolltech (QPL or GPL). IMO I don’t think they will stop their work on Qt soon, I think they understood that there is a real need / business opportunity. I don’t know if it will work. wait and see.

Belmondo says:

You are doing great work with Qt5! Not everyone understands it now, and some of those who understand it later will never admit it… such is life.

Qt 5.0 is all about getting the base ready for future and Qt 5.1 & 5.2 will bring more features on top, we hear you. It is great that Qt developers have guts to provide the most moders framework which others will soon try to follow & mimic!

OPENSTEP says:

Being a commercial user for many years and Mac developer, one of the biggest drawbacks to the QtQuick/QML system is that there is no standalone graphical design tool for working with QML. Not everyone uses or wants to be forced to use QtCreator. Qt Designer is stand alone and can be easily used with any variety of build system. I’ve not seen anything similar for QML which seems to me like something which should easily be feasible.

Marvin says:

Damn it’s tempting to feed those trolls, but lets not.

It’s nice to see that the Qt team has learned from previous mistakes (publishing API’s too early) and the choice of JSON as a declarative format is much preferred over XML as it is quite readable even without specialized tools (as opposed to eg. XAML). Keep up the good work and don’t let the trolling get to your heads :)

Percy says:

@Marvin: Is very naive to think all above is trolling … very naive.

tbscope says:

Marvin,

Do not start insulting people who voice an opinion that doesn’t correspond with your opinion.

As far as I can see, nobody is saying that QML is bad. On the contrary, it’s very nice. There are so many superlatives to desribe QML.

However, why does the rest of Qt need to suffer from it? And why are some programmers using QML to write complete porgrams?
Isn’t the purpose of QML to replace the old .ui files? That’s the idea I always had.

But now I see that the QWidgets module is abandonned by the Qt developers, except for some bugfixes if they have the time and manpower. That might make sense when there’s an alternative. But there is none at the moment.

Can you also immagine for a second the billions of lines of code in existance that use QWidgets. The thousands of programs that make use of Qt. Do all these developers end up with a toolkit where they invested lots of time and money in, that isn’t going forward anymore? Do they now need to spend a lot more money and time in learning the new QML languange and change their code completely? Can you see the problem here if you have anything more than a little App that shows the train schedule?

In a certain way, Qt introduced me to Linux. In fact, it let me love Linux so much that Windows became second class. Before I learned about Qt, I was addicted to Windows using Delphi and Visual Studio. But with Qt I actually enjoyed writing software (This was at the time of KDE3 and Qt3).

I followed the development of Qt very closely and I tried to help out in the open source community as well as I could.

But now… after Nokia buying Qt, my interest started to dwindle. Ok, it might turn out ok, there’s a lot more money behind it now, maybe we see even more developers working on Qt. But even before the buy, I saw key developers leave Trolltech. And after the buy, even more developers left the Qt development team. And now they end up with a small group of developers that needs to maintain a very large and complex code repository and trying to make some parts of it more modern and better (like QML).

You can’t do that. So the only sollution to please the huge userbase is to make it open source. But just telling people they can now improve Qt themselves when there aren’t any Nokia developers available is actually insulting.

As said again and again… users of Qt invested a great deal of time and money in Qt. If you ignore them, they maybe first get mad. But after a little while, they will just vote with their money and go somewhere else. This in turn means less income for Nokia (or Digia) and that in turn will lead to more deprication of the code. In the end you end up with a very small Qt that isn’t even a part of the shadow of the former Qt in its glory days.

I find this very sad.
Qt still is at the moment, and was in the past, a very very nice, easy and great all round C++ api.
It is now turned into a toy for mobile phone app developers.

Christian says:

@tbscope

++

These are real and honest concerns and not simple trolling. But since Digia owns the Qt licensing it might be better to raise our concerns about the future of Qt there.

And honestly: Who wants to influence Qts future has to either pay for it (Digia) or contribute himself.

Marvin says:

@tbscope: My insult was directed at some person that claimed repeating previous arguments is a sign of “consistency” rather than bad argumentation (or outright trolling), obviously believing repetition of a previous arguments somehow makes them better or more valid. And, whether you’ve noticed it or not, there are quite a few people har that claim that everything not C++ is bad and should be thrown out ASAP, just refer to the poll:
https://qt-project.org/forums/viewthread/16465/P15/
Which for some bizzarre reason contains a heap of negative superlatives for QML and just positive ones for C++ (geez, wonder why?).

When it comes to “my opinion” on QML it can be summed up as this: Qt, like any other serious UI toolkit/library, needs support for RAD tools. The choice is between parsing and interpreting the source code directly (theoretically impossible with C++), an XML data definition (like XCode, Delphi, .ui files etc), or a declarative language definition (like XAML, HTML5 osv). Of the 3, declarative is the best option (since option 1 is ut of the question with C++, even Java is too difficult (ref IBM’s failed attempt)), and of all possible languages and source code styles, I prefer JSON over XML, and JS is a pretty easy language to use for glue (probably because it’s syntax resembles C/C++/etc).

Dian says:

@Marvin

“And, whether you’ve noticed it or not, there are quite a few people har that claim that everything not C++ is bad and should be thrown out ASAP”

It is nothing short of amazing that after extensively stating that:

– we wish for an alternative to QML while not having anything against QML itself, but against the exclusive attention it gets
– there is no reason why C++ frontend cannot coexist with the QML/interpreter frontend just like XML UIs coexist with C++ for QtGui
– people should be able to use whatever tool they want, whether that be building GUI structure by hand with C++ or using QML

… YOU SOMEHOW still manage to say something that is technically a LIE, since I don’t recall anyone insisting to throw “everything not C++” out.

Have you noticed the poll option being “We want QML thrown out” or is it about providing the option to skip on that bunch of technologies that go with QML and their overheads?

Nope, it is YOU, QML supporters that for some reason want us C++ supporters to have no choice of using C++ for GUI development, we C++ supporters have nothing against QML existing for those who need a special set of tools to build GUIs.

Also, where are those superlatives addressing C++ you speak of? I recall statements that are quite objective, that while C++ is not the best tool to build GUI applications with, since it is by design a GENERAL PURPOSE LANGUAGE and not a GUI structure describing language, it STILL SUFFICES and offers a wide range of benefits that QML cannot offer. QML cannot substitute C++, but C++ can substitute QML, since all QML is used for is driving a C++ backend through an interpreter. For trivial apps that do not extensively reach beyond QMLs standard facilities there is no trouble, but the more you reach out and create custom objects the more tedious using QML gets, since you have to design your classes keeping the limitations of QML in mind and overcome them by means of extra code and extra objects that would not be needed if there was the option of a public native frontend.

We get it that some prefer to describe structure in a data structuring language, we don’t mind you doing that, what you fail to understand is some of us want to build data structure rather than describe it to an interpreted to build for us.

Would you try reading more carefully and being more objective? Who knows, I might be “trolling” but unlike you I am not lying…

Fork QWidget says:

Is there room or a fork of QWidget?
I mean enough interest and support from the community? A fork completely independent from qt-project and Nokia?

qt-project and Nokia are only show stopping and demotivating QWidget stuff.

Dian says:

^^ the problems with QWidget are not that it needs improving, but that it needs replacement. QWidget serves the purpose it is designed to, and it does that job well. The problems of QWidget have to do with that fact, with the fundamental design of it. Which is the motivation behind Qt Quick, it fixes all the flaws of QWidget, sadly there was no decision to make the Qt Quick API available for native use, instead making QML mandatory if you need something up-to-date and better than the hopelessly stuck to an outdated UI paradigm QWidget.

Cuke says:

#111 +1

GettingLife says:

Lars, can you disable comments? This is getting silly.

Dave says:

@Dian

Without addressing the central issue one way or another, there’s an interesting point about communication with the Trolls in here.

From what I’ve seen, if an idea has some merit and explained clearly and concisely to the Trolls they’re normally willing to consider it (although sometimes it ends up on a backlog if they’re working on a release) or they’ll explain why they don’t think it’s a good fit.

In this case I can imagine – as others have pointed out – that designing a maintaining a Qt-style (and Qt quality) API to provide the QML functionality from C++ would take a huge amount of time. API design is a huge undertaking. And there’s already something which provides the functionality ie QML, so it probably appears like a choice between duplicating a lot of effort to please the people who don’t like QML or getting other stuff that needs doing done – the QML components for the desktop are probably amongst those things.

Anyhow, so you’ve explained your idea and a few people have chimed in with why it might not be happening. When I’ve seen this kind of think happening in the past it’s been over a few short emails / blog comments / forum posts, and then everyone moves on one way or another.

What I’ve seen in the last few blog post comments and in the relevant Qt DevNet threads is
– you’ve been using great big walls of text where a small fraction of the content should be able to get the point across
– you’ve been repeating several of your points long past the point where it’s appropriate
– you’ve been jumping on small details and occasionally twisting what people have said to fit your own outlook to rebut counter-arguments while not accepting or ignoring the “bigger picture” contained within, that are sometimes very valid and pertinent

The overlong and repeated text shows that you’re very passionate about this, but if the message could be conveyed more succintly it would be a bit more respectful to the people (and especially the time schedules of the people) you want to read the messages.

You have some potentially valid points, but maybe you should let others take them from here.

The feature request / I-feel-strongly-about-this threads I’ve seen in the past have usually been composed of communications that were business-like, concise and respectful – basically communication between proffessionals. It seems to have worked in the past. If someone willing and able to communicate your points to the Trolls in that manner it might be much more helpful than continuing on the current path.

My view is that your commenting strategy on this issue is at best setting a terrible example of how to try to communicate with the Trolls about something you feel strongly about, and at worst are poisioning these communications channels and (to a smaller extent) the community in general.

But then again, I might have summarised something partially incorrectly, in which I case I don’t expect you to absorb any of the other points in my comment… :)

Yuchen Deng says:

Be honestly, I only want use QWidget of Qt. So, I hope someone can still improve QWidgets with the same of QML.

Dian says:

@Dave – I really like how you twisted it so that it will somehow be my fault if C++ remains a GUI dead end. It is true thou, there has been too much repeating, I myself got sick and tired of it quite a while ago, but the worst thing is with all the repeating there are far too much people who haven’t gotten the point, or gotten it completely wrong against all the explicitly stated points.

And since your issue is my communication with the trolls, let’s just put it this way, a lot of people have been asking nicely and they were either paid no attention or were told QML is a necessity for modern GUI or similar lies. I’ve been watching the development direction of Qt for quite a while before saying something, and if there was any indication someone would have paid attention to a C++ GUI API, I wouldn’t even make a sound. But there was no such outlook at all, all the trolls claimed QML is the “future”, there was not even a hint that an improved C++ API is even considered. They always acted as if everyone is happy with QML and there are just isolated cases of people who are not pleased and want more, at least now they do have a clear idea that people like me are MANY, and if they are the nice people you appear to see them to be, they will take this into consideration. If they are willing to ignore the requests of that many people just in spite of me, well, that doesn’t speak that well of them, does it?

Up until a week or so ago I was just an ordinary forum member, I was doing my best to help newbies out, was keeping it polite and all that, and I was totally happy with that… And I am very sorry it had to come to this, but it is totally provoked by the direction of Qt and the attitude of trolls towards criticism of it, for this is merely the reaction to their actions that has been building up for a long time. Trolls are not god, they they cannot tell developers what is best for them, but they surely have been acting an awful lot like it, justifying the exclusive attention QML gets for it being a necessity, which is not really true, repeating QWidget is still there even thou no one complained about it disappearing, and all the other weaseling out… they have been acting like damn politicians, ignoring the concerns of long time developers and consistently pushing Qt in that concern rising direction like it is the best thing since sliced bread.

You reap what you sow!!!

Dave says:

@Dian

You repeated yourself again – including a lot of stuff that wasn’t necessary in a reply to my post – and completely failed to address my counter argument – you’re effectively asking for at least a hundred thousands of dollars of work to be done (at the low end) for functionality that already exists but doesn’t match your preferences.

To summarise my earlier comment – maybe it’s time to consider the possibility that you not seeing the response you want to this issue and you ignoring people’s counter-arguments and typing walls of text might be related.

Other people that care about this issue might be able to push it further by communicating more proffessionally / effectively.

Chew says:

@Dian. I’m not a Troll and as a professionnal Qt user for years I really like what was sowed by Trolls, but I really don’t like the Nokia public strategy since february 2011

Christian says:

@Dian:

I have to agree. I undertstand your concerns (and agree for the most part), but you are starting to sound like a zealot on a wholy mission.

Calm down. ;)

lemmel says:

@Dave.
Sorry but @Dian hits the point; the Qt framework is a C++ framework, and where are the news about the C++ side ? Where are the new API for C++ side ?
It seems to me that is quite normal that hard C++ coders feel a bit uneasy about QML: not about the technology itself, but about the feeling that there is nothing in Qt goals except QML.

I’m a C++ developer, and I want to be able to develop applications that
– have a native look,
– that get font size policies from the OS (e.g. for visualy impaired),
– do not require to have graphical oriented skills
– and so on.

I’m not complaining like @Dian but I understand him. What he said is true from the hard C++ coders point of view. There are people (like myself) waiting to see the power of QML (for it is promising), but it takes time to have something as shiny as the long time polished C++/Qt side. So wait and see.

Dave says:

@lemmel

I’m not trying to take one side or another when it comes to C++ or QML – I can see points on both sides – I’m just trying to point out that the way Dian is communicating isn’t coming across like he or she is a technical professional at best and at worst might be harmful to his or her cause.

Steph says:

Hmm, this has me worried. I write server apps for a fairly large (several million user) website, as well as clients for it that run on Linux, OSX and Windows using Qt4.

With the decline of C++, is that going to have any effect on the non-gui parts of QT? QObject, XML, Network etc?

Sadly I have a bad feeling about this. On so many other projects, when the maintainers / owners go in a direction that the majority of users don’t like, it’s the start of that projects eventual death. I really hope not, QT is by far the best C++ framwork out there.

stottle says:

“With the decline of C++, is that going to have any effect on the non-gui parts of QT? QObject, XML, Network etc?”
This comment just boggles my mind.

Having API compatibility and binary compatibility is a Good Thing. If the Trolls were making changes that broke that compatibility in QWidgets or the other c++ parts we rely on, there would be a LOT more people complaining. The fact that there isn’t a lot of feature work here is the sign of a mature, stable system, not a dead one.

Moving to “dynamic UIs” (I just mean anything where QML could be considered more appropriate than QWidgets) requires a lot of changes. If you disagree, feel free to use Qt 4’s state and animation frameworks with QWidgets to make your dynamic UI (all in C++, too).

The fundamental issue is that games (the real definition of dynamic UIs) use totally different rendering techniques than “standard” apps. And to get smooth dynamic UIs, the Trolls needed to use those gaming techniques.

The decision developers need to make is whether they need GPU acceleration or not (I think this is true whether you choose Qt or not). If you need GPU acceleration, and you want something cross-platform, you need OpenGL. With OpenGL, most C++ purists are going to be learning new languages anyway (I’m assuming most non-game C++ devs haven’t done a lot of GPU programming, and don’t program fragment and vertex shaders, texture loading, etc). I suppose if you ARE a C++ dev who is familiar with shaders, you could just use QGLWidget and skip QML if you didn’t like QML, anyway.

The Trolls took something as complicated as GPU accelerated interfaces with states and animations, and simplified it to a concise declarative language. The fact the achieved that is nothing short of remarkable, giving the amount of stuff going on behind the scenes.

So if you have a CPU-centric application, use the stable/mature QWidgets, they aren’t going away. If you need GPU acceleration, learn QML – I would guess in just about every case it will be faster (in learning curve and performance) than doing the same thing without QML.

I for one am glad that the Trolls are providing solutions to whole new categories of problems. I think that the Trolls (as they usually do) boiled the API down to its bare essentials. To those that disagree, could you provide an example of a better API?

Rene Jensen says:

I miss that these discussions could remain more pragmatic in terms of actual suggestions.

== TROLLS, YOU CAN SKIP THIS SECTION ==

The Qt4 series are in my view at the pinnacle of integration so far (and with the arc of development that Qt5 takes, probably for a while): QDeclarativeView is a QGraphicsView and all widgets can be stuffed into QML and canvas and vice versa. Very nice.

In my view, the QWidget system is somewhat flawed (though pleasant to work with being mature): It has mediocre separation between data and presentation.

The QML idea is clean and purpose-neutral:

– Except for QDeclarativeView and QDeclarativeItem, all classes in the declarative module is a straight way of making automatic dependency graphs of Qt meta properties. In theory a QDeclarativeEngine would not even need to be about a GUI.

– The declaration language is easy to parse, and in fact rather typical for home made C++ syntaces. E.g. I think Ogre too uses a curly brace notation for most scripts.

– It would have been a simple matter (and a healthy task) to separate the declarative engine from the script engine. Again in theory those are orthogonal aspects of requirements. 1) Let the engine maintain dependencies between properties in a network of QObjects – if necessary animate them over time. And 2) allow the engine to use complex scripted expressions to describe dependencies using a plugable script engine. No reason to fixate on javascript here.

== TROLLS, PLEASE READ ==

The most fundamental key to the success of QML as a new paradigm is A SOLID BRIDGE between C++ (which in many cases WILL deal with all the network and resource management) and QML using as few and simple classes for representation as possible.

(1) — Currently it is VERY unintuitive how to bridge complex relations! Your focus seems to be on Row’s, Column’s, GridView’s *model* property, which in most example get binded directly from the context. Bad choice: You don’t specify the TYPE of the property when directly assigning a context-property to a model. The tutorial may seem minimal, but in fact you make it more confusing.
Focus on the properties declared in a component, since they require a specified type. Bind the model property of a ListView to some subproperty of the specified property. Yes, we as programmers may need to think at first, but we avoid guessing at the name of the type in QML terms.

(2) — Don’t succumb to Javascript’s confused data model. Just about every script language in the world can make a distinction between objects (as instances of classes), lists and maps. In javascript it is practically all the same (indeed, I once implemented a javascript engine myself, so I have read the specs and can spot when you adapt that mentality in the Qt code). Lists are lists, maps are maps, and objects+properties belong to a separate world. Make javascript adapt to C++, not the other way around.

(3) — Make a sensible set of classes and stick to them. Looking at the examples in “QML Data Models” (“Structuring Data with Models”) it becomes clear that you didn’t spend the necessary time picking the right solution. Again, from torturous practice, I get the distinct feeling that the model property of lists can take more C++ data types than component properties:

CASE A)
Item {
id: mainItem
property variant companyObject
Row { … Repeater { model: mainItem.companyObject.allEmployeesAsQList } }
}
CASE B)
Row { Repeater { model: employeesAsSomethingBoundToContext } }

What C++ types would be allowed in case A and B? According to the docs, case B can deal with QStringList, QAbstractItemModel, QList, and probably more. Case A on the other hand is a lot more poisonous. I’ve been trying so hard to make it work, that I honestly can’t remember what is okay and what is not. Bad sign. Officially, if my storage in the “companyObject” is:

QList m_employees;

then I would need something like this property declaration:

Q_PROPERTY(QDeclarativeListProperty guests READ guests)

That thing there… QDeclarativeListProperty… is the sickest class I have seen for ages. What where you thinking! Pure and ugly hack. I have even seen an email dating from 2010 where you yourselves admit that a better solution based on a QList should be invented. You cannot postpone that task any longer.

I admit that job is hard. After a long time of thought, I couldn’t myself come up with a good design. Surely, the basis should be a clean C++ interface! You already have a very good set of core container classes. Amend them somehow. Loose thoughts: If I use QList, QMap… I am aware that they aren’t QObjects, so no signals or notifications if things change. You would say that if I want a “notifying” QList, I should use QAbstractItemModel. But the latter is a poor choice as a generic storage container, imho. No third-party library would adopt it.

I see the dilemma: QList/QMap etc. are fast, but outside the meta system, so no properties, signals and slots. Would a simple QMetaList, QMetaMap etc. suffice? I.e. the same methods as QList, QMap etc., but with signals when items change and slots for invoking methods via the meta system. I doubt it. To be of real value, QList and QMetaList should be interchangeable, since in that case the QMetaList could be used all over the Qt API just like QList. Even more important: The more third party libraries that adopt those core data classes, the easier it will be for those of us using QML to make use of those libraries.

And somehow QVariant, QVariantList and QVariantMap needs to fit into all of this.

Example, where I hint of the usefulness of a core set of classes that other C++/Qt libraries could adapt (hint: QxOrm or some JSON REST monitor interface that synchronized changes back and forth between a server):

class MyHouse { …
Q_PROPERTY (QMetaList guests READ guests … )
QMetaList m_guests;
.. constructor.. {
myJsonServiceMonitor.maintainTarget (&m_guests);
// The service monitor would itself connect
// to the hypothetical “itemAdded” signal etc.
}
}

The core data classes really needs to sparkle!

rafael castillo says:

@stottle you are right about qml and no one is denying that, ill try to put in a example our issues here qith QML(really scenegraph tho not QML per se)

case 1) you are a kopete(<-KDE SC app) developer and want to give kopete an impressive dinamic UI with lots of options and standard widgets.

case 2) you develop a Multi Layered GIS applications that need to fullfil realtime surface/layers changes of massive HD data and pixmaps,etc in regular bussines class hardware (mid class quadro/firegl cards) and at least support support SSE3 with handpicked cache optimizations / massive threading etc.

in case 1 QML use is ideal and the performance in the worst case scenario won't be less than QWidgets, everyone in this thread knows that and prolly most of the modifications can be done in an good afternoon of work.

in case 2 QML is a no go, the existing C++ is too massive to even think in port it to qml at least the main widget and QML is killer slow in this case but faster than a standard QWidget (you still right up to here)

so you may ask what is the fuss about if qml is still faster, well is simple using qwidget i can modify qpainter to use low level opengl rendering optimized for this workload keeping all the goodies of QWidget at the same time our issue is that having exposed scenegraph we can make this ultra complex C++ widget use the same capabilities of hardware accel that QML plus add some custom render code here and there to optimize for specific workloads plus the ablity to interact with other scenegraph render targets.

hence the request is not kill QML for the 100th time, the request is open scenegraph to the C++ api(this can be done by the comunity though)

Dian says:

@Christian – it’s not a wholy (I assume you meant holly ;) mission, it is just what I consider right. I do realize this whole issue brought out the worst of me but please understand where I come from. I’ve been working with HTML and Flash for a long time, and the reason I spent all this time learning C++ and Qt was because I wanted a solution to offer the best performance and efficiency, a solution to produce native applications. So I hope you do understand my frustration when the so called vision of the “future” for Qt is… QML, a solution that is inferior in many cases to HTML and Flash, especially since the latest iterations of those APIs and the tremendous improvements they feature, which raised the bar quite a lot. I don’t need QML, I already know how to develop in solutions that are established, widely used, supported everywhere, for me QML is a step back, and that’s a pretty lousy “future”. So it makes sense for me to not be happy, I chose Qt because I wanted a modern cross platform framework for native applications, not because of its recent endeavors to imitate solutions I can already develop in.

Lars Peterson says:

@Dian – I think for you QML is a step back and a lousy “future” because you simply do not understand QML and how to use it. For me QML is a step forward and a bright “future” because it is the best tool to create fluid user interfaces – an some time even you will understand this – at least I hope so :O)

Dian says:

@Lars – I’ve been creating fluid interfaces in Flash for over half a decade, and the last year in HTML, and I think if you paid a little more attention you’d realize my concern with Qt is it does not have a native C++ API for fluid interfaces. Another thing you seem to have failed to understand – QML does not make the UI, it only describes it. I completely understand the need for modern, fluid GUI, that is why I insist on creating a native C++ API for Qt, because it doesn’t get any “fluid-er” than native. Sure, there are tools for animation with QtGui, but the old API is not really optimized for such stuff, performance is not there, and it is much more tedious than it needs to be. Here I am, once again repeating the same stuff over and over again, simply because you didn’t bother to read before rushing into playing smart…

Dave says:

@Dian
–QUOTE–
that is why I insist on creating a native C++ API for Qt, because it doesn’t get any “fluid-er” than native
–ENDQUOTE

QML and fluid UIs are discussed together quite a bit, and it looks like you’re using a different meaning of fluid than most other people. Maybe that’s part of the problem here.

Given that, having a go at people for not reading or understanding is a bit rich. I thought Lars was pretty much right – and if he is (ie and you don’t understand QML) then it would be pretty much impossible for you to know whether he’s right, one way or that other.

Anyhow – I’d still be interested to hear a response to the counter-argument in comment 119 (ie you’re asking for hundreds of thousands of dollars of work / several years of engineers time, for duplicate functionality, based on a preference,).

Joerg says:

@Dian – On which part of Qt should Nokia stop to work to implement the QtQuick C++ API for you – QML 2.0? QML Desktop Components? Which part of the actual Qt project work should get dropped in favour of a QtQuick C++ API that simply repeats the already existing QtQuick QML API in C++?

Lars Peterson says:

@Dian – QML is simply a very powerfull tool to create next generation user interfaces. If you need to do a certain task, you take the tool that is best suited for this particular task. And QML is perfectly suited for the creation of fluid, touch friendly user interfaces – so it is the tool that is best suited for the task of creating such kind of user interfaces. C++ is better suited for implementation of the backend and business logic. Maybe QML is in a to early state for you to understand, that it is much more suited for the creation of modern, fluid user interfaces than C++. So maybe, with a little bit of patience, the time will come, when you will understand and appreciate the power of QML.

Ok, a C++ API would be nice – but I know that the menpower and the money is not infinite – the resources are limited. So instead of doubling a already existing API, I would prefer if Nokia puts their resources into QML desktop components. I’m sure, as soon as QML desktop components are released and the first QML based desktop user interfaces will popup the screaming for a C++ API will dissapear.

Dave says:

@Dian

You could do a lot of what QML does in C++ before QML existed, but it was a bit ugly. The unwieldlyness of doing those kind of tasks was recognized and solutions were sought. QML was that solution. If an equivalent solution that used C++ instead of Javascript was known it would have been chosen in a heartbeat.

(I happen to view QML as a data format, like the XML .ui files, but that might because I haven’t needed to use any Javascript to do what I need to do with it yet. But I’ll happily play “C++ vs JS” for the sake of laying out these points)

So you’re also asking for the Qt developers to commit to inventing something which the Trolls missed when they put their heads together and looked at the problem. Something which is completely unknown at the moment.

It would probably be better to
– ask people (probably in the community) to look for a solution for to the problem in a semi-organised way
– then polish up the solution and present it on the Qt5 development list
– if the list thinks it looks good, then you need to try to recruit enough people to implement the solution

That may still fall down though through the duplicate effort argument, especially if you include docs and tooling, and also because you’ll be asking people to volunteer there time for an uncertain outcome that could be 3-5 years away.

No matter how hard it would be to get the right number / quality of volunteers, coming up with the solution will be much, much tougher (although a good solution will certainly help with the recruiting).

Dian says:

@Lars – you continue to not get it – QML does not create those fluid interfaces, it just describes, what creates the actual UI is the C++ backend behind.

“you’re asking for hundreds of thousands of dollars of work / several years of engineers time, for duplicate functionality”

Several years of development time? It didn’t take that long to do Qt Quick 2 starting from zero, so but what measure did you calculate it will take several years to expose an already existing C++ backend to a native C++ frontend, and naturally polish it a little to turn a messy private API into a nice and easy to use public API.

@Joerg – I don’t think doing what I just described in the paragraph above requires any stopping of work or any drastic shift of focus or anything like that, from all the “arguments” I was presented with, my initial view that it is mostly “corporate politics” that wants to push QML into adoption is only being more reaffirmed, not any technological limitations, development logistics or whatsoever, just like any other company out there in the position to push their own technology without really being needed, Nokia is doing the same.

“QML was that solution.”

For the LAST TIME, QML is not the solution, drill that into your head, I am beginning to feel like I’m explaining to mentally handicapped people, the solution is the SceneGraph and Qt Quick, both native C++ backends, QML is just text describing structure, it could just as well have been XML, HTML, any other structuring language or even plain text or whatever. You say you are aware QML is just a data format, and yet you claim that data format is the solution? I hope you do realize the paradox here, your statements are in conflict. And no, it won’t take immense effort to do what me and lots of other people want, it already exist, it just needs some polishing, some documentation and there you have it, many people happy for the option of skipping on all the QML charade. The only problem as I see it, this will actually make QML optional, whereas today it is mandatory if you want a better GUI, which is good for people who want to enforce their own “language” by making some nice C++ backend exclusively available to it, like we’ve seen far too many times already.

stottle says:

@rafael castillo
I appreciate that you took the time to provide a real example.

Have you seen the QSGPaintedItem? It is intended to allow you to use QPainter based graphics from QML. I’m not sure what it does to performance, as it isn’t going to be optimized for OpenGL, but may point you in the right direction. I’m not sure how applicable it would be, but there are also ways to store coordinates for data points in an OpenGL texture and “draw the colors” (where r/g/b represent x/y/z) from a shader program in QML. Between those two and QGLWidget, you at least have a few options for something as complex as a GIS system.

Is there anything else out there that simplifies making a GIS application though? Is that a valid measure of whether QML (or Qt in general) is doing a good job?

http://doc.qt.nokia.com/qt5-snapshot/qsgpainteditem.html

@Dian,
Well, you’ve convinced me.

Not that you are right, mind you, but that rational discussion with you is not possible. Either you really think QML is some sort of Nokia conspiracy to force a new language on developers (in which case you are deranged) or you are arguing for the sake of arguing. Either way, best of luck to you.

rechtar says:

This Dian dude is really making me sick. His comments here are more and more like direct insults to the Trolls. Such a pity that we have members like him in our community :-(

Chris Adams says:

The concerns he raises are valid. As were many of the responses. This is getting a bit non-constructive in my opinion. I don’t know what I can or should say to address any of the concerns that have been raised (and I’m certainly not in a position to say “this will or will not be so” or anything) except to say that all of the concerns are important issues.

@Dian: the fact that there is no clean, nice, fully-featured public C++ API to access the scene graph at the moment doesn’t necessarily mean that there won’t be one in the future (although, please note that I’m not saying that there necessarily will be or won’t be, obviously that depends on resourcing, demand and so forth). But the important point is that it’s possible in the future. The scene graph is still a young technology, and the best API to expose it (from a C++ point of view) is still very much an open question. The QtQuick APIs are still private, for the most part, because there is a need to be able to change them (completely, if necessary) to maximise performance and ease of use as we find problems with their current form, or optimisations which require certain changes. That flexibility that is a requirement at the moment, while the technologies powering Qt 5.0 are still maturing. But in the future, once it has matured, that will not necessarily be the case.

What that means right now is that if you want to access the full power of the scenegraph, you either have to do a lot of the work yourself (defining geometry nodes and texture nodes yourself), or you have to use QML. In the future, that may not be the case. Qt 5.0 needs to be a strong base from which extensions can be made in the future. Making SC or BC guarantees now which may preclude allowing performant and beautiful extensions in the future is definitely not something we would want.

There are some “intermediate steps” which might be possible: for example, codepaths to allow construction of a QQmlEngine in JavaScript-less mode, where only v4 bindings are allowed (more complex ones, or var property ones, simply have an error thrown for them). That way, no JavaScript engine would be required, as long as you don’t import any .js files or use complex binding expressions or define dynamic slots or signal handlers in QML. Perhaps a step after that would be to define a QQmlAbstractBinding-derived class which allowed complex binding “expressions” to somehow be defined in C++ code (perhaps via a callback function ptr or something). Contributions are welcome.

By the way, QtQuick2.0 did indeed take many man-years of engineering time to develop – and it’s still undergoing development as we speak.

tbscope says:

I think I can read between the lines that one reason that QML exists is to have a separation between the C++ backend and the QML frontend so that it is possible to completely change the C++ backend without any real impact on the QML code. Not because it is the best thing since slided bread to make animations. Is that a correct assumption?

That would indeed be a nice feature to have.

However, in any case, Qt5 should not be released without complete QML desktop support. That’s my opinion.

MySchizoBuddy says:

Will there be a QTWighet to QtQuick migrator

Lars Peterson says:

@Dian

“Several years of development time? It didn’t take that long to do Qt Quick 2 starting from zero, so but what measure did you calculate it will take several years to expose an already existing C++ backend to a native C++ frontend, and naturally polish it a little to turn a messy private API into a nice and easy to use public API.”

This clearly shows that you have now idea about the time and manpower it needs to create a well documented public API. Often the task of polishing and documenting a private API needs more time then the previous creation of private code. And like many other people already explained it to you more than one times here: a public API means a stable API means a binary compatible API – you do not get such an API with a little bit of polishing here and there.

For doing this task, you need resources – time and menpower. So like Joerg already asked you I also would like to ask you: from wich part of Qt should Nokia remove resources to implement this API? You say you do not want to remove QML – but if you would like QML to become a serious tool Nokia needs to implement QML Desktop Components – and I think this is more important than putting resources into doubling a public API.

Jorg says:

@Dian

“.. you continue to not get it – QML does not create those fluid interfaces, it just describes, what creates the actual UI is the C++ backend behind.”

Yes, finally you got it :O). QML is e very simple but very powerful tool to describe fluid interfaces. The result will be a native compiled, GPU accelerated fast user interface. That exactly is the thing QML was made for. It is a language to describe something much more intuitive and easier than you would do it in C++. Nobody would insist on describing a HTML page in C++ – you use HTML because it was made for this task. And QML was made for the task of describing fluid user interfaces – so I do not understand why you want a C++ API when QML is more powerful, easier to use and if it is the tool that is perfectly suited for this task.

QML does not mean that C++ will go away from Qt sooner or later – simply because QML relies on native C++ code and all the Qt functionality and modules that are well known from Qt since a long time.

So why do you want to describe your UI in C++ if it is easier in QML and if you can save time and mony using QML? I’m quite sure, that even with a clean C++ API you would need much more time to reach the same goal like you can reach with QML. If you use QML, you can test the results instantly. If you do animations in your user interface, you need to tune and test the animations again and again and again until you have the perfect result. It is not like the static QWidget based interfaces where you change a property here and there. Now imagine, you would need to change a line of C++ code for each such iteration. Even if you need to build and link only one single C++ file, you are much slower than describing and testing the interface in QML.

And nobody says, that you need to build your whole user interface with QML. Like QtCreator shows you can perfectly mix widget based UI with QML. So if you have a big static application than you can use mainly QWidget and only use QML here and there for some nice fancy user interface animations that lets your application stand out from all the other “boring” ;O) (don’t hit me) desktop applications.

Dian says:

Quoting Henrik Hartz:
“We are (currently) using “Qt Modeling Language”. The TLA has some historical residue; it started as an XML language and was designed to instantiate a tree of QMetaObject’s.”

And that’s really all there is to it, a data structure description that is processed by an interpreter to instantiate a tree of objects, something that is 100% doable by hand. The structural concept of Qt Quick is the same as the structural concept of QtGui, the only differences are: 1) – Qt Quick 2 uses a new and improved backend; 2) – Unlike QtGui, Qt Quick has not public API to instantiate and build UI structure natively.

That means there is an already existing mechanism for instantiating Qt Quick natively, it is just not tailored as a nice and clean public API, and whoever claims this will take “several years” and “hundreds of thousands of dollars” is completely clueless.

The problem – innovation is presented in a way it cannot be used directly, but exclusively through QML, for the last time, I have no problem with QML, it appears to be the right tool for many people, and I don’t mint QML’s existence, and its usage, I mind me and many others being extorted into using QML without really needing it or be left behind with an outdated GUI API with lacking performance and tedious to use when building modern UI interfaces.

So, Lars, to answer your question, that API already exists, and it is a core part of Qt Quick, so your concern is that Nokia will have to redirect resources away from Qt Quick to dedicate some time to Qt Quick, which is foolish. Opening Qt Quick for native public use has a very high “cost-to-return benefits” ratio and will make Qt Quick much easier to extend, which will eventually benefit even QML fanatics like you.

“Either you really think QML is some sort of Nokia conspiracy to force a new language on developers (in which case you are deranged)”
First of all, I am just saying it looks that way. And to be honest, it is nothing new, we’ve had big companies doing it all the time, Microsoft is a shining example, and it does seem that recently Nokia is proudly marching, following in the missteps of Microsoft. It is ONLY NORMAL for companies to use the fruits of their developers efforts to push their own way of doing things, if you haven’t noticed that, chances are you have been living in a cave the last few decades. As I already stated countless times, it would have cost NOTHING to build Qt Quick to also be possible to use native from the ground up, and it would cost very little for its designers to clean up the already existing APIs and document them. The cost of providing the option NOT TO USE QML and the bunch of tools stuck to it is not all that high for the people who designed and know the structure of the backend, and the ONLY LOGICAL reason I see for not doing it is to make QML NECESSARY without really having to be.

Anyway, I’ve said all that needs saying at least a few times over already, and for those of you who still fail to get it, I don’t think you will even if I keep repeating it for years, because it is not me the deranged zealot, it is you who think developers should not have a choice and cannot provide a single adequate argument to substantiate your claims, claims you take for granted and mindlessly repeat without understanding the true corporate motivation behind them. You chose to be just as blind to the problems of Qt as religious people chose to be blind to the absurdities of their religion, and appear to be just as hopeless at “getting it” as they are too. And I know trying to explain to such people is a futile and wasted effort, so pardon me, if from now on I ignore the preposterous “arguments” you recite without even putting some thought into.

Unless someone steps up with some common sense, logic and reason in his posts, I am stepping out of this absurdity, because all that blind, fanatical devotion is getting ugly.

Uno says:

I’m not a qt user, but I don’t get it what’s so hard in creating public c++ api to qt quick and scenegraph. Why forcing existing loyal user to use qml only. Why not leaving a choice. I’m with Dian on this.

Lars Peterson says:

@Dian

“That means there is an already existing mechanism for instantiating Qt Quick natively, it is just not tailored as a nice and clean public API, and whoever claims this will take “several years” and “hundreds of thousands of dollars” is completely clueless. ”

No – here you are definitively completely wrong. I don’t know how much time and money it will cost but you need resources to implement this API that are better invested into making QML more powerfull and usable for desktop applications.

“And that’s really all there is to it, a data structure description that is processed by an interpreter to instantiate a tree of objects, something that is 100% doable by hand.”

Right :O). But why would anyone would like to do all this stuff by hand in countless hours if the QML interpreter does this on the fly in some ms?

“I mind me and many others being extorted into using QML without really needing it”

If you don’t need it – QWidget is still there – stable, mature and with a great C++ API.

I think you should have a little bit of patience and when QML desktop components are released, you should really try it – it will change your mind about QML in some hours :O)

Ron Berger says:

@Uno

“but I don’t get it what’s so hard in creating public c++ api to qt quick and scenegraph.”

If it is so easy – why don’t you make one?

Dewell says:

@Dian: “I am stepping out of this absurdity…” Thank You.

@others: Current plan to get Qt 5.0 out with powerful scenegraph and QtQuick 2.0 QML additions, then collect feedback and open up more C++ APIs, provide desktop components etc. with Qt 5.1 & 5.2 sounds excellent!! Humble thanks to all contributors!

Uno says:

@Ron
“If it is so easy – why don’t you make one?”
Like I said, I’m not a qt guy (I’m just interested in, but even if I was why I should do the work and not the authors?). Recently I wrote something similar to qt quick for my customer (of course not equals to qt quick in number of features) and one can make ui using xml (something similar to xaml) or directly in c++ code. And it wasn’t hard to implement that. I know that designing good api (if we don’t won’t to redesing it later or break compatibility after a year or two) takes some time but don’t tell the people it is undoable or it has no sense. From my point of view C++ api should be created in the first place and qml should be just an addition built on top of that. Qt was always about coding in c++. Why taking so radical steps in opposite direction?

c++freeloader says:

@Dewell Do you speak for the developers? If someone from Qt had said what you said that, “Current plan to get Qt 5.0 out with powerful scenegraph and QtQuick 2.0 QML additions, then collect feedback and open up more C++ APIs, provide desktop components etc. with Qt 5.1 & 5.2″, at some point, then I doubt there would have been such a fury. The whole problem is that it appears that most are willfully ignorant of the technical points being brought up and there hasn’t been a single acknowledgement from anybody in power that these arguments are valid and that they will be addressed.

c++freeloader says:

@Ron – just stop with that ridiculous argument. It has been made many times in the past and each time has been rebutted. Yes, it is theoretically possible for someone with absolutely no knowledge of the internals of a non-documented design to come up with a well polished API. But practically speaking, it aint gonna happen.

Ron Berger says:

@Uno

“From my point of view C++ api should be created in the first place and qml should be just an addition built on top of that”

If QML is the right tool to create fluid user interfaces, it it is easier to use than a C++ API and if it saves time and money creating the user interfaces – why should a C++ API be created first? I would like to have a powerful tool like QML now and a C++ API would be a “nice to have” later – but in my opinion people that once worked with QML will not use this C++ API because with QML you get results faster and easier.

Ron Berger says:

@c++freeloader

Yes, you are right. It should not sound offensive – sorry. I’t was not meant like “do it yourself” but more like “yes, it needs resources and menpower – if it would not need resources and menpower and would be that easy, we could all create this API on a afternoon”.

I think we all would like to have a C++ API (for free of course :O) – but the developers need to be paid and money is not endless – do it is a decision what is more important at the moment. An I think strengthen QML was the right decision because it is essential for modern fluid user interfaces – now and even more in the future.

c++freeloader says:

@Lars
“Right :O). But why would anyone would like to do all this stuff by hand in countless hours if the QML interpreter does this on the fly in some ms?”

Except that a properly designed C++ API version of a UI description is no more verbose and no less easy to understand than the same thing done in QML. With all the syntactic and library-based functionality provided stock in C++ (even more so with C++11), it is even likely that a moderately complex UI would be substantially less verbose than the QML version.

So a better question would be:

Right :O). But why would anyone would like to do all this stuff using QML when you can do the same thing just as easily and probably more easily in C++ and you don’t have any of the QML downsides.

Benoit Walter says:

I see that pride and arrogance are somehow interfering with the discussion. Some people are hurt and afraid because they might have to use the same language as the folk. I read some comments which roughly mean “QML is for the mass, but I am able to do it in C++” which skips the real question: is it really more efficient to use C++ directly for the UI layer of large projects?

Getting the same results as QML with a C++ API involves that the API relies on complicated structures, templates, macros, code generation or string-based interfaces (which would be nothing more than an embedded script….). Succeeding in making such an API elegant, intuitive and stable instead of using ugly hacks is not only a big challenge. It would also take a huge amount of time. The success however is not guaranteed and the benefits are still not obvious, even for large C++ projects. This is the reason why the main concern is whether the expensive time should be focused on trying to achieve that goal, or to focus on a new, promising QML language.

In my opinion, the primary focus should be to improve the current interfacing between C++ and QML. It is currently achieved in a non-explicit way, using dynamic properties, invokable methods or slots and signals. A possibility is to use a “bridge” object which delegates the functionality to the relevant C++ objects. It requires some work but makes especially sense for large projects as it requires a better separation between back-end and front end. For smaller projects, it means overhead and more complexity. It may be worth trying to find a better solution, with some kinds of interface contracts between C++/QML. That would also enforce the idea of using QML as an improved UI file, while providing a safe interface between the Quick/QML UI and the C++ back-end.

Lars Peterson says:

@c++freeloader

“Right :O). But why would anyone would like to do all this stuff using QML when you can do the same thing just as easily and probably more easily in C++ and you don’t have any of the QML downsides.”

Good question :O). I think at the moment it is a matter of a personal opinion – and in my opinion doing all the UI description (including states, animations…) will be possible (maybe) but never be that easy in C++. This is only my opinion and future will show if I’m right :O). And like Joerg stated in comment 142:

“Even if you need to build and link only one single C++ file, you are much slower than describing and testing the interface in QML.”

c++freeloader says:

@Benoit

To keep things grounded in reality, perhaps you could provide examples of QML functionality that would not be doable in C++ or would require “complicated structures, templates, macros, code-generation, or string-based interfaces”.

I have yet to see such a thing in any of the QML code that I’ve been exposed to, but am open to the possibility of it existing.

Dian says:

@Lars – if you have proven something, it is that you are completely clueless when it comes to programming. Countless hours? You do realize the interpreter does not write code for you, that you still have to write the QML, that in the absence of constructor parameter passing and in the requirement of additional structure defining braces QML code can actually get longer, not to mention additional custom component glue code, and last but not least, the interpreter will keep interpreting the QML code each and every time, for each and every user who runs the application over and over again, whereas C++ code is compiled to binary, you actually save some of the extra work, extra time and extra power usage/battery drainage for your end users (not that you have any, judging by the absurdity of your statements and the clueless-ness they reek of)

c++freeloader says:

@Lars. Perhaps I am just in need of convincing.

Perhaps you can post here a snippet of QML code which would illustrate by example your belief that “doing all the UI description (including states, animations…) will be possible (maybe) but never be that easy in C++. “

Konstantin Tokarev says:

Public C++ API of SceneGraph would be much more than just “defining fluid GUIs from C++”. Currently, widget APIs are available not only for C++ code but also for several scripting languages including Python and Lua. UI could be considered as XML binding. On the other hand, exposing new GUI APIs exclusively through QML is locking UI developers to one vendor-specific language which is neither standard nor even used anywhere else outside of Qt.

Konstantin Tokarev says:

@all those claiming that QML is interpreted only once GUI is being constructed:

UI files are usually interpreted during compilation so this little overhead doesn’t exist at all.

Lars Peterson says:

@Dian

“the interpreter will keep interpreting the QML code each and every time, for each and every user who runs the application over and over again”

Normally the users of our desktop applications starts them once or twice a day so then they can have a coffee and relax a little bit during the time the slow toy QML interpreter interprets the QML code ;O) *irony”

“you actually save some of the extra work, extra time and extra power usage/battery drainage for your end users (not that you have any, judging by the absurdity of your statements and the clueless-ness they reek of)”

Ah, ok – that is something I did not know until know. I always thought it was the bright display, the GPU or the WIFI and GPS parts that drained my handy battery. So you think in the future it will be the QML interpreter of all the QML scripted toy and trash apps that drain my handy batter? Maybe I need to think about QML again.

c++freeloader says:

To give an example of how C++ can be used in place of QML, I went into the Qt documentation and found an example that uses binding and other things. The example is shown directly below. Then below that, I put a hypothetical C++11 version of the same. As you can see, the C++ version is not necessarily much less readable nor is it significantly more verbose. Of course for the C++ code to work, it requires a proper definition of Rectangle class and MouseArea and so on. The C++11 version makes significant use of initializer lists and function objects. However, detailed understanding of those C++11 constructs is not required to understand the pattern of their use.
====================== QML version =================
import QtQuick 1.0

Rectangle {
width: 400
height: 400

Rectangle {
id: coloredRect
width: 100
height: 100
anchors.centerIn: parent

Behavior on color {
ColorAnimation {}
}

MouseArea {
id: mouser
anchors.fill: parent
hoverEnabled: true
}

states: [
State {
name: “GreenState”
when: mouser.containsMouse

PropertyChanges {
target: coloredRect
color: “green”
}
},
State {
name: “RedState”
when: !mouser.containsMouse

PropertyChanges {
target: coloredRect
color: “red”
}
}]
}
}
====================== C++11 version =================
#include

class OuterRect : Rectangle {
struct InnerRect : Rectangle {
MouseArea mouser;
slist states;
InnerRect(Rectangle *parent) : Rectangle(100,100), mouser(this) {
colorChanged().connect(ColorAnimation);
anchors.centerIn(parent);
mouser.anchors.fill(this);
mouser.hover_enabled(true);
states = {
{ “GreenState”, mouser.containsMouse, { this.color, “green” } },
{ “RedState”, unary_negate(mouser.containsMouse), { this.color, “red” } }
};
}
} coloredRect ;

OuterRect() : coloredRect(this), Rectangle(400, 400) {}
};

c++freeloader says:

Sorry for the lack of spacing in the above code. I guess the comment system removes leading spaces.

JubiluM says:

I’ll be repeating myself, but the bottom line: serve C++ users and you will be highly appreciated. Serve QML users and you will be highly appreciated. Putting an artificial, political line in the middle will turn the community into a battleground.

Turn this into win-win and cohesion by fruitful co-development and providing the C++ api for declarative stuff in the future also (believe or not, C++ users can live with the fact that the api’s change, it is our dog food), as well as continuing the widget development (there is no such status as done, there is always room for improvement). QML and Widget Qt can grow and exist side by side, unless it is a question of a political nature.

Clemens says:

That’s the “quintessence”, JubiluM!

One thing I don’t understand: Why isn’t it possible to spare just a hand of people from the QML team and let them improve the private API docs. This is not something irrelevant, this will of course come back to Qt, in form of more contributions due to the better understanding of the internals. So, it would be an investment into the future of Qt. What’s so bad about this?

Clemens says:

Another question, completely different topic:

Are there any plans to remove the meta-object system in future Qt versions? Would be easier today (e.g. with C++11) than it was, when this MOC concept was introduced.. were there any alternatives in the past? Maybe someone from the old Trolltech crew remembers something?

Jonny Dee says:

I just would like to throw my 2 cents in:

If there were a C++ API as alternative to QML then one could write a code generator/compiler that translates QML code into native C++ code (which might e.g. look like the hypothetical C++ version posted by c++freeloader). This would let you profit from the advantages of both worlds:
* Code can easily be maintained by editing QML files.
* During development you can profit from the fact that you don’t need to recompile after every change you make.
* The compiled C++ code obviously is more efficient.
* You can protect your IP, because the released software won’t include QML code (be it an embedded resource or not).

While I am not as concerend about the efficiency gain (or drawback) I am concerned about being able to protect IP, and this is my reason why I would appreciate a C++ interface plus such a compiler.

RealNC says:

I’m not sure that QML is really just “another option”. It’s not an option at all, because using QML results in non-native GUIs.

QWidget is still the *only* option in Qt5.

Konstantin Tokarev says:

Clemens: C++11 doesn’t feature reflection capabilities, so it’s impossible to remove moc.

JubuluM says:

@Jonny Dee

Really, really an interesting idea. Definitely +1 for that :)!

Lastwish says:

Check out the financials of Nokia Q1…It’s just sinking, we may have to abandon the firing ship. Please just listen to your users(developers&end-users). What does they really need? That’s your last wish to survive.

Simon says:

Is this the end? Nokia shares slipping, dumbest decision ever to use Windows on their phones (seriously, who on their board thought that was going to be a good idea!), and now taking a direction with QT that almost all the developers hate.

Hey, maybe its a conspiracy by their Microsoft partners to kill QT so developers will change over to using .net!

I see a migration away from QT by the masses, maybe to a fork by open source developers. Someone on the Nokia / QT board of directors really has no idea what their users / developers want, it’s like Firefox’s rapid release cycle – annoyed all the users and started the decline of their user base to the point where Chrome overtook Firefox.

Why is is the people at the top of these tech companies are so out of touch with reality?

The Nokia board should ENGAGE its massive user base, get feedback on what they actually want and need from QT, not try and force technologies we don’t want down our throats.

Goodbye QT, it’s been an amazing ride, very sad to see it end.

Const says:

Nokia moving to exploit third world people too, laying off people, 2300 in Hungary, 2200 in Romania, 1000 in Finland, people who were dedicated and now given the boot to pay for Nokia’s moronic failure.

Dewell says:

Please leave Nokia speculations to some other forums… Personally I’m waiting for my Raspberry Pi (http://wiki.qt-project.org/Devices/RaspberryPi) to arrive and run Qt5 on it! Then we’ll see how well QtQuick 2.0 & QML scenegraph really performs!

Ter says:

@Simon FUD, I see the opposite, use .net if you want, I’ll keep using Qt because it’s going better and better every day.

No feature is going to be removed, some features are added and it’s obviously impossible to satisfy all the wishes. There will always be some people which will criticize the new features regardless new functionnalities that will be developed by the Qt team.

Once again, thanks to the Qt developers for this amazing framework

Some Qt User says:

What I have seen from QtQuick looks great.

Some little summary of why a C++ API should be added for QtQuick
1. Qt is a C++ framework, it should therefore have a C++ API, and a modern one in order to replace the aging QWidgets
2. QML requires JS, which might not exist on all platforms
3. Bridging from QML to C++ and the other way round can be tiring whereas a C++ API could be not verbose at all (see #162)
4. QML is a language invented specifically for QtQuick whereas C++ is a widely used language and all the C++ API can be bridged to other language through PySide, QtJambi …
5. QML is resource, not native binary, which can provoke IP concerns.(#167 et #58)
6. Invented language can have problem. qmake is at least one example. Having a C++ API would mean that if QML gets buggy there would be an alternative

Of course creating a C++ API could take time.
In my opinion some strong sign that the C++ API is going to exist in a future Qt5.X version needs to be sent (a roadmap ?)
Having a C++ API would imply having a QtQuick C++ Library and a QtQuickQML library, the latter depending on the former.
Nevertheless as creating a complete API for C++ on which QML would depend cannot be done without delaying Qt5 for much time.

If QtQuickQML could depend on C++ private headers (which would imply keeping both lib in one repository) it could be possible to split QtQuick in two, QtQuickQML exporting the QML API and the QtQuickC++ being meant to develop the API in a future Qt version

The roadmap I would propose is :
Qt 5.0. Split of QtQuick in two library, source kept in one repository. QtQuickQML depends on private QtQuickC++ headers, no C++ API
Qt 5.1 Finish desktop QML QtQuick support
Qt 5.2-3 C++ API for QtQuick
Qt 5.3-4 Re-implement QtQuickQML in order to use the C++ public API, split the repository
The two smaller libraries could be then maintained more easily by two different team, one working on C++ without risking to break QML and the other working on QML.

Samuel says:

@Jonny: Yep, compiled QML would be great, and could possibly be prioritized for a future Qt 5.x release: http://lists.qt-project.org/pipermail/development/2012-April/003456.html

For many Qt users that might be of higher priority than a C++ API, since then you get the best of both worlds.

c++freeloader says:

@Some Qt User

Full Ack!! I really like your summary and proposals. If the QT management or developers would at least acknowledge that there are very good reasons for a C++ API and give a roadmap for when such an API is to exist, there would be a lot less grumbling from the user base.

Also, I like the proposal to split the code base and re-merge so that neither QML nor C++ side gets stalled and eventually, QtQuickQML is based properly on the QtQuickC++.

Finally, if the QT team was really serious about engaging the open-source community, they would actively seek their involvement and provide some guidance on various things. As it is, it would be very difficult and uncertain for some prospective outside developer to step in and provide assistance on certain things, because there is no visibility into the internal processes. Maybe I’m missing out on where these discussions are happening – if so, please correct me if I am wrong.

ary says:

@c++freeloader:

> If the QT management or developers would at least acknowledge
> that there are very good reasons for a C++ API

Or maybe those who complain about QML should start explaining what those “good reasons for a C++ API” are, exactly?
Not just vague and polemic pro-C++ sentiments.
Concrete, specific explanations of what such an API would allow a developer to do (and, roughly, how it could look like).

Remember that QML is not interpreted source code, its a data language. The QML input doesn’t “drive” a Qt Quick application, the Qt Quick engine (written in C++ and shipped with Qt) drives the application.
QML is merely used to define a tree of objects (visual and behavioral elements), which is translated into an in-memory QObject tree during the loading phase, and then the Qt Quick engine operates on those QObjects.

So your imaginary C++ API would allow replacing the single line of
view->setSource(QUrl(“myqmlfile.qml”)); // view is a QDeclarativeView*
with a long, verbose list of individual C++ function calls to create the individual declarative objects and link them (and their properties) together manually?
The end result would be the exact same in-memory QObject tree, which the Qt Quick engine could then start to operate on.
All you would gain would be a few microseconds shaved off the application start-up time – at the cost of greatly reduced readability and maintainability of your application code, having to recompile your app for every little UI change, and the Qt Quick developers having to maintain an public C++ API which in addition to the usual maintenance cost might very well make future optimizations of restructuring of the Qt Quick engine unnecessarily difficult or impossible. Do you really think that’s worth it?

Or what else, exactly, would your C++ API do?
Please be specific, otherwise you all come off as nothing more than C++-purists exhibiting a knee-jerk reaction at the thought of having to get their hands dirty with anything other than pure holy C++.

ary says:

@c++freeloader

You can find the Development mailing list here: http://lists.qt-project.org/mailman/listinfo

[PS: I’m not a Qt developer myself, but I follow the qt-devel list out of interest.]

ary says:

@Some Qt User

“2. QML requires JS, which might not exist on all platforms”

This is a misconception. The current *implementation* of Qt Quick is bundled together with a JS interpreter.

But the JS interpreter is only ever called *if* you use JavaScript expressions/functions when defining bindings or event handlers for your QML elements.
No one forces you to do that – you can choose to set only static values (or very simple dynamic ones, which the Qt Quick engine can handle without the JS interpreter) for all element properties in you QML file(s) and implement all imperative logic in C++.
In this case you would effectively be using QML as a plain replacement for .ui files (with the difference of being much more human-friendly, and benefiting from the high-performance graphics rendering provided by the Qt Quick engine).

The *current* implementation still requires the Qt Quick engine to be linked against the JS interpreter, even when the latter is never used. This is not an issue of the QML language vs C++, it is a limitation of the current implementation of the Qt Quick engine. On the mailing list a developer mentioned that the option to build Qt Quick without a JS interpreter will probably be added at some point during Qt 5.x, just not for Qt 5.0 (which is already feature-frozen and in alpha/beta phase).

Ter says:

@ary I totally agree with you, the real question is ‘what those “good reasons for a C++ API” are, exactly?’. QML is an evolution of .ui xml files (ok, a bit more ;) ), but it can be seen at least like that disregarding the lack of desktop components for the moment. QML is more readable than xml for sure.

David Johnson says:

If QML were strictly a descriptive language for the UI, I would have no problem. It would be little different from the XML markup of UI files, just a bit easier to write by hand. And using tiny pieces of JavaScript for bindings isn’t much of a problem either (although I would really like to avoid extra runtimes in tiny embedded devices where cycles, memory, and power are at a premium).

The problem I have is that C++ on the front end interface has been all but officially deprecated. Why is C++ good enough for the back end, but unclean for use in the front end? And what about Python? Is Python (via PyQt) not good enough for the front end either? Why are three languages needed for any non-trivial application, one language on the back end to do the work, and two (QML, Javascript) on the front end?

Dar says:

@Ter @ary

” @ary I totally agree with you, the real question is ‘what those “good reasons for a C++ API” are, exactly?’ ”

Are you serious?

Some buddies here need to read the comments above … please do it before commenting.

Samuel says:

@c++freeloader

Finally, if the QT team was really serious about engaging the open-source community, they would actively seek their involvement and provide some guidance on various things. As it is, it would be very difficult and uncertain for some prospective outside developer to step in and provide assistance on certain things, because there is no visibility into the internal processes.

The Qt Contributor Summit, plus the open governance, public development mailing list, irc channels, bug tracker, and review system don’t count as visibility?

Start here: http://qt-project.org/contribute

DG says:

This thread has turned into a haystack, so a bullet list of “good reasons for a C++ API” would be helpful.

@c++freeloader Your C++ example looks interesting, but wouldn’t that declaration just get compiled into some other internal structure at runtime?

Perhaps a C++ API could be written that compiles to QML, just to fool around with it and figure out what works and what doesn’t.

To all participants: Great thread! I’ve learned a lot here today.

c++freeloader says:

@ary, @ter,

Sorry, I can’t go back through all the comments and resummarize every detail there for you. Suffice it to say that the reasoning is all there, by myself and by many others. Feel free to look in the “Lounge” topic “Does Qt need a modern C++ GUI API” for even more in-depth discussion (and neatly outlined code). Sorry, I can’t put a hyperlink here to it. The last time I did, my comment was never posted.

Go to qt-project.org slash forums slash viewthread slash 16465

The one-line summary is: QML provides NO significant user benefits and has many costs in comparison to a hypothetical C++ API.

c++freeloader says:

@Samuel (alias capisce)

Thank you for the pointer. I guess I was too sweeping in my characterization of the contribution process.

What I really meant to say is that for something like the C++ API, let’s say that I actually want to go through the private headers and such, trying to understand the code. It’s not like it’s going to be easy to come up to speed on the internals when there is no documentation that tries to provide an overview of the architecture or generally provides guidance on what should or shouldn’t be done. But let’s say that I am masochistic and decide to wade through all that, reverse-engineering everything so that eventually, after a few months of nights and weekends, I get a good understanding. Then, I go ahead and spend a few more months of nights and weekends coding up a new C++ API. There’s no guarentee that it will even get accepted. From appearces here, it even appears that there would be good chance that it will get rejected for specious reasons. Then, if it does get accepted, am I on the hook for continued maintenance? Is someone who is paid to upkeep Qt eventually going to take over and continue the work that was done, or will it simply die on the vine.

In contrast, a hypothetical way for Nokia to go forward would be to say:

OK, we understand and acknowledge that a QtQuick and QtSceneGraph C++ API is needed by the broader community. We don’t have enough resources internally to staff up this project right away. Given that, we’re looking for a team of volunteers to help get started. We understand the difficulty in getting up to speed on the QtQuick2 code, so we’ve written this 15 page QtQuick2 and QtSceneGraph architecture document that should hopefully provide enough information to help you get up to speed quickly. In order to meet our other goals, the code and documentation for the C++ API needs to satisfy these specific QtQuick related criteria:
1. blah
2. blah
3. blah
If the code meets these requirements, and meets the other guidelines set forth in the open-governance web page, then we will incorporate the code into the mainline Qt release as soon as possible.

Samuel says:

@c++freeloader:

Then, I go ahead and spend a few more months of nights and weekends coding up a new C++ API. There’s no guarentee that it will even get accepted.

Agreed, that’s probably not the ideal way to go ahead (at least if you want your code to end up in one of the existing modules and not as an add-on, the latter is of course a possibility). Open source communities are usually not too happy about large code drops, but prefer tighter involvement with gradual improvements and cycles of feedback. It’s better to stay involved on the dev mailing list, and maybe hang out on irc. There you can bounce ideas back and forth with other Qt developers, and stay more connected with what other people are working on.

c++freeloader says:

@ter, @ary

You wrote: “Or maybe those who complain about QML should start explaining what those “good reasons for a C++ API” are, exactly?
Not just vague and polemic pro-C++ sentiments.
Concrete, specific explanations of what such an API would allow a developer to do (and, roughly, how it could look like).”

Well, for concrete specific explanations, did you read my hypothetical code example? sorry for the lack of indentation. It was indented before I hit “Post”.

As for good reasons, well, this list is littered with them (and BTW, no non-rebutted good reasons for QML/JS as of yet). But here is my own personal prioritized list of reasons. I hope with this list you’ll stop with this inane gibberish about there being no good reasons. BTW, this list is also contained in the Lounge forum item that I mentioned earlier, but I am repeating it here for your benefit.

1.Effectively disallowing the use of C++ to access any “modern” improvements to Qt GUI framework even though C++ is radically more flexible and has many language features and pre-existing libraries that could be put to good use to simplify design of non-toy GUIs.
2.Requirement to use QML to gain access to most recent Qt backend functionality, even though QML has been demonstrated to not have any signficant readability, expressability, maintainability, or writeability advantages over a hypothetical C++ API
3.QML is not proven to be useful to develop non-trivial apps (and no, Snowshoe isn’t non-trivial application of QML). Language design is notoriously difficult to do right. C++ has been on the development path for 40 years (if you take C as a starting point). QML will never compete against that. qmake is at least one example of a hacked up language.
4.Requirement to learn a new language that has no use anywhere outside of Qt
5.Requirement to use JS (yes, I know you supposedly don’t really need it, but from what I’ve seen, all non-trivial QML apps use it to some extent)
6.Requirement to learn JS when JS provides no significant benefit and is only really beneficial if doing significant amounts of web development.
7.Opportunity cost of Qt developers putting the cart before the horse and spending their finite resources on reinventing the wheel, rather than moving the framework forward in fundamental new ways. QtQuick and QtSceneGraph should have been developed in C++ first and with a public, documented API. THEN, if necessary, QML should have been developed on top of that.
8.Need to jump through hoops for anything more than minor QML/C++ integration.
9.Performance and run-time cost of QML/JS in comparison to compiled C++. Yes, they both must populate the scene-graph, but one must parse the QML and JS and then JIT the JS and finally execute it in order to populate the scenegraph. Sufficient performance for toy apps doesn’t imply sufficient performance for non-toy apps. Also, why waste energy for mobile apps where battery life is so important especially when there’s no good reason to do so. BTW, memory footprint will be bigger as well. In addition the footprint of all the supporting infrastructure (e.g. V8)
10.Lack of debuggability of QML and JS. If something were wrong in the implementation of QtQuick, you can’t simply pull up GDB and single-step the code (which I’ve done with QWidgets). With a pure C++ paradigm, you can still do that. Again, by taking this step of defining a whole new language and runtime system, Qt developers have bitten off more than they can chew. Now they need a QML debugger. They should be leveraging as much stock stuff as they can and using their development resources/talents to really add value in places that matter.
11.Requirement for OS to support V8 JS engine. This is specifically bad in the case of iOS where it may be that Qt5 will not be runable due to this. Maybe this will not be a problem, but at this point it could very well be. Of course Nokia doesn’t care about this (even though, for their own good, they should strive to be the leading provider of cross-platform development environment – but this is another whole thread).
12.Inability to use any of the readily available C/C++ static code analyis tools (e.g. Clang static analyzer) to help find bugs in JS script and other aspects of the UI.

c++freeloader says:

@DG

Regarding your question “c++freeloader Your C++ example looks interesting, but wouldn’t that declaration just get compiled into some other internal structure at runtime?”

Yes, both QML and C++ API would be declarative for many good reasons. That means that there is a process that needs to happen to convert them from a declarative form to something that can actually be executed by a CPU and/or GPU to render the screen image. With QML, you have to parse the QML/JS, JIT the JS, and then interpret the QML and run the JIT’d JS (I don’t know the exact details, but since they are using V8, I know they are JITing the JS). This then populates the Scenegraph and also possibly compiles up GLSL language segments.

Now a C++ version gets compiled up front so that there is no interpretation of QML nor JITing of JS. Rather the native code that is required to populate the scenegraphi is run directly. In the end both QML and C++ API version would end up populating the scenegraph with about the same thing. One tradeoff is compile speed – a C++ version would definitely require greater compile time than QML (which requires none).

Regarding your comment “Perhaps a C++ API could be written that compiles to QML, just to fool around with it and figure out what works and what doesn’t.”

This is a really insightful idea that would allow someone familiar with C++ to make forward progress on the C++ API without even touching the Qt internals. Not sure how to deal with the functional aspects of QML/JS though. (like signals, slots and states and stuff like that). If you try it out and make any headway, I’d be interested to see the results.

Kamth says:

Well, you don’t have to be a genius, just checking all the last qtlabs entries and all the talking about how wonderfull QML is and how we can achieve this and that with QML (heck even some folks are trying to make a build system with it) … the true seems to be clear: If this no sense (that devs don’t listen to their users) continue, then Qt will not longer be choosed for the new big and complex applicationes (read this as applications not “apps”)

Maybe Qt will remain on projects like KDE (free/open sources projects) but here we are talking about corporate projects, complete products … and even if that, there other big issues more important that all this QML stuff (¿want an example? itemviews issues have been pointed not only by enterprises user base, but by independent Qt/KDE developers too)

And btw, the people that are showing those kind of concerns (users like temp/dian, etc) don’t belong to the minority. OTOH some users have responded (blindly) to those concerns with: if you don’t like this model (QML as the unique bridge to new Qt tecnologies) then Qt isn’t for you; well, I have some news for you guys: if “we” as “users” that spread the use of Qt are getting this kind of responses, then we’ll choose not to use Qt anymore, so: what a piece of wise advice! … please, take those concerns with more inteligent approach.

JubiluM says:

@ary:

“Or maybe those who complain about QML should start explaining what those “good reasons for a C++ API” are, exactly?”

One obvious reason is that many developers want to use plain C++ in their project. That might be because of various reasons. I think that 99.5% of C++/widget developers have nothing against quick/qml and many of us use either where appropriate. But the C++/widget api is really important for thousands of projects, both commercial and open source. If you do not understand the importance of the matter please do not make yourself an idiot by understating others’ needs.

An important factor is also being able to use the development tools that suits the best. Maybe ary, you can tell how I can use, for example Visual Studio or XCode if I had a project that involves qml?

Mutual development of C++/widget Qt and qml profits both.

Dewell says:

@c++freeloader: Thank you very much for keeping the tone positive! Personally, I think the current approach of separate QML UI language is the right one. It is just so flexible and natural to write, making UI programming productive and fun again =) Simple QML could be turned into C++ as your example shows, but QML allows creating & binding UI components so dynamically that don’t know how much of it could be done at compile time. But I’m sure Qt community is open for technical discussions regarding this.

@Kamth: Qt devs do listen to users, and frankly it’s quite disrespectful to think otherwise. QML does not currently replace QWidgets in desktop applications and that’s why QWidgets are core part of Qt5 and not going away as explained in this blog post.

Summing up discussions here & mailing lists, in the Qt 5.1 / 5.2 schedule I would want to see:
– QML binary mode to be considered, for increased IPR protection and to (slightly) reduced startup time. Question is what the binary format would be and how much BC could/should be promised?
– Providing more public C++ APIs as discussed here, to make it easier to implement custom QML components and extending existing ones.
– Provide (desktop) QtQuick-components as part of Qt5 in a separate module. Components are required for QML to be considered as a viable option for QWidgets.

Mark Visser says:

QML is definitely the way forward. For those who can’t wait for desktop components to reach maturity in Qt5, you can play with them in Qt4.8:
http://labs.qt.nokia.com/2011/03/10/qml-components-for-desktop/
https://qt.gitorious.org/qt-components/desktop

DG says:

@c++freeloader: Thank you very much for the summary.

One of the previously stated concerns about a C++ API is that the developers want the freedom to make major internal changes if needed, and a public API would severely impair that. You said that your C++ example would be directly executed to populate the scene graph, but what if there was an extra transformation layer in between? By this I mean that your C++ declaration would be transformed into some internal implementation-dependent representation, and then *that* gets executed to populate the scene. In other words, you have a parser that instead of consuming a QML text file, consumes a C++ data structure. This might be a good way to decouple the public API from internal implementation. In the interim, a C++ API could be made to compile to QML, and then if that is worthy then the transformer could be written to do the direct conversion.

I understand the attraction to remove JS from the equation. My gut feeling is that a lot of JS usage will just be simple little one-liner expressions, and it is a shame to drag in a whole JS interpreter just for that. Perhaps there could be some non-JS mini-interpreter for these, or perhaps they could even be C fragments that get compiled. Or perhaps as computers and batteries get bigger, the size of a JS interpreter becomes irrelevant?

On a slightly different topic, I find my self comparing QML to SQL. SQL is an interpreted language without a C/C++ API. Much like QML allows decoupling of internal implementation, SQL allows completely different backend implementations (SQLServer, mySql, sqlite, etc). There are programming language specific ORMs that basically compile down to SQL statements, which is what I suggested above as a C++ API. This whole situation has worked out for some 25 years now. It is not exactly the same as QML, but the SQL experience can serve as a source of inspiration.

Patrick Noffke says:

I look at the use of QML as comparable to using UML software design tools or state machine design tools, which are then used to generate code (such as C++). Often the design tools are sufficient, and you can work 100% from within those tools. But there are many cases where they don’t do exactly what you want, so you need to get in and tweak the generated code. They you have issues with round-trip engineering (and designing the design tools to play nice once you’ve edited the generated code).

The designers of design tools cannot possibly expect to think of every use case (though the Trolls historically do a Very Good Job), which means there will be timed when you need to “fix” the generated code, or add some feature the design tools didn’t allow. I think this is a strong reason for providing a C++ API, or at least the ability to get at the code and implement some customization.

Kamth says:

@Dewell

I’m talking (mainly) about how many users have raised concerns on how Qt Devs are doing all improvements and new features (again mainly) to be used only by QML, also how there are other parts of Qt that need strong focus instead of QML. If you haven’t noticed this behaviour then I can’t do nothing for you to open your eyes.

… oh and btw of course I didn’t want to be disrespectful, big thanks to the devs for all the effort, but it doesn’t hurt to express my own ideas.

Donald says:

1) QWidget is done indicates that it is mature and not subject to major change. Anyone suitably competent and suitably motivated can step it and actively contribute towards developing it forwards. It is broadly used, drastic changes will require thorough regression testing but many people will appreciate any work which improves it beyond its current functionality.
2) QWidget is not deprecated, clearly, since there is nothing to deprecate it in favour of. It is currently marked as “done”, see point above.
3) OpenGL is a requirement for QtQuick 2 and fundamental requirement for us to be competitive. There are tons of terrible OpenGL drivers on the Linux landscape, and scenegraph is going to rip the scabs off these in a big bad way. Device manufacturers and driver writers have to step up their game, we are not going to step down ours. As consumers, you can vote with your wallets.
4) Some people are already hinting at scandal where we will actively discourage development outside of our primary focal zones. Feel free to air our dirty laundry; I feel useful people are met with warmth and ushered into our ranks with joy and I am not aware of any legitimate wrong doing. RIM are making major contributions and are doing a fantastic job of upstreaming significant changes.
5) I can’t demand anything of you, you can’t demand anything of us. You can pay via consultancy/commercial bodies, contribute code, or lend your technical expertise to API design/discussion, bug fixes or patches. We would value your input.
6) To those advocating the forking of Qt; attempt to duplicate our infrastructure and then extend QWidgets. Or simply contribute to it where it sits right now with constructive/mutually beneficial discussion/collaboration and useful feedback from the original authors. (People like Girish go through and eyeball QWidget related worked, and have long stemming insight into why the code has its current format.)
7) “How can I join the qt-project as middle/upper management?” – You can’t turkey, you join as someone useful and you ascend as someone useful. We aren’t actually looking for pocket dictators.
8) QML has to grow some additional functionality before its full merits become apparent for desktop developers, I hope we can land this functionality sooner rather than later since this I think this would win the hearts and minds of many people currently sitting on the fence.

c++freeloader says:

The last few posts here are funny in an ironic sort of way. Kamth first made a statement giving an implication that the devs don’t listen to users. To which Dewell responded “Qt devs do listen to users, and frankly it’s quite disrespectful to think otherwise.” After this Kamth responded:
“I’m talking (mainly) about how many users have raised concerns on how Qt Devs are doing all improvements and new features (again mainly) to be used only by QML, also how there are other parts of Qt that need strong focus instead of QML. If you haven’t noticed this behaviour then I can’t do nothing for you to open your eyes.”

And this was immediately followed by a post from an apparent dev, Donald which essentially confirmed what Kamth was saying all along. Apparently everything that was said in this drastically long thread (and the other in the Forums Lounge) went in one ear and out the other.

.QED.

dcarr says:

@cc+freeloader:

Don’t mistake me for a Qt dev; I am a benevolent semi-civilized chimp, yet I find myself flinging less dung than the average participant in the discourse above.

We read the blogs, this is a good forum for feedback, and I think people are well aware that there is some demand for a C++ API for scenegraph. You don’t know the internals of our classes, and we could afford to improve the documentation to lower the bar for contribution. We aren’t deliberately starving you of documentation, when Qt 5 settles down, this will undoubtably improve with time.

Other people, that is actual contributers, are managing to come to terms with the code with its current level of documentation and actually helping us drive this project forwards. Those people are wonderful.

The point of this blog, which is thoroughly buried under these comments, is to dispell FUD, FUD that is being aggressively peddled in the comments amongst legitimate feedback/grievances. The take away is that QWidget is not deprecated, but awaiting suitably passionate people to drive it forwards. We welcome your participation. Classes like QGraphicsView serve a purpose and continue to exist to serve that purpose in Qt 5. As Sam indicated, you will probably want to create your own custom GL scenegraph if you are dealing with an exceedingly large number of items; general purpose classes have a hard time handling extreme usage.

There is no guarantee of a one to one mapping of functionality between QML and C++. there is a massive amount of work that stills remains to be done and duplicating existing functionality (for any reason) when so much important/low hanging work remains, would be folly.

Speaking for myself, I personally hear your proposal, I just happen to disagree with it heartily. There is a distinction between listening to users and complying with every users demands. I am very glad you are not our captain, or I would be severely inclined towards mutiny. I think our technical leadership is doing a damn fine job.

We could really use some desktop components :)

yang says:

I am very disappointed to have this release, because I use the QT nearly 10 years, but when the QML came out, I found that he was a very modern programming framework, I have developed Alcatel’s feature phones eight years ago, which frame was so similar QML(QT), so sometimes I think it is not Qt5 QML , that is only a Nokia development frame to move the name of the QT.

c++freeloader says:

@dcarr

All the raving QML fanboys around here can’t seem to present one cogent technically grounded point to justify their QML fanboism. Instead, mindlessly repeating one or more of the following as if by repeating it enough times, that will “win” the argument.

1. QML can do stuff that C++ can’t
2. QML is easier to develop in than C++ or more readable, or more maintainable or … my favorite “more fluid”.
3. Qt devs don’t have enough time to do a C++ API
4. QML avoids having source and binary compatibility issues
5. There is almost no cost to do QML
6. If only you wait long enough, QML will have all the features that you need and everybody will be won over
7. You can still use QWidgets and they’re not deprecated, so what’s the problem.
8. If you don’t like what the devs are going, go find another toolkit
9. It’s open source, so roll up your sleeves if you’re not happy with what’s there.

Each and every one of these arguments (except perhaps #3) has been rebutted time and time again (not just by me) using concrete examples and other rational arguments. I’m not going to repeat them here, because it has become obvious that the fanboys have drank the koolaid and are willfully blind to rational reasoning. #3 is only that way, because the devs have prioritized creation of a new language, new runtime, new documentation, new examples, new tools, etc, when such creation of such was not justified by the benefits. Qt5 is not out, among other reasons, because they’re still paying the price for this decision.

There are plenty of things that are going right in Qt. Lighthouse, Scenegraph are two prime examples. Modularization is another. QtCreator is another. Unfortunately, QML is not one of them. Surely, I wouldn’t care about QML’s existence, if it didn’t preclude usage of native C++ and it didn’t suck away resources from other more important work.

Donald says:

@c++freeloader:

I have seen very little structured rational discussion in these comments. This is a great forum for fuzzy feedback across a large swath individuals. although it clearly isn’t serving that purpose now. There are probably around 30 unique people commenting on this blog post. People writing large sweeping technical arguments should really be directing them at the qt-project dev mailing list:

development@qt-project.org

Because I am clearly a sucker for punishment:

1. QML can do stuff that C++ can’t
QML and C++ are not at odds. QML is a domain specific language. We are a C++ house. We are zealous, although clearly we are far more moderate than I originally suspected. You know what your QML style C++ reminds my humble eye of? The hoops people jump through to write object orientated C. It is doable, but why fight a language for the sake of it? Ah, for performance. We are taking Qt down to the point were it runs extremely well on incredibly low end hardware (with nice GPUs, granted). We are using it/testing it on a daily basis. You have to realize your performance claims ring awfully hollow when we have concrete evidence directly to the contrary. We moved to Qt 5 to lower the hardware requirements of Qt and become more competitive.

The burden of proof about inferior performance is on you. We are performing our own research, Its findings run entirely contrary to yours.

2. QML is easier to develop in than C++ or more readable, or more maintainable or … my favorite “more fluid”.

We are putting serious effort into QML and hope to disrupt existing development paradigms. We are the same trolls we always were, and we are excited about our tech, like we always were. Shoot us. (I keep on seeing this straw man fallacy where people blame Nokia for our technical direction)

Easy is a contentious subject. We think the language is concise, elegant and powerful.

3. Qt devs don’t have enough time to do a C++ API

This is not on our immediate roadmap and there are far more pressing tasks. Correct. Are you going to contradict us? I didn’t get my cheque from you for last month. Ah, thats right, Nokia cuts my cheque and hence I can’t actually focus on polishing your shoes/preparing an omelette for you.

4. QML avoids having source and binary compatibility issues

QML bypasses the binary contract issue. I have personally ported a lot of code from QML 1 o QML 2, it was rather pleasant and involved me dusting off my sed skills. We do this via a hand behind the curtain which switched out the rendering engine and JS backend when you weren’t looking. You want us to drop the curtain, and yet still perform magic?

5. There is almost no cost to do QML

We are prepared to accept the cost for the gains, clearly.

6. If only you wait long enough, QML will have all the features that you need and everybody will be won over

No, there are currently some functional gaps we really need to fit before QML will be on a functional par with QWidget based functionality. Some people will not be won over, but we will actually be meeting many peoples needs and hopefully see a drastic increase in QML usage on the desktop which will clearly harden the product.

7. You can still use QWidgets and they’re not deprecated, so what’s the problem.

QWidget is here to stay, don’t worry about the FUD about it going away. It is not like qt3support in the Qt 4 era.

8. If you don’t like what the devs are going, go find another toolkit

Again, no. We have a clear agenda and clear goals. If our goals do not exactly overlap with yours, the good news is you can still heavily influence the project via a plethora of ways: Direct contribution, commercial licensing or QA/technical input. You will find shouting at us as productive as shouting at people in the real world tends to be.

9. It’s open source, so roll up your sleeves if you’re not happy with what’s there

Or pay someone else to roll up their sleeves and shout at them. You have to pay me to shout at me, or I will simply walk off.

Rupert says:

@c++freeloader: The dev team are predominantly Norwegian/German. It does not matter how big a plume of steam you blow out of your nose about performance; Empirical data über alles

Robert says:

@Donald

There are also enough shitty OpenGL drivers on Windows to make life miserable, especially when you have business customers without high-end graphics cards.

They all tend to work…somehow. But not quite the same way. And sometimes things will work differently on the secondary screen. Or not at all. Or you’ll spring resource leaks. And it’s enough if 10 % of your customers are having issues, if you don’t have enough leverage with the graphic card vendor to fix their drivers. Are you going to write a second graphic implementation for those customers? Drop them? Get a bad name in the market?

I’ve been through this nightmare, thank you very much, and I have no desire to repeat it. I’ve written my software to require only OpenGL 1.1, which is supported by a software driver from Microsoft. It also has a few bugs, but I can work around them, and I know they’ll be the same for each customer.

OpenGL is fine for professional graphics like CAD, where people have proper workstations, and also for gamers who are passionate about their graphics cards and drivers.

(Accelerated) OpenGL isn’t for everyone.

Samuel says:

@Robert

It’s silly to not have our UIs take full advantage of the GPU at this point, considering both the improved performance, quality, and power efficiency. There are solutions for Windows that don’t involve using Microsoft’s or the GPU vendor’s OpenGL drivers (should they be of shoddy quality), the simplest might be to use the ANGLE wrapper that converts OpenGL API calls to Direct3D. ANGLE is used in Webkit (for Chrome and other browsers) to render WebGL, and thus it should already be well supported and stable.

Donald says:

@Robert:

This is a legitimate point of divergence between optimal performance/battery life for embedded devices and desktop applications. I know terrible OpenGL drivers exist on every platform.

1) I am glad Intel have raised the bar on entry level drivers/hardware
2) We are not the only people struggling to cope with this problem (As Sam mentioned, Chrome and friends are battling this very dragon)

This is exactly one reason why we are stressing that QWidget is not going away, and Scenegraph (OpenGL hard requirement) is a parallel technology you can choose to use if the constraints/benefits appeal to you. It is not mandated. In a perfect world, you could use QtQuick 1.0 for your desktop applications (if need be) and QtQuick 2.0 for deploying it to constrained embedded devices.

The extent to which the UI is going to be reusable is highly debatable. We are clearly at a point of heavy transition in the industry and many people are going to be angry/griping about both Apple and Microsoft’s move towards mobile/portable UIs/UI paradigms. We are just a large green (Trollish) canary. What is every more ironic is that the most constrained devices now have the highest resolutions in widespread usage, all thanks to Apple. Do you know what happens to an ARM Cortex A9 when you try to have a raster engine render 2048×1536 pixels? This is currently present on only one device, but it does not a wise man to see the competitive advantage this has lent Apple and gamble how rapidly the market responds in kind. (Even Android phones are now 720p, which is enough to have any moderately complex painting crawling along if the CPU is driving it)

No, the move to OpenGL was required for us to be competitive in the mobile space, in terms of both raw performance and battery life. I have not evaluated this (ANGLE), but agree that flakey GL drivers are liably going to be one of the biggest pain points ahead.

TheDude says:

http://code.google.com/p/angleproject

“ANGLE is an early work-in-progress, but when complete, …”

Can we please stop wishful thinking and stay in reality?

Samuel says:

@TheDude:

It has passed the OpenGL ES 2.0 test suite, and Google Chrome _and_ Firefox use it: http://www.i-programmer.info/news/144-graphics-and-games/3471-googles-angle-brings-opengl-to-windows.html

Using ANGLE is not a pipe dream.

c++freeloader says:

I am also a sucker for punishment, but I’ve already been punished enough over the past week. So I’m not going to spend the time to make this post extremely well written. Sorry about that.

1. Regarding domain specific languages – already addressed multiple times. Demonstrated many good reasons to not use domain specific language. Either you didn’t read them or you’re willfully blind. C++ example almost mirrors QML, slightly less or more verbose depending, again voiding your argument. Good performance of QT5 has nothing to do with QML. No requirement to use QML for better performance. This has been talked about to death, but again, someone can’t read the comments in this and the other threads. And if you bothered reading my prioritized list, you would see that performance of QML versus C++ is far down the list of issues.

2. Obviously you’re putting serious effort into QML – and by the rules of finite resources, other things suffer. Of course, this was on my list of issues as well. Of course the trolls should be proud of their tech. As I said, there are many things right with Qt. But it’s not a question of pride, it’s a question of doing something that has little or negative value while sacrificing things that have positive value. There’s no question the language is concise for what it does. But the fallacy of this point has already addressed to death in many other comments. No point in rehashing.

3. Yes, Nokia pays your bills. So, if Nokia management wants you to do QML you do it. Obviously. And if the management is too technically incompetent to question koolaid imbibing engineers, how else can they see the other side of the story? One way is for some devs to stand up and say, “Wait a minute, is this QML thing really the basket we should be putting all of our eggs in? Have we made some assumptions that in hindsight are incorrect? Did we really look at all the options before embarking on this QML project? Aren’t we spending a lot of time doing something that could have been done in a much easier way? Are we really providing unique value for our users or are we just reinventing the wheel? Are we really offering our users what they really need?”

4. Obviously, there are other ways to achieve binary compatibility than by introducing a whole new language on top of the system. Been addressed in other comments. No sense in rehashing.

5. The gains are minimal at best and negative at worst. So the ROI is either nearly zero or negative. Given finite resources, this also introduces opportunity costs. This topic has been covered many times also.

7. Regarding QWidgets going away. For the Nth time, people are not concerned about them going away. If you haven’t understood the concerns then again, you haven’t bothered reading what people are saying or you’re willfully blind.

8. Who says I’m shouting. If you perceive legitimate criticism as shouting, that’s on you. If countering falsehoods or educating people with concrete examples is considered shouting, I’m not sure what to say. If having to repeat arguments over and over again, due to unwillingness to read through the threads or due to willfull blindness is considered shouting, then what else can one do other than pick up their toys and go home. If the only way not to shout is to not criticize, then I guess I have to shout. A year ago already, people were expressing many of these same concerns. But the devs or the management (not sure which) were hell bent on their direction, so here we are.

My suggestion is to go back through the comments on this thread and even more so, the other one in the “lounge” (can’t provide link or this post disappears). Put aside for the moment that QML is your baby and that you’ve worked really hard on it. Reread what the detractors are saying. These aren’t stupid or ignorant people – maybe I am, but most of them are not. By a roughly 2-1 margin, people are voting that QML is not the be all end all and something else is needed. Of course none of us are expecting the devs to drop QML, but that doesn’t mean that the devs can’t acknowledge the concerns and take them into account.

Robert says:

@Samuel, Donald:

I know there are difficult choices to make. I could escape my own nightmare only because my performance requirements were such that software rendering alone was sufficient. On the other hand, I was on my own in this, I had no hopes to single-handedly fix the issue of graphics acceleration.

If the Qt team is willing to dream my nightmare for me, and I can rely that my software is going to work on every standard desktop PC on the market, kudos to them!

qtnext says:

Angle is needed to support qml apps with movie on embedded windows (or small computer) … We need to use the power of the gpu to decode the movie (for example on atom platform) and there is no way to decode movie with gpu on opengl … we need to have directx !!!
for me, qml is amazing (need qml desktop components for sure) but we need movie hardware decoding to be usable on low perf computer with windows

Domino says:

@c++freeloader: you just managed to write some C++ code which roughly looks like the QML one for a small, specific example. Using nested structures, initializer lists and function bindings…

Just a few comments:
– First, C++ will never be the right language to use nested structures to represent a tree
– Binding must be explicitly done, which makes the complexity exponentially grow as soon as you use typical QML expressions. In your example, you skip the most interesting QML cases where properties are binded to each other (e.g. “width: parent.width * 0.2 + ( brother1.width > brother2.width ? 150 : 50 )”)
– It is questionable whether an intensive use of fctors or lambda functions leads to an intuitive and maintainable code. Alternatives (such as using interpreted strings) would not help that much to convince that a C++ binding really makes sense.

And believe me, after working for months on a C++/QML project, the binding functionality is the real strength of QML. And in the future, modern GUIs will use it quite intensively. On mobile devices, we already see the need. It will be the same for modern desktop applications.

Real examples would clearly demonstrate that a QML-like description can only be achieved in C++ using complex mechanisms. Succeeding in creating a clean and elegant, Qt-like, C++ API is not a simple task. It might be possible but the question is whether it is really worth trying to reach that goal for the sake of using C++. Qt must be prepared for the future. The competition, in the mobile segment but also for desktop applications (the gap is shrinking…) is very high and there is no time to loose.

JubiluM says:

@Donald:

Really funny, but proves the point. If a decision has been made on a political basis, there is no counter argument for that. I’ve seen enough of bad decisions in it-business through the years and what I am seeing now is a stubborn Nokia-way of doing things. This is, not understanding at all of users’ needs. Which will lead you down the drain, believe me.

You could have it all if your vision weren’t blurred by a couple of buzzwords and what is most important, you could have it without doing duplicate work. Give us qml, it satisfies the mobile developers’ needs. Qive us widget Qt (with an api to use also declarative-stuff), it satisfies the desktop developers’ needs. You have a perfect solutions for either use case or domain. And no wasted resources trying to re-invent the desktop-development wheel. And by saying “give us” I mean giving us something that is under an active development. By developing heavily C++ backbone you could consume the fruit of that development effort both in widget Qt and qml. Everybody would be happy.

Ok Donald, first since you are an expert, I’d be delighted to get your view of a question that is hanging in the air and what I consider important. What C++/widget Qt allow and what is very important, is developing and debugging with various ide’s. Will it be possible to develop qml and work with, let’s say, Visual Studio or XCode? Other issues why many prefer pure C++/widgets-combination already addressed, but haven’t seen any comment on the above.

I’ll put my 2 cents on your sins:

1. Vice versa, both have their natural domains. If you do not understand the importance and reasoning of being able to use pure C++, be at least smart enough not to give an impression of a dumb monkey by deliberately pissing off people.

2. “fluid” sounds cool and almost gets me aroused. Easier, more readable, easier to maintain…it might be that for small throw-away projects, but you know, the object oriented structuring of software is there for reason? When it comes to really complicated stuff….let’s say Qt itself, or Qt Creator, anything compared with qml will become an unmanageable mess. If you look at the Qt source code, you can see that it is well written, compared to its size, it is well manageable and using widgets is child’s play even you weren’t that familiar with C++.

3. It is always the matter of resources. And if all the focus is being put on the buzzword, the consequence is of course focus being lifted from somewhere else. And if there is a political decision behind, nothing can change that.

4. No it doesn’t. I can’t for example get Scribus running using qml. It’s been coded using widgets and, I believe, will never ever be ported to qml. So, serious source compatibility issues in any project that is comparable in size with the mentioned.

Source compatibility issues are dogfood of C++ developers, we can eat it and cope with it. It’s all right. But changing to a different language just for the buzz is an issue of totally different order of magnitude.

5. Huge cost for any big projects using Qt widgets, if they were to be ported to declarative. I suspect that majority will keep on using widgets since there is no actual gain from qml, if we talk about desktop usage.

6. qml baby is not even crawling, if we talk about desktop. It doesn’t make any sense to repeat the job already done not least for the fact that it’ll be 5 to 10 years or so before any sensible person would even think of qml being mature enough in desktops. And even after that it would be a wrong paradigm in a wrong domain.

7. That is good to hear. Had you totally lost your mind by even considering something like that would have been an epic suicide not seen before. Also, Digia seems to honestly understand also C++ programmers’ various needs, so I feel kind of confident.

8. There is not a library that quite compares with Qt, especially if one’s programming language is C++. Qt also serves a dozen of other languages so it is quite important. Still, it is important not to rely too deeply on something. Keep the gui layer thin as possible. And study also other libraries. One should never ever suck anything vendor dependent (especially qml) into application logic. Well maybe if it were a trivial throw away.

9. I’d love to contribute in a form of throwing some code in. Just wish I had the time (even to study Qt internals)…from my family, daytime job, an open source project into which I contribute (using Qt).

Samuel says:

@Jubilum

If you do not understand the importance and reasoning of being able to use pure C++

QML is not the enemy of C++, they co-exist happily, with QML being used for the front-end UI (like the old .ui files), and C++ being used for the backend, exposing properties that can then easily be used and bound from QML.

Easier, more readable, easier to maintain…it might be that for small throw-away projects, but you know, the object oriented structuring of software is there for reason?

QML is also object oriented and well-structured.

And if all the focus is being put on the buzzword, the consequence is of course focus being lifted from somewhere else. And if there is a political decision behind, nothing can change that.

QML is not a buzzword, it’s a technology that many already use and love, and that makes it a lot easier to write well performing quality GUI applications in a rapid way. It’s also not politically motivated, it has been developed by the trolls because it seemed as the right direction, and we do have a lot of experience with GUI programming. Here are some blog posts from the past that shows parts of the journey to get to where we are now:

http://labs.qt.nokia.com/2007/09/05/thoughts-about-graphics-performance/
http://labs.qt.nokia.com/2008/11/06/welcome-to-kinetic/
http://labs.qt.nokia.com/2009/05/13/qt-declarative-ui/
http://labs.qt.nokia.com/2010/05/18/a-qt-scenegraph/

Keep the gui layer thin as possible.

Good strategy, would also make it relatively easy to port from QWidget to QML if desired :)

Clemens says:

Where are any docs to the internal classes? It’s much harder to understand the code if you do not have any docs, why do you only document the public API? An open source project without documentation of ALL parts, especially the most important ones, where the real functionality resides are ABSOLUTELY NOT documented. You have to go through the code manually and learn it the hard way. You could save manpower if you did some internal documentation..

This QML discussion is hopeless: There are the QML fanboys and those who criticize them, but no real progress is made, even though arguments were exchanged.

It’s a wise thing, to take different view points. For example: Take the view point that QML is not gonna become a success, just assume (hypothetically) that QML will flop extremely.
Maybe you all should have a Plan B, and have at least one or two people writing internal documentation, which would lead to much more and, what’s most important, more serious external contributions.

A qt fork would be the last option. Sometimes it seems that even at Nokia, there are only a few people who really understand the Internals. It would be also a great improvement for your other employees, if there is an internal documentation.

JubiluM says:

@Samuel:

“QML is not the enemy of C++, they co-exist happily, with QML being used for the front-end UI (like the old .ui files), and C++ being used for the backend, exposing properties that can then easily be used and bound from QML.”

They can co-exist, that’s what I have been saying if you have read my opinions. But you make the classic mistake by supposing that everybody wants to use it. That is why C++ api for Qt widgets for declarative stuff is so important. Because qml is no no in many important use cases. I know it hurts to hear it but it is a fact anybody cannot deny. Or you can try and make yourself an a**h***.

Ok, so I hope that now you get it right :), I am pro widgets and pro qml, they really can co-exist but you got to give the user to make the choice. They both cover important use cases. Same as it is with the other tools user uses at his/her work.

“QML is also object oriented and well-structured.”

It is really hard to write large, complex applications using qml without creating an organizational nightmare. When I see Qt Creator written totally in qml, I’ll believe you and quit smoking. But I know and probably you know too that it would be wasted effort, would not perform well and is not about to happen’ any time soon, am I right?

“QML is not a buzzword, it’s a technology that many already use and love, and that makes it a lot easier to write well performing quality GUI applications in a rapid way.”

I agree that it fits its domain perfectly, that is a language/gui-toolkit to write small, quality GUI applications in a rapid way.

“Good strategy, would also make it relatively easy to port from QWidget to QML if desired”

Isn’t it. You never know when an ill development decision is about to be made and if you’re not prepared, you might end up in a dead end. Still QWidget to qml port might be pain and effort thrown in vain, if you talk about large, tested and tried desktop applications. As for an example, Scribus.

And if making a mixed language mess, or using ide other than Qt Creator, or creating extra complexity in debugging doesn’t fit your use case or scenario, porting to qml is not an option.

But anyways, all the best for you and all the Qt devs out there. The issue raises many concerns and strong opinions. That is only because Qt is an important software for many developers and projects.

P.S.
“Here are some blog posts from the past that shows parts of the journey to get to where we are now:”

I know, I’ve read it all since day one…

jdavet says:

@Dewell “Summing up discussions here & mailing lists, in the Qt 5.1 / 5.2 schedule I would want to see:
– QML binary mode […]
– Providing more public C++ APIs […]
– Provide (desktop) QtQuick-components […]”

While they all sound nice (or at least not harmful) to have in the long term, I would prioritize them very differently. In fact, there are quite a few potential additions to Qt Quick which in my opinion would be a *lot* more useful to add in the short/medium term than a C++ API that duplicates the declarative object description which QML is already very good at.
And I also believe that adding too much public C++ API too *soon* in the Qt Quick project’s lifetime, *will* actually be harmful (by preventing in from internally involving without being constrained by BC promises).

So since all of us Qt users seem to have very different opinions regarding what we would like to see prioritized for Qt Quick in the short/medium-term (Qt 5.1 and 5.2), I put up a corresponding poll here:

http://qt-project.org/forums/viewthread/16693/

You can select between:
– Desktop Components
– Generic Theming Support
– Binary QML
– Expanded C++ Component API
– Full C++ API
– Optional V8 Dependency
– Graphics View Component
– some other improvement/add-on
– nothing – I’m happy with what Qt Quick 2.0 provides
– nothing – I don’t like Qt Quick altogether, I’d like to see more resources put into improving other parts of Qt

Cheers

Antti says:

Thanks Donald for taking time to respond!

As a Qt developer I’m very excited of QML; I definitely will not use my time in widget based UIs any more, and don’t personally know any developer that would (when starting a new project, that is). QML is currently likely the best UI development paradigm, and even improves overall code quality in creating a clear separation of data and representation.

I wouldn’t mind a C++ API, but I think it has been made quite clear that’s currently a bad idea: no technical proposals how to implement complex property bindings; public API would likely now be premature and prohibit architectural improvements; no real value but the cost of a duplicated API. As things currently stand, I think a C++ API would be a mistake — after all, as said, the widgets aren’t going anywhere. And KDE is already embracing QML, so I think it’s pretty much given that Qt is moving to the right direction.

It seems that the best way forward is the creation of desktop components and Mr. Alpert’s proposal (posted on the dev mailing list) of incrementally making the QML API extensible.

Thanks for all your hard work, eagerly waiting for the final release!

c++freeloader says:

@Domino

Thanks for the explanation. I appreciate when someone brings “real” arguments to the table – kudos to you.

I saw your brief “width” example, but can you post a more substantial example of QML that you believe to illustrate the advantages of QML. This is what I’m really looking for and no one seems to be willing/able to give. If I can see concrete explanations of where the “real” advantages are, then I wouldn’t be so strenuous in my criticism. BTW, if you go to the “Forums->Lounge” thread “Does Qt need a C++ api” and post there, you can use code formatting codes to make the code more readable.

BTW, the example I gave was after 2 minutes of essentially just mirroring the QML example with obvious counterparts in C++. That doesn’t mean there is not a better way to structure things or a better thought out C++ API that can be developed if a few knowledgable people spend 2-3 days thinking about it. User Dian (or in the other thread “temp”) has some very good ideas of what can/should be done.

Regarding the rest of your post, let’s just say that there have been tons of reasons given as to why being able to use a C++ API for “the new Qt” is a strongly desired capability. Don’t brush off all these other concerns with hand-waving about having to be ready for the future and there’s no time to waste. We all know how much time it took Qt developers to get QtQuick off the ground and supply all the infrastructure that comes for free with C++, so that argument is essentially null and void.

Dave says:

@c++freeloader

It’s kind of interesting that you “appreciate it when people bring real arguments to the table” while at the same time failing to acknowledge or respond to actual arguments when they’re inconvenient for you.

Donald brought up some great points and you hand waved them away as having already been covered in the comment thread and added a bit of criticism for not having read the comments properly.

I’ve read the comments properly. Most of those points have been completely ignored or inadequately responded to throughout the entire thread. One of the points was answered by you refusing to believe a Nokia employee about the state of affairs inside Nokia. Awesome rational argument there. It’s like watching a teenager, arguing from emotion rather than reason, and trying to use the right wording to make the whole think look like a rational debate.

I’m sure I’ll be told that I’m actually doing what I’m accusing you of, since that’s what’s typically happened throughout this debacle.

The lack of rational, professional discussion around this point is kind of laughable – I assume that if the people involved in the debate were capable of proposing a Qt-style C++ API for the QML functionality that the comment thread would look significantly different.

Chriss says:

@Dave wrote for supporting Donald arguments
“The lack of rational, professional discussion around this point is kind of laughable”

@Donald wrote (previously):
“Are you going to contradict us? I didn’t get my cheque from you for last month. Ah, thats right, Nokia cuts my cheque and hence I can’t actually focus on polishing your shoes/preparing an omelette for you.”

Thanks @Dave for point that:
“The lack of rational, professional discussion around this point is kind of laughable”

c++freeloader says:

@Dave

Donald brought up points that have been brought up many times over this thread and others – 200+ comments deep in this thread and I don’t know how many in the other Forum->Lounge thread. Why should I rehash the response to every one of them. He obviously either didn’t read the comments or was willfully blind. I can’t keep responding to the same arguments over and over again. It gets tiring and I don’t have the time. Every time that I said a point was covered in other posts, it was. You obviously don’t read very well either. Talk about emotion versus reason – emotion is all that is seen from you fanboys. You fanboys can’t even present a single example of why QML is “more fluid” or “more easily created”, etc. Just hand-wave it away as if it’s written in the bible or something. Finally Domino actually brought a technical argument with examples to justify his thinking. He should be congratulated.

The ironic thing is that in post 120, you accused Dian of repeating himself:

“@Dian
You repeated yourself again – including a lot of stuff that wasn’t necessary in a reply to my post”

And yet, you have the nerve to ask people to repeat themselves over and over again.

The other ironic thing is that somehow you claim to be impartial, but always seem to come back to: the c++ fanatics just don’t know how to communicate professionally. Your bias is showing through here in an obvious way. I waited for a long time (150 posts) before I jumped into the fray, watching people like Dian, Erik, and a host of others get beat on over and over for bringing up these criticisms. The communication styles on both sides were bad, I’ll have to admit, but overall, the QML fanboys tended to be the dismissive ones who refused to listen or acknowledge valid points. It got so bad that at some point, I felt bad for these guys and felt I should jump in and add another voice to counter the massive amount of irrational or just plain false rhetoric that was be spewed out by the anti-C++ guys. I started out trying to be the level-headed, and open-minded, saying in post 157:

“To keep things grounded in reality, perhaps you could provide examples of QML functionality that would not be doable in C++ or would require ‘complicated structures, templates, macros, code-generation, or string-based interfaces’.
I have yet to see such a thing in any of the QML code that I’ve been exposed to, but am open to the possibility of it existing.”

and then again in post 159, I said,

“@Lars. Perhaps I am just in need of convincing.
Perhaps you can post here a snippet of QML code which would illustrate by example your belief that ‘doing all the UI description (including states, animations…) will be possible (maybe) but never be that easy in C++. ‘”

Of course, no QML fanboy would take me up on the suggestion to provide an example showing the benefits.

So then, in post 163, I posted example code pointing out that a hypothetical C++ API need not necessarily be more verbose or less readable than it’s QML counterpart. Funny thing happened, as expected, no QML fanboy would actually address the example nor provide any concrete arguments why the example code was bad or could not be used or anything.

I could go on. I challenge you to point out where my posts were out of line or unprofessional except for a response to Donald. And Donald’s post, by all accounts deserved the response that it got. I sat by the first 150 comments on this thread, plus dozens of comments on the Forum Lounge seeing the same false points by QML fanboys and I saw a small but diligent group of people keep having to repeat themselves and repeat the arguments because different QML fanboys come in and repeat the same false points over and over again while refusing to do anything but hand-wave that QML is Qt’s gift to the world and we should just shut up and appreciate everything that we’ve been given.

c++freeloader says:

@Chriss — Thanks for brightening my day with your sense of humor.

Stephan says:

Guys, Are you telling me that people like Donald are the developers behind the QML stuff? … If that is the culture of some Qt devs, then certainly I can tell you: we are doomed … there is no chance technical arguments can guide to Qt (at least not the UI module)

Ireen says:

@c++freeloader (alias Dian alias temp)

I think a lot of your arguments are plain wrong or you are not able to state them properly. And this is the reason that all you posts won’t change anything. One thing I learned in my job is: there are people that talk a lot and make a lot of noise and there are people that bring things forward – and you belong to the first group. I know, you are not the only one that raised concerns in this thread, but if I count all your posts and the posts of you aliases Dian and temp, then you spended hours in complaining where other people spended hours in improving Qt and bringing Qt project forward.

And insulting the people that develop Qt will help a lot to convince them that your concerns are not serious. A lot of people raised their concerns about a plain QML API here in their posts – but all their words are sunken in the countless lines of noise you are producing again and again and again – thank you.

So you can continue to complain – I’m going to develop some Qt software.

Dian says:

@Ireen – I’ve officially stepped out of this pointless nonsense, just to let you know I am not c++freeloader, and if you don’t trust me, website administrators can confirm that by comparing IP addresses. I suppose you think it is just one guy that is not happy with the direction of Qt, and it is just me, playing some game, posting through a number of other aliases, changing proxies and all that stuff just to create some illusion of unrest – well, sorry to burst your bubble, but that is not the case. As my poll in the Lounge indicated, there are quite a lot of people that are not thrilled by all the QML pushing through exclusively paying attention to it, sadly it doesn’t seem that user base requests matter to the decision makers in Qt, that is why I already walked away and started looking into alternatives.

Samuel says:

@c++freeloader

Of course, no QML fanboy would take me up on the suggestion to provide an example showing the benefits.

Is using the term “fanboy” over and over your idea of having a rational discussion?

In any case, I did take you up on that suggestion in the qt-project forums, but it seems you conveniently ignored that for the cause of scoring points in here. You should also realize that there are benefits to using a DSL instead of a pure C++ API, as it gives us much more flexibility to do optimizations, say by in the future loading different sub-trees in different threads, or by moving parts or the whole binding evaluation code to a separate thread, such that hiccups in the main thread don’t lead to lost frames. Good luck doing that in a C++ API without introducing a whole slew of expensive mutexes, and breaking existing code. Also, it requires thinking long and hard about memory management and ownership, as any item can now be deleted by the user at whim. These issues might also raise extra costs in checking and verifying that the state is correct, something that could be avoided with a DSL. As for the syntax, that’s clearly a subjective topic, but I and others feel that the QML API makes for clean and expressive code, with all the non-important implementation details left out.

Some of the QML detractors here have also been spreading misinformation by claiming that the Quick item and scene graph APIs are not accessible from C++, which is clearly not true. Both QQuickView, QQuickItem, QSGNode and other enablers are public API, and can be used to create custom items. Those who can’t accept that QML is the current solution for accessing the standard items will either have to create their own C++ wrapper around the QML items they need (which is fully possible), or simply not use the QML items.

@jdavet

Thanks for being productive when discussing, and for creating a more nuanced and unbiased poll.

Konstantin Tokarev says:

Samuel: being forced to use DSL instead of general-purpose programming language to use advanced platform’s functionality is not a benefit, it’s a broken design.

Konstantin Tokarev says:

>You should also realize that there are benefits to using a DSL instead of a pure C++ API, as it gives us much more flexibility to do optimizations, say by in the future loading different sub-trees in different threads, or by moving parts or the whole binding evaluation code to a separate thread, such that hiccups in the main thread don’t lead to lost frames. Good luck doing that in a C++ API without introducing a whole slew of expensive mutexes, and breaking existing code.

That’s what Qt platform should provide for us developers (since Qt itself is written in C++, it’s certainly possible).

>These issues might also raise extra costs in checking and verifying that the state is correct, something that could be avoided with a DSL.

This issues can also be avoided without DSL but with proper API. As for DSLs, I can justify their usage for interfacing with users of software (non-programmers) or in very resource-limited environments where even Lua does not fit. In other cases extensive usage of DSL will eventually make you stumble on its limitations (like with qmake), but it would be too difficult to replace it.

c++freeloader says:

@Samuel

First off, I did not conveniently ignore your post on the Lounge thread. I didn’t even see it til late yesterday and I haven’t had a chance to think through the “right” way to do any API. Also, it’s not like I don’t have a regular job and family matters to attend to – I can’t watch this thread every hour of every day and then spend all night hashing through possible solutions to the binding problem.

Everything but the binding problem is trivial of course. The binding requires a bit more thought as to what approach to take. I don’t want to put something out there that is less than half-baked. Dian/temp provided some different suggestions, but unfortunately didn’t have the time or inclination to expand on his thoughts.

Secondly, the word “fanboy” is an apt description for several people on this thread and the Lounge thread. Certainly, it applied to several people that were responding in the first 150 comments to Dian and others. I don’t think it applies to you as I thought you are one of the more rational people here. I would more call you a happy QML user and developer.

Regarding the specific points you bring up…

If I understand correctly about intended usage of QML, property bindings are not supposed to be compute heavy and thus would not benefit from multi-threading. The thread-crossing penalty and cache-line swapping implied by fine-grained sharing of simple property bindings would not justify it. If it turns out that things entailed in property bindings are heavier, it’s certainly true that they should not be executing in JS. Moreover, if something is done in C++, then the developer has the flexibility needed to move stuff to a different thread if need should arise. As I understand it, the truly compute-heavy portions of the GUI are automatically managed by the underlying scenegraph. Isn’t that the whole point or moving to a declarative method?

The memory management issue has long been a solved problem. QML solves it one way, QWidgets solves it in another way. Other C++ programs use various techniques: unique_ptr, shared_ptr, pool allocation, garbage collection, class-specific new and delete, etc. I hardly think this qualifies as a reason to reject having a C++ API.

As for the subjective “cleaner code”, you are right, it is a personal preference. Yet, aside from the binding problem, we’ve already seen the a C++ description is reasonably close to as clean as QML. In some, more complex cases, possibly it could be even cleaner than QML, in other cases, not. Again, it’s not like one language is a factor of 2X or 5X or 10X better than the other on this front. For the binding problem, I’ve got some ideas about how to make it as clean or nearly as clean as QML. I haven’t yet had a chance to flesh them out, so that is why I haven’t posted them. Just because clean techniques to provide “binding-like” functionality haven’t been published, doesn’t imply they are not possible nor does it imply that they will necessarily be more verbose or less readable than the QML functionality that they replace. Moreover, any “less clean” aspect (if there are any) should be balanced against the glue code that is required to interface the business logic into QML which of course wouldn’t be required at all in a C++ only app. Not to mentioned, balanced against the other advantages of a fully native API.

With regards to the QuickItem and QGSItem. Thanks to the devs for making these public. I am currently unaware of any examples of their use. If you know of some, can you provide a pointer to these examples? Also, I just went back to the 5.0 docs on qt-project and it seems all QtQuick examples and documentation are not available. At least the hyperlinks which should be associated with “QML Examples and Demos”, “Qt Quick – develop fluid UIs with QML”, and “QML Elements” do not seem to exist.

As a final point, as soon as I saw jdavet’s poll, I immediately thanked him for putting together this poll. I do think that it is a reasonably good poll.

Erik Schwartz says:

What I might add here what bothers me even more is the simple fact that there is absolutely no migration path from QML back to C++.

QML components like TextInput, Flickable or WebView have no public C++ API and are only extendable from QML.
Once I did this and a significant part of my application is done in qml there is NO way back to C++.

There is no uic for QML and things like states, transitions, anchors and all the build in elements are purely accessible from QML.

It is not even possible implementing your own C++ components and using anchors, states and build in components like flipable.

If I want this I have to use QML and from my perspective even worse: Java Script. I have to use Java Script.

If I now realize that I have performance or IP issues with QML (or scalabilty/complexity issues), then it is game over.

This is basically a ridiculous risk for any bigger investment.

Also Java Script is introduced as a “must have” (to extend existing QML components) and Java Script is neither a DSL nor declarative.

Pure Java Script free QML is a DSL, but pure QML is not complete, since even extending a TextEdit is impossible this way.

The only reson for Java Script I see, is that it could be done and might attract web developers. From a seasoned C++ developers view Java Script is a nightmare.

Also having Java Script inside QML breaks code speperations. Suddenly logic is all over the ui description.
This nullifies all the sweat talk about seperating frontend and backend, ui declaration and code and MVC.

Samuel says:

@c++freeloader

As I understand it, the truly compute-heavy portions of the GUI are automatically managed by the underlying scenegraph. Isn’t that the whole point or moving to a declarative method?

Yep, I didn’t mean that the bindings would be heavy, but it could still pay off to move them to another thread so that if the programmer does something compute intensive on the main thread, it won’t block the rendering on the scene graph thread (the scene graph needs to be synchronized with the QtQuick tree whenever properties of the latter changes). Not sure how feasible it is with the current design, but at least QML puts less restrictions on how we might later change the implementation.

The memory management issue has long been a solved problem. QML solves it one way, QWidgets solves it in another way. Other C++ programs use various techniques: unique_ptr, shared_ptr, pool allocation, garbage collection, class-specific new and delete, etc. I hardly think this qualifies as a reason to reject having a C++ API.

Sure, but there are always complexities relating to memory management that tend to creep in, such as order of destruction etc. We’ve made it quite easy in Qt to not have to worry about these details, but QML completely hide the issues.

Moreover, any “less clean” aspect (if there are any) should be balanced against the glue code that is required to interface the business logic into QML which of course wouldn’t be required at all in a C++ only app.

The only glue code involves adding setters / getters / change signals, as well as Q_PROPERTY declarations on the QObjects you wish to expose to QML. Apart from the Q_PROPERTY declarations you typically have these even in a C++ application. The distinction between backend code implementing the logic and frontend code implementing the UI is useful to have in any case.

With regards to the QuickItem and QGSItem. Thanks to the devs for making these public. I am currently unaware of any examples of their use. If you know of some, can you provide a pointer to these examples?

I have for example used them in qtwayland to implement a WaylandSurfaceItem class which exposes a surface from another process to QML, making it easy to animate it etc in the compositor and making implementing a window manager almost trivial: https://qt.gitorious.org/qt/qtwayland/blobs/master/src/compositor/compositor_api/waylandsurfaceitem.h

Unfortunately, as you point out, the documentation is still a bit lacking.

@Erik

There is no uic for QML and things like states, transitions, anchors and all the build in elements are purely accessible from QML.

You should be able to access the item from C++ by querying for the id or similar, or by making your own C++ Item wrapper which contains the actual item you’re dealing with. Once you have access to the QQuickItem you’re interested in, you have the following API:
https://qt.gitorious.org/qt/qtdeclarative/blobs/master/src/quick/items/qquickitem.h

From there you have access to the item’s properties like the state: Q_PROPERTY(QString state READ state WRITE setState NOTIFY stateChanged)

If I want this I have to use QML and from my perspective even worse: Java Script. I have to use Java Script.

You can use a very limited amount of JavaScript for simple bindings, you’re not forced to write a lot of code in it.

If I now realize that I have performance or IP issues with QML (or scalabilty/complexity issues), then it is game over.

Not really, you can make your own custom items if needed. The performance issues would still have been possible if say the TextInput element had been exposed via C++ instead of QML, since you still would not have access to the internal implementation.

Pure Java Script free QML is a DSL, but pure QML is not complete, since even extending a TextEdit is impossible this way.

Here’s a TextField being extended with pure QML and some very simple bindings: https://qt.gitorious.org/qt-labs/meespot/blobs/master/qml/AdvancedTextField.qml

I would be interested in seeing an example where those bindings would become the bottleneck preventing a 60 fps+ UI.

Also having Java Script inside QML breaks code speperations. Suddenly logic is all over the ui description.

Yep, this goes against keeping logic and UI separate, and is not a good design approach even with QML. Some users might be happy with only QML and JavaScript for simple games or apps, but you are free (and encouraged) to implement any complex logic in C++.

Erik Schwartz says:

@Samuel: Thank you for answering my post. I really appreciate this.

“You should be able to access the item from C++ by querying for the id or similar, or by making your own C++ Item wrapper which contains the actual item you’re dealing with. Once you have access to the QQuickItem you’re interested in, you have the following API:”
[]
“From there you have access to the item’s properties like the state: Q_PROPERTY(QString state READ state WRITE setState NOTIFY stateChanged)”

I fully understand that there are possibilities, but this is just not sufficient for my use cases. Imagine I want to derive from Flickable (like e.g. ListView does). This is simple not possible in C++. Also, afaik I do not have access to the factory creating a Flickable, since it is private. The same is true for anchoring or anything state related, apart from setting the current state. Imagine I want to create a State?

Why do I want this? Because I have QML code that I want to port to C++. In QML I do derive from Flickable, use anchors and define states. I want to do the same in C++. Propably not because it is faster (startup might be faster), but to protect my IP and way more importantly to avoid bridging heavy backend code. Lets imagine I have a very, very special ListView with some weird quirks that do not allow me to use a ListView and implement the ListModel. This is a valid, not so untypical, usecase.

“Not really, you can make your own custom items if needed. The performance issues would still have been possible if say the TextInput element had been exposed via C++ instead of QML, since you still would not have access to the internal implementation.”

But this is exactly what I want and have to and what I can do with QTextEdit and more often QLineEdit. I derive from QLineEdit quite often in classical Qt code and the use cases stay relevant for Qt Quick. But since TextInput and friends are private I cannot do this in C++ and have to revert to QML. And even in QML I miss important functionality, because Qt Quick is not mature enough.
In the end I am forced to “forke” TextInput in my own source code.

Of course simple changes can be done in pure QML and it will not hurt, but custom TextEdits are not so uncommen and they have the tendency to become really complex.

And what you really have to understand: If the data the application has to visualize gets complex, bridging this data is not a trivial task. If it is more then a simple List exposing the data to QML becomes a real burden.
And all the bridging/proxy code gets complex and having to deal with two languages + 2 runtimes (QML + JavaScript) does not really help.
I understand that the typical Mobile App, you propably target, does not have this issue. But traditional Qt user do have. All I ask is please do not leave your traditional users behind. Qt has a long and sucessful history. Lets not forget this.

Thank you for listening.

Samuel says:

@Erik

Regarding the IP issue, I hope we’ll get a binary / compiled QML in some future 5.x release. I wonder if it’s possible to encrypt parts of QML and load it dynamically at run-time, but I’m not going to speculate too much.

As for the Flickable, do you really need to sub-class Flickable, or would it be enough to be able to populate it from C++? In the latter case, you could for example instantiate the Flickable from C++ like so:

QQmlComponent component(&engine);
component.setData(“import QtQuick 2.0; Flickable{}”);
QQuickItem* item = qobject_cast(component.createObject());

Then you can make that item child of a wrapper item of your own, and all the properties of Flickable are accessible through QObject::property() and QObject::setProperty(), plus any items you want in the Flickable you simply dynamically instantiate from C++ and make them children of the Flickable item.

Another way of customizing Flickable would be to create a QML item that wraps it, and simply sets properties etc based on a backend C++ object’s exposed properties, but I’m not going to go through how to do that here. You can have a look at http://doc.qt.nokia.com/qt5-snapshot/qtbinding.html for more information. Although it explains how to use the QDeclarative* classes (which is QtQuick 1.x), it works pretty much the same with QQuick* and QQml* classes in Qt 5.

Maybe it does make sense for the QQuickFlickable API to be made public from C++ as well in a future 5.x release. In any case, you also always have the option to use private API for now. If you’re comfortable with that you just do “QT += quick-private” in your .pro file and you can then do “#include <QtQuick/private/qquickflickable_p.h". Then you can inherit directly from the C++ class, with the risk of having to modify your code a bit in future 5.x releases. You can see the private header here: https://qt.gitorious.org/qt/qtdeclarative/blobs/master/src/quick/items/qquickflickable_p.h

If you can get away without inheriting, that sounds like the safest option, and in case the QQuickFlickable API does become public, you can just change your component.createObject() code to simply do new QQuickFlickable.

Ian Monroe says:

@Samuel regarding Flickable, I think Flickable itself isn’t so interesting in terms of having a C++ API. But the physics that flickable uses would be interesting for sure.

Erik ‘imagines’ wanting to derive from Flickable, but the interesting part is how it has a concept of velocity of so forth.

Alan Alpert says:

@Ian

That’s exactly it. I agree the concepts of velocity inside flickable would be valuable to customize – we just don’t have a good API for it yet (and making it inheritable would do zilch). If anyone wants to help us come up with the right API for it, that would be great. There isn’t even such an API in QML, so this isn’t a QML/C++ language issue. This is simply about not knowing what the API should be (and so, not implementing something rashly now and maintaining it forever).

Rogger says:

Hi, well I understand a couple of things:

We have two developers who are in love with their QML, that’s ok with me. But please, be aware there are many users of your technology. First, @Donald who is developing only with focus on economic and political aspects (nokia pays him) without caring the else.

Then, @Samuel seems not to have the foot on the earth, please @Samuel keep in mind the idea here is Qt on the companies/business with real users making real (and complex) software: is good to experiment with wayland to show the scope of the technology, but is not the main concern … I don’t know if you get the point of the whole discussión.

Finally, @Samuel:

“QML is not the enemy of C++, they co-exist happily, with QML being used for the front-end UI (like the old .ui files), and C++ being used for the backend, exposing properties that can then easily be used and bound from QML.”

* Are you aware is not what -most of- your clientes (Qt developers) want?
* If so: Are you prepared for the consequences?
* If QML is not the enemy of C++ then: why one can use QtQuick *only* through QML? … why the choosen design looks like: “the enemy is C++”?

Samuel says:

@Rogger

Real users _are_ making real and complex software with both QML and Wayland, please see http://qt-project.org/videos/watch/qt-and-qt-quick-on-the-freebox-player-set-top-box for an example of a successful product.

And for another product also using QML, see http://www.youtube.com/watch?v=SfyptGmX93U for an example of an inflight entertainment system used by 100 airlines and 5 million passengers per day.

Note that these projects were done with Qt 4.x, where QML used QGraphicsView behind the scenes, and still they chose to use QML.

Ter says:

@Rogger “Are you aware is not what -most of- your clientes (Qt developers) want?”
How can you say that? How do you know that? I really don’t have the same conclusion from my point of view but I will not say to everybody “I have the truth”, that’s a bit arrogant isn’t it?
@all the QML detractors
A fact is that there are more and more people which use Qt, obviously for more and more use cases. You can say whatever you want but QML is really easy to use and easy to maintain (but it’s not C++;) ), it’s easier and faster to create nice UI(s) than before. There’s a lot of competition in industry, if a client has the choice between a software with a nice UI and another one with static things for the same functionalities you will loose the market. To create nice UIs, you have to try, to tweak in live and I really don’t know how you can do that easily in C++. It’s not just a toy. The backend of your code is still C++ and if you haven’t understood this FACT, you haven’t tried to do something with QML seriously. I’m not a fanboy, I’m someone who’s creating better apps using QML and C++, it’s a conclusion, not a fanboyism. QML made me win business for industrial softwares (no toy game), that’s concrete.
I really don’t understand why you are so nasty and disrespectful with the Qt people. If you don’t want to use QML, well… don’t use it but don’t think for others. Oh, another point: I don’t work for Nokia

Donald says:

@Rogger

Nokia has a roadmap, the Nokia sponsored Trolls have a roadmap which is heavily aligned with that roadmap. The closer you are aligned to that roadmap, the more functionality you happen to get for free. Free. fRee. Freeeee. free?

Our (paid) development time is dictated strategically by technical concerns, a road map, laid out by technical people with a set agenda. The fact that people can feign offense at the fact that we work to a schedule, rather than in response to the most vocal people responding to our blog posts is a surprise to me. This can’t seriously be a surprise? If you were my manager, and assigned me task A, you would be happy with me working on task B instead because thousands (read 10?) people in the comments section cant digest the fact that we aren’t in a position right now to focus on a C++ API for our OpenGL scene graph? We have other functional gaps which are important, other people have a vote. An API might come later when we have the time, or it could come sooner if you personally, Rogger, actually expedite it.

Dian says:

@Donald – this is actually a part of the problem – the nice free stuff trolls are working on aligned to Nokia’s roadmap and we get only if we align to Nokia’s roadmap in turn. “Free” stuff is not intrinsically “good” and in far too many cases “free stuff” is just the bait to lure people in, which does seem to be that “agenda” you mention. You are so busy with QML that you don’t have the time to bring the same type of out-of-the-box functionality to a native API, god forbid QML loses any of its artificial advantages. I myself don’t recall blaming you, since you do as you are told, but just because it is the thing you are told to do and supposed to consider the right thing to do doesn’t mean it is the same for everyone, as Nokia is not paying us to have specific opinions, and that trail of candy, leading to QML is obviously not enough to convince us all.

In short, we don’t have anything against getting nice free stuff, but plenty of people (yeah, it is really like 10, you can put money on it…) seem to have a thing against being tricked with nice free stuff to swallow Nokia’s load, coated in the benefits of your efforts. If Nokia didn’t wanted to make the product of your labor bait to adopt QML, then that roadmap you follow with such dedication would be a little more adequate, focusing on polishing native APIs, make them more flexible and extendable, and then do the QML stuff on top of it. And I get it, at this point, all you can do is pretend it is an issue of resource, that you don’t have the time just now, but in some distant future, there is some hope (acting like politicians now, selling hope?) of native UI API based on the scenegraph, even thou it is not on your precious roadmap. Sorry, but your actions and your words don’t draw a compelling picture, I am highly skeptical that Qt will ever deter from that direction and become dedicated to C++ again, and even thou you pretend it is not a big deal, it is quite a significant thing to walk away from being C++ centered and focus on being C++ extendible and centered on another “language” which gets all the neat functionality exclusively. Is it that strange that C++ supporters are not happy when their language of choice is used to make stuff that isolates that language and turns a C++ framework into something else? What were you thinking? Oh wait, you weren’t, you were just following orders… And how could you even dream of criticizing the direction you are told to follow, let’s never doubt whatever big greedy corporations tell is is the best thing for everyone and ignore all they naysayers – they are stupid, they do not understand… That amazing progress Nokia provides is too far ahead of us for us to get it, otherwise we’d unanimously agree it is the “the future” even if it is actually arriving late at the show…

Domino says:

@Dian:
Please also consider that the roadmap is often the key to success. Qt needs adoption and there is not much time. During the last years, most innovations in UIs were born on mobile devices and that’s for Qt a really great opportunity that a big player in the mobile business believes and invests in Qt.

The decision regarding the C++ API seems to be based on the lack of resources and on time constraints. Now, the chance for Qt is to be a major player for the modern interfaces. Future desktop GUIs will follow that trend. If Qt misses the train, it will be almost impossible to fill the gap with concurrent technologies.

For many different reasons, QML seems to be a good choice to make sure that Qt can be a real competitors. On time. C++ purity or other nice-to-have features are important but as long as the benefits are neither urgent nor obvious, please accept at least Qt and Nokia’s choice. The business decisions behind it are not as much in conflict with the overall quality. Qt must be successful and that’s a common goal.

Marius Storm-Olsen says:

..and with that we close this thread to focus on the code..

Nokia will not be locking in a C++ API for this right now. However, if you feel strongly for it, feel free to work on a code suggestion, submit it for peer-review and discussion at https://codereview.qt-project.org/. This is the whole point of Open Governance and the Qt Project, to let people scratch their own itch.

Thank you for your interest and all your comments.

Commenting closed.