Does Qt need a modern C++ GUI API?
-
[quote author="Lukas Geyer" date="1335519690"]QML introduces a significant performance overhead, due to beeing executed in a JavaScript-based virtual machine, and is introducing lots of glue code, glue abstract and proxy objects..[/quote]
The real answer is that we simply don't know how well QML will scale in non-toy apps, because no non-toy apps have been developed. Or at least no one who has developed such a non-toy app has been willing to go public. We also know that a native implementation would be monotonically more performant than the QML version. Just what the delta is, we don't know[quote author="Lukas Geyer" date="1335519690"] QML (as beeing a declarative language) doesn't require JavaScript, it is (theoretically) possible to build and use Qt Quick and QML without any JavaScript interpreter at all. Qt Quick uses JavaScript just to evaluate imperative code and non-trivial bindings. Everything else results in native code.[/quote] Except that "everybody" says that the non-trivial bindings are the real reason to use QML. So in theory, you then don't need QML, because if bindings are not needed, there's no good reason to use it.
[quote author="Lukas Geyer" date="1335519690"] There is no requirement for additional glue code or proxy objects to expose data from C++ to QML. Existing objects (QObject), collections (QStringList, QObjectList) and models (QAbstractItemModel) can be directly exposed to and used in QML, signals and slots are routed transparently and both, C++ and QML, can modify object properties. [/quote] Unless my objects aren't one of QML's predefined things it understands and unless my signals and slots are implemented using Boost signal or some such thing.
[quote author="Lukas Geyer" date="1335519690"] QML is used to build a native representation, as other non-native, domain-specific, interpreted languages already present in Qt and every Qt application, like CSS, SQL or PCRE.[/quote] Except that these other things don't completely dominate the application, are not a requirement to use the technology, and there are C++ interfaces for all these things.
[quote author="Lukas Geyer" date="1335519690"]QtWidgets and The Graphics View Framework are still first class citizens in Qt, they still can be used and will be used to create applications, they will receive attention on part of the developers and there are still additions made (there has been a quite impressive charting component released just a few weeks ago). QtQuick is optional, there is no obligation for new applications to use it, and there is no requirement to port existing applications.[/quote] There you go, not listening again. Many people have explained their concerns regarding this matter and it has nothing to do with "I can't use QWidgets or QGraphicsView".
[quote author="Lukas Geyer" date="1335519690"]QML is fully network transparent, each resource can be either local or remote, including source files.[/quote] You seem to be fond of this, but not even any other fanboys seem to care. And it's not like a C++ declarative (yes declarative) API couldn't easily be made to do the same thing.
[quote author="Lukas Geyer" date="1335519690"]In addition, there is full tool support for creating QtQuick user interfaces, [/quote] Yes, this is where the trolls have been burning their time instead of doing stuff that truly provides value. That's part of the list of concerns.
[quote author="Lukas Geyer" date="1335519690"]which also allows for doing user interface-specific code by the designer, who usually isn't aware of C++, and thus enabling another layer of user interfaces / business logic abstraction. It is absolutely easy to learn and has a much less steep learning curve for people not beeing aware of imperative programming languages in general and C++ in specific.[/quote] I really wish there was one "designer" who would stand up and validate your hypothesized use-case. A designer who isn't familiar with C++ and who came up to speed on QML and is using it in the way you imply. Let me know when one of those guys shows up.
[quote author="Lukas Geyer" date="1335519690"]Beeing a declarative language featuring an imperative interpreter one gains the advantages of lazy evaluation and (non-trivial) bindings. In addition, there are almost no binary contracts introduced, which is vital for emerging technolgies.
This is not possible in C++.[/quote]
How about you back up your statements with real examples which illustrate these supposed advantages and let someone familiar with C++ poke holes in your fallacious beliefs. -
[quote author="Lukas Geyer" date="1335519708"]QML is a proprietary language, it was made closed-door and political motivated, as any decisions regarding Qt. Declarative langues are quite uncommon for creating user interfaces.
QML with its JSON-like syntax and imperative JavaScript language is the result of a technical selection process. The specification and implementation is publicy available, and can be searched, modified and extended by everyone. Decisions on the future of Qt were always takes on purely technical reasons inside Nokia before open governance was fully set up. Now decisions are taken in the public — and again for technical reasons only.[/quote] If you can point to anybody else who uses QML, then I might put some stock into what you're saying.
[quote author="Lukas Geyer" date="1335519708"]Although QtQuick / QML beeing an emerging technology, both are activly used to create and port applications, like KDE, Qt Media Hub or the Nokia N9.[/quote] You probably shouldn't use a dead-end phone with a dead-end OS as the shining example of where QML can be used. I don't know the details of KDE, so it's hard to know if their adoption of QML is due to technical merit or because there is no other choice, seeing how they're going to have to use it in order to access future Qt technology.
[quote author="Lukas Geyer" date="1335519708"]C++ can be used as a declarative language as well.
QML is declarative, not imperative - JavaScript is, as well as C++. You cannot express one using the other.[/quote] Another of the complete fallacies you try to hoist on unsuspecting people.
[quote author="Lukas Geyer" date="1335519708"]Qt5 is a primarily a QtQuick release. There are no other improvments for the classical development.
- All ports now base on the Qt Platform Abstraction Layer
- Modularization of the Qt Respository
- Improvments for QtCore, including a new way of handling standard pathes, a full-blown JSON parser, MimeType recognition, a completely new compile-time checked signal/slot connection syntax, which allows for using of C++11 lambdas, a completely new Perl-compatible regular expression parser, a rewrite of many data structures optimized for better performance and C++11 support
- Improvments for QtGui, including a port to the new QPA architecture, top-level surfaces and built-in OpenGL support
- Improvments for QtNetwork, including support for DNS lookups
- Integration of Qt3D, QtLocation, the Mobility APIs, improvments for QLocale, time handling, unicode, an updated WebKit, ...
[/quote] No one is complaining about these other improvements. But just imagine what they could have done if they had spent the QML infrastructure development man-years instead on real value added stuff like the stuff you mention.
[quote author="Lukas Geyer" date="1335519708"]Dynamic fluid interfaces are just for smartphones, which are still a niche market. Desktops require native looking and behaving applications.[/quote] Again, you have it backwards. If people didn't care about the new "fluid interface" technology in QT and were perfectly happy with existing QWidgets, there wouldn't be the uproar. And you're implying that the myriad reasons people have stated regarding the need for C++ API don't apply to smart-phones. When in fact they apply just as much.
[quote author="Lukas Geyer" date="1335519708"]In 2011 415 million desktops were sold. In the same time 488 million smartphones were sold, about 700.000 smartphone applications were created, 17 billion applications were either sold or downloaded for free and this number is expected to rise to 185 billion in 2014. A revenue of over 15 billion dollars has been generated, which is an increase of 190% over 2010. There is a strong momentum in classical desktop application development for user-centric and task-centric applications as well, which breaks with native platform-specific look and feel. The predominant desktop platform Windows (92.5%) completely focuses on task-centric applications within its upcoming release (Windows 8).[/quote] Do you actually have a point in this gibberish? BTW, quoting number of cell phones sold and how big of a market it is, doesn't really bolster the case for QML, because 1) how many of these phones could actually run a QML app 2) how many of those are not based on a dead-end OS. 3) what phones does Nokia expect to field in the upcoming years that are going to be able to run QML 4) what percentage of smart-phone developers in their right mind would even think about using QML today - the answer, roughly 0 with a possibly rounding error.
[quote author="Lukas Geyer" date="1335519708"]No, but there are facts, and there is fiction. Basis of discussion should be the former, not the latter.[/quote] So start showing "facts" then. You seem to hand-wave all the supposed advantages of QML (which for all the handwaving are a mere "fiction" so far) while poo-pooing legitimate concerns of C++ users. Put your money where your mouth is and show us some real QML examples that just "cannot be done using C++". Because that's what it all comes down to. The only reason to boil the oceans for QML is if it has significant advantages All the other verbiage of your last two posts are really irrelevant at the end of the day. Let's see these advantages laid down in concrete examples.
-
I like the vision of your most recent post. If you have the time, would you mind expanding on your thoughts about the proper way to create a C++API that takes advantage of the language and provides alternate ways to achieve the end-effect of bindings?
-
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 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..
-
@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.
-
[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="<<r.width<<" height="<<r.height<<" area="<<r.area<<endl; }); cout << "width="<<r.width<<" height="<<r.height<<" area="<<r.area<<endl; cout << "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.