Exploring System76's New Rust Based Desktop Environment
blog.edfloreshz.dev
blog.edfloreshz.dev
What I really wonder about is Wayland support. Is this going to be a brand-new DE that's X only? That would be a real shame. I know System76 has stuck doggedly to X because they sell so many NVidia cards, but NVidia supports GBM now.
1: https://github.com/pop-os/cosmic-comp/blob/main/Cargo.toml#L...
EDIT: Just found this, which explains a bit: http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i...
Succeed at what ? Re-implementing Gnome in Rust ?
> Re-implementing Gnome in Rust
That seems a bit disingenuous. It's all still GTK.
sure they are a bit more related then KDE and QT, still but the same at all
Are their Clevo-based laptops designed in-house? If they are, why are they designed with such abysmal speakers, mediocre webcam and no attempt to go past the full-HD screen resolution? Why not design something cool like Framework?
This would really be a game changer. Unfortunately, you need a really great number of units, that building your own custom laptop hardware is feasible. I really which System76 success with that.
I always thought, if Dell were smart, they would do their own Linux-based brand, where they would reuse parts from mainline Dell. Kind of how they produce gaming laptops.
- Article: https://www.forbes.com/sites/jasonevangelho/2019/11/20/syste...
- HN: https://news.ycombinator.com/item?id=21586422
If you have any suggestions for the laptop design, System76 is collecting feedback here:
Not re-implementing Gnome. Not re-implementing macOS which Gnome strives to imitate. OTOH I see the value of that: many people got used to macOS, and making things similar, and the cognitive load of switching low, makes business sense. Same as with Windows in early 2000s.
Apple had fiery fest of sales in Q4 2021, outsold all Wintel manufacturers, let alone Chromebooks. And after that, guess what, they now have 8% of desktop/laptop market share, instead of 6% they used to have. You can guess who covers most of the other 90+ percent.
Sent from my 2021 M1 Max MBP.
I use Cinnamon with Manjaro - it is not GNOME but it is GTK. Unity was the same. MATE is old GNOME but quite different from new GNOME — still GTK though. XFCE, LXDE, and pretty much every popular DE outside KDE and FVWM2 is based on GTK.
Choosing Rust has nothing to do with re-implementing GNOME either although I do like that choice. If nothing else, this ensures well tested Rust bindings and paves the way for devs to write other GTK apps in Rust—-perhaps even ones intended to target GNOME itself.
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.
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!
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.
GNU/Linux apps will never have something like OLE 2.0 or XPC that actually works consistenly across desktops.
There is D-BUS, but not everyone cares it is there.
Do any Linux experts out there feel the same way?
https://github.com/pop-os/cosmic-comp/blob/main/src/backend/...
Unpopular opinion, but more DEs is fine and good, especially if they will have teams that are either (a) large or (b) well-funded. Plasma and GNOME are very good, and Unity was actually great to use in its heyday.
Imo what we don't really need more of are the conservative, under-resourced 'classic look and feel' DEs like most of the minor players in the space. Those tend to end up incomplete and ill-performing, and there are already lots of them. I hope the existing ones thrive, but I don't think having more f them would do much good.
But anything as good as the big two, but with a different focus? Let's see it!
Lxqt is the closest to allowing that because it wraps standard tools when possible, but this wrapping of standard tools also means that those tools don't really work.
For example, I use slock for screenlocking, but there is actually no working third party freedesktop screensaver implementation that doesn't tie you into their DE.
Xsecurelock seems to have hacks for it, but it can't even do something as simple as just showing an image without breaking with the wrong window compositor.
Or if they're interoperable. For instance, icewm doesn't have a screensaver of its own, but it just uses xscreensaver so it's fine.
And that's the problem with the proliferation of DEs. Applications, which range from having no developers actively working on them, to the best teams at Microsoft working on them, have to handle yet another DE, and have to deal with the bugs raised by the users of yet another DE, etc.
UI/UX is hard enough to begin with, but requiring devs to either maintain several UI/UXs, or try and come up with a design that works across the proliferation of DEs is highly counterproductive.
Ideally, that's what the freedesktop.org specifications help with. You build against the specs and interfaces, and the code should work across DEs that implement specs from freedesktop.org. In my (albeit limited) experience of writing against freedesktop.org specs, it works pretty well.
Very few developers actually attempt to do this, on any platform— virtually none, as far as I can tell. It's slightly more common on macOS for developers to actually try to emulate or reuse the design language and look-and-feel of the base system. But on every platform, it's extremely common for GUI apps to just throw the design language and other details of platforms they run on completely out the window. It's the M.O. for the most popular cross-platform toolkit right now (Electron). For every app that maintains multiple UIs, there are at least ten that do that, maybe a hundred!
Besides, COSMIC doesn't use a new graphical toolkit. It uses GTK+, just like GNOME.
But even without them caring for UI/UX, the proliferation of DEs, even with common UI toolkits in the Linux world means they spend a lot of time and energy working on bugs that are not true bugs but are artifacts of a UI theme that the developer did not consider while developing their app.
For example, it's almost certain that the unified tooltip in COSMIC will lead to bugs complaining about how users are unable to drag the window by clicking on the chrome. In this case it would be fairly easy for a dev to close the bug because this is such a prominent and obvious difference in COSMIC. But there will certainly be other UI differences that will not be as easy to pin down to being the result of COSMIC's UI changes, and will not be as easy for devs to close.
Edit: it's GTK so no problem
System76 is only adding to that mess.
Heck, many apps are web-based and uses electron anyways, and those are generally multiplatform anyways.
I think if whatever app they make/port worrks via Flatpak, it should work on all/most modern distro.
I use KDE now which does provide a lot of choice but I'd love something that has tiling built in. And yeah I know there's add-ons for KDE that do that :)
Edit: this is the one: https://github.com/Bismuth-Forge/bismuth
There's also kwin-tiling https://github.com/kwin-scripts/kwin-tiling
Not sure which is best tbh. I have yet to try them
Guide: https://userbase.kde.org/Tutorials/Using_Other_Window_Manage...
I tend to disagree here. I recently switched back to MacOS after years of running both. The DEs on Linux are just one generation behind. Things have gotten better, but macOS and to an extend Windows are ahead.
Linux DEs would be well advised to onboard more graphics and UI experts to make them more user-friendly and stable. Desktop metaphors have more or less stabilized and it's counter-productive to have 5 takes on the Linux-side alone.
The entire problem starts and ends with this term. It is ambiguous, personal, localized, fluid and case-dependent.
What is friendly to one user, is insulting to another. What is friendly to me at 10:00 in the morning is frustrating when I have a presentation in two minutes. What is friendly to an American pensioned welder, is insulting to an Iranian accountant.
Just to explain why I love Linux so much - when I'm in Gnome, I'm not bothered by any alerts or notifications or popups or sounds or ads or anything! It's a silent, stable, good looking desktop that runs my programs and doesn't get in my way at all. It's amazing! I truly love it.
I think Linux DEs are fine, it's just that the default config / on-boarding rarely asks what the user wants and what they need.
More distro/DEs need to incorporate UX/Desktop Layout Switcher, like Ubuntu Budgie, Zorin OS (Gnome, XFCE), Manjaro (Gnome, there are plans to do KDE as well in the forum?), and FerenOS. It'll solve the issues of personal preference in UX, as people could just one-click choose what feels/looks the best for them.
I personally don't mind taking a few hours setting up the UX I want with Fedora KDE, but I doubt most others do.
Breaking compatibility with Ubuntu-compatible dev tools is one thing, but the lack of awareness or consideration of tooling standards is evidence that Pop_OS! is not for me.
Unfortunately, the `tensorman` article shows up first (after several complaint/support threads) in a google search result for the subject https://www.google.com/search?hl=en&q=nvidia%20docker%20pop%...
In all actuality, the correct article to reference is https://support.system76.com/articles/cuda/ but alas, this is presently broken on PopOS 21.04 unless you pin nvidia's repo's as you've suggested.
At the very least, an unpleasant experience. Probably some blame to be shared by system76 and nvidia.
https://github.com/pop-os/nvidia-docker/commit/aa9fbcff6e6e5...
This changes nothing about my story of the Pop OS developers previously thinking it could be replaced with their bespoke custom tooling.
I won't ever defend nvidia, but... I really think Broadcom is worse. They've ruined tons of routers and wireless cards. Also, the Raspberry Pi is full of blobs because of them.
CUDA support in Docker requires nvidia-docker+nvidia-container-toolkit+libnvidia-container, and that is the whole point of having nvidia-docker installed. We validate that CUDA functions inside of Docker when pushing updates to nvidia-container-toolkit and friends.
Tensorman is not a replacement for nvidia-docker, and you're not going to get anywhere by trying to convince me about the functionality of something that I personally wrote. It is quite literally just a simple command-runner that runs docker commands, specifically for the purpose of managing the official Tensorflow Docker images, and getting a more streamlined setup for managing your local Docker images based on them. The sole purpose is to replace our previous tensorflow packaging in Pop!_OS that became impossible to package because newer versions of Tensorflow did not build beyond 18.04. Tensorflow themselves recommend using their docker images instead of trying to package and install their libraries on your host OS.
Screen sharing is already made easy with Pipewire. I've not seen any issues with copy/paste between applications. WiFi driver issues can only be fixed by kernel driver developers with hardware documentation for the exact model of the PCI device they're writing a driver for. The same goes for touchpad drivers, but I've not had any issues with them on our laptops. We sell systems where we can vouch for the quality of the driver support in Linux for the WiFi and touchpad.
I think if Apple had embraced free software early in its history, it could have known a much brighter future (err, present?). Hell, even HyperCard may still be alive and kicking.
But I'm always skeptical when underlying language choice is featured prominently as a selling point for any new project.
It tells me, this is a technology-first, users-second enthusiast project.
And thus, I'll be surprised if it tackles the deepest issues users need solved.
That doesn't mean it isn't cool as a proof of concept for a new or popular language.
It just makes me question to what extent it's going to solve the deepest problems with similar or older projects it is competing against.
A Ctrl-F rust showed no results.
This post's author just likes Rust.
As a System76 fan, I too am curious to see what the point is. I have no idea what Rust is nor do I care.
Now, 90-95% of users use GNOME or KDE, having some competition from a `new` GTK4 DE can't be bad, so I would like to see Cosmos gain attention, and maybe be ported to other distros.
Jokes aside: during early development it makes perfect sense to advertise tech being used, because the audience is so different at that time. So even if system76 would "shill" it as a Rust DE, at this phase, that would be fine, because of the highly technical audience.
Oops! That should read
> the existing engineering talent there
apologies. Missed the edit window on the comment, and only saw the error now.
I'm not at System76 and never have been
> It tells me, this is a technology-first, users-second enthusiast project.
> And thus, I'll be surprised if it tackles the deepest issues users need solved.
Some of the deepest issues that users need solved are ones that Rust was designed to solve at the language and compiler level.
1. System stability and memory efficiency, zero or fewer crashes due to memory-safety or thread-safety problems.
2. Security and assurance via the elimination of entire classes of attack vectors like buffer overflows.
3. Highly performant, responsive applications that are a joy to use.
Solving problems at the compiler level eliminates the reliance on fallible programmers to do so. People also tend to discount maintaining those solutions over years of dev team turnover, startup failures, etc. Building those solutions, capabilities, and constraints into the language itself makes maintenance over the entire product lifecycle more consistent.
It's like buying a Toyota, you know from the brand alone that you're getting a certain baseline level of reliability, maintainability, durability, and longevity. Rust is like the Toyota of programming languages - it can produce many different types of cars/programs, but they're all guaranteed to come with a baseline level of assurance, and to eliminate common classes of problems that degrade the end-user experience.
It may not make sense for other languages to be prominently featured as a selling point, but Rust is an exception.
It's possible to make buggy, slow, crappy software in any language. Rust is no exception. Nobody should derive any confidence from the language a product is written in.
True.
> Rust is no exception.
Also true.
> Nobody should derive any confidence from the language a product is written in.
This, on the other hand, is a non-sequitur, or at least it's too strong, because Rust can do things that C can't do: safe deterministic memory management and safe concurrency without data races. These things are not just available, they are the defaults in Rust. You have to go out of your way to get these things wrong. So, I wouldn't derive absolute confidence from an application being written in Rust. But I'd be willing to bet a whole lot that it has fewer memory bugs than an equivalent application written in C.
Exactly, this is what I should have explicitly said. Language defaults have a powerful effect on a project's norms and culture.
> You have to go out of your way to get these things wrong.
Yes, you actually have to try to write shitty Rust code, at least where there are defaults that prevent it. Thus the average Rust program will have that baseline level of quality. Like TQM/TPM/Six-Sigma for manufacturing software.
Also that is besides the point, unsafe only deals with a very specific cause of errors that plague C code bases (and those of languages copy-paste compatible with it).
Rust's unsafe wouldn't have done anything to protect against an hypotetical log4r.
It is no accident that Ada and Java also have security guidelines similar to MISRA, because even with memory corruption bugs out of the picture, as log4j newly remided us, security only happens when it is part of the daily process, regardless of the language.
As for the memory fuckups you are right, pity that they are using a C GUI library.
Even if the binding has been deemed safe upon validation, if only remains a valid certification until the next Gtk version update, even minor ones might break the assumptions validated on the unsafe code block.
You are correct. No programming language will protect you from writing flawed application logic.
> pity that they are using a C GUI library. (...) Gtk version update, even minor ones might break the assumptions
I don't know about that. GTK is more "battletested" than most frameworks, and has a lot of contributors to fix bugs. Also, and that's a very important point, GTK cares for accessibility! Using any other framework would have meant excluding a lot of people from the GUI.
As for assumptions, i certainly hope GTK devs don't push breaking changes to the ABI on minor updates. But i guess that's yet another assumption that can be broken.
a conclusion or statement that does not logically follow from the previous argument or statement. "his weird mixed metaphors and non sequiturs"
You shouldn't dervive all confidence in a product from it's implementation language, but when you are looking at all available products and need to filter down to ones you might be interested in. Implementation language can be a useful litmus test for understanding how it might behave without doing a complete in depth evaluation.
For example if I learn that a desktop application is written in javascript, it is likely to be using electron or an OS webview. Or if an application is written in C++ it is unlikely to have GC pauses cause stuttery UI. Both of those assumptions may not be true (Sciter for JS and Boehm GC for C++ respectively). However those assumptions are a useful starting point unless proven otherwise.
Technically it's possible, but you have to try a lot harder to do it in Rust than most other systems languages.
Remember vala anyone?
Although I want this to succeed if it is infact more performant and smoother than GNOME.
That's not given.
> Remember vala anyone?
Vala is nothing like Rust, doesn't solve the same problems, and is much more narrow in scope (Gnome development).
https://webcache.googleusercontent.com/search?q=cache:AcldYn...
That Rust is much more capable doesn't matter.
It's more likely that by the time Rust makes an impact in Linux stability and performance - because you're using an OS, not just desktop environment - nobody will even remember what System76 was.
> Some of the deepest issues that users need solved are ones that Rust was designed to solve at the language and compiler level.
However, for System 76 Rust is a very good choice.
But calling it "Rust based" when it's GTK is clearly a bit bold ...
What?! The year of the Linux desktop hasn't been eluding us because of buffer overflows and memory safety. The Rust hype train is incredible. The Linux desktop problems have nothing to do with the goal Rust sets out to solve.
It's definitely a good choice of language for the problem, don't get me wrong, but choosing that language doesn't improve the chances of COSMIC revolutionising the Linux desktop situation one iota.
I also know that Linux desktops are often victims of memory bugs, and that a higher-level language for extensions is something people appreciate, that's why there's JS in GNOME.
That said, this is not the sole benefit of Rust. It is more of a side effect of aliasing XOR mutability than the primary benefit of Rust as a whole. Let's take a look at the C and Vala landscape as a comparison. Neither support message passing with channels, and async support is virtually an unmaintainable hack. Vala has generics thankfully, but C doesn't have generics and it's really bad. It also doesn't help that your only options for building software is pretty much almost entirely GLib and whatever sparse set libraries might be available for the package manager. Whereas with Rust there's a vast immutable repository of libraries you can leverage, and publishing open source libraries on the platform is easy.
> It tells me, this is a technology-first, users-second enthusiast project.
I disagree. There are thousands of pieces of software out there using convenient technologies at the expense of performance. I think a real, legitimate advantage of unreal over unity is that it uses c++ instead of c# for gameplay code. I’ve never been cpu bound in unreal. Js algorithms often run 100x slower than Java ones, and if gnome were written in rust we wouldn’t have had quite so many memory leaks.
Also, pg credits much of his startups success to his language choice, letting him iterate faster
Language can make a pivotal difference!
Why is this called Rust-based? I’ll do some more research but would like to get some insight from more knowledgeable sources.
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.
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.
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/
[1] https://gtk-rs.org/gtk4-rs/stable/latest/book/gobject_memory...
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.
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.
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.
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.
There's some libraries that effectively automate GTK in this way, such as relm4.
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.
[1]: https://github.com/orgs/pop-os/repositories?q=&type=source&l...
[2]: https://gtk-rs.org/
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?
Wasn't the whole point of the project to emancipate themselves from GNOME? If they rely on GTK they will fail.
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.
Is there a reason iced is not good enough (other than not being accessible)?
but looking good so far, gonna check this out for myself. I was rooting for azul, but iced seems to be further ahead
Anyway although a11y and i18n support have not been implemented, they are planned.
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.
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:
- Rendering multiple layers
- Creating multiple windows
- Multiline text layout and editing
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.
How many serious Gnome/GTK developers are there who are not IBM employees?
>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.
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 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.
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.
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/Pantheon, even "Gnome+extensions" are all in this category to various degrees). I suppose one distinguishing factor that Cosmic has is a strong Wayland focus, which is still missing from nearly all Gtk based alternatives.
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), "we can make trackpads the best they can be" (requires shipping some forked libinput related things IIUC) or "we can make font rendering best we can make it". The actual desktop environment stuff I'd be interested in.
A desktop environment needs more vision than shipping the same old Linux desktop problems with some other apps. I really hope System76 can make an effort there. They're trying to make their paycheck depend more on their own Linux desktop's success, and that I can only encourage.
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...
The only distro that manages to do this OOTB is Ubuntu. I don't know how many patent demons they had to slay but It's second only to Windows 7's rendering.
Everything seems overly rounded, and more importantly, the screenshots even show very weird/inconsistent alignment and padding in the UI.
Why is it that so many Linux GUIs — between apps and desktop environments — suffer from a lack of attention to detail?
Once again, it’s early, I’m sure they are aware of some of these issues, but I can’t say I’m excited for this based on what I just saw.
https://blog.edfloreshz.dev/images/articles/linux/system76/r...
I'm not sure why this desktop UI looks like an iPad either.
I'm not saying this is exclusive to Linux distros, I sometimes find the UI in Windows 10 to be confusing, having to jump between the settings and control panel application to find some niche option. It's apparent that parts of that UI were made 20 years ago while others are made with modern toolkits.
I hope that System 76, being more consumer oriented than other companies that mainly develop for Linux, listens to feedback from a wide range of users and manages to develop an ecosystem to be the "MacOS of Linux workstations" in the sense that everything is polished and working out of the box and everyone from regular home users to advanced professionals and enthusiasts can pick up and use without major inconveniences.
They're rewriting all of that but it's a pain in the neck to do it.
My guess is that they'll finish in 10 years :-))
If you want compatibility worries, check their Windows Terminal blog.
Or Raymond Chen's blog for some real compatibility howlers.
> Why is it that so many Linux GUIs — between apps and desktop environments — suffer from a lack of attention to detail?
The other stuff (like rounding everything) is a deliberate choice.
Instead of complaining, why not contribute to making it better?
What is the alternative, if not for people who notice problems and care about them to step in and contribute?
The software you're looking at hasn't been released yet— at all. Not even an alpha. There are literally no tags on the libcosmic git repo.
You mention that it's early, but I'm not sure you appreciate how early.
It just... Doesn't do anything my custom openbox or i3 setups in the past didn't do (imo better). Nor is it better at being gnome than gnome.
And now that i'm getting old and gotten used to stock gnome it just seems like it makes me change my workflow again for no good reason.
And then cosmic was even worse by changing the behavior of the super key completely.
Both of these things broke my workflow for things i never asked for.
I like pop and their polish compared to ubuntu [0]. I really hate it when software breaks my workflow.
Are you sure you had to break things for them instead of only hijacking it when tiling is enabled?
And that still doesn't address hijacking the super key completely with cosmic.
Sorry but imo these things have been handled really poorly.
I have machines where I run Alpine with sway customized. I have had machines where I've run without a DE at all. I've customized things that weren't meant to be, and not customized things that were.
But if I want something where I can walk up to any somewhat modern machine (currently typing this on an old Alienware running pop), and install an OS that gives me an i3-like environment with no extra work? Pop is fantastic. There are things that I would do differently. But they're minor and being able to just go is worth a lot.
Strikes me as a bit amusing, as this was the case also in early versions of GNOME 3. I believe it was abandoned because non-GNOME apps (or more specifically, ones that didn't follow the GNOME HIG) had a visible distinction and greater consistency was desired. Changing GNOME's own look was the way to do so.
(New dark pattern: popups which have an X box to dismiss them being harder to dismiss. First, the box around the X disappeared. Then, the X moves to different places in the box. (Bing does this for their house ads.) Then, the active portion of the X shrinks to make it harder to hit.)
That pattern did get scaled back. A few GNOME apps still do it, but most only allow it on the title bar now.
Sway has little to no footprint. I have configured my system the way I like it. Now I do minor tweaks sometimes but nothing major. My entire configuration is in a single file! I am not going back to DEs ever.
As for theming, Zukitre for Fluxbox + any modern theme for icons. Done. Fancy, modern yet featureful as back in the day.
I like (and use everyday) sway and I like using WM's as a part of puzzling together a system. I just don't think you are comparing apples to apples here.
Selfishly, as a MacOS refugee and someone who has an on/off relationship with using desktop Linux as my main (and a desire to use it daily); I would love it if there was a shameless clone of the MacOS DE for Linux.
I don't care for customisation, I just want a sensible default that I can get up and running with immediately.
Why's GNOME not good enough for this use case?
I use it about once a week and as far as I can tell, Gnome40+ is giving off signs that I might be able to use it as a daily driver (for work).
Looking forward to the updated Files application and whatever else is coming in G42.
That said, there are a lot of design choices that cater more to mobile form factors and the desktop experience suffers as a result.
Then there are non DE related issues like application installation. Chromium has bizarre window and mouse performance issues related to Wayland. Graphics card drivers are difficult to install, even as someone who knows how to read documentation. Flatpak has a permissions structure that doesn't always make sense for certain applications (like OBS, Discord, IDEs) and installing applications using a package manager is very hit and miss (e.g. OBS is broken in Debian Bookworm when installed via apt because of a qt5 dependency)
I don't mean to sound negative - I only complain because I love Linux and want to be able to go to my friends and colleagues and say "you can use this" - feeling confident that they will have an experience on par with MacOS.
There currently isn't a fix for the scroll being slower than other system windows and there also isn't a fix for issues with dragging tabs.
Middle click doesn't work but I think that's system wide
At all? Applications don't receive middle click events?
Elementary OS
The best experience I have had so far is Gnome41 on Debian Bookworm (my current setup which I log into about once a week) - though the DE has some design choices that cater more to mobile desktop environments at the expense of desktop usability (I don't want to appear ungrateful towards the volunteers developing it, it's a great project and I know critique is easy).
I'm talking about a complete rip off. Things like per-window virtual desktops, screenshot/video recording via hotkey. The global menu. The rock solid stability. Window decorations, spacing, fonts and overall feel. MacOS's DE _feels_ really solid.
That or perhaps join the Elementary OS QA team so that it can have a chance at reaching that really solid _feel_.
This is the essence of the issue.
As someone who started on PCs running Windows and Linux for decades, I moved to MacOS for work because it's a zero config Unix based system with a productive and ergonomic desktop environment. I don't have an inherent bias towards Apple/MacOS and currently no longer use it (though I have an old x86 MacBook I use when not working on my desktop)
It was always an issue that I was not able to use my existing PC to run MacOS due to Apple's restrictive license model and since Apple's move to proprietary hardware (M1), I have abandoned MacOS.
I am actively polling various Linux variations to see if something offers me the same level of productivity but am using Windows+Linux within VBox for my work/engineering requirements in the meantime.
So it's not that I want to keep using MacOS specifically, it's that I need to use a Unix based operating system that has the polish, usability and stability of MacOS.
I respect that the Linux ecosystem is maintained by volunteers and I have as much opportunity as anyone to contribute (and I have been trying to contribute by submitting QA tickets to the Gnome project). That said, I would be more than happy to pay a substantial annual license fee for a Linux experience that rivals that of MacOS.
EDIT:
> All of that should be more or less easy to tweak on Linux
A lot of this functionality simply does not exist on Linux. With multi monitor setups, virtual desktops scroll on both screens. Gnome 4 is the first DE to pseudoreplicate MacOS's model.
Screenshots and screen recordings are close but lack the nuance of MacOS (and Windows) that make them valuable. For instance no DE offers the ability to draw notes on a screenshotted area, copy the modified version to clipboard (rather than save a file). There is also no way that I know where you can create an mp4 video of a selected area of the screen as easily as you can take a screenshot.
This is invaluable for me as I like to send detailed representations of bugs, with screenshots, notes and videos. Really helps when working remotely or contributing to something like Gnome.
The DE included software might not get you there but there’s seems to be plenty of variations you could install. Again it’s not as polished but I’m not super picky about the specifics of how my OS appears to function.
I’m looking to add some niceties myself to KDE soon as apart of an attempt to learn some C++ and/or Rust.
> That said, I would be more than happy to pay a substantial annual license fee for a Linux experience that rivals that of MacOS.
Are you looking for BSD?
Joking aside, you're going to have to be a lot more specific than "rivals" MacOS. There are a lot of cases where MacOS has dug itself into arbitrary, insurmountable leads (eg. nobody is going to add haptics to your touchpad with a software update), but there are also cases where Linux whoops MacOS up and down the block (full WINE functionality, Vulkan drivers, Nvidia compatibility, system-agnostic filesystems, etc.)
> A lot of this functionality simply does not exist on Linux. With multi monitor setups, virtual desktops scroll on both screens. Gnome 4 is the first DE to pseudoreplicate MacOS's model.
This is tacitly untrue, KDE scrolls all monitors by default, and most x11 sessions can be configured to do the same afaik. The only holdouts are esoteric window managers like i3wm, where arbitrary desktop/monitor association is just part of their design paradigm. I'm pretty sure GNOME 3 could be configured to do the same, too (the developers just didn't put the option in the default settings app because they don't trust you, I guess). Not sure where you're getting this impression from, but it sounds like a misunderstanding.
> Screenshots and screen recordings are close but lack the nuance of MacOS (and Windows) that make them valuable. For instance no DE offers the ability to draw notes on a screenshotted area, copy the modified version to clipboard (rather than save a file).
Again, KDE's default screenshot utility ("Spectacle") has robust annotation and saving options. I just let it save the screenshotted areas to my clipboard, and it works fine. It should probably be compatible with your GNOME system too, if you want to try it out.
TL-DR:
Linux is not MacOS, for better and for worse. Most of the features you've listed are indeed configuration options, but nobody really ships a "MacOS clone" distro because it doesn't exist. You can't pay developers to make something like that because there's not a single other organization on earth with 200 billion dollars in liquid cash to spend on decadent UIs and eye candy.
This has been the problem from GNU/Linux desktop for ages, the Look gets cloned, yet the Feel dies along the way.
Red Star OS has you covered
Sarcasm aside, it does look pretty good. But between indistinguishable window title bars and yet another settings app (wanna bet it will miss some config so users wil still need to run one of the others?), I think I'll pass. As far as I'm concerned this problem was solved ages ago, so I simply don't understand why the designers keep mucking with it. Maybe I'm just getting old. :-/
One could argue that because no one desktop environment has taken over the Linux mindshare, we haven't invented the one yet, so people keep trying. It's not until something takes over the mindshare (like systemd did), we can all unity and start improving upon the same base.
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 car manufacturers is paralyzing. Nobody opines that once the perfect car is invented we can just deprecate the rest because those would all be silly positions.
The car market and computer uis are an evolving multidimensional entities whose evolving product lines are and have been dependant upon many parties pulling in different directions.
It's like looking at only a duck and a pond and asking why the universe couldn't have just made a duck because it would be an ideal choice for that place and time. Of course it couldn't possibly work like that because arriving at that exact solution without intermediate steps would be impossible and besides the duck is no good in the desert or tundra.
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.
It is a worst in class solution.
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-further back. Every GNOME contributor you meet will try to deny it, but it really has come to a boiling point over the last few months. There have been so many feature cuts, unaddressed issues, internal hostility and asinine workarounds (text is broken on native apps, so ship with Flatpak until we get it fixed! wait, Flatpak has more issues?) that I really struggle to have any respect for their leadership now. They're throwing out pieces of the plane to get it off the runway, and the complete lack of communication combined with their internal holier-than-thou social ethics has turned a transparent, thriving community of users into a miasma of apologists, skeptics and people who have never tried anything else.
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.
[0] After initially attempting Kinoite, which has some rather unfortunate problems that don't seem to be being addressed.
I'm not talking about cars though, I'm talking about Linux not getting a lot of traction on desktop because of too much choice. The mainstream environments are often not viable for somebody trying to switch. We can ignore it and create a dozen more distros and environments but this pollutes the Linux landscape even further.
A desktop environment isn't that difficult to make, that's why we have so many. Gnome and KDE peaked 10 years ago and they're now stuck in a local maxima, afraid to move outside their comfort zone. A new desktop environment is an opportunity to question assumptions and try to find a better design.
I don't know what else to say. I'm describing the landscape as I see it.
I do disagree that KDE or Gnome are stuck, I thought Gnome 40 was a nice refresh. It's evolved quite a bit from the Gnome 2 of Red Hat Linux that I used as a youngster.
The truth is, most people don't want to install operating systems, even if they're free and easier to install than Windows. The only way to go further is to ship with hardware and for that combination of hardware and software to be in demand. On top of that, when the operating system/desktop environment has reached a decent baseline of general usability like KDE Plasma and GNOME have, the software ecosystem around the OS/DE is more of a limiting factor than the UIs of the OS/DE.
The fact that System 76 sells laptops could actually give their DE a significant advantage over other small DEs if they ship their own DE. It's unlikely to overtake KDE and GNOME since System 76 doesn't sell tons of laptops like Dell or other big hardware companies, but I guess never say never.
I don't expect instant world domination, but I hope the Steam Deck (which will ship KDE Plasma for its desktop mode) will greatly boost the popularity and developer community of KDE. With success, there is a chance at a snowball effect where new users who enjoy the product contribute and bring attention, which brings more new users, etc. All things considered, the share of people using the Steam Deck isn't going to be that big compared to Windows or even MacOS, but it is getting a lot of attention.
One of my friends from the KDE community (which I am also a part of) has written multiple articles about this on his blog. Here's one: https://pointieststick.com/2021/12/09/what-desktop-linux-nee...
> A desktop environment isn't that difficult to make, that's why we have so many.
We actually don't have that many and they actually are pretty difficult to make. Linux has quite a lot of window managers, but not complete desktop environments. The 2 most popular ones require a lot of maintenance. Even GNOME, which has gained a bit of a reputation for dropping features is very large in scope.
A desktop environment is so much more, is a full stack development experience, with development tooling, APIs, and UI/UX workflows that users can be confident they work across most applications unless they go out of their way not to support the native idioms of the desktop environment being used.
Most of those "so many experiments" fail at being half as good GNOME/KDE are at being a full desktop environment as other desktop and mobile platforms are.
Most of these issues are just bugs, not issues with some vision. The gnome people I've talked to want them fixed and want help with fixing them. But I get that it's lot easier to complain on hacker news than it is to fix architectural issues in a large codebase.
Bugs are inevitable but bad design is not.
Unfortunately the problem actually continued for some at least into 2020.
In summary a broken design nearly completely ignored for 7 years and fixed with a band-aid that doesn't actually solve the underlying issue over the next 2 years. 11 years in and the design fail is still with us. I appreciate the fact that many of the contributors aren't paid for their efforts and I applaud their efforts to give to the community but large parts of gnome ought to regarded as learning experiences not something to build the rest of our software on top of.
I hope System76's work will be a better basis especially since their financial success could fund future efforts.
And I'm sure zillions of people would pay in order to have a 3D like shell a la Windows 98, or Windows XP/Net theme for a more modern look.
They don't need to be fast to use, so there's nothing to gain from better speed. They weren't ugly, so a slightly different styling is not a win. They weren't crashing all the time, so reliability is not it.
They don't try to redesign some core desktop experience from the looks of it either.
So... why?
The bigger thing is that GNOME is making it harder and harder to customize and extend, which is a problem for System 76 for obvious reasons.
I don't speak for everyone, but GTK3 is the unofficial "native" toolkit for Linux. QT isn't far behind (I've been using Plasma since GNOME 40 and it's a blast), but GTK3 just feels... right. Also licensing and custom stylesheets yadda yadda yadda.
I do still like certain aspects of GNOME, but I worry for their future under the current leadership.
Does it contain a window manager or is that fully separate? Is it the "explorer", shell, menu, dock, what not? (But didn't that at least in part reside in a window manager)?
Is it libraries that applications that are to be executed under the DE?
If it is using the GNOME libraries (GTK???) ? Will GNOME applications be native?
yes, it does. You can sometimes swap out the default WM for a DE, if you want
> Is it the "explorer", shell, menu, dock, what not?
yes
> (But didn't that at least in part reside in a window manager)?
not really. That's an implementation detail that just varies between different DEs and WMs more than across time. Most DEs don't use the window manager to draw the desktop background, but some do
> Is it libraries [and] applications that are to be executed under the DE?
yeah, at least if they're integrated with the DE or come with it on a given distro
> If it is using the GNOME libraries (GTK???) ? Will GNOME applications be native?
that's up to System76, basically. I think they do want most GNOME apps to be more or less native under their DE
And the same set of applicatins are in general included in each one?
But it's the other way around— the WM is part of the desktop environment. For some desktop environments, you can choose to swap out the default WM of that DE for another. (That's what I meant to say before.)
Desktop environments have applications that are designed to be part of the DE. Typically some core applications, like the file manager, fall into this category. Linux desktop environments are ecosystems, and anyone can write an application that aims to fit into them and be a part of them in as first-class a way as possible. That means leveraging the desktop environment's libraries and adhering to its interface guidelines. Linux distros typically base themselves around such an ecosystem and choose most but not all of the applications in them based on their membership within that ecosystem, as well as their maturity and quality. Sometimes those ecosystems include competing apps in the same category, or apps which could be alternatives with partially overlapping use cases. Linux distros then make a choice.
There are sometimes issues between desktop environments, or inter-compatibility issues that require patching to make everything work. They tend to be very niche, and very universal (expecting all applications to use a common interface or behave the same way). The only desktop environment that reliably achieves comparable features without such an issue is that of macOS (and even then, only if you exclude apps that don't aim to feel ‘native’). The best example I can think of is the menu search functionality of the Unity desktop, which IIRC required custom patching of GTK libraries. That's the worst case: novel features rely on would-be standards that simply aren't in place across desktop environments or display servers or window managers or whatever.
In the best case, for example desktop shortcuts (XDG .desktop files), there are open standards that meet the needs of a wide range of desktop environments, and which all desktop environments and applications understand and meet.
In terms of basic integration though, of the kind you might see on Windows, where VLC looks more or less like Windows Explorer and Firefox looks more or less like Notepad, ‘integration’ is generally a matter of configuration that distros take care of themselves. Apps based on Qt libraries can be made to look right in ecosystems built on GTK and vice-versa. (Most apps can be made to look like GTK apps.)
If your point is to highlight the nuance and complexity of the situation: fine, I get it. What a ‘desktop environment’ is is nuanced and complex, and trying to nail down a philosophically satisfactory definition is technical and complicated.
If, on the other hand, you'd like to develop an intuition for what desktop environments are like:
1. Any given release of Windows has just one desktop environment. macOS has another.
2. Like most things humans have created, the details are tricky but the intuition is simple, and the best way to understand the thing is to play around with it in real life. Find a bookstore that carries Linux magazines, and buy one. (It may be imported and expensive.) It'll come with a DVD that lets you try several different desktop environments. Spend some time with a few, and you will very, very quickly get a clear sense of what a desktop environment is and why the concept is meaningful.
(Searching around, I see a lot of people don't get it, they say that Year of Linux on the Desktop has happened. It hasn't yet and some think it never will.)
I agree a lot of mistakes have been made but I'm not sure Linux developers/community will continue to make big enough mistakes to stop its momentum every time it gains some.
I'm not sure all sabotage it unwittingly. I think there might be some deliberate sabotage in Mozilla which gets funded by Google. A browser is a key component of a Linux desktop. I don't think we should pin our hopes entirely on Firefox, but explore all options.
I have trouble going near CockroachDB because of its name. It's absolutely unjustifiable from an engineering perspective, but the effect (for me, at least) is real.
They should rename to TardigradeDB.
Either way, both using CockroachDB and participating in this thread put cockroaches on my mind a lot more than I'd really prefer. +1 for TardigradeDB.
MongoDB because mongo is a derogartory word in my language. It is an abbreviation of Mongoloid, was (apparently) used to describe people with Down syndrome, thought I've never heard it used for that. It's more colloquially used to describe people who act wierd or something that are stupid or made in a wierd way.
Svelte, the javascript framework is also something I've kind of avoided so far due to its name. While it doesn't really mean anything in my native tongue as far as I know, it is a very plausible word/spelling and it kinda just sounds unappealing. I can't help but reading it like that either.
I don't know who their designer is, but they're the only reason I'm not pumped about all of this.
There is a good reason these color schemes aren't seen elsewhere, ever, in any interface. Hopefully they will fully support theming or even provide a different built in theme.
So far all Cosmic UI has been immune to normal GTK theming.
I like the idea of using Rust for the DE, but personally I'd stick with KDE.
They could limit the scope though. I.e. focus on Linux only from the start at least. But it's probably still a lot of work.
Rendering would be done presumably using some cross-platform GPU API like Vulkan or wgpu.
Cross platform here is not easy, if you want that toolkit not to be ugly and have some kind of native look and feel.
And let's not forget the accessibility systems, clipboard handling, filesystem (e.g. a GUI toolkit needs file open/save dialogs, which means you want to monitor the filesystem for changes, which is different for all operating systems), audio, notification systems, printing, ... And probably many other things I can't think of right now which modern toolkits like Qt or GTK have to deal with.
A full GUI toolkit is already an incredibly ambitious endeavor and cross platform compatibility only makes it much more unrealistic to achieve in a timely manner.
A desktop environment on the other hand can be much less work and can grow more naturally. For example you can start with a window manager/compositor (which there are good libraries for), launcher and dock/panel. All the applications (file manager, image viewer, ...) can be leveraged from other DEs and replaced step by step if needed.
What system76 is doing could be a great opportunity to rethink a desktop for desktop users. And I understand that after so many years, users have come to expect certain things from a desktop and there's less room to innovate without alienating a huge segment of the userbase that doesn't want to relearn how to use their computer. But still it would be great to get a new idea in the space. And I would love to get an alternative to gnome and kde that isn't just a remix of the past desktops.
Take look the screenshot under "The search bar is available everywhere in the app" section, the Navigation button is not aligned with (I assume) the window title.
The Navigation button did in fact aligned with the "Find a setting..." search input box (trust me, I measured it with two different rulers). But... visually it's misaligned still because the bottom borderline of the Navigation button is too blended in with the window background color.
Well, that's ... dare I say... ugly?
GTK.. what a waste of an opportunity
I wish Canonical didn't gave up with Unity 8.. Ubuntu and unity was the reason i was using linux as my main desktop OS, when they announced they'll use Gnome 3, i reinstalled windows.. when windows 10 got announced i moved to macOS, i now back to linux with Mint (i love cinnamon desktop btw)
Gnome and GTK are a curse, they drive people away from linux desktop
My thinking is that such a style guide could help developers, desktop environments and distributions at the same time.
As many mention here the developer of a small app or program is not a UI guru. So if there is a guide to follow why not?
The fact that System 76 can just tweak Gnome, but is choosing not to, points to the deep levels of custom development they want to be able to accomplish. New ideas... now THAT's exciting.
[1] https://www.boia.org/blog/dark-mode-can-improve-text-readabi...
Is this an Americanism? My brain can't read this properly.
I’m not sure if it’s an Americanism as much as poor phrasing :)
Then the "as to", while correct, isn't an obvious construction. It's often paired with "curious" to help transition the sentence a bit, but it's wordy and unnecessary here. For the sake of reading, ignore it.
Then it becomes:
> we're all curious how this desktop will look
The original text is probably written by someone who doesn't do a lot of writing, as it reads how someone might talk. I'm no expert by any means but I'm moderately aware of my own struggle with this exact problem, enough to see it in others' writing.
It's of course aesthetically pleasing but it's technically very ill suited for actual users aside from those without vision impairments.
Also cause GNOME uses by default Wayland. COSMIC uses Xorg..
>The search also displays a list of all the settings that match the search criteria and not only where they’re located as GNOME Settings does, this makes it easier to change your settings without having to leave the section you currently are in.
>the search bar is available at the top of the navigation view, this is problematic when inside nested menus as the user has to go back to the begining to access it, but in COSMIC it’s available everywhere in the app, no matter how deep inside a menu the user is.
https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues...
https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues...
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.
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.
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.
They just make boutique computers computing against the like of Dell/Lenovo when it comes to Linux friendly computers.
How many sales do they do per year to justify this direction
Google has done that with Chromebooks successfully but they focus on the educational market where the folks using them has very little choice in the matter.
I, for one, would love to see someone fork GTK3 for desktop purposes. GTK4's development has almost entirely been predicated by the GNOME team (despite how hard they deny it), and additions like libadwaita has made GTK unusable for many. After Pop_OS! was publically harassed by the GNOME team, I kinda expected them to take that project up. I can settle for a desktop fork all the same though.
> and additions like libadwaita has made GTK unusable for many
Could you expand on that?
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 completely unfinished and unusable in production, inconsistent compositor blocking, etc.)
Plus, relm still doesn't fix the issue of how horrible it is to write GTK code inside a language as restrictive as Rust. With previous versions of gtk-rs you could at least circumvent that by drawing a definitive line between GUI code, builder code, and functional code (what is this, the future?), but now it's all been homogenized into .rs files and endless method calls. What a great development experience! [/s]
> Could you expand on that?
libadwaita has done nothing but further fracture the Linux landscape while pushing the onus onto me, the developer, to re-write the app to look native on other systems. On GTK2 and 3, I could write once, deliver to any platform and have it look as native as any other system utility. It's flexibility is what gave it it's value, since it was mostly just an open-source widget standard that could be used on any system you please. Unfortunately, now that the GNOME team has become the primary development leader of the GTK project, and projects like libadwaita do more harm than good for the desktop userspace as a whole. It provides me basically no value as a developer, and all of the "muh accessibility" and "muh dependability" arguments are total bunk. GTK3 was arguably more accessible since people with vision impairments could activate high-contrast or complimentary stylesheets that enabled them to... actually use the device. Nowadays, my only option is to assimilate into their brown blob UI or get thrown out for being "wrong". Does that seem like Linux to you?
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, it would be easier to understand what you're talking about if you shared some code illustrating what the problem is.
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.
In my experience Qt apps behave much better on Windows and Mac because they're designed to be native first. GTK was never designed to do that, it started out as a clone of Motif and it only ran on Unix, the cross-platform support was added later when some Windows developers wanted to port GIMP to Windows. To me GIMP and Inkscape always had some weird GTK widgets that don't look or act anything like Win32 widgets. I'd say use Qt if you want a better native experience on mac and windows.
>The GNOME team never opened libadwaita for public comment, or held any forums where I could voice concerns with the direction they were headed. I can understand how this all sounds accusatory, but I really do recommend that you research it.
I've researched it. This isn't how open source works, projects are not driven by public comments on forums. They're driven by people showing up to work together on a shared goal. Those who show up and write the code, get to be the decision makers.
>The community has been completely locked out of the GNOME decision-making process.
It doesn't make much sense to say this, the whole point here is the community makes the decisions for itself and nobody else. Every single contributor past the original founders are from the community.
>They won't accept contributions that allow cross-platform stylesheets
>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
I've no idea where you got this. I've never seen any comments from libadwaita developers to suggest that. This doesn't need to be contributed either, if you have a stylesheet you want to work on you can just ship it as part of your app, or create another add-on library for platform extensions similar to this: https://github.com/GNOME/gtk-mac-integration
Regardless of where it ends up, the styles for GIMP on Win32 is just a theme, if that's not available in newer versions then somebody needs to port it to the new theming system. You could wait for a GIMP contributor to do it but that might take a long time.
>It was a really good library until it hit v14, when the developers lobbed off support for Glade files
I might still be misunderstanding, but the break was caused by GTK4. The GTK3 bindings are a separate crate. You can use those until the GTK4 gui designer is released. Breaking glade wasn't done on purpose.
>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
I can't really figure out what you mean for sure but I did some searches. Closure support is still there but it appears to have been moved to another crate called gtk-rs-core.
https://gtk-rs.org/gtk-rs-core/stable/0.14/docs/glib/closure...
https://gtk-rs.org/gtk-rs-core/stable/0.14/docs/glib/macro.c...
Iirc it was all hanging off of a single process sometime back so if a single dock item died basically it hosed your entire desktop. I managed to get it started once or twice, as I was a huge fan of e16 but it just seemed… unusable really.
https://what.thedailywtf.com/topic/15001/enlightened
Definitly a good choice. /s
Enlightenment was a nice window manager back in the mid-1990's, nowadays who cares if it still compiles.
https://www.enlightenment.org/
EFL has been supported by Samsung and Tizen, so I expect a full rewrite soon. They are doing really good changes now.
And lets be honest, who still cares about Tizen in 2022?
Whenever a new tool appears whose existence is justified by being "written in Rust" I cringe a little. I'm a happy Rust user, but I wish people would use the language to make cool stuff, not just spread the language for the sake of the language
It's also still mouse-first, and has not been redesigning itself for touch screens.
Maybe it's just because I don't live in the happy path but I still encounter bugs daily.
What I meant was crashes, freezes, data loss, things just not working type of things are rarer now a days and I personally will much rather take the remaining bugs instead of spending a ton of money and subjecting myself to Apple's whims or Windows advertising.
Another small one: I've set the panel to auto-hide. It works fine for the most part but occasionally it will stay visible until I minimize and restore any window.
> Another small one: I've set the panel to auto-hide. It works fine for the most part but occasionally it will stay visible until I minimize and restore any window.
I've had that as well, but only on X11. I've switched to Wayland some years ago, and never got around to debug that.
I use fluxbox + rox but XFCE would the closest DE to my setup.