System76 Reportedly Developing Their Own Rust-Written Desktop, Not Based On GNOME

[Anvil]

Seems unlikely when they use things like systemd-boot instead of the "oh balls there's a grub update, fingers crossed for no chroot required, no whammies no whammies..."

problem with systemd-boot is that it aint as configurable as Grub is. afaict, systemd-boot is low maintenance

[shmerl]

What toolkit are they using? Having something that's matching Qt in functionality but written in Rust would be huge.

Rust has some rudimentary UI libraries, but nothing that can replace Qt proper.

[Myownfriend]

GTK needs to split from GNOME, IMHO.

This fragmentation occur (Solus is thinking about using EFL and Solus something else) because GTK is controled by the GNOME Project. I think that except from KDE nobody should use anything else, but the fact GTK is part of the GNOME project brings more fragmentation than it would be needed.

My suggestion? GTK should to be a freedesktop.org project or an independent project. This way, GTK could be more inclusive and projects can have confidence to use and contribute with the toolkit.

I'm not sure what that's supposed to do.

[Alliancemd]

I imagine they will use GTK-rs. It won't be GNOME but still using GTK

[brent]

Jeremy, the lead Sys76 dev, is already involved with RedoxOS and orbtk. I bet they'll just get the RedoxOS code, port to Linux and change the workflow.

https://github.com/redox-os/orbtk

PS: Yes, I think that all this theming drama was because Jeremy thinks they will be fine without GNOME.

Oh boy, yet another minimalistic UI toolkit. These toolkits are simple and elegant for one reason: they do a whole lot less than "real" toolkits like Qt or GTK. And I'm not only talking about fancy features, but inconvenient and complex but important things like internationalization and accessibility. None of these simpler UI toolkits support complex text layout, for instance, and that's something needed all over the world if you look beyond western countries.

[StarterX4]

yet another toolkit to add to the mess of toolkits on linux. one of the biggest complaints with windows at the moment is lack of UI consistency with all the different interfaces. linux is no different. i'm all for desktop environment choices but i wish they would all agree on a single, standard toolkit they all follow. if system76 is going to use their own toolkit it just add more of a mess.

Toolkit devs just ignite the situation with their dumb developing choices.
But still, why not fork the last right toolkit version and push it forward? Existsing software could easely port to it, and abandon GTK4 trash or forget about those commercial QT updates.

[StarterX4]

Jeremy, the lead Sys76 dev, is already involved with RedoxOS and orbtk. I bet they'll just get the RedoxOS code, port to Linux and change the workflow.

https://github.com/redox-os/orbtk

PS: Yes, I think that all this theming drama was because Jeremy thinks they will be fine without GNOME.

Or recently popular eGUI.

[Aisyk]

I love System76 for this, they always challenges projects and lead innovations. Building an entire DE from scratch is a very big challenge !

I wonder if RUST is a fastest language for the desktop, what are it's advantages (Wayland, Xorg...) ? Will it be supported by the graphic UIs in Linux (QT4-5-6, GTK-2-3-4...) at no cost for application developers like GIMP, Inkscape (because they don't have much dev energys)... ? Why this choice (except the Jeremy Soller's projects like RedoxOS) ?

[ssokolow]

They can still leverage existing libraries and apps, so it isn't an entirely impossible task. But as always, writing an app isn't the hardest part but supporting it in long-term is. Although, since they're targeting Rust, it makes me wonder how mature are the Rust bindings for e.g. Qt or GTK? The showcase for GTK/Rust had only a few smaller apps. Trying to build an entire ecosystem on top of them will surely hit a few hard blocks.

There are basically three options for binding Qt right now in the Rust ecosystem:

1. KDE's Rust Qt Binding Generator, which is more about integrating Rust modules into an existing C++ project with its own pre-existing build automation and, thus, punts on binding the QWidget APIs.
2. Ritual and its rust-qt bindings, which is developed in fits and starts, gained signals and slots in its last burst of development but is still waiting on subclassing, and mostly produces unsafe Rust APIs for lack of the manpower to fill in the binding definitions. (I've often wondered how viable it would be to design a Rust binding generator which reuses the definitions from PySide's shiboken binding generator.)
3. QMetaObject. I'm unsure how mature it is, but it's the closest thing to the GObject Introspection approach gtk-rs uses. The problem being that Qt only has the requisite metadata for the QML/Qt Quick side of things, and Qt Quick is still too incomplete and feature-poor compared to the older QWidget APIs. (eg. I tried using Qt Quick to port something that seemed perfect for it, only to discover that StackLayout, the Qt Quick replacement for QStackedLayout, was added after the Kubuntu Linux 20.04 LTS feature freeze.)

No idea how mature gtk-rs is, given that it was introduced for GTK 3.x and my only use for post-2.x GTK is QuickTile, which was ported from PyGTK to PyGI, has no visible UI, and only relies on GTK because Qt has no libwnck equivalent.

GTK needs to split from GNOME, IMHO.

This fragmentation occur (Solus is thinking about using EFL and Solus something else) because GTK is controled by the GNOME Project. I think that except from KDE nobody should use anything else, but the fact GTK is part of the GNOME project brings more fragmentation than it would be needed.

Don't forget the developers of LXDE beginning a move to GTK 3.x and then deciding to cancel it, merge with Razor-Qt, and produce LXQt instead.

"Wayland is a protocol XDDD" has worked exactly as well as I would have expected.

It's not "Wayland is a protocol" that's the problem. X11 is a protocol. The problem is that Weston (the X.org analogue) failed to take on the role that wlroots is slowly achieving. (Bear in mind that, for most of its life as XFree86, X.org wasn't the only X11 implementation.)

Or recently popular eGUI.

eGUI is an immediate-mode GUI. It punts even more to the application developer than a retained-mode GUI like GTK, Qt, or OrbTk.

[ssokolow]

Poke poke. Unapproved.