[Interest] Guide me through the Qt offerings for GUIs

[Rui Oliveira]

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.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.