[Qt-interest] C++ or QML

[Jan]

Oliver, thanks for your thoughts about this.

Jan




Am 28.06.2010 18:00, schrieb Oliver.Knoll at comit.ch:
> Jan wrote on Monday, June 28, 2010 4:57 PM:
>
>>> ...with QML you reach your goal
>>> (hopefully) faster, since editing QML
>>> files is - by design - meant to be very easy. At the possible cost of
>>> some performance.
>> Well, isn't "fast and easy" enough to make it a better choice?
>
> Well, I was just assuring that we are talking about the same "superiority" here. QML is by no means "more powerful", that is everything you create is also possible (with more effort) using the traditional Qt Designer/C++ approach (when it comes to animations the effort in C++ is clearly much higher in C++ than by defining some XML properties ;)
>
> Disclaimer: I have never used QML in practise, but since QML sits "on top" of the Qt GUI API I think my assumption that they are equally powerful is pretty sound ;)
>
>> But if QML makes ui design easier, faster and has other advantages
>> (e.g QML vs bad c++ code ...) it seems rational to use it in desktop apps
>> as well.
>
> Hmmm, again this very much depends on the complexity of the desktop app: if we are talking about a "multimedia player" with a few fancy play/stop/pause and track editing menus, then maybe QML is the way to go. Or a "weather forecast" widget which downloads the weather forecast and displays some nicely animated clouds...
>
> If we are talking about a "large" (without definition ;) application with e.g. some OpenGL widgets, toolbars, lots of custom widgets, complex signal/slots dependencies between widgets, stacked widgets, maybe GUIs which are dynamically created by plugin code etc., I think the Designer/C++ way is way more maintainable than a huge (single? multiple?) XML kind of file.
>
> But in the end it is a matter of taste, too. I like the fact that my compiler tells me that when renaming a widget variable that I get a compiler error there and there. "Outsourcing application logic" into separate XML files can be tricky (but to be honest I don't know at which point with QML you would notice that the widget name you have declared in your "QML" file does not match with the "resource" name you have specified in your C++ code - at link time?)
>
> And again, I don't consider it totally bad either to even design a mainwindow with a typical toolbar, menubar etc. in Designer bad. And you won't ever see this code in C++ because this is also auto-generated! All you see is the C++ code which connects to the signals emitted by your widgets (and this part I guess you also have to code with the QML analogon).
>
> To my understanding you mostly gain with QML when it comes to "animating your GUI" ("Pimp my GUI") and when you want to look your widgets "exactly like the graphics/marketing departement has told us" (and not as the OS guidelines suggest aka "native"), as Thiago already pointed out; the C++ analogon would be custom Qt Styles, but they are "expensive" to implement - or "Qt Style Sheets", but they are limited (by the behaviour of the "native widgets") and you pay a performance penalty for complex/lots of widgets.
>
> But for "native (desktop) applications" designing your widgets with the Qt Designer, connect to the signals and implement your logic in the corresponding C++ class is totally easy as well - in the best case you see hardly any "Qt GUI API" calls in your own code (except querying the values/states of your given widgets - but I guess that is the same "application logic" code you'd have to write in the "QML world" as well.
>
>
> Cheers, Oliver