Qt’s commitment to C++?
-
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.
-
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++.
-
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: 200Rectangle { 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.
-
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.
-
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".
- Expression Bindings
-
@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.
-
@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.
-
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++.
-
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).
-
@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?
-
@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?
-
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?
-
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/
-
Yep, the power of rant is amazing, capable of un-censoring censored comments and provoke LABS posts. However, this LABS post "clarifies" that QWidget is not gone, which totally misses the point of this thread, as I never complained about QWidget getting sacked, but about QWidged being outdated, while the 21 century-adequate UI solution is exclusive to QML and enforces a proprietary language (QML), additional scripting language (JS), QML interpreter, JS VM and glue code overhead.
-
Can you please stop ranting about (un)censoring comments. This does neither happen here nor in any qt.nokia.com sites. So quit stating false assertions here. If you do not adhere to it, I will close this and any other thread containing that statement for further comments. This is the last warning. Thank you.
-
I see you are quite dedicated to your role and sensitive on the topic of censorship. Entirely out of respect for you I will no longer raise the issue of comments mysteriously disappearing and just as mysterious reappearing after the issuing of a certain statement. Lets just say it was an amazing coincidence, caused by a possible technical glitch, hopefully this will not put you in the awkward position that provokes you into issuing such warnings ;)
-
It is not only me who is is sensitive on that topic.
This site, as every other on qt.nokia.com, is free for everyone and every opinion. There are only very rare cases where posts or comments are actually deleted. This includes mostly SPAM and obviously insulting messages. From this point on I can only speak for this site: while we kill the former silently, we always leave a comment when moderating the latter, usually after consulting at least one fellow moderator or site admin. If a thread goes out of control it is closed, but not deleted.
-
OK, let me put it this way:
I wasn't like posts were offensive, I try my best to keep it on point, and if I use some "qualifiers" that can be interpreted offensively, it is never in a demeaning context, but justified. That explains why my comments were not actually deleted, they just did not appear, both posted from home or my work IP, while comments of other users kept on popping up. And it wasn't until I pointed out this "issue" when all those comments magically appeared in an instant. So pardon me if this looks suspicious, and sadly it doesn't end there...
I honestly don't mean to nag, but after yesterday I stated I will no longer raise that issue of disappearing comments, my comments mysteriously stopped appearing AGAIN, while comments from other users keep on going on. Is this purely coincidental? I am willing to assume even an amazingly improbable coincidence once or twice, but this keeps on repeating and IT WILL NOT BE MY FAULT if I start calling things as I see them, it will be well justified.
I know my comments are INCONVENIENT, and for about a year I kept away from doing or saying anything, waiting for an indication someone will address the issues at hand, but there was no indication whatsoever that anyone at Qt is concerned with an up-to-date GUI API for C++ despite the many requests from developers, and I REALLY HATE to be that guy, but someone had to do it. For my time in this forum I did my best to be polite and as helpful to everyone as I could, and I really hate to have to be the "persona non grata" but looking at the responses from the community it does seem to appear I have a point and am not a vocal minority. I never wanted to provoke this wave of complaining, I spent lots of time hoping someone at Qt will take on that issue, but since no one did, well, "a man has to do what a man has to do", and forcing things is really the last resort. Apparently Nokia has no problems renaming blind and deaf to individual requests from developers, hence my actions aiming to combine all those requests so that Qt managers finally notice we are not talking a few dinosaurs' last stand against this devolutionary form of "evolution", we are talking ABOUT A LOT OF PEOPLE, and hopefully pay attention to what the developer base wants instead of pushing people to adopt fancy and useless new tools we can easily do without.
I brings me no joy to do what I do. To be honest, I think this sucks, and the reason I don't blame myself is things would have never come to this if the managers behind Qt listened to what developers want. Someone had to do it, and it is not that important if it is me or someone else, perhaps it would have been better if it was someone with a milder and softer personality, but if we're all silent there is nothing to put Qt back in the tracks of C++ dedication, not as a low level language to extend QML but as a fully fledged programming language with access to modern APIs and the option of keeping applications simple and native.
Keep this in mind, my actions are merely a reaction to the direction Qt is being pushed since the acquisitions. To quote a smart man who lived a long time ago:
bq. To every action there is always an equal and opposite reaction
If the vector of my reaction is inconvenient to Qt managers, it is entirely their own fault for directing Qt in this direction and ignoring developer's requests for so long. And if it sounds a bit too intense - let's just say I speak for all of those too polite to do it and for all of those who were too quiet to provoke any attention.
And just to keep it on the bright side ;)
!http://i39.tinypic.com/dbhyqo.jpg(guiapi)! -