Qt’s commitment to C++?
-
I started learning Qt about a year ago, after enthusiastic recommendatory from my room mate. I spent quite a while before picking Qt, for various reasons I decided to go for C++ development and portability, and Qt happened to offer both. It also offered a complete package, a good IDE, a full tool chain and tons of functionality.
I am not that deep into programming but I noticed a swift change in the opinion of Qt in the very person who got me hooked on using it in the first place. I myself experienced a similar, even thou not as drastic shift - my initial inspiration from reading all those exciting new technologies in the LABS section began mixing in with disappointment after noticing the directionality of those innovations.
At this point, looking at the fruit of the development efforts the last year or so, it doesn't seem like Nokia is committed to keep the high level native C++ API up to date and evolving. All development is focused on QML, which gets all those new features exclusively, and the C++ API appears to be left behind. And sure, we are still able to use native C++, but without access to all the new technology and with the overhead of having to interface C++ logic to QML. I dislike the fact that C++ is being pushed to become an isolated, low level routine language by directing development efforts away from it.
bq. Qt 5 should be the foundation for a new way of developing applications. While offering all of the power of native Qt using C++, the focus should shift to a model, where C++ is mainly used to implement modular backend functionality for Qt Quick.”
The reason I chose Qt was C++, the reasons I chose C++ to begin with are quite many, with the goal of my choice of C++ being developing applications in C++, not using C++ to extend QML. I really dislike the fact QML, a limited application language gets all the focus and all the goodies, while C++ APIs are still there, but not really improved on, more like left for compatibility purposes and scheduled for future deprecation. I dislike the fact Nokia is extorting users into adopting QML or miss out on the benefits of development efforts, invested in Qt and get stuck with an outdated GUI API.
At this point I begin to understand the disappointment of my room mate, he spent 3 years learning, using and recommending Qt as a good C++ framework, luckily I wasted less of my life with it.
I may be a dying breed but for various performance, portability and efficiency reasons I really want to stick to C++, I don't like the concept of having code generated for me, I don't like the concept of having to glue bits of code in different languages together. After careful consideration I decided to cut my losses and go for an Allegro/Boost combo, as it offers better performance, better portability, better memory efficiency and all the features any application would need and above all, it doesn't enforce a new, proprietary language to take benefits of new features, allowing me to do what I want to do - keep it all native and obvious C++ code, no stitching, no behind the scene code generation, no extra languages and no limitations. Better licensing, Windows, MacOS, Linux/Unix are already supported, so is iOS and a healthy Android port is on the way, and with no indication of Nokia committing to evolve the C++ high level API or officially support mobile platforms that have taken the market by storm this is the deal breaker for me.
I know I am not the only one with similar concerns, yet people who voice such concerns don't seem to be enough to influence the direction Qt is being directed at by its new corporate owners, so my choice is to no longer be part of this community, I'd like to thank you all for being helpful and wish you best of luck.
-
I totally agree with you. I am also very disappointed with Nokia. This new line (XML/JavaScript) will go smash. I haven't used Qt in mobile platform. I use(d) it only in desktop environment. My favourite language is the C++. I have (had?) a really multiplatform C++ framwork. The 3.x and 4.x line of Qt was very good. But the new 5.x line with emphasized JavaScript is completely different what I want from the Qt (Nokia)... Me is unclear the future of Qt.
-
Well, what makes you think that C++ support will disappear anywhere soon (not trolling, just curious)?
QML gives you an additional option, it won't replace anything (and for sure JavaScript won't replace C++). And actually it is an absolutely valuable and inevitable option. Like it or not, but mobile computing and fluid interfaces (just take a look at Windows 8) become more and more important in the whole IT business and Qt Quick is one of the reasons Qt will play an important role in the future. You should be worried if Qt hasn't such a technology as Qt Quick.
But again, you don't have to use it. C++ is the foundation of Qt Quick and it will be there as long as there is Qt. The same goes for Qt Widgets. There is no need to learn QML, there is no need to learn JavaScript.
Yes, Qt Quick is receiving a lot of attention - but for the simple fact that it is emerging technology whereas Qt Widgets is around for decades now and can be considered mature technology (which, however, should not mean that it should not receive further love). And yes, Qt Quick 2 is a large part of Qt 5, but there is also "a ton of stuff":http://qt-project.org/wiki/Qt-5Features for the plain old C++ people.
I think there is a lot of confusion and insecurity caused by a serious lack of information on both ends, Nokia unable to provide and the developers unwillingly to inform.
-
[quote author="Deleted Member # 269f" date="1334051073"]....
bq. Qt 5 should be the foundation for a new way of developing applications. While offering all of the power of native Qt using C++, the focus should shift to a model, where C++ is mainly used to implement modular backend functionality for Qt Quick.”
The reason I chose Qt was C++, the reasons I chose C++ to begin with are quite many, with the goal of my choice of C++ being developing applications in C++, not using C++ to extend QML. I really dislike the fact QML, a limited application language gets all the focus and all the goodies, while C++ APIs are still there, but not really improved on, more like left for compatibility purposes and scheduled for future deprecation. I dislike the fact Nokia is extorting users into adopting QML or miss out on the benefits of development efforts, invested in Qt and get stuck with an outdated GUI API.
[/quote]Hi,
I'm using Qt now fro nearly 10 years, and it got better and more. I use it commercially for work. And I don't see a problem there. IIRC, the business part of an app is usually the biggest one and the most important one.
I have often seen changing the UI, but not the business logic. Changing the UI using Qt Quick is easy and fast. And some companies need it and use it. We will not, and that's OK.
Qt is IMHO the best cross platform framework.
I know it's not ported to iOS, and there is a reason (legally). And also not officially to Android.
If you face those platforms, you have to decide what to do. But AFAIK, iOS only supports Objective C, right?
-
[quote author="Lukas Geyer" date="1334064028"]I think there is a lot of confusion and insecurity caused by a serious lack of information on both ends, Nokia unable to provide and the developers unwillingly to inform.[/quote]
Yes, you are right. I can't see CLEARLY the future of Qt (in Nokia). My main problem is the "serious lack of information". I my opinion, the Qt will calm down without a STRONG back support (=Nokia's money). Qt is now for Symbian and N9, but these are not the main line of smartphone market. According to Nokia, WP7 will be the MAIN line (next to Android and iOS). Sorry, but without clear information, I can't see the future...
-
Perhaps you should look at who's contributing to Qt at the moment then. The repositories are all in the open, so it's easy to check. Look at the number of @nokia.com addresses in there, both for Qt itself, as for Qt Creator. Those people do not work for free. And did you notice the "We're hiring" signs on the website? So yes, Nokia is pooring big money into Qt. I bet they have a good reason for that.
Sure, I would prefer to have Nokia communicate more openly on their business case for Qt. I have argued for that myself in the past. But so far, the acts speak loader than words. And the fact of the matter is that Nokia is still developing Qt, and putting in lots of effort to do so. And so is Digia, and KDAB, and...
-
How can we have huge, sweeping changes to the C++ APIs when we promised to stay almost source compatible with Qt4? But still there is lots of cool stuff happening in Qt5 that is directly visible to all C++ user.
This includes things like reworking the containers to be faster, better/faster regexp support, integration of C++11 features into Qt, work on QLocale, Time handling, unicode work, better modularity, a new version of webkit, ... . Check the commit logs for lots more! I really do not see how "the C++ API appears to be left behind".
The biggest beef most people seem to have with Qt5 is that QWidgets are pretty feature complete and have a useful API that should stay stable. I really fail to see what is the issue with that!
Where is that focus "on QML, which gets all those new features exclusively"? Of course there is a focus on QML as that is a new and exciting technology. Does it get features exclusively? I don't think so. The one exclusive feature is the scenegraph, which is indeed not used in QWidgets. The QPainter-based rendering approach used by the widgets just does not profit from using a scenegraph. So why use it there, especially considering that this would break all widgets with custom paint methods?
Qt does require code generation... so if you are allergic to that, then it is indeed the wrong tool kit for you. The whole QObject system depends heavily on generated code. Fun fact: With Qt Quick you have less generated code then with QWidgets (when using the designer), since Qt Quick does not need uic, the ui file compiler.
@broadpeak: Calling Qt5 a javascript framework because of Qt Quick is as true as calling Qt4 a XML toolkit just because Qt Designer happens to produce files in XML.
-
[quote author="broadpeak" date="1334065963"]
Yes, you are right. I can't see CLEARLY the future of Qt (in Nokia). My main problem is the "serious lack of information". I my opinion, the Qt will calm down without a STRONG back support (=Nokia's money). Qt is now for Symbian and N9, but these are not the main line of smartphone market. According to Nokia, WP7 will be the MAIN line (next to Android and iOS). Sorry, but without clear information, I can't see the future...[/quote]This is right for the high end smartphone market. But AFAIK Nokia is also selling other mobiles, and IIRC those might get Qt on board. Why else should they investigate much money there? There is some Nokia place near (or in) Ulm in Germany, where they do Qt development. And they are hiring.
It's just not for the high end. But AFAIK for the next billion.
-
[quote author="Lukas Geyer" date="1334064028"]... what makes you think that C++ support will disappear anywhere soon...
[/quote]There is a huge difference between supporting something and evolving something. Microsoft still supports Windows XP, but it is a dead end, the same kind of a dead end that the Qt C++ GUI is. I never complained about C++ not being supported, I companied about the C++ GUI API not being improved to meet today's standards.
bq. ...QML gives you an additional option, it won't replace anything...
bq. ...inevitable option...
bq. ...But again, you don't have to use it.... There is no need to learn QML...
You do realize the contradiction in the above three quotes? You do realize Qt is redesigned to make QML inevitable and yet you claim we don't have to use it. This is exactly hand in hand with what I said - C++ GUI is there, but if you chose to stick to it, get get left behind. As much as a single developer can do it is no match to what the pack of trolls can bring, and that is my problem, that ever since Nokia bought Qt it has been directing the trolls in a direction that puts a lot of the C++ APIs in disfavour, all aiming to make QML look better by holding back on the C++ API
bq. ...Yes, Qt Quick is receiving a lot of attention - but for the simple fact that it is emerging technology whereas Qt Widgets is around for decades now and can be considered mature technology...
Qt GUI goes far beyond mature, into the area of outdated, of which you seem to be quite aware judging from:
bq. ...Like it or not, but mobile computing and fluid interfaces (just take a look at Windows 8) become more and more important...
As pointless as eye candy is, it is nice to have it. And that is where most of my issue with the direction of Qt actually lies. Nokia are extorting Qt's developer base - "either settle for QML or miss out on the new GUI API we deliberately made only accessible through our own proprietary language". The point of the matter is - QML is not a requirement for fluid, modern, touch supporting GUI, and in fact without QML this would only be even more fluid, smoother and so on, because no interpreted language is a match to native C++ code. The point of QML IS NOT to enable a modern GUI API, but to exploit a modern GUI API to force developers to adopt QML. You don't actually claim it is impossible to achieve the same without QML, do you? Like I said, and you said, it the back end behind QML is ALL C++, so why the hell would QML be made, to put it in your own words "innevitable"??? Besides the obvious reason I already stated?
bq. ...I think there is a lot of confusion and insecurity caused by a serious lack of information on both ends, Nokia unable to provide and the developers unwillingly to inform....
I think the purchase of Trolltech was the worst thing that could have happened to Qt. Nokia was already a sinking ship, trying to get hold on whatever it can to help it stay afloat. And that GENIUS Elop hammered the final nails in, but I honestly doubt he is that stupid, I don't think he did an extremely bad job as CEO, he did an EXTREMELY GOOD JOB as a Microsoft mole, doing 2 HUGE favours to MS, first jacking Qt, a major threat to the software monopoly of Microsoft, and mutating it into yet another toy app interpreted language framework (the so called "long term vision driving Qt development ever since the acquisitions) and last but not least, Elop also massacred Nokia's market share, clearing quite a lot of field for Microsoft to invade in that SO DESIRABLE and PROFITABLE mobile market. I won't be surprised the least if in the future Elop gets a good chair position at MS for the job he did so well, much like Hector did get the chair at GF after his actions cost AMD their fabs.
That is why I am more willing to bet on Allegro and Boost. Allegro is literally a public domain framework, the chances of it selling out to some greedy corporation, which inevitably spoil everything they get their claws on is much lower, practically non-existent. Sure, Allegro is supposed to be a library for games, but it can just as well be used for generic GUI, it is faster at painting, has a faster event system, and although not as complete as Qt, all that is missing is not all that hard to implement, unlike Qt, where the sheer size and complexity of the framework make it very hard, and the licensing scheme makes it even harder. For all that is missing in Allegro, Boost offers more than adequate solutions, and unlike Qt, the direction of both Allegro and Boost is perfectly clear, I have only two regrets, time time I spent on learning Qt and the fact Nokia bought it, for if that did not happen I am concrete that Qt would have been a much better framework, with much clearer direction and potentially even wider feature and platform support. Instead of that we have Qt as a framework that made its name on C++ trying to push C++ to become the new assembly language, a framework owned by Nokia that is actually not even supported on Nokia phones. I am sorry but I will need to be on some pretty serious, Prozac grade drugs to be HAPPY with what Nokia did to what was if not a great, at least the best C++ cross platform framework alternative out there.
-
[quote author="temp" date="1334069537"]There is a huge difference between supporting something and evolving something. Microsoft still supports Windows XP, but it is a dead end, the same kind of a dead end that the Qt C++ GUI is. I never complained about C++ not being supported, I companied about the C++ GUI API not being improved to meet today's standards.[/quote]What do you want to be evolved? What are you missing currently? Which parts of Qt Widgets don't meet today's standards? And how do you do all this without violating sourcecode compatibility?
[quote author="temp" date="1334069537"]You do realize the contradiction in the above three quotes?[/quote]No I don't - and I ask you to elaborate.
[quote author="temp" date="1334069537"]You do realize Qt is redesigned to make QML inevitable and yet you claim we don't have to use it. This is exactly hand in hand with what I said - C++ GUI is there, but if you chose to stick to it, get get left behind.[/quote]Again, what makes you think so? Qt Widgets is and will be an integral and maintained part of Qt. Noone ever said something different.
[quote author="temp" date="1334069537"]As much as a single developer can do it is no match to what the pack of trolls can bring, and that is my problem, that ever since Nokia bought Qt it has been directing the trolls in a direction that puts a lot of the C++ APIs in disfavour, all aiming to make QML look better by holding back on the C++ API.[/quote]You do realize that all parts of Qt benefit from the improvements made for Qt Quick?
You do realize that Qt Quick purely bases on technology - the meta object system, the animation framework, the state machine framework, the graphics view framework, the OpenGL module and so on and so forth - which is an integral part of the core Qt framework, accessible to both, QML and C++?
[quote author="temp" date="1334069537"]Qt GUI goes far beyond mature, into the area of outdated, of which you seem to be quite aware.[/quote]Outdated? Where?
[quote author="temp" date="1334069537"]As pointless as eye candy is, it is nice to have it.[/quote]That's a fundamental misinterpretation of the current situtation in the IT business.
[quote author="temp" date="1334069537"]And that is where most of my issue with the direction of Qt actually lies. Nokia are extorting Qt's developer base - "either settle for QML or miss out on the new GUI API we deliberately made only accessible through our own proprietary language". The point of the matter is - QML is not a requirement for fluid, modern, touch supporting GUI, and in fact without QML this would only be even more fluid, smoother and so on, because no interpreted language is a match to native C++ code. The point of QML IS NOT to enable a modern GUI API, but to exploit a modern GUI API to force developers to adopt QML. You don't actually claim it is impossible to achieve the same without QML, do you? Like I said, and you said, it the back end behind QML is ALL C++, so why the hell would QML be made, to put it in your own words "innevitable"??? Besides the obvious reason I already stated?[/quote]Qt Widgets and Qt Quick serve two totally different purposes - that's what people have to understand. The former one for native legacy applications, the latter one for fluid, non-typical user interfaces.
Declarative languages are the future of describing rich user interfaces and they do a way better job at doing so than classical programming languages. Why do you think HTML5 is so popular? Why do you think Microsoft is heavily pushing XAML? Why do you think declarative mobile platforms like PhoneGap are so popular?
This is where the IT business moves to - you either follow or you are left behind. And that's the reason Qt Quick is an inevitable technology for Qt.
Don't get mad at me for not commenting your remaining Nokia, Elop, Qt rant.
-
I see that you were very enthusiastic about Qt and are deeply frustrated with what you see. Unfortunately there is little I as a developer can do about that: Please consider to "go here":http://www.nokia.com/de-de/support/kontakt/ instead, as those guys at least have tools to pass on your critique to people that have the insights to comment on management/product planning/company strategy. The developers hanging out here (even those working at Nokia) are the wrong audience for that, sorry.
I can assure you though that the people working here also do care a lot about Qt. There is a concensus here that Qt Quick does make a lot of sense from a purely technical point of view. QML is a requirement for modern, fluid UIs, since it is expressive enough to actually describe those UIs and yet maps to a scene graph that allows for hardware accelerated rendering that is just not possible for the existing QWidgets. If you leave out one or the other you will not end up with a fluid UI. Of course you can come up with all kinds of interfaces for this functionality... but QML is a pretty easy to use one. In my opinion it beats C++ for this use-case hands down.
You are overrating javascript use in QML, too: You can embed javascript into the description of what your interface looks like (and it often makes sense to do that), but you can get by without using of the javascript interpreter in your QML UIs as simple bindings just use the fast path around the interpreter, getting native C++ speed.
PS: You are aware that we have about as many lines of QML in Qt5 as we have python? It is in the less than 2% range of all source code we have (with much of that in the examples and tests). Actually there is less QML code in Qt5 than in Qt4 (using the not very sophisticated "find . -name *.qml -exec cat {} ; | wc -l" as a metric).
-
bq. What do you want to be evolved?
Qt GUI for one, I thought that should be OBVIOUS by now. Unless you didn't bother to read my post.
bq. Which parts of Qt Widgets don’t meet today’s standards?
You ask questions you already answered in your first post, but just to make it easy for you - fluid, modern, touch optimized GUI FOR C++
bq. And how do you do all this without violating sourcecode compatibility?
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.
bq. No I don’t – and I ask you to elaborate.
Well, you said QML is innevitable and then that I don't need to use it and it is optional. Those are contradictory - OPTIONAL and INEVITABLE that is. Common sense 101... If you need further elaboration on this I fear it is kindergarten for you ;)
bq. Outdated? Where?
Already answered by you and me. See above...
bq. Qt Widgets and Qt Quick serve two totally different purposes – that’s what people have to understand. The former one for native legacy applications, the latter one for fluid, non-typical user interfaces.
And where exactly is the C++ API for fluid, non-typical user interfaces? There is none, we have to do it by hand, but then what do we need Qt for, to use as a tool to reinvent the wheel? There are more open, smaller, more flexible and overall better solutions for that. Oh well, by now you are probably starting to scratch the surface of the basis of my disappointment...
bq. Declarative languages are the future of describing rich user interfaces and they do a way better job at doing so than classical programming languages. Why do you think HTML5 is so popular? Why do you think Microsoft is heavily pushing XAML? Why do you think declarative mobile platforms like PhoneGap are so popular?
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++. My vision of the future... is of a future where performance and efficiency are vital. Sure, PHP is very popular, even thou it offers HUNDREDS OF TIMES lower performance, meaning the internet could get away with hundred times less servers, waste hundred times less energy, JS is TENS OF TIMES slower than C++, meaning mobile devices could get better battery life, I tested same game logic in C++ and JS - the C++ version does increase battery life by a considerable amount. The reason the industry does not care about efficiency is simple, it needs to sell more servers, it needs to sell more power, it needs to find excuses to* sell faster hardware just to offset the penalty of using inferior technologies*, and all this we pay for and what is worse, our already exploited planet pays and in term our children will pay.
So, if Microsoft do something as stupid as XAML that means everyone should follow? Microsoft is not doing it because it is better, they do it because they've always been about ENFORCING their proprietary standards in attempts to monopolize the market. If Microsoft jumps of a bridge and tells you this is the future, will you follow?
HTML based syntax is not cleaner, nor easier to read, nor is it faster to write or any of that nonsense. No matter if your UI is modern or legacy, design always starts from the bottom up, which is the old school way of writing code, and the declarative method actually results in less linear workflow, if you are familiar with the way programs are built the declarative is less logical, and it is mostly people FRIGHTENED and unaware of programming that buy and settle for this approach.
The entire industry pushing to convince the world this is the future has nothing to do with this approach being better, I've done HTML + CSS for years, roughly 4 times as long as I've been dealing with C style syntax, initially through ActionScript and then C and C++, and I DO find the latter easier, more intuitive, which combined with the outstanding performance of C/C++ seals the deal, even thou I came from and was used to the declarative way, which only made it harder for me to get into the better way of doing things. I find the declarative way more tedious and uglier, and even thou I agree it MAY BE easier for someone who starts from zero, the extra effort it requires to become adept in coding in C style syntax is WELL WORTH IT, ON SO MANY LEVELS.
bq. Please don’t get mad at me for not commenting your remaining rather pointless Nokia, Elop, Qt rant.
Why did you assume I will get mad? I totally understand you, you are dependent and not supposed to even consider biting the hand that feeds you. I don't have a quarrel with you, you've been nothing but helpful, nor do I have any problem with the trolls, who are just doing what they are told and paid for. My problem lies entirely in that corporate greed and stupidity inspired vision that has been directing the main development force of Qt. It is too bad many people aren't allowed to have an opinion, not if they want to keep their jobs, but that's life for you...
EDIT: I notice you removed "rather pointless" - it is good to see sparks of reason :)
-
As childish and stupid as the concept of "if you don't like is don't use it" may be, that is exactly intend to do, I can't pull millions of dollars out of my pocket to buy Qt so I can change its direction, so I am changing my own direction away from it. It is too bad thou, the world DESERVES a good C++ framework, which is something Qt is no longer aiming for. And even thou I cannot tell for sure if QML was spawned by Nokia or it was conceived back in the days of Trolltech, but I know for sure it appeared about a year after the acquisition. And just a final attempt to make myself clear - I have no problem with QML, I find it quite neat compared to other HTML based ATROCITIES, my problem is it has stolen the development efforts and direction of Qt, making it cumbersome and complex for me to do what I want to do in C++ to the point it is not worth using Qt at all. What for? QPainter? If I have to reinvent the wheel I might just as well do it with a framework that is way more open, flexible and free of the burden of being owned by a corporation like Nokia, which I am boycotting for life for what it did to this wonderful framework.
@Tobias Hunger
bq. QML is a requirement for modern, fluid UIs
That is the whole point, IT WAS MADE A REQUIREMENT without really being a NECESSITY. It can be done with C++, IT IS DONE IN C++. It was a design decision, not a technological limitation, a design decision aiming to enforce a proprietary language that also happens to be slower and less efficient, without even bothering to enable that type of functionality straight from a C++ frontend.
And I don't really have a problem with what Nokia is pushing Qt to become, my problem is it wasn't what I signed for, and the time I've wasted I could have invested in something better.
I really don't get it, how is QML's way of creating a rectangle component with two more rectangles inside better than creating a class that inherits rectangle and has two rectangles in its body? I can tell you how it is different, the latter is compiled and compacted as a amazingly fast to allocate stack object, but how is it that much better? How is importing it and using it in another QML component different from including it and using it for another class?
The difference between declarative and OOP C++ is far too minimal to justify the efficiency and performance penalty, let alone having to learn JS (trivial and applicable) and QML (trivial but not applicable anywhere else) . JS binding is actually slow enough to produce noticeable hiccups in QML applications, and extensive logic requires a rather ugly way of interfacing C++ logic to QML instead of simply using it natively. Everything done in QML can be done in C++, with the support from the back end, animations, states - everything that QML gets exclusively can be done in C++, at the cost of minor coding speed penalty, but with the benefit of increased performance and efficiency. This is the option Qt fails to provide. Or if it is somewhere there, burred deep in the bowels of Qt, no one is rushing to promote it, write example code, for maybe it will put QML back where it belongs, as an optional feature rather than being inevitable...
-
[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++.