Show HN: Sauron-native – A native cross-platform GUI for Rust (opens in new tab)

Personally, I find that most modern UIs that explicitly do not conform to an OS’s opinionated UI design style (for example: the majority of web stack UIs[1]), are often better in almost every way vs apps that do conform to OS style!

When I’m using an advanced UI to do some specialized task, I generally appreciate when the UI patterns I learn on one OS transfer seamlessly to any other device and OS I may use to do the same task.

But I especially appreciate that apps can choose the UI style and design to suit the task at hand, rather than some notion of conforming to OS style patterns that may or may not work in its favor. For example, I prefer that Visual Studio Code looks the same on all platforms, because I find its UI to be superior to the default style of any OS!

What do you think about these thoughts? Am I alone in preferring custom UIs per app, with consistent app experience across devices?

[1] For the sake of this argument, I’m not counting differences in runtime performance and efficiency, since that’s a whole other topic, and one theoretically orthogonal to the UI design.

Back when I wrote the comment, I tried to make clear that there were two very important and very contradictory requirements :

1. it has to look and behave the same way everywhere (because we don't want to have to retrain users when they switch platform, to maintain several documentation and marketing materials, and because we want to respect the designer's esthetic vision, and / or corporate graphical vision)

2. It has to look and behave native everywhere (because we don't want to confuse users of any given platform.)

Again : of course, I know they're contradictory ! If you have a sword to cut that knot, go for it !

And of course you're perfectly allowed to value requirement 2 more than requirement 1.

And sadly here, different user's interests are not aligned with different software producer's interests, so we're basically not going to please everyone.

Again, I have neither data, nor religion, nor solution about this.

Wouldn’t the ideal solution (if you really need rust performance) then be to write platform-Native applications (ie swift/obj-c for Mac) with bridges to performance critical parts in rust?

I’m probably very naive here- since I am not a rust or swift developer!!

The holy grail part.

Druid and OrbTk have definitely caught my attention. The challenge for me is that while I have relatively simple needs for now (buttons, text, table widgets), I would like to do things not represented by the examples. With the (understandable) paucity of documentation it's difficult to be productive.

My current challenge is to swap out different top-level views as I navigate to different parts of the app. This may may be something best suited to something like Cursive.rs, but I'm still holding out hope that the GUI toolkits will mature at a reasonable clip.

It's really quite refreshing to see something more portable and lightweight than Electron gain traction. So far the only major detractor I've seen is that the project uses Zulip for chat/messaging and it's put behind a registration wall.

Is that 2+1GSoC team focussed purely on druid, or is it the xi team working on druid as part of that project?

I have liked the idea of NeWS for a very long time. Sadly NeWS was born and died long before it was viable: postscript has always been difficult to write a VM for and unfriendly to application programmers, machines were significantly slower, and NeWS itself was very much vendor-locked.

However, things are different now. We could embed Lua or WASM into the display server, and you'd have a much more programmer-friendly platform that can run efficiently enough to feel snappy. We have more memory, so you don't need to share toolkits between applications.

Maybe it's time to revive the concept.

Some charge money for developing products, and it leads to sustained development. Some call those commercial products, and have a tendency to work well. The source can still be open, as open source doesnt have to be free. But many dont want to pay for products, want them free, and at the expense of others.

When it comes to using only GTK+ for the cross-platform use-case, it already has the Cocoa and Win32 back-ends built in via the GDK, which that API is abstracted to GTK+ so that work is already done. It maybe enough to solve the Rust GUI problem on Win/Mac/Linux, however the drawback to using GTK+ is that it will look out of place on other platforms other than Linux, because of the GNOME _look and feel_ it brings.

I think the author might have to support GTK+ theming options to counter this issue then? If not then perhaps using GTK+ for Linux and using the win32 and cocoa crates separately and abstracting that might be something worth looking at?

No gtk draws its own widgets.

>> a cross platform UI lib that is light and fluffy and simple

Can you comment on whether you evaluated Java Swing or Java FX as a cross platform UI lib for your needs? I am curious to hear others thoughts on the matter.

libui is limited to the point of uselesness. You will very quickly reconsider once you try using it.

Javafx/tornadofx or maybe wxwidgets/qt is a better choice

The advantage that Rust's GTK bindings have over Rust's Qt bindings is great enough to counteract any advantage that Qt has over GTK. That's because GTK has an (XML?) schema that allows bindings and documentation to be autogenerated to a large extent. Binding to Qt from Rust is in comparison very difficult (not to mention the fact that Qt's idiosyncratic programming model naturally conflicts with Rust's militant ownership concepts).

Edit: To be clear, I'm not comparing the relative merits of different GUI options, I'm saying that GTK is the only option that you really have in Rust today.

please no one turn this into a gnome 3 flame war. all I wan to know is what HCI flaws did gnome make? it seems fairly universally hated, but unconfigured (fresh rhel or centos install). I like it better than 2.x. I recognize I am unusual in many ways so I wanted to know if maybe I was using 2.x wrong. my workflow on any os is press button start typing the name of an app then hit enter dock to a position on screen then do everything from there. I like it shows what is in the workspace when I got the button. I want to dock apps, move between workspaces and move apps between workspace and start apps only using the keyboard. don't muh care about anything else as long as there is a dark theme. rat poison was a bridge to far for me, but that is the general idea

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.

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/

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.

Yes but I’d consider neither of those “native”. Except HTML which is native to the web. TUIs are native not GUIs by definition.

Of course, I'm talking about frameworks for rust that have already done this for me.