9 ms·

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

125 points by jandeboevrie 3y ago

sourcegrift 3y ago
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 no benefits because 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.
- heavyset_go 3y ago
  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.
  - sourcegrift 3y ago
    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.
    - eYrKEC2 3y ago
      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.
- actionfromafar 3y ago
  Do you mean it’s no point in writing a GUI toolkit in Rust?
  - guappa 3y ago
    You'd never be able to compete with qt anyway.
    - bluGill 3y ago
      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.
      - mathverse 3y ago
        That cant be true. Why does QT need hundred of developers when the core product can be done by a single person? (see Sciter)
        bluGill 3y ago
        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.
  - amelius 3y ago
    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.
    - simion314 3y ago
      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.
- self_awareness 3y ago
  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. With declarative + nonstandard we end up with some declarations, which are not the GUI we expect it to be, plus imperative code that mutates this anyway. So it's like we don't have the advantages of declarations, and we still need to write the code to build the GUI. I'm still waiting for nice Qt bindings for Rust, as qmetaobject-rs seems to be QML-only?
  - guappa 3y ago
    Could you make some actual example? Because I read 3 paragraph and I have no idea what you're talking about.
    - notyoutube 3y ago
      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 wouldn't cut it, or be very abstract, with most of the logic outside of the declarative description. Another option might be something that's "runtime declarative", and drag&dropping icons and panels around just change the ui definition?
      - self_awareness 3y ago
        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 from preferences. Along with their order and sorting preference. So I can't declare that in QML, I need to dynamically create the GUI in window creation code. GUI style: basic/advanced. I might be able to get away with different QML files for that, although I need to figure out which QML file to use in runtime (because I need to read it from prefs), so I can't hardcode it. Maybe the main window can have a splitter in the middle. In this case the left and right widget needs to be saved/restored somehow, and the splitter position needs to be persisted. Maybe we support tabs in the main window, and those tabs could be dragged outside of our window into a separate standalone window. We need to serialize the state of the window manager, and deserialize it later, so user preference would be preserved. Is the scrollbar standard or custom? Because we might be doing a text editor and we maybe want to support visualizing buffer map inside the scrollbar. This widget is probably fully owner-drawn anyway, so can't be declared in the QML. I guess nowadays most of those topics are not even considered because there is no such thing as user preference for GUI. User takes what the javascript developer gives, nothing more, nothing less.
- Kelteseth 3y ago
  Have you tried https://slint.dev/ https://slint.dev/?
  - vilunov 3y ago
    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.
    - ComputerGuru 3y ago
      Didn’t they migrate to Fluent UI style or am I mistaking them for someone else?
      - madnirua 3y ago
        You are right. The Qt backend is optional.
    - saidinesh5 3y ago
      I thought slint supports a Qt backend for desktop apps: https://slint.dev/releases/1.3.2/docs/slint/src/advanced/backends_and_renderers 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.
- lmm 3y ago
  > 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.
  - nine_k 3y ago
    Rust does not make your rocket fly faster, but it lowers the chance that it would explode mid-flight.
    - lmm 3y ago
      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).
    - blackpill0w 3y ago
      Rust can also leak memory (memory leaks are memory safe in Rust).
- eYrKEC2 3y ago
  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 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.
soundarana 3y ago
> 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, underperforming copy of Electron.
- alexey-salmin 3y ago
  Dead or not, I'm really glad Telegram and few other desktop apps still use QT and not the Electron shitsandwich.
- turrini 3y ago
  Sorry, but this is FUD. Qt is miles ahead of Electron in terms of performance, app startup, native platform support, and low memory consumption, to name a few. Additionally, its documentation is one of the best in the market.
  - LorenDB 3y ago
    +1 on the documentation. As someone whose job involves a daily use of Qt, I think I've been spoiled by the documentation. Qt does a tremendous job of explaining nearly every function and property in detail, as well as giving a healthy class-level overview (often with code snippets and even screenshots where it might be useful). In fact, even their (many) example programs each have their own documentation page explaining what the example code ia doing.
- ahartmetz 3y ago
  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. Unlike HTML and CSS! The documentation is very good, actually. Of course, if you are already familiar with the web stack, it may seem obscure to you.
philark 3y ago
[flagged]
- savolai 3y ago
  For doing serious UX work, having direct manipulation of the GUI is paramount. Modeling human cognition without actually seeing the design while designing is makes hard to actually do the core of the work. Qt creator/designer for Qt desktop/widgets shines here. Designing UIs in text is where most frameworks fail. It seems really bizarre that more techie devs still seem to believe they can design good UI blindfolded. Imho, C++ not is a language using which user facing software should be built anymore, but Qt at least makes the compromise bearable, making memory management less of a burden.
- self_awareness 3y ago
  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.
st_goliath 3y ago
I'm a C programmer with occasional stints in C++, a language that I admittedly have a complicate relation ship with. Personally, I was quite pleased with Qt 5 & Qml when I got to work with it some time back. I commented on my opinion on Qt/Qml once before: https://news.ycombinator.com/item?id=35652347 https://news.ycombinator.com/item?id=35652347 I'm mentioning this here because, as already noted in my previous post, HN threads on Qt have this bizarre tendency to attract some really weird FUD/shit-flinging. Qt is nothing like Electron. It is nowhere near that, or "underperfoming" in comparsion. In my previous post, I even specifically mentioned how the projection I was on was replacing a Chromium + REST backed based stack on an embedded device with Qt, because that was a slow resource hog in comparison. Somehow I have my doubts that comments like that come from actual experience.
_8j50 3y ago
I 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.
- eql5 3y ago
  If you like Common Lisp, here is one: https://gitlab.com/eql/lqml https://gitlab.com/eql/lqml
- LorenDB 3y ago
  My employer, KDAB, is building an excellent Rust binding for Qt: https://github.com/KDAB/cxx-qt https://github.com/KDAB/cxx-qt
sircastor 3y ago
In my last role we were using QML as a prototyping tool for interfaces, and basically making whole proof-of-concept apps in it. It is immensely powerful once you get the hang of it. Though if anyone is thinking about it, please note that it is not (or wasn't) really a language on its own. It's meant as a UI complement for Qt, and trying to build stuff exclusively in QML is a recipe for tears.
- JanisErdmanis 3y ago
  Can you elaborate on “recipe for tears”?
  - ognarb 3y ago
    Not OP, but QML is not a great language to put more logic than simple bindings and functions like Button { text: "Save" enabled: textField.text.length > 0 // this is reactive to the value of a TextField onClicked: Backend.save() } as soon as you try to for example implement the save method in JS/QML this starts to become very painful as it often ends up with a lot of spaghetti code. The very cool thing with QML is that the save function can be simply implemented in C++ like this. Backend::save() { // call QFile/QNetworkRequest/... } It force the programmer to split their logic from the UI layer which I don't consider a bad thing.
    - JanisErdmanis 3y ago
      It is also possible to have a backend implemented in JS in similar way. Though I personally only have used in intial UI prototype which I latter swapped with Julia backend.
      - notyoutube 3y ago
        I'm curious about julia as a gui language: mind sharing your code/project?
        3y ago
mardifoufs 3y ago
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?
- saidinesh5 3y ago
  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 usecase, it was good.
  - mardifoufs 3y ago
    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!
    - saidinesh5 3y ago
      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 https://doc.qt.io/qt-6/qtquicklayouts-overview.html - which are similar to what we've had in QWidgets
singularity2001 3y ago
Does anyone else think that QT is mostly overkill and HTML is good enough in most cases?
- flohofwoe 3y ago
  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.
- speed_spread 3y ago
  Funny because I think HTML is overkill and QT is good enough. HTML meaning that your app runs in a browser, which generally uses much more resources than a QT app.
- guappa 3y ago
  html doesn't have events that can be connected to actions. Doesn't resize decently, doesn't respect user's settings. And a browser is much much slower and bigger than a qt application.
  - mildmotive 3y ago
    > Doesn't resize decently, About HTML+CSS, that’s just incorrect. Go and try Tailwindcss and then tell me how bad HTML is at resizing. https://tailwindcss.com/docs/responsive-design https://tailwindcss.com/docs/responsive-design
    - guappa 3y ago
      Well in Qt layouts are native, no need of using an external project.
      - mildmotive 3y ago
        Tailwindcss makes using CSS easier, it’s still CSS underneath, which you can interface with directly if you want. For medium to large applications it takes quite a bit of work to give your Qt GUI a custom style, and do it right. This isn’t something you can hand wave away.
password4321 3y ago
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 https://news.ycombinator.com/item?id=34291701
- jcelerier 3y ago
  Everything you need for a traditional desktop app, or hell, a complete desktop environment, is LGPL. GPL parts are more specialty and industry tools (IoT protocols, etc)
- guappa 3y ago
  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.
  - Capricorn2481 3y ago
    Right, but what the GP wrote was not one of those comments. They are correct. Some parts are LGPL and some aren't.
  - saidinesh5 3y ago
    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://www.ics.com/sites/default/files/images/licensing.png https://i0.wp.com/embeddeduse.com/wp-content/uploads/2023/01/qt6-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..
    - JanisErdmanis 3y ago
      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?
felipefar 3y ago
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.
- nextaccountic 3y ago
  in which ways is the qml desktop integration lacking?
  - felipefar 3y ago
    If you create a sample project with a list view, you can scroll that widget by clicking the mouse on the background and dragging it (a reminiscence from touch based interfaces). The example projects don't look native but look like a mobile app inside your desktop. Windows themed button sizes don't follow Windows 7 desktop guidelines out of the box. Sure that if you put the extra effort you can make QML look native, but it makes you wonder if desktop is in fact a goal for the framework.
- IshKebab 3y ago
  There still isn't even a native way to make text nodes in a custom widget. It's been 14 years. I tried to write a basic serial console app using QtQuick some years ago but the functionality was just too anaemic. I don't really understand how you can write a serious GUI app with QtQuick/QML. If it's just very basic controls, sure. As soon as you need something slightly complicated it totally falls down in ways that QtWidgets don't. Also the scoping rules of QML make no sense. Children can refer to parents which totally breaks encapsulation. I love Qt, but QML is meh at best.
- rubymamis 3y ago
  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 https://www.get-plume.com
delijati 3y ago
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 https://github.com/thp/pyotherside [2] https://github.com/delijati/fosdem-qml/tree/master https://github.com/delijati/fosdem-qml/tree/master
- ognarb 3y ago
  I'm curious, why are you using this instead of the official Python bindings?
  - delijati 3y ago
    It is more lightweight than PySide, PyQT and was easier to bundle as one click pkg for ubuntu-touch
Siecje 3y ago
When working with QML I created this simple debug console, maybe it is useful to someone. https://github.com/siecje/qml-explorer https://github.com/siecje/qml-explorer
diath 3y ago
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.
- eYrKEC2 3y ago
  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.

125 points by jandeboevrie 3y ago

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 no benefits because 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.

heavyset_go 3y ago
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.
- sourcegrift 3y ago
  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.
  - eYrKEC2 3y ago
    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.
actionfromafar 3y ago
Do you mean it’s no point in writing a GUI toolkit in Rust?
- guappa 3y ago
  You'd never be able to compete with qt anyway.
  - bluGill 3y ago
    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.
    - mathverse 3y ago
      That cant be true. Why does QT need hundred of developers when the core product can be done by a single person? (see Sciter)
      - bluGill 3y ago
        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.
- amelius 3y ago
  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.
  - simion314 3y ago
    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.
self_awareness 3y ago
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. With declarative + nonstandard we end up with some declarations, which are not the GUI we expect it to be, plus imperative code that mutates this anyway. So it's like we don't have the advantages of declarations, and we still need to write the code to build the GUI. I'm still waiting for nice Qt bindings for Rust, as qmetaobject-rs seems to be QML-only?
- guappa 3y ago
  Could you make some actual example? Because I read 3 paragraph and I have no idea what you're talking about.
  - notyoutube 3y ago
    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 wouldn't cut it, or be very abstract, with most of the logic outside of the declarative description. Another option might be something that's "runtime declarative", and drag&dropping icons and panels around just change the ui definition?
    - self_awareness 3y ago
      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 from preferences. Along with their order and sorting preference. So I can't declare that in QML, I need to dynamically create the GUI in window creation code. GUI style: basic/advanced. I might be able to get away with different QML files for that, although I need to figure out which QML file to use in runtime (because I need to read it from prefs), so I can't hardcode it. Maybe the main window can have a splitter in the middle. In this case the left and right widget needs to be saved/restored somehow, and the splitter position needs to be persisted. Maybe we support tabs in the main window, and those tabs could be dragged outside of our window into a separate standalone window. We need to serialize the state of the window manager, and deserialize it later, so user preference would be preserved. Is the scrollbar standard or custom? Because we might be doing a text editor and we maybe want to support visualizing buffer map inside the scrollbar. This widget is probably fully owner-drawn anyway, so can't be declared in the QML. I guess nowadays most of those topics are not even considered because there is no such thing as user preference for GUI. User takes what the javascript developer gives, nothing more, nothing less.
Kelteseth 3y ago
Have you tried https://slint.dev/ https://slint.dev/?
- vilunov 3y ago
  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.
  - ComputerGuru 3y ago
    Didn’t they migrate to Fluent UI style or am I mistaking them for someone else?
    - madnirua 3y ago
      You are right. The Qt backend is optional.
  - saidinesh5 3y ago
    I thought slint supports a Qt backend for desktop apps: https://slint.dev/releases/1.3.2/docs/slint/src/advanced/backends_and_renderers 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.
lmm 3y ago
> 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.
- nine_k 3y ago
  Rust does not make your rocket fly faster, but it lowers the chance that it would explode mid-flight.
  - lmm 3y ago
    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).
  - blackpill0w 3y ago
    Rust can also leak memory (memory leaks are memory safe in Rust).
eYrKEC2 3y ago
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 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.

soundarana 3y ago

> 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, underperforming copy of Electron.

alexey-salmin 3y ago
Dead or not, I'm really glad Telegram and few other desktop apps still use QT and not the Electron shitsandwich.
turrini 3y ago
Sorry, but this is FUD. Qt is miles ahead of Electron in terms of performance, app startup, native platform support, and low memory consumption, to name a few. Additionally, its documentation is one of the best in the market.
- LorenDB 3y ago
  +1 on the documentation. As someone whose job involves a daily use of Qt, I think I've been spoiled by the documentation. Qt does a tremendous job of explaining nearly every function and property in detail, as well as giving a healthy class-level overview (often with code snippets and even screenshots where it might be useful). In fact, even their (many) example programs each have their own documentation page explaining what the example code ia doing.
ahartmetz 3y ago
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. Unlike HTML and CSS! The documentation is very good, actually. Of course, if you are already familiar with the web stack, it may seem obscure to you.

philark 3y ago

[flagged]

savolai 3y ago
For doing serious UX work, having direct manipulation of the GUI is paramount. Modeling human cognition without actually seeing the design while designing is makes hard to actually do the core of the work. Qt creator/designer for Qt desktop/widgets shines here. Designing UIs in text is where most frameworks fail. It seems really bizarre that more techie devs still seem to believe they can design good UI blindfolded. Imho, C++ not is a language using which user facing software should be built anymore, but Qt at least makes the compromise bearable, making memory management less of a burden.
self_awareness 3y ago
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.

st_goliath 3y ago

I'm a C programmer with occasional stints in C++, a language that I admittedly have a complicate relation ship with. Personally, I was quite pleased with Qt 5 & Qml when I got to work with it some time back. I commented on my opinion on Qt/Qml once before: https://news.ycombinator.com/item?id=35652347 https://news.ycombinator.com/item?id=35652347 I'm mentioning this here because, as already noted in my previous post, HN threads on Qt have this bizarre tendency to attract some really weird FUD/shit-flinging. Qt is nothing like Electron. It is nowhere near that, or "underperfoming" in comparsion. In my previous post, I even specifically mentioned how the projection I was on was replacing a Chromium + REST backed based stack on an embedded device with Qt, because that was a slow resource hog in comparison. Somehow I have my doubts that comments like that come from actual experience.

_8j50 3y ago

I 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.

eql5 3y ago
If you like Common Lisp, here is one: https://gitlab.com/eql/lqml https://gitlab.com/eql/lqml
LorenDB 3y ago
My employer, KDAB, is building an excellent Rust binding for Qt: https://github.com/KDAB/cxx-qt https://github.com/KDAB/cxx-qt

sircastor 3y ago

In my last role we were using QML as a prototyping tool for interfaces, and basically making whole proof-of-concept apps in it. It is immensely powerful once you get the hang of it. Though if anyone is thinking about it, please note that it is not (or wasn't) really a language on its own. It's meant as a UI complement for Qt, and trying to build stuff exclusively in QML is a recipe for tears.

JanisErdmanis 3y ago
Can you elaborate on “recipe for tears”?
- ognarb 3y ago
  Not OP, but QML is not a great language to put more logic than simple bindings and functions like Button { text: "Save" enabled: textField.text.length > 0 // this is reactive to the value of a TextField onClicked: Backend.save() } as soon as you try to for example implement the save method in JS/QML this starts to become very painful as it often ends up with a lot of spaghetti code. The very cool thing with QML is that the save function can be simply implemented in C++ like this. Backend::save() { // call QFile/QNetworkRequest/... } It force the programmer to split their logic from the UI layer which I don't consider a bad thing.
  - JanisErdmanis 3y ago
    It is also possible to have a backend implemented in JS in similar way. Though I personally only have used in intial UI prototype which I latter swapped with Julia backend.
    - notyoutube 3y ago
      I'm curious about julia as a gui language: mind sharing your code/project?
      - 3y ago

mardifoufs 3y ago

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?

saidinesh5 3y ago
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 usecase, it was good.
- mardifoufs 3y ago
  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!
  - saidinesh5 3y ago
    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 https://doc.qt.io/qt-6/qtquicklayouts-overview.html - which are similar to what we've had in QWidgets

singularity2001 3y ago

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

flohofwoe 3y ago
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.
speed_spread 3y ago
Funny because I think HTML is overkill and QT is good enough. HTML meaning that your app runs in a browser, which generally uses much more resources than a QT app.
guappa 3y ago
html doesn't have events that can be connected to actions. Doesn't resize decently, doesn't respect user's settings. And a browser is much much slower and bigger than a qt application.
- mildmotive 3y ago
  > Doesn't resize decently, About HTML+CSS, that’s just incorrect. Go and try Tailwindcss and then tell me how bad HTML is at resizing. https://tailwindcss.com/docs/responsive-design https://tailwindcss.com/docs/responsive-design
  - guappa 3y ago
    Well in Qt layouts are native, no need of using an external project.
    - mildmotive 3y ago
      Tailwindcss makes using CSS easier, it’s still CSS underneath, which you can interface with directly if you want. For medium to large applications it takes quite a bit of work to give your Qt GUI a custom style, and do it right. This isn’t something you can hand wave away.

password4321 3y ago

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 https://news.ycombinator.com/item?id=34291701

jcelerier 3y ago
Everything you need for a traditional desktop app, or hell, a complete desktop environment, is LGPL. GPL parts are more specialty and industry tools (IoT protocols, etc)
guappa 3y ago
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.
- Capricorn2481 3y ago
  Right, but what the GP wrote was not one of those comments. They are correct. Some parts are LGPL and some aren't.
- saidinesh5 3y ago
  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://www.ics.com/sites/default/files/images/licensing.png https://i0.wp.com/embeddeduse.com/wp-content/uploads/2023/01/qt6-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..
  - JanisErdmanis 3y ago
    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?

felipefar 3y ago

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.

nextaccountic 3y ago
in which ways is the qml desktop integration lacking?
- felipefar 3y ago
  If you create a sample project with a list view, you can scroll that widget by clicking the mouse on the background and dragging it (a reminiscence from touch based interfaces). The example projects don't look native but look like a mobile app inside your desktop. Windows themed button sizes don't follow Windows 7 desktop guidelines out of the box. Sure that if you put the extra effort you can make QML look native, but it makes you wonder if desktop is in fact a goal for the framework.
IshKebab 3y ago
There still isn't even a native way to make text nodes in a custom widget. It's been 14 years. I tried to write a basic serial console app using QtQuick some years ago but the functionality was just too anaemic. I don't really understand how you can write a serious GUI app with QtQuick/QML. If it's just very basic controls, sure. As soon as you need something slightly complicated it totally falls down in ways that QtWidgets don't. Also the scoping rules of QML make no sense. Children can refer to parents which totally breaks encapsulation. I love Qt, but QML is meh at best.
rubymamis 3y ago
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 https://www.get-plume.com

delijati 3y ago

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 https://github.com/thp/pyotherside [2] https://github.com/delijati/fosdem-qml/tree/master https://github.com/delijati/fosdem-qml/tree/master

ognarb 3y ago
I'm curious, why are you using this instead of the official Python bindings?
- delijati 3y ago
  It is more lightweight than PySide, PyQT and was easier to bundle as one click pkg for ubuntu-touch

Siecje 3y ago

When working with QML I created this simple debug console, maybe it is useful to someone. https://github.com/siecje/qml-explorer https://github.com/siecje/qml-explorer

diath 3y ago

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.

eYrKEC2 3y ago
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.