Does Qt need a modern C++ GUI API?

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

[cfreeloader]

@temp

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?

[capisce]

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/

[capisce]

@c++freeloader

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

[cfreeloader]

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

[Guest]

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

[capisce]

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

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

[capisce]

@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?

[capisce]

@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

[Guest]

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

[capisce]

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

[broadpeak]

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