[Interest] Guide me through the Qt offerings for GUIs

[Rui Oliveira]

"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 <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" 
> 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 at qt-project.org
> https://lists.qt-project.org/listinfo/interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210422/2e68ff7d/attachment-0001.html>