Mikeserv Support Forum

They've been at odds with Gnome and decided to create their own DE.

System76 today is releasing an alpha build of Pop!_OS 24.04 that is built atop Ubuntu 24.04 LTS and making it very interesting is that it includes the alpha version of their Rust-written COSMIC desktop environment. I've been playing around with this Pop!_OS 24.04 alpha in advance of today's embargo lift and it's been working out quite well.

COSMIC is an interesting Rust-based desktop environment that System76 has been developing. It's focus is on their Pop!_OS distribution but there have been other distributions like Serpent OS expressing interest as well along with the likes of Redox OS.

From phoronix.com

I was looking at that, it's not really ready yet (I don't mean because it's "alpha" but missing functionality). I might try it when it's divorced from pop OS and the features work and maybe by then it will be more practical to use Wayland. It looks nice.

It has the potential to be pretty light weight and snappy, but we'd have to see. You can write a kludge in Rust too. It'll be all bindings and crates to interface with C/C++ system libraries too.

As soon as gaming issues are sorted, I'm having less and less reason to cling to legacy X11. I already have to use a compositor now, or I'll have sync issues leading to floods of crippling driver/firmware errors when the display comes out of power management. These compositors need to be stable though, and not cause problems. For example, I liked that Picom compositor, but it caused me stability problems. I think also related to display PM, but I quit using it and stick to XFCE (without xfce4-power-manager installed... I hate that, I just use X11's facility with xset) where the compositor is good (don't even know it's there, I'm not using any effects) and IceWM with pm turned off with xset (in my .xinitrc), for games.

With Wayland, there are going to be a multitude of "compositors". Wayland is just protocols and framework, the window manager will be the compositor (or the DE will have a component that sits below the WM). It would then be pointless to use old X11 window managers through XWayland.

Did you know, Arch has packages for this? In their main repos no less (so users will start playing with it)

https://wiki.archlinux.org/title/COSMIC

That means I should easily be able to figure out how to compile this. I haven't decided if I'm going to build Arch packages or just use the PKGBUILDs for guidance on build order and config etc. and just compile it and send it off somewhere like /opt/cosmic. However, if I can't compile it I don't really want it on my system.

According to the wiki above, this is still something that can be started from console like an X client, simply with a "start-cosmic" wrapper. It's going to use Wayland, but I should be good to go for that because I made sure that the things I compile in the distro do link against Wayland. It's not like I'll be gaming while using this desktop, it's just a curiosity at this time (and building it is part of it... an important consideration for anything I use)

Yeah I was going to install it over the weekend but didn't get around to it. I didn't know it was in their main repos though, I was assuming I'd find it only in the AUR. Being that it's still alpha it will be buggy (I've seen some examples of that in some Linux youtuber channels), but of course the install will eventually update to the release version.

I have to install something called "switcheroo-control"
I wonder if that's really a dependency, it doesn't sound like something I want. I think I might try just yoinking that from the package dependencies in the PKGBUILDs. I don't want something trying to detect that Intel adapter. It's all but disabled in the BIOS (with the multi monitor setting disabled), but it still shows up on the bus and xorg sees something when it probes:

xf86EnableIO: failed to enable I/O ports 0000-03ff (Operation not permitted)

I couldn't find anywhere that would give me the build order, but it wasn't hard to work out from the PKGBUILDs, because most of the components don't actually depend on each other (some do) so it wasn't too confusing. Most of the dependencies are built-in rust crates.

Anything that does matter is in order here. I built them each and installed them before the next (if not all actual build dependencies, package dependencies they were). The one with the most dependencies is cosmic-session and it takes about 20s to build (the irony, I thought that one was the one that was going to be trouble). Build times are between 20 seconds and 2 minutes for these packages (including package creation). It downloads and builds a lot of rust crates, but most of them take a second or two to compile and link in.
I installed a few distro packages before I started:
That all built nicely for me with my Rust and LLVM toolchains and it used my RUSTFLAGS in /etc/make.conf
(and any RUSTFLAGS in the PKGBUILDS were += to append)

I did skip that switcheroo dbus thing... cosmic built crates for it, but it wasn't actually a library "dependency" for the build. I don't intend to use it, as I'm never going to be starting this with a login manager like GDM anyway. I don't even have one. I think that's for having a drop list to choose which GPU to start your wayland session on.

Before I started this I made a backup of my home directory, in case it clobbers files. I expect it will when I get configuring it (gtk etc.) and I want config backups to diff.

This is actually the first time I've ever run a Wayland session, it seems to be OK. This DE is fairly light weight and fast, and starts up very fast, though the UI seems a bit awkward for me. I haven't customized anything yet, but I like the appearance so far.

One thing though, I think I'm going to have to recompile my GTK+ without those "classic" patches that disable client side decorations. My non-gtk programs seem normal, but some GTK programs like Firefox seem to be missing some window controls... I only have an X and have to double click the titlebar to maximize). Other GTK programs like gimp seem fine. I'm sure it's those CSD disabling patches though.

One thing that doesn't work is the Gimp screenshot plugin. It only captures a black screen. So I had to use the cosmic-screenshot app. Press the "print" screen button on the keyboard and the interface comes up to click Capture.

Right click and view this in new tab... looks OK, but I've got some work to do on that panel lol


By the way, I didn't put my Firefox icon on that Panel. It grabbed that from the .desktop file I have configured for it. That was rather nice of it, I was pleased to see it

So this doesn't seem to step on anything. Its config seems to all go in ~/.config/cosmic

It looks like my Firefox titlebar simply doesn't work right in this desktop, whether I have the titlebar turned on or not (CSD vs. window decorations) I only have the X for window controls. However, double click maximizes/minimizes and there's a right click menu with window controls so it doesn't matter. I did recompile gtk3 without the no-csd patches but it had no effect.

Anyway, I think this is going to be a nice desktop. I envision a day when I could use this.

It just occurred to me that I've never tested Firefox in a Wayland session before. The toolkit it uses on Linux, cairo-gtk3-x11-wayland, is for both X11 and Wayland

Holyfuckingshit, the difference is no joke. Without even seeing scores, I saw the graphics benchmarks moving so fast I couldn't focus my eyes on them. The GL tests, the Draw Stress Tests...

I haven't run this test since Firefox 126, but I don't have to, to know this is night and day different (I saw the visuals with my own eyes too). This isn't the firefox upgrades that did this

Firefox 126.0 with X11

Basemark Web 3.0
2029.21

Firefox 129.0.1 with Wayland (cosmic-comp)

Basemark Web 3.0
3178.07 !!

OK, now I see why people want this.

P.S. I at least should compare the same browser. The test differences aren't as dramatic now (Firefox 126 was a long time ago in terms of... everything)

Firefox 129.0.1

Basemark Web 3.0 X11
2640.03
2658.21

Basemark Web 3.0 Wayland
3178.07
3063.13
3125.13

I haven't finished testing yet (sick of doing this shit right now! lol) but it looks like I get a bit WORSE performance in the browserbench motionmark 1.3 tests

Firefox 129.0.1

motionmark 1.3.1 X11
796.66
792.44

motionmark 1.3.1 Wayland
692.48

I only recorded the first one (hoping to discard it) but the ones I didn't record didn't look good either. It looks like Firefox is doing worse on the 2D canvas tests and stuff with Wayland (at least cosmic's compositor) but better with the EGL stuff.

Now... this is the fuckery I'm having with my Firefox window decorations. I realized that what's happening is that it's confused into using my GTK style (my XFCE plasma-fire black with orange gradient style... not only in XFCE, but in GTK 2 and 3 config files). That's its titlebars, only a bit bigger (the size they'd be in cosmic) It seems cosmic can't replace that one. Other window managers normally use their own titlebars, whatever they are. Actually that's a good thing in disguise of a "bug"... it looks nice and I have very good right click functionality on titlebars to do anything I'd want and more anyway. I think I'll be sorry now if that fixes itself lol

Note in the image that other windows, GTK and misc. X11 like my XFE file manager all get normal titlebars (that look pretty good when active actually, the window controls get the colour of the blue outline... I quite like that)

I think the window controls are covered by the graphics that aren't supposed to be there


This is going to be a nice window manager, and that "dock" (to me it's a panel! lol) is nice. Minimized programs iconify and get an image preview for an icon and stuff.

P.S. Oops... my panel/dock didn't show up, because I set it to autohide. Oh well, I described it verbally lol

It's sounding really good, especially with your seal of approval I wonder how well it would coexist with Plasma. I was debating whether to try it on my main machine where I have Plasma, or my Arch machine downstairs which has Mate.

PS: Ain't it nice to have default wallpaper that's not half bad for a change?

I don't think it would affect Plasma at all, I haven't seen it do anything outside of ~/.config/cosmic

Indeed, I haven't even changed the wallpaper yet. There are some more nebulous images similar to that one in cosmic-wallpapers that look good too.

LOL... ever notice one of your mistakes in a screenshot? I just did, I just noticed out of the corner of my eye, from that image, that I had /local off the root. That happened when I manually installed audacious... I must have done "cp -a local /" (like I would if copying something through the /usr prefix) instead of "cp -a local /usr". The reason I didn't notice was that it was just an unnecessary recompile I was overwriting with and the application was working

That's a program I hate the way Arch builds, because they build it with QT6 and disable GTK. Why? (Jawohl!) That's not even how it's intended to be shipped, it can use either. I compile mine with GTK2 (--disable-qt --disable-gtk3) for the classic interface, and it looks really sharp with my GTK styling. It's supposed to be a little mp3 player like winamp/xmms not some bloated QT application. So in order to have this "little" mp3 player, if you install the distro package it's going to pull in that whole fat assed QT6 stack. So far I have kept QT6 off my system by compiling around it. I do need (and somewhat like) QT5 for some applications though.

This is what it looks like in Cosmic... this cosmic-screenshot program leaves something to be desired, but I don't have anything else that can take screenshots from Wayland. If you choose to capture a single window, it does it without titlebars. Best I can do is draw a selection if I don't want to do full screen and select. There IS a "Take Screenshot" in the right click menu on window titlebars, but it doesn't work (does nothing). That will be handy when they fix it though.

I like the rounded shapes in this DE. They can be turned off I noticed, but over my dead body

I wonder how long it would have taken you to realize that if not for seeing it in your screenshot lol! I remember having that problem with taking screenshots under Wayland in Plasma 6. Under the latest Plasma release (6.1) Wayland has been pretty good, better than in 6.0, though when my A/C was out and I was remoting into it from downstairs (accessing my desktop full screen) I had to switch it to X11 in order for that to work using nomachine, and I never bothered to switch it back.

I got Cosmic installed in Arch, not enough time to play around with it and tweak it much right now before work but it seems to be working well.

By the way, cosmic-text-editor does have a real, mandatory build dependency on oniguruma.
I guess the only reason I don't like that is because I had build failures related to it in the past because it was optionally present. (Sylpheed and something else, maybe PHP... I can't even remember) as well as generally not liking unnecessary dependencies on the system. So I might as well install oniguruma, so I can see what Cosmic's text editor is like. It's really just a small regex library.

Work... yes, you probably wouldn't want to be doing important work in this environment

I haven't had any serious mishaps that have caused me to lose open programs or anything, but all the same, I don't want to find out what it's going to be like doing a Firefox build in this environment, at least not today (it has to profile with xvfb etc.)

Probably the worst thing that has happened is focus stealing behaviour, for example an X11 child window might cause the application to lose focus and disappear in the background when you click "OK" on it or something.

One aspect of the workspace switching mechanism I don't like here is that if you go to Workspaces, and click on, say, workspace 2 that has nothing on it, the only way to dismiss the Workspaces bar is to press ESC. However, if there's a window on it, if you click on it in the workspace switcher, the Workspaces bar will dismiss as expected. That's likely just unfinished, I doubt they'll be leaving it like that.

Oh yeah, another thing to watch out for is communication between Wayland applications and X11 (xwayland), for example copy and paste between Firefox and an X11 text editor or terminal and vice versa. Copy and paste within Firefox was working, both clipboard types.

I had this problem for a while yesterday, but I think it was because something was hurt. At the same time, the screenshot application wasn't working. There was a disconnect there. I quit and restarted Cosmic and the screenshot functionality was working again and so probably was the copy and paste behaviour (I just didn't think to test it) which was later working normally, as it is now. (both clipboard types, highlight and middle click and the copy/paste)

So if you run into any shit like that, restart Cosmic. I haven't had those things happen since.

So that Cosmic text editor really didn't need oniguruma after all, it was because Arch was forcing it with -lonig in the PKGBUILD. I took that out and the text editor built without the package installed and seems to work OK. It might have more limited regex functionality because of it, but we'll see. I likely won't be using this text editor (I don't particularly like it or dislike it but I've been using a rather simple text editor from the FOX GUI toolkit for decades, and while it's nothing special, I'm used to it)

Now, while I'm making a screenshot of this text editor, I'll also show something about the appearance customization interface. It's rather limited at this time. While it will let me change the "Active Window Hint Color" (the outline around active program windows) it won't let me change much of the rest of the theme from the UI. Changing "Accent Color" didn't seem to get it. So I figure ehh... what else is new and went to find the actual configuration files. While it did populate them from $PREFIX/share/cosmic to my user config in ~/.config/cosmic, they are pretty miserable CSS-like syntax (miserable values).

All these things are coded for that baby blue colour in individual configuration files. The "Active Window Hint Colour" was just matching those. I want the rest of where that colour is used to be my reddish orange, but I'd have to find all the files that's configured in, convert the hex triplet to RGB and then convert to those RGBA decimal values. It's not hard (52 becomes 0.52 etc. and I'll use zeros for placeholders to keep their significant digits in case that matters to somebody) but it will have to be done in an annoying number of places.

Highlighted in that text file is that baby blue colour for the active window's "X" close button. That's just one thing, for that specific state, for that specific button lol

This is showing the file in /home/grogan/.config/cosmic/com.system76.CosmicTheme.Dark/v1

This is not nice shit to be editing by hand.

There... how do you like the taste of my ass now, futhermuckers

Thinking about it, there was an instant way to do it. Because those values were so "unique", it was easy to find and change them everywhere they used them. So as not to be creating strange triplets with re-used colour values, I checked with grep -n first (line numbers) and those colour values were all used together in the files. I thought so, because for them to be that silly, they had to have been generated from some colour generator/wheel or something and they kept all the decimal places (lol! utterly pointless) and thus, would be part of a triplet. I really don't need all those (don't need to pad them, they haven't), my significant figures are 3

For one other element, they have it like this. That's just noise from whatever generator they used, it was meant to be 0 in the triplet (black, RGB 0, 0, 0 with alpha 1.0). That's how I'm sure the decimal places are bollocks.
In case I get docked marks for not showing my work (I used to hate math teachers that did that):

From the focus setting for that destructive_button, I knew the values to change
Of course "alpha: 1.0" means opaque.

So, it's pretty simple to use sed with wildcard here because all the files are in the same directory
That's it, awesome colours.

Actually the screenshot situation is pretty awful in Wayland. First of all, the only reason you have permissions to grab the screen at all is through xdg-desktop-portal. Secondly, not all Wayland screenshot programs work on all compositors. I just downloaded and compiled a few that looked promising. The first one called grim would have been a simple utility I could have just "sleep 10 && grim" and just position everything and have it capture the whole screen. Unfortunately this compositor doesn't have the method it wants to use.

So I download and compile another one only to find out that it's a front end for grim lol

The problem with the stupid cosmic-screenshot utility is that you have to bring up the program and operate it. This will DISMISS anything you had hovering or cause loss of foreground focus in the things you want to capture. It's very poorly thought out.

I wanted to show a screenshot including the buttons and sliders and stuff and my user session/logout thing and I just can't do it with that screenshot utility.

Arch's packagers do some pretty silly things. They always have to be "clever"

I noticed an ignored update for cosmic-greeter (a -2 pkgrel) so I updated my PKGBUILD and did it. They added a patch to enable the systemd service with an alias (I don't want the cosmic-greeter-daemon service enabled through systemd so that doesn't affect me) but somehow, from the same commit, this managed to build a package almost twice the size. cosmic-greeter is a program that cosmic-session itself uses, so it's running right now. (It's mandatory, without it, cosmic-session will abort)

Instead of just building the tag they checked out, now it's:
I see why... the cosmic-greeter binary is 27 Mb stripped. I noticed that wasn't right as soon as I saw the package (I installed it first though with "pacman -U *.pkg.tar.zst" without listing lol). I would not have published that package, there's no way a program jumps 10 Mb in size overnight. That must have built and linked in a lot of unnecessary crates.

So much for light weight. That can fuck right off, I'm going back to the previous prepare method. I wish I'd have kept my package, but it looked to me liked they were just installing that patch, so I deleted it. I'll have to go back to the git history to get the -1 rel PKGBUILD. Ah well... a few seconds to build that and I see my cosmic-greeter binary is over 10 megs smaller. Guess I'll go install it.

That looks a lot better!

It's the same thing with making screenshots in Plasma 6.1 when using Wayland. What works there is to press the print screen key, and then up pops Spectacle. If you click the 'Rectangular Region' button it'll show you the desktop and let you select what you want to copy.

From there I can copy & paste into Gimp. There was no way to get a screenshot of Spectacle itself without using another utility (can't bring up another Spectacle instance) so I used my phone.

Yeah, it looks like you can set a delay there in that one. That's what I'm missing. "Capture the whole screen, including mouse pointer" after a delay of e.g. 20s and then get everything in position and hover over what I want etc. (That's how I'd use Gimp screenshot utility to capture things you can't keep on screen otherwise)

I can select a region, or get it to snap the screen, but only after a click, "capture", which then dismisses things like the logout area (I wanted to show my red/black buttons there, hanging down over the control center to capture that too).

You'll see what I mean when you get playing with Cosmic

Ahhh... the screenshot program wasn't working correctly last night. When it does a full screen, it draws a big outline around the whole screen before it snaps it. When that occurs, whatever was on screen seems to be there in the image and I can click Capture. That was not occurring. I should have restarted cosmic.

I tried it again today and now it's working like it's supposed to. I'd prefer a timer, but at least I can position shit before pressing Print Screen and it will be captured. This is what I was trying to do last night...

Looks good!

I'm going to be keeping this I think. I'll be building the packages, so I won't let anybody fuck it up. (and I'll be keeping my previous ones as well as the old PKGBUILD dirs from now on... like I do with the distro packages I build)

This, has earned its place in my "startd" wrapper that I keep in /usr/local/bin (shortened from "startdesktop" because that proved awkward)
I really do hate those graphical login managers and this gives me the functionality I need. Basically, the only functionality I do like about those things... a chooser. I've been thinking about having it start automatically with my shell, but not sure I want to have to abort a script to get to my console (especially when switching to another shell to kill something).

So finally I have a use for that Windows key. This environment programs it as the "Super" key which is used in keyboard shortcuts.

Switching workspaces is

Super+1
Super+2
Super+3
...
Super+0 (to switch to last workspace)

This is according to how many there are. If nothing is on them, they get removed except one extra. So if I only have a program open on Workspace 1, there will only be 2 of them. As soon as I open something on workspace 2 there will be 3 of them etc.

Also there's a choice between vertical or horizontal workspace layout. Vertical is the default, but I changed it to Horizontal because that's the layout I'm used to. There's also a Tile vs. Float setting for the windows on the workspace switcher, but floating (default) is fine. I'll not likely see that very often, using the keyboard shortcuts just switches to the workspace without any additional clicks. This is actually practical, most window manager shortcuts for switching desktops are too many keys. Probably the best is IceWM with CTRL+ALT+NUM but others are worse than that.

I can work with this!

How to add things to the Dock...

It's easy if it's just an application that runs with no arguments. Simply open the application and then right click on its taskbar area on the Dock, and toggle "Pin to App Tray". Fine and dandy, but some applications are useless to just open with no arguments, for example a terminal application like my urxvt.

So I found where it stores those entries. I pinned my URXVT terminal, but it didn't take the arguments of course. I figured I'd manually add them to whatever source it's getting these from. It would pretty much have to be a .desktop file with the way it behaves (it gets my firefox icon etc. and those com.system76.CosmicEdit etc. are .desktop files in /usr/share/applications.

/home/grogan/.config/cosmic/com.system76.CosmicAppList/v1/favorites
They seem case insensitive (there is nothing in all of Hell's creation named "URxvt"). However, that just opens the application with no arguments. I figure it has to be coming from /usr/share/applications so I edit urxvt.desktop but no. So on a hunch I copied it to ~/.local/share/applications, edited there and then just added "urxvt" to the list in that favorites array. I can't stand it being incorrect case like that. That's wrong, wrong, wrong of them. That should not be case insensitive, not only accepting but generating incorrect case.
That worked, now "urxvt" on my Dock panel launches my terminal correctly.

Anyway, if you want some application, make a .desktop file configured to your liking in ~/.local/share/applications and add the name of it (without .desktop extension) to that array in that favorites file

P.S. It gets some applications absolutely wrong, so careful with that. I went to pin my favourite text editor "Adie" (/usr/local/bin/adie) and it added it as Unknown Application 28 and gave it a wine icon. At first I thought it just chose an icon wrong so I clicked it and it tried opening nothing with wine (generating prefix but it aborted and didn't create ~/.wine). I have no idea why it tried to run what would have been "Unknown" with wine lol

If that happens, fix it manually as shown. I added it as adie in that favorites file array and it worked because I have an "adie.desktop" in ~/.local/share/applications configured with the icon "text-editor" so it's perfect on my Dock. It must have been unable to grab the application name from the process and consequently didn't find adie.desktop that was already there.

P.P.S. Icons. You can specify an absolute path to an icon in a .desktop file. OR, this will find them in ~/.icons (which is the old school location for them). Otherwise, to reference an icon by name like that, there would have to be an alias or a symlink in the icon theme that the environment is using.

Currently, there's an "Experimental" settings panel in Appearance that lets you change the icon theme. I don't want to find out how that works out, because I see they don't have to be valid to show up there. I have incomplete icon sets that I use icons manually from BUT also things like cursor themes show up in there and they are NOT icon sets (moreover, there's no xcursor support, you're getting the cursor from the environment except in things that support it directly, for example Firefox through my GTK+ styling). So I'd expect icon themes to not jibe at this time. Probably icon aliases aren't all worked out, which is why it's "Experimental".

For example, I added Sylpheed to my Dock and there was no icon for it. I never noticed before because I always assign my own icon to it, but there actually is no icon named "sylpheed" as the shortcuts are configured (some icon themes, older ones, do have one for it).

So I took my email icon and resized it to 48x48 as used on the dock (I don't like having icon images automatically downscaled every time they are drawn, why do that work). I stuck it in ~/.icons and referenced it as simply Icon=email in the sylpheed.desktop file.

I knew this because my Firefox icon has "noie" as the icon, which the only place that would be automatically found would be there, where I have a "noie.png". That's the only firefox.desktop file configured with "noie" the one I manually use in ~/.config is named "ie.png".

LOL... I found a pretty strange bug. After finally getting my urxvt dock entry to launch my terminal with the arguments in the .desktop file, I noticed that sometimes the terminal would start scrolling enter repeatedly, very fast. Hitting the Enter key stops it.

Then I figure out that it doesn't happen the first time it's launched, but does each subsequent time. Hitting Enter stops it.

I also noticed after that, my XFE file manager launched from the Dock does the same thing. The directory view keeps refreshing over and over while the mouse cursor flashes briefly to busy and back. Again, hitting Enter stops it. That area shouldn't even be in focus like that until something is clicked in the pane.

It is because of the way I quit my terminal, my hands are on the keyboard while using it and when I'm done, I type "exit". This kills the shell and the window, I've been doing it like that for 25 years.

If I quit my urxvt terminal by clicking the X ("destructive_button" lol) this doesn't occur. I can repeat it over and over and it doesn't happen if I kill the window with the X. Then, my XFE file manager doesn't act up either. It must be the way something is terminated when passing execution through the Dock or something in this desktop, when I kill that shell but the window resource isn't killed it must keep perpetuating the Enter command in the background, to new subshells the Dock launches programs in. So I have to remember... When in Cosmic, use the X (that's going to be a hard habit to break as it makes opposite sense)

P.S. I'll bet this also explains why my keyboard suddenly stopped working last night. It was indeed after having that bad behaviour occur (and little did I know at the time, it was still going on in the background). I was typing a post here and suddenly no more keystrokes. I clicked somewhere else, and the keyboard started working again briefly in a text editor but then stopped dead there too. It was also accompanied by the green light on the keyboard coming on (like if it's been powered down and powering on from a keystroke). Even after I quit Cosmic the keyboard was dead on the root console. I went upstairs and got some new batteries, but still the keyboard wouldn't work. At that point all I could do was an ACPI power button shutdown and the keyboard worked again after booting up. The receiver must have been in a bad state or something (in that case unplugging and replugging probably would have worked also). The mouse on the same receiver was working though.

I'll play around with it this weekend. One of the Linux youtubers I sometimes watch did some videos on Cosmic, one of them he titled "Become one with the bugs"

LOL.. he thinks the extra workspace is a bug, to me it's a feature. How else would that work? You can't open a program on another desktop if it doesn't exist yet, unless the workspace switcher creates one when you go to switch (I think it would be more practical to always have an empty one if they aren't pre-existing like other window managers). I've never had a window manager that dynamically creates and destroys virtual desktops/workspaces. The way this works it's fine for me, not much different than pre-existing workspaces in practice, the way I use them.

Also, that's not true about hand editing configuration files. He admits he doesn't know, hasn't looked at them, yet he's saying that. As long as you don't change that property, you can still change other settings in the GUI, moreover it's separate files in separate com.system76.blah directories for stuff. This one doesn't overwrite the whole configuration when you change something. That setting he's complaining about probably has to parse and change data in a lot of files, hence, there's a delay when he increments it. "Small" and "Large" on a slider... meh. Not as reproducible as a numeric value, but often it's more precision than the slider is capable of doing reproducibly anyway. It can be tricky to get it to keep an exact value (sometimes to decimal places, or sometimes the bar snaps to incremental positions anyway when it's whole numbers) depending on the movement scale.

This guy is a bit opinionated on how he thinks thinks should work, comparing the workspace switcher tiling with other window managers etc. I'm not sure if it's bugs, or he just doesn't like how it works. That complex tiling window management he's doing isn't how I'd work, so I couldn't say. I'm more of a full size window on multiple desktops kind of guy. Not always, sometimes I want a smaller terminal or something over top of a maximized window but I don't like a bunch of narrow windows that snap to any kind of grid, I like things maximized or floaty. That's why I like focus follows mouse in XFCE (it works particularly well there, better than KDE), because I can still type on a window behind without dismissing the focused one on top. Hopefully they'll implement different focus settings in Cosmic.

I'm beating this into submission for my usage OK