6 ms·

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

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.

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.