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?
Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis
31–40 of 107 posts
Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis
#32[flagged]
The problem with Flutter and Dart is that it changes so often; a 1-year old codebase is probably always non-compilable on a newer Flutter version. Even the language evolves quickly; I did some app on Flutter one day, only to discover two years later that the language itself evolved to support nullable types, and the official way of migration was to "just create a new project from scratch and copy your files to this new project, fixing compilation errors", because the amount of small items to tweak was too high.
Another problem with Flutter is that the build system is arcane, nobody understands it, save for framework authors. It's being marketed as "you don't need to understand it, just push this button", until something breaks, and something always breaks from time to time.
One could argue that it's good that the ecosystem evolves to a better version; but the problem is that often this "better" is different for different people. If we're aligned in the same set of definitions then maybe it's a positive thing, but when the definitions diverge, a problem starts to be visible.
So I wouldn't say that using Qt/C++ is harder than Flutter/Dart. Maybe for one-off easy apps that are forgotten about a few months after creation. But for long-term programming and maintenance, Qt/C++ beats Flutter every day of the week.
Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis
#33Earlier quoted context omitted.
> even if I can write some GUI in a "rusty" way, it won't suddenly speed up things because GUI is almost never a bottleneck. Nor are any of the other things people use Rust for, but that doesn't seem to reduce the enthusiasm any.
Rust does not make your rocket fly faster, but it lowers the chance that it would explode mid-flight.
If that's your reason for using Rust then safety is as useful in a GUI toolkit as anywhere else (indeed I'd say more so - GUI toolkits tend to involve lots of hierarchies and callbacks that make it easy to get confused about ownership, or get into unexpected states).
Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis
#34Earlier quoted context omitted.
Do you mean it’s no point in writing a GUI toolkit in Rust?
It would make sense to have a library that can do basic Svg/Canvas things, in Rust. From there, people can write all sorts of GUI libraries.
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 work with different user preferences, different languages, different color schemes, different DPIs, different platform conventions. Then you want to access the clipboard, the App settings folder, the notification system, maybe embed a webview to show soem html content ... Qt does a lot of things if your job is to make a professional complex Desktop application starting from basic building blocks and wasting your time on the Widgets and platform stuff then on business logic is not a good investment. If you are a hobist and writing Rust makes you super happy then I invite yout o continue.
Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis
#35Earlier 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.…
I think I get what you mean. In my experience, declarative frameworks are great for simple UIs but don’t scale all that well with UI complexity. Eventually you find yourself doing somersaults and handstands to achieve what you need with them and find yourself wanting to fall back to a boring old imperative framework. Granted, my experience is with SwiftUI and Jetpack Compose, not QML but it doesn’t seem like developi…
SwiftUI is still relatively young and... idiosyncratic. I hate how hard or weird it makes some basic things. (empty, transparent element with an action attached just to handle an event of the window appearing?)
But there are some really good systems available. .NET WPF is great overall for example. I could of course complain about how things are implemented and how mvvm is not baked in and how converters are too big and many other details. But I never needed to hack around the declarative part - that always just worked.
Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis
#36Earlier 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 feel like half the things you describe as needing to do at runtime are ok to exist in the declarative QML, but as a property with a signal. Position? Property. Basic/advanced view? Property. Splitter config? Property. Etc.
Leaving some things as parameters that can be adjusted in the model doesn't make the GUI not declarative. Preferences are just fine in a declarative world. Some things are harder than others, so list views that handle very generic data may need to be built manually, but those are exceptions.
Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis
#37Does anyone else think that QT is mostly overkill and HTML is good enough in most cases?
Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis
#38Does anyone else think that QT is mostly overkill and HTML is good enough in most cases?
The traditional widget-based Qt up to 4.x was a pretty good application development framework (not just a UI framework). From that point of view, both "modern" Qt and HTML are overkill.
Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis
#39What 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)?
Re: Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis
#40I just wanna say I've been a fan of Qt and its contribution to native UI, KDE is awesome and all. I just wish there were good qml supporting easy to use libraries in modern languages that wrapped it because I can't do C++ unless someome is paying me good money and full time for it. Not fun for side projects.
My employer, KDAB, is building an excellent Rust binding for Qt: https://github.com/KDAB/cxx-qt