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...



  • [quote author="Gerolf" date="1334065772"]Qt is IMHO the best cross platform framework. [/quote]

    Yes, Qt is the best C++ cross platform framework, but IMHO not the best JavaScript framework...



  • 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...


  • Moderators

    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.


  • Moderators

    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++.



  • Thanks for the response. In that case I think you should move to a different framework which solves your problems, Qt isn't for you.


  • Moderators

    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-ZE9Mo

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

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

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

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

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



  • 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++.



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

    So how is this:

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

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

    }@

    immeasurably better than this hypothetical API approach:

    @Item myItem(200,200);

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

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

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

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

    @Item myItem(200,200);

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

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

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

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

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



  • 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".



  • @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++.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.