[Interest] Guide me through the Qt offerings for GUIs
ruilvo at hotmail.com
Mon Apr 19 12:01:31 CEST 2021
Well, let's then hope that Mr Volker Hilsheimer's statements hold to a
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.
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
>> 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 (slides ), 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.hilsheimer at 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.
More information about the Interest