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?



  • @c++freeloader

    And Panasonic Avionics make an inflight entertainment system using QML that is used by 100 airlines serving 5 million passengers per day: http://www.youtube.com/watch?v=SfyptGmX93U



  • [quote author="capisce" date="1335553426"]bq. If you can point to anybody else who uses QML, then I might put some stock into what you’re saying.

    French Telecommunications company Free uses QML on their quite successful Freebox:

    http://qt-project.org/videos/watch/qt-and-qt-quick-on-the-freebox-player-set-top-box

    RIM exposes a QML API together with its Cascades UI engine:

    http://nerd.web.id/index.php/2012/03/22/playbook-tat-cascades-on-mobiletechcon-munich/[/quote]

    I'll have to take a look at the Cascades UI engine. Could be interesting.

    With regards to the Panasonic one, I thought it was clear that I was talking about using QML as their own framework interface language, but I guess I wasn't explicit. He was talking about just how open and available QML is for the rest of the world to use. And what I should have said is "show me who else is using QML as their language for specifying UI's". Not just using QML to interface to the Qt engine.



  • [quote author="capisce" date="1335553426"]

    RIM exposes a QML API together with its Cascades UI engine:

    http://nerd.web.id/index.php/2012/03/22/playbook-tat-cascades-on-mobiletechcon-munich/[/quote]

    This actually looks nice. Ironically, those fellas must not be that keen on QML, since, if my eyes do not deceive me, they have chosen XML syntax instead. And furthermore, this only makes the need of a C++ API with similar capabilities even more desirable, as again, QML does not enable this kind of UI, it just describes it, the reason there isn't a similar out of the box UI API for C++ is... well, no one bothered to make it.

    Also - all those showcases you are pimping are the product of scores of developers and companies with plenty of cash, who do have the manpower and resources to extend QML, it is a completely different story than single developers or smaller groups, where the avoidance of compartmentalization is a very good thing.

    I still haven't seen one solid argument of WHY should QML be a necessity, the closest thing was the runtime binding, an easy analogue of which can be achieved as simple as overloading a virtual method of the root object.

    @c++freeloader - my impression that sharing any type of thoughts here will never go beyond chit-chat has been reaffirmed so many times, I really don't want to bother. I've already started looking in other directions and setting the blueprint for a cross platform API, I've already got the core backbone, display, input and event loop running on win, mac, linux, ios and android, now I am torturing myself with graphics, progress is slow but at least it has a chance to manifest (better late than never). I actually plan to make the process of building the framework as C++ programming video tutorials, knowing how the framework will make it easier for people to use, that's why I try to keep the code simple, unlike the mess that Qt (and many other) private backend APIs are. When I get its basic APIs running I will expose the framework, hopefully there will be interest and more people will join in the development, so we can have a complete and truly open solution with no corporate interest behind the wheel. It will take time thou, since I am alone and develop only in my spare time, having a full time job and all..



  • bq. Ironically, those fellas must not be that keen on QML, since, if my eyes do not deceive me, they have chosen XML syntax instead.

    Nope, that video was from before TAT were acquired by RIM, so they must have adopted QML since then.



  • @temp

    Have you looked at making your API on top of QQuickItem and QSGNode which are public API and give you access to the raw power of the scene graph from C++, which earlier seemed to be the main thing you desired?



  • @c++freeloader

    How about you write a C++ equivalent of some real-life application QML code, and we can compare the merits of that code to the QML code? I would suggest this QML code, as it's quite idiomatic and exemplary, and yet not absurdly trivial: https://qt.gitorious.org/qt-labs/meespot/blobs/master/qml/AdvancedTextField.qml



  • [quote author="capisce" date="1335560638"]@temp

    Have you looked at making your API on top of QQuickItem and QSGNode which are public API and give you access to the raw power of the scene graph from C++, which earlier seemed to be the main thing you desired?[/quote]

    Desired not as a final goal but a direction of development focus... but yes, however it seems a little backward, if you know what I mean. I feel like I will have an easier time tapping into OpenGL benefits from scratch than conforming Qt's APIs to my vision. I've already got some sweet results with SDL and Cairo, now trying to integrate an OpenGL accelerated painter. Shader drawing is just too fast to skip it, and it is interesting too, I never really worked with low level OpenGL until now.

    From my Flash days I really find the design and workflow paradigms behind Flash truly awesome, the only thing wrong with Flash is ActionScript, although it is still relatively close to C style performance is just awful. And all those "let's make it easier than C++" ideas that don't really deliver, like instead of "string name" you have to do it "var name:string" - and numerous other small nonsenses. So my idea is to do a "Flash done right" with declarative stage items, some additions and native C++, running in browser is simply not worth 10 times performance penalty, especially if the framework supports all major platforms natively.



  • @temp Ok then, best of luck, never hurts to experiment with new approaches :)



  • [quote author="temp" date="1335559794"]
    I still haven't seen one solid argument of WHY should QML be a necessity[/quote]

    The only argument: Nokia has made a modern mobil UI.
    But!
    The majority of QT users use the Qt only for multiplatform C++ desktop framework.



  • @capsice

    I went through the exercise of figuring out how to do the one-to-one mapping of QML to C++ for the example you asked me to look at. I repeat the example code first and then follow it with the C++ version. Before I do that, however, I wanted to make a few other comments...

    As I went through this exercise a lot of questions came up as to when exactly the bound properties are read and how they exactly are updated under the hood. In looking at qquickitem.cpp and qquickrectangle_p.h and qquickrectangle_p_p.h, I now understand some of the other points that temp/Dian was trying to make. One point is that it is very difficult for an outsider to make any sense out of the QtQuick internals without having some baseline understanding of how everything works together. For the hour I spent browsing through the code, I still really don't have a clue as to , how the scenegraph backend is populated, how updates are done, when a property changes, how does the change get propagated to the backend, etc. Unless this stuff is documented on some level that is sufficient for an outsider to come in and understand how things work, I don't think it is possible for a "real" C++ API to be done by anybody other than the current QtQuick devs.

    The second point that temp/Dian had made was that there is probably much cleaner ways of implementing the intended effect of "binding". That is, the intended effect of "binding" is that when some aspect of one element changes, it should impact another aspect in some functionally specified way.

    Because I was clueless about the internal operations, I chose to look at the problem for now in a way that mirrors QML, where binds truely do update automatically. This is kind of like taking a sledgehammer to a problem requiring a regular hammer, but since I didn't have visibility into the QtQuick internals, it's what I chose to do for this example. I believe now, as Dian/temp had said, that there are very likely much cleaner ways to solve the problem if you look at the whole problem wholistically and design the underlying structures with the idea of having a C++ user API.

    With that being said, let me first talk about the approach I took. Fundamentally, there's nothing in the QML declarative description except for binds that can't be easily mirrored in C++ in a straightforward way. The binds are a bit different. I considered two ways to mirror binds in C++. One, was something called "expression templates" (google it if you don't know what it is) and the second was C++11 lambda functions (although you can use any function object and not just lambdas). Although expression templates would have allowed for cleaner and easier to use binds, I decided to go with lambdas for this exercise. The reason I chose this was because lambdas (and function objects in general) can be just about anything that the user desires and they are directly supported in the language. Whereas for expression templates, I would have had to create some intricate libraries and these expression templates would only support the kinds of expressions I had the forsight to allow for.

    Lambdas essentially allow you to create arbitrary functions to "bind" to a property. That is, instead of a value, a property can be a lambda function. Morever, you can embed this lambda function inside a "Property" object so that every time you access the object, you basically evaluate the function instead. But you still run into the problem of when to evaluate the lambda. Because I didn't really know how or when the property values are used in the backend code, I assumed, for the time being, that the backend should be notified whenever a property may be changed. That is, whenever the state of the property is "invalidated". Whenever a property is invalidated, then the backend can access the property again, thereby evaluating the underlying lambda function, and get back the "new" value of the function.

    But in order to know when to re-evaluate the lambda, you have to know something about the functional dependencies of the lamda. For example, say you have a lambda like: &{return a+b;}, then you would want to re-evaluate the lamda whenever a or b have possibly changed. The problem is that for any arbitrary lambda, the compiler doesn't tell you what the functional dependencies are. The only way I'm aware of is for the user to supply the dependencies. And so this is the method I chose. To avoid the 6000 word limit, in the next post I will put the code that I wrote to support lambda-based properties with dependencies.



  • Below is the code that implements lambda-based Properties. After the definition of the Property<T> template, I have included an example "Rectangle" class that uses this Property<T> template. From this you can see the bind of the area is defined usinga lambda. Then, below that, I have a main program that uses an instance of the Rectangle and connects various signals so that you can see the effect of changing the width or height of the rectangle and that the area is recomputed whenever either width or height is changed.

    I used gcc-4.7 to compile this:
    g++ -std=c++11 -I$HOME/tools/boost/include -o dprop main.cpp
    Since I transcribed this manually (don't ask...), I hope I didn't make too many typos.

    @
    #include <iostream>
    #include <functional>
    #include <boost/signals2.hpp>

    using std::cout;
    using std::endl;
    using std::function;
    using namespace boost::signals2;

    template<typename T>
    class Property
    {
    public:
    // Signals are based on boost::signals2 library
    // This signal only is emitted only when the functor is evaluated and
    // the actual value of the property has changed.
    signal<void ()> changed;

    // This signal is emitted whenever the value of the property “might” be 
    // changed.  It indicates that the property should be accessed again to
    // get its updated value.
    signal<void ()> invalidated;
    
    // Basic constructor takes a functor as an argument to “bind” to the property
    Property(function<T()> evalFn)
    : m_prevValue()
    , m_evalFn(evalFn)
    , m_valid(false)
    { evaluate(); }
    
    // A constant value is translated to an lambda that returns that constant value
    // and then the above constructor is called.  Calling a different constructor is a
    // C++11 feature.
    Property(const T & value)
    : Property([=](){ return value; })
    { }
    
    // This takes an eval function and also an arbitrary list of Properties on which the
    // eval function depends.  This is using the C++ variadic template feature.  (notice the …)
    template<typename... Deps>
    Property(function<T()> evalFn, Deps &...deps)
    : Property(evalFn)
    {
        addDependencies(deps...);
    }
    
    // If this Property is already invalidated don’t do anything.  Otherwise, set it to
    // not valid and emit the invalidated signal to propagate to all dependent properties.
    void invalidate() const {
        if (!m_valid)
            return;
        m_valid = false;
        invalidated();
    }
    
    // The variadic template base-case.
    // Connect the invalidated signal in the antecedent property to this
    // property’s invalidate function.
    Property & addDependencies(Property<T> &p) {
        p.invalidated.connect([this](){this->invalidate();});
    }
    
    // The variadic template recursive case
    template<typename P, typename... Deps>
    Property & addDependencies(P &dep, Deps &... deps) {
        addDependencies(dep);
        addDependencies(deps...);
    }
    
    // So that you can write:  x = [](){ return foo; };
    Property & operator=(function<T()> evalFn) {
        m_evalFn = evalFn;
        invalidate();
        return *this;
    }
    
    // So that you can write: x = 234;
    Property & operator=(const T &value) { return *this = [=](){return value;}; }
    
    // if necessary, evaluate the function object and if it is different than
    // before, emit the changed signal and return true.  If the newly evaluated
    // value is the same as before, do not emit invalidated signal and instead return false.
    bool evaluate() {
        if (m_valid)
            return false;
    
        m_valid = true;
        T newValue = m_evalFn();
        if (!(newValue==m_prevValue)) {
            std::swap(newValue,m_prevValue);
            changed();
            return true;
        }
        return false;
    }
    
    // conversion function so that you can access the property like a value.
    // e.g. :   cout << x << endl;
    operator T() const {
        evaluate();
        return m_prevValue;
    }
    

    private:
    mutable T m_prevValue;
    function<T()> m_evalFn;
    mutable bool m_valid;
    };

    // Example Rectangle defined using Property<T> where the area Property is
    // bound using a lambda. Notice that the dependencies are width and height
    // properties.
    struct Rectangle
    {
    Property<int> width;
    Property<int> height;
    Property<int> area;

    Rectangle(int w, int h)
    : width(w)
    , height(h)
    , area([=](){return width*height;}, width, height )
    { }
    

    };

    // Example main program using the above Rectangle.
    int main()
    {
    Rectangle r(100,200);

    r.area.changed.connect([](){ cout<<"area changed"<<endl; });
    r.width.changed.connect([](){ cout<<"width changed"<<endl; });
    r.height.changed.connect([](){ cout<<"height changed"<<endl; });
    
    r.area.invalidated.connect( [&r]() {
        cout << "width="&lt;&lt;r.width&lt;&lt;" height="&lt;&lt;r.height&lt;&lt;" area="&lt;&lt;r.area&lt;&lt;endl;
    });
    
    cout &lt;&lt; "width="&lt;&lt;r.width&lt;&lt;" height="&lt;&lt;r.height&lt;&lt;" area="&lt;&lt;r.area&lt;&lt;endl;
    
    cout &lt;&lt; "changing width" <<endl;
    r.width = 50;
    
    cout << "changing height" <<endl;
    r.height = 100;
    

    }
    @

    Since it is getting late here, I will post the QML and equivalent C++ code tomorrow.



  • bq. As I went through this exercise a lot of questions came up as to when exactly the bound properties are read and how they exactly are updated under the hood.

    The bound properties must be QObject properties, declared with the Q_PROPERTY macro in C++, which means they typically have a getter, and usually also a setter and a getter if they're mutable. The Q_PROPERTY declaration makes Qt's meta object system aware of the properties, so that they among other can be found with a string lookup. Here's an example Q_PROPERTY statement from QQuickRectangle:

    Q_PROPERTY(QColor color READ color WRITE setColor NOTIFY colorChanged)

    So when the QML binding like "x: parent.width / 2 - width / 2" is parsed, connections are automatically made to the properties' changed signals. The source properties for the binding are thus read first at the time the binding is first evaluated, and then whenever the change signal for one of the properties changes. One awesome feature of Qt signal / slot connections is that they work across threads, so you could have a C++ worker object in a separate thread exposed to QML, doing heavy computations in an asynchronous manner without interrupting the UI.

    The connections are also automatically disconnected when either the receiving or sending object is destroyed. Whenever a property change leads to a visual change in a quick item it calls update() to signal to the quick canvas that it is dirty and thus the corresponding scene graph node / nodes might need updating before the next frame is rendered. The call to update() happens automatically in the backend (though you might need to call it manually if you implement a custom quick item).

    Properties declared in QML automatically get the corresponding changed signal. Here's some more information on QML properties: http://doc.qt.nokia.com/qt5/qml-properties.html

    I have to say your property binding system for C++ looks quite promising, gotta love C++11 lambdas. For the best interoperability with Qt I'd love to see it support Qt properties and signals though :)



  • Resources are usually finite and more often than not there's more than one solution to a single problem. It is therefore all the more important to select that solution, which provides the most benefit (usability, maintainability, future-proofness and performance) to the majority of people. Such a selection has to be the result of an objective discussion, and everyone involved in this decision process is heavily interested in all the different opinions - because two heads are better than one.

    But there are three fundamental requirements for such a discussion:

    • a common basic knowledge (what),
    • a reasonable argument (why) and
    • a feasible alternative (how).

    And since the beginning of the public discussion about QtQuick and more specifically QML vs C++ I see a serious lack of all of the three, mostly at the end of the native proponents. An expectation needs not to be a fact, an opinion is not an argument, the loudest voice needs not to be the most important one and a "No" is absolutely worthless, if it isn't followed by "because".

    So I compiled this list of popular misunderstandings so that we have a common basic knowledge we can base our discussion on. And the best things is - you do not even have to believe what's written there; Qt is open source, the Qt Labs explain almost everything, the mailing lists are ready for providing information and in the end you could just try it on your own, dissect, benchmark and profile it and gain your own experience.

    And again, everyone is heavily interested in an objective discussion, your opinion and your worries on this topic, even me, and even if the result is that the current solution selected for QtQuick was not the most benefitial. But the discussion is rather pointless as long as we talk about two different things.

    I know that many native proponents feel unheared, but as long as there is denial and prejudice, as long as statements start with "We all know" and "I think" instead of "We have proof, that", as long as people who use and take their advantage of QML (and there are actually a lot of it) are defamed of beeing "fanboys", conspirators or victims of conspirators, who have no clue about C++ and fall for fallacies and the only reason they actually use QML is because they must be some kind of dumb and they are "not right in their mind", as long as people cry for facts and numbers, just to devalue them as "gibberish" while at the same time providing none, as long as there is aggression instead of creativity and as long as people keep rehashing the same disproven resentments over and over again they will stay mostly unheared because time is precious - too precious for a pointless skirmish.

    We have evaluated (and we are activly using) QtQuick and we have found out that when done properly it scales better than our native interface implementations because we can focus on describing the interface and we can delegate the implementation to the QtQuick runtime, whose additional one-time cost turned out to be minuscule and irrelevant for our applications. The same way it is irrelevant for the SceneGraph if it was built from the QtQuick runtime or from native code.

    In spite of that QML is far from dominating our applications. Quite contrary to, most of the code is still C++ - although we wish we could have done more code in QML, because it allowed us to achieve the same goal using less code and less time. QML is "real value" (and real money) for us - and from what I've heared not only for us. There are thousands of threads just here at the QtDN in the QtQuick forums - this doesn't seem like "no one in there right mind is using it".

    I'm quite sure you can elaborate on that -we know- you think that a native implementation would be monotonically more performant.

    And even at the cost of repeating myself - we could have done the same thing in pure C++ using the already available native SceneGraph API, the Animation Framework and Statemachine Framework. The ramp-up time for QML was quite short as almost any developer was already familiar with JSON and JavaScript, two of the most used data-interchange and scripting languages.

    If you don't want to evaluate QtQuick on your own you might take a look at the large-scale projects already available, like the ones mentioned by capisce or KDE, the QtMediaHub and the N9 (which is by the way Nokias best-selling, best-rated smartphone, altough beeing deliberatily held back for political reasons; it has sold millions of units, is still selling more units than all Lumia phones combined and has a projected sales level of 25 million units a year; its operating system is still beeing developed, even though with a different name, and is expected to drive Nokias next billion devices - provided Nokia still exists then). QtQuick applications can also be found in the App Store, the Android Market and the Nokia Store - and their number is increasing rapidly.



  • QtQuick has got many advantages, non-trivial bindings are just one of them, and they don't vanish just because they are of no use to you. The majority of people is using graphical tools to design their user interfaces and this is a hard requirement for any graphical toolkit. The prerequisite is a meta-language as native-language tools are way to complex to be created. This is the reason QtDesigner is using .ui files, VisualStudio is using resources and XAML, GTK+ is using XML. No, you can't take advantage of QML if you don't use QML (which is, as I already said, easily extensible using C++ and QML) and no, you can't take advantage of it if you use a third-party meta-programming library like boost, but this true for any advanced Qt, including a hypothetical native QtQuick interface.

    It's actually a bit weird that the declarative approach of QtQuick is reputed to have no advantages, yet everyone is trying to re-create the declarative API in C++ as an example of how a modern, native API should look like, including non-trivial bindings and lazy evaluation.

    The bad news is, there are things you cannot express in a declarative language and there are things you cannot express in an imperative language. I am eager to see - honestly, I'm not beeing a drag here, I'm really curious - how one expresses <code>for(int i = 0; i < 10; i++) { ... }</code> in a declarative language (preferably QML) and <code>Item { value: innerItem.value + anotherValue; Item { id: innerItem; value: anotherValue; } }</code> in an imperative language (preferably C++).

    I am also eager to see how source-based network transparency can be easily achieved in C++; do we integrate a complete build environment in our applications and compile the source on-the-fly; or are we using some kind of meta-language which is interpreted (like QML); or do we precompile the source and transport binaries (which isn't source-based anymore but at least it works) and disqualify our application from almost any controlled platform and application store, as downloading and executing binary data is prohibited on all.

    How do we all this without introdcuing any binary contracts - which is the severe issue with native frameworks, especially with emerging technology.

    I've seen that you are already working on a C++ API and honestly, I like it, I really do, but unfortunately I have more bad news for you. Although your implementation is possible, it is unsuitable for what it tries to achieve. The public API of Qt5 is C++98, which means no boost, no variadic templates and lambdas as requirement, and a tight connection to meta-object model of Qt.

    I do think Qt will benefit from a native QtQuick API. But I also think (after activly working with QML) that it is (just) the second best solution to solve the given problem. If there are resources left (or if there is a strong momentum from the community) there should be native QtQuick API, but by then all effort should be put it the most benifitial (usability, maintainability, future-proofness and performance) solution.

    If all you have is a hammer, everything looks like a nail.



  • bq. It’s actually a bit weird that the declarative approach of QtQuick is reputed to have no advantages, yet everyone is trying to re-create the declarative API in C++ as an example of how a modern, native API should look like...

    I think it is more like the declarative approach of QtQuick mimics the data structure of a program, written in an imperative language, just in a slightly different way, where structuring is not logical but visual. I don't think those theoretical C++ code examples aim at exploiting that, C++ programmers are bound to know data structure, there is no other way around, what the example code tries to exploit is the modularity of QML, which is present in QtGui as well, but is relying on a sub-optimal model when it comes to modern UI. It is probably due to the fact QtQuick arrived with very little components and literally no functional components, just some basic building blocks with which people can build functional components. In this regard I find the paradigm behind QtQuick more flexible and attractive, and while you can still do the same with QtGui it is more cumbersome, truly more cumbersome than it needs to be.

    I honestly don't get it why so many people assume C++ supporters are AGAINST QML. QML has its benefits, I've said that far too many times, and all this time this initiative was not pushing against QML in any way, just insisting on providing cool new functionality to the ageing QtGui. And please, don't step forward with the "we have limited resources" arguement, especially while suggesting we do all that work ourselves. If Nokia didn't intend to offer excessive functionality to QML in order to give it an artificial advantage by not paying attention to solving the problems of QtGui for a new C++ API, if the backend was done more flexible and with a public native API, that extra effort woudn't be needed now. It would have been much easier designing QtQuick with native use in mind and adding the QML functionality on top of that than having to go back and do it for a QML centered backend. It is not OUR fault the Qt development team decided to take the wrong direction, there is a saying in my native language "measure twice, cut once" because if you cut without carefully measuring, chances are you will come short and have to cut another piece, waste the old one, just because you didn't take the right considerations.

    It is most certainly not the first time a big company buys a smaller company with a nice product, and channels the further development of this product through some proprietary language. It is not the first time cool new C++ backends with cool new functionality get little to no native access, so that developers are forced to adopt a new language. And don't get me wrong, QML is not hard, it is trivial, it is far from a programming language, you DON'T DO QML PROGRAMMING, you do data structure description, and since we all know about data structure, is it that much of a stretch to want to do it ourselves and skip on the entire QML chain of not-really-necessary-but-made-necessary tools?

    A nice, public QtQuick API would not only please native code supporters, but will make QtQuick more extensible, which will in turn bring benefits to the QML front as well.

    As trivial as it may be to interface C++ to QML, doing it for a few objects is nothing compared to extensively doing it, over and over again. QML doesn't take the needs of professional software with custom functionality in consideration. For trivial apps with small number of custom elements, QML is an ease, but this changes as the number of custom elements increases, to the point QML becomes a burden.

    Let's face it, creative developers need a little more than rectangles, creative developers need custom graphics. And so far, all QML examples I've seen that go beyond built in primitives are relying on raster images, which are static and resolution dependent. And when you reach for custom and dynamic graphics, you are met with all the tedious interfacing, working around QML limitations, and QML gets unattractive proportionality to the number of custom elements which you need to implement.

    I think the absence of a QML canvas deserves most of the blame, a QML canvas, supported by the scenegraph, and native, OpenGL accelerated painter would address the majority of drawbacks of using QML for non-trivial apps. And since the extensive amount glue between QML and C++ is the biggest annoyance (at least for me), I think that could use some work, both on the C++ API front as well as the design limitations of QML, which produce a lot of the necessity for glue code.

    The lack of innovation on the C++ front is just one of the aspects in which I think Nokia exerts negative influence on Qt, and while Nokia employees continue denying the obvious, I think the negative influence of Nokia is indisputable. For one, if Trolltech was never purchased, I have the feeling Qt would have had official support of iOS and Android today, which is where money is, and not some half-backed, stuck community ports. Now let's see someone denying the lack of support for the most widespread platforms is not Nokia's fault, but some dedication of Qt developers, like we are supposed to consider QML.

    So, if not a C++ public API, then at least focus on a good CANVAS for QML, that would remove a lot of the burden of using QML that is associated with custom components. That would allow to keep C++ and glue to a minimum, only for extensive computation. That request to cut C++ to a minimum might sound strange coming from someone, who is viewed as a C++ supporter, but again, the issue is not with having to use more than C++, the issue is with interfacing and gluing lots of stuff together. Currently, QML is limited to require tedious C++ extenssion, and making QtQuick work with a native public C++ API is by far not the only solution to this issue. Reducing the need to interface C++ to QML works equally well.



  • bq. For trivial apps with small number of custom elements, QML is an ease, but this changes as the number of custom elements increases, to the point QML becomes a burden.

    Is this just an assertion or can you prove this? We use QML here in a desktop application with a number of plugins and we have not the impression that it scales bad. So it would be great if you could bring some facts to prove your statement.



  • What do you mean by "scales bad"? I am not talking about performance here, I am talking about functional code to glue code ratio, and that after a certain point the ease of QML is totally displaced by the tediousness of interfacing and gluing stuff together. How many custom elements that do custom painting do you have in your application? How much native functionality are you interfacing to QML? What do you mean by facts? Prove my statement? Is this an investigation or it is just you lacking common sense? There is a full hour dev talk on C++/QML integration, and it is just covering the basics, now imagine doing this over and over and over again, imagine projects where custom elements are 90% and more of your code, you still don't see how the limitations of QML and the workarounds around those can become a burden?



  • bq. QML is totally displaced by the tediousness of interfacing and gluing stuff together

    Can you prove this or do you think repeating something often can substitute a proof. Ok, if proofes are overvalued here, then I simply claim you are wrong :O).

    bq. How many custom elements that do custom painting do you have in your application

    Because desktop components are not available yet, all components are custom.

    bq. now imagine doing this over and over and over again, imagine projects where custom elements are 90% and more of your code, you still don’t see how the limitations of QML and the workarounds around those can become a burden

    I don't need to imagine something because we already use QML here - and obviously you don't use QML because you simply state plain wrong things and from all you say here it becomes clear that you never used QML and therefore you have absolutey now idea what you are talking about - that's quite funny.

    bq. Is this an investigation or it is just you lacking common sense

    I simply asked you for a prove of your statement and you answered with an offense - nothing more to say :O)



  • @Uwe - "all" may sound like a lot, unless the total number of elements in your app is like 5, which could very well be the case, since you avoided sharing a concrete number in favor of "all". And then again, stuff like desktop components i.e. push buttons, scroll bars, check boxes and so on - you can entirely do in QML, there is no complexity, no advanced painting, no extensive logic involved in such components and there is no necessity for those to be C++ components. You don't even say what kind of application you are developing, how complex is it, the amount of business logic it contains relative to UI code. It sounds like it is you who fails to substantiate his claim, for it doesn't sound like your application can even fit in the profile of apps, the development of which renders QML a burned rather than an advantage.. And in case you failed to extract a PROOF from my well known facts, from my last post and from the dozens that preceded, then chances are do you lack common sense, it's just like a religious person asking for evidence god doesn't exist ;)



  • @temp

    bq. It sounds like it is you who fails to substantiate his claim

    I claimed nothing, i wrote:

    bq. ...and we have not the impression that it scales bad

    that is simply a subjective impression we got from using QML in our application.

    bq. And in case you failed to extract a PROOF from my well known facts..

    I did not found any facts in your posts - only assumptions or repetition of something you read somewhere.

    bq. For trivial apps with small number of custom elements, QML is an ease, but this changes as the number of custom elements increases, to the point QML becomes a burden.

    I simply do not understand how you can claim something like this.

    How big is your application?
    How many QML elements do you use?
    Which concrete problems arised when you used a great number of custom QML elements?

    If you make a desktop application, you need to choose the right tool and need to do the right desicions. For some things in an application QWidgets are much better suited than QML Components and for other parts of the application QML components are better suited. We mixed both in our application - like QtCreator does it.

    So simply claiming something does not mean that it is the truth.



  • bq. So simply claiming something does not mean that it is the truth.

    To me this sounds like it applies to your earlier statement:

    bq. We use QML here in a desktop application with a number of plugins and we have not the impression that it scales bad.

    Where is the substantiation of that claim? Oh, but it isn't a claim, just a subjective impression, well in that case lets call my "claim" simply an objective impression.

    You didn't provide any the specifics I noted you'd need to provide to actually be able to tell whether you have a point or not. Cuz right now you sound like you haven't done a lot of C++ components for QML. In short, like someone, who is clueless to the issue at hand.

    Watch this talk, and try to imagine what would be if you need to make those considerations and add that glue throughout 90% of the development process.
    http://qt-project.org/videos/watch/programming-with-qt-quick-6-6-c-integration

    It is no brainer really, QML is good when you already have the components, to just quickly and easily stitch them together into a working app. I have yet to see a QML application that actually does something beside being a front end for web services or tech demonstration. QML is perfect for such case scenarios, however a productivity oriented application with scores of custom components and performance critical logic is a completely different matter. And believe it or not, some people are after that kind of applications, so I assume you will not really get the point until you try and do it for yourself. Until then, I stand by my previous claim that you just happen to be clueless on that subject, not because you are stupid or anything, simply because you haven't been in that situation, you haven't experienced it, so you couldn't possibly know.

    Now either prove me wrong by tossing an amazingly powerful and productive QML application in my face, or finally realize some people have higher requirements and standards, and that just because QML happens to work fine for your "mysterious application" doesn't mean it works for serious projects.



  • @temp

    bq. well in that case lets call my “claim” simply an objective impression.

    Finally you got it - hurray. That is the thing I try to say the whole time. The people that read your posts should know, that this is all your impression and that all you say about QML is not based on facts but that it is only your personal opinion.

    bq. and that just because QML happens to work fine for your “mysterious application” doesn’t mean it works for serious projects.

    And just because you don't get along with QML does not mean it does not work for serious projects ;-P



  • So, we are basically right back at denial, prejudice and unproven personal opinions straight in the follow-up to the post that was intended to actually help you and to make your voice more heard and valuable.

    So much for that.



  • [quote author="Uwe Kindler" date="1336116905"]The people that read your posts should know, that this is all your impression and that all you say about QML is not based on facts but that it is only your personal opinion.[/quote]

    And all this time I assumed people realized every opinion in this thread is a personal one. Perhaps you assumed I speak the words of god or something like that? What part of my statements did ever hint at my posts not expressing my opinions? And sorry to break your awesome theory, but my personal opinion is based on facts. And FYI I get along with QML just fine, just in my line of work, the extra effort to get along with QML is arguably worth it. So please, at least have the courtesy of not speaking in my name stuff that is not really true. Just because QML doesn't address the needs of some developers doesn't mean they are too stupid to get it, you know... But apparently that is your fixed idea or people, having a problem with the limitations and overheads of using QML.

    @Lukas Geyer - what the H are you talking about? Denial? Prejudice? Where???
    Pardon me but but voice your personal opinions just as loudly, and accusing people of what you do yourself is called hypocrisy. What kind of proof do you mean? I tried developing serious applications with QML, I experienced the tediousness, associated with writing extensive amount of C++ components for QML, and that's all the proof I need to voice an opinion based on my experience. Or do you imply I am a liar or something? Why do QML supporters keep asking me to prove the obvious, and kind of proof exactly do you mean? Can you even answer, or is it just some desperate effort to make me appear as unable to support my arguments by not providing that "evidence" whatever that may be? And just to get you a taste of your own medicine, where is the proof of me being wrong??? Because you, a guy whose avatar is a suit with a Qt emblem on it says so?

    I never implied my opinion has more weight than that of anyone else, but the same thing cannot be said for some other individuals around here. What has weight is the collective opinion, and as this, as well as the other poll indicates, it seems the people, completely happy with QML are a minority. So if you are that much frustrated by my edgy individuality, at least show some respect to all those other people, who appear to be more or less on the same page as me!



  • @temp

    bq. and as this, as well as the other poll indicates, it seems the people, completely happy with QML are a minority

    It is absolutely clear that nobody is perfectly happy with QML at the moment because it simply misses some important things like desktop components, theming or QtQuick 2.0. So normally nobody would vote for the first item. So it is really astonishing for me that such a lot of people voted for the first item in this poll.

    bq. ...but my personal opinion is based on facts

    Ok, then you might puplish a link to these facts? I ask for facts because I'm seriously interested in these facts that prove that QML is not suited for normal "serious" applications and not because I want to argue.

    It is god if people raise their concerns about QML here and it is good to discuss about these concerns. But in my opinion it is not OK to claim things like

    bq. For trivial apps with small number of custom elements, QML is an ease, but this changes as the number of custom elements increases, to the point QML becomes a burden.

    without proving anything. The next one claims that you are going blind and deaf and that you get crippled fingers if you use QML often ;O)



  • One example of something that is trivial with C++ Qt, but impossible with QML (It might be possible, but I have not found how to do it) is to use a variable number of widgets.

    For example, suppose which fields to display is something the program decides at runtime, base on the user login etc. So the program comes up with a list of fields to put on the form. Using the C++ API one would do something like this (pseudocode in python) :

    @for field_name in field_names_to_display:
    layout.addRow( field_name, QLineEdit() )@

    And the layout would contain all the needed fields, be it 2 or 20 fields.

    Now these kind of things are huge time savers in larger applications. I'd like to know if these kind
    of things are possible in QML, and if possible without JavaScript.



  • @Erik

    In QML you would probably use a Repeater for that, see http://qt-project.org/doc/qt-4.8/qml-repeater.html



  • @capisce

    Ahah, thank you for the link. I'm trying to see the parallels between the QML data binding and the traditional model-view-delegate.



  • I've seen you've already taken the easy way out, but there are still some things that are worth beeing mentioned.

    The SceneGraph is not an exclusive feature of QML, see QSG* classes. There is a hardware-accelerated painter interface, see QGL* classes. There is also a traditional QPainter interface to QML, see QQuickPaintedItem. QML can be easily extended with C++ code, see QQuickItem.

    QML has got a canvas interface, which allows drawing of straight and curved lines, simple and complex shapes, graphs, and referenced graphic images. It can also add text, colors, shadows, gradients, and patterns, and do low level pixel operations, see Canvas item.

    Images in QML can be supplied in any of the standard image formats supported by Qt, including bitmap formats such as PNG and JPEG, and vector graphics formats such as SVG. If you need to display animated images, use the AnimatedImage element. BorderImage provides automatically scaled raster images.

    QML is at an advantage due to beeing an declarative, interpreted language (id est not beeing C++). An interpreted API has to maintain source code compatibility, whereas an native API has to additionally maintain binary compatibility, thus is usually less extensible, as there are binary contracts to be abode.

    QObject, QObjectList, QStringList, QVariant, QVariantList, QVariantMap and QAbstractItemModel can be directly exported to QML without any additional glue code. qmlRegisterType() allows for registering custom types, which are then available in QML immediately. QML supports C++ inheritance hierarchies and can freely coerce between known, valid object types. The QtQuick engine takes advantage of the meta-object information already present for each object.

    There already is an extensive list of professional, productivity-oriented applications created with QtQuick, see KDE, QtMediaHub, N9, mixd.tv, httvBOX, Ocean Blue, IP4.tv et al.

    QML is a replacement to QtWidgets in the same way the Graphics View Framework is a replacement to QtWidgets. QtQuick stands for Qt User Interface Creation Kit, not Qt Application Creation Kit.

    Nokia spent 150 million dollars to acquire Trolltech just to release the framework under the terms of the LGPL, so that everyone can use Qt for closed-source non-commercial and commercial applications for free. Since then, Qt has grown exponentially in number of features, users, applications, SDK downloads, full time developers and specialized companies. Although Qt beeing an Open Governance community project now, Nokia is still (by far) number one code contributor, main contributor of legal resources to define and protect the Qt trademark, licensing and Contributor License Agreement, main funder of Qt training courses and materials, the Qt Certification and Qt Ambassadors program and the Qt Project infrastructure, the Qt Contributors Summit, the Qt Developer Days and experimental activities around Qt5 such as the QtonPi, Qt5 for N9, Qt5 for PhoneGap or INdT.

    Yes, we've still got a long way to go with QtQuick and QML and there is definitely room for improvement. Therefore we need a vivid discussion about the future development. But such a discussion is quite impossible as long as we have such a diverging perception and as long as most subsequent conclusions are based on it.

    I do not presume to know what the majority of people thinks about QtQuick and QML, and you shouldn't do that either. Especially as based on a biased poll with insignificant participation [the Qt SDK is downloaded by millions of people, 130 have participated in "your" poll, 85 of them have voted in favor of an (additional) native API], which doesn't even allow for differentiation between a native API beeing a replacement or an additional, secondary option to QML. You must have missed that in the second poll you are referring to (which suffers from the same insignificant participation) two-thirds of the people have voted in favor of QML.

    But what I do know is that a lot of the argumentation against QML is based on denial, prejudice and personal opinions. It would help me a lot if I would actually see all the excessive amount of glue code that is obviously somewhere, if I would see the huge performance impact of QML on our applications, if I would see all those, or at least one, applications that have been made quite impossible due the way QtQuick works and if I would see that perfect native C++98 API, which has all the advantages of QML without its disadvantages. Where is all this?



  • Lukas Geyer, you keep stating that we need to keep to fact-based arguing... so I'll keep this short:

    Hardware Accelerated C++ GUI API with bindings does not require a JavaScript Interpreter, a Virtual Machine, or a brand new declarative language.

    There, that's it. There is no fact-based argument to defeat that. Please try as it will be amusing to read. Now please stop with the same old tired push of "use the QtQuick back-end directly" (QSG* classes) HURRRR you troll. We can both agree that there's a reason QML exists: to serve as a front-end to drive the back-end that you're proposing we manually drive. If it's so easy, why was QML invented to drive it? We want a purely C++ front-end to drive the QtQuick back-end, get it?



  • I do. And if you would have followed the discussion you would have seen that I've never had a problem with people demanding it, but rather how the gave reasons; and you would know that I've explicitly mentioned that Qt should have a native QtQuick API.

    But I do have a spot of bother with it, and it is to be feared that your are most probably not amused with it, as it is quite of a killer argument: it is practically impossible to express the requirements for such an API in C++98.

    But I'm quite sure you bring an idea, a sketch, a paradigm or possibly even an early implementation of such an API with you, which supports at least automatically re-evaluable expressions, or bindings as you call it, which substantiates your demand and in further consequence disproves my assumption, don't you?



  • [quote author="d3fault" date="1336928933"]Hardware Accelerated C++ GUI API with bindings does not require a JavaScript Interpreter, a Virtual Machine, or a brand new declarative language.[/quote]

    It does not theoretically "require" them, no. But then again, no computing task theoretically "requires" anything more high-level and productive than assembler code. And not even that, why not go one step further and design a new hardware chip for each computing task?

    Yes, there would have been different possibilities for solving the task that QtQuick/QML tries to solve. The Qt developers made a design decision. They gave higher value to maximizing productivity for application developers/designers, than to making diehard "C++ for the sake of C++" purists happy. A good choice.



  • [quote author="jdavet" date="1336997353"]They gave higher value to maximizing productivity for application developers/designers, than to making diehard "C++ for the sake of C++" purists happy. A good choice.[/quote]

    Wrong. They gave higher value to creating a NeW eXtreMe eXper1mentaL "Designer Friendly" AppLiCatiOn pr0gr4mming LaNguaGe in hopes that it would earn them more moneys in the mobile market. They're pissing a lot of us C++ devs off by forcing the use of this NEW BITCHIN PROGRAMMING LANGUAGE [if we want to use up-to-date UI]. We already know how to code and we don't need a javascript interpreter thank you very much.

    If I was a C++ purist I'd be using Boost, not Qt. Qt's use of MOC makes C++ purists cringe.

    [quote author="Lukas Geyer" date="1336990448"]But I do have a spot of bother with it, and it is to be feared that your are most probably not amused with it, as it is quite of a killer argument: it is practically impossible to express the requirements for such an API in C++98.[/quote]

    I agree. A lot of the previous examples included the use of lambdas and C++11 features. Here is one that is C++98.... though it is uglier because of it. (best case scenario: support both)

    What you type:
    @m_SomeDeclaredView.somePropertyToBeUpdatedWhenTheBindingPropertiesChange = Q_BINDING((Q_BIND(m_SomeOtherObject.someProperty1) + Q_BIND(m_AnotherObject.someProperty2)) /Q_BIND(m_YetAnotherObject.someProperty3) + aConstantInteger);@

    Post-MOC result:
    @
    //Auto-Generated
    autoGeneratedEvaluateFunction()
    {
    return (m_SomeOtherObject.someProperty1 + m_AnotherObject.someProperty2) / m_YetAnotherObject.someProperty3 + aConstantInteger;
    }
    connect(m_SomeOtherObject.someProperty1, SIGNAL(changed()), this, SLOT(autoGeneratedEvaluateFunction());
    connect(m_AnotherObject.someProperty2, SIGNAL(changed()), this, SLOT(autoGeneratedEvaluateFunction());
    connect(m_YetAnotherObject.someProperty3, SIGNAL(changed()), this, SLOT(autoGeneratedEvaluateFunction());

    //Your original binding, wherever you typed it
    m_SomeDeclaredView.somePropertyToBeUpdatedWhenTheBindingPropertiesChange = autoGeneratedEvaluateFunction();@

    in the precompiler stage,
    each Q_BIND evaluates it's contents to ensure it is being pointed to a proper Q_PROPERTY
    each Q_BIND 'makes note of (somewhere)' the property it points to
    the contents of Q_BINDING are stored in some "autoGeneratedEvaluateFunction" function, with the Q_BIND macros removed (since we've already processed them)
    the right hand side of the equals sign points to autoGeneratedEvaluateFunction() to get the initial state
    each of the Q_BIND'd properties we 'made note of' have a slot connected to their NOTIFY Q_PROPERTY signal. this connection is disconnected when the view is no longer seen.
    the slot that the NOTIFY signals is the autoGeneratedEvaluateFunction function. there could also be some: if(new != old) { old = new; emit changed(); } protection in the property's setter.

    since aConstantInteger is not surrounded by Q_BIND (and since it's constant!), there are no signals/slots to set up. Q_BINDING might (idktbh) also need compiler optimization-prevention so it doesn't get rid of aConstantInteger

    I pulled this example out of my ass. I'm sure others could come up with a better solution. Do you also need to be shown how to declare a GUI in C++?

    [quote author="jdavet" date="1336997353"]It does not theoretically "require" them, no. But then again, no computing task theoretically "requires" anything more high-level and productive than assembler code. And not even that, why not go one step further and design a new hardware chip for each computing task?[/quote]
    Any solution is not the best solution. Qt strives for the best solution. There are plenty of overly expensive languages that provide the exact same functionality as Qt... usually incurring a run-time cost (JIT etc) where Qt requires none. Java/.Net/any-interpretted-scripting-environment... are all inferior to Qt.... for the same reasons QML will be inferior to a Hardware Accelerated C++ GUI API with Bindings: Native and/or Not Interpretted. (give me QML compiled down to byte code in my executable and don't force the use (includes simple loading without using (a lot of people saying: don't like js? don't use it!)) of a JavaScript Interpreter/VM at runtime and I will consider it a 'good-enough' compromise sadface)



  • Yes, using a preprocessor is a possibility.

    But let's take a look at the idea behind: we are adding specific language extensions because the requested functionality is not supported, which are then translated by a seperate tool into native code.

    If we now extend your example to the correct use of properties (which require the use of property() and setProperty(), as there is no such thing as a property in C++) or a more declarative way to describe a hierarchy of components using key-value assignment (as requested and suggested on the mailing list), basically everything on the list for an advanced GUI API (and everything that distincts QtQuick from the already existing, hardware-accelerated Graphics View API) we end up adding specific extensions and then, although having a native API, in creating and implementing our QtQuick components using those language extensions - a specific meta-programming language front-end - which is then translated into native back-end code by a seperate tool. What we implement in native code is the required supporting code, like constructors, destructors, operators, memory management and so forth.

    If you bring this to a head, you'll end up exactly where we are right now. We have a specific meta-programming front-end language, QML, which is then translated by a seperate tool, the declarative engine, into a native representation (no, QML is not interpreted, it is translated into a native representation and no, V8 does not interpret JavaScript, beeing a just-in-time compiler it produces run-time optimized machine code, which is then executed). In both cases you will have to (learn and) use a specific front-end language (with different aesthetics) which is not C++.

    You've already been told that a byte-code compiler for QML is possible, partially done and possibly integrated in Qt 5.1 if there is a strong momentum from the community.



  • Just food for thought....

    Someone mentioned here the BlackBerry 10 Cascades framework based on Qt/QML as non toy app development, well, RIM seems to think that having a C++ alternative interface for Cascades as well (and not just QML only) is actually a good idea and looks like an implementation like that is very viable (as opposed as some people here seem to think), check this link for an example:

    "BB10 developer documentation":https://developer.blackberry.com/cascades/documentation/getting_started/introtocascades.html

    Also, a while ago I contributed to a declarative language and API that was very controversial as well called JavaFX with the very cool and infamous FX Script, well, if history has something to teach us, by version 2 they ended up adding a java interface for it because there were too many developers complaining that had to forcefully use FX Script instead of the language everyone knew. At the end, FX Script died, java interface prevaled, and even ended up adding an XML declarative interface (go figure) instead of FX Script.



  • Well, its basically a fluent interface wrapper around the proprietary Cascades elements and the Animation Framework for constructing objects, but there is no support for states, bindings or anything else we are used to know from QML (which doesn't mean having a fluent interface is not a viable idea).



  • @Lukas - you are aware in the manner surveys are done, aren't you? When probing about the public opinion, usually only like a thousand random people are being questioned and that gives an adequately accurate representation of what hundreds of millions are thinking.

    This poll has kept a steady 2:1 ratio from the moment I first checked it with only 50 votes to now - over 150 votes. At this point I think it is safe to assume this is an accurate representation of what people think in general, and considering the claimed figure of about 500 000 Qt developers, about 333 333 of them would want to see efforts invested in a modern, customizable, hardware accelerated GUI API that is pure C++.

    Or do you imply all the people who didn't find this thread or have no forum registration would vote against a C++ API? If so on what grounds? Because you think it is the right thing to do and value your opinion above that of hundreds and potentially hundreds of thousands people?

    And furthermore, what do you imply about all the people who voted in favor of a C++ API? That they are clueless fools that don't know what's best for them?

    With the risk of repeating what's already been said, if a new GUI API was conceived with the idea of being public and native above all to begin with, and extend QML functionality out of it - this issue wouldn't even be at hand. Alas, Nokia chose to offer the candy result of development efforts through their own language like so many other corporations before that, so at this point it becomes a burden to reshape the API in a native form, so may as well be better to create a new API focused at C++ nativity rather than modify the existing, QML/JS focused API.

    As of the matter of stuff that is not technically possible with C++ - C++11 already provides solutions and I think it is about time Qt begins taking advantage of them, incorporating a compiler that is not ancient history and whatnot. BUT even without C++11 - Qt already heavily relies on code generation and the MOC and I cannot shake the feeling it would have been much easier to extend the MOC to generate some more boilerplate code from a nice and clean syntax that describes property binding in C++ source than reinventing the wheel and throwing in the mix a pile of new and avoidable tools in some ill conceived attempt to be "cool" and trendy in the philosophy of "monkey see, monkey do" and follow in the steps of other companies that work hard to make the excellent language that C++ is into the new assembler in both area of application and usage frequency, to push forward another "our way of doing things" like development is not fragmented enough already.

    I get the feeling of C++ as well as Qt itself being neglected by Nokia, surely, no one argues they spent good (too good IMO) money on it, they made it LGPL which is a great thing, making adoption easier and usage of Qt higher, however the effort to morph Qt from a purely C++ application framework to a mostly QML application framework, extendable through C++, combined with the decision to NOT support the actual major mobile platforms and all the (potential) Qt supporting mobile platforms being pretty much dead, dying or stillborn - somehow it doesn't seem those decisions are in Qt's or its developer base best interests. And with all the yapping that despite being owned by Nokia, Qt is a community framework, where are the platform support and features this community obviously wants? And no, I don't think the community CAN or SHOULD even try to push against the bulk of the development effort that is in the hands of Nokia, it is Nokia that should direct that bulk of development effort to address the needs of is developer base, not protect its preposterous corporate interests that have already inflicted billions of dollars of damage and cost thousands of people their jobs.

    And surely, C++ classes are still there, no one denies that, the problem at hand is not with old native stuff being gone, the problem is it is all DONE and there is NO new native stuff being developed, QML absorbs almost completely the development efforts, whereas other new promising technologies and platforms are being completely neglected and this has been going ever since the acquisition. Is this really "progress" or is Qt being sent on a wild goose chase, pimped to appear progress-like?



  • [quote author="utcenter" date="1338631185"]@Lukas - you are aware in the manner surveys are done, aren't you? When probing about the public opinion, usually only like a thousand random people are being questioned and that gives an adequately accurate representation of what hundreds of millions are thinking.[/quote]Yes, statistics uses samples to infer about a population, but this requires a certain sample size which is (for a common confidence level and interval) too low for the projected population size, which means that the result is not adequetly accurate. In addition, passively recruited or self-selective surveys are generally never representative, due to the erronous nature of sampling (and questioning in this case).

    [quote author="utcenter" date="1338631185"]At this point I think it is safe to assume this is an accurate representation of what people think in general, and considering the claimed figure of about 500 000 Qt developers, about 333 333 of them would want to see efforts invested in a modern, customizable, hardware accelerated GUI API that is pure C++.[/quote]No, because this poll answers a different question (should there be an optional C++ API) than the one you've raised (should resources be spent on creating one). The latter question is answered in "this poll":http://qt-project.org/forums/viewthread/16693/, and for the vast majority of voters improving QML is more important than creating an optional C++ API.

    [quote author="utcenter" date="1338631185"]Or do you imply all the people who didn't find this thread or have no forum registration would vote against a C++ API? If so on what grounds? Because you think it is the right thing to do and value your opinion above that of hundreds and potentially hundreds of thousands people? And furthermore, what do you imply about all the people who voted in favor of a C++ API? That they are clueless fools that don't know what's best for them?[/quote]No, that's your implication, not mine.

    [quote author="utcenter" date="1338631185"]With the risk of repeating what's already been said ...[/quote]Yes, you are repeating what's already been said, discussed, disproved and clarified.



  • The sample size of the poll has varied and increased with the ratio remaining constant, that is an indication the poll results are accurate. Other than that, I can see bias and arrogance heavily influencing the direction of your arguments. I still didn't catch the reason for your claim probing more developers will dramatically sway the outcome in the opposite direction?

    In that other poll, the "full C++ API", albeit not really a viable solution, still has plenty of votes, certainly more than "I am happy with QtQuick".

    And in case you noticed, that other thread is about the direction of QtQuick, not the direction of Qt itself. And a modern C++ GUI API is the subject of the latter. It should be no surprise even to you it is not prevailing in a topic it is not the subject of.

    Furthermore, in case you noticed, the title of this thread is not "Should QtQuck get a public C++ API?" but "Does Qt need a modern C++ GUI API?" and even thou this was somewhat addressed here, due to the design of the very foundations of QtQuick would be about as cumbersome as designing a new one.

    bq. No, that’s your implication, not mine.

    Indulge me of yours then, I am really curious about the motivation of your opinion being put over those of many people.

    bq. Yes, you are repeating what’s already been said, discussed, disproved and clarified.

    Repeated - sure, discussed - extensively, other than that you are now making things up. No one disproved the need of a modern C++ API for UI and I am sure those poll results are inconvenient enough for you to do your best to downplay them, but here is a news flash for you - other people have opinions too, and many of those are just as valid as yours, only more in count and with less bias.



  • I think we talk past each other.

    The result of a vote is absolutely irrelevant for its representativity (and my personal well-beeing). We don't know what the vast majority of Qt developers think; we indisputably know what 158 people think (and that's what I've said). An extrapolation to the population is only valid if qualitative (a representative sample) and quantitative requirements (sufficient participation) are fulfilled. This has nothing to do with a personal opinion or downplaying, that's a statistical fact.

    Even if the poll might sway to a different result it is still not representative, the same way the other poll is not representative for the population of Qt developers (but on the suppostition that a majority of people who have voted in this poll also have voted in the other poll - which is, of course, up to discussion - it is representative for the population of people that have voted in this poll).

    I do not take part for or against, but I do correct people who try to affect the discussion in their favor with improper rationales. I do want to have Qt a prosper future, but this future has to be decided on comprehensible technical reflections, not sentiments or animosities. So I will correct people and ask for proof from both sides of the aisle. The impression, that I am the declarative envangelist, is pure and simple created from the fact that there is a disproportional high amount of subjectivity on the part of the native proponents.

    Having a meritocratic consensus-based development model, which implies having discussions about the further development, is a good thing. Meta-discussions about objectively insufficient arguments aren't.

    Every opinion is as valid as mine (and yours). But there are ones that prove themselves true and become facts, and there are ones that simply stay opinions.

    In addition, I would like to encourage you to continue this discussion in a reasonable manner. If you think that I'm wrong just bring your own comprehensible reasoning and disprove; there is no need to constantly discredit and misrepresent me (or anyone else).


Log in to reply