"Anything that's non-trivial ends up with (a) huge boilerplate wrapper(s)."
Q_INVOKABLE, Q_PROPERTY, etc... The Qt stuff crawls into what would
otherwise be just business logic because you need to access something.
I've linked this before:
https://stackoverflow.com/questions/66618613/qml-c-classes-with-bring-your-own-component
Which again, is absolutely trivial do to with C++ and polymorphism. And
a pointer/reference instead of adding macros in 20 places and the
Q_PROPERTY lines...
Basically we're coupling the whole backend to the GUI framework.
I'd prefer to write C++ than to learn Loaders and whatever else there
is... But seems that people do love QML a lot (again, shouts out to KDE).
Opinions, I guess.
Rui
Em 22/04/2021 15:37, Konstantin Shegunov escreveu:
On Thu, Apr 22, 2021 at 4:59 PM Jérôme Godbout <godbo...@amotus.ca
<mailto:godbo...@amotus.ca>> wrote:
I wonder if it would be possible to totally declare the QtQuick
scene from C++ without any Qml files actually, with Qt6 you got
C++ binding and the Qml is compiled to C++ anyway. Maybe I miss
something but it could be possible to actually only write C++ to
create the actual scene?!
It will have been (even in Qt5) if the classes were public. In the end
the QML engine is really a glorified object factory. There are other
problems with that though, one such example is the tree control:
GPL/Commercial for QtQuick, while with widgets you get that directly
with the same license as the whole library (there are other such cases
too, if I'm not mistaken) ... and the mentioned already "native"
look'n'feel.
I would not actually do this myself but it might attract some user
that are scare of declarative
Many of us avoid it not because we are 'scared' as such, but because
of other more practically-relevant reasons.
I stop using QWidgets a few years ago and I don’t miss it a bit,
haven’t seen anything I could not achieved into Qml yet, some are
a bit trickier than they should but in the end prototyping and
modifying the GUI is so quick, I often make the change live when
I’m working with my graphic designer and KDAB GammaRay (just need
to apply those change after).
Well, I can build a nuclear power plant at home - probably I can
achieve it, but the fact of the matter is, should I? There are a
couple of considerations here. Firstly a lot of code is already
written with the widgets and even with best practices it's generally
not trivial to do a 'face-lift'. Secondly, QML fails to sell its point
to desktop devs due to its C++ integration being a great PITA already.
Anything that's non-trivial ends up with (a) huge boilerplate
wrapper(s). And while graphics performance does matter, it's not
typically the driving force on desktop, where usually we value
convenience over performance (on desktop you rarely are pressed for
resources). In fairness, exposing the property bindings natively to
C++ is a step, no doubt about it.
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
