Live data from Hacker News

Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

qt.io

71–80 of 107 posts

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#71

Pyotherside [1] == QML+Python is really a nice combo. Build a schedule app [2] some time ago for ubuntu touch. [1] https://github.com/thp/pyotherside [2] https://github.com/delijati/fosdem-qml/tree/master

I'm curious, why are you using this instead of the official Python bindings?

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#72
post #7

Earlier quoted context omitted.

Do you mean it’s no point in writing a GUI toolkit in Rust?

You'd never be able to compete with qt anyway.

You could - if you have several hundred full time developers working on it for years. This probably means you pay them, but the count of full time developers is the important part.

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#73
post #44

Earlier quoted context omitted.

Yeah but Qt does a lot more, to match Qt you would need a similar effort. I remember some time ago was a popular article shared here on how hard it is to render text when you need to consider all the languages and all the font types and all the options. So it wold be easy to paint some shapes and some english text in the happy case and it would probably be enough for video games but then you need Widgets that will wo…

The point is if you start with a good foundational layer, then a community can build greater things on top of it. Of course, it will take time and if you're looking for a great library that can do everything out of the box, now , then you should pick Qt, there's no doubt about that.

the good foundation layer needs to be designed correctly. Otherwise you have SVGs and English, but you have to tear the whole thing up when someone asks for translations. Then someone asked for the next feature and you have to tear it all up again. This is a hard problem.

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#74
post #72
post #7

Earlier quoted context omitted.

You'd never be able to compete with qt anyway.

You could - if you have several hundred full time developers working on it for years. This probably means you pay them, but the count of full time developers is the important part.

That cant be true. Why does QT need hundred of developers when the core product can be done by a single person? (see Sciter)

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#75

I'm favorably disposed to QML, but for it to actually replace Qt Widgets it'd have to provide: better out of the box desktop integration, a public C++ API and a better WYSIWYG UI designer.

I've created a desktop app using QML (the model is written in C++) that looks pretty good in my opinion[1]. I second the out of the box desktop integration, Qt Quick components should look and behave more like native ones. Although they're very easy to customize so it's not too big of a problem. But definitely something to consider if Qt wants better adoption.

[1] https://www.get-plume.com

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#77
post #70
post #50

Earlier quoted context omitted.

But who'd contribute when qt is already there? Getting contributions is nearly impossible. Getting them for a not so useful vanity project is probably impossible.

> But who'd contribute when qt is already there? Because it will be written in pure Rust (with all the memory-safety advantages that come with it).

>Because it will be written in pure Rust (with all the memory-safety advantages that come with it).

I do not think that Rust enthusiasts will waste their free time reimplementing complex, boring stuff in Rust, only if they are paid, otherwise they will work on a new Rust game engine, or TODO app, or AI, WASM or something cool. Something as big and as high quality as Qt can't be implemented by 3 guys in weekends, maybe if they get Patreon support os they can work full time they can get the easy part done.

I do not think Qt suffers from memory issues so nobody would pay to rewrite it, but maybe we will have some super simple GUI framework you could use for GUI in video games or some simple English only , zero customization , simple apps.

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#78
The only thing about QML that I like that QWidgets does not have is the anchor-based layout system where you can anchor widgets relative to the edges of other widgets. Other than that QML seems more like a solution for embedded interfaces (car media centers, dashboards, kiosks, etc) where you roll your own look, rather than desktop applications.

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#79
post #76

I'm favorably disposed to QML, but for it to actually replace Qt Widgets it'd have to provide: better out of the box desktop integration, a public C++ API and a better WYSIWYG UI designer.

Qt Design Studio not enough?

Qt Design Studio is buggy and heavyweight. It lacks integration with Visual Studio, has a bad integration with Qt Creator. It doesn't produce clean .qml files. Qt Designer (the one used for Qt Widgets) is better in those regards.

Anyhow, this might be a controversial opinion, but the best experience I've had with WYSIWYG UI designers was with Netbeans Swing Editor and VS Windows Forms Editor. The IDE integration was seamless.

Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

#80

What's the QML story when using pyside6/pyqt? I know it's possible to use both but I was wondering if it's worth it, and how painful it is to add to an existing app?

If your existing app is a pure CLI app, you just expose your Qt objects to qml and it should be fairly smooth sailing. If your existing app is a QWidgets app, then not sure how much benefit you'd have when mixing QML/QtQuick with your QWidgets side of things. We did implement such a thing at a little project before... where the "canvas of items" was written in QML and the remainder of the UI was QWidgets. For our use…

Awesome that's exactly what I was wondering. Yeah, my app is mostly qwidgets with the layout in code. It's pretty painful to do the layout so QML does look tempting. At least it's probably better than doing it with qtdesigner!
Post reply on HN