Hacker News Reader

Comment by diskzero | Hacker News Reader

Original Nautilus and early GNOME developer here. I am very out of touch with what is current, so excuse some possibly ignorant questions. How is this a Rust-based environment if it is based on GTK? I assume GTK is still essentially the C-based GTK we used with some improvements.

Why is this called Rust-based? I’ll do some more research but would like to get some insight from more knowledgeable sources.

View on HN

The answer seems to be that the applications [1] are written in Rust using gtk-rs [2] (Rust-bindings for the GTK libs).

[1]: https://github.com/orgs/pop-os/repositories?q=&type=source&l...

[2]: https://gtk-rs.org/

Does this work similar to the python bindings that were ubiquitous a decade ago?

My understanding is that you don't get any memory safety/performance advantage from using Rust because gtk can still be unsafe.

Is this correct?

Even Rust code can still be unsafe. It's a question of where it can be unsafe. You're reducing the scope of code that can be unsafe to specific areas.

So basically it’s not Rust.

How pure does your program have to be to be rust for you? How few libraries in C or C++ must it call? The developers are writing all their code in rust, so it is in rust…

It’s a UI library that’s showing UI controls that are written in C. It’s dishonest to call it Rust because it wraps those controls in a layer of Rust

By that standard no binary that links against glibc, whether originally written in rust or go, is in fact rust or go.

I appreciate your facts. But System 76 should then call it GTK based, I guess.

Only the applications are GTK-based. The compositor that makes the whole environment possible is written in Rust.

Also GTK4 means they are still at the mercy of GNOME which changes APIs often and without consideration for third parties.

Wasn't the whole point of the project to emancipate themselves from GNOME? If they rely on GTK they will fail.

Then they would need to either

1) do the yak-shaving and create a whole new GUI stack in Rust (which would be an absolute boon to the Rust community but will be a tremendous effort), or

2) switch to Qt (and basically become KDE)

Thinking about it, maybe Sciter (https://sciter.com/) would be an okay foundation to build a DE in (lightweight stack, flexible theming, solid Rust bindings). But then it isn’t open source (only the interface is, you need to pay for source access), so maybe not.

create a whole new GUI stack in Rust

Is there a reason iced is not good enough (other than not being accessible)?

https://iced.rs/

https://github.com/iced-rs/iced/issues/552

No stable release yet, and you generally want your DE to be the most dependable bug-free part of your software, especially if you are selling hardware with your own software pre-installed.

but looking good so far, gonna check this out for myself. I was rooting for azul, but iced seems to be further ahead

I'm assuming Iced has no A11 support (these projects never do). Probably no RTL support. Possibly no reusable "system" widgets like open/save dialogs.

Can you clarify what you mean by "these projects never do"? Your comment comes across as dismissive. Especially since I already noted that it was lacking a11y in my original comment.

Anyway although a11y and i18n support have not been implemented, they are planned.

https://github.com/iced-rs/iced/issues/250

It wasn't meant as dismissive of the project. It's totally fine to write a UI library that has another focus (games, for example). I'm just tired of those projects being suggested as alternatives to native/GTK/Qt in discussions here and elsewhere.

If Iced actually gets cross-platform accessibility support, that's great! Very few projects have that today. More certainly wouldn't hurt. But until it does, you shouldn't base a DE on it.

Edit: The issue you linked to is about RTL support. That's also required, but doesn't touch on a11y.

My original comment mentioned and linked to the a11y issue.

Input Method support? (A feature used in various East Asian languages by over a third of the world’s population)

https://en.wikipedia.org/wiki/Input_method

https://github.com/iced-rs/iced/pull/686

See the challenges of properly supporting IME in Druid, another Rust toolkit:

https://github.com/linebender/druid/issues/1308

Iced looks pretty cool but it's focused on being a cross-platform toolkit and will probably not ever be the best choice for making programs native to Linux, like a desktop environment. If you thought there were enough problems between GTK and Qt with skinning, fonts, keybindings, and all that stuff, adding another toolkit to the mix just makes it worse.

Iced is missing even basic features such as:

- Rendering multiple layers

- Creating multiple windows

- Multiline text layout and editing

Regarding 2, aren’t they basically gnome if they are using gtk, as per your logic?

With the transition from version 3 to 4, GTK is now more focused on being a generic UI toolkit, with GTK4-based libadwaita now being the place to be for GNOME-specific patterns.

History and experience tells a different story [1]. Never trust a library that is maintained by GNOME.

1.: https://github.com/thestinger/termite

libadwaita exists solely to move Gnome specific stuff out of GTK into libadwaita.

And it's hard to see how an open source project with as many developers as Gnome/GTK have can have some secret agenda that is counter to what they are saying publicly and creating libraries and code publicly to implement.

> it's hard to see how an open source project with as many developers as Gnome/GTK have can have some secret agenda

How many serious Gnome/GTK developers are there who are not IBM employees?

That question is a non-sequitur. But to give you a type of answer, most of libadwaita came out of Purism.

Checking the response from the maintainer shows another different story: https://bugzilla.gnome.org/show_bug.cgi?id=679658#c12

>Implementing keyboard selection inside vte means that every terminal based on vte benefits; adding only hooks for you means that all the other terminals get no benefit.

The patch being pushed wasn't going to help other projects. The developer of that project was working on a fork of the library but it appears it didn't get much use and was abandoned: https://github.com/thestinger/vte-ng

I don't see much more that anyone from GNOME could have done there.

So XFCe == GNOME and LXDE is GNOME or KDE, depending on which version we're talking about?

UI toolkit doesn't equal a desktop environment. There is tons of stuff in the GNOME ecosystem (some of which it will make a lot of sense for System76 to reuse, no doubt) that can be entirely ignored when you're using GTK to, essentially, draw your UI widgets for you.

GTK is just a library, you can use it from any language it has bindings for.

Understood. I have made significant contributions to GTK. My contributions possibly had memory leaks or memory corruption issues that will bring down the higher Rust layer. I am trying to understand the purpose of the Rust layer. It is fine with me if it is because Rust is interesting, but what is being presented doesn’t seem like a Rust desktop environment _to me_.

It's not 100% Rust but I think you would expect that GTK itself is fairly well tested - probably much better tested than any new app you write that uses it, so it is still worth it to write that app in Rust.

And it has to be said that memory safety isn't Rust's only compelling feature. It also has a pretty great build system, a decent library ecosystem, a very strong type system which gives you an "if it compiles it works" experience surprisingly often, probably the best multithreading system, etc. etc.

The big selling point of Rust in respect to these kinds of scenarios is that it's very often that a C or C++ library says things like "You must not call function CallAfterFoo before function Foo is called", or "Once you call DestroyObject, that object must not be used again", or "You must not call SomethingDangerous while a ResourceOwningObject exists", and so on and so on.

In well-tested libraries like GTK, SQLite, Curl, and such, they are often quite robust just based on having been heavily developed and tested by many people over a very long time, and there are still ways that they can be misused and abused that are usually well-documented and warned against. A well-developed Rust wrapper actually makes it impossible to misuse one of these libraries from Rust, and therefore better enables a much smaller team of developers to write secure, robust applications. Rust can guarantee these documented restrictions at the type level and even make impossible many error conditions.

So even though the UI is GTK, Rust still enables developers to write more robust applications with less fear. Personally, I find that GTK with Rust is a very pleasant experience. It's less about guaranteeing that the lower libraries have no bugs and more about preventing people from interacting with the libraries in dangerous or buggy ways.

I've made some small contributions to gtk-rs-core (the library providing rust bindings to glib, gdk...).

While the lower layers written in C do impact the overall safety, the bindings are made to be as safe as possible.

For example: every glib parameter that may take NULL in Rust becomes an Option<T>.

GObject's methods are defined on traits and checked by the Rust type system. There are also some macros to provide an easy and safe interface to the GLib type system.

All of this directly applies to gtk-rs.

Overall, the bindings are well documented and with many examples. There's even a book. Also, there's a great community around them.

Bindings website: https://gtk-rs.org/

I agree! I think they're just using Rust because they'd rather use it than C, not because they need safety guarantees for the DE applications.

The issue is that Rust is extremely opinionated at to how code should be structured and there is going to be considerable interface friction with a system that is built around aliasing data every time there is a callback.

Do you have an example of that friction? Looking through the docs at e.g. https://gtk-rs.org/gtk4-rs/stable/latest/book/hello_world.ht... it doesn't seem that bad but not having used it I would be curious how it works out once you're building a serious app.

Things are already getting quite hairy by page 4[1] of that link. And that example is showing data completely owned by the GObject. If you need to pass a mutable reference to third party data to a GObject it's not going to work in Rust. Imagine a button that you click to change the contents a GtkTreeModel connected to a GtkTreeView--you're going to need to work hard. You're going to write a fair bit Rust specific glue code to work around these issues.

[1] https://gtk-rs.org/gtk4-rs/stable/latest/book/gobject_memory...

Asking as someone who's never spent significant time/effort working with Gtk/GObject in C (only a bit in Python). Isn't it still generally desirable to have the compiler yell at you, if you can't convince it you know what you're doing? Rather than allowing the possibility of memory corruption.

I do agree that the code in the example is far from beautiful. I wonder if we were to redesign GObject from scratch, if we could make interfacing with Python, Rust, JS, etc a bit less hairy.

The work you have to do to show your compiler that certain constraints hold (say that i and j point inside the same array and that i < j can be extremely cumbersome, even in cases where it’s obvious that they do hold. That makes it not seem worth the trouble.

Of course, that obvious may turn out to be incorrect for some edge condition.

Basically, that’s the same reason why mathematicians don’t put all proofs through a proof assistant.

Of course, to the extent you assumed things the machine didn't test that.

The core of TLS 1.3 was proved before it shipped. But, the proof makes an assumption which has consequences. It assumes when communicating using an agreed shared secret† you have a separate shared secret for every such pairing. So Alice and Bob need a shared secret but (and this is where humans trip up compared to what was actually proved) the proof says Bob and Alice also need a shared secret different from the one for Alice and Bob.

The consequence of this accidentally missed assumption is the Selfie attack. Alice and Bob share a secret S and communicate over the Network using TLS 1.3. Bob fed the cat half an hour ago. The cat has employed Mallory to trick Alice into feeding it even though Bob already did. Alice sends a message on the Network. It is encrypted with S and it says "Did you feed the cat?". Mallory doesn't know S and can't read this message or tamper with it. But Mallory simply redirects the message back to Alice. Alice receives a message, properly encrypted using S, which says "Did you feed the cat?". She presumes this message is from Bob, so she answers "No, go ahead and feed the cat". Mallory redirects this response back to Alice too. Alice receives "No, go ahead and feed the cat" and she concludes Bob hasn't fed the cat so she feeds it again.

Oops.

The proof was fine, but we brought an assumption along that we did not clearly articulate.

† You never use this mode in your web browser, but IoT things might do this because it's easier than all that stuff with certificates.

> The work you have to do to show your compiler that certain constraints hold

In rust, that's what the unsafe keyword is allowed. It doesn't mean that the code is actually unsafe, but rather that the compiler should trust you on this one.

You can avoid virtually all friction by sidestepping shared mutable references altogether and writing your GTK application in a more idomatic Rust way. For example, instead of passing shared references of application state to every widget signal, you can pass async Rust channels to signals. You can spawn a single async event loop attached to GLib's main context that listens for events sent from those signals, and manage all your widgets and application state in one place.

There's some libraries that effectively automate GTK in this way, such as relm4.

Thanks for the link, the last time I used Gtk-rs, the book wasn't yet a thing, you can imagine how much fun I had learning those patterns on my own.

Yes, there is relm nowadays, which was yet to be born when I did my Gtkmm => Gtk-rs port.

At least I can also now point others to the book.

Depends on what parts of the environment you're looking at. The compositor that's the basis of the entire environment will be written entirely in Rust, based on smithay. But applications written for COSMIC are currently based on GTK4.

GTK is currently the best GUI toolkit for Rust application developers. It's the only toolkit that's fully functional with first class and official bindings. It's been pretty well endorsed by GNOME for most of their new applications lately.

There are some Rust GUI toolkits out there that are shaping up, such as some former Qt developers actively developing sixtyfps, but it'll be a while before we have a GUI toolkit in the Rust space that's truly ready for complex application development.

Easy, it's for advertising reasons.

Devs, admins, enthusiasts etc. are the main target for Systems 76. Hackernews audience is very enthusiastic regarding Rust.

I think it's indeed unfair to GTK.

Reply on news.ycombinator.com