Does Qt need a modern C++ GUI API?
-
bq. it is what I keep on using, but in that case you completely miss out on everything, done for Qt the last 3 years or so. That is the grand problem – QtGui is flawed by design, as a result, modernizing it is hard and awkward, QtQuick has the right design to enable neat modern features, but it is exclusive to QML without a public native API.
I don't agree. QtGui works perfectly well for the current applications. During development of our quite complex multi plugin "Qt application":http://www.cetoni.de/produkte/mikroreaktionssystem-qmix/software.html we hardly had any problems with QtGui or QWidget and there was nothing we really missed - and if something was missing we could implement it quite fast.
So what are you really missing from the development of the last 3 years?? QtGui works perfectly well for current desktop applications.
And for the future user interfaces, there is already a new solution under heavy development: QML.
I do not see the need for a C++ API for QtQuick. But this does not mean, that I think there should not be a C++ API. Maybe a C++ API will come - you never can tell. But at the moment it is more important to focus manpower on further development of QML desktop components. If QML works perfectly well and desktop components are available than maybe a C++ API will come (although I dont think it is required and that IMHO only a minory of the developers would use it).
And as a software developer one should always be open to new inventions and new things. If a developer stops to learn new things and stops to be interested in new trends and developments he can quit. And I think QML is e really interesting new trend and it looks really promising - will it be a success - I don't know - will it fail - I don't know. But I'm ready to learn something new - because it is part of my daily job.
-
[quote author="Jayakrishnan.M" date="1339661577"]Hope your words come true. I guess the ' Asha powered by Symbian ' is a typo. Lack of progress in Necessitas has been disappointing. Lack of info regarding Qt4ios also has been disappointing. I hope both of them attains production quality.[/quote]
Me too. ;-) But there are actually more quite bad news (as far as I can see), escpecially for Meltemi (you've already found the article).
Yes, it actually is a typo, they are powered by Series40 6th Edition.
-
[quote author="utcenter" date="1339663530"]Again, no offence, but you shouldn't be asking me this question unless you've been living under a rock for the last 20 years.[/quote]
I've always been told that there is "... significant overhead ..." and a load of "... stuff you need to do on top of C++, wrapping, importing, proxies and so on..." and I've always been asking what this "... stuff ..." actually is and where this "... overhead ..." does come from and how relevant it is for the actual application.And even though I've never got a mentionable answer I still keep asking because although creating quite complex applications QtQuick has never required me to add a load of stuff nor did I suffer from significant overhead so far.
Yes, creating QtQuick items is different from creating a QtWidget - for the simple fact that the scene graph requires a declarative, state-based drawing model instead of the imperative drawing model we know from QtWidgets and the Graphics View Framework (which is also still available using QQuickPaintedItem). This is nothing a native interface would change.
But I'm quite sure you have some examples, code snippets, use cases, benchmarks or anything, which visualizes or materializes the significant overhead and the load of additional work, for me, do you?
Please don't get me wrong, I'm not beeing a drag here. I'm just in search of something I can actually look at to understand the worries (and to re-evaluate my perception if neccessary).
-
@Uwe - no one argues about how well QtGui works, as I said it myself, it is still what I use. The problem of QtGui is not with its functional aspects, but its fundamental design, which makes it less-than-optimal to create modern GUI. It is still possible, you have multi-touch, you have states, you have animation, it is just harder to work with it because it QtGui wasn't conceived with those things in mind and designed around them.
You keep insisting that developers who want a C++ API are a minority and efforts are rightfully focus almost entirely on QML, but this doesn't really fit with the opinions, voiced by the Qt developer base here in this thread. I am sure there are plenty who call for a C++ API for the wrong reasons, but there are also quite many who really see the fundamental design flaws of QML and its inapplicability in many development scenarios. You act as if QML is the best thing since sliced bread, but it isn't, and it is far from addressing all development scenarios. There are too many people for whom QML is unattractive, and focusing the development efforts of Qt entirely on QML is literally turning the back on those people. People like me are in a suboptimal situation whether we go for QML and deal with its overheads or stay with QtGui and deal with its fundamental design flaws.
@Lukas - I am not talking about performance overhead, that would be critical on mobile platforms, which QML doesn't seem to support any time soon, at least not the major ones. On the desktop the performance overhead is negligible. I am talking development overhead, where you have to wrap and export every program component to QML, something you don't have to do with QtGui. And again, it is not hard to do once or twice or even 10 times, but as the number of such elements increases so does the overall overhead, to the point it becomes more prominent than the savings you get from using those components in QML. Gosh, it is not that hard of a concept, why is it so hard to wrap your mind around it? It is an overhead that cannot be demonstrated with a code snippet, I am sure you know the workflow of interfacing native components to QML, the overhead is in doing it over and over again. It is not an issue of complexity that can be indicated in a code snippet, it is the total instances of snippets like that you don't really need but have to do in order to take advantage of modern GUI features absent from QtGui.
-
====================== 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) {}};@
Quoting c++freeloader....
Simply beautiful -
[quote author="utcenter" date="1339668714"]I am sure you know the workflow of interfacing native components to QML.[/quote]Yes, I do.
[quote author="utcenter" date="1339668714"][... and you know] the overhead is in doing it over and over again.[/quote]No, I don't, and that's why I'm having such a hard time to "... wrap [my] mind around it.", because for me there wasn't and I have not seen any evidence yet - and you obviously can't provide either - that there is for others. It is contradictory to my personal experience and I'm not able to relate it with the information you provide.
Please take another look at the "documentation":http://doc.qt.nokia.com/4.7-snapshot/qml-extending.html or one of the examples on how interfacing QML and C++ actually works. In most cases it is as simple as a call to "qmlRegisterType<>()":http://doc.qt.nokia.com/4.7-snapshot/qdeclarativeengine.html#qmlRegisterType and in any case there is no additional effort in comparison to a native interface.
It is a prejudice and does not reflect reality.
-
So you expect of me to convert an entire application to QML and expose my commercial code just for the sake of showing you the code increase and design changes QML demands? And sadly, in most of the cases it goes beyond qmlRegisterType. You seem to have missed the many instances I explicitly stated it is nothing hard, just tedious to do over and over again.
Let me assure, I am quite aware of the reality of extending QML in C++ and not prejudiced even a tiny bit.
Lets just agree to disagree, we both know the direction of your attempts of discreditation, the more people in favor of a new native API you "prove" prejudiced, clueless, biased or whatnot, the more you undermine the validity of this poll.
It is funny thou, since I recall you saying you too want a native GUI API, and yet you spend so much effort to convince me QML is so good and effortless to use no one really needs a native GUI API. It is even more absurd than justifying QML as an attempt to escape the bore of standard desktop components, and then launch QML desktop components.
-
[quote author="utcenter" date="1339676069"]So you expect of me to convert an entire application to QML and expose my commercial code just for the sake of showing you the code increase and design changes QML demands? [... ] you spend so much effort to convince me QML is so good and effortless to use no one really needs a native GUI API.[/quote]No, I don't. I just ask you to provide proof for the accusations you've made.
-
Accusations? What accusations? I don't recall accusing anyone of anything...
Does the interfacing of native classes to QML require extra code? It does! Now take a chill pill ;)
And it is rather naive from you to point to those tiny, trivial, simple examples, written for basic educational purposes as they are the reality of practical application code.
-
I have never used QML and I do not have plans to use it. IMHO it's interesting for beginners who are doing simple projects. But, at least it will be a easy door for beginners to enter into Qt. This door has benefits and the costs for this benefits should be balanced. That's the fact.
-
You loose a lot by having this attitude ;) QML is a really nice tool, it's not a monster and is unlikely to eat you.
Anyway, you can do as you wish, of course. I mean to hint at the fact that perception about QML tends to change rapidly once one actually tries it, or at it has in my case.
-
@sierdzio : I'm sure that I loose a lot by having this attitude. I did not mean that I'm disagree with existence of QML or using it. It does not fit with projects I'm working on or I have worked on. My wings are much more powerful with C++ API at this time. This is about how you think. As I said, many people are happy with QML and this is enough to let it be there and improve it. This is a dynamic world.
I will try using it as you said it may change my opinion about it. -
Yeah I kind of suspected that this is what you mean, and I've meant no harm :)
Just couldn't stop myself, sorry.
-
[quote author="cincirin" date="1334815916"]I believe Apple Animation Framework is what Qt C++ GUI have to follow[/quote]
That could have been my words. Like Apple or not but the iOS GUI is the best prove of a smooth working UI that can be coded natively. Besides that it would bring native looking buttons etc. (in the world of the Cupertino fruit there is something like a native looking widget)
-
[quote author="hardcodes.de" date="1353420894"]
[quote author="cincirin" date="1334815916"]I believe Apple Animation Framework is what Qt C++ GUI have to follow[/quote]That could have been my words. Like Apple or not but the iOS GUI is the best prove of a smooth working UI that can be coded natively. Besides that it would bring native looking buttons etc. (in the world of the Cupertino fruit there is something like a native looking widget)
[/quote]
I agree with these. For ios development we have the ability to visually design the UIs and access them in the application and apply any effects or animation. A declarative framework is not needed here. I feel GUI should always be done using a visual designer unless you need your GUI to be dynamically generated based on some application parameters. The underlying code generated can be xml, qml, c++ or anything. Both ios and Android uses xml. But ios hides this behind the interface builder. Hand creating a GUI is tedious whether you are using Qml or c++. The ios approach seems the best. We have a lot of trouble writing complex GUI for Android since we have to hand create all the needed xml. Same is the case with Qml. A visual designer for Qml together with the ability to access these components from c++ is the best approach. In my experience, Qml is tough for the html people and something alien for the c++ folks.
