[Interest] QGraphicsView and OpenGL in Qt6

Michael Jackson mike.jackson at bluequartz.net
Fri Dec 8 22:41:00 CET 2023


On Dec 4, 2023 at 9:55:26 AM, Volker Hilsheimer via Interest <
interest at qt-project.org> wrote:

> On 30 Nov 2023, at 12:16, Filippo Rusconi via Interest <
> interest at qt-project.org> wrote:
>
> > I know things change but after that little exercise I am not sure anyone
>
> > would ever convince me to try QML on the desktop again. Period. If
> QWidgets
>
> > goes away we would probably just move to another language all together
>
> > rather than try QML. QML on Phones and tablets? Sure. Go for it. Desktop,
>
> > stay away. Far Far away.
>
>
> +1000
>
>
> It is some time now that I feel like Qt going the Qml route in a preferred
>
> manner with respect to the QWidget route (more revenues, I guess). I hope
> I am
>
> wrong with this feeling. I would be terribly sorry to have to adopt a new
>
> library set for widgetry…
>
>
>
>
> First of all: yes, we know that there is still a bit of a way to go before
> Qt Quick can support everything we want to be able to do on the desktop.
> What was broken or missing a few years ago might be available, or work
> better, today.
>
> But QML vs C++ and Qt Quick vs Qt Widgets is not at all about revenue,
> it’s about technology.
>
> QML is a better language for building UIs than C++.
> And the modular, scene-graph based and hardware accelerated rendering
> architecture of Qt Quick is a better architecture than the comparatively
> monolithic, CPU-bound approach of Qt Widgets.
>
> Of course, you might disagree with those statements. But if those two
> statements are true for mobile and embedded, then they are - in principle -
> also true for the desktop. Again, we know there’s work to be done to
> improve desktop-specific use cases.
>
> So yes, our focus is on making Qt Quick better, and new UI solutions will
> be designed primarily for Qt Quick. But our focus is also on the
> technologies that allow mixing the two, so that you don’t have to pick one
> or the other. You can keep your widget code and add Qt Quick via
> QQuickWidget to it already today.
>
> Volker
>
>
>
Again, my experience is with QML under Qt 5.15 at the time my company had
it’s disastrous try at QML. Qt 6.2 was out at the time I think but we had
to stick with 5.15.x due to requirements from our client. But even *if* we
would have been allowed to use Qt6, QML simply lacked the needed widgets
and ease of customization that we required on the desktop. The main issue
was the lack of QTreeView. Since QML was targeted at mobile screens, the
lack of a workable TreeView is understandable as that isn’t how
hierarchical information is navigated on a mobile device, but on desktop,
it is the norm and specifically was needed by our project in order to move
“data” between nodes in the tree. There was a QML QTreeView that was
commercially available which didn’t work with our licensing so we were
stuck. We spect a large sum of funding from the contract just trying to get
a workable QTreeView. The other major tipping point, ironically enough, was
the ability to easily style the application. We would spend hours and hours
just trying to get simple ui bits styled. We had a professional UX group
help design and come up with the needed CSS but it just didn’t work at the
end of the day.

You can say that one language is better than another all you want, but if
that language is simply missing features that are needed then nothing else
really matters. If the debugging experience is not as good as the other
language, it doesn’t matter. If I am locked into a specific development
environment which objectively is not as good as others out there, then the
language isn’t good enough.

At some point in the future, QML will surpass QWidgets in all those areas.
In my opinion, that time still has not arrived for desktop apps that need
certain kinds of widgets. For the simple basic “hello world” trivial app
demos that come with Qt, everything looks really nice. It is when you
actually try to create something more complicated is where the entire
development ecosystem falls apart with QML. I wanted to like it. I wanted
it to work. I could see the potential in QML to make slick “modern” apps
but potential is just that. Potential. Potential doesn’t pay my employee’s
salaries. I can’t go to clients and say what we delivered has “potential”.
I need something I can deliver *today*.

Just my 2 cents.

—
Mike Jackson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20231208/d6c3ae36/attachment.htm>


More information about the Interest mailing list