System76's Pop!_OS COSMIC Desktop To Make Use Of Iced Rust Toolkit Rather Than GTK

[mmstick]

Now you really have to tell me how on earth Rust and a DE written from scratch can be a necessity to have a usable store? Worst case just use the default Gnome store, that still gives you a much better experience than that Frankenstein thing S76 half-assed ripped out of elwmentaryOS.

First of all, the elementary appcenter is perfectly usable today and our use of it is a collaborative effort with elementary. When we make improvements to it, elementary also gets those improvements. elementary improved it a lot in the 22.04 release, and so now it's very responsive. One of our team members made some great progress in making the shop more responsive to small screens and widths. Besides the issue with error dialogs crashing the application from a memory safety violation lately (exactly why we use Rust!), it's a decent application store. On Monday, we'll release an updated package of the store with the error dialogs fixed.

That said, you're asking some things that should be obvious. Why would an engineering team that's strongly focused and centered on Rust want to use Rust, or want a Rust GUI toolkit, to write their own applications with. Hmm, I wonder. Maybe it's because they need a GUI toolkit to develop an application with, and Rust is what they're experienced in and motivated to work with. And unless there's a good reason to do so, the current application store works fine, and any decision to make a new store would require a lot of UX investment that would have to also be compatible with COSMIC goals and plans.

[Artim]

First of all, the elementary appcenter is perfectly usable today and our use of it is a collaborative effort with elementary. When we make improvements to it, elementary also gets those improvements. elementary improved it a lot in the 22.04 release, and so now it's very responsive. One of our team members made some great progress in making the shop more responsive to small screens and widths. Besides the issue with error dialogs crashing the application from a memory safety violation lately (exactly why we use Rust!), it's a decent application store. On Monday, we'll release an updated package of the store with the error dialogs fixed.

That said, you're asking some things that should be obvious. Why would an engineering team that's strongly focused and centered on Rust want to use Rust, or want a Rust GUI toolkit, to write their own applications with. Hmm, I wonder. Maybe it's because they need a GUI toolkit to develop an application with, and Rust is what they're experienced in and motivated to work with. And unless there's a good reason to do so, the current application store works fine, and any decision to make a new store would require a lot of UX investment that would have to also be compatible with COSMIC goals and plans.

Now you're getting even more ridiculous. The shop is far from usable. Constant glitches are all you get. And it's only getting better when you admit that you people simply aren't capable of doing anything else than rust so you create a whole new DE from scratch just to use Rust for the sake of using Rust, just to be able to make an App Store that doesn't fall apart left and right. Do you ever read what you are writing? Maybe you should just hire some competent programmers so you don't have to waste time on such a nonsense. Or simply use what's already there instead of reinventing the wheel just for the sake of reinventing it. Like I said, Gnomes own software shop works a hundred times better than your Frankenstein monster. And vanilla gnome looks and works at least a hundred times better than that abysmal themed Gnome you call pop-session (plus it's not interfering with other GNOME extensions) and probably also than what you are cooking up.

Let's be honest, your users are accustomed to GNOME including all extensions they use. Your sole argument for not going full in on Gnome 42 and GTK4 was literally to ease the users over from the GNOME 3.x and GTK3+ days to have less of a break, yet you cook something up that's impossible to deliver everything the users had with GNOME. Not only is it unclear if Cosmic will even allow extensions, but even if it did I very much doubt it will have full support for Gnome extensions (otherwise there would even be less use in Cosmic). Who do you think would port all those extensions to Cosmic? So in the end, the user experience can only be worse. Now tell me, what should be the actual, user facing improvement? Sure, we all hope it will work better than the current solution, but that can literally be achieved in an afternoon by getting rid of 90 % of your changes to GNOME, especially getting rid of that Pop shop. The user experience would be immediately skyrocketing. Add one or the other Extension that brings back some useful features like having the hidden dock appear on mouse approach and you'll have the best user experience you can offer. And it will look much more modern. And no, "It'S wRitTeN iN rUsT!!!" is not a user facing improvement. The user doesn't care for Rust. But only being able to write something that actually works in Rust doesn't speak for the developers. Or better, the ones who hired them. Same goes for making projects wasting years of time to have a usable experience, when ob really all it needs is less needling with things instead of more.

[Charlie68]

I read the whole discussion and it was quite comical. Unfortunately, there is little that can be done when users become fanboys.

[mmstick]

Now you're getting even more ridiculous....

tl;dr. If you don't want to use the pop shop then don't. No one's forcing you to use open source software.

[marlock]

tl;dr. If you don't want to use the pop shop then don't. No one's forcing you to use open source software.

IMHO if you indeed work with PopOS, you shouldn't bite the bait like this in comment sections...

If a goodwilled user comments on a usability issue, they'll either provide more concrete details upfront (hoping the issue is solved after their feedback) or will at least be willing to provide more specific insights when asked for it.

OTOH if you engage someone that's just pissed-off with the same question (without hints of antagonism or distrust), it will usually disarm them or turn them away if they're trolling.

Your "don't use it then" response can both scare goodwilled users and feed trolls, even if you feel it's warranted after a fair amount of provocation (which definitely happenend here already).

Artim, can you be more specific? which sort of usability issues are you actually referring to? which sort of glitches exactly? years of steam for linux forum dwelling showed me very few recurring complaints from PopOS users (mostly not linux-savvy ones), so it's hard to believe the issues you alluded to are as widespread and critical for usability as you make them seem here... maybe it's been a while since your last attempt at using Pop, maybe those issues were more specific to your machine and had underlying causes outside PopOS, or maybe you're just coming from a different usability perspective than those users, so it would be nice if you drop the stones and actually help them gain insight?

[marlock]

now about the article itself:
it's clear that Rust as a programming language is here to stay... it's been deemed useful enough for linux kernel development where the requirements for supporting a new language are very strict, it's gradually showing its merits as a means to detect issues earlier and produce safer and less buggy results in initial iterations of new code... "loosing time" on it now might avoid loosing more time than that in code review and bug fixes later

of course writing a new toolkit is an enormous task, and it might not pan out in the long run, but the tension between gnome devs and gtk-based DE and distro devs are evident and don't seem to be diminishing over time, so it's unsurprising that someone that can pay for a sidetrip will attempt it... I just really hope they succeed in making the new toolkit something broadly useful and not a niche thing for PopOS alone like Unity, SNAPS, Mir and so much more was just for Ubuntu. In my narrow experience as a non-dev user, Linux Mint devs have proven with x-apps that partnering with other distros to create stuff that solves shared issues is a more sustainable path amid so much choice (and yes, fragmentation)

I don't hate what GNOME is achieving from a user perspective, particularly what can be seen produced with Purism for GNOME Mobile (which would more accurately be described as GNOME Convergence because they're managing to push apps that really adapt to both portable small screen touch devices and traditional PCs on the same apps instead of creating new apps "for the smartphone")... and the need to reduce app UI breakage derived from layout tweaks at the distro level is real, regardless of what each person's position on the best solution is...

...but I also see tangible issues posed by GTK changes, libadwaita, cut features from GNOME, frequent UI/UX breaking changes, etc, and how hard it is to have those addressed by GNOME and GTK devs with enough consideration for those other DEs and Distros... and I trully doubt a decision like this is taken lightly by the Pop devs.

In short, anyone pretending this is an easy problem with an obvious and immediate solution is a fool and having competing solutions (with cross-project collaboration intact) is perhaps a reasonable path forward at this point.

[microcode]

Is the accessibility stuff figured out in iced? Guess I'll give it a look see.

[ClosedSource]

You can create dynamic libraries in Rust, and there are some libraries that can automate this at a high level for Rust-to-Rust FFI, such as cglue and abi_stable. However, there isn't much demand for this. Since most Rust libraries are very small, or contain generic functions and types, there isn't good reason to put in that kind of effort. You have to have a special case to make this worthwhile. Generic functions and types also cannot be compiled unless they have their types defined. When using a library with them, their code cannot be generated until the application using them defines the types being used with them.



You're overestimating the size of the binaries quite a bit here. The source code in iced is very simple so there's not much to compile and link. The vast majority of code is generated at compile time by the application. Code that wasn't used by the application will not be linked into it. Some of the smallest Flatpaks are Rust applications by the way. I'd imagine that the GUI code embedded into the binary would be within the order of a photo from a camera.



This isn't the job of an end user to worry about. Libraries receiving bug fixes is more a matter for the developer to be concerned about than the user. Regardless of what fixes that a development dependency receives, you still have to wait for the application author to release a new version of their application with an updated lockfile. A process where the developer has to validate that the updated dependencies have not caused any regressions in their application.



Package maintainers already don't rebuild C applications when they receive commits with bug fixes. They will either wait for a release or withhold updates until the next point release. Only the more severe issues get special treatment that warrants adding patches to an otherwise frozen package.

It's generally not the job of the package maintainer to mess with dependencies without good reason and their own QA to validate that the changes they made haven't caused a regression. Those who do already have a CI in place to automatically rebuild packages when a source crate is updated.

First of all, I am a maintainer for multiple stacks at a local university distribution.
Secondly, they don't rebuild single packages when gtk3 gets bug fixes because the applications which just use the updated shared library. Your framework may be tiny but the app code won't. Imagine rewriting evolution-data-server or gstreamer or ffmpeg as rust crates and expecting everything to embed them. You don't make much sense here. Rust is not the correct tool for this.

[Artim]

Artim, can you be more specific? which sort of usability issues are you actually referring to? which sort of glitches exactly? years of steam for linux forum dwelling showed me very few recurring complaints from PopOS users (mostly not linux-savvy ones), so it's hard to believe the issues you alluded to are as widespread and critical for usability as you make them seem here... maybe it's been a while since your last attempt at using Pop, maybe those issues were more specific to your machine and had underlying causes outside PopOS, or maybe you're just coming from a different usability perspective than those users, so it would be nice if you drop the stones and actually help them gain insight?

Besides the fact that it throws completely uninformative errors that make it impossible to help novice users (other than use apt and tell us what it says), like I said it falling apart left and right with graphics glitches hiding important details or making the drop-down for selecting deb or Flatpak unusable, or just plain refusing to install/update (only showing an animation but not actually doing anything). Also it doesn't seem to handle multi user environments that well, I have yet to find a way to completely disable update notifications system wide.

But to see the problems you literally just have to look through the Pop OS Reddit. Pretty much not a single day goes by without someone needing help with the Pop Shop because it's either throwing unhelpful errors or just not doing what it's supposed to. Sure, I'm not using that thing anymore, apt is way more reliable. But you shouldn't need to tell novice users to do so. A well working software shop should be one of the highest priorities for a Distro catering to absolute beginners, first impression is key. If you can't even deliver that, you shouldn't be taking about reinventing the wheel, just because.

Besides the fact that support for Pop could be improved a lot. If you got problems that are less common, just nobody gives a rats ass. Not on Reddit and not on their own git. And yes, I am talking from experience.

[Alliancemd]

Linux is just too fragmented to be successful. There are already too many toolkits and even the ones that are available have no concept of backward compatibility. I read about Gnome team rewriting their gtk+3 apps to support gtk+4.

`iced` is not a Linux "toolkit". They write their apps in whatever they want, why do you care?