Well, let's then hope that Mr Volker Hilsheimer's statements hold to a
bright future.
As I said before, I wouldn't even mind to wait for the RHI backend on
Widgets if that meant a cleanup up effort of the error log.
Let's see what the future brings.
At this time, I guess I'll stick to Widgets for my particular application.
Thanks!
Em 18/04/2021 22:34, André Pönitz escreveu:
On Thu, Apr 15, 2021 at 11:25:08AM +0100, Rui Oliveira wrote:
I want to write a desktop application. This desktop application would not
involve displaying lists of things, which seems to be what all
tutorials/guides/courses are about, especially on the QML side. This
application would involve some "custom graphics", namely a FFT display,
and a "waterfall" display. You can google for "GQRX" and you'll know what
I want.
And then I looked at Qt, and:
First thing I have looked at were QWidgets. I feel comfortable staying in
the C++ domain. To implement said custom widgets I gave a shot to a class
inheriting from QOpenGLWidget. And honestly, the experience wasn't bad at
all!
But, I feel very hesitant to start a project on QWidgets. It feels like
starting a project on dead tech. Although, I did watch Giuseppe D’Angelo's
talk in Qt Desktop Days 2020 ([1]slides [1]), and looking at slide 19,
there seem to be prospects of evolution. My attention goes especially to
"Accelerate widget rendering & compositing through RHI". Will QWidgets
really have a RHI backend? And a QRhiWidget option? Or maybe just QWidget
and everything HW accelerated? I can dream...
I know QWidgets are no longer "interesting".
Depends whom you ask.
QWidgets are robust. QWidget based applications don't need glue code to talk
to C++. They have overall low maintenance need from a user's point of view.
A Qt 4.2 application from 2006 has good chance to require no or only marginal
changes to run with 2020's Qt 5.15.
Qt Quick/QML on the other hand needs significant glue when talking to C++
backends. Error detection at "compile" time is rarer than in the widget case.
There have been several rounds of major changes to the technology during the
last decade, with impact on user code. The language is not standardized, and
practically unused outside a Qt context (Ok, there's QBS. Anything else?),
I personally would expect more changes to come here, but overally with an
effect to make Qt Quick application development more similar to what widgets
were all the time: Ahead-of-time compilation, better integration with C++, use
of standard compilers, debuggers, profilers, static analyzers, ...
Even KDE moved on from them...
If I only could use sarcasm on this mailing list...
In summary, it would seem that my options for the desktop with Qt are two
self-competing technologies: one "half-dead", one "3/4-baked"... I'd
really love to be wrong.
I understand that this is the natural interpretation of most of the messaging
around Qt Widgets and Quick during the last decade.
I'd like, however, point out that comments like
From: Volker Hilsheimer <volker.hilshei...@qt.io>:
"TL;DR: Qt Widgets will be with us for a long time, and we’ll continue to
maintain them and +make sure that they continue to work and look great on
future versions of the various operating systems as well. There’ll probably
always be applications for which the widget concepts are a perfect fit."
have not been common in 201x, but do show up in 2021. Mark Twain comes to mind.
Andre', not speaking for his employer.
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
