At least, it would be convenient to reap the benefits of QML: HW
acceleration, for example.
I personally don't care for QML. I would prefer to write everything in
C++. But that's me. If there was a "no-QML-Quick-API" I'd be so much
happy. No more gluing code and properties and questions like this:
https://stackoverflow.com/questions/66618613/qml-c-classes-with-bring-your-own-component
I could just use what I know: C++... The talk Volker linked in this
thread talks a lot about "working easily with your designers". But I'm
just me... So the team point is moot. I also don't have a background as
frontend engineer, so I never bothered to learn JS. I guess it's
implicit that this is another advantage of QML. Just take the armies of
frontend devs that exist in the web design market and employ them on GUI
applications, cheaper than a C++ programmer. Likewise, that sure is a
reason of why Electron and web backends on JS are so popular (and the
results so disastrous, sometimes). Some seem to agree with me:
https://github.com/uwerat/qskinny
But I think the "dream" is the same feature set as QWidgets as Qt Quick
Controls. And some things to make desktop usage actually decent, like
native dialogues and especially menus. So that on Macs the menu goes to
the top bar (also on some GNU/Linux graphical configurations), etc etc.
When I look at frameworks from like the .net ecosystem, which is growing
so fast, I see exactly that. Practical example: https://avaloniaui.net/
is totally rendered with SKIA#, but there is
http://reference.avaloniaui.net/api/Avalonia.Controls/NativeMenu/. Also,
allowing the window to resize without it glitching all over, and other
desktop/productivity things.
Or, in reverse, if the RHI backend for QWidgets really comes to life,
and QWidgets keeps receiving some love to be up standard with the latest
OSes, and receive a public RHI Painter API instead of QOpenGLWidget, and
look decent on hi-dpi, that's a winning product right there. In my
opinion, anyway...
That said, I wouldn't support scrapping what's already done. Just
improving it. Like the native look and feel in QML actually going
somewhere, and having a feature-equivalent set to QWidgets for desktop
work.
Rui
Em 21/04/2021 16:48, Giuseppe D'Angelo via Interest escreveu:
On 21/04/2021 17:42, Jason H wrote:
Personally, I think the exsting QtQuick element should be scrapped
and just focus on QML versions of the existing Widget functionality.
I love the QML syntax, hate that it's not just a layer on top of
widgets.
That said, I still really like both.
Do you mean something like this
https://github.com/KDAB/DeclarativeWidgets
or actually reimplementing the widgets themselves?
Thanks,
_______________________________________________
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
