Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

qt.io

Post reply on HN
Print view View original

81–90 of 107 posts

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

#81

Post by vilunov »

Kelteseth wrote: post #6
sourcegrift wrote: post #2

As a Rust user, very happy with qmetaobject-rs. It was really a breeze to make a basic GUI for personal use ... I would also add an opinion: Qt is a great fit for Rust. GUI toolkits (=presentation layer) is best done declaratively and QML does an amazing job at it. Keep in mind that making a GUI kit, specially for 5 platforms in a way that it runs and feels uniformly across them all is a herculean task that returns n…

Have you tried https://slint.dev/ ?

I have tried it, and I feel like this is not a good toolkit for desktop apps. It's great for embedded hardware with custom interfaces such as vending machines, car on-board PCs, screens in public transport, but it does not have that native look-n-feel on desktop, at least not out of the box.

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

#82

Post by agent327 »

singularity2001 wrote: post #37

Does anyone else think that QT is mostly overkill and HTML is good enough in most cases?

No, just the other way around in fact. Qt applications don't come with a starting requirement of ~300MB just for the mandatory webbrowser - before adding any of your own code.

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

#83

Post by eYrKEC2 »

sourcegrift wrote: post #10
heavyset_go wrote: post #3

Earlier quoted context omitted.

Can you compare it with GTK bindings for Rust? I'm a big fan of QML, but I've avoided Qt on Rust for some time due to poor experiences with earlier bindings a while ago. At the time, using GTK, imgui, etc were a bit friendlier on Rust than Qt. Hoping this has changed.

Sorry, no experience there but it's possible that just for big screens, GTK might beat Qt ... (I think KDE also supports the "legacy" Qt + Rust option in some way ...) But my point was mainly about the (almost) impossibility of building a well functioning cross platform UI kit. I honestly believe that effort should not be spent in that direction when a reasonably open source and well functioning option already exists…

I find QML satisfactory for big screens. Made an app back in Qt5 and my main dev machine was a 4K, 43 inch LCD TV -- it did fine on the big screen. No limitations in that regard that I could see.

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

#84

Post by eYrKEC2 »

sourcegrift wrote: post #2

As a Rust user, very happy with qmetaobject-rs. It was really a breeze to make a basic GUI for personal use ... I would also add an opinion: Qt is a great fit for Rust. GUI toolkits (=presentation layer) is best done declaratively and QML does an amazing job at it. Keep in mind that making a GUI kit, specially for 5 platforms in a way that it runs and feels uniformly across them all is a herculean task that returns n…

The only issue with declarative is when declarative is a prison instead of a fantastic and reasonable guideline. One of the very nice things about react is that you can escape pure declarative syntax to use actual javascript/typescript. Every declarative DSL/language/format that I've used has approximations like QML's [`Repeater`](https://doc.qt.io/qt-6/qml-qtquick-repeater.html), but eventually you will want and need some weird loop or logic that is most easily and succinctly expressed in a proper programming language -- at that point, you'll need to do some angry hack that unrolls one data structure into another so that you can iterate over that one with the limited logic in the declarative format. And then you'll have to keep the two models in sync.

All doable, just a pain.

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

#85

Post by ComputerGuru »

vilunov wrote: post #81
Kelteseth wrote: post #6

Earlier quoted context omitted.

Have you tried https://slint.dev/ ?

I have tried it, and I feel like this is not a good toolkit for desktop apps. It's great for embedded hardware with custom interfaces such as vending machines, car on-board PCs, screens in public transport, but it does not have that native look-n-feel on desktop, at least not out of the box.

Didn’t they migrate to Fluent UI style or am I mistaking them for someone else?

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

#86

Post by ComputerGuru »

self_awareness wrote: post #5
sourcegrift wrote: post #2

As a Rust user, very happy with qmetaobject-rs. It was really a breeze to make a basic GUI for personal use ... I would also add an opinion: Qt is a great fit for Rust. GUI toolkits (=presentation layer) is best done declaratively and QML does an amazing job at it. Keep in mind that making a GUI kit, specially for 5 platforms in a way that it runs and feels uniformly across them all is a herculean task that returns n…

I've always tried to build GUIs declaratively, but always failed to see the advantages over a traditional imperative building blocks. It's all good if we want to display a static dialog box, which is always the same, but complications arise when we want to do some nonstandard stuff. And this "nonstandard" is defined differently depending on the framework, but for some frameworks this status is achieved pretty easily.…

Have you seriously looked at/studied XAML?

I was convinced that XAML was the perfect answer for rust and had the idea that I could write an independent XAML library/engine that rust appdevs would use and then match to a backend that would codegen the XAML into code that utilizes its corresponding api.

I had a sample that worked with both imgui and one of the other rust gui engines (not immediate mode) to prove it could be done. Biggest benefit was abstraction from actual ui toolkit choice (inspired by Windows where you can use a subset of the same XAML with WPF, Avalonia, WinUI 3, UWP, Noesis, Uno) and being able to take an imperative ui library like ImGUI and use it in a declarative fashion. Moreover, you could reuse existing XAML designers or avail yourself of XAML export functionality in some design software, without having any of that be rust-specific.

I put out feelers in the community to gauge interest but I think XAML is too foreign to most FOSS devs that picked up Rust early on and people couldn’t see what I saw in it (having worked with XAML for over a decade in C# land).

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

#87

Post by wiseowise »

ahartmetz wrote: post #15
soundarana wrote: post #11

> Another thing you can immediately see is that the QML version of the algorithm is generally much slower than the JavaScript version. As noted above, this is due to it being built on QObjects rather than JavaScript objects. Of course, QML is trying to beat the browser at it's own game, but can't match the billions invested in browser performance. Qt classic is dead, and QML is a less featured, less documented, under…

QML is not trying to beat the browser at its own game. It is not made to display, you know, websites (and web apps), with a stack that was originally created for documents, and that still shows. QML is not JavaScript, it's a neat UI description language that uses JS for dynamic aspects. It's not less featured, it's differently featured: it has features that have been directly designed to create user interfaces. Unlik…

It is irrelevant what was the original purpose of HTML, what matters is what problems it can solve now.

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

#88

Post by ahartmetz »

wiseowise wrote: post #87
ahartmetz wrote: post #15

Earlier quoted context omitted.

QML is not trying to beat the browser at its own game. It is not made to display, you know, websites (and web apps), with a stack that was originally created for documents, and that still shows. QML is not JavaScript, it's a neat UI description language that uses JS for dynamic aspects. It's not less featured, it's differently featured: it has features that have been directly designed to create user interfaces. Unlik…

It is irrelevant what was the original purpose of HTML, what matters is what problems it can solve now.

It can do it, the way you can hammer a nail with a small axe. It's not exactly terrible, but you can tell that it wasn't made for it.

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

#89

Post by eYrKEC2 »

diath wrote: post #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.

I think QML was originally designed as "mobile first", but I think it works fine for desktop interfaces as well. I wrote an app that ran on Android as well as Windows and I liked it just fine for that task.

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

#90

Post by LtWorf »

self_awareness wrote: post #22
notyoutube wrote: post #9

Earlier quoted context omitted.

I've got a potential example; I always wondered how that would be achieved with something like slint or qml: With tools like xournal++ or other things like document processors, you can usually define your own panels, reorganize them, move them around, add icons or separators, etc, and all of that in a drag&drop fashion, live from the program running. I feel like having a (compile-time) declarative description of that…

Yes, panels are one example. Which panel goes to which window corner? What is the resize policy? It will probably be read from the file according to user preference, so it can't be hardcoded declaratively in QML. What is the current theme? Window position? Maximized/minimized state? Those need to be read from preferences and applied at runtime. I can declare a listview. What are the columns? Those are probably read f…

I think it works completely fine in QML.

Qt has had panels and splitters that you can move around at runtime since forever. There's a function to call to save the state and restore it when loading. What's the problem?

Post reply on HN