[Interest] Guide me through the Qt offerings for GUIs
ruilvo at hotmail.com
Thu Apr 22 17:06:51 CEST 2021
"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:
Which again, is absolutely trivial do to with C++ and polymorphism. And
a pointer/reference instead of adding macros in 20 places and the
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.
Em 22/04/2021 15:37, Konstantin Shegunov escreveu:
> On Thu, Apr 22, 2021 at 4:59 PM Jérôme Godbout <godboutj at amotus.ca
> <mailto:godboutj at 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"
> 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 at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Interest