Live data from Hacker News

Exploring System76's New Rust Based Desktop Environment

blog.edfloreshz.dev

271–280 of 408 posts

Re: Exploring System76's New Rust Based Desktop Environment

#271
post #261

Earlier quoted context omitted.

It could, but hasn't been - and GNOME is hostile to users/devs doing such things so it probably never will.

That's categorically false, there are issues to fix both of those in the gnome settings: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues... https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues...

Which are 2 years and 12 months old with little to no work done on each.

And as a counterpoint:

https://gitlab.gnome.org/GNOME/gtk/-/issues/233

Open, locked, and 17 years old.

GNOME cares about nothing that doesn't fit precisely into their "vision". This could turn out well! But it doesn't change the situation for any external contributors, or anyone who wants functionality changed in a way that the GNOMEr's that be don't agree with.

Re: Exploring System76's New Rust Based Desktop Environment

#272
post #145
post #109

Earlier quoted context omitted.

DEs are just the window dressing and computer management. That's how you end up in a situation where the contents of the window clash with the dressing because more and more apps can't be themed. If they want a consistent look they'll need to fork or write a whole new set of apps.

The irony is that the reason why authors claim when they remove theming is to have a consistent look. For some apps I don't care too much, because I run them in full screen anyway, and their specific look is adjusted to their function: IDEs, DAWs, even graphic editors. But if they do support DE-wide themes, I do appreciate that!

Consistent look?

If you’re thinking of the website I’m thinking of [1], the screenshot they lead with isn’t just inconsistent. It’s broken, with light text on a white background. And I’ve seen apps fail in that same way for real when trying custom GTK themes.

It’s the same reason web browsers can’t change the system CSS stylesheet without extreme measures like Reader Mode that strip almost all of the design work out of the site: it’s hard to mix design work from two different people (the application author and the theme author) without risking a total mess.

[1]: https://stopthemingmy.app/

Re: Exploring System76's New Rust Based Desktop Environment

#273
post #256

Earlier quoted context omitted.

> Gnome doesn't want thousands of developers implementing their own visions for their projects and others don't want to donate their time to implementing gnomes vision. This is definitely looking more-and-more like the case. The GNOME team's insistence on cutting people out of their workflow has left them with less contributors... which leaves them with a worse desktop and a roadmap that's being pushed further-and-fu…

It's not easy for me to take this comment seriously because gnome doesn't actually have anything anyone could define as leadership. It's a decentralized open source thing. You might be incorrectly assuming bad faith.

GNOME has a foundation[0] that is responsible handling their funding as well as setting goals/standards for their desktop. As a matter of fact, they're the most well-funded desktop environment in the entire Linux desktop landscape. I think criticism is fair, especially when it pertains to removing features and working against the community using funding that is, in large part, raised by said community.

[0] https://foundation.gnome.org/

Re: Exploring System76's New Rust Based Desktop Environment

#274
post #261

Earlier quoted context omitted.

It could, but hasn't been - and GNOME is hostile to users/devs doing such things so it probably never will.

That's categorically false, there are issues to fix both of those in the gnome settings: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues... https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues...

The first is two years old the second one is a rehash of a two year old issube Since this is about when gnome switched to gitlab they might be further history.

They have a history of finite resources and inability to resolve issues in a timely fashion. They ought to set goals and raise money. People really need to commit their money if they want nice things.

Re: Exploring System76's New Rust Based Desktop Environment

#275
post #251

Earlier quoted context omitted.

Gnome doesn't want thousands of developers implementing their own visions for their projects and others don't want to donate their time to implementing gnomes vision. The proper thing for them all to do is all implement their own visions and people to use or work on what they please. Nobody asks why Tesla, Ford, and Toyota are wasting everyone's resources by being different company. Nobody suggests having different c…

>Also gnome is so flawed in so many ways from leaking memory due to unfixable mismatch between js and compiled code, to nonsensical handling of multiple desktops, to add-ons that both rely on monkey patching your desktop due to lack of addon api and can with a single crash kill your whole session, to hostility towards themeing, to ugly header bars, to hostility towards support for non gnome desktops. Most of these is…

How they handle multiple monitors is a choice and the memory leaking is a design decision as is the lack of addon api and a system where any crashing addon takes out the whole session.

Bugs are inevitable but bad design is not.

Re: Exploring System76's New Rust Based Desktop Environment

#276
post #261

Earlier quoted context omitted.

That's categorically false, there are issues to fix both of those in the gnome settings: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues... https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues...

Which are 2 years and 12 months old with little to no work done on each. And as a counterpoint: https://gitlab.gnome.org/GNOME/gtk/-/issues/233 Open, locked, and 17 years old. GNOME cares about nothing that doesn't fit precisely into their "vision". This could turn out well! But it doesn't change the situation for any external contributors, or anyone who wants functionality changed in a way that the GNOMEr's that be…

That's not a counterpoint, the rest of your comment doesn't follow either. Check the most recent comment for suggestions on how to help out with changing the functionality: https://gitlab.gnome.org/GNOME/gtk/-/issues/233#note_1106706

If you've got some code to contribute to that, ping the developers on IRC. Adding more comments to that issue isn't helpful. These issues aren't suffering from a lack of comments, they're missing someone to step up and do the work. The original comment was that they were hostile to this, which isn't true.

Re: Exploring System76's New Rust Based Desktop Environment

#277
post #100

This blog post focuses on some superficialities of how their DE's apps will look slightly different. That's understandable for first impressions. I do hope these superficialities don't have all of System76's focus, as they're a dime a dozen in Linux DEs. Even the category of "we kind of look like Gnome, but with more familiar workflows" is oversaturated amongst Linux desktops (Budgie, Xfce, Cinnamon, MATE, Elementary…

> System76 with Pop_OS! has an opportunity to tackle topics head on like "we can make fractional scaling work somewhat decently across all apps" (IIUC currently requires shipping a forked XWayland, unfortunately)

I'm excited to see System76's implementation of fractional scaling in this new desktop environment. Since they have actually sold laptops with 1080p and sometimes 4K displays, they have a real incentive to get this feature working smoothly on Wayland.

System76 previously developed a HiDPI daemon for X11 to be used with GNOME Shell:

- Blog post: https://blog.system76.com/post/174414833678/all-about-the-hi...

- Help page: https://support.system76.com/articles/hidpi-multi-monitor/

- Source: https://github.com/pop-os/hidpi-daemon

It handles multiple scaling factors, including fractional ones, flawlessly across displays.

If the next version of COSMIC supports fractional scaling on Wayland as well as this daemon does on X11, this alone would make the entire project worthwhile. GNOME Shell still hides fine-grained fractional scaling behind an experimental flag for both X11 and Wayland,[1] with X11 needing a patch for Mutter.[2]

[1] https://www.linuxuprising.com/2019/04/how-to-enable-hidpi-fr...

[2] https://github.com/puxplaying/mutter-x11-scaling

Re: Exploring System76's New Rust Based Desktop Environment

#278
post #256

Earlier quoted context omitted.

It's not easy for me to take this comment seriously because gnome doesn't actually have anything anyone could define as leadership. It's a decentralized open source thing. You might be incorrectly assuming bad faith.

GNOME has a foundation[0] that is responsible handling their funding as well as setting goals/standards for their desktop. As a matter of fact, they're the most well-funded desktop environment in the entire Linux desktop landscape. I think criticism is fair, especially when it pertains to removing features and working against the community using funding that is, in large part, raised by said community. [0] https://fo…

That isn't how gnome works, being decentralized and all. The foundation pays for very little of the development and has little to no influence over what developers actually do. If you wanted the community to have more influence over development, the way to do that would actually be to get more money for the foundation so they can afford to hire more developers from the community. Right now, they don't employ any. The funding they have now is actually shockingly small for a nonprofit based in the USA, and almost unnoticeable compared to what a tech company based in the USA would have.

Removal of features would still happen though because that's a natural part of any software project responding to the ever-shifting priorities of a large group of users.

Re: Exploring System76's New Rust Based Desktop Environment

#279
post #252

Earlier quoted context omitted.

> Sounds like you want high level bindings, instead of gtk-rs. Have you tried relm4? No, because as of 9.0.0 it was perfectly capable of building ergonomic UIs and works with external tools like Glade. It used to have plenty of features, now it does not. I haven't tried relm4 because I'm not going to write any apps for GTK4 while it's still broken (egregious text rendering issues, assistive tools like Cambalanche are…

That seems like a lot of revisionist history. From what I've seen GTK never had good cross-platform development support. Programs like GIMP and Inkscape always looked and behaved very oddly to me on other platforms. The little support that's there is because interested parties contributed it. If this is what you want, it's self-defeating to refuse to contribute it. If you do not want to use Rust, you can always use a…

> From what I've seen GTK never had good cross-platform development support.

From the start, GTK was written so that it would have good cross-platform support. GTK itself (not GNOME or Glib) is perfectly system agnostic, and as you've mentioned, it compiles and runs on other platforms. Not sure why you'd knock the way GIMP and Inkscape LAF on other systems; they both look perfectly native on Windows, and much better than the majority of cruddy MacOS desktop app wrappers. If there's a "more native" solution, I'd like to hear it.

> The little support that's there is because interested parties contributed it. If this is what you want, it's self-defeating to refuse to contribute it.

I can't. The GNOME team never opened libadwaita for public comment, or held any forums where I could voice concerns with the direction they were headed. They won't accept contributions that allow cross-platform stylesheets because it would undermine GNOME's own authority as a middleware distributor. I can understand how this all sounds accusatory, but I really do recommend that you research it. The community has been completely locked out of the GNOME decision-making process.

> If you do not want to use Rust, you can always use another language like Python or Javascript. I might be misunderstanding because the rest of your complaints are jumping around a lot

My problem here is explicitly with gtk-rs, a Rust crate that handled GTK bindings. It was a really good library until it hit v14, when the developers lobbed off support for Glade files as well as idiomatic/procedural app design. Now, the crate is pretty much useless as anything other than a GNOME support tool. This expanding GNOME-ification is particularly concerning because, as mentioned before, the GNOME team pretty much doesn't care about anything the community has to say. It's a bad direction for the project to be heading in, and it definitely makes it harder for regular people to write good-looking, system-agnostic GTK apps.

> it would be easier to understand what you're talking about if you shared some code illustrating what the problem is.

I wish I had code to share. I haven't been able to successfully port any of my apps with full feature parity on GTK4. The gist of my code/ergo concerns mostly boil down to this; v9.0.0 allowed you to build programs functionally and register their various interfaces as closures. This made it fairly simple to not only separate UI code from function code, but was also really comfortable to write "like a normal app". v14 eliminated this workflow though, instead forcing you to write UI code with Rust the same way you write the interactions, which have now shifted from a "flexible functional approach" to pure-object-orientation. For a language like Rust, that's two steps removed from madness. It's certainly not a great approach for small, hacked together utilities, and it completely throws the more advanced, idiomatic programs under the bus.

Re: Exploring System76's New Rust Based Desktop Environment

#280
post #251

Earlier quoted context omitted.

>Also gnome is so flawed in so many ways from leaking memory due to unfixable mismatch between js and compiled code, to nonsensical handling of multiple desktops, to add-ons that both rely on monkey patching your desktop due to lack of addon api and can with a single crash kill your whole session, to hostility towards themeing, to ugly header bars, to hostility towards support for non gnome desktops. Most of these is…

How they handle multiple monitors is a choice and the memory leaking is a design decision as is the lack of addon api and a system where any crashing addon takes out the whole session. Bugs are inevitable but bad design is not.

The only one out of those that's a intentional design is multiple monitors. The other ones are known shortcomings that are just really hard to fix. The memory leak was fixed a few years ago: https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...
Post reply on HN