Does Qt need a modern C++ GUI API?
-
@pierrevr. Perhaps you could create a writeup that shares the knowledge you've been able to acquire about QtQuick2 internals through your familiarization of the source code? I'm sure there are any number of people who could use that knowledge as a kickstart to their own familization process.
-
I mean, it is so OBVIOUS all those decisions were made to pave the way for issuing statements like:
bq. "QML is a requirement for modern GUI"
A data structure describing language a requirement for GUI? Damn it, and me, the stupid one thought it was a modern, hardware accelerated backend that was the requirement, SILLY ME...
It could have been any other form of text just as well. QML is as much a "requirement" for modern UI as SVG is a "requirement" for vector graphics or XML for only god knows how many things. It's just foolish.
@minimoog77 - thanks for bringing those cliches to my attention, It is only the n-th time I read such insightful clarifications that manage to miss all the points all over again:
bq. .ui files in Qt 4.x are XML, yet nobody complains about these.
Missing the point - because you were still free to do it in a programmatic, imperative way besides a descriptive, declarative way. AND THE ONLY GLUE you needed to access XML defined UIs was a single ui pointer, nothing like with QML. Unlike QML, XML was not MADE a requirement, it was an option, the usage of which brought none of the drawbacks of QML. And wherever you chose XML or doing it the old school way, you still got the same backend, same features, same performance, unlike with QML.
bq. Simply exposing the C++ interface of all QML elements won't buy you anything, as the most important feature of Qt Quick (bindings) still can't be handled that way.
Missing the point - because what people want is a public API to use the new backend, not a C++ interface for QML elements, just give us a nice and well documented API and we will make our own components, people want access to the C++ backend, there is no need to carry the burden of interfacing all QML centered stuff to C++
bq. If you need to create your own QML elements in C++ we have QQuickItem and QQuickPaintedItem, which form a very good and solid basis.
And those help us avoid QML how? Oh, wait, it doesn't!
bq. That's a strongly biased poll due to the wording. And it's missing the points the Lars has been trying convey, but some seem to ignore.
It is Lars who is missing the points, thus the disagreement with his points which do not account for the points, we don't ignore Lars' points, we are well aware of those already.
bq. This poll has no value. Regardless of who is right or wrong, the wording is completely partial to making QML look bad
I am happy you can disregard the needs of so many people with such a light hand. My question to you is whether any of those words, used in the poll is not true? Isn't QML extra syntax, doesn't it require an interpreter, doesn't it require JavaScript for basic stuff like property binding, doesn't JavaScript require a virtual machine, doesn't the limitations of QML require glue code and glue objects to extend with C++??? Which one of those are partial to making QML look bad, I didn't even hint to those being bad, just presenting them as the full entourage that comes with QML, which may not be familiar to some people who only know QML in the form of a few snippets of rectangle objects. We've been presented with the benefits of QML on countless occasions, I just focus on the drawbacks just to make it even, and I don't even present them in a negative way that states those do not need to be, but in a way that states those should be OPTIONAL.
And furthermore, do you really think people are that stupid to be fooled by my treacherous, cunning and deceitful use of words? LOL
bq. If you’re unhappy that the project leadership does not share your views, and if you really want a C++ API, just take a good look at the Qt sources, and write an API…
I only started familiarizing myself with Qt internals a couple of weeks ago, and it’s not such a big dealWhy don't you do it then, when you find it that easy? You will have the gratitude of so many people?
bq. temp, you could be right, but I’d prefer not to speculate on intentions
I prefer the same, but if we are given nothing more, what else are we left with? Speculation is always a last resort in my book.
-
".ui files in Qt 4.x are XML, yet nobody complains about these."
This isn't count!
I have used the Qt from version 3. At that time the Designer wasn't so reliable, and its knowledge run behind the full API.
So, I used Qt always from scratch: only in C++ (*.h and *.cpp).
I know, today the QtCreator much more clever than before. But I use no the designer in the IDE. I follow Mark Summerfield (author of the official Qt book!) technique, building projects only from cpp source code. -
bq. Simply exposing the C++ interface of all QML elements won’t buy you anything, as the most important feature of Qt Quick (bindings) still can’t be handled that way
Can someone please explain why the above statement is true (or not)?
-
@broadpeak: My point was, agreeing with mlong, that the poll isn't even closely neutral enough.
Just to clarify on my views... Although I am generally fond of native code, I believe QML is a good approach to UI. But seeing the discussion, "who can shout the loudest" still comes to mind and, respectfully, I will go back to my work.
-
With regards to "who can shout the loudest". What other choice does one have at this stage if one isn't able to "do it yourself" and there is so much inertia and false information in the system due to years to promulgating the "goodness" of QML and years of developing QML by dozens of engineers.
-
The one thing I honestly don't get is why are some people acting like I am the devil's advocate and that I am standing for some evil cause what will somehow be harmful to people?
Since when is the option of sticking to C++ and offering your users the most efficient solution at the expense of a little extra work a bad thing?
Can somebody perhaps answer?
-
[quote author="c++freeloader" date="1335165426"]
For example, perhaps, some set of people might be interested in putting together C++ classes that mirror the currently published QML elements. The problem is that at least for some of these, it is difficult to know where to even start. If one of the current developers could perhaps create an example of what a C++ API class could look like and an explanation of how it interfaces to the lower level API's then some volunteers could get started looking at this example and actually make some progress.
[/quote]Seems both you and temp ignored my previous comment, where I pointed to the C++ API exposing the QtQuick items: http://qt-project.org/forums/viewreply/83016/
-
And for further detail you might be interested in Alan's comments on the qt development mailing list: http://lists.qt-project.org/pipermail/development/2012-April/003413.html
I think it's a better idea to discuss there, as the discussion will reach more of the developers behind scene graph / qt quick / qml.
-
capisce - Well, this is exactly what the whole point is about - tailoring a nice public API. So a Qt engineer managed to come up with some ugly code to make a biased example of how tedious would it be to use Qt Quick with C++, what a surprise!!!
@QQuickCanvas canvas;
QQmlEngine engine;
QQmlComponent component(&engine);
component.setData("import QtQuick 2.0; Rectangle{}");
QQuickItem* item = qobject_cast<QQuickItem*>(component.createObject());
item->setX(10);
item->setY(10);
item->setWidth(10);
item->setHeight(10);
item->setParent(canvas);
canvas.show();@What about this:
@#include <QtQuick2>
QQuickApplication myApp; // contains engine and surface
QQRectangle item(10, 10, &myApp); // avoid three lines by using that amazing C++ feature, the constructor
item.moveTo(10, 10);myApp.exec(); // shows the entire hierarchy@
And it is not like a contemporary compiler stack cannot hold at least half a megabyte of objects, usually quite a lot more, but feel free to instantiate the item dynamically if you care that much about the significant overhead of dynamic memory allocation:
@QQRectangle *item = new QQRectangle(10, 10, 10, 10 &myApp); // define both dimensions and location in the constructor, why not?@
Although I don't really think this is nessesary, as the class should be fairly small footprint, and resources such as its image cache are supposed to be internally allocated dynamically anyway, since they vary.
I do realize you can make it ugly and you do realize it can also be made too nice for many people to even bother with QML and company, so WTH?
A nice, intuitive public API can reduce that code quite a bit, so instead of those ugly and unnecessary 11 lines we end up with something neat like:
@#include <QtQuick2>
QQuickApplication myApp;
QQRectangle item(10, 10, 10, 10, &myApp);
myApp.exec();@And no, it is not my responsibility, neither is it in my capacity to walk after the entire task force behind the project and make nice public APIs, unlike me you get paid to do that kind of stuff. As I said on numerous occasions, it will take me more time to do it from scratch that patching your messy, undocumented private API. You designed it, you know it, for you and your team it will be tremendously easier to do it, you get paid to do it, you chose not do it the right way right from the start and instead center it all around QML, it does appear to be your responsibility, I am not asking you to come over and do my job, so why do you expect that of me?
As I already said, if you have that much problem designing a neat public API, I am offering my assistance totally free of charge for the collective benefit of all Qt developers, I give you a design for an elegant C++ frontend to Qt Quick, you do the heavy lifting and hide that ugly code in a nice, neat wrapper. Qt Quick gets more public, everyone is happy.
-
Although I dislike temp's provocative style of writing (no offense meant, just my reception) - he (or she? don't know) has a point. I think QML is in fact a very nice additional feature to Qt. I can think of a lot of cases when I would rely on a technology like QML (e.g. it is very easy for a design team to create mock-ups with QML that may be evolved into fully functional UIs) but:
If you provide such a nice and seemingly natively supported feature like QML there should also be an easy way to access these features without actually using a new language but from within the already existing API. There are many development teams out there without the capacity (money or time) to invest into training for QML.
Regarding the "it's open source - so just contribute"-point I saw mentioned in this thread: Just because you may contribute content to a repository it does not mean somebody with a good ideas has the required abilities/time/... to do so :)
-
bq. As I said on numerous occasions, it will take me more time to do it from scratch that patching your messy, undocumented private API.
Since you again ignored the part of my earlier that pointed you at the current private API, here's a direct link: http://qt.gitorious.org/qt/qtdeclarative/blobs/master/src/quick/items/qquickrectangle_p.h
It won't be made public for Qt 5.0, but nothing's stopping you from trying out that API, or writing an add-on that exposes it. Just be aware that it comes without SC / BC guarantees.
Alan on the other hand was offering an alternative that would be SC / BC, and of course it's a bit more tedious, but you could in theory write your own C++ wrapper around it, exposing it with a nicer API. Just because Qt doesn't offer everything straight away doesn't keep you from writing a little bit of extra wrappers in the short run.
-
[quote author="Daniel Eder" date="1335181849"]Regarding the "it's open source - so just contribute"-point I saw mentioned in this thread: Just because you may contribute content to a repository it does not mean somebody with a good ideas has the required abilities/time/... to do so :)[/quote]
If nobody has the required abilities and time to do so, then it won't happen. In fact, it's not about the abilities or the time. It's about the financial investment of developing and maintaining the Qt codebase. And frankly, I don't really understand what we're hoping to achieve here.
Even with open source, there's no free lunch as they say, and Qt developers are only that, paid developers. If none of the major contributing employers (Nokia for the most part, but also Digia, KDAB, Accenture, Intel...) judge it interesting to invest in a C++ API, then it's indeed unlikely to become a priority anytime soon.
It's a meritocracy where Nokia happens to be the party investing the most, but luckily, it's no longer a closed group. So if there is another company out there that wants to pay several full-time devs to work their way up to a contribution point where they are part of the decisional level of Qt, then what's stopping them? Just don't expect other companies to pay for something that has obviously been judged not a priority for them. I know it sounds a little cold, but I think that's really all there is to it. -
[quote author="c++freeloader" date="1335171302"]bq. Simply exposing the C++ interface of all QML elements won’t buy you anything, as the most important feature of Qt Quick (bindings) still can’t be handled that way
Can someone please explain why the above statement is true (or not)?[/quote]
It is true. Well, at least most of it. The thing is that normally you have an object with some property, and you can bind that object's value to another value in some overloaded method, like the paint event. This is somewhat tedious and has to be specific for every different scenario. And in QML you are isolated from all this, unless you dig into creating a custom object in C++, and this is where JS comes in handy for some wiring of properties.
That being said, there are alternatives to that in C++, and while they have their overheads, those are minimal compared to the overhead of having a running JS VM and JS execution.
One solution that comes to mind is instead of storing the value of a property, the object stores an address of a property, so binding to another object property becomes fairly simple, but in case you want a regular property you need to instantiate that type and pass it to the object, effectively binding to another object again.
You can also have a bool whether a property is set or bound, and a union that can either hold an address of a property in the case of bound or the actual property in the case of set. You can use bit packing to minimize the space used by all those bools for every property.
You can also instantiate a binder object (can even be a part of the QQApplication too) which may take any number of bindings between objects and properties in any order you want to, it will not be automatic as it currently happens in QML with JS but it is not that much of a pain too, and its overhead will once again be minimal compared to the overhead QML induces.
Last and least, as I mentioned, you can have an empty virtual method like for example bindEvent, which you overload and add your bindings there, but in this case you have to crawl up the hierarchy and shoot in the blind to connect to an object you know is there. That is why I chose this method last.
There might be other ways to do it as well, who knows, those are just a few that come immediately to mind. The main hardship with doing property binding in C++ is you have to think a little, which is not that bad at all if you ask me. And it is not always a good thing to relieve people of thinking, just look at the disaster the relieving of physical activity has done to the world - an epidemic of overweight and obesity. Believe it or not, this happens to the mind too. That is partially why people coming from other languages find C++ such a pain. It is like making a fat guy run for his meal :D He won't like it despite the fact it is actually good for him.
-
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.
-
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.
-
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:
- QML is just so much more readable and easier to use that I can't imagine anyone ever wanting to use C++
- You can't easily do things in C++ that you can do easily in QML
- 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.0Rectangle {
width: 400
height: 400Rectangle { 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) {}};
@