A declarative desktop UI framework for Rust built on GTK and GTK-rs | Hacker News Reader

A declarative desktop UI framework for Rust built on GTK and GTK-rs

github.com

119 pointstempodox64 comments

I’ve been enjoying using Tauri [0] to develop a desktop app for the last few months. As someone who’s been a web dev, and a C++/Qt dev before that, I think it strikes a nice balance. I can use my web skills on the UI, and do the heavy lifting in Rust, and it’s all very fast.

I’m building a video editor [1] (actually rebuilding an app that was originally in Swift) and I’ve been happy to see that the performance is great. I think it feels faster than some of the Qt-based editors I’ve tried. I haven’t noticed JS being the bottleneck - way more often it’s been that I’m doing something sub-optimal on the Rust side.

Tauri still feels early in some aspects, but it’s moving quickly and they’re buttoning things up. I think it’s already a strong contender in the space currently (mostly) owned by Electron.

0: https://tauri.studio

1: https://getrecut.com

I've been watching Tauri for a while. Are there any apps we can try out yet? Thanks.

I see there are a few apps listed here, mostly open source: https://github.com/tauri-apps/awesome-tauri

I'm always curious to see these projects, because I've been experimenting with a React renderer for the GJS bindings for a while. It's frustrating because GTK "feels like" it's so close to being able to support a vdom/declarative paradigm, but the devil is in the details.

The simple use-cases like "Window > Box > Label" are easy to get going. The more complex widgets like Stack/Grid/TreeView ... aren't.

This project seems to have the same issue: https://github.com/bodil/vgtk/issues/40

This is made more difficult now GTK4 has removed the Container base class, so there's no longer a unified interface for adding children (although it had caveats in the first place).

I totally get the GTK view that (presumably) specific widgets are more intuitive with specific add/remove APIs (like the grid - one doesn't really "appendChild" to a grid).

It just feels like: if there was a consistent container API comparable to the web's appendChild approach, a vdom/declarative approach would require only a very light wrapper. Without it, I keep coming back to the idea of implementing wrapper widgets that expose that consistent API instead. And that's just not something I want to maintain - effectively duplicating each GTK widget for the purpose of making it fit into a tree model.

It's also a problem of trying to wrap richer functionality (pack_start and pack_end) into a simpler set (append only) of course.

So I don't know exactly what my point is :) Perhaps cautioning the reader that the simplicity of the approach comes with a catch.

This approach sounds interesting and I think something like this is what we should focus on to bring UI frameworks to new programming languages (in the short term).

Let's not throw out all the work that went into Gtk/Qt but instead embrace it. Bindings/wrappers that are idiomatic in the target language. Maybe including a small state or declarative layer and lean on the framework for rendering, input events, windowing, accessibility, etc.

Another example of this approach is TornadoFX which is a declarative Kotlin DSL on top of JavaFX.

A more maintained alternative: https://github.com/Relm4/Relm4

Why is it licensed under Apache and MIT? The underlying GTK is LGPL, so this is just creating extra licenses in a users project for no good reason.

Apache or MIT "if" you make the choice. But yeah, that is kind of strange to do it that way.

Because the author preferred to share their code under that license is the only reason you actually need.

Additionally, there's an added benefit if you're building non-(L)GPL software with it: you can just use the compiler defaults (statically link Relm4, dynamically link Gtk) and stay compliant.

For those unfamiliar with Rust, the Rust language and a lot of the foundational ecosystem are dual-licensed with MIT and Apache. For any Rust project, this is not a surprising default for the licensing choice.

Here’s a good discussion on it: https://internals.rust-lang.org/t/rationale-of-apache-dual-l...

This makes the most sense of all the answers. Either matching the GTK license, or the common Rust app licenses is reasonable. I think I would have gone the other way, but that's just me.

Do you happen to know if Relm addresses accessibility at all, or has plans to do so in the future? Every time I see a Rust GUI post, that's my first question: https://www.cmyr.net/blog/rust-gui-infra.html#accessibility

It's a rather light wrapper around gtk-rs, so if gtk-rs covers it, it should be there.

Does anyone actually enjoy using the Elm paradigm? I personally can't stand the amount of boilerplate and "indirect thinking" that it requires.

It's nice in elm

It's horrible in JS because of the boilerplate

It's ok in rust, at least you have types

Yes. I honestly find it much easier to think about, easier to design, and eventually easier to modify and maintain.

It feels like a lot of code needs to be written, but in my experience that's because it necessitates thinking about the edge cases in a way that you can try to ignore with more imperative UI or data flow.

I've used the Elm paradigm in Elm and in Swift on iOS. Would definitely use it again for any data-driven complex UIs like apps or big web frontends.

Yeah, it's nice. I don't know what it would be like in a language with a weak/no type system (e.g. JS) though, probably annoying.

Redux is basically that. Lack of types can be slightly annoying, but controlling your state changes through explicit events tends to prevent a lot of ails.

> Does anyone actually enjoy using the Elm paradigm?

Reading "Elm architecture" (https://guide.elm-lang.org/architecture/) it looks like classic MVC - they just call it Model / View / Update instead of Model / View / Controller.

If not, the rest of my comment is invalid.

> I personally can't stand the amount of boilerplate and "indirect thinking" that it requires.

Of course, just because you use a classic paradigm it doesn't mean the implementation thereof is elegant. And that might be because according to the Elm docs programmers "stumbled" upon it (reinvent) instead of designing for it: "Rather than someone inventing it, early Elm programmers kept discovering the same basic patterns in their code."

Could you elaborate on boilerplate and indirect thinking? Those are the exact opposite things I think of when I thinking of model-view-update, so I'm not sure I understand your comment.

https://github.com/bodil/vgtk/issues/79 about the project being active or dead had no response so far.

Given that the project had exactly one commit in the past year, I'm afraid the question is answered...

(Which is too bad, the ideas behind the project seem sound.)

A totally unscientific observation:

Do Rust projects have a tenancy of becoming abandoned maybe due to the complexity of the language since it's hard to contribute? I've seen enough cases on this that prompted me to ask this.

You’ve seen enough cases of what? People saying that it’s too hard to contribute?

No, cool projects in Github that are written in Rust but abandoned after some time.

Can't this be explained simply by rust being a new and trendy language with a lot of young developers experimenting while they improve their skills?

There are tons of those in every language. You just see a lot them in Rust because people are excited to submit Rust projects to HN.

Seems that you’ve skipped a bunch of steps in order to come up with your pet theory, then.

1. Rust projects become abandoned (observed fact)

2. Language complexity (?)

3. Hard to contribute (?)

I guess that’s why you were kind of defensive when you brought it up.

No , not really a lot of the time people are trying to tackle problems that have taken years to solve in other languages which isn’t easy and is why you see stuff abandoned. This project is also pretty similar to https://github.com/antoyo/relm which is an active project.

Instead of language complexity I think it's a result of the specific positioning of the Rust language as a more safe successor to C/C++.

Rewrite-in-Rust is a thing. Not only for applications but also for foundational libraries (crypto, http, async, etc). The ecosystem is still young with lots of gaps and many devs are experimenting with new approaches to fill those gaps. More new projects -> more abandoned projects.

I think we're just early enough in the language that the established libraries and their mechanisms for ensuring continuity just aren't there in many areas.

Other languages had similar teething problems, just ask anyone with applications in Zope, WebPy, Pylons, Merb, JS frameworks not named React, EJB, MFC, etc.

"early enough in the language" is really worrying at this point. I was there, at Mozilla London office in 2015 15th of May when Rust 1.0 was launched. That was 7 years ago. If you look at the history of languages, 7 years is a point of maturity for those that took off. I really hope Rust doesn't flame out like Scala did.

What makes you think it will flame out?

Again though, EJB, AngularJS, Backbone, Pylons were all things in languages that were widely accepted at the times those frameworks were in vogue yet still ran out of steam. Yet Java, JavaScript and Python are still here

And C#, C++, C.

For comparison, Python 1.0 was released in 1994. 7 years later in 2001, Python 2.2 was released. I don't think many of today's popular Python packages date back that far.

> For comparison, Python 1.0 was released in 1994. 7 years later in 2001, Python 2.2 was released. I don't think many of today's popular Python packages date back that far.

Python is an outlier though; it was mostly ignored until very suddenly it took off starting around the time Jupyter released.

Most (including I) think it took off due to how easy and accessible it was back then, syntax-wise. You could pick it up and be slightly productive in a day, be extremely productive in a week and essentially master it in a month.

Go is following a similar trajectory: productive contributor in a week, master in a month.

Rust is in the opposite direction: too many people simply give up on it, those that persevere report months before any reasonable productivity.

Before it's adoption with the scientific community, Python still had a place as "Better perl for scripting" and "Dynamic language for webapps if you don't like Ruby". e.g. Reddit, YouTube and Eve Online are notable apps written in Python before scientific Python was a thing.

Reddit and Eve are interesting in being largely stuck with the now-dead platforms they built on too, in the form of web.py and Stackless Python. YouTube I presume the original Python application is gone in favour of a bunch of Go and Java microservices by now.

It's interesting as someone who was in the Python for web development camp as Python for scientific computing took off as the two camps were both oblivious to the existence of the other in many cases.

>"Dynamic language for webapps if you don't like Ruby"

Wasn't PHP the king of dynamic laguages for Web?

PHP was an earlier era, and certainly continued (to this day even) to be used, but I was thinking more of the Rails era than PHP's peak, which came earlier.

> PHP was an earlier era, and certainly continued (to this day even) to be used, but I was thinking more of the Rails era than PHP's peak, which came earlier.

I don't think Rails/Ruby was ever used more than PHP.

IIRC, PHP at its lowest popularity ever is still higher than Rails/Ruby at it's highest popularity ever.

The lowest I can recall PHP being at is +-6% (recently). The highest that Rails/Ruby ever got to was <3% (2004/2005/2006).

PHP is still used. I don't know if many new apps are written in PHP, or it is used to maintain the large pool of existing PHP apps, but according to Tiobe, Redmonk, PyPl PHP is still widely used.

This is some extreme revisionist history here. The scientific Python community and many of the libraries around it go back way before Reddit, YouTube, etc.

Some dates from Wikipedia:

Major scientific libraries:

- SciPy: "Around 2001"

- ipython: 2001

- Matplotlib: 2003

- NumPy: 2006

- Pandas: 2008

Major web libraries:

- Zope: 1999

- Twisted Web: 2002

- WSGI: 2003

- Django: 2005

- Pylons: 2005

Applications mentioned:

- Eve Online: 2003

- YouTube: 2005

- Reddit: 2005

I don't think this justifies the claim that the web python community was around at the same time as the scientific community while the two were relatively unaware of each of other as "revisionist". It just makes it look like you were in the camp that was aware of the scientific stack and not the web stack.

> web python community was around at the same time as the scientific community while the two were relatively unaware of each of other

I didn’t dispute this, please reread what I said again.

> It just makes it look like you were in the camp that was aware of the scientific stack and not the web stack.

No, actually I’m a web stack Python guy mainly, I just actually know my history.

IMO, we're very much past the point at which things have "settled down"... as long as you're not doing web dev or desktop UI dev in Rust. The former will continue to evolve about as fast as JS-land does because it's all web people who have no idea what a sustainable project is, and the latter will take a few more years because nobody has really solved it in any language. (Ask your favourite "cross-platform" desktop UI framework what their accessibility story is; there is one that gets close, it's Qt.)

But like, if you're trying to do something you'd otherwise do in C++? Audio/video processing, or something along those lines? Yeah, it's fine. The common libraries you choose today are likely to be maintained going into the future.

typo : tenancy -> tendency

In my personal experience, I make and abandon a ton of Rust projects because it's such a fun language, and I really enjoy starting new projects in it. I get an idea, get excited about how I can model the types and relationships in Rust, then throw together an early prototype, then drop it when I've had my fun and before it turns into a job.

Other languages don't have as fun a type system, so I feel bogged down and lose motivation before I even start writing code.

I don't know how many others this applies to, but I have a lot of abandoned Rust projects because if it wasn't in Rust, I never would have even started writing them down before abandoning them.

I don't think Rust projects get abandoned any more than projects in other languages. I think it's just that you see them more because people are excited about Rust so they share projects even if they're abandoned.

Depends on the use case. If it is a GUI library project then yes.

Quite the opposite in this case:

https://twitter.com/bodil/status/1520404060138094592

The author of this crate enjoys advanced type systems, and can't wait for Rust to add what you'd call "more complexity" in the form of higher-kinded types, generic associated types, and specialization (some of these features are available in an unfinished/experimental form in the nightly compiler, but may not become part of the language anytime soon, if ever).

404 now.

That's... interesting. I clicked the link earlier today I can confirm someone was asking whether the project was still maintained, with no answer. Can't say it inspires confidence to see the issue removed...

It was removed literally today, according to archive.org: https://web.archive.org/web/20220528105757/https://github.co...

Does this support different types of message enums so you can keep the enums relatively small based on context? With iced that has the exact same pattern, I find that I end up with an enormous message enum with very long keys

Another declarative UI framework written in rust: https://github.com/slint-ui/slint

GNU GPLv3 or commercial license isn't very usable :-(

Nice to have more options but I don't see a compelling reason to use gtk over qt.

The api is just better and gives you more for the bang

Licensing I suppose.

How is this different from Relm?

The 90s called and want their WndProc back.

If it's old it doesn't mean it's bad. The message loop model for GUIs is/was great.

More or less. I'm thinking that a single-thread for UI model could fit well for Rust.

Desktop GUIs by necessity always use a message loop under the hood. WndProc certainly worked and you could build GUIs with it (same for using CreateWindow, implementing resizing on foot in WM_SIZE and using resource files for dialogs - also subclassing for making those fancy progress bars). But it's also verbose and at the end of the day you have a giant function handling dozens of messages and passing messages back and forth with other wndprocs. If we want to stay on the message level, both the signal/slot paradigm and/or using coroutines are just better, especially the latter is a very natural fit for UIs.

Reply on news.ycombinator.com