Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Does Qt need a modern C++ GUI API?



  • @utcenter

    Thank you for this detailed explanation. I appreciate, that you have put a lot of energy into this work - it is almost worth an own wiki page.

    But I do not completely agree with your statements.

    Depending on your application and what you want to do, you always need to choose the right tool.
    If QWidget is better suited for some parts of your application, then you should choose widgets and use QML only for those parts where it is better suited.

    The point that logic cannot always be isolated from the GUI might be true - but you should always try to get a separation between GUI and logic. We developed a quite complex application in Qt with a lot of GUI and lot of backend logic or device control functionality.

    "http://www.cetoni.de/products/microreaction-system-qmix/software.html":http://www.cetoni.de/products/microreaction-system-qmix/software.html

    In this application we achieved a quite good separation between GUI and logic. And I think QML can even help you to improve this design princible of GUI/Logic separation. We used QWidgets for our application. But now more and more customers ask for touchscreen support to control their devices. And I think, we are going to implement this with QML because it is simply better suite IMHO for such an interface. That means, we are going to mix QWidget and QML - we pick the right tool for the right task.

    You always need to connect your GUI with your business logic. If you call it "glue code" for QML it is o.k. but also in C++ you need to write code to connect logic and GUI.

    I do not see the real big differences between defining GUI in a .ui file and in a QML file. You do not need to implement javascript logic in QML and can simply use it as a kind of .ui replacement.



  • [quote author="utcenter" date="1339619270"]BUT then again, there are the kind of applications where GUI is a miniscule part of the total application, a negligible amount compared to the logic. There is a high number of custom UI elements that need to interact with the core logic, but the overall GUI portion of the code is tiny, elements are responsible for their custom drawing. In this case QML helps you save on that INSIGNIFICANT GUI part but adds significant overhead having to interface the SIGNIFICANT component logic to it, so the little benefit if QML is totally displaced MANY TIMES OVER.[/quote]
    Like what?



  • "http://mobilecorner.funkruti.com/2012/06/qt-5-withdraws-support-for-symbian.html":http://mobilecorner.funkruti.com/2012/06/qt-5-withdraws-support-for-symbian.html

    I wonder what platform Qt 5.0 will run on. Find the discussion here regarding Qt as a next gen mobile declarative framework rather amusing, considering the fact that there are no supported platforms.



  • The probably best answer is, although beeing quite unsatisfactory, be patient. There will happen a lot at Nokia within the next months, and I can understand the decision to not risk the possible waste of resources (especially on a platform, which is dead end in pretty much every scenario).

    Windows Phone 8 will have native code support, which will most likely result in Qt beeing available, Samsung will be pushing Tizen, already having a Qt port and Neccessitas will at this point pick up pace again - which means Qt beeing available on almost any smartphone (and tablet and desktop platform) sold.

    Elop is stripping out the family silver wherever possible to fund his highly questionable enterprise policy, but there is still commitment to Qt, which is most probably an indication that it is still a staple in their vision - which is clearly mobile for Nokia. We will know more as soon as either Windows Phone 8 or Meltemi is ready to drive the frequently invoked next billion (the new Asha devices powered by -Symbian- Series40 are just a temporary solution).

    It is a rocky future (especially for Nokia and even more its employees, including those other 10.000 which "just got laid off":http://www.bloomberg.com/news/2012-06-14/nokia-to-cut-10-000-jobs-as-elop-tries-to-stanch-losses.html) but it is for sure premature to turn one's back on Qt.



  • @Lukas

    Hope your words come true. I guess the ' Asha powered by Symbian ' is a typo. Lack of progress in Necessitas has been disappointing. Lack of info regarding Qt4ios also has been disappointing. I hope both of them attains production quality.



  • @Uwe:

    1 -You don't necessarily have to abstract a "different tool" on language level, especially when it is just a data structure description and the language is pretty much irrelevant, it could be QML just as well as it could XML, plain text or whatnot. A "different tool" can just as successfully be abstracted on API level, and indeed, the body of QML is not the language abstraction itself but QtQuick - the API abstraction. That is what this whole thread is all about - that same tool being publicly available natively instead of mandating QML, which is not applicable in all cases. QtGui is "fine", it is what I keep on using, but in that case you completely miss out on everything, done for Qt the last 3 years or so. That is the grand problem - QtGui is flawed by design, as a result, modernizing it is hard and awkward, QtQuick has the right design to enable neat modern features, but it is exclusive to QML without a public native API.

    2 - Separating core from GUI is best practice, and I too follow it and separate those as much as possible, but there are the cases where "as much as possible" is very far from "completely" - my area is Audio/Video/2d/3d/CAD where all elements are two way interactive, it is not just a matter of user doing 1 data input and getting 1 data output after a ton of computations, most elements are not just data representation but alive components that are connected and interact with the entire application.

    Your program looks really nice, it is always nice to see a designer has been employed and there is also aesthetics besides functionality, I am not a big fan of just slapping stock buttons and sliders, which will make an app just as functional, but without a feel to it. From personal experience, QtGui works fine on touch screens, even by sticking to regular events and not making use of explicitly touch events, which are more about pressure and gesture support, and it doesn't look like your application can take use of both. What I mean touch support enough is not enough to justify switching over to QML on its own, but you could just as well do it for the sake of doing it. Perhaps then you will share your impressions on porting it, even thou the application is basically a hardware controller, while I wouldn't call it trivial by no means, it is still far from the scenario where QML becomes a major pain in the lower back area ;)

    3 - you seem to get "glue" in the wrong context. You always need to connect program logic to GUI, just in C++ it all happens on the same level, whereas with QML you have to interface everything to the runtime, so by glue I mean all this stuff you need to do on top of C++, wrapping, importing, proxies and so on. It is not that hard to do for a few components, but when components are numerous and GUI is just a tiny portion of the whole app, you get to the scenario I visually represented in my post, where the little overhead of QML gets multiplied by a much larger number of elements you have to do it for, and the big improvements on GUI implementation multiply by a tiny number:

    "Small QML overhead" * "big number of components" = X
    "Big QML GUI gains" * "small GUI relative to full app" = Y
    X > Y
    or QML overhead is more than QML gains

    4 - I don't really use .ui files or the graphical designer, I do for very basic things, for complex apps I build it in C++. That is the good thing about the old approach, everything is optional, you can do it in C++, you can do it in XML, you can do it with the designer, and worst case scenario is you get a single ui pointer to access the GUI through. With QML you don't have that kind of optionalily, and it is significantly harder to interface logic to GUI, you have to use wrapper classes, you have to export stuff to the runtime, you have to do workarounds for stuff like enums and so on.



  • ..continued...

    bq. Like what?

    Oh my, it is you again, and what a comeback. Again, no offence, but you shouldn't be asking me this question unless you've been living under a rock for the last 20 years :)

    The most significant thing that might happen at Nokia the following next moths is its cheap broke behind gets bought off by Microsoft. And I am not very optimistic that such a move will be of any good to Qt. We all know MS are not too fond of competing frameworks, especially not such with cross platform capabilities, especially not those, which allow TOP TIER HTC and WORKSTATION apps to migrate to other competing platforms, or, GOD FORBID" to FREE open source operating systems. I for one know of a few 5 digit price tag software packages that switched to Qt the last few years, which made MS quite "unhappy".

    I am perfectly sure old Trolltech employees are still very committed to their product, it is not them but those on top of them I am worried about. Nokia was just fine a few years back when it purchased Qt, but today it is pushing to get into the big, warm, cash suffed bed of Microsoft, which could only spell trouble for Qt.

    The last thing I want to see is MS purchasing Nokia's mobile business and Qt being thrown in the deal, it is a common practice to take over competitors to eliminate them and maximize market share. But even if it never comes to this, MS can still "influence" Qt through pressure on Nokia executives, at this point it surely looks like MS has found its open way into Nokia.

    Funny that you mention Neccessitas - as it is a shining example of what community efforts can achieve, only that porting is much easier than creating an API. At this point Neccessitas is not a viable market solution, more of an experiment, like putting roller blades on a horse, you do it for the sake of making it work, but it is a long way from a complete and finished product you can rely on for more than just toying with it. Hopefully Qt5 and QPA will make it easier for Bogdan and that other guy, whose name I forgot, but seeing how Qt5 slips out of schedule is no source of optimism either.

    This whole poll is about not turning our backs on Qt. Turning our backs would be just walk away, that is the WHOLE REASON why people insist on a new native GUI API so they DON"T get chased away, for turning the back on works both way, and the last few years it is Qt that turns its back on its developer base, that is why I feel it is IMPORTANT for Qt to address the needs its developer base voices here, so that neither Qt turns its back on us, nor we are forced to turn our backs on Qt.

    But hey, at least now we have desktop components for QML, the one thing it was designed to help developers break free from
    :D :D :D



  • @utcenter

    bq. it is what I keep on using, but in that case you completely miss out on everything, done for Qt the last 3 years or so. That is the grand problem – QtGui is flawed by design, as a result, modernizing it is hard and awkward, QtQuick has the right design to enable neat modern features, but it is exclusive to QML without a public native API.

    I don't agree. QtGui works perfectly well for the current applications. During development of our quite complex multi plugin "Qt application":http://www.cetoni.de/produkte/mikroreaktionssystem-qmix/software.html we hardly had any problems with QtGui or QWidget and there was nothing we really missed - and if something was missing we could implement it quite fast.

    So what are you really missing from the development of the last 3 years?? QtGui works perfectly well for current desktop applications.

    And for the future user interfaces, there is already a new solution under heavy development: QML.

    I do not see the need for a C++ API for QtQuick. But this does not mean, that I think there should not be a C++ API. Maybe a C++ API will come - you never can tell. But at the moment it is more important to focus manpower on further development of QML desktop components. If QML works perfectly well and desktop components are available than maybe a C++ API will come (although I dont think it is required and that IMHO only a minory of the developers would use it).

    And as a software developer one should always be open to new inventions and new things. If a developer stops to learn new things and stops to be interested in new trends and developments he can quit. And I think QML is e really interesting new trend and it looks really promising - will it be a success - I don't know - will it fail - I don't know. But I'm ready to learn something new - because it is part of my daily job.



  • [quote author="Jayakrishnan.M" date="1339661577"]Hope your words come true. I guess the ' Asha powered by Symbian ' is a typo. Lack of progress in Necessitas has been disappointing. Lack of info regarding Qt4ios also has been disappointing. I hope both of them attains production quality.[/quote]

    Me too. ;-) But there are actually more quite bad news (as far as I can see), escpecially for Meltemi (you've already found the article).

    Yes, it actually is a typo, they are powered by Series40 6th Edition.



  • [quote author="utcenter" date="1339663530"]Again, no offence, but you shouldn't be asking me this question unless you've been living under a rock for the last 20 years.[/quote]
    I've always been told that there is "... significant overhead ..." and a load of "... stuff you need to do on top of C++, wrapping, importing, proxies and so on..." and I've always been asking what this "... stuff ..." actually is and where this "... overhead ..." does come from and how relevant it is for the actual application.

    And even though I've never got a mentionable answer I still keep asking because although creating quite complex applications QtQuick has never required me to add a load of stuff nor did I suffer from significant overhead so far.

    Yes, creating QtQuick items is different from creating a QtWidget - for the simple fact that the scene graph requires a declarative, state-based drawing model instead of the imperative drawing model we know from QtWidgets and the Graphics View Framework (which is also still available using QQuickPaintedItem). This is nothing a native interface would change.

    But I'm quite sure you have some examples, code snippets, use cases, benchmarks or anything, which visualizes or materializes the significant overhead and the load of additional work, for me, do you?

    Please don't get me wrong, I'm not beeing a drag here. I'm just in search of something I can actually look at to understand the worries (and to re-evaluate my perception if neccessary).



  • @Uwe - no one argues about how well QtGui works, as I said it myself, it is still what I use. The problem of QtGui is not with its functional aspects, but its fundamental design, which makes it less-than-optimal to create modern GUI. It is still possible, you have multi-touch, you have states, you have animation, it is just harder to work with it because it QtGui wasn't conceived with those things in mind and designed around them.

    You keep insisting that developers who want a C++ API are a minority and efforts are rightfully focus almost entirely on QML, but this doesn't really fit with the opinions, voiced by the Qt developer base here in this thread. I am sure there are plenty who call for a C++ API for the wrong reasons, but there are also quite many who really see the fundamental design flaws of QML and its inapplicability in many development scenarios. You act as if QML is the best thing since sliced bread, but it isn't, and it is far from addressing all development scenarios. There are too many people for whom QML is unattractive, and focusing the development efforts of Qt entirely on QML is literally turning the back on those people. People like me are in a suboptimal situation whether we go for QML and deal with its overheads or stay with QtGui and deal with its fundamental design flaws.

    @Lukas - I am not talking about performance overhead, that would be critical on mobile platforms, which QML doesn't seem to support any time soon, at least not the major ones. On the desktop the performance overhead is negligible. I am talking development overhead, where you have to wrap and export every program component to QML, something you don't have to do with QtGui. And again, it is not hard to do once or twice or even 10 times, but as the number of such elements increases so does the overall overhead, to the point it becomes more prominent than the savings you get from using those components in QML. Gosh, it is not that hard of a concept, why is it so hard to wrap your mind around it? It is an overhead that cannot be demonstrated with a code snippet, I am sure you know the workflow of interfacing native components to QML, the overhead is in doing it over and over again. It is not an issue of complexity that can be indicated in a code snippet, it is the total instances of snippets like that you don't really need but have to do in order to take advantage of modern GUI features absent from QtGui.



  • ====================== C++11 version =================
    @#include <QtQuick2>

    class OuterRect : Rectangle {
    struct InnerRect : Rectangle {
    MouseArea mouser;
    slist<State> states;

        InnerRect(Rectangle *parent)
          : Rectangle(100,100),
            mouser(this)
        {
            colorChanged().connect(&ColorAnimation);
    
            anchors().centerIn(parent);
            mouser.anchors().fill(this);
            mouser.hover_enabled(true);
    
            states =
            {
                { "GreenState", mouser.containsMouse, { this.color, "green" } },
                { "RedState",  unary_negate(mouser.containsMouse), { this.color, "red" } }
            };
       }
    } coloredRect ;
    
    OuterRect() : coloredRect(this), Rectangle(400, 400) {}
    

    };@

    Quoting c++freeloader....
    Simply beautiful



  • [quote author="utcenter" date="1339668714"]I am sure you know the workflow of interfacing native components to QML.[/quote]Yes, I do.

    [quote author="utcenter" date="1339668714"][... and you know] the overhead is in doing it over and over again.[/quote]No, I don't, and that's why I'm having such a hard time to "... wrap [my] mind around it.", because for me there wasn't and I have not seen any evidence yet - and you obviously can't provide either - that there is for others. It is contradictory to my personal experience and I'm not able to relate it with the information you provide.

    Please take another look at the "documentation":http://doc.qt.nokia.com/4.7-snapshot/qml-extending.html or one of the examples on how interfacing QML and C++ actually works. In most cases it is as simple as a call to "qmlRegisterType<>()":http://doc.qt.nokia.com/4.7-snapshot/qdeclarativeengine.html#qmlRegisterType and in any case there is no additional effort in comparison to a native interface.

    It is a prejudice and does not reflect reality.



  • So you expect of me to convert an entire application to QML and expose my commercial code just for the sake of showing you the code increase and design changes QML demands? And sadly, in most of the cases it goes beyond qmlRegisterType. You seem to have missed the many instances I explicitly stated it is nothing hard, just tedious to do over and over again.

    Let me assure, I am quite aware of the reality of extending QML in C++ and not prejudiced even a tiny bit.

    Lets just agree to disagree, we both know the direction of your attempts of discreditation, the more people in favor of a new native API you "prove" prejudiced, clueless, biased or whatnot, the more you undermine the validity of this poll.

    It is funny thou, since I recall you saying you too want a native GUI API, and yet you spend so much effort to convince me QML is so good and effortless to use no one really needs a native GUI API. It is even more absurd than justifying QML as an attempt to escape the bore of standard desktop components, and then launch QML desktop components.



  • [quote author="utcenter" date="1339676069"]So you expect of me to convert an entire application to QML and expose my commercial code just for the sake of showing you the code increase and design changes QML demands? [... ] you spend so much effort to convince me QML is so good and effortless to use no one really needs a native GUI API.[/quote]No, I don't. I just ask you to provide proof for the accusations you've made.



  • Accusations? What accusations? I don't recall accusing anyone of anything...

    Does the interfacing of native classes to QML require extra code? It does! Now take a chill pill ;)

    And it is rather naive from you to point to those tiny, trivial, simple examples, written for basic educational purposes as they are the reality of practical application code.



  • So you can't?



  • I don't think there is any point of trying to prove the obvious to you any more, this is about as productive as arguing with a wall, so whatever you say, you are the weener :)



  • Obviously.



  • [quote author="utcenter" date="1339682641"]... you are the weener :)[/quote]

    [quote author="Lukas Geyer" date="1339682881"]Obviously.[/quote]

    I am glad we are finally in agreement about something :D Now let's move on!



  • Come on guys! Let's keep it up... we need something new... We always need something new.



  • I have never used QML and I do not have plans to use it. IMHO it's interesting for beginners who are doing simple projects. But, at least it will be a easy door for beginners to enter into Qt. This door has benefits and the costs for this benefits should be balanced. That's the fact.


  • Moderators

    You loose a lot by having this attitude ;) QML is a really nice tool, it's not a monster and is unlikely to eat you.

    Anyway, you can do as you wish, of course. I mean to hint at the fact that perception about QML tends to change rapidly once one actually tries it, or at it has in my case.



  • @sierdzio : I'm sure that I loose a lot by having this attitude. I did not mean that I'm disagree with existence of QML or using it. It does not fit with projects I'm working on or I have worked on. My wings are much more powerful with C++ API at this time. This is about how you think. As I said, many people are happy with QML and this is enough to let it be there and improve it. This is a dynamic world.
    I will try using it as you said it may change my opinion about it.


  • Moderators

    Yeah I kind of suspected that this is what you mean, and I've meant no harm :)

    Just couldn't stop myself, sorry.



  • [quote author="cincirin" date="1334815916"]I believe Apple Animation Framework is what Qt C++ GUI have to follow[/quote]

    That could have been my words. Like Apple or not but the iOS GUI is the best prove of a smooth working UI that can be coded natively. Besides that it would bring native looking buttons etc. (in the world of the Cupertino fruit there is something like a native looking widget)



  • [quote author="hardcodes.de" date="1353420894"]
    [quote author="cincirin" date="1334815916"]I believe Apple Animation Framework is what Qt C++ GUI have to follow[/quote]

    That could have been my words. Like Apple or not but the iOS GUI is the best prove of a smooth working UI that can be coded natively. Besides that it would bring native looking buttons etc. (in the world of the Cupertino fruit there is something like a native looking widget)

    [/quote]

    I agree with these. For ios development we have the ability to visually design the UIs and access them in the application and apply any effects or animation. A declarative framework is not needed here. I feel GUI should always be done using a visual designer unless you need your GUI to be dynamically generated based on some application parameters. The underlying code generated can be xml, qml, c++ or anything. Both ios and Android uses xml. But ios hides this behind the interface builder. Hand creating a GUI is tedious whether you are using Qml or c++. The ios approach seems the best. We have a lot of trouble writing complex GUI for Android since we have to hand create all the needed xml. Same is the case with Qml. A visual designer for Qml together with the ability to access these components from c++ is the best approach. In my experience, Qml is tough for the html people and something alien for the c++ folks.



  • [quote author="Jayakrishnan.M" date="1353471883"]A visual designer for Qml together with the ability to access these components from c++ is the best approach.[/quote]"Using the QtQuick Designer":http://doc.qt.digia.com/qtcreator/creator-using-qt-quick-designer.html

    "Using QML in C++ Applications":http://doc.qt.digia.com/qt/qtbinding.html
    [quote author="sierdzio" date="1353412782"]I mean to hint at the fact that perception about QML tends to change rapidly once one actually tries it...[/quote]



  • I recently started using QML, I'm really newbie. I like it but I also agree that it's much more powerfull to use the designer. The problem it that designer seems to be somewhat broken.
    Another problem to me it we have Meego components, symbian components, (and also desktop components ???), but if I choose a new general QML project in QtCreator, the available components don't even have a button, I have to do it myself. Souldn't not be avalible many more cross plataform components (code once deploy everywhere) ? Am I missing something ?


  • Moderators

    [quote author="john_god" date="1353499489"]I recently started using QML, I'm really newbie. I like it but I also agree that it's much more powerfull to use the designer. The problem it that designer seems to be somewhat broken.
    Another problem to me it we have Meego components, symbian components, (and also desktop components ???), but if I choose a new general QML project in QtCreator, the available components don't even have a button, I have to do it myself. Souldn't not be avalible many more cross plataform components (code once deploy everywhere) ? Am I missing something ?[/quote]

    You are right, of course. Those elements are missing due to many reasons, mostly due to the long and dramatic death of Nokia support. Now Digia has a huge amount of work on their hands, and a lot of it is more important than components at the moment. I don't know where it will go in the future.

    Maybe setting up a new playground project with the aim of adding new cross platform components is the way to go. maybe waiting for desktop components maturity is better... I don't know.



  • Another issue to me is the documentation. I already found some good links, but I miss a good QML book. Until now it was perhaps to early, but in the following months, with the final release of Qt5 and QtQuick 2, I think it's time for a book. I even filled a request to packet publish, since those guys are open to sugestions.



  • You only find the designed better because you are new, I can assure you, in time you will really get to prefer typing and leave the visual workflow for where it belongs - Photoshop.

    The lack of in depth educational materials on QML is a big concern, like 90% of the stuff that is already available boils down to putting together something simple to demonstrate the eye candy features of QtQuick. And even thou every tool of QML is being explained, there is a HUGE gap between knowing what tools are used for and actually putting together something complex and functional with those tools.

    Unfortunately, the biggest flaw of QML for me will not go away ever - with the risk of repeating myself, QML is great for quickly assembling existing components into an application, but if your applications depend entirely on custom and unique components, the interfacing to QML becomes a tedious and pointless endeavor. In most of the cases the interfacing components to QML in order to use its GUI features takes up more effort than implementing similar GUI features with QtGui and OpenGL on hand, which is the reason for this discussion.

    Unfortunately, neither Nokia, nor Digia seem to have respect for the opinions of the people who voted here. That is the reason I migrated most of my work away from Qt, so the last few months I bothered to learn a few JS frameworks in depth, and I dare say QML comes nowhere near the flexibility and dynamics of the HTML/JS stack. Surely, QML is much cleaner, but offers poor separation and only a fraction of the functionality. It is ironic how the main bullet point of QML is "dynamic" GUI when in reality QML is practically static compared to using something like jQuery, which allows to build UI in a procedural and imperative way, which is IMMENSELY more flexible than having a static mark up. I often find myself starting off with practically no HTML markup, just a div to which I can attach whatever content I want dynamically, with whatever styling or animation.

    And while flexible and dynamic, HTML/JS comes short of all the stuff I need, for which I am sticking to Qt with the good old QtGui, since essentially all the scenarios HTML comes short are also the scenarios where QML is useless. Hopefully we will at least see Android and iOS support soon which will surely breathe some life into Qt.



  • my opinion , every thing z possible with Qt c++



  • Ironically, Digia pledged to support Win8 and iOS while at the same time the first one lacks openGL in metro mode, the second one prohibits V8 from running. And while the Win8 dilemma can be solved by adding even more bloat and dependency by using ANGLE to translate openGL calls into Direct3D, it is obvious that forcing Qt to lean on QML spells more and more trouble, and even worse - exhausting to much developer efforts...


  • Moderators

    [quote author="utcenter" date="1355679123"]Ironically, Digia pledged to support Win8 and iOS while at the same time the first one lacks openGL in metro mode, the second one prohibits V8 from running. And while the Win8 dilemma can be solved by adding even more bloat and dependency by using ANGLE to translate openGL calls into Direct3D, it is obvious that forcing Qt to lean on QML spells more and more trouble, and even worse - exhausting to much developer efforts...[/quote]

    Both problems you have listed are already worked upon. ANGLE is default backend on Windows since Qt5 beta1. V8 problem is addressed by v4mv that is under development currently.

    Besides, QtWidgets are now back on track with official maintainer.



  • [quote author="sierdzio" date="1355691692"]
    Besides, QtWidgets are now back on track with official maintainer.[/quote]

    Back on track? Which track? Going where exactly? Oblivion?
    Maintenance of QtWidgets doesn't change the fact it is morally and technically outdated and no longer relevant.

    BTW, there is really no need to quote the entire post you are replying to, considering it is the previous one. But then again, if you were that concerned with abstract aesthetics, you wouldn't be such a QML cheerleader ;)



  • V8 "does work":http://lists.qt-project.org/pipermail/development/2012-December/008718.html on iOS.

    What has the OpenGL requirement of the scenegraph to do with QML? (Nothing.)
    How would a native, non-QML interface change that requirement? (It wouldn't.)

    Why is it Digias or the Qt Projects fault that Microsoft has made the deliberate choice to leave the industry standard for hardware acceleration out? (It isn't.)



  • Why you ask me questions and then you answer instead of me? And no, I won't answer for you, I am not all that manipulative ;)

    Care to point out where exactly did I state that V8 can't work on iOS? IIRC I used the term "prohibit"... Sure, you can jailbreak, but then your application no longer classifies as "legit" in the eyes of Apple. Also, last time I checked, jailbreaking voids product warranty. Apple don't want any execution engines on their platform for security purposes, and a NATIVE API could have plaid a wonderful role here, because it would compile to platform binary, which Apple don't mind being executed on their platforms.

    bq. What has the OpenGL requirement of the scenegraph to do with QML?(Nothing.)

    QML is an exclusive frontend to using QtQuick2, which is OpenGL dependent. The relation between OpenGL requirements and QML is obvious enough for a blind man to see!

    bq. How would a native, non-QML interface change that requirement? (It wouldn’t.)

    It depends a lot, a more flexible API could just as well include a fallback for rendering in software, which is not that much of an issue on powerful desktops. This way the same code would be able to run optimally depending on the capabilities of any particular platform.

    bq.
    Why is it Digias or the Qt Projects fault that Microsoft has made the deliberate choice to leave the industry standard for hardware acceleration out? (It isn’t.)

    No one argues that MS sucks. The whole point of this "discussion" is to prevent Qt from behaving in a similar manner. Neither Nokia, nor Digia is to blame for the decision of MS to abandon a portable industry standard in favor of their own proprietary technology, but Nokia and Digia are to blame for abandoning another portable industry standard in favor of their own proprietary technology (got to love the hypocrisy of this), I mean of course scrapping a public C++ API in favor of an exclusive QML one. And while MS surely has the downside when it comes to portability, at least its proprietary technology is more capable, more feature rich and offers public native APIs.

    See now Lucas - reality extends far beyond your personal conceptual limitations. For some reason you seem to have a huge problem abstracting from your bias and perceiving the matter objectively.



  • [quote author="utcenter" date="1355835060"]Sure, you can jailbreak, but then your application no longer classifies as "legit" in the eyes of Apple. Also, last time I checked, jailbreaking voids product warranty.[/quote]V8 on iOS does neither require a jailbreak in principle, nor does it violate the App Store Terms and Conditions.

    The jailbreak is currently required because the used RWX memory allocation scheme is not supported on iOS, but the replacement RW/RX is, which also abolishes the jailbreak requirement.

    Apple further on does not prohibit execution engines like V8. The only requirement is that if the origin of the to-executed code is the internet the code has to be interpreted using Apples own execution engine. This does not affect local code and it does not affect QML applications.

    [quote author="utcenter" date="1355835060"]QML is an exclusive frontend to using QtQuick2, which is OpenGL dependent. The relation between OpenGL requirements and QML is obvious enough for a blind man to see![/quote]Again, OpenGL is a requirement of the scenegraph, not QML.

    A car requires fuel. A car is controlled using a steering wheel. So a steering wheel requires fuel?

    QtQuick without QML will still depend on OpenGL. A fully native C++ interface will still depend on OpenGL.

    The principal reason for the performance advantage of QtQuick over QPainter and the Graphics View Framework is the state-based, hardware-accelerated OpenGL-based drawing model, called the scenegraph, which is an absolute technical requirement of graphics hardware.

    Qt already offers an imperative software- (QPainter) and hardware- (Graphics View Framework) rasterizer. There is no point in creating another.

    In addition, the scenegraph requires OpenGL, not hardware-acceleration. It works with any software rasterizer like llvm-pipe in case there is no or limited hardware-acceleration available.

    But feel free to share your vision of a hardware-accelerated, platform-independent, high-performance drawing backend (which is obviously not QPainter nor The Graphics View Framwork).

    I would love to see my personal conceptual limitations extended.



  • So is there any other API to use the scenegraph in Qt other than QtQuick2, which depends on OpenGL and is exclusive to QML? No? thought so...

    bq. What has the OpenGL requirement of the scenegraph to do with QML?(Nothing.)

    Leaving QML to be the sole actively developed GUI API mandates the OpenGL requirement. Please don't tell me you still fail to see what is obvious and quite simple. QML is being made a requirement, QML requires QtQuick2, QtQuick2 requires the scenegraph, the scenegraph requires OpenGL. I think about 2 working brain cells outta be enough to figure out how the dependency propagates.

    My idea was of implementing a low level graphics API that is backward compatible with a software rasterizer, while stile being able to make use of OpenGL hardware when present. This API itself can be ported directly to DirectX as well, making the entire process transparent, without the need of translators and emulators. QPainter already supports hardware accelerated OpenGL drawing and caching, and the performance is as good as that of QtQuick2, it is just that the process is tedious since a lot of the stuff done for you in QtQuick you have to do manually. All this threat is asking for is a native API that handles all that stuff without forcing QML.

    No one can force the expansion of your horizon against your own unwillingness to do so.


Log in to reply