I still think they could give a nice equivalent of Qml Ui's advanced capabilities for C++ too,instead of reinforcing Qml...
I still think they could give a nice equivalent of Qml Ui's advanced capabilities for C++ too,instead of reinforcing Qml...
One hour and I am still thinking why you posted here and not in the Tech board or in the General Discussion thread..
Code - functions and small libraries I use
It’s 2014 and I still use printf() for debugging.
"Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson
they do. from what I've seen, Qml is mostly used to draw the UI. yes, it has some basic event handling and scripting functionality, but it's mostly about drawing the UI outside C++ code, so that an interface can be designed and loaded at runtime without a recompile. basically, you would use the painting and event classes from the Qt GUI Module to do all the stuff that qml/quick does, at least with respect to drawing controls and handling events. that said, you can still load qml objects from C++ code, and use the C++ code as the backend event handlers and other such logic.
Not everything. QML has support for some animation features (if i remember/read correctly) not easily supported by QtGUI/QWidget. Internallly QML uses a scenegraph that makes use of OpenGL in a way that QtGUI doesn't.
My main gripe is, why didn't they add this functionality in C++ and then made QML an interface to those parts? As it is today you can not get this capability directly from C++ (without doing alot of lifting yourself). To me they just did things backwards...
O_oQML has support for some animation features (if i remember/read correctly) not easily supported by QtGUI/QWidget.
Would you be willing to give an example?
I'm not trying to be a jerk or anything; it just happens that to my knowledge, while the scenegraph stack used by "QML" was feature built for "QML", many engines are available to core "Qt" that use the same underlying primitives and shared drawing contexts.
Soma
yes, but with QML, the possibility exists to define an animation in a few lines of QML code instead of potentially hundreds of lines of C++. I've only dabbled a bit with QML/Quick but designing an interface is far easier and quicker (pun intended, of course) than with pure C++ code, assuming no RAD GUI designer is being used.
O_o
Either you misunderstood me or I misunderstood him.
If we look at the "Qt" API, which animation features of "QML" aren't easily supported?
Are we talking about animations that are a part of the exported scenegraph API? If so, there exists several scengraph widgets for "Qt" that can trivially expose the same or similar facilities to C++.
Are we talking about a legitimately missing API reference/callback/hook from the native API to even enable such drawing? (An example might be displaying a rendered scene in a secondary widget, like a button, without jumping through the hoops of creating an "owner drawn" widget.) If so, a bug/request needs to be filed.
I seriously don't know which scenario here was intended. I'm used to working with a lot of API so both situations are familiar, but I was fairly impressed with "Qt". I wouldn't have thought that "Qt" developers would bother exposing an API layer only reasonably accessible though a first-party facility so I kind of just assume that the "heavy-lifting" is available as an API from within C++.
Soma
We are talking about QML providing functionality not available in the public Qt API. With the old way, QtGui, everything I did in the designer I could do in pure C++ by hand. I did not have to rely on anything at all outside of C++ and the MOC. This is no longer true for QML. I can not do something equivalent of
I can not use QtQuick functionality in my own classes without going through the QML file, unless I want to use the Qt internal API which is not guaranteed to be binary compatible. Want to add a MouseArea to your own class? It is essentially not possible to use QtQuick without using qml files. Here is some more information: How to create an Item from C++ (without QML? | Qt Project forums | Qt ProjectCode:#include <QtQuick2> ... QQRect *pRect = new QQRect(size, position, parent); QQApplication::addToScenegraph(pRect); ...
Why would you want to use C++ as your UI description language? Are you some kind of masochist?
Just describe the UI with QML and write the important part of your application (the logic) in C++.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Well I must say I can enjoy some pain at times :P
I'm not saying QML is bad, I haven't used it enough to form any form of judgement of it. However I'd like the option of using pure C++ and not have go through the QML parts. QML also introduces a javascript runtime to glue interface events to C++. Again not saying it is necessarily a bad thing, however I would like the option to not have to go through javascript for this.
I wouldn't necessarily recommend "QML" because I don't have much experience with it, but using tools that can design a "GUI" and build live is a solid win.Just describe the UI with QML and write the important part of your application (the logic) in C++.
If nothing else, such tools can go a long way in simplifying internationalization and localization.
You ever spent hours tuning a "progressive display" "GUI" only to find that one of your target languages needs a much larger set of regions? I have.
That's what I thought.We are talking about QML providing functionality not available in the public Qt API.
You'd do yourself a favor to look into other scenegraph widgets for "Qt".QML also introduces a javascript runtime to glue interface events to C++.
Just because the "Qt" developers chose to expose their API through a dependency on a JavaScript framework doesn't mean you can't find a solution.
Soma
I had a similar experience going from Windows Forms into WPF/XAML and indeed the run time linking had an impact in debugging for example. When the gluing wasn't correct you don't get the nice "failed at this line" behavior. Also quite slower. It was annoying, you are not alone But you just get use to it and then realize the advantages you get as well. I almost always had the option to use code, though. Haven't touched QML but I would be curious if you can give an example of something that you are forced to do in QML?
I want to say there is "good" pain and annoying pain, but I guess we should just not go down that path