On Mon, Dec 04, 2023 at 02:55:26PM +0000, Volker Hilsheimer via Interest wrote: > > On 30 Nov 2023, at 12:16, Filippo Rusconi via Interest > > <interest@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++.
Is it? By what metrics? Having GUI parts and non-gui parts in the same language is a huge advantage in my book. Whether that language is C++ or something else is secondary to being the same language. Of course, if this one language is standardized, kind of typesafe, AOT compiled, coming with a wealth of tools for debugging, profiling, static analizers etc. that's a non-negligible bonus on top. Last week there was quite a few talks and some talking about how to pass data kind-of-effeciently between a C++ backend and a QML frontend. Good to hear that some cases are solvable nowadays, but at the end of the day this whole field of problems does not exist if there is no language divide between the components - one can use the same kind of mechanism (up to "no mechanism at all") to "communicate" between frontend and backend that one would use to otherwise separate the backend into smaller functional bits. > 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. Which, at least for "my" applications does not matter. And I still see no reason why hardware accelearated rendering backend would imply the use of a certain frontend language, specifically none that embeds a full interpreted or at best JIT-ed language with the expected consequences on performance. Besides, QGLWidget was hardware accelearated before QML got invented. > 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. Andre' _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
