Does Qt need a modern C++ GUI API?
-
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.
-
[quote author="Jayakrishnan.M" date="1353471883"]A visual designer for Qml together with the ability to access these components from c++ is the best approach.[/quote]"Using the QtQuick Designer":http://doc.qt.digia.com/qtcreator/creator-using-qt-quick-designer.html
"Using QML in C++ Applications":http://doc.qt.digia.com/qt/qtbinding.html
[quote author="sierdzio" date="1353412782"]I mean to hint at the fact that perception about QML tends to change rapidly once one actually tries it...[/quote] -
I recently started using QML, I'm really newbie. I like it but I also agree that it's much more powerfull to use the designer. The problem it that designer seems to be somewhat broken.
Another problem to me it we have Meego components, symbian components, (and also desktop components ???), but if I choose a new general QML project in QtCreator, the available components don't even have a button, I have to do it myself. Souldn't not be avalible many more cross plataform components (code once deploy everywhere) ? Am I missing something ? -
[quote author="john_god" date="1353499489"]I recently started using QML, I'm really newbie. I like it but I also agree that it's much more powerfull to use the designer. The problem it that designer seems to be somewhat broken.
Another problem to me it we have Meego components, symbian components, (and also desktop components ???), but if I choose a new general QML project in QtCreator, the available components don't even have a button, I have to do it myself. Souldn't not be avalible many more cross plataform components (code once deploy everywhere) ? Am I missing something ?[/quote]You are right, of course. Those elements are missing due to many reasons, mostly due to the long and dramatic death of Nokia support. Now Digia has a huge amount of work on their hands, and a lot of it is more important than components at the moment. I don't know where it will go in the future.
Maybe setting up a new playground project with the aim of adding new cross platform components is the way to go. maybe waiting for desktop components maturity is better... I don't know.
-
Another issue to me is the documentation. I already found some good links, but I miss a good QML book. Until now it was perhaps to early, but in the following months, with the final release of Qt5 and QtQuick 2, I think it's time for a book. I even filled a request to packet publish, since those guys are open to sugestions.
-
You only find the designed better because you are new, I can assure you, in time you will really get to prefer typing and leave the visual workflow for where it belongs - Photoshop.
The lack of in depth educational materials on QML is a big concern, like 90% of the stuff that is already available boils down to putting together something simple to demonstrate the eye candy features of QtQuick. And even thou every tool of QML is being explained, there is a HUGE gap between knowing what tools are used for and actually putting together something complex and functional with those tools.
Unfortunately, the biggest flaw of QML for me will not go away ever - with the risk of repeating myself, QML is great for quickly assembling existing components into an application, but if your applications depend entirely on custom and unique components, the interfacing to QML becomes a tedious and pointless endeavor. In most of the cases the interfacing components to QML in order to use its GUI features takes up more effort than implementing similar GUI features with QtGui and OpenGL on hand, which is the reason for this discussion.
Unfortunately, neither Nokia, nor Digia seem to have respect for the opinions of the people who voted here. That is the reason I migrated most of my work away from Qt, so the last few months I bothered to learn a few JS frameworks in depth, and I dare say QML comes nowhere near the flexibility and dynamics of the HTML/JS stack. Surely, QML is much cleaner, but offers poor separation and only a fraction of the functionality. It is ironic how the main bullet point of QML is "dynamic" GUI when in reality QML is practically static compared to using something like jQuery, which allows to build UI in a procedural and imperative way, which is IMMENSELY more flexible than having a static mark up. I often find myself starting off with practically no HTML markup, just a div to which I can attach whatever content I want dynamically, with whatever styling or animation.
And while flexible and dynamic, HTML/JS comes short of all the stuff I need, for which I am sticking to Qt with the good old QtGui, since essentially all the scenarios HTML comes short are also the scenarios where QML is useless. Hopefully we will at least see Android and iOS support soon which will surely breathe some life into Qt.
-
my opinion , every thing z possible with Qt c++
