In defense of the author and their education… They’re Brazilian so English probably isn’t their native language, and their history education was almost certainly in Portuguese. I don’t think it’s necessarily an indictment of their education that they weren’t taught about the English translation of a German phrase, and I don’t think it’s reasonable to apply the same standards of subtext awareness to native and non-native speakers either.

That’s true from a technical perspective. But in reality devs (especially ones who aren’t making “Linux apps” but are doing things like porting a previously Windows-only game to Linux) will occasionally ship a broken Wayland client. The compositor could then still give that a basic titlebar with window buttons like KDE and Cosmic do, or alternatively it can refuse to do it and make the novice user annoyed at the system as a whole.

I’m not really convinced that requiring all Wayland clients to draw their own decorations was the correct decision in the first place, but even if we accept it, I think there’s still a convincing case for fallback SSDs.

Now if there was just an official API from all window managers that can check this configuration

This actually does exist. Reasonable Wayland Compositors will negotiate with their clients on whether they should use CSDs or SSDs. To an extent Qt does this: It prefers SSDs but it can draw CSDs if the compositor can’t draw SSDs (or signals that it doesn’t want to), which is why proper Qt apps are perfectly usable on GNOME Wayland despite missing SSDs.

It would be possible to go even further and make apps that display menu and tool bars on compositors that prefer SSDs (like Plasma/KWin) and nice GTK-style decorations on others. It just happens that most apps either really want to draw their CSDs (mostly because they’re made for GNOME, a.k.a. anything using Libadwaita) or they don’t really have a use for them (like regular Qt apps).

The biggest drawback of not providing any SSDs even as a fallback is obviously… what if the app just doesn’t draw CSDs? ~~There are many new Linux users who try to get something like DaVinci Resolve running and then can’t maximize it because it doesn’t have CSDs. For these users it just makes using Linux feel broken for basically no reason.~~¹

This is also a burden for application developers. Maybe the DaVinci Resolve devs should just fix their app (from what I heard it’s a massive PITA in all aspects imaginable), but is it really reasonable to also expect e.g game devs to add dependencies on libdecor or whatever solely to unbreak window mode on GNOME Wayland?

¹ Edit: I have since learned that Resolve actually does draw CSDs, it just doesn’t draw the window buttons. That’s certainly a choice… I think the overall point isn’t too affected but this specific app isn’t a good example since it would still be broken if GNOME had fallback SSDs.

That’s a largely unrelated topic… You can have theming without SSDs (as seen in most standalone compositors and also kind of Cosmic) and you can have SSDs without theming (at least in theory, I’m not aware of a project actually taking this stance).

deleted by creator

There’s apparently a ZSH plugin for this with a quite a few stars, though I haven’t used it and can’t speak for how well it works. In other shells what you want just doesn’t exist to my knowledge, though it should be possible to script it with enough effort.

The problem is that in the terminal you always have at least two layers of input handling in the terminal emulator and the shell. And these layers talk to each other by emulating a 70s VT100. This leads to some issues, in no particular order:

• Terminal emulator keybindings will step on shell keybindings, and the shell will never know about it because it can’t actually see the keys being pressed.
• Even if the terminal doesn’t care about a key, it might be impossible or error-prone to detect anyway. This applies to surprisingly regular keys like Tab.
• As you’ve noticed some terminals try to get clever and do things like making Ctrl-C copy if you’ve selected text. The shell doesn’t know about this either.
• Most shells and TUI apps have selection modes. These are independent from terminal selections.
• There’s no standard way of using the clipboard in Linux, but multiple different ones that may or may not work.

All of these problems gets worse if you add multiplexers like tmux by the way.

Now it would be possible to write a bespoke terminal emulator and shell combination that unifies selection and makes all the reasonable keybindings actually work. There are attempts at this, such as the Emacs Eshell. Unfortunately Emacs people don’t quite share your idea of what reasonable keybindings look like (and it’s also a little bit broken, though for mostly unrelated reason).

Ultimately though the main reason this is an unsolved problem is that most Linux users just get used to the regular Readline line editor that all commonly used shells ship with. Complex edits can always be done in your $EDITOR (via C-X C-E in Bash).

Yes, that is true. Curiously Qt kind of has the opposite problem of trying to be too flexible, and we have like four theming engines of which only one actually works (and it’s the one that’s tied to the Plasma desktop). GTK4 + Libadwaita is at least consistent in that it supports basically nothing.

GNOME theming discussions are weird. A lot of people will peddle cargo culted bad (broken) approaches when asked about it, but honestly it’s not that complicated¹, just restrictive:

• Use gsettings [get|set] org.gnome.desktop.interface gtk-theme [new value] to set the theme that GTK3 apps will load. Libadwaita apps will ignore this setting.

• Use gsettings [get|set] org.gnome.desktop.interface color-scheme [prefer-light|prefer-dark|default] to control whether Libadwaita apps (and GNOME shell) will display in dark mode. GTK3 apps will ignore this setting.

  • prefer-light makes everything light mode.
  • prefer-dark makes everything dark mode.
  • default makes apps light mode but the panel will stay dark.

• If you insist on theming Libadwaita apps, put the theme in ~/.config/gtk-4.0/gtk.css. You can also have add an @import directive there to import a theme. Note that this file is only loaded at startup, so using this feature means that GTK4 apps can no longer respond to the dark mode toggle.²

All of the applications that promise to help in theming GTK/GNOME (regardless of whether you’re talking about Tweaks, Refine, the theming settings of other DEs, Gradience, etc.) just flip some combination of these settings, mostly the first two.³

¹ It might seem complicated based on the length of this comment, but trust me that Qt is worse.

² The newest GTK version has media selectors, so if all of your applications are already updated to use the new GTK and your theme is updated to use media selectors then dark mode toggles should actually work now. Mine unfortunately haven’t.

³ A handful (mostly random scripts from GitHub, but also more reputable stuff like home-manager) will also try some wrong ways:

• Setting the GTK_THEME environment variable will prevent applications from loading the default Adwaita stylesheet completely, which will break all kinds of things.

• You can also put a theme at ~/.config/gtk-3.0/gtk.css, but this does nothing you can’t do with gsettings except preventing you from changing the theme without restarting all your apps.

Generally, no. You can’t install Linux onto a Windows filesystem (NTFS). What you can do is one of these things:

• Back up the files you care about (Desktop, Documents, Downloads, whatever) in Google Drive, Dropbox, a thumb drive or anywhere else that you can access later. Then you can tell the Linux installer to wipe Windows and afterwards put your important files back.

• If you have a spare SSD you can put Linux on that. Then you can access the Windows drive from Linux. You might have to install an NTFS driver first, and you will definitely need to configure Windows to shut down properly instead of secretly hibernating, because that leaves the filesystem in a weird state and Linux won’t be able to open it.

• If you don’t have a spare SSD you can still do the same trick by shrinking the Windows/NTFS filesystem and installing Linux in the now-free space on the same drive. Among Sysadmins shrinking filesystems has a bad reputation because at least historically it could (rarely) fail and destroy all your data, so I would not recommend you do it but it is possible and in most cases it works without issues.

Each of these comes with some risk - You might forget to copy over important files onto your thumb drive, or you might make a mistake in the Linux installer and accidentally delete Windows when you didn’t mean to. That said you should already have a backup strategy, because your PC could also just spontaneously die and lose the data even if you do nothing. If you have backups and you’ve tested them to know that you really can restore all the files you care about, then even that first option stops looking very scary.

One thing that bothers me about Nushell (even if it doesn’t really matter) is honestly just how bloated the table style is, with three columns in each column margin and six columns of enforced line numbers. Why can’t it display tables in the same style as regular UNIX commands?

Another thing that bothered me is that the “blessed” way to parse tables from external commands seems very fragile to me. Iirc the builtin parsing commands work solely off table headers, which are locale dependent for many commands, so a script might appear to work fine but suddenly break if an LC_* environment variable sneaks in somewhere. The size filter trick works nicely for ls, but doing the same thing becomes painful again when using df.

I also found the script syntax (implicit line continuations, command seperation, etc.) difficult to understand but presumably that’s just a matter of familiarity.

I’ll have to give it another try in the future but for now Fish is good enough for me.

No C program is written to satisfy a borrow checker and most wouldn’t compile with one, so adding it would require rewriting the world anyways. At that point why not choose a language that, in addition to being memory safe, also drastically cuts down on other kinds of UB, has sum types, sane error handling, a (mostly) thread safe standard library, etc.?