Qt’s commitment to C++?

[Guest]

bq. A lot of your earlier ranting was “a tad offensive” for the people working hard on making Qt better ever day

Please don't put words in my mouth, I explicitly stated I don't blame the developers behind Qt, who simply do what they are told to and paid for. I am as far from blaming workers for the actions of managers as it gets.

[lgeyer]

... sigh ...

Please don't get me wrong. I don't deny your right to dislike the efforts put into Qt Quick on the part of Nokia. But I don't agree with the arguments you've based your decision on - and you are loudly voicing here - mostly because they do not stand close examination and they are not supported by facts.

There is still active development of Qt Essentials, there are no exclusive features to Qt Quick, which is not a proprietary technology, held back for the rest of Qt, QML is a mostly technical requirement for fluid user-interfaces and it is way more efficient (both in development time and runtime) and it was neither created nor is expected to replace the current C++ API, Qt Widgets or The Graphics View framework. C++ is not a guarantee for efficient code, neither is not C++ a guarantee for inefficient code.

I have full understanding that "a human beeing that does programming" does not necessarily has the knowledge to understand the technical reasoning behind the decisions for Qt Quick (I don't consider myself a know-all as well), but I find it a bit presumptuous to take facts as granted born out of a serious lack of knowledge and learning aptitude just to allege dishonest motives on the part of Nokia and the Qt Team and to spread untruth. That's what I accuse when saying that people are unwillingly to inform themselves and learning something new.

It is your unrestricted right to voice your concerns about future technology in Qt, but you should not base it on subjective impressions nor should you expect technology to stop, just because you won't or can't keep up with it.

If you want to continue the discussion on an objective basis I'm right here. But this discussion has come to a point where further participation on my end is rather pointless to me.

[andre]

The people working hard are not programming drones. They are intelligent people that have a vision on where Qt should be heading. There are also many people working hard on this vision, this direction without doing a lot of programming at all. It is a community, that discusses these things out in the open. And yes, many of us here feel part of that community.

[goetz]

What one wants to express and what the audience actually does understand can be very different once in a while. Communication science states that it is always the sender to blame if the receiver misreads...

There is no "one size fits all" in IT. The brilliant minds in that domain know many, many tools - their brilliance comes of the fact that they know to choose the right tool for a certain task. Be it C++, be it QML, be it a bash script, or be it some write-once-read-never-again Perl script.

I'm so fond of that pure-blah-blah thingie evangelists. It started with vim vs. emacs, evolved to Linux or Windows or Mac and goes as far as Coke or Pepsi and Volkswagen or Mercedes in real life. Choose the right tools! But you only have a choice if you know them!

PS: I am very concerned about QWidgets and the C++ part of Qt living on. All my income work is based on that. And no, I'm not scared that the base of my job and little company is breaking away anyway soon.

[Guest]

@Lukas Geyer - OK, let's get objective, how is QML an objective requirement for a fluid user interface, and not subjectively MADE a requirement? I've seen plenty of fluid interfaces that do not use QML, in fact most of them don't. And looking at MS's Metro, it does seem to be possible to achieve modern fluid GUI with native C++. Catch my drift? So can you objectively point me to that easy to use Qt API through which I can write modern GUI applications natively, using my trusty C++?

Are you entirely sure the decisions behind QML are 100% technical and not for example... let's say corporate politics? I may not be a QML sword-wielding programming guru, but I happen to be familiar with technical details when it comes to computing, from the metal through compiler design all the way to code execution. Not an expert by any means, but I am not in the dark, I know how this stuff works. That is the reason I am sceptical towards all those claims QML is a "requirement" - nope, there was a decision to be make it a requirement, not an optional one unless you want to stick limit yourself to half a decade old GUI API.

I never said technology should stop, technology must and will inevitably march forward, but as it does it is supposed to get more, not less efficient. There is always the sweet spot, the peak after which it is not worth going, in terms of approaches to tap in the benefits of technology. And it just happens so that no language since C was able to exceed its performance, C++ added a little overhead at the benefit of making it much easier to program. 5% lower performance for 200% easier development - IT IS WORTH IT, Python - 10000% lower performance for 200% easier development - IS IT WORTH IT?

Let me give you an example, earlier humans communicated with grows and grunts for millennia, and then there was speech, which appears to be the peak, it doesn't get any better, sure we can force ourselves to come up with a new way of communicating for the sake of being NEW, something like... I don't know, burping in Morse code, but it won't be better just because it is new. Or what about feeding habbits, first we ate with our hands, then we learned to use feeding utensils, but stopping here does not mean we stop progress, there is no need to start eating with our feet just for the sake of coming up with a new way to eat. Sure, those are extreme hyperboles I just use as a figurative example, the same principle applies everywhere, there is always a bell shaped curve, you improve something to the point it doesn't get any better, and all further forcing actually makes it worse, you advance on the X but go back on the Y...

@Andre - I am not a mindless drone either, but I constantly have to force myself into doing very stupid things my millionaire bosses demand of me, so I know how it is. Do you mean to say QML is not a management decision but an idea of the trolls, who did a C++ framework for decades and suddenly decided "You know what, let's conform our C++ library to another programming language, that would be fun!". You mean to tell me the aquisition of Trolltech by Nokia has nothing to do with QML suddenly popping out and it is just an accidental coincidence work on QML began after Qt got bought? If you confirm that's what you say then I take all my critique back and admit of being wrong - I have no problem with admitting a mistake.

[Guest]

...continued...

@Volker - I don't really think Mac VS PC, Coke vs Pepsi, WV vs Mercedes is the same category. Those are about fandom, brand loyalty, about cults created through advertising, driving people into blind, subjective frenzy that has nothing to do with logic or reason. No one advertised C++ to me, quite the opposite, the majority of stuff I knew about C++ before I bothered learning it was negative, must have been those fanboys again...

It may be true that one size does not fit all, but there is always the tool that fits the most, and the way I see it in programming that tool is C++, hence my decision to focus on it.
http://www.youtube.com/watch?v=VzpRh-ZE9Mo

However, quite often the reason a tool does not fit is not because of technical requirements but because of deliberate decisions to make it not fit - let me give you another real life example. I happen to have a full set of 12 different screwdrivers, and they all do the same kind of work, screwing and unscrewing. The reason I need that many screwdrivers has nothing to do with them serving a different purpose, but with "clever" manufacturers creating their PROPRIETARY screws:
!http://www.daviddarling.info/images/screw_heads.gif(screw heads)!
And it is not like my toaster will work in any different way if I change the fancy Allen screws with regular slotted screws - the reason manufacturers do it is to make it harder for me to fix my own toaster so I have to pay for service that will cost way more than I would cost me to fix it. I've had my share of bitter experience on that subject, stories like corporate servicing asked me to pay 50$ for the replacement of a 5 cent capacitor, whose legs kept on breaking because the PCB was subjected to continuous vibrations due to bad design decisions. And sure, often it is quite good to prevent people from tinkering with machinery, but I think it is the responsibility of the customer to keep away from it if he doesn't know what he is doing, but if you do know - I have actually improved on many of the devices I own, simple improvements manufacturers decided to hold back on for... my bet is more profit.

I don't NEED to have 12 different types of screwdrivers, I AM FORCED TO, there is an ocean of a difference between the two

The screw example is very fitting for this type of situation, as the screw head itself does not define the purpose of the screw, it is just the interface to use a screw. And instead of making different type of screws with the same interface, or head, to ease their users, the industry actually does the same type of screws with different interfaces to use them, so you end up needing a lot more tools to do the same thing even thou you could use a single tool to do different things if the interface is common.

The situation with QML, as well as some other declarative languages seems to be very similar to this, different players in the industry want to enforce their own standards, not because they are better, but because they are their, which benefits them while fragmenting and dividing the developer base. QML is not objectively needed, a decision was made to make it needed, much like with my screwdrivers, for me it would be better to have one that would fit it all if manufacturers did not make it so that I need more.

All in all, apart from you guys trying to convince me I don't understand, am lazy, subjective and all that stuff, you never really said what exactly prevented that modern API to be created available for native use, and then simply added QML as well as other language bindings? You almost make it sound it is technically impossible, which I very well know it isn't, not only on basis common sense, there are actual real life examples that it is doable, and you never really answered my question why Qt decided to not do it?

[goetz]

Nice try on the screw drivers. Which fits perfectly in our scenario.

Did you ever try to use a slotted one with an an electrical screwdriver? The slotted is easiest to use with manual screw drivers, it doesn't work out with (semi)automatic tools, so Philips was invented. That as it's drawbacks too, so "Pozidriv":http://en.wikipedia.org/wiki/Pozidriv#Pozidriv was invented (which is missing in your list). Torx and the others have their own advantages and disadvantages.

And in the same manner programming languages have their own advantages and drawbacks. I am happy that I can choose!

Oh, BTW: one reason for QML/Quick being based on JavaScript is the fact, that it is declarative - which is not doable in a compiled language as C or C++. And instead of inventing a new wheel, the Trolls did a clever thing: they grabbed an existing tool and extended it for their needs. You might want to argue why not lua or embedded perl or python or ruby. But that's bascially vim vs. emacs and doesn't count here.

[Guest]

Great, you are happy that you can choose, so you must understand me not being happy being deprived of the choice to stick to C++ with Qt. It is still a choice to not use multiple languages, just as it is a choice to use many languages, isn't it? It is a fact that C++ facilitates enough features to fully describe any type of logic or application structure. Even if it is not the easiest way, it is good enough on that front, and superior in most. You seem to implicitly keep on denying the application of C++, so maybe you could go forward and explicitly state something like "C++ cannot be used to describe modern GUI interfaces" to further try and convince me of the inevitability of QML?

And even thou you are partially right that there is application behind different screw heads, there are also quite many that are there for solely for the purpose of being proprietary.

[andre]

Ok, I'll bite:

I would like to claim that C++ cannot be used to describe modern GUI interfaces in a compact, understandable way to facilitates easy cooperation between designers and programmers.

Note that choice is not taken away from you. You can still do what you do now in C++. It is just that you're not getting the new choice to do new things - like using scenegraphs - in C++.

[Guest]

I have been a long time UI designer (8 years) and about 3 years of UI implementer. As a designer I can tell you NO ONE describes design IN CODE, design is described and prototyped through graphical representation, which can later be implemented in basically ANY LANGUAGE you can think of, the implementation process may vary depending on the back end API, but virtually every language in existence will do.

So how is this:

@Item {
id: myItem
width: 200; height: 200

 Rectangle {
     id: myRect
     width: 100; height: 100
     color: "red"
 }
 states: [
     State {
         name: "moved"
         PropertyChanges {
             target: myRect
             x: 50
             y: 50
         }
     }
 ]
 MouseArea {
     anchors.fill: parent
     onClicked: myItem.state = 'moved'
 }

}@

immeasurably better than this hypothetical API approach:

@Item myItem(200,200);

Rectangle myRect(100, 100, myItem);
myRect.setColor(Color::red);

State moved(myItem);
moved.addProp(myRect.xPos, 50);
moved.addProp(myRect.yPos, 50);

MouseArea clickArea(myItem);
mouseArea.onClicked.connect(moved.activate)@

Or if you really insist on code visible structure, you can just use indenting:

@Item myItem(200,200);

Rectangle myRect(100, 100, myItem);
myRect.setColor(Color::red);

State moved(myItem);
moved.addProp(myRect.xPos, 50);
moved.addProp(myRect.yPos, 50);

MouseArea clickArea(myItem);
mouseArea.onClicked.connect(moved.activate);@

My hypothetical approach is actually shorter due to the absence of structuring curly braces and constructor passing of parameters, structuring is instead achieved by a parent-child API, it is faster to type and cleaner to the eye, and it requires ONLY rudimentary programming skills and API knowledge to be perfectly clear what you are doing. And sure, there is a slim chance for a total NUBE the QML version may be a little easier, but the C++ version is actually closer to the actual model of the application in the back end API itself. Plus the added benefits of better performance and lower memory footprint. Not to mention keeping it all native, with all the features and flexibility C++ offers, full direct access to the entire native framework with no extra glue code for interfacing between technologies nor any other types of unnecessary overhead.

The optimal solution would be if both ways were available to chose from, and I am truly amazed by your persistence to remain blind to this simple concept. It almost smells like "fanboyism" ;) Like you are idolizing and idealizing QML.

[andre]

I am certainly not idealizing QML. I think QML has many flaws, is not mature enough, and has the risk that we loose many of the corner cases already covered in QWidgets. Having said that, I do think that it is the way forward, and the only way to make it more mature, is to invest development effort into it. You might not agree on that, but that is what's happening.

I am not going to comment on your simple example. I think it will break down pretty soon, as soon as you start adding more dynamic behaviour. And that was the whole point of the excersise.

That nobody describes UI's in code is nonsense. You did not, perhaps, but many people in the field use tools like Flash to create their (dynamic) mockups. How is that not code? One great advantage of QML is that it is so simple, that somebody capable of designing using Flash is also capable of designing using QML & QML designer. But, instead of trying to re-create what the designer did in Flash, you can now simply interface with what he did in QML.

However, I think that your point is clear: you would have prefered an (imperative) C++ based API to develop dynamic UI's. That is not happening at the moment, and this topic is not going to change that. If you think you can introduce a C++ API for the same technogies as are underlying QML: great! Your input will be welcome at the development@qt-project.org mailinglist.

[lgeyer]

Well, that's almost exactly the API we've already got with the Graphics View Framework. Now let's add some basic Qt Quick features to your example.

• Expression Bindings
  How do we support even simple expression bindings like <code>visible: item.width === 0 || item.height === 0</code>? Do we go down the WPF road having a glut of classes just to support expressions?
  @
  Item item(200, 200);
  PropertyExpressionParameter itemWidth(item, "width");
  PropertyExpressionParameter itemHeight(item, "height");
  PropertyExpressionIntComparator itemWidthComparator(itemWidth, 0);
  PropertyExpressionIntComparator itemHeightComparator(itemHeight, 0);
  PropertyOrExpression orExpression;
  orExpression.addComparator(itemWidthComparator);
  orExpression.addComparator(itemHeightComparator);
  PropertyExpression expression;
  expression.addOrExpression_(orExpression);
  item.setPropertyExpression_("visible", expression);
  @
  Or do we introduce a new expression language?
  @
  Item item(200, 200);
  item.addPropertyExpression_("visible", "item.width == 0 || item.height == 0")
  @
  Or do we have have to implement functors for each and every expression?

And all this stuff does not come for free. Each of these classes have to be QObjects, as property changes have to traverse so that expressions are correctly re-evaluated.

• Network transparency
  Qt Quick is fully network transparent, which means that resources can be either local or remote, even items themselves. How do we support this scenario in your implementation? Do we download C++ source code and compile it on the fly? Do we download binary code? How does this conform with security restrictions?
• Nested Property Bindings, Multi-Threading, Runtime Optimizations, ...

It's actually quite funny that you've mentioned WPF (or Windows Runtime or WinRT or Metro, which is basically the same technology) because it is a prime example how horrible things end when you try to force a dynamic user-interface approach into an imperative language as it basically looks like the absurd example I've sketched above.

Even people close to Microsoft say that "WPF makes the hard trivial and the trivial hard" and it has almost no acceptance in the industry so far for exactly this reason. That's something I do not expect from a mature Qt API.

WPF has such an absurdly steep learning curve due to all this additional stuff that had to be added just to support the programming model you are promoting here that a lot of people just refuse to use it. This is something that isn't true for QML. Any decent programmer gets the basics within a day and is able to activly work on a project within a week. We actually see a lot of people that use Qt Quick and QML to create applications who haven't seen C++ before and haven't done any serious programming before because QML is that easy to learn and understand.

We have canned a project we've been working almost half a year on and made a complete re-write in Qt and Qt Quick just because it couldn't meet most of our performance requirements even though WPF is fully hardware accelerated and it turned out to be a maintenance nightmare before it was even finished.

All these things you are bringing up here have been widely discussed before Qt Quick and QML was released. Not behind closed doors, but open for everyone. Dig through the Qt Labs archives, join the IRC channels or the mailings lists and you will see that there is a critical discussion on a daily basis about almost everything concerning Qt between the developers and even the community - and that there is a mature technical justification for almost everything.

But let's turn the tables. Where is your evidence that this was a pure political discussion? Where is your evidence that Qt Quick is 10.000 times slower than pure C++? How would you implement all the core features of Qt Quick in C++? How can you make sure that this is more efficient then using QML?

Maybe someone is idolizing and idealizing C++? It almost smells like "fanboyism".

[Guest]

@Andre - I am sure with your programming experience you can conceive moving this block of code to a class definition, you can also add pointers and dynamic memory allocation to the mix, your thinking it will break down smells more like wishful thinking, C++ is inconceivably better at building immense dynamic program structures QML will most likely never even be the foundation of in its lifetime.

There was a call for objectivity in this discussion, but apparently it was only regarding me, as your previous post is anything but objective. I work in a company that churns out dozens of UI designs each and every month, and in my 8 years of experience there was not even one assignment to request the expression of a UI in a non-graphical representation, and hey, we do that for a living. And this is professionals at work, surely, if you want to be "special" you could probably do it in Morse code, but since UIs are to be looked at, it is only logical to go for a graphical approach which gives an instant idea of the interface instead of having to parse lines of code, trying to IMAGINE what it would look like. You are simply coming up with more and more absurd ways to justify the enforcement of QML, which is fairly biased of you, but entirely in the realm of the expected.

I've been using Flash extensively for like 4 years, only recently backing down on it due to corporate decisions - there are generally two types of flashers - flash designers, which use the graphical facilities of Flash to design, and flash developers, which use designs created by designers as a graphical representation to implement via code. This is the professional way, as nonsense as you may find it.

And... umm, no, ActionScript is a C-style syntax language, it is far from being similar to QML, and so is the MXML atrocity, which although declarative in nature is an XML style language. MXML is just as pointless, introduced for the sake of simplicity without being all that simple at all, plus it is only suitable for object structure, all functionality you still have to implement in ActionScript, which you have to add extra tags to embed in the MXML, so there is a lot of overhead both in code length, code readability and that "simpler" way actually requires you to learn more syntax to to the same thins you can do with AS alone.

At least MXML is just an alternative to AS, just as QML should have just been an alternative to C++. So while Adobe might have done stupid and pointless, AT LEAST THEY DID IT RIGHT.

You are right thou, since QML is a parsed and interpreted language it can be interfaced, but QML is not UI description, it is UI implementation, and if you are willing to pick nits, you could twist it and say the implementer only describes the UI to the API and the QML API implements it on the fly, but this does not change the concrete fact every professional UI begins as what is usually a PSD Photoshop file, which can later on be implemented as a functional UI in any language out there, probably with the exception of machine.

What I miss is the option to use C++ to access the new GUI API of Qt that gets all the attention and development efforts, that is the point of using a framework - tapping into what it offers. And surely, C++ is supposed to be an imperative language, but object orientation actually makes it much more dynamic than an old-school imperative language.

Could I introduce a C++ API for the same technologies as are underlying QML - technically, probably yes. But it would cost me tremendously more time and effort, whereas it would cost very little to the full team of people who designed, implemented and are intimately familiar with the API. I spent a full year learning Qt, don't think the decision to walk away comes easy, but I will have significantly easier time implementing a similar API from scratch than the effort of plugging it into a vast and complex API I am not familiar with.

But I get the reasons behind the absence of such an API for C++, it would have made QML optional, which would inevitably lead to a much weaker adoption compared to now, when it has been made mandatory, and after all, whether you are capable of admitting it or not, this whole endeavor is to establish QML not to ease us developers. There is no ease in having an additional language, additional glue code and additional performance overhead, if you know C++ you can already to everything you can do in QML, surely, in a different, but even more powerful and performing way.

[Guest]

@Lukas Geyer - I often feel like you guys don't even bother reading and trying to understand the base of my complaints. Here you go, stating what I've been complaining all along, that the old C++ APIs are... old and unsuited for today's needs, which brings us to the point we need a better API, which brings us to the point the solution is there but exclusive to QML, leaving C++ GUI development behind.

You ask how can we bind properties at run time, well I think it is possible, the underlying C++ API behind QML seems to do it, and you seem to be trying to convince me that QML DOES IT ALL, but QML is just an interface, it is words, it is not even code that gets executed, it is just interpreted and used to control the QML API, which is C++, and the JS API, which is written in C.

bq. And all this stuff does not come for free. Each of these classes have to be QObjects

Oh yeah? And which QML component doesn't have AT LEAST a QObject behind it? Which custom QML component doesn't require to inherit AT LEAST a QObject if not any bigger interfacing class? I mean, really? This is a lousy form of argumentation..

Network transparency - well, thanks to pointing out yet another aspect QML is better than the C++ API, simply because the same feature has not been implemented there.

Everything else - it can be done in C++, it wasn't skipped on because it is impossible, but because of a decision not to do it. I don't thing QML has an advantage when working with threads, it has the advantage of having its API threaded, which is yet another benefit it exclusively get, leaving the C++ APIs behind.

The reason doing all those new things in the OLD C++ is hard is... because it is old and not really designed to do them, that is not a feature of QML to make those things possible, it is a feature of its underlying API. You make it sound like a QML feature simply because that C++ API is only accessible through QML exclusively, which, for the n-th time, is a design decision not a must.

Now runtime optimization - this I give to you, you cannot optimize compiled code, so finally, score 1 for QML.

My mention of Metro also contained the qualifier "sucks", I didn't mention it because I think it is awesome, but because it is a modern UI API that allows native access. And as bad as it is, I am willing to bet ANYTHING in just a few months its user base will exceed even the wildest dreams behind QML. I am not familiar with its internals and very vaguely familiar with its interface, mostly because I am not interested in platform limited APIs. No doubt as a native support API, Metro has a much larger footprint which does mean it will take longer to learn it all, but chances are you are not going to have to learn it all, just because it offers more features than QML doesn't mean you have to use them all. The same applies to C++, you can be a fully proficient programmer by keeping it to 5% of the C++11 specification, the rest if there if you so choose, entirely optional unlike QML. Qt as a whole has a very steep learning curve, it has so many APIs, but it is a fact you don't need to know them all, you only need to know those you need to use.

bq. But let’s turn the tables. Where is your evidence that this was a pure political discussion? Where is your evidence that Qt Quick is 10.000 times slower than pure C++? How would you implement all the core features of Qt Quick in C++? How can you make sure that this is more efficient then using QML?

Here we go again, putting words in my mouth - can you quote me stating QML is 10000 times slower? Didn't think so, as this statement was regarding Python performance I profiled in a specific computing task. Luckily, QML is supported by a C++ API compiled to native code, and it is not that much slower, but still it is slower, uses more memory, more CPU cycles, plus needing a running VM which all is avoidable by keeping it all native.

bq. Maybe someone is idolizing and idealizing C++? It almost smells like “fanboyism”.

Now you are just being a parrot, how mature of you. I remember explicitly stating that C++ might not be the best tool to do this, but it suffices and has quite a lot of advantages QML could not possibly ever match. Your (lack of) objectivity only equals the lack of a C++ interface to use like 90% of the innovations Qt has received the last year. Isn't ironic, since you are the one who called for objectivity to begin with? I never claimed C++ is perfect, it is you who claims QML is invaluable even thou it is just a collection of words used to control a C++ API.

[jaak]

I think the whole c++-Qml thing is miscommunicated. C++ is not going away. There is C++11 support coming in Qt 5.0. But there seems to be an over emphasis on Qml on many of the related blogs. UI is best done using a visual designer. What code it generates shouldn't matter, be it c++ or Qml. Hand coding a UI is tedious whether it is Qml or c++.

Somebody at Nokia have decided that a fluid UI can be better done using a declarative language and I can't find any good reason. But they have made the decision and the developers have to accept it regardless it is right or wrong. iPhone don't have any declarative thing. We use interface builder and OBJ-C code to do all the fancy UI tricks and it is easy. Qml seems difficult for html / css folks and alien to c++ developers. I hope the Qt visual designer would support (would hide) Qml and those can be manipulated with c++.

[lgeyer]

Well, I think I have supported this thread long enough so that the open-minded reader can conceive an objective opinion on the commitment of Qt to C++, Qt Quick and QML and the reasons behind on his own later on (and therefor I see the initial, or even any goal achieved).

And I think we all gave you more than one chance to actually understand why things have been done they way they have been done. It is your sole responsibility to accept it, and it is your sole free decision to like it or not.

Let's agree that we don't agree. I wish you the best finding what you are looking for, it obivously isn't Qt - but it is for a lot of us, including me, including Qt Quick. Does this mean that I would have done the same thing if I were in charge of Qt? Probably not, but I can understand the reasoning behind the decisions made - and after trying the result I am more than convinced (and, actually, I am glad that I wasn't in charge of).

[Uwe Kindler]

@temp - I do not really understand what QML can do (I'm no QML expert yet), that you are missing in the Qt C++ world.

QML is based on C++ API's that are already there for a long time. QDeclarativeView is derived from QGraphicsView. So instead of creating components in QML you can create QGraphicsItems in C++ easily with a very nice and comfortable C++ API.

In QML you can do state changes of components - in C++ you can use the powerful Qt statemachine framework (QState) to do the same - its C++ API is really great.

In QML you can easily create animations of visual (and non visual) components - in C++ you can use the Qt animation framework (QAbstractAnimation...) to do the same.

So all you can do with QML you can also do with C++. For each QML thing there is a C++ API. Ok, maybe it is not so easy and comfortable in C++ to get the same results like in QML, and maybe you need to spend a lot more time to get the same results, but you can do all the fancy UI stuff in C++ already. So what are you missing exactly in the Qt C++ world that you can do with QML?

[Guest]

@Uwe Kindler - you are thinking Qt Quick 1 and the old API. We are talking Qt Quick 2, which is based on the SceneGraph, which is exclusive to QML. Surely, you can do all this in the OLD C++ API, you are correct on this one, however you don't get the extra development ease, the extra performance, and basically you isolate yourself from the vast majority of improvements made to Qt the last year or so. What's missing is a new, elegant, contemporary GUI API for C++, that should have been perfectly clear by now.

@Lukas - so now I am close or narrow minded for not agreeing with your lack of arguments? All this time you did not present one technical, factual argument to support the need of QML, maybe you can't, maybe you think I am too stupid to get it, maybe because you fear I might point out a way to do it in C++. The fact is QML is not any more powerful than C++, and everything to can express in QML in a declarative way can be expressed using C++ in an imperative way, and in both cases it will be C++ doing the heavy lifting behind the scene, only if you chose C++ as a front end you have the advantage of keeping it all native, with all the benefits and with the elimination of interfacing, glue code and so on.

How can you even be convinced QML is the better and should be the only way when there is no C++ interface to use the same API, so that you could actually compare and have a base for your conclusion rather than bias?

[Guest]

After all the "it is not possible", "QML is innevitable" and so forth, finally some information from someone who appears to know what he is saying, a quote from a lab comment by someone, named Rupert:

bq. c++ binary contracts bind our hands, hence the lack of a c++ API to scenegraph.

Anyone care to elaborate on that?

[goetz]

Find some clarifications on the topic from Lars Knoll in his recent blog post: http://labs.qt.nokia.com/2012/04/18/qt-5-c-and-qt-widgets/