4 ms·

Interesting project, I’ll be checking this out soon. I’ve been experimenting with several gui libraries in Rust lately and so far the GTK3 bindings seem to be

Interesting project, I’ll be checking this out soon. I’ve been experimenting with several gui libraries in Rust lately and so far the GTK3 bindings seem to be the most promising for building native GUIs in Rust. With native I mean GTK/Qt style fast/performant widgets that do not necessarily use platform-specific widgets. This project seems to use GTK as one of its backends. I’m curious to see how the multiple backends architecture will influence the library design as GTK, html and TUI are vastly different.

krapht 7y ago
Could you say why you disliked the QT Rust bindings?
- vbsteven 7y ago
  I have to spend some more time on it but due to lack of getting started documentation or examples it was hard to get a Hello World project running. On the GTK-rs side the documentation [1] is much better and I was up and running with a sample project in a few minutes. [1]: https://gtk-rs.org/ https://gtk-rs.org/
  - slezyr 7y ago
    Oh, wow. It looks horrible[1] in some cases. Even worse than most C++/Boost constructions. [1]: https://gtk-rs.org/docs-src/tutorial/upcast_downcast https://gtk-rs.org/docs-src/tutorial/upcast_downcast
    - nicoburns 7y ago
      Yeah, existing GUI libraries tend to make heavy use of inheritance, which Rust doesn't support very well. I have high hopes for a Rust-native GUI library being the goto cross-platform UI library at some point. But that's probably still 2-5 years off at this point.
- ssokolow 7y ago
  While i'm not vbsteven, I can probably give a useful answer to your question. As a KDE user, QML is about as useful to me as GTK+ when it comes to feeling native, so bindings built around those APIs are out. rust-qt-binding-generator (the one maintained by KDE people) is fundamentally designed around the assumption that you're comfortable writing parts of your program in C++. (It's designed for embedding Rust pieces in a project with its own build automation, like CMake, and where hand-written C++ will still be used for part of the process of talking to Qt.) rust-qt comes the closest to what I want (something where, as long as I don't touch the `unsafe` keyword and I only pick trustworthy dependencies, I can't accidentally introduce memory-unsafety into my project.) but "Creating custom signals from Rust code." is still on the TODO list and its development seems to have run out of steam. So far, my solution has been to use Rust to write a cleanly encapsulated backend, use rust-cpython to expose it to Python, and then use PyQt5 (because I haven't started a new Qt project since PySide2 matured) to build a frontend, producing a QML-esque development experience for the QWidget APIs... though I'd still much rather have strong compile-time checks for the entire project.
- hawski 7y ago
  I have a side question. How are Qt bindings for D? Since, AFAIK, D has one of the best, if not the best, FFIs to C++. I also imagine if D could run on Android's JVM or could it be traspiled to Java. I've seen the latter effort, but quite preliminary from what I remember. Can't really hope for this with Rust, at least not yet.

krapht 7y ago

Could you say why you disliked the QT Rust bindings?

vbsteven 7y ago
I have to spend some more time on it but due to lack of getting started documentation or examples it was hard to get a Hello World project running. On the GTK-rs side the documentation [1] is much better and I was up and running with a sample project in a few minutes. [1]: https://gtk-rs.org/ https://gtk-rs.org/
- slezyr 7y ago
  Oh, wow. It looks horrible[1] in some cases. Even worse than most C++/Boost constructions. [1]: https://gtk-rs.org/docs-src/tutorial/upcast_downcast https://gtk-rs.org/docs-src/tutorial/upcast_downcast
  - nicoburns 7y ago
    Yeah, existing GUI libraries tend to make heavy use of inheritance, which Rust doesn't support very well. I have high hopes for a Rust-native GUI library being the goto cross-platform UI library at some point. But that's probably still 2-5 years off at this point.
ssokolow 7y ago
While i'm not vbsteven, I can probably give a useful answer to your question. As a KDE user, QML is about as useful to me as GTK+ when it comes to feeling native, so bindings built around those APIs are out. rust-qt-binding-generator (the one maintained by KDE people) is fundamentally designed around the assumption that you're comfortable writing parts of your program in C++. (It's designed for embedding Rust pieces in a project with its own build automation, like CMake, and where hand-written C++ will still be used for part of the process of talking to Qt.) rust-qt comes the closest to what I want (something where, as long as I don't touch the `unsafe` keyword and I only pick trustworthy dependencies, I can't accidentally introduce memory-unsafety into my project.) but "Creating custom signals from Rust code." is still on the TODO list and its development seems to have run out of steam. So far, my solution has been to use Rust to write a cleanly encapsulated backend, use rust-cpython to expose it to Python, and then use PyQt5 (because I haven't started a new Qt project since PySide2 matured) to build a frontend, producing a QML-esque development experience for the QWidget APIs... though I'd still much rather have strong compile-time checks for the entire project.
hawski 7y ago
I have a side question. How are Qt bindings for D? Since, AFAIK, D has one of the best, if not the best, FFIs to C++. I also imagine if D could run on Android's JVM or could it be traspiled to Java. I've seen the latter effort, but quite preliminary from what I remember. Can't really hope for this with Rust, at least not yet.