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

91–100 of 107 posts

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

#91

Post by saidinesh5 »

guappa wrote: post #55
password4321 wrote: post #39

What is the licensing story for Qt these days, my understanding is some portions are only available under commercial license or the GPL (vs. others also under the LGPL)? https://news.ycombinator.com/item?id=34291701

For 20 years people have been commenting that Qt doesn't have LGPL license. This has been false for the past 20 years but people feel the need to write it in a comment any time they read "qt" in a title.

Honestly, Qt company is to blame for this imo. They've relicensed things so many times that you need a complicated chart to figure out the license:

https://www.ics.com/sites/default/files/images/licensing.png

https://i0.wp.com/embeddeduse.com/wp-content/uploads/2023/01...

I've lost track of things and I know companies that still stick to Qt 5.6 because of the licensing issues..

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

#92

Post by saidinesh5 »

mardifoufs wrote: post #80
saidinesh5 wrote: post #47

Earlier quoted context omitted.

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!

Ah. Anchor based layouts are nice and work well until they don't. Especially when dealing with multiple resolutions, different sized content/padding etc.. They did work really well in simpler projects of mine though.

When using QtQuickControls2 , i have started falling back to RowLayout, ColumnLayout, GridLayout etc: https://doc.qt.io/qt-6/qtquicklayouts-overview.html - which are similar to what we've had in QWidgets

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

#93

Post by saidinesh5 »

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.

I thought slint supports a Qt backend for desktop apps: https://slint.dev/releases/1.3.2/docs/slint/src/advanced/bac... ?

But yeah I've had same issues when using QtQuick for desktop use cases.

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

#94

Post by marwis »

pjmlp wrote: post #76
felipefar wrote: post #48

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?

Can it even do basic forms by dragging and dropping of components?

I recently tried and failed. It was either doing absolute positioning or failing completely - for example dropping components onto grid would just place them into cell 0,0. There was no way to design form with mouse.

I used a lot of different UI designers in the past and all of them were heaps and bounds better.

As sibling points out NetBeans Swing designer (with Matisse/GroupLayout) is the best, along with VS WinForms (although these tend to be non-scalabale)

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

#95

Post by JanisErdmanis »

saidinesh5 wrote: post #91
guappa wrote: post #55

Earlier quoted context omitted.

For 20 years people have been commenting that Qt doesn't have LGPL license. This has been false for the past 20 years but people feel the need to write it in a comment any time they read "qt" in a title.

Honestly, Qt company is to blame for this imo. They've relicensed things so many times that you need a complicated chart to figure out the license: https://www.ics.com/sites/default/files/images/licensing.png https://i0.wp.com/embeddeduse.com/wp-content/uploads/2023/01... I've lost track of things and I know companies that still stick to Qt 5.6 because of the licensing issues..

I didn't know that QtQuick is GPL. That is a commonly used dependency for QML apps.

I guess I misread the chart. Can you explain what it means for QtQuick to be purple under the GPL/LGPL section?

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

#96

Post by saidinesh5 »

JanisErdmanis wrote: post #95
saidinesh5 wrote: post #91

Earlier quoted context omitted.

Honestly, Qt company is to blame for this imo. They've relicensed things so many times that you need a complicated chart to figure out the license: https://www.ics.com/sites/default/files/images/licensing.png https://i0.wp.com/embeddeduse.com/wp-content/uploads/2023/01... I've lost track of things and I know companies that still stick to Qt 5.6 because of the licensing issues..

I didn't know that QtQuick is GPL. That is a commonly used dependency for QML apps. I guess I misread the chart. Can you explain what it means for QtQuick to be purple under the GPL/LGPL section?

That's the QtQuick 2D renderer. They mostly use that on devices without a decent 3D GPU.

That was also Qt 5.7. With Qt 6, QtQuick itself is part of QtGui now. It is available under LGPLv3 and additionally under GPLv2, GPLv3, Qt for Device Creation Professional (Pro) and Qt for Device Creation Enterprise (Enterprise).

But the embedded companies I've worked with tend to avoid LGPLv3 because of the anti tivoisation clause. (To let the end users swap out the Qt libraries on your devices).

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

#97

Post by bluGill »

mathverse wrote: post #74
bluGill wrote: post #72

Earlier quoted context omitted.

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)

Details are hard. The core might be doable in a basic form by one person, but there is a lot more than the core that needs to be done. All those little details add up - they are only a small improvement, but all those small improvements adds to polish.

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

#98

Post by joeld42 »

ComputerGuru wrote: post #86
self_awareness wrote: post #5

Earlier quoted context omitted.

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 cou…

I tried for a year to learn XAML (mostly using Avalonia) and it just never clicked for me. Feels like it needs too much secret insider knowledge that you're only going to get with that decade of C#. To much is implicit and magical, and it was very, very hard to trace through what was happening when something behaves unexpectedly.

I got to the point where I could build a basic app with it fine, and I might pick it up again if I find the right project, but it just never seemed like it was adding anything, just making simple things more convoluted to me. I also found the C# community to be pretty hostile and insular, not in an intentional way, just more of a "hey we really want to help but everyone is too dumb and lazy to learn these hundreds of 'basic' things", and there's no good places to learn outside of noisy discords, SEO Spam q&a sites, and weird and vaguely hostile chatrooms.

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

#99

Post by self_awareness »

ComputerGuru wrote: post #86
self_awareness wrote: post #5

Earlier quoted context omitted.

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 cou…

I haven't used XAML even once, but I've tried to use FXML (JavaFX), but generally it felt too superfluous and inconsistent. But I'm not sure how XAML and FXML are related (if at all), also I'm not sure if XAML is even used outside C# and Windows?

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

#100

Post by prewett »

singularity2001 wrote: post #37

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

HTML was designed for documents, which it does adequately. But for an actual UI, you need to be able to position things easily. HTML/CSS just has all these gotchas all over the place because the defaults are just unsuitable for UI. If you work hard enough you can something working, but QLayouts are so much easier. Then after that you have to work in a language that makes every error a runtime error and doesn't even distinguish between between float and int. Which you can work around by adding another layer, namely TypeScript. All these layers just add the complexity. Qt Widgets is one of the best-designed UI APIs.

I've kind of given up on Qt, though:

- they seem to want to go in the QML direction, and if I wanted to use JS I wouldn't be using a C++ library

- their interpretation of LGPL has historically required making the entire Qt library downloadable from your website, which is inconvenient. (This may have changed with Qt 6?)

- it never looks or works quite right on macOS. In particular, text in comboboxes is just not centered vertically correctly, and it drives me nuts.

Post reply on HN