|
|
Subscribe / Log in / New account

COSMIC desktop makes its debut

By Joe Brockmeier
August 12, 2024

Linux hardware vendor System76 started promoting its work on a Rust-based, Wayland desktop environment for its Pop!_OS Ubuntu-derivative distribution almost two years ago. On August 8, the company released an alpha version of the COSMIC desktop environment for users to test out. While it has rough edges and missing features, it is stable enough to get a good feel for what the finished product has in store—and the initial results are promising.

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 Pop!_OS distribution after Canonical discontinued its work on the Unity desktop. Pop!_OS started out using GNOME with just a few tweaks, but over the years the distribution has diverged farther and farther from stock GNOME. In 2018, with the Pop!_OS 18.10 release, the company added its own software "store" called the Pop Shop. The 20.04 LTS release introduced tiling features to the desktop with a GNOME extension called Pop!_OS Shell.

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]

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.

[COSMIC Desktop]

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'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 Pop!_OS 24.04 LTS alpha are available in two flavors: one for systems with NVIDIA graphics chipsets (which includes the proprietary NVIDIA drivers), and one for systems with Intel or AMD graphics. If the system has hybrid graphics with Intel/NVIDIA, choose the NVIDIA ISO. There is a Raspberry Pi version of Pop!_OS for the current stable release, but so far there is no alpha ISO for Raspberry Pi.

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 Pop!_OS.

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 Pop!_OS Mattermost server. Note that this requires setting up an account on the server.

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.



to post comments

I can't understand the logic for this

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.

In memory of a programmer. v0.3.

Posted Aug 12, 2024 18:55 UTC (Mon) by liw (subscriber, #6379) [Link]

In a corner of the cemetery,
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 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.

I can't understand the logic for this

Posted Aug 12, 2024 19:37 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (13 responses)

> let's rebuild a whole new Desktop environment with all its applications! (immense humungous work???!!!!!)"

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.

I can't understand the logic for this

Posted Aug 13, 2024 1:52 UTC (Tue) by atai (subscriber, #10977) [Link] (12 responses)

>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.

Qt proved that in, what, 1999?

Rust is nothing new in this front.

I can't understand the logic for this

Posted Aug 13, 2024 2:14 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Sure. And the list of "you don't need this anymore" has grown quite a bit: no need to handle rendering and compositing, no need to handle input on your own, font handling, etc. There are libraries ready for all these purposes.

I can't understand the logic for this

Posted Aug 13, 2024 3:54 UTC (Tue) by comex (subscriber, #71521) [Link] (10 responses)

Qt implemented its own language extensions (moc) and standard library (QtCore has its own string, vector, etc. types separate from the STL ones). I don’t know whether it *had* to do that, but it probably made more sense at the time than it does with modern C++ implementations.

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.

I can't understand the logic for this

Posted Aug 13, 2024 7:54 UTC (Tue) by hunger (subscriber, #36242) [Link] (7 responses)

Yes, slint has its own language, but it is a UI description language, not a scripting language.

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?

I can't understand the logic for this

Posted Aug 13, 2024 9:58 UTC (Tue) by anselm (subscriber, #2796) [Link]

Having a simple language to describe UI has a host of advantages

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.)

I can't understand the logic for this

Posted Aug 15, 2024 10:56 UTC (Thu) by khim (subscriber, #9252) [Link]

> 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?

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.

I can't understand the logic for this

Posted Aug 15, 2024 13:05 UTC (Thu) by jengelh (guest, #33263) [Link] (2 responses)

>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?

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).

I can't understand the logic for this

Posted Aug 15, 2024 19:01 UTC (Thu) by yeltsin (guest, #171611) [Link] (1 responses)

And then, on top of said imperative foundation, people invent and widely use libraries/frameworks like React that provide a (not purely) declarative model for describing the user interface (or more precisely, for deriving the user interface from the underlying data). Because the imperative model is so difficult to work with in large applications. We've come full circle.

I can't understand the logic for this

Posted Aug 19, 2024 5:04 UTC (Mon) by ssmith32 (subscriber, #72404) [Link]

I know you said not "purely".. but..

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,
then connect it to component B,
when you get signal X, then update Y, etc.

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.

I can't understand the logic for this

Posted Aug 15, 2024 16:00 UTC (Thu) by DanilaBerezin (guest, #168271) [Link] (1 responses)

> 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?

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.

I can't understand the logic for this

Posted Aug 22, 2024 10:04 UTC (Thu) by DOT (subscriber, #58786) [Link]

It's not all that bad, really. Yes, scripting support is mandatory for the proper viewing of web pages, but there is still the DOM lingua franca of basic display primitives, which does give tremendous accessibility benefits over a black-box OpenGL surface rendered at 60 FPS.

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.

I can't understand the logic for this

Posted Aug 13, 2024 16:52 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

Qt predates the STL's release, so it made its own containers. In the process, it made decisions that the STL did not go with including CoW support for its containers. Now with move semantics that is less useful (e.g., forgetting a `const&` on a `std::vector<std::string>` parameter was very costly before moves were a thing), but by then there was 15+ years of existing API patterns laid down and at that point it's just easier to add move constructors to the existing APIs than to uproot it all and go with the STL instead.

I can't understand the logic for this

Posted Aug 14, 2024 8:31 UTC (Wed) by mbunkus (subscriber, #87248) [Link]

From a practical point of view: Qt's philosophy is different that STL's wrt. usability. If it makes usage easier, Qt is very eager to add utility functions to its classes, be it strings, containers or date/time types. The C++ standards committee on the other hand prefers users us the generic STL algorithms for anything they can be used. In reality this means that things are often a lot easier to remember, type, research, read & understand than equivalent STL-based code.

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;
std::default_random_engine e1(r());
std::uniform_int_distribution<int> uniform_dist(1, 6);

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.

I can't understand the logic for this

Posted Aug 12, 2024 20:05 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (6 responses)

Difficulty of maintaining legacy code was deemed higher than rewriting clean code from scratch.

Well known pattern - https://www.jwz.org/doc/cadt.html

I can't understand the logic for this

Posted Aug 15, 2024 1:20 UTC (Thu) by motk (guest, #51120) [Link] (5 responses)

Can we please stop quoting this? It's glib and irrlevant.

I can't understand the logic for this

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.

I can't understand the logic for this

Posted Aug 19, 2024 15:03 UTC (Mon) by wazoox (subscriber, #69624) [Link] (3 responses)

If you prefer a more sophisticated take on this (but just as old as jwz's one):

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:
>
> 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

Posted Aug 19, 2024 16:58 UTC (Mon) by excors (subscriber, #95769) [Link] (2 responses)

I'm not sure that's a particularly convincing article. He says it's harder to read code than to write it - but then he goes on to say the old code has had years of testing and bug fixing. He's arguing it was surprisingly hard to write, and it'll be just as hard to write a new version that's just as good, so it's always better to refactor the old version than to throw it away. People mistakenly embark on a rewrite because they can easily read the old code and recognise that it's a mess (and they're often correct it's a mess, as with the architectural problems he mentions), while underestimating the effort involved in (re)writing it.

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.)

I can't understand the logic for this

Posted Aug 19, 2024 17:02 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> The rewrite that he's complaining about became Firefox

Firefox was not a total rewrite, it was more of a refactor where they extracted only the browser-specific parts from the Netscape suite.

I can't understand the logic for this

Posted Aug 19, 2024 18:46 UTC (Mon) by excors (subscriber, #95769) [Link]

> Firefox was not a total rewrite, it was more of a refactor where they extracted only the browser-specific parts from the Netscape suite.

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.

I can't understand the logic for this

Posted Aug 12, 2024 20:17 UTC (Mon) by atnot (subscriber, #124910) [Link]

It makes more sense when you think about it from the perspective of a manager.

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 :)

I can't understand the logic for this

Posted Aug 12, 2024 20:40 UTC (Mon) by dilinger (subscriber, #2867) [Link] (7 responses)

It's not really that difficult to understand - I've not yet tried COSMIC, but I watched another GNOME extension author come to the same conclusion. GNOME releases are constantly breaking extensions, so maintaining a set of extensions long-term is not only unsustainable, it also doesn't even guarantee that you get the desktop you want. You're limited by various GNOME design decisions, dealing with various features/APIs you can't access, the javascript engine (or maybe other plugins) slowly leaking memory, instability/crashes, etc. The GNOME extension world really isn't a pleasant experience, other than for small desktop modifications.

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.

I can't understand the logic for this

Posted Aug 12, 2024 20:52 UTC (Mon) by Wol (subscriber, #4433) [Link] (6 responses)

> 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.

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,
Wol

I can't understand the logic for this

Posted Aug 12, 2024 22:44 UTC (Mon) by dilinger (subscriber, #2867) [Link] (5 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?

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.

I can't understand the logic for this

Posted Aug 13, 2024 7:21 UTC (Tue) by Wol (subscriber, #4433) [Link] (4 responses)

> I think generally rewrites are frowned upon where you have a system that is efficient and works (but is considered "ugly" or "unmaintainable").

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,
Wol

I can't understand the logic for this

Posted Aug 13, 2024 8:54 UTC (Tue) by patrick_g (subscriber, #44470) [Link] (3 responses)

> I just want a UI that "just works" and doesn't NEED changing every five minutes!

XFCE is the answer.

I can't understand the logic for this

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,
Wol

I can't understand the logic for this

Posted Aug 13, 2024 10:02 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

No, MATE is the answer! GNOME 2 forever - the perfect desktop.

Splitter!

I can't understand the logic for this

Posted Aug 13, 2024 12:10 UTC (Tue) by rrolls (subscriber, #151126) [Link]

Hooray, I'm not alone :)

I can't understand the logic for this

Posted Aug 13, 2024 19:31 UTC (Tue) by Heretic_Blacksheep (guest, #169992) [Link] (2 responses)

From what I understand of the reasoning, and I don't really have any internal insight mind you I don't work for System76, they don't want arbitrary Gnome changes to screw up the desktop they're basing a commercial product upon. It's a bad user experience if an upgrade wipes out the customization a user spent a product's lifetime accumulating only to have the Gnome team decide to hare off in another direction entirely and wipe everything out both System76 and their users have done. It's about control over their product's customer experience.

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.

I can't understand the logic for this

Posted Aug 14, 2024 19:26 UTC (Wed) by Agrippa (subscriber, #170417) [Link] (1 responses)

Two points:

(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.

I can't understand the logic for this

Posted Aug 22, 2024 21:19 UTC (Thu) by mwilck (subscriber, #1966) [Link]

> The choice was to allow extensions full power to change the desktop in all sorts of ways,

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.

I can't understand the logic for this

Posted Aug 16, 2024 15:06 UTC (Fri) by bbbush (subscriber, #17456) [Link]

Source code is a liability. By inheriting technical debt, the revolving debt would have a lower credit limit.

I can't understand the logic for this

Posted Aug 19, 2024 4:45 UTC (Mon) by ssmith32 (subscriber, #72404) [Link]

No statement was made that Option #1 was ruled out because of the amount of work.

It was that building on an unstable base meant that they'd be faced with:

a) breaking their desktop
b) holding back an update of GNOME, until they can migrate... which with GNOME, may essentially involve a complete rewrite.

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.

stable rust

Posted Aug 13, 2024 5:49 UTC (Tue) by tzafrir (subscriber, #11501) [Link] (6 responses)

How stable is rust for a base for this desktop? Can they use rustc from the distribution? Packaged rust crates?

stable rust

Posted Aug 13, 2024 8:02 UTC (Tue) by hunger (subscriber, #36242) [Link] (5 responses)

Why is that relevant?

You get self-contained binaries that are statically linked one way or the other.

stable rust

Posted Aug 13, 2024 9:27 UTC (Tue) by tzafrir (subscriber, #11501) [Link] (4 responses)

I looked at the fedora source package they point to for one random package (cosmic-randr). There's a build dependency on "rustc" (no specific version). There doesn't seem no be any build dependency on any specific packaged crate. All crates come from the huge included vendor tarball (that includes a lot of junk).

stable rust

Posted Aug 13, 2024 10:24 UTC (Tue) by hunger (subscriber, #36242) [Link] (3 responses)

Why do you care how the sources of dependencies are shipped?

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?

stable rust

Posted Aug 13, 2024 10:50 UTC (Tue) by mbukatov (subscriber, #96216) [Link]

> You do not insist on someone packaging header-only libraries in C or C++ either, do you?

Why not? Fedora does that: https://docs.fedoraproject.org/en-US/packaging-guidelines...

stable rust

Posted Aug 13, 2024 12:40 UTC (Tue) by tzafrir (subscriber, #11501) [Link] (1 responses)

That's a reasonable argument if rust is limited to leaf packages (specifically: executable binaries). What about any other type of shared code? Can it be a distribution package?

A quick search in Debian shows many librust-$foo-dev packages.

stable rust

Posted Aug 13, 2024 15:51 UTC (Tue) by hunger (subscriber, #36242) [Link]

You can build dynamic c-style libraries or binaries... what else is there? Both are leaf nodes from the perspective of the rust ecosystem.

Fragmentation

Posted Aug 13, 2024 12:49 UTC (Tue) by daenzer (subscriber, #7050) [Link] (3 responses)

> For users new to Linux, which would include much of System76's target audience, it is likely more confusing.

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)

Fragmentation

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.

Fragmentation

Posted Aug 13, 2024 17:33 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

There's definitely a lack of consistency. There are lots of client-side decorations on Windows and even Microsoft can't stick to a single style across its apps.

Fragmentation

Posted Aug 13, 2024 17:45 UTC (Tue) by pizza (subscriber, #46) [Link]

> There's definitely a lack of consistency. There are lots of client-side decorations on Windows and even Microsoft can't stick to a single style across its apps.

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)

False dichotomies, anyone?

Posted Aug 13, 2024 15:57 UTC (Tue) by smurf (subscriber, #17840) [Link] (1 responses)

> which left building a custom desktop from the ground up.

Well, no. They could have chosen some suitable wlroots-based compositor and added their configuration on top of that.

False dichotomies, anyone?

Posted Aug 14, 2024 10:40 UTC (Wed) by rsidd (subscriber, #2582) [Link]

There isn't a large list of wlroots-based compositors. Sway, and some niche projects like wayfire (hyprland recently migrated away from wlroots). And none of those would be suitable as something to build a DE on top of.

They started with smithay which is like wlroots for rust. And their efforts should enable a large rust ecosystem on wayland.

Display Scaling

Posted Aug 14, 2024 18:08 UTC (Wed) by Nikratio (subscriber, #71966) [Link] (7 responses)

There is one thing that I'd really like to understand: where did we go wrong such that display scaling (especially fractional) is nowadays so hard and worth highlighting?

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?

Display Scaling

Posted Aug 14, 2024 18:15 UTC (Wed) by intelfx (subscriber, #130118) [Link] (3 responses)

> Excluding the case of using multiple monitors with different resolutions for now, does someone know where we went wrong?

Well, if you exclude the actual hard problems, the rest is very easy indeed.

Display Scaling

Posted Aug 14, 2024 19:02 UTC (Wed) by Nikratio (subscriber, #71966) [Link] (2 responses)

>> Excluding the case of using multiple monitors with different resolutions for now, does someone know where we went wrong?
>
> Well, if you exclude the actual hard problems, the rest is very easy indeed.

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.

Display Scaling

Posted Aug 15, 2024 7:25 UTC (Thu) by smurf (subscriber, #17840) [Link]

>> Well, if you exclude the actual hard problems, the rest is very easy indeed.

> 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.

Display Scaling

Posted Aug 15, 2024 18:03 UTC (Thu) by atnot (subscriber, #124910) [Link]

> 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.

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:
- 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.

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:
- 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.

Have fun :)

Display Scaling

Posted Aug 14, 2024 21:06 UTC (Wed) by pizza (subscriber, #46) [Link]

Fonts are easy, as they were largely designed to be scalable from the outset. Which leaves... everything else.

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)

Display Scaling and multiple monitors

Posted Aug 15, 2024 9:24 UTC (Thu) by farnz (subscriber, #17727) [Link]

Excluding the case of using multiple monitors with different resolutions for now

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:

  1. The pixel density on each monitor can be different; for example, I have two outputs here: a big 32" screen at 3840x2160, and a smaller 17" screen at 3200x2400 (different aspect ratios, too, in this case); I previously had a big 32" screen at 3840x2160, and a 15" screen also as 3840x2160. Finding the scale factor such that they both have the same scaled density is beyond the X11 model, since the X11 model is based around pixmap per window - but a pixmap cannot change pixel density as it moves from output to output. Thus, you need the compositor involved in scaling to the viewable area.
  2. It's rare for users to carefully align their monitors such that the top and bottom of the viewable areas are precisely aligned; that means that you not only need to be aware of different scale factors, but you also need to allow for the non-alignment of monitors. X11 can do this.

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.

Display Scaling

Posted Aug 20, 2024 1:14 UTC (Tue) by AdamW (subscriber, #48457) [Link]

You can still set a custom DPI if you like. In GNOME you run Tweak Tool, go to Fonts, and set a "Scaling Factor", which really just changes the DPI (it's multiplied by 96). I don't know where it is in KDE, but you can do it. It still "works" like it always did, which is to say, it *kinda* works. See other comments for all the things it doesn't do.


Copyright © 2024, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds