
Show HN: Sauron-native – A native cross-platform GUI for Rust - ivanceras
https://github.com/ivanceras/sauron-native
======
whatshisface
For Rust programmers that want to write GUIs, I highly recommend gtk-rs. It
does not have the easiest-to-read documentation in the world but it is a good
wrapper of gtk and it suffices for production use. Although it has not reached
1.0 yet, the changes to the API are slow and mostly happen in esoteric
corners, so the development cost of keeping up is not noticeable. Further,
since cargo has good versioning, it won't update and surprise you.

~~~
ssokolow
In the GTK+ 2.x era, I would have agreed with you. GTK+ was either the basis
for or easily themeable to feel reasonably native under any Linux desktop
environment and, because of the applications which depend on it, pretty much
everyone is likely to have it already installed.

Unfortunately, in the GTK+ 3.x era and beyond, the perspective of many KDE
users is that hell has frozen over because GTK+ has supplanted MacOS as the
GUI with the most alien feel to it.

(Plus, the LXDE developers started a transition to GTK+ 3.x, got fed up, and
decided that their upgrade path from GTK+ 2.x would be Qt 5. They then merged
with Razor-Qt to form LXQt.)

Personally, what rubs me the wrong way the most is the various ways in which
it explicitly goes against what HCI research recommends because the GNOME
people just liked it better their way. (And I've read quotes by the devs
showing that they now see GTK+ as GNOME's toolkit first and other desktops are
on their own if they don't want to ride along... which explains things like
how long it took them to stabilize the GTK+ 3.x theming APIs.)

I still might consider it if the gtk3-mushrooms patchset for making GTK+ 3.x
less alien weren't a single-person, amateur effort that's only packaged for
Archlinux.

([https://github.com/krumelmonster/gtk3-mushrooms](https://github.com/krumelmonster/gtk3-mushrooms))

~~~
whatshisface
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.

~~~
ssokolow
That depends on your requirements.

As I mentioned in another comment, I value my GUIs feeling native on my KDE
desktop (and not having to reinvent things like QSettings and, last time I
tried with GTK+ 2.x, drag-and-drop multi-select for list views) strongly
enough that I start with PyQt and then add rust-cpython and Rust if enough of
the application can be cleanly encapsulated away from the GUI code to justify
the added build-time complexity.

~~~
solarkraft
Sounds like a nice model. What are the worst disadvantages?

~~~
ssokolow
Mainly that, for any portions written in Python, I can't rely on Rust's type
system to help me catch mistakes at compile time.

...though Qt's QTest module does help to balance things out a bit, by
providing a Selenium-like facility for automating GUI interactions.

------
ivanceras
Hi HN, This is a work-in-progress project inspired by this HN comment[0].

[0]: HN comment
-([https://news.ycombinator.com/item?id=19746440](https://news.ycombinator.com/item?id=19746440))

~~~
Razengan
In that linked comment:

> _2.1) I want to ship something that looks the same on Windows / Linux /
> MacOS_

As a user: No no no, _please,_ no.

I want apps to fit the look, feel, and _idioms_ of the OS I'm currently in,
_not_ "look the same" on every OS.

For example. macOS in particular has many builtin features that work in all
apps with standard controls. Like text-to-speech, or converting selected text
into all-caps, lowercase, or capitalized. Or custom services/scripts built in
Automator.

I may not always use these little tricks all the time, but when they fail to
work in some app, it immediately feels lower quality, suspicious, and/or
suggests a lazy developer.

It's not pleasant to use something that ignores the special features of a
platform in favor of the lowest common denominator.

~~~
electrograv
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_.

~~~
ridiculous_fish
1\. The reason for platform UI conventions is so users can transfer knowledge
between apps. Some specialized apps may want to establish their own
conventions, because they are aimed at experts who will be investing a lot of
time in the app. Most apps aren't in that category.

2\. HTML and JS make sucky UIs regardless of how much "work pools", because
the underlying APIs are limited and incomplete. For example, scrolling: there
is no native support for large tables in HTML, so apps either do some janky
faulting in like infinite scroll, or reimplement scrolling entirely.
Cut/copy/paste/undo is another example, along with keyboard navigation in
general.

------
yoz-y
I may be missing something. I read native and cross platform, project is about
TUIs, HTML and GTK... maybe I have my definitions wrong.

~~~
giancarlostoro
Those are some of the outputs possible, TUI is cross-platform, so is GTK and
HTML. I don't know why they put them under "supported backends" it would be
clearer if he just put "supported output interfaces". If you dig into his
"/examples" directory it's all Rust code.

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

------
faitswulff
For anyone else looking to get an overview of available GUI options in rust,
there's [https://areweguiyet.com/](https://areweguiyet.com/)

~~~
raphlinus
One of those efforts is druid. I'm deliberately choosing not to make a lot of
noise on social media yet, but I suggest people actively looking for native
GUI in Rust take a closer look. Our team (currently two people funded full
time, a GSoC student, plus a growing, dedicated community) is solving the hard
problems, and we're on the hook for delivering a basic font editor by the end
of the year. The webpage and demos don't look impressive yet, but this is
because we're currently focusing on building out the core.

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

~~~
raphlinus
The two funded full-timers focused on making a font editor using druid as the
GUI toolkit. I personally think this is the best way to grow an ambitious new
toolkit from scratch. Also, there's overlap with the xi team, but in Silicon
Valley speak you might say we've pivoted.

The GSoC student project is a GPU compute renderer for 2D graphics. Early
experiments (piet-metal) show promise that this could advance the state of the
art.

~~~
rapsey
How coupled is druid to druid-shell? It would be great if it would easily be
embeddable into projects that already have platform native windowing code.

~~~
raphlinus
It definitely depends on druid-shell, but we're also thinking about being a
good guest (ie for VST and the like). But honestly our focus is full desktop
apps right now.

------
alkonaut
Good to see more alternatives in this space. If I can make one big app design
request it would be this: Don’t assume that apps can always create their own
windows. This has been a snag for winit and several others. Allow creating a
GUI given an existing window handle.

See e.g. [https://github.com/rust-
windowing/winit/issues/159](https://github.com/rust-
windowing/winit/issues/159)

If you create a rust ui framework that supports the VST windowing/event loop
model and just supports _one_ GUI backend on Win32/MacOS, then many people in
the audio plugin community would be very happy.

------
vbsteven
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
Could you say why you disliked the QT Rust bindings?

~~~
vbsteven
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
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
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.

------
wayneftw
I want a multi process GUI architecture that lets me send messages to a native
rendering process from a bundled sub-process which can be written in any
language. Is it a bad idea? I don’t see anybody trying this…

~~~
hawski
It's a nice idea. One possible implementation could use a Unix domain socket
to communicate between client and server. Or even regular sockets to support
network transparency. We can call the server X and after eleven versions end
up where we are already.

X11 and wide idea of terminals go in hand. It's a problem of abstraction and
platforms evolving. So I think, that you either end up with something like Web
front-ends of today or something more structured, but far simpler like various
TUIs or maybe Tcl/Tk with it's windowing shell wish. I think that some middle
ground is possible, but hard and shifting quite fast.

~~~
thequux
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.

------
nautilus12
Since its a front end component and front end people are used to looking at
gorgeous front ends and since you took the effort to make it functional (well
done!) you should take the little bit of extra effort to also make it look
pretty so it resonates with your audience. :). Rust is more a system language
so you want to avoid that stigma from the outset.

------
rapsey
These projects always stop (or make no useful progress) at the really
difficult/tedious work of abstracting cocoa and win32 API.

~~~
phtrivier
Isn't this abstraction already done (at least partly) by gtk ? (Or are you
thinking of another level of abstraction - otherwise gtk would be enough ?)

~~~
rvz
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?

~~~
danieldk
_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._

It is not worse than electron in that respect ;). But some small Rust Gtk+
utility that I have for personal uses a whopping 7564KB of resident anonymous
memory.

~~~
jakevn
Personally, my issue with Electron is that, in practice, it is hugely
inefficient. The up-side to Electron, IMO, is that it doesn't try to straddle
the uncanny valley of native GUIs. In GTK, usually everything _looks_ like a
normal GUI, but behaves/looks just a little (or, often times, a lot) bit
different than what is expected.

------
Multicomp
This ui framework, if not abandoned by the tedium of win32 api integration,
will make me sit up and actually try Rust for the first time. The TUI in
particular looks great.

2020 was already slated for Rust for me but this may make me start dabbling in
it a few months early (assuming I can find up to date leaning materials)

Tldr great job, please don't give up on the hard part of win32 and macos but
this has a great foundation feature set.

~~~
ivanceras
The core architecture is not done yet. I put this out in the open in the hope
it will get more contributions, since I will be working on to a next project.
An enthusiast would certainly be able to play with it and maybe experiment
with the core architecture.

------
crimsonalucard
What's the "best" solution out there for GUI's? Looking for varying opinions
of people who dabbled in several frameworks.

~~~
yoz-y
Personally I’d say: separate data and interface logic to the maximum possible
level and then write a truly native interface for each platform that matters
to you.

This does not apply if your application has so many custom controls that being
native does not matter that much (for example a music creation software or a
highly advanced raster editor)

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

------
wokwokwok
It runs on wasm in a browser; not really mobile support.

...and the author is abandoning it to move on to other things?

/shrug

Didn’t solve any of the actually hard problems of a cross platform or rust
based UI imo.

~~~
api
I pimp this project any chance I get:

[https://github.com/andlabs/libui](https://github.com/andlabs/libui)

We're considering using it for the next generation of the ZeroTier desktop UI.
Unfortunately no mobile support (but we already have native mobile UIs), but
it looks like the best contender for a cross platform UI lib that is light and
fluffy and simple. Rust bindings should be trivial. There are high quality Go
bindings here:

[https://github.com/andlabs/ui](https://github.com/andlabs/ui)

~~~
itronitron
>> 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.

~~~
api
What sort of memory consumption and general overhead are we talking about
here?

~~~
itronitron
Well, people run Java UIs on Raspberry Pis which demonstrates that the
overhead can be very low.

~~~
vardump
Raspberry Pis have a ton of RAM. Most old ones have 512 or 1024 MB, and new
RPi4s up to 4 GB.

If something runs on a Raspberry Pi, that's not exactly a proof it's light
weight.

~~~
inferiorhuman
The problem I ran into using Pis was that 3D hardware didn't seem to want to
play well with Qt. Unfortunately since using 3D acceleration for UIs is all
the rage almost nothing worked without a lot of tinkering (and even then).

I'm pretty sure this has changed since the last major Raspbian update, but the
Pi still isn't quite at parity with more mainstream desktop hardware.

------
mseidl
Did my dog Melkor make you?

