Qt’s commitment to C++?
-
[quote author="temp" date="1334075846"]It is too bad thou, the world DESERVES a good C++ framework, which is something Qt is no longer aiming for.[/quote]
I totally agree with you, I feel the same.
We really need a good cross-platform desktop C++ framework.
I think this is the area where Qt could be good (the best!).Anyway MS says: In the future the Silverlight line will be killed (WP7 dev. lang.!). And the next VC++ will be back to native! An upgraded MFC (WinRT=MFC in C++ clothes) will be provided, instead of CLI/C++. Is it interesting, isn't it? Where is Qt in this line???
Other. Last IDC report says: Symbian is only at 1%. The smartphone selling is over 90% in the USA. What about the non high-performance mobils?
See this pic:
http://farm8.staticflickr.com/7043/7044935049_a54fbe7993.jpg
This pic says everything.... -
^^ This is actually the paradox - MS, the standard for proprietary, monopolistic frameworks has their new GUI API - Metro actually opened to native C++ code, to bad Metro sucks and is platform limited. but still, Nokia could take a lesson. Not rush foolishly the same way MS is stepping back away from...
Symbian actually was dominating the mobile market some 3-4 years ago:
!http://www.gsmdome.com/wp-content/uploads/2010/02/mobile-os-market-share.jpg(symbian)!2007-2008 - almost 70%
2009 - 50%
2010 - 3%
today - 1%I ain't putting THAT driver in my car... Yet another reason I am NOT feeling happy and safe with the new owner of Qt, I really don't feel comfortable long-term betting on a framework, behind which sits a company, capable of such an epic failure. Hopefully Nokia will not decimate Qt the same way it did its mobile market share...
-
So, what is this, yet another Nokia, Microsoft and Elop rant? Or are we still trying to talk about C++ and QML in a serious way?
[quote author="temp" date="1334075818"]I totally understand you, you are dependent and not supposed to even consider biting the hand that feeds you.[/quote]
I'm afraid I have to disappoint you. As a self-employed developer its my own hand that feeds me, not the one of Microsoft, nor the one of Nokia. Quite contrary to, Nokia is spending hundreds of millions of dollars to assist Qt just to give it away for free, including me. I'm not a friend of Elop as well but this is Nokias problem, not mine, nor the one of Qt, which has gone open governance a few months ago.[quote author="temp" date="1334075818"]My problem lies entirely in that corporate greed and stupidity inspired vision that has been directing the main development force of Qt.[/quote]
The work on Qt Quick and QML has started years before Microsoft and Elop. Qt Quick was released in March 2010, Elop has become the CEO of Nokia in September 2010. It was purely created to improve the performance and usability of Qt, thus opening it to a much broader audience, guaranteeing a future for Qt (and thus beeing inevitable for Qt, not for you).[quote author="temp" date="1334075818"]The same way everyone is doing it, leave the old stuff for backward compatibility and crate a new, modern API, one that can be used natively not exclusively accessible through QML.[/quote]
Well, the new, modern API you are looking for is QML. C++ was built to express algorithms and business logic - it was never meant to express rich user interfaces and it is not suitable to do so. And that's exactly what Qt Quick does: seperating two different domains into two different domain-specific languages. C++ for algorithms and business logic, QML for the user interface.And that's what I as a developer do on a regular basis. I use SQL instead of C++ to query my data because it allows me to express data selection better. I use XML instead of C++ to describe the data format because it allows me to express a data schema better. I use CSS instead of C++ to describe the style because it allows me to express formatting better. I use .pro files and makefiles instead of C++ to express projects because it allows me to express build rules and dependencies better. And now I use QML instead of C++ to design user interfaces because it allows me express them way better.
Does this mean that I've stopped using C++ and ordinary Qt? Well, no. My applications still consist of 95% C++ and ordinary Qt code, but I've decided to use a domain-specific language for the remaining 5%, because it saves me an awful lot of time (and time is money in my case).
The vision of seperating the user interface from application logic has never been so clear as with QML. We finally have full tool support for creating rich user interfaces (which is quite impossible using C++). Instead of tediously recreating design proposals from the designers they now can completely create the user interface on their own, including animations and transitions, all without knowing a bit about C++ - which is another key strength added to Qt.
Not everyone using Qt is using C++. We have an active PyQt community, people are using Java and C# to interface Qt as well. And now everyone beeing capable of JavaScript can join as well, which will again multiplicate the audience of Qt - which is a damn good thing. There is almost nothing like a large audience that will guarantee the future development and improvment of Qt.
Does this affect me as a C++ developer? No. Besides that I get another effective tool, which can be learned in less than a week and that allows me to save a great amount of my precious time, including improved tool support and performance.
[quote author="temp" date="1334075818"]The problem is you and me have a totally different vision of the "future" - your vision is what the industry tells you, an industry concerned by nothing but profit through proprietary, incompatible technologies, and the waste due to lower performance and worse memory usage is the small price that needs to be paid for straying away from good, fast and efficient languages like C++.[/quote]
Qt as well as Qt Quick and QML are are fully documented and publicy available. Anyone is free to adopt, reimplement and change the way it works - and contribute those changes to the Qt project itself.Improving performance was one of the reasons they have actually moved away from C++. QML was a prerequisite for implementing the scene graph, the reason Qt Quick now performs way better than Qt Widgets and the Graphics View system (and any other framework, including the ones you've mentioned).
-
As Qt is now in open governance, you could always contribute a module to sit on top of Qt GUI giving a library of C++ controls. As mentioned in an earlier post, all of the building blocks are there. There seem to be a (small?) number of people who feel the love for C++ is being lost, so perhaps it just needs them to work together to add something back into the library?
Just my 2p...
-
I'm reluctant to mix into this rant, but hey, here it goes...
Perhaps you should realize that the Graphics View framework was mostly conceived for the reason you're looking for: a C++ based way of expressing dynamic UI's. While QGraphicsView has many uses, for the purpose of creating complete dynamic UI's, it simply did not turn out to be enough. There have been more attempts (Qt Edje comes to mind) that have not succeeded themselves, but did lay another brick of the foundation of QML. Even Quick 1 can be considdered a attempt that did not quite wend far enough to reach the levels of performance needed to be able to provide a real fluid experience. And note that Quick 1 was based on QGraphicsView. That's right: just QGraphicsView objects that are being manipulated in all the ways you can also do from C++.
Perhaps you should take a look at "this video":/videos/watch/a-desktop-ui-with-qt-quick, and reconsidder if Quick in combination with C++ may be worth investigating after all, even for the desktop. There also was a very impressive presentation at last years DevDays by someone who created, right there in the room during the session, a Stottify client using Quick Compontents for Desktop, but I can't find the video at the moment. (I think the presentation was by "this":http://labs.qt.nokia.com/author/jbache/ guy.)
-
@Lukas Geyer - let's cut the quote wars, yes it is true Elop came in after Qt Quick 1 was out, and he cannot be blamed for making the decision to come up with QML, I don't even know whether Qt falls in the scope of his responsibilities, but if so, he did nothing to change that course, and in my book setting a bad direction is not that much different from deciding to keep a bad direction. But the BIG question is did work on QML started before Nokia came into the picture? And even if so, whose is the plan to push C++ away from receiving high level API attention in favor of QML?
bq. C++ was built to express algorithms and business logic – it was never meant to express rich user interfaces and it is not suitable to do so
C++ was built to be a GENERAL PURPOSE programming language, and MOST CERTAINLY was NOT built to act as a modern day assembly level language, isolated in the low level and only accessible through additional glue code, generated code and other forms of unnecessary trickery, made mandatory and inevitable by pushing another language's exclusive use.
The matter of fact is even Microsoft are stepping back from this approach, it took them 5 years to figure out it is simply not worth it, and if Nokia is too busy proudly marching in the missteps of MS I am not waiting another 3 years for Qt to come to the same realization.
The reason for the better performance of the SceneGraph has nothing to do with QML, but with optimizations, built into the engine. The same type of performance boost is possible through optimizing the old rendering API, the onyl difference is with the old one you have to do it by hand and can be quite tedious, with the SceneGraph it is automatic, but only if you settle for QML. This is the type of selective improvements Qt gets and gives excursively to QML which is the source of my disappointment. You should have figured it out by now.
@SteveKing - everything you say is true, I can do that, I can create a QML alternative for C++, states, animations, and I can contribute it to Qt, but if I am to reinvent the wheel, I might as well do it with a framework that is more open, more independent, simpler, smaller, faster, one that does not require 20 MBs of dll to do the most basic things, one that doesn't ask you to open your code or pay THOUSANDS of DOLLARS if you want to avoid dynamic linkage, and above all, a framework that is not pushing away from a fully native workflow. Qt still has a good C++ low end API, but with the overall direction, overhead and complexity, and above all with Nokia behind the wheel I am willing to look another way.
@Andre - yep, Qt Quick 1 exposed GraphicsView as being sub-optimal, and what was the response - make an optimal API, but exclusive to QML. GraphicsView - a C++ API could lend itself to QML, but SceneGraph gets locked to offer benefits only to QML. And please don't tell me QML is a necessity to use a better graphics API, QML doesn't even directly interface with the SceneGraph, it does so through a (my bet is a C++ based) interpreter. As I already mentioned above, the same GUI API optimizations can be made to the C++ GUI API, but that wouldn't put QML to the advantage Nokia seems to want to give it. I've said it - the bowels of Qt are too complex for me, I cannot put that optimization there myself, I can optimize my own application to get the extra performance boost and features, but I cannot make it a part of the API, I have to keep on doing it over and over again, which seems to be that extra tedious development process Nokia wants to save only for the QML front end to put C++ high level development in a disadvantage.
I did watch just about every DevDay presentation, in fact I still have most of them on disk (yep bothered to download even thou it was not easy thanks to that awesome video service provider) and I honestly dislike the extra effort, bunch of macro, MOC code, glue code that all would not be necessary if Nokia allowed native access to all the improved APIs designed to give QML exclusive features and advantage.
APIs should be created equal, and then give users the alternatives to native use, be that QML, Python, JS or any other technology. But giving QML exclusive advantage sucks about just as much as it would suck if PySide got extra features from the Qt APIs what is not available for native use. As a language binding PySide gets nothing more (and probably less) than what the native use of the APIs offers, and the only actual benefits it may have are strictly Python related and have nothing to do with the APIs it binds to, the same approach would have been much better for QML - let it have the advantage of simpler and declarative syntax to access the APIs that can also be used natively, which is the option that is missing.
Another problem is the interfacing for QML actually increases the complexity of Qt, I have chosen Qt because it made C++ development simple and easy, and now I chose to walk away because the simplicity QML offers comes at the expense of making C++ APIs more complex. I care about simple C++ and I cannot force myself to like the fact C++ gets more tedious and complex just to benefit, promote, and to a considerable extent enforce QML. C++ development WITHOUT QML is simpler, more elegant, and no matter what you keep saying, will offer better performance, as QML actually decrease performance, the effect of which is masked out by the better graphics API it exclusively gets.
I care about C++, which suffers in too many ways because of the push to establish QML. C++ gets more complex, less "C++" and more macro, MOC, meta objects and what not, gets left behind, gets pushed into the low level even thou it is by far the most diverse programming language of all and second only to C in terms of performance, gets less attention and development effort investments, all those - bad prospects for anyone who wants to focus on C++.
-
Just some corrections:
The C++ APIs do receive a lot of attention, even with Qt Quick taking the limelight.
The performance boost you see when using QML is mostly due to making use of the GPUs, not due to optimizations made here and there in the rendering path. Using the GPU requires a scenegraph. To use a scene graph you need a rendering infrastructure that maps well into one. Qt Quick does, QWidgets do not.
The scenegraph is no secret sauce at all... it is readily available on gitorious.org. Use it in whatever way you like.
I do not know the price of a commercial Qt license, but was told it was very affordable. Definitely not the millions of dollars you claimed earlier, most likely not even the thousands of dollars you claim now. You also do get commercial support for that money.
Decisions on the future of Qt were always takes on purely technical reasons inside Nokia before open governance was fully set up. Now decisions are taken in the public -- and again for technical reasons only.
MOC, Q_OBJECT macros, etc. are used for the signal and slot system and have been used in Qt since the very beginning. More macros (Q_INVOKABLE, etc.) were introduced later to enable language bindings to Qt Script, Python, etc. All this is in no way new to Qt5 and completely unrelated to QML (even though QML does of course use this infrastructure, too).
I see you do not agree with the decisions taken with Qt5. You are free to try to influence those, we have mailing lists set up for this, there is this forum you are already using. Getting a better understanding of the technologies involved would strengthen your arguments a lot though;-).
If you are too frustrated to care about influencing the direction of Qt, then all we can do here is to wish you good luck with whatever tool kit suits your style of working better. After all there are no silver bullets in IT.
-
"There is no reason to believe that there is one language which is best for everything. There are things I would use JavaScript or Python for. Different applications have different constraints and there are [constraints] that are not C++s core domain." - Bjarne Stroustrup
And the same goes for an application framework. There are different applications with different constraints - and that's what Qt offers. If you are going to develop a native legacy application you choose Qt Widgets, if you are going for graphics-intense applications with thousands of lightweight objects you choose the Graphics View Framework and if you are going to focus on a rich user-interface you are going for Qt Quick - or you just combine all of them in a single project.
None of the three are meant to be replacements for each other, all of them serving a different purpose, all of them beeing good at different things, and thus all of them beeing implemented differently using different technologies. You cannot use a scene graph for drawing native widgets and you cannot use a raster paint engine for efficiently drawing fluid user interfaces. These are technical limitations, not political one.
Qt Quick is just another option, another specific tool that is provided to solve a specific problem. You either have a tool that is average on everything or you have a set of different tools, each of them beeing superior at their task. As a developer I prefer the latter one.
And this is where all the insecurity comes from. Some people see Qt Quick as a replacement for everything they have done so far, which it is clearly not. It is just another tool given the developers willingly to learn something new to solve a specific problem in a more efficient way. It is not threat, it is a great addition to Qt, which will widely broaden its use cases.
If you are unwillingly to inform yourself or to learn something new that's most probably not the fault of Qt.
-
@Tobias Hunger - I never claimed a commercial license costs millions of dollars, that was not about purchasing a commercial Qt license but purchasing Qt itself.
@Lukas Geyer:
bq. If you are unwillingly to inform yourself or to learn something new that’s most probably not the fault of Qt
Now this seems to get a tad offensive - as a polymath my head is already bursting at the seams, because I am very curios and love learning, I am already "burdened" by a wide range of technological and artistic disciplines, we all have limits and my unwillingness to adopt QML has nothing to do with me being lazy or lacking the will to learn, it has more to do with not considering QML being worth learning. I am pretty sure Nokia is very eager for as many people as possible to adopt QML and establish a wider user base for their proprietary technology. I have too many interests besides programming to be able to learn each and every proprietary, limited use, inefficient language out there, that is why I want to keep it to the bare minimum, going only for the most powerful and flexible solutions, that is the reason I chose C++ which gives me the foundation to tap into other powerful technologies like OpenGL and OpenCL, which are based on C, which is almost completely available as a subset of C++.
Surely If I was lazy I wouldn't go for the most complex programming language, would I?
Sure, different languages have their areas, but considering that most other languages are actually written in C++ or C (as well as all operating systems and powerful libraries) I honestly won't step up and say something as stupid as "this cannot be done in C++" - it may not be the easiest way to do it, but it will be the best performing, and I PUT THE RIGHT WAY ABOVE THE EASY WAY, because most of the times the easy way is the wrong one, the harder an achievement, the more rewarding, of course without having to be TOO HARD (as would be sticking exclusively to assembly language for example). A block of logic may be 1000 lines in C++ vs only 500 lines in Python, which is a whooping 2x advantage for Python in terms of development speed, which sadly comes at a 100x performance penalty. And for me, writing half the code is not worth getting 100 times less performance, because I AM NOT LAZY as you implied. Even if you compile Python to binary to avoid the cost of interpreting it on the fly, the performance hit still outweighs the development ease, which can be achieved with C++ by forging an API for that specific task.
You seem to assume I never even bothered with other languages, that I have blinds on my eyes and stubbornly refuse to look any other way - besides C and C++, more or less I have done and am familiar with (in order of appearance) Basic, Foxpro, JS, ActionScript, Python and Java, my decision to chose C++ comes from comparing a wide enough base to make a rational and objective decision. Again, I cannot afford to learn a whole bunch of programming languages, there are many other things I want to and am learning as well, so I am only willing to dedicate effort to the one language that offers the most, which is C++, that is why I chose Qt as a C++ framework, that is why I dislike Qt being pushed to become something else. I realize I may be an isolated case, but I have no aspirations of becoming a programmer at the expense of everything else, I am conformable enough with being a human being that does programming, not as a purpose in life, but as a compliment to all the other things that I do.
-
A lot of your earlier ranting was "a tad offensive" for the people working hard on making Qt better ever day. No don't go crying if that gets back at you.
I'm sorry if Qt isn't developing into the direction you'd like to see it develop. Ranting about that won't change that though. You can only pitch in yourself, either by contributing code or by contributing money if you want to influence the direction of Qt development. If that is not an option for you, sorry. I hope you'll find a toolkit that suits you better.
-
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.
-
... 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.
-
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.
-
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.
-
@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.
-
...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-ZE9MoHowever, 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?
-
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.
-
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++.