Does Qt need a modern C++ GUI API?

[jonny.dee]

I just would like to throw my 2 cents in:

If there were a C++ API as alternative to QML then one could write a code generator/compiler that translates QML code into native C++ code that uses this API. This would let you profit from the advantages of both worlds:

• Code can easily be maintained by editing QML files.
• During development you can profit from the fact that you don’t need to recompile after every change you make.
• The compiled C++ code obviously is more efficient.
• API changes wouldn't be as dramatic because the code generator could be used to recompile the sources incorporating the API changes.
• You can protect your IP, because the released software won’t include QML code (be it an embedded resource or not).

While I am not as concerend about the efficiency gain (or drawback) I am concerned about being able to protect IP, and this is my reason why I would appreciate a C++ interface plus such a compiler.

[jturcotte]

The way I think it is best used and why it doesn't need a pure C++ API:

C++:

• The application's shell
• Custom QQuickItems for application components needing performance
• Heavy parts of the application's logic exposed as slots through QML plugins/global objects

QML:

• UI layouts
• Light parts of the application's logic

I think that a pure C++ API can only be slightly more efficient for most use case, and I think that the maintenance and complexity costs of both a QML and C++ binding systems would not be worth paying for those benefits.
As much as I like signals and slots, I don't want to have to write a slot for every single connection between Rectangles/MouseAreas in the app that involve more logic than a direct value binding.
If a component of an application really requires ultimate efficiency, it is then better to go directly down to the metal with the current scene graph API to avoid as much abstraction as possible.

The real question to be polled should be "Should we expose QQuick* and QSG* classes in the public API?". And for the sake of the quality of Qt5's future API, the answer should remain "no" at least until 5.1 or 5.2.

[cfreeloader]

If you assume for the moment that there is a way to deal with binary compatibility, then I think that the arguments typically boil down to one of more of:

1. QML is just so much more readable and easier to use that I can't imagine anyone ever wanting to use C++
2. You can't easily do things in C++ that you can do easily in QML
3. You can't do declarative in C++, because C++ is a imperative language

My concern is that people really aren't understanding what a well defined C++ interface would allow and are thus rushing to an incorrect judgement on items 1-3 above. To better illustrate the kinds of things that could be, I took a segment of QML from the Qt4.8 documentation that has animations and states and converted it to a hypothetical C++ API based description. These are shown below. From this, you can see that the C++ version is not necessarily overly verbose or less understandable than the QML version.

Note the C++ version implicitly uses various recent C++ language features to simplify and streamline the resulting code. This illustrates another reason why C++ is better in general than QML - that is, C++ has a myriad of language-based that have been intensively developed and refined over 30 years, culminating in C++11 which is supported by all major compilers now. Language design is notoriously difficult to do right and QML cannot hope to compete with C++ in this area.

C++ also enables a use of a wide variety of libraries that can be incorporated into the UI design if desired. These libraries include the C++ std library as well as Boost and many others. QML also cannot hope to compete with C++ in the area of available libraries that can be leveraged if desired. Now you may say, "well, for UI I don't need any libraries, so that doesn't matter". The response to this is, "maybe you can't imagine using any libraries, but that doesn't mean that someone else doesn't have a need to use some crazy library." For example, you might want to use some graph library (of which there are many available) to help create your UI. But with QML, this becomes a lot more tedious to do.

Now you might argue that a "designer" isn't going to use C++, to which I would probably say, yes, you're right, but they're probably not going to use QML directly either. They're more likely to use a tool like QtCreator and a such a visual design tool doesn't inherently require QML (e.g. QtDesigner doesn't use QML).

@====================== QML version =================
import QtQuick 1.0

Rectangle {
width: 400
height: 400

 Rectangle {
     id: coloredRect
     width: 100
     height: 100
     anchors.centerIn: parent

     Behavior on color {
         ColorAnimation {}
     }

     MouseArea {
         id: mouser
         anchors.fill: parent
         hoverEnabled: true
     }

     states: [
     State {
         name: "GreenState"
         when: mouser.containsMouse

         PropertyChanges {
             target: coloredRect
             color: "green"
         }
     },
     State {
         name: "RedState"
         when: !mouser.containsMouse

         PropertyChanges {
             target: coloredRect
             color: "red"
         }
     }]
 }

}
====================== C++11 version =================
#include <QtQuick2>

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

    InnerRect(Rectangle *parent)
      : Rectangle(100,100),
        mouser(this)
    {
        colorChanged().connect(&ColorAnimation);

        anchors().centerIn(parent);
        mouser.anchors().fill(this);
        mouser.hover_enabled(true);

        states =
        {
            { "GreenState", mouser.containsMouse, { this.color, "green" } },
            { "RedState",  unary_negate(mouser.containsMouse), { this.color, "red" } }
        };
   }
} coloredRect ;

OuterRect() : coloredRect(this), Rectangle(400, 400) {}

};
@

[jturcotte]

I agree it's beautiful, and nobody is against a pure C++ API.

It is just usually smart to offer and support only one solution for a given problem, and offering only a C++-only API wouldn't be as good as what QML has to offer to reduce application development costs.

QML has both pros and cons compared to C++, and it's part of the reasons why the Qt Quick scene graph isn't tightly coupled with QML/QtDeclarative. JavaScript isn't mandatory to be able to use the new graphics pipeline.

So overall something had to be chosen to be shipped with Qt 5.0 to offer a complete solution, and it doesn't imply that this will be the de facto solution for all 5.x releases.

[jdavet]

[quote author="c++freeloader" date="1335227533"]From this, you can see that the C++ version is not necessarily overly verbose or less understandable than the QML version.[/quote]

I disagree, I think the QML version is much easier to read/understand (and to write) than the hypothetical C++ version.

In the C++ version, you need to deal with low-level concepts like variable declarations vs definitions, constructors, initialization lists, pointers, class definition vs instance, signals & slots, etc.
Not that a Qt developer would have a problem to understand any of those, but interpreting foreign code that has all those concepts tightly thrown together takes a lot more mental effort than understanding a declarative object tree consisting of clean, uniform statements of one of the forms
@ Element { ... }
property: ...
property: [..., ..., ... ...]@
...for which the parser will perform all the necessary "instantiating" and "connecting" automatically.

C++ just isn't optimized as a clean declarative definition language for in-place defined nested objects. The model of... 1) class definition 1a) member declarations 1b) constructor for member definitions 2) class instantiation ...is inconvenient for such a straight-forward declarative use-case and puts information that belongs together in separate places (which, if several levels of nested objects are defined, can become quite far apart for the outer objects).

Also, the "streamlining" (as you call it) which you demonstrate e.g. for defining a state as...
@{ "GreenState", mouser.containsMouse, { this.color, "green" } }@
...looses the readability advantage of QML's "named property statements" idiom and doesn't really seem to appreciate the intended flexibility of such objects (most properties of most elements are optional, most elements allow child-elements, it should be easy to add more properties or potential child-elements in future versions).

As for practicality of implementation, I haven't dug too deep into the possibilities of C++11 yet, so I might be overlooking a few things that could be handled behind the scenes in your example, but I'm wondering...
In the C++ version, how would the Qt Quick engine know when to re-calculate the value of "mouser.containsMouse" and "unary_negate(mouser.containsMouse)"?

As for the usefulness, how much would really be gained? A runtime cost would still incur during loading of the Qt Quick scene.
As I understand it, what the Qt Quick engine does is:

Translate QML input into an optimized internal object tree.

Run the Qt Quick scene according to those object definitions.

With you C++ API, it would become:

Translate C++ object tree input into an optimized internal object tree. (And no, I don't think letting the two be the same is feasible.)

Run the Qt Quick scene according to those object definitions.

Regarding verbosity, you cheated a little by using a pretty concise coding style for the C++ example, but a line-number wasteful coding style for the QML version.
This is how the QML example would look with a coding style that's similarly-concise as the one you used for the C++ example:

@import QtQuick 1.0

Rectangle {
width: 400; height: 400

Rectangle {
id: coloredRect
width: 100; height: 100
anchors.centerIn: parent

MouseArea { id: mouser; anchors.fill: parent; hoverEnabled: true }

states: [ State { name: "GreenState"; when: mouser.containsMouse
                  PropertyChanges { target: coloredRect; color: "green" } },
          State { name: "RedState"; when: !mouser.containsMouse
                  PropertyChanges { target: coloredRect; color: "red" } } ]

Behavior on color { ColorAnimation {} }

}
}@

[capisce]

And a point about the run-time cost of parsing / translating of QML, the same thing exists in OpenGL, with GLSL snippets needing to be compiled into GPU-specific internal shading language by the driver's built-in compiler. Still, the result is high performance 2D / 3D graphics, and not that many people are complaining about it.

[cfreeloader]

[quote author="jdavet" date="1335386303"]

I disagree, I think the QML version is much easier to read/understand (and to write) than the hypothetical C++ version.[/quote]

"easier" - maybe, though that I guess depends on personal preferences, how much prior experience with QML, degree of comfort with JS, how much you understand the object model, and so on. "Much easier" - that is hard to argue. And I wasn't arguing that QML is much easier to understand, I was arguing, "... not necessarily overly verbose nor less understandable than QML".

[quote author="jdavet" date="1335386303"]In the C++ version, you need to deal with low-level concepts like variable declarations, constructors, initialization lists, pointers, class definition vs instance, signals & slots, etc.[/quote]

As far as I can tell, the property statements are not too dissimilar from "variable declarations". A property that already exists in a super-class doesn't need to be declared either. i.e. if you just want to assign it, you can do that. Moreover, if you want, using C++11, you can put the initialization directly at the point of declaration. e.g.
@ struct Foo {
int width = 100; int height=200;
...
};@

If you're worried about having to declare the "type" of the variable, this is only necessary for newly defined properties and you can argue that static typing has some advantages and some disadvantages to dynamic typing (which is what QML in effect uses). You can always use "auto" to avoid having to think too hard about the exact type you want. Admittedly, having to specify a type or "auto" does add one more word to the description - hardly making QML "much easier" to understand.

I'm not sure how you're criticizing "initialization lists", when after all, QML has essentially the same thing, though again, much less flexible. You don't after all have to use initialization lists. Because it's C++, there are many different ways to do it, depending on the specific needs at the time. For example, say you had an arbitrary number of items to set up and each had to have some specific computation to compute location, color, size, etc. To do this in QML, now you're forced to jump through hoops (which makes it harder to understand BTW). With C++ you can do it however you want.

It's hard to argue that a class definition and instances are all that much harder to use than a purely instance based thing. The programming world (as well as many other disciplines) has pretty much settled on the concept of definitions and instances, because it allows easy reuse. You can argue that the rest of the world is stupid, but that's a pretty hard argument to win.

"signals and slots" - again, I find myself wondering what you're talking about - it's not as though in QML you don't have to have signals and slots. In QML, you have to put them in using "when: <signal>" - not too much different than saying "<signal>.connect(functor)". And you can use C++11 lambda's to allow in-place definition of the slot. Or you can do pretty much anything else to your heart's content. The point is, it's flexible to suit the needs of everybody. And all this flexibility works out of the box. Don't need to spend a dozen or more Nokia engineers to reinvent the wheel when something already exists that works well - as so many are so fond of repeating ad-nauseum when it comes to implementing a C++ API. (Sounds a bit hypocritical, but hey, that's just me)

(continued...)

[cfreeloader]

(continuation from previous post...)

[quote author="jdavet" date="1335386303"]
Not that a Qt developer would have a problem to understand any of those, but interpreting foreign code that has all those concepts thrown together takes a lot more mental effort than understanding a declarative object tree consisting of clean, uniform statements of one of the forms

C++ just isn't optimized as a clean declarative definition language for in-place defined nested objects. The model of... 1) class definition 1a) member declarations 1b) constructor for member definitions 2) class instantiation ...is inconvenient for such a straight-forward declarative use-case and puts information that belongs together in separate places (which, if several levels of nested objects are defined, can become quite far apart for the outer objects).[/quote]

You can make a syntax as clean and simple as you want by further restricting the use cases for the syntax. If I develop a language to describe circles, I can just use a single number - the radius. The problem comes when you actually want to live in reality. You'll have a hard time convincing anybody that QML has been sufficiently used on enough "real" non-toy projects to know that it has sufficient syntax to support all reasonable use-cases. Especially when there is not a single example that I'm aware of where QML has been used to develop non-trivial applications. If you have an example, please post so I can be impressed. C++ has been used on an uncountable number of "real" applications. It's been in development over 30 years. Naturally, the syntax and language facilities have grown to support "real world" applications. The point again is even with all this extra flexibility and support for real world apps that, "... not necessarily overly verbose nor less understandable than QML".

[quote author="jdavet" date="1335386303"]
Also, the "streamlining" (as you call it) which you demonstrate e.g. for defining a state as...
@{ "GreenState", mouser.containsMouse, { this.color, "green" } }@
...looses the readability advantage of QML's "named property statements" idiom and doesn't really seem to appreciate the intended flexibility of such objects (most properties of most elements are optional, most elements allow child-elements, it should be easy to add more properties or potential child-elements in future versions).[/quote]
Well, if you don't like that method, you can pick from 20 other C++ ways to do the same thing. If I don't like "named property statements" in QML, what other choices do I have? Not many.

[quote author="jdavet" date="1335386303"]
As for practicality of implementation, I haven't dug too deep into the possibilities of C++11 yet, so I might be overlooking a few things that could be handled behind the scenes in your example, but I'm wondering...
In the C++ version, how would the Qt Quick engine know when to re-check the value "mouser.containsMouse" ?[/quote]

Just like any other signal somehow "knows" when it's been emitted. Something in the implementation does the emitting.

[quote author="jdavet" date="1335386303"]
As for the usefulness, how much would really be gained? A runtime cost would still incur during loading of the Qt Quick scene.
As I understand it, what the Qt Quick engine does is:

translate QML input into an optimized internal linked object tree in memory

run the Qt Quick scene according to those object definitions

With you C++ API, it would become:

translate C++ object input into an optimized internal linked object tree in memory

run the Qt Quick scene according to those object definitions

[/quote]
They are both declarative after all. Something must translate from the declarative description into something that is processable by the CPU/GPU.

[quote author="jdavet" date="1335386303"]
Regarding verbosity, you cheated a little by using a pretty concise coding style for the C++ example, but a line-number wasteful coding style for the QML version.
This is how the QML example would look with a coding style that's similarly-concise as the one you used for the C++ example:

@
import QtQuick 1.0

Rectangle {
width: 400; height: 400

Rectangle {
id: coloredRect
width: 100; height: 100
anchors.centerIn: parent

MouseArea { id: mouser; anchors.fill: parent; hoverEnabled: true }

states: [ State { name: "GreenState"; when: mouser.containsMouse
                  PropertyChanges { target: coloredRect; color: "green" } },
          State { name: "RedState"; when: !mouser.containsMouse
                  PropertyChanges { target: coloredRect; color: "red" } } ]

Behavior on color { ColorAnimation {} }

}
}@
[/quote]

I'd hardly call it cheating - I just copied and pasted from the docs - written presumably by the QML developers themselves. If anything, what you wrote looks even more similar to the C++ version I provided - further evidence that C++ provides nearly all the readability and succinctness of QML. At the same time, C++ provides dozens of other significant advantages. Since these have been stated so many other times, I will not repeat them here.

[capisce]

bq. You’ll have a hard time convincing anybody that QML has been sufficiently used on enough “real” non-toy projects to know that it has sufficient syntax to support all reasonable use-cases.

Do you consider a browser a toy project? http://snowshoe.cc/

[chaos6]

i believe it's need more for hard work to do it we need it really

[cfreeloader]

[quote author="capisce" date="1335392258"]
Do you consider a browser a toy project? http://snowshoe.cc/[/quote]

I looked at the source code, qml and all. Looks like a marketing gimick. So to answer your question a little more pointedly, yes I consider this browser to be a toy project in the sense of what would be required for an even moderately complex application of the likes that have been done using Qt in the past. If these guys had actually rendered the web pages using QML or even had some heavy duty interaction between QML and C++ to render the web pages, then I would have been highly impressed. As it is, WebKit is doing 99.999% of the work and QML is used to create some tab widgets and a few other things. This isn't very convincing as to why one should use QML versus C++. Let us see QtDesigner or QtCreator done in QML and then we'll start to believe that QML has everything you need to build applications of "real world" variety.

[cfreeloader]

[quote author="capisce" date="1335387147"]And a point about the run-time cost of parsing / translating of QML, the same thing exists in OpenGL, with GLSL snippets needing to be compiled into GPU-specific internal shading language by the driver's built-in compiler. Still, the result is high performance 2D / 3D graphics, and not that many people are complaining about it.[/quote]

For me personally, performance of QML is not high on my prioritized list of concerns. For me, the prioritized list would consist of:

Effectively disallowing the use of C++ to access any "modern" improvements to Qt GUI framework even though C++ is radically more flexible and has many language features and pre-existing libraries that could be put to good use to simplify design of non-toy GUIs.

Requirement to use QML to gain access to most recent Qt backend functionality, even though QML has been demonstrated to not have any signficant advantages over a hypothetical C++ API

QML is not proven to be useful to develop non-trivial apps (and no, Snowshoe isn't non-trivial application of QML). Language design is notoriously difficult to do right. C++ has been on the development path for 40 years (if you take C as a starting point). QML will never compete against that. qmake is at least one example of a hacked up language.

Requirement to learn a new language that has no use anywhere outside of Qt

Requirement to use JS (yes, I know you don't really need it, but from what I've seen, all non-trivial apps use it to some extent)

Requirement to learn JS when JS provides no significant benefit and is only really beneficial if doing significant amounts of web development.

Opportunity cost of Qt developers putting the cart before the horse and spending their finite resources on reinventing the wheel, rather than moving the framework forward in fundamental new ways.

Need to jump through hoops for anything more than minor QML/C++ integration.

Performance and run-time cost of QML/JS in comparison to compiled C++. Yes, they both must populate the scene-graph, but one must parse the QML and JS and then JIT the JS and finally execute it in order to populate the scenegraph. Sufficient performance for toy apps doesn't imply sufficient performance for non-toy apps. Also, why waste energy for mobile apps where battery life is so important especially when there's no good reason to do so. BTW, memory footprint will be bigger as well. In addition the footprint of all the supporting infrastructure (e.g. V8)

Lack of debuggability of QML and JS. If something were wrong in the implementation of QtQuick, you can't simply pull up GDB and single-step the code (which I've done with QWidgets). With a pure C++ paradigm, you can still do that. Again, by taking this step of defining a whole new language and runtime system, Qt developers have bitten off more than they can chew. Now they need a QML debugger. They should be leveraging as much stock stuff as they can and using their development resources/talents to really add value in places that matter.

Requirement for OS to support V8 JS engine. This is specifically bad in the case of iOS where it may be that Qt5 will not be runable due to this. Maybe this will not be a problem, but at this point it could very well be. Of course Nokia doesn't care about this (even though, for their own good, they should strive to be the leading provider of cross-platform development environment - but this is another whole thread).

Inability to use any of the readily available C/C++ static code analyis tools (e.g. Clang static analyzer) to help find bugs in JS script and other aspects of the UI.

[Guest]

I think some people are taking the wrong direction, the usage of JavaScript provides some benefits that cannot be realized in C++ through the same workflow. I don't think there should even be an attempt to make QML and C++ interchangeable to operate on the same type of objects. Not only because stock QtQuick components have a lot of QML specific stuff, but because they are optimized for use through QML, which is less flexible than subclassing objects in C++, thus the need of JS to overcome that lack of flexibility.

I fully realize it may very well require the design and creating of new components for an eventual C++ api, it would be the right thing to do, and the workflow will be a little different. For example, the type of property binding in QML is unnecessary complicated to emulate in C++, not that it can't, but there is really no need to do it exactly the same way, since C++ offers a more efficient ways, for example, overload the parent updateEvent and put binding code there, to be executed before each redraw.

I have read that other discussion people have been trying to redirect this thread into, and some people appear to have gotten the main point, we need a new and fully hardware accelerated GraphicsView, that I assume can be implemented through the SceneGraph, not simply slammed on top of it as it is currently done in Qt5. A hardware API centered aroung making avaiable and easy stuff like:

0. • built entirely on top of OpenGL/ES, the option of reaching into the 3rd dimension
1. • easy animation, state based, tween based, with control curves, timelined, etc...
2. • hardware accelerated drawing, using shaders that can easily offer 20-30 times performance increase
3. • easy integration of 2D shader based effects, like it is currently done for QML
4. • easy integration of 3D geometry and shading, a 3D centered sub-API with basic modelling and modifier capabilities
5. • better optimized for texture caching, automatic texture redraw when needed, draw and cache several states at once so even common static changes like button over, pressed are not continuously redrawn
6. • shared texture caching so that identical components or sub-components are efficient
7. • automatic multi-pen drawing to avoid costly painter state changes
8. • 2d and 3d collision detection, hardware accelerated IK animation and physics
9. • easy media IO - audio, video, image
10. • platform independence, so its features can easily be ported by the community to mobile platforms that are not dead end, since it doesn't seem Nokia will ever bother doing it
11. • OpenCL processing if supported, fallback to lower precision through OpenGL when absent

Making a native API with such capabilities is far more important and beneficial in the long run, and if that hypotetical API has a well designed fronted, I bet we'll see new components, optimized for it, stack up very rapidly, not even requiring Troll efforts, but entirely through the community.

I know that you can use GraphicsView, you can put it on top of a OpenGL widget and get some performance boost in many cases, I know you can use QQuickPaintedItem to get a custom painting item in QML(and be conformed to it), but those aren't really solutions.

Such an API, described above will effectively grant developers ultimate freedom, the ability to do advanced applications very few API's can offer out of the box and none of them can offer the speed and efficiency of native, platform specific binary. From basic, modern and fluid 2d UI, through 3d games and CAD applications, not just an API for the user interface, but an app engine. Adobe have already a solution like that, ever since the introduction of Stage 3D, capable of delivering astonishing "results":http://alternativaplatform.com/en/demos/crash/ , and Qt can the potential to do it even better, if unrestrained by the poor efficiency of interpreted languages.

I've been developing applications using Flash, but the moment you reach into some extensive logic, performance isn't there, AS is just as poorly performing as JS. I wasn't that aware of the fact until the moment I tried running Sumopaint on my tablet, on a PC Sumopaint works just fine, but on my Tegra2 tab performance was so poor the app wasn't really usable. Even apps written in Java, which is way better than JS are still sluggish compared to the little drawing app I developed and ported to Android with Necessitas, which has outstanding performance. I realize there aren't that many companies with the capacity to do something as advanced as Adobe did, but better, or in other words C++ NATIVE, but Qt comes very close to being able to provide such an API, because currently there is no similar API in existence (the little that to exist are either based on a slow programming language or not platform portable at all), which will inevitably translate into a huge advantage and make Qt very attractive to a wide range of software developers by offering something truly unique and irreplaceable (unlike QML)...

[capisce]

@c++freeloader

bq. If these guys had actually rendered the web pages using QML or even had some heavy duty interaction between QML and C++ to render the web pages, then I would have been highly impressed. As it is, WebKit is doing 99.999% of the work and QML is used to create some tab widgets and a few other things.

The UI is exactly what QML is meant for for, WebKit already has its own renderer. Noone's saying you should do everything in QML. Even if Creator were to make most of its UI based on QML, it would probably still want to write the code editor widget with a high dose of C++, since it's such a highly application specific component with very custom needs. You wouldn't expect Maya to write their 3D renderer in QML, but it could certainly be used for parts of their UI.

Here's another example of an application that has seen quite some use, a Spotify client for MeeGo: https://qt.gitorious.org/qt-labs/meespot/trees/master

bq. Requirement to use QML to gain access to most recent Qt backend functionality, even though QML has been demonstrated to not have any signficant advantages over a hypothetical C++ API

I've already mentioned that the base enablers QQuickItem (corresponding to Item in QML), QSGNode, etc are public API. It's just the sub classes of QQuickItem, such as Rectangle, MouseArea that are not exposed as C++ API at this point.

[jdavet]

[quote author="c++freeloader" date="1335391023"]C++ has been used on an uncountable number of "real" applications.[/quote]

Altough usually not as a pure declarative object-defining data language. Either XML or some custom solution has usually filled that role, even for C++ applications.

[quote author="c++freeloader" date="1335391023"]Well, if you don't like that method, you can pick from 20 other C++ ways to do the same thing. If I don't like "named property statements" in QML, what other choices do I have? Not many.[/quote]

20 different-looking ways to do the same simple thing, is not exactly a readability and maintainability dream come true. At least not unless all code you will ever deal with was written by yourself (and you can still remember what you thought when you wrote it).

[quote author="c++freeloader" date="1335391023"]Just like any other signal somehow "knows" when it's been emitted. Something in the implementation does the emitting.[/quote]

But "mouser.containsMouse" is not a signal, it's a property (which at any point in time can be either true or false).

[quote author="c++freeloader" date="1335391023"]Something must translate from the declarative description into something that is processable by the CPU/GPU.[/quote]

No, into an internal declarative description that is processable by the Qt Quick engine.

Unless you choose to embed JavaScript expressions or GLSL shader snippets inside your QML source, I don't think there will be any byte code compilation of any sort. The only thing that gets passed to the CPU is the compiled Qt Quick engine's code (which was written using C++).

[cfreeloader]

[quote author="jdavet" date="1335455361"]20 different-looking ways to do the same simple thing, is not exactly a readability and maintainability dream come true. At least not unless all code you will ever deal with was written by yourself (and you can still remember what you thought when you wrote it).[/quote]
The point is that in the real world, there are many ways of doing things for a reason. A language dictating the "one-and-only correct and true way" is a language that hasn't yet been used in the real world. A book for a 3 yr old is easy to read too. Doesn't mean that it's going to be considered a literary class.

[quote author="jdavet" date="1335455361"]But "mouser.containsMouse" is not a signal, it's a property (which at any point in time can be either true or false).[/quote]
A property that has the semantics of a signal.

[quote author="jdavet" date="1335455361"][quote author="c++freeloader" date="1335391023"]Something must translate from the declarative description into something that is processable by the CPU/GPU.[/quote]

No, into an internal declarative description that is processable by the Qt Quick engine.[/quote]
Which is ultimately imperatively executed by a CPU/GPU. Do you like arguing for arguing sake or do you actually have a point?

[lgeyer]

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.

QML is analyzed once at the time a source file is loaded to build a native representation, which then provides the same performance as beeing created in native C++ code. A compiler is beeing evaluated, which would shift analysis from run-time to compile-time, but as performance metrics have shown that the current run-time overhead is minuscule, it is currently on low priority.

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.

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. For doing so, Qt Quick utilizes the Meta-Object Information that is generated by <code>moc</code> and already present for every object in Qt.

Former native applications become non-native due to the use of QML.

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.

QtQuick requires applications to be created in QML and JavaScript, the advantages of the new graphical arichtecture (SceneGraph) can be used from QML only and C++ has been deliberately left out to push QML, which has made QtWidgets and The Graphics View Framework obsolte.

QtQuick exposes the API to C++ where meaningful and the SceneGraph can be used using both, QML and C++, one without the other. This includes all the building blocks for QtQuick, including the Animation Framework, the State Machine Framework and the Graphics View Framework (all of them beeing there before QtQuick). Every object created in QML is accessible in C++ and QML is fully extensible using C++. However, there is a trade-off between exposing internal classes of QtQuick and thus introducing binary contracts and the value to the developer (which is actually low, as there is no support for most QML features in C++).

The application and the business logic itself is still expected and required to be made in C++, because QML is mainly used to build user interfaces, not applications - the same way CSS is used to style QtWidgets, SQL is used to query data and PCRE is used to do string analysis.

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.

However, you cannot use SceneGraph with QtWidgets, because the imperative drawing model of QtWidgets is quite incompatible with the state-based drawing model of a modern GPU (where almost all the additional performance of QtQuick comes from). This is a technical limitation.

There is no way to debug declarative user interfaces created using QML, above all not using GDB.

GDB is a debugger for imperative languages, Qt Quick / QML has its own debugger suitable for declarative languages.

There are no advantages of using QML over C++.

QML is fully network transparent, each resource can be either local or remote, including source files. In addition, there is full tool support for creating QtQuick user interfaces, 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. 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++.

[lgeyer]

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.

Declarative user interfaces-languages are widely used and pushed, for example XAML, HTML5, XUL, SVG and Cocoa.

QtQuick / QML is a toy-language only, no real spplications have been ever created with it.

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.

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. A C++ QtQuick API will always be imperative.

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

Dynamic fluid interfaces are just for smartphones, which are still a niche market. Desktops require native looking and behaving applications.

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

X is better than Y, and should take precedence over Z.

No, but there are facts, and there is fiction. Basis of discussion should be the former, not the latter.

[cfreeloader]

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

[cfreeloader]

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