COSMIC desktop makes its debut
Linux hardware vendor System76 started promoting
its work on a Rust-based, Wayland
desktop environment for its
The road to COSMIC
System76 sells Linux laptops, desktops, servers, and other hardware. The
company was founded in 2005, and preinstalled Ubuntu as the default
operating system on its offerings for many years. In 2017, the company created
its
The 21.04 release introduced the "COSMIC" name by using it to describe its customizations to GNOME. The name was initially expanded as "Computer Operating System Main Interface Components", but the company seems to have abandoned that unwieldy backronym, which is probably for the best. Changes in 21.04 included the addition of a dock (a fork of the Dash to Dock extension), trackpad gestures, and other various and sundry modifications.
According to the README
for the tiling shell extension, the original plan was to propose
integration of the tiling window management features to GNOME
upstream. It is unclear if that ever happened, but a
recent blog post about building the desktop indicates that
it was unsustainable to maintain COSMIC as an extension, since upstream GNOME
changes could cause the extension to break. The team also
considered forking GNOME, but that would entail "taking on decades
of legacy code and adapting it to fit what we want to build
". That
was ruled out, which left building a custom desktop from the ground up.
COSMIC components
The team working on COSMIC was already familiar with Rust and, according to the blog
post, chose to use it for its "readability, stability, and memory
safety
". The developers chose the iced cross-platform
graphical-user-interface (GUI) library,
and created their own libraries for text handling, animations, and additional Wayland support. COSMIC uses its
own Wayland compositor, which is built on top of the Smithay
project. COSMIC's compositor does have XWayland support, so X
applications should work just fine on the desktop.
The team has also created a cross-platform libcosmic platform
toolkit for applications and applets that is based on iced. According to its documentation,
the goal of libcosmic is to "enable the creation of a
cross-platform ecosystem of applications that are easy to port from
one OS to another
". The docs for libcosmic are a work in progress,
but interested developers will find a number of examples
for creating COSMIC applications in its GitHub repository using the
library, as well as an application
template.
Desktop impressions
Even though COSMIC is no longer based on GNOME, it still takes a lot of visual cues from GNOME. The default applications and system tools seem to share GNOME's "less is more" approach to toolbars and user-interface elements. For example, COSMIC's file manager has just two navigation buttons (forward and backward), the ability to edit the filesystem path, and (of course) lets users click on directories and files to open them. It has only two file views: grid (thumbnails) or a list view that includes the modification date and size of the file. Other file managers like Mate's Caja or KDE's Dolphin offer several view options, a toolbar full of controls, such as "up" or "home" navigation buttons, and allow users to customize the icons/actions that are presented on the toolbar. Currently that is not possible with COSMIC's default applications.
![COSMIC Files application [COSMIC Files application]](https://static.lwn.net/images/2024/cosmic-files-sm.png)
Some of the desktop's minimalism may be due to the fact that some features are just not implemented yet. One would usually expect, for instance, right-clicking the mouse on the desktop would bring up options to change the background or manage display settings. Right now, right-clicking COSMIC's desktop does nothing. It seems unlikely that will be the case by the time the desktop has a stable release. Still, the overall theme seems to be "keep it simple" when it comes to the user interface.
Simple does not mean that the user can't have it their way, though. Like the GNOME-based iteration of COSMIC, the new desktop environment has a top panel and dock that can be customized to suit most users' preferences. Users can resize and reposition both, add or remove applets (such as the date/time widget, or a button to manage tiling), configure them to automatically hide until they are moused over, and even set light/dark mode for those elements independently of the desktop theme. If a user has a multi-monitor setup, the dock and panel can be set to appear on all monitors or a specific monitor. The settings also have a handy "reset to default" option in case customization gets out of hand. Users can choose to simply turn off the panel and/or dock entirely if desired.
COSMIC's tiling mode is the feature that is likely to be most compelling for users. Tiling is completely optional in COSMIC, and it is off by default. Users who do not like a tiling window manager can just ignore the feature and it will not get in the way. For those who do want it, though, COSMIC's implementation is flexible and user-friendly.
If tiling is turned on, it will attempt to automatically arrange windows on the desktop, but it is easy to adjust and override the automatic placements using the keyboard or mouse. In the extension-based tiling implementation, rearranging windows required a shortcut to start the "adjustment mode" and then use shortcuts to rearrange windows. Now, users only have to use the shift-super-arrow shortcut or just use the mouse to rearrange windows. (The "super" key is the one with the Windows logo on most PC keyboards these days.)
Windows can be stacked as well, by dragging one window on top of another and letting go. This creates a tabbed interface at the top of the window for switching between stacked applications. If a new application window is opened while a stack has focus, then the window will be added to the stacked window automatically. Finally, the tiling mode also supports floating windows. Users can click the title bar and select "Float window" or use the super-g shortcut to toggle the float mode for any window. Using super-f for "float" would have been easier to remember, but that shortcut is used to open a new file manager window. It is possible to change that in the keyboard shortcut settings, though.
For an alpha release, the tiling mode seems quite solid. The one complaint that some users might have is that tiling mode does not seem to work well with multi-monitor setups. In testing, tiling mode could only be activated for one monitor. Other than that, it seemed to work perfectly.
Desktop user-experience folks seem unable to resist the temptation to tinker with the behavior of alt-tab. Historically, one could expect that alt-tab would cycle through windows on the desktop. Now that behavior is desktop-dependent. Sometimes alt-tab does what one would expect, sometimes it cycles through applications instead of windows. In the case of COSMIC, though, it does an unexpected third thing: alt-tab brings up a list of up to eight application windows that the user can cycle through. If there are more than eight windows open, they simply are not displayed. Hopefully this convention will evolve to be more usable before the desktop reaches a stable release. Aside from that one grumble, though, COSMIC is already quite usable when it comes to window-management features.
The desktop only ships with two theme options at the moment, for light mode and dark mode. It also has a settings option to switch between modes automatically at sunset. Users can create and install custom themes as well. For example, Reddit user "Bilu47" posted a link to a set of custom themes that they had created.
The new COSMIC App Store seems more stable and responsive than the Pop Shop included 22.04 LTS. I've run 22.04 on one of my laptops for more than a year, and the Shop can be sluggish at times, and unstable too. Despite being an alpha release, the new App Store has been problem-free for installing, removing, and updating software. It can install applications from the Pop!_OS repositories and Flatpaks from Flathub, and it also lets users install updates. The catalog of software displays applications by category (e.g., "Create", "Work", "Develop", and so on), and includes basic descriptions of the applications. It is missing some information compared to the previous iteration, though, such as the application's homepage and license.
COSMIC supports fractional scaling for displays, including fractions less than 100%. This is an interesting feature for users who might want to squeeze a bit more desktop space out of smaller, lower-resolution screens. The options range from 50% to 200%. The 75% option for a 1920x1080 display produced good results while testing the desktop. The 50% option was too small, but that may have more to do with my eyes than the feature. Younger users may find it perfectly usable. Likewise the larger fractional settings worked well, though the desktop does not rearrange windows correctly within the available space. Increasing the display scaling may result in some windows being partially or completely off screen.
COSMIC $thing
In addition to the desktop environment's components, COSMIC comes with its own file manager, terminal application, and text editor. They all follow the naming convention "COSMIC $thing"—COSMIC Text Editor, COSMIC Files, and COSMIC Terminal. All of the applications are usable, but not quite full-featured enough for daily use. They do, however, provide a good showcase of the libcosmic toolkit for creating applications and applets for the desktop.
![COSMIC Terminal application [COSMIC Terminal application]](https://static.lwn.net/images/2024/cosmic-terminal-sm.png)
COSMIC's sample applications only have three top-level menu choices: File, Edit, and View. This means that users may not find things, such as settings, where they would normally expect to find them. COSMIC's homegrown applications also have a somewhat novel way of displaying settings and other secondary pages. Instead of opening a new window or a dialog for settings, etc., applications have a side panel that opens on the right-hand side of the window as seen in the screenshot to the left.
The terminal and text editor applications are fine for light use, but probably will not win over users who already have a favorite editor or terminal application. The file manager would need a few additional features to be suitable for daily use, such as the ability to choose from any installed application to open a file. Right now, selecting "Open with" for a file only displays a list of applications that COSMIC thinks are suitable for the file.
Users can set the color scheme for applications independently of the desktop, so even if the desktop is set to a light theme, one might choose to use the dark theme for the terminal application. This would also be useful when using COSMIC applications with another desktop environment, since they do not inherit their color scheme from GNOME, KDE, or other desktop environments.
Fragmentation
On the topic of running applications on different desktop environments: testing COSMIC as my primary desktop for more than a week really emphasized just how inconsistent the Linux desktop user-interface experience can be. Using Firefox, Claws Mail, Emacs, and other applications alongside native COSMIC applications, GNOME applications, and a few KDE applications, means having a bunch of inconsistent menu types, application title bars, and so forth. Claws Mail, for example, did not inherit the minimize and maximize title bar buttons in COSMIC, nor did Firefox. Some applications use COSMIC's native file dialog when opening files, while Emacs and the Kate text editor use different file choosers. The list of small, but real, incompatibilities is lengthy.
As a person who has been using Linux since the 1990s, I've grown accustomed to this and it is generally nothing more than a mild annoyance, if that. For users new to Linux, which would include much of System76's target audience, it is likely more confusing. This, of course, is not System76's fault or problem to solve alone, but the introduction of yet-another-desktop does exacerbate the fragmentation problem. The company is not wrong in creating COSMIC, by any means, but more unity (pun somewhat intended) on the Linux desktop would be a good thing for appealing to new users. Short of dropping all of the open-source-desktop teams into an arena and making them sort out their differences Highlander style, though, there doesn't seem to be a solution to the fragmentation problem.
Getting COSMIC
ISOs for
The company has been open about wanting to see COSMIC adopted by
other Linux distributions, and the desktop is already packaged for a
number of them. There are instructions for installing COSMIC on Arch, Fedora,
NixOS, or
Serpent OS.
OpenSUSE is listed as "coming soon" on the landing page for COSMIC,
and Redox OS (which LWN covered in June) already includes some COSMIC
components. One note for users who try out the desktop on another
distribution: the packages may be behind those available for
Users should temper their expectations before installing and testing COSMIC. It is reasonably stable for an alpha release, but it does have plenty of minor bugs, usability paper cuts, and enough instability that it's a bad bet for a production system. It has problems waking from the suspend state, as just one example. This is a known problem, so it is likely to be fixed soon, but it is no fun having to restart a laptop every time its lid closed.
A smaller, fixable, issue is that it's necessary to set the system time zone manually using timedatectl or similar:
$ sudo timedatectl set-timezone 'America/Denver'
All of those problems, of course, are to be expected from an alpha-quality
release. Users who would like to test COSMIC and give feedback are
encouraged to join the
Grumbles about desktop fragmentation aside, COSMIC is an ambitious project and shows a lot of promise. It also has a great deal of maturing to do before it will be suitable for daily use, but it has made significant progress in just two years. Watching it evolve, and seeing whether users and developers take to it, should be interesting.
Posted Aug 12, 2024 18:51 UTC (Mon)
by jorgegv (subscriber, #60484)
[Link] (36 responses)
I can't understand the logic of this sentence at all: "...it was unsustainable to maintain COSMIC as an extension, since upstream GNOME changes could cause the extension to break. The team also considered forking GNOME, but that would entail "taking on decades of legacy code and adapting it to fit what we want to build". That was ruled out, which left building a custom desktop from the ground up." So the logic is... "option 1: we can't keep it as an extension because GNOME may break it ("big" work?), so... option 2: we can fork the whole GNOME, but it would take too much work (huge work?!!), so... option 3: let's rebuild a whole new Desktop environment with all its applications! (immense humungous work???!!!!!)" I really don't get it, I must be missing something.
Posted Aug 12, 2024 18:55 UTC (Mon)
by liw (subscriber, #6379)
[Link]
I imagine they thought writing a whole new desktop environment can't be that hard. I've not tried to do that myself, so I can't say if they were wrong.
Posted Aug 12, 2024 19:37 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (13 responses)
It's actually surprising how it's _not_ such a humongous task anymore. The low-level components are already there, and most of the work is in tying them together.
Back in the day, GTK had to implement its own custom object-oriented language (GObject) and a basic library (glib). None of this is needed anymore.
Posted Aug 13, 2024 1:52 UTC (Tue)
by atai (subscriber, #10977)
[Link] (12 responses)
Qt proved that in, what, 1999?
Rust is nothing new in this front.
Posted Aug 13, 2024 2:14 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Aug 13, 2024 3:54 UTC (Tue)
by comex (subscriber, #71521)
[Link] (10 responses)
Oh, and more recently, Qt decided to implement its own scripting language, QML.
Not that newer UI frameworks are immune to this trend of reinventing the world. I don’t know about Iced, but Slint, one of the other Rust-based UI frameworks, also has its own scripting language similar to QML.
Posted Aug 13, 2024 7:54 UTC (Tue)
by hunger (subscriber, #36242)
[Link] (7 responses)
Having a simple language to describe UI has a host of advantages: https://slint.dev/blog/domain-specific-language-vs-impera...
Just look at the web: Do younreally think it would be as successful as it is if you had to actually program pages in rust, C++ or any other "proper" programming language?
Posted Aug 13, 2024 9:58 UTC (Tue)
by anselm (subscriber, #2796)
[Link]
Indeed? We knew that in the early 1990s, with Tcl/Tk.
(Tcl/Tk may not be everyone's cup of tea, but at the time it ran in circles around everything else in that space.)
Posted Aug 15, 2024 10:56 UTC (Thu)
by khim (subscriber, #9252)
[Link]
That question is, essentially, impossible to answer before you would give criteria for “success”. Would it have been successful at attracting bazillion “designer” who created bazillion barely-usable sites? Probably not. Would it have been successful at facilitating the ability of people to communicate? Most likely yes, and even more than web achieves that today.
Posted Aug 15, 2024 13:05 UTC (Thu)
by jengelh (guest, #33263)
[Link] (2 responses)
And here we are, people programming web pages with Javascript (which is "proper" in the sense that it is imperative rather than declaring the UI).
Posted Aug 15, 2024 19:01 UTC (Thu)
by yeltsin (guest, #171611)
[Link] (1 responses)
Posted Aug 19, 2024 5:04 UTC (Mon)
by ssmith32 (subscriber, #72404)
[Link]
React is not a declarative model, even moderately. Maybe slightly if you squint really hard after too many drinks? But it's mostly *not* declarative.
It's very much an imperative language that lets you build components.. similar to how most object-oriented UI frameworks work. If you stretch the definition of declarative enough, maybe? But then GTK would be considered declarative...
But you very much tell it to
Build component A,
Step by step, in an imperative fashion.
Having abstractions and components != declarative.
SQL is probably the closest thing to declarative that most folks are familiar, and it's nothing like building a React app, and is absolutely *atrocious* for building large apps out of. Large SQL queries are usually much less maintainable than code of any sort of a similar size.
Prolog is also much closer to declarative than React. And is also absolutely horrible for large programs.
A declarative language for UIs would let you declare what you want to accomplish, literally, something like: "A UI to let me update the time and timezone on COSMIC"... and then the optimizer goes off and builds that UI.
React, you have to tell it exactly what you want, and, most importantly, how to handle input, step by step. That's imperative.
Posted Aug 15, 2024 16:00 UTC (Thu)
by DanilaBerezin (guest, #168271)
[Link] (1 responses)
Ironically, if you actually do take a look at the *modern* web, you'll find that nearly everyone programs almost the entirety of their web pages in the "proper programming language" called Javascript. The original purpose of the web in providing an internationally accessible repository of documents has been relegated to the dustbin of history. The reality is that the web has been turned into its own application platform by its users. A transformation which was so egregiously abusive of it's original design that Google poured billions of dollars into creating an optimizing javascript engine, and when that proved to be insufficient and still painful, people decided to invent WASM. And now, people do (and in fact quite commonly) write entire web pages in Rust and C++ thanks to WASM.
Posted Aug 22, 2024 10:04 UTC (Thu)
by DOT (subscriber, #58786)
[Link]
Any new desktop GUI library has to do the hard work of making their widgets available to accessibility tooling. On the web, this is much easier: you get most of it for free by using HTML tags, and you can easily improve on it by using ARIA attributes.
Of course, we can imagine whole websites being created as a single canvas element drawn by a WASM binary. That's not very popular though, because the DOM already gives you the primitives you need.
Posted Aug 13, 2024 16:52 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Aug 14, 2024 8:31 UTC (Wed)
by mbunkus (subscriber, #87248)
[Link]
One thing that Qt simply doesn't have is differences in implementation quality. As the STL is only a spec, there are multiple implementations of that spec by multiple vendors (gcc's libstdcpp, clang's libstdc++, Apple clang's libstdc++, Microsoft's, the mingw implementation which is gcc's but adjusted for Windows or something like that, most likely others). Not only do they implement various differing parts of the STL specs, their quality of implementation is also often lacking. Here are two examples:
The standard's std::filesystem::path library is based on Boost's library of the same name, boost::filesystem::path. Paths are a tricky thing. Boost's implementation has had a LOT of years to mature, whereas the STL implementations haven't. One result is that the implementation in mingw doesn't support UNC paths for Windows properly (things such as \\?\C:\Test\Foo.txt). Therefore I cannot implement a simple algorithm such as "look through the directory structure going upwards until you find a directory containing a certain file" properly as certain test functions ("is this path empty?" or "is this the root path?") just don't work with it. The corresponding algorithm works just fine with boost::filesystem::path with exactly the same functions (as in, the STL's spec copied Boost's implementation almost verbatim). It also just works with Qt's path libraries. Of course this has been reported as a bug but hasn't been fixed yet.
Another bug due to different quality in STL implementations is again mingw's, this time with random number generation. For C++ with the STL you're supposed to use something like the following in order to generate random numbers:
std::random_device r;
Unfortunately std::random_device on mingw doesn't see the RNG (which the STL specs allow!). Therefore each run of the program produces the same sequence of numbers. Meaning I cannot use std::random_device in cross-platform compatible code.
And don't get me started on the quality of the regular expression engine in the STL… Pretty much the worst one out there.
For me using Qt's own classes is much more satisfying & much less annoying. It's easier to use, easier to reason about, quicker to implement, produces faster code, more correct code.
Posted Aug 12, 2024 20:05 UTC (Mon)
by zdzichu (subscriber, #17118)
[Link] (6 responses)
Well known pattern - https://www.jwz.org/doc/cadt.html
Posted Aug 15, 2024 1:20 UTC (Thu)
by motk (guest, #51120)
[Link] (5 responses)
Posted Aug 15, 2024 11:04 UTC (Thu)
by khim (subscriber, #9252)
[Link]
How exactly is that “glib and irrlevant”? Now in addition to about half-dozen existing desktops that are half-done and understaffed we have got yet another one which is even more rough and unpolished and which would be even more understaffed unless they would convince some other group to abandon what they are doing. Which is highly unlikely to happen.
Posted Aug 19, 2024 15:03 UTC (Mon)
by wazoox (subscriber, #69624)
[Link] (3 responses)
https://www.joelonsoftware.com/2000/04/06/things-you-shou...
> There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:
Posted Aug 19, 2024 16:58 UTC (Mon)
by excors (subscriber, #95769)
[Link] (2 responses)
In short, he says writing code is really hard, which is the exact opposite of the "fundamental law" he just proposed.
He also says rewriting code from scratch is the single worst strategic mistake you can make - and then in the very next paragraph he says Microsoft tried to rewrite Word from scratch, but it explicitly was not a strategic mistake because they kept developing the old version in parallel. Really he should say the strategic mistake is "don't completely stop developing your publicly-available product for three years in a rapidly-advancing competitive market" (which seems rather obvious).
Also his specific example is the rewrite of Netscape. If I'm not getting the versions mixed up, the original Netscape was developed from 1994 to about 1997, by which point "The consensus seems to be that the old Netscape code base was _really_ bad" (according to Spolsky). The rewrite that he's complaining about became Firefox, which achieved substantial market share and has remained technically competitive for two decades, with huge advances in standards compliance and features and performance and security etc. Could they have had that long-term success if they'd stuck with the Netscape 4 codebase and hadn't taken the short-term hit of paying off technical debt? Obviously it didn't work out for Netscape as a company, but the software looks like a success story.
(To be clear, I'm not saying rewriting software is always (or often) a good idea. But Spolsky phrased it in absolute terms as "Things You Should Never Do" with no nuance, which I think is simply wrong, and his arguments contradict his claims.)
Posted Aug 19, 2024 17:02 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Firefox was not a total rewrite, it was more of a refactor where they extracted only the browser-specific parts from the Netscape suite.
Posted Aug 19, 2024 18:46 UTC (Mon)
by excors (subscriber, #95769)
[Link]
I meant specifically that the Mozilla Application Suite, which was the basis of Netscape 6 (when Spolsky wrote the article) and which Firefox was later extracted from, is the project that chose (in 1998) to do the rewrite he's referring to.
In particular the Gecko layout engine was new, which "constituted an almost-total rewrite of the browser ... Now we had to rewrite the entire user interface from scratch before anyone could even browse the web, or add a bookmark" (https://www.jwz.org/gruntle/nomo.html), so Firefox is directly derived from that completely rewritten browser.
Posted Aug 12, 2024 20:17 UTC (Mon)
by atnot (subscriber, #124910)
[Link]
Interfacing with a community, trying to convince people who aren't on your payroll to let you do the thing that's on your roadmap, compromising on designs made by someone else, telling the manager above you that upstream has rejected their bright idea. That stuff is hard, really hard.
Explaining to your boss why your team spent a month refactoring some old system and couldn't get to CEO's pet priority and convincing them you're still doing a good job despite that is only a little bit easier (after all, controlling the flow of bad information up the chain is a primary function of management anyway)
But building a brand new thing from scratch, now that's easy! You just lay back and let your workers build things that have been built 1000 times and implement solutions to solved problems and every week you just report all of the fancy new things the team has done. The workers will love it too, it's fun and they get to put it on their CV. It'll look good on yours too. Everyone's happy! Is it a good idea? No idea, but you'll probably dip just after it gets released anyway.
And I'm happy because they invest money that could have gone to seasteading, dark market drugs, rifle collections or whatever the system76 folks are up to now into the rust gui ecosystem, which I get to use :)
Posted Aug 12, 2024 20:40 UTC (Mon)
by dilinger (subscriber, #2867)
[Link] (7 responses)
Forking GNOME is what the Cinnamon authors chose to do. It works okay (certainly better than extensions), but there's still lots of rough spots in any version that you're going to fork. You inherit those bugs and design issues, and you either fix them manually as your code base diverges more and more from upstream, or you do a massive rebase to sync up your code with upstream. Cinnamon recently did that, syncing their fork of mutter (called muffin) after a decade or so, and it looked rather painful. And that's just one desktop component; more recently now dealing with headaches around theming and libadwaita as various GNOME apps moved to gtk4. It's a different kind of treadmill than the extensions one, but it's still a treadmill.
Then there's the route that COSMIC took, which is _also_ a lot of work, but allows them to bypass design decisions that they don't like. If you're frustrated with an ancient C code base, an embedded javascript engine, and various other designs that are a core part of GNOME.. then COSMIC's seems like the route to go. And honestly, as a frustrated sometimes-gnome/sometimes-cinnamon user, I'm pretty excited to see what they come up with.
Posted Aug 12, 2024 20:52 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (6 responses)
Isn't this called the "second system effect"? Where you look at all the (wrong?) design decisions the original designers took, and rewrite it to avoid them? Then after a few years or so, another bunch of people look at all the (wrong?) decisions you took, and rewrite it again?
That's why I like Multi-Value - I used a "second system" which based a nice clean design on all the good (and bad) decisions of the original designers. And it did its best to stick with the clean design, bodging a load of corner cases to actually work, but always sticking to the clean basic design as best it could keep theory in line with reality.
It's hard to do that, but it makes for a damn good system. The trouble with Gnome, and KDE, and a lot of these systems is if you don't have - and stick to!!! - that clean core, you eventually end up with a system that is more string and sealing wax and sticking plaster than anything else.
Cheers,
Posted Aug 12, 2024 22:44 UTC (Mon)
by dilinger (subscriber, #2867)
[Link] (5 responses)
I think generally rewrites are frowned upon where you have a system that is efficient and works (but is considered "ugly" or "unmaintainable"). Considering the number of people who are unhappy with GNOME's UI and features (just based on the number of forks, extensions to change the UX, and the existence of stuff like Mate), I don't think it really works for a huge number of people. That includes me and my wife, for different reasons, despite trying our best.
Posted Aug 13, 2024 7:21 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (4 responses)
This is usually called "legacy" - aka "nobody's keeping this up to date (but nobody asks whether it NEEDS keeping up to date or is feature complete)".
> Considering the number of people who are unhappy with GNOME's UI and features (just based on the number of forks, extensions to change the UX, and the existence of stuff like Mate), I don't think it really works for a huge number of people.
I just don't get on with Gnome. Different people think different ways (I also don't get on with WYSIWYG especially Microsoft's vision, that everyone else has blindly copied), and I just want a UI that "just works" and doesn't NEED changing every five minutes!
KDE, WordPerfect, Multi-Value, they just *click* for me and the cognitive load of making them do what *I* want is just so much lower ... this is where the modern "winner takes all" is so damaging, because usually the winner is not the truly most popular, it's the one with the most money that can buy-out / bankrupt the opposition.
Or, as with Open Source, that one that can get the most early-adopter mindshare in the academic "who cares if it's ivory tower" world, and not what actually works in the real world ...
Cheers,
Posted Aug 13, 2024 8:54 UTC (Tue)
by patrick_g (subscriber, #44470)
[Link] (3 responses)
XFCE is the answer.
Posted Aug 13, 2024 9:16 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
(I did try that in the KDE4 days, when my main desktop boot-time was "more than 36 hours from login prompt to usable desktop" ...)
Cheers,
Posted Aug 13, 2024 10:02 UTC (Tue)
by paulj (subscriber, #341)
[Link] (1 responses)
Splitter!
Posted Aug 13, 2024 12:10 UTC (Tue)
by rrolls (subscriber, #151126)
[Link]
Posted Aug 13, 2024 19:31 UTC (Tue)
by Heretic_Blacksheep (guest, #169992)
[Link] (2 responses)
I can see System76's side, and I can understand Gnome's side in not wanting to be tied down. But as a user, I don't like having my workspace disrupted by arbitrary changes that may not benefit me, either. Gnome has a historical track record of doing this very thing (and whataboutisms doesn't change the fact that it occurs and has very recently). Gnome fans may not care, but a lot of people use Gnome simply because it's the default on their distribution. For these people those changes are unnecessary pain points.
I have other beefs with Pop_OS in other areas, but I can certainly understand why they're building a UI stack they control.
Posted Aug 14, 2024 19:26 UTC (Wed)
by Agrippa (subscriber, #170417)
[Link] (1 responses)
(1) The last major user-interface change for users in Gnome occurred with 3.0. That change was controversial, for sure. But Gnome 3 was released in 2011–13 years ago. So, from a user’s perspective, Gnome is not making major interface changes all that often. Mate and Cinnamon originate from the old change.
(2) Also controversial and more frequent are the changes to the JavaScript code that runs Gnome shell and can affect extensions. Changing the base code happens; this is not unusual or “arbitrary,” necessarily. The choice was to allow extensions full power to change the desktop in all sorts of ways, but any changes to the base code can affect the extensions, which are essentially hot patches. The alternative was to present API stable extension libraries to allow extension authors to change the desktop in more future-proof, but limited, ways. My understanding is that the community, including the extension authors, greatly preferred the first approach—which is what Gnome does. The downside , of course, is that extensions might break from release to release. The Gnome folks try to mitigate this problem by releasing an extension-port guide with new releases.
So, I would dispute that Gnome has a history of making frequent “arbitrary changes.” That said, System76 is free to go its own way and reinvent the desktop in a way that is under the company’s control. The upside is that the company is not beholden to the Gnome community or legacy code—it’s a fresh start. The downside is that starting mostly from scratch is very difficult. If System76 can pull it off, kudos to it.
Posted Aug 22, 2024 21:19 UTC (Thu)
by mwilck (subscriber, #1966)
[Link]
Was this done out of kindness for extension authors? I doubt it. I believe the reason was that plain GNOME was a pain, and extensions came to the rescue. If there'd been no extensions, or if the set of things that extensions could do had been severely limited, GNOME 3 would have been much less of a success.
> My understanding is that the community, including the extension authors, greatly preferred the first approach—which is what Gnome does.
Did extension writers actually have a say in this discussion? Well, a few of them, who were around 13y ago, perhaps. Many of which have probably given up by now. I wonder if you've been trying to maintain any GNOME extensions through the last decade. I did, and still do, and I can tell that it's no fun.
Posted Aug 16, 2024 15:06 UTC (Fri)
by bbbush (subscriber, #17456)
[Link]
Posted Aug 19, 2024 4:45 UTC (Mon)
by ssmith32 (subscriber, #72404)
[Link]
It was that building on an unstable base meant that they'd be faced with:
a) breaking their desktop
And re-writing from scratch is can certainly be easier than maintaining a fork. Particularly if upstream has no reason to not maintain something(s) your patches depend on, leaving you back to the dilemma of Option #1.
Some of the hardest things I've had to work on involve large, undocumented legacy codebases. And I've helped build systems from scratch more complex than those legacy codebases.
Posted Aug 13, 2024 5:49 UTC (Tue)
by tzafrir (subscriber, #11501)
[Link] (6 responses)
Posted Aug 13, 2024 8:02 UTC (Tue)
by hunger (subscriber, #36242)
[Link] (5 responses)
You get self-contained binaries that are statically linked one way or the other.
Posted Aug 13, 2024 9:27 UTC (Tue)
by tzafrir (subscriber, #11501)
[Link] (4 responses)
Posted Aug 13, 2024 10:24 UTC (Tue)
by hunger (subscriber, #36242)
[Link] (3 responses)
In the end cargo will download the same SHA from crates.io... either on your system, on the system of somebody vendoring all dependencies into one tarball to ship as part of the package build sources of cosmic-randr or as part of a package for each of the dependencies when those are packaged by the distribution
In all cases the same code will end up in one self-contained, statically linked binary. The user of that binary will not need any of the sources of the dependencies. It really does not matter whether those are packaged or not.
I really see no point whatsoever to package any library crate... they are just source code, nothing more. You do not insist on someone packaging header-only libraries in C or C++ either, do you?
Posted Aug 13, 2024 10:50 UTC (Tue)
by mbukatov (subscriber, #96216)
[Link]
Why not? Fedora does that: https://docs.fedoraproject.org/en-US/packaging-guidelines...
Posted Aug 13, 2024 12:40 UTC (Tue)
by tzafrir (subscriber, #11501)
[Link] (1 responses)
A quick search in Debian shows many librust-$foo-dev packages.
Posted Aug 13, 2024 15:51 UTC (Tue)
by hunger (subscriber, #36242)
[Link]
Posted Aug 13, 2024 12:49 UTC (Tue)
by daenzer (subscriber, #7050)
[Link] (3 responses)
Doesn't Windows have a similarly fragmented user experience? (Not saying it's a good thing per se, just that it might not be that confusing for most Linux newcomers)
Posted Aug 13, 2024 14:25 UTC (Tue)
by jzb (editor, #7867)
[Link] (2 responses)
I don't think so, in general, but I would also admit I have a lot less current experience with Windows. As I understand it, things like title bar buttons (close, minimize, maximize) are pretty uniform for Windows apps even when running older programs. But it's possible my understanding is a bit flawed—I had Windows on a work laptop for about six months in 2022, and time may have blurred things a bit and/or my use might not have matched other peoples' experiences.
Posted Aug 13, 2024 17:33 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Aug 13, 2024 17:45 UTC (Tue)
by pizza (subscriber, #46)
[Link]
Historically, Microsoft has been the worst offender in that respect.
(Not unlike how Apple routinely violates its own UI guidelines. The same guidelines they doggedly require everyone else to follow)
Posted Aug 13, 2024 15:57 UTC (Tue)
by smurf (subscriber, #17840)
[Link] (1 responses)
Well, no. They could have chosen some suitable wlroots-based compositor and added their configuration on top of that.
Posted Aug 14, 2024 10:40 UTC (Wed)
by rsidd (subscriber, #2582)
[Link]
They started with smithay which is like wlroots for rust. And their efforts should enable a large rust ecosystem on wayland.
Posted Aug 14, 2024 18:08 UTC (Wed)
by Nikratio (subscriber, #71966)
[Link] (7 responses)
For as long as I can remember, the X server had a concept of the monitor's dpi, and font sizes could be specified in inches rather than pixels. I distinctly remember entering my exact monitor dimensions into the XFree86 config file, so that xrandr would show the physically correct DPI, and ghostscript would render a PDF of an A4 page in such a way that I could put an physical A4 page on my monitor and they would perfectly overlap.
Yet, nowadays showing everything twice as big was a major accomplishment that unlocked the use of 4K displays, and fractional scaling (as it was available in the 90's) has seemingly become a northstar goal that we're unlikely to ever reach completely.
Excluding the case of using multiple monitors with different resolutions for now, does someone know where we went wrong? What design decisions locked us into the mess that we now can't get rid of?
Posted Aug 14, 2024 18:15 UTC (Wed)
by intelfx (subscriber, #130118)
[Link] (3 responses)
Well, if you exclude the actual hard problems, the rest is very easy indeed.
Posted Aug 14, 2024 19:02 UTC (Wed)
by Nikratio (subscriber, #71966)
[Link] (2 responses)
Would you mind to elaborate? I'm really asking for my education, not to imply that anyone working on this back then or today isn't doing the best that's possible.
Posted Aug 15, 2024 7:25 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
> Would you mind to elaborate?
Well. Did you ever try to place two monitors with disparate (and possibly fractional) resolutions next to each other and have a window seamlessly stretch from one screen to the other?
Using X that's basically impossible. There simply is no way to shoehorn the ability to do this into X11. Each window is backed by a single bitmap with a predetermined resolution, period end of discussion.
With Wayland it's a no-brainer. It. Just. Works.
The flip side is that Wayland has to re-implement some of the *other* features that were a no-brainer under X. Different display paradigms and all that. A lot of work went into X over its lifetime and you can't replicate all of it instantly.
Not to mention: on top of that, somebody needs to write the code to support the new cool stuff that's now possible. Just one example: Say you temporarily need to add another screen to your computer but you don't have a free display output? Fine, let's dynamically add a headless display to the running compositor and show it on your laptop using VNC. Done.
Granted, writing code for new cool stuff is a lot more sexy than writing code for all the old boring usecases that we still need and like to keep working, and granted we could do without the Gnome vs. KDE vs. wlroots nonsense that accumulated during the transition. But we're getting there IMHO.
Posted Aug 15, 2024 18:03 UTC (Thu)
by atnot (subscriber, #124910)
[Link]
Oh, there's an unbelievable list of problems once you start even thinking about doing it properly. The sibling comment goes into some of the compositor problems, but it's just the tip of the iceberg.
So here's some things to just think about:
Many of these can be solved if you're willing to dedicate most of a lifetime to them, for sure. But they're not the kind of problems you can just solve once and for all with a good design. It takes a lot of work to get a good coverage of most of the edge cases and a lot of tuning and heuristics at all levels of the stack that must play well together and nobody notices, until they're wrong.
There are also some bonus unsolveable problems though:
Have fun :)
Posted Aug 14, 2024 21:06 UTC (Wed)
by pizza (subscriber, #46)
[Link]
The problem can be summed up with this question: Is the intent for "high resolution" to "fit more stuff on screen" or "fit the same stuff, only crisper"?
In the past, it was nearly always the former, but now it's increasingly the latter.
Those two intents require very different approaches to how you go about things, and which applies depends on both the application and the user preferences.
Meanwhile. Do all elements of your application have awareness of the pixels-per-inch resolution of the screen? Which ones are handled by the application, and which are provided by external toolkits? Which should be rendered at a higher resolution and which ones should be linearly scaled? Is your application layout specified with pixel-based positioning, or something else? Etc etc.
(BTW, from what I recall, back in the "good old X days" all sorts of stuff went quite wonky if you told X that you were not using the default of 96dpi. Because the _font_ dpi wasn't the same as the _server_ dpi. So no, this wasn't ever a properly solved problem)
Posted Aug 15, 2024 9:24 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
Even the case of two monitors with the same resolution and different sizes is non-trivial to get right. In a perfect world, you want windows to maintain their apparent size as they move from screen to screen, and for the top and bottom to line up as the window moves across monitors. But that has two big problems to get right:
The simple solution is to have a virtual screen setup where the application renders to a pixmap sized such that its pixel density is an integer factor of all output's pixel densities; you can then trivially scale down subsets of the pixmap to fit the real screens. This is, however, exceptionally computationally intensive in many cases - you can (for example) find yourself needing to scale down by 11 for one output, and 13 for the other, and a good-quality downscale filter is approximating a sinc response which means that it needs to read all pixels of the pixmap for every output. Worse, if you're doing this to fit the X11 model, you have to do it for all windows, even ones that don't move across screens.
The medium difficulty solution is to determine a scale factor that's empirically good enough, and a scaling algorithm like Lanczos resampling that's computationally less intensive, but still produces decent results. This is the best you can do in the X11 protocol, but it's still computationally intensive, because you're always scaling down the pixmap the application produces. Again, though, you have to do this for all windows, even ones that don't move across screens, in the X11 model.
The hard approach, and the one Wayland takes, is to determine the scale factor as the window moves; when a window is on a single output, you render at the correct scale factor for that output alone, and the compositor can just blit your output pixmap to the display (or use hardware overlays). When it's across two outputs, you fall back to the medium difficulty solution. The rendering application knows the scale factor from output pixel to real world units, and can tell the compositor how to scale window pixmap pixels to output pixels (which means that you can let the compositor work out how to scale your 1280x720 pixmap from video decoding to the 1600x900 window the user's given you).
The close to perfect approach, which Wayland could adopt in the future, is to ask windows spread across two outputs to render twice, with a region given to tell the window where to render for each scale factor. This then gives you the potential for minimum rendering and perfect appearance as a window moves across outputs, at the expense of more complexity, and applications having to work out how to minimize their rendering (a trivial implementation renders the whole window twice with a scissor set up to remove the unwanted bit, but that's problematic because it results in wasted effort setting up to render (e.g.) parts of the PDF that are off-screen, only for the resulting rasterization to be discarded by the scissor.
Posted Aug 20, 2024 1:14 UTC (Tue)
by AdamW (subscriber, #48457)
[Link]
I can't understand the logic for this
In memory of a programmer. v0.3.
on grass, beneath an old tree,
lies a tombstone, fallen,
covered by moss and leaf,
a name, two dates, five words,
a summary of a life of grief:
"how hard can it be?"
I can't understand the logic for this
I can't understand the logic for this
I can't understand the logic for this
I can't understand the logic for this
I can't understand the logic for this
I can't understand the logic for this
Having a simple language to describe UI has a host of advantages
> Just look at the web: Do younreally think it would be as successful as it is if you had to actually program pages in rust, C++ or any other "proper" programming language?
I can't understand the logic for this
I can't understand the logic for this
>
>Just look at the web: Do younreally think it would be as successful as it is if you had to actually program pages in rust, C++ or any other "proper" programming language?
I can't understand the logic for this
I can't understand the logic for this
then connect it to component B,
when you get signal X, then update Y, etc.
I can't understand the logic for this
I can't understand the logic for this
I can't understand the logic for this
I can't understand the logic for this
std::default_random_engine e1(r());
std::uniform_int_distribution<int> uniform_dist(1, 6);
I can't understand the logic for this
I can't understand the logic for this
I can't understand the logic for this
I can't understand the logic for this
>
> It’s harder to read code than to write it.
>
> This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it’s easier and more fun than figuring out how the old function works.
I can't understand the logic for this
I can't understand the logic for this
I can't understand the logic for this
I can't understand the logic for this
I can't understand the logic for this
I can't understand the logic for this
Wol
I can't understand the logic for this
I can't understand the logic for this
Wol
I can't understand the logic for this
I can't understand the logic for this
Wol
I can't understand the logic for this
I can't understand the logic for this
I can't understand the logic for this
I can't understand the logic for this
I can't understand the logic for this
I can't understand the logic for this
I can't understand the logic for this
b) holding back an update of GNOME, until they can migrate... which with GNOME, may essentially involve a complete rewrite.
stable rust
stable rust
stable rust
stable rust
stable rust
stable rust
stable rust
Fragmentation
Fragmentation
Fragmentation
Fragmentation
False dichotomies, anyone?
False dichotomies, anyone?
Display Scaling
Display Scaling
Display Scaling
>
> Well, if you exclude the actual hard problems, the rest is very easy indeed.
Display Scaling
Display Scaling
- Window moves from one display to another
- User has a window span multiple resolutions
- Two monitors of the same resolution, but different sizes
- Two monitors of the same size, but different resolutions
- The larger monitor is actually lower resolution.
- You drag a window from one monitor to another. Where does it appear and what size will it be. The obvious answer is physical size, right. But...
- ...it's a projector, TV or something else comparatively huge. What happens if you drag windows between them.
- Laptop gets suspended, gets plugged into a dock attached to a display, and wakes up with the lid shut i.e. primary display suddenly changes resolution. Where do the windows go now and how big should they be.
- Applications often clamp line widths to be exactly 1 pixel (and align them to pixels) to prevent weird rendering of thin lines and varying brightness caused by antialiasing. What do you do if there's two resolutions.
- The user has used the preferences to specify exactly how thick the lines should be and will be annoyed if it's ever wrong.
- Subpixel Rendering. Just everything to do with it.
- Respecting the system text size preferences well across applications, OSes and Toolkits.
- What you do and don't scale with the text size.
- The application might want to use different layouts and scaling depending on how much screen estate is available.
- You want to remember the size and position of windows across restarts, but the resolution has changed.
- Multi-window apps having to do all of the above at the same time across multiple monitors.
- One monitor gets unplugged or goes into standby. You better remember where and what size those used to be when it comes back. But those windows must also remain visible on the workspace. Bonus: What if the user moved the window in between. What if it's a different monitor. Do you pop up their sensitive browser window they forgot about on the office projector when it gets plugged in, because that's where they had it at home?
- Games, especially simulators, that want to work across multiple displays
- VR, just in general
- You want to implement the power saving feature that many phones have where they dynamically change the screen's render resolution (and hence dpi) depending on battery saving settings and the content of the display. But everything should stay where it is. This can not break any of the solutions to previously mentioned problems.
- Let's not forget various accessibility features like magnified views (they better not be pixelated, and it better not have to render the entire window at 32k to do it), people who need extra large text, people who need big buttons but want small text, etc.
- Users generally want the contents of their displays to be big enough that every element has enough pixels, as small as possible to maximize screen space, but big enough physically to still be readable. What points those are depends on the person, their eyesight, device size, form factor, environment, etc.
- Applications all have their own, varying ways of adapting to various DPIs which were built to work exactly with the behavior that the developers assumed at the time and there's not really any way for compositor to figure out what those assumptions are.
- The perceived size changes depending on your distance to the object.
Display Scaling
Display Scaling and multiple monitors
Excluding the case of using multiple monitors with different resolutions for now
Display Scaling