well, it's happening: we're trying Gnome. we've been using KDE for a few years... let's see how this goes.
we're not people who actually *use* a desktop manager, other than as a fast way to configure certain services that we don't feel like spending time understanding, so realistically we should probably be trying to do without one.
we have no complaint about KDE for what it is, it's just we have been meaning for a while to figure out how to disable krunner because it gets in our way, and it turns out the system isn't designed for that.
like disabling it breaks other things about the startup process, and the startup process is governed by a C++ binary.
you know what? we are capricious and whimsical. we are going to learn i3wm instead of Gnome.
yes they do entirely different things.
see, as far as file manipulation, we use the terminal, and have done, across every OS we've ever used, for nearly thirty years. so any form of GUI file manager just gets in the way, to us.
as far as launching programs, we've been very happy with rofi the last couple years, and we will be continuing to use it.
so like... the Settings windows, and their integrations with various services, are the main thing we would actually need from a desktop manager.
see, when we did our thread about lp and lpstat and stuff the other week... part of why we gravitate to command-line tools is they're much more loosely integrated than GUI environment stuff is. so if we choose to change our GUI we don't lose the stuff we understand already.
it's totally fine to prefer tighter integration, but we enjoy being able to swap out the pieces. we want to understand our machine, it's an extension of ourselves.
cool, NixOS gives us the option to use the Nix store to manage our i3wm config file, rather than using mutable state in our home directory. we will be taking it up on that. declarative state for everything!
This is fascinating, we're already learning more about how KDE, despite nominally coming into the picture after the display manager has done its work, had been providing some config to sddm.
That kind of tight integration, while good for UX, is in opposition to our ideals around software that's organized as small, composable pieces with well defined boundaries. So it's nice to see exactly what breaks when it changes!
You learn way, way more about any complex system when it breaks, compared to when it works properly.
It's very nice to be using NixOS for this kind of thing, because if we render the system unusable we can always roll back to yesterday's config.
We know how to find our way out of a vast range of broken states, but it's always preferable not to need that experience.
That's fascinating. It doesn't set wallpaper automatically, which means the login screen is still visible in the background after login. It took a bit of messing around in tty mode to convince ourselves it was fully logged in.
This is not a beginner-friendly experience. It could be made to be, without adding intrusive elements that will annoy experienced users. It just needs some sort of interactive tutorial.
"For experts" shouldn't mean "elitist" or"you're on your own for learning it".
One of the core hacker ideals is that knowledge is power, and, as such, should be available to anyone who seeks it out.
Anyway, we're just noting this in passing. We know very little about the community around i3wm.
First things first, let's see if we can switch out urxvt for konsole. Konsole is a good program, as long as we can get it to work without the rest of KDE.
Plus our personal cherry blossom theme is written for konsole.
Okay, it uses a utility program called i3-sensible-terminal to pick the terminal emulator. That seems like a useful layer of indirection, so we'll figure out how to hook into it...
The terminal emulator is the first step because until we get this working, we're still doing our stuff in console mode and thus we aren't actually using i3. Also we really don't like the color scheme or font size in console mode.
Nah, okay, the manpage for i3-sensible-terminal makes it pretty clear that it's already served its role by helping us bootstrap, we don't need it as an indirection layer long-term. We'll just rebind this.
The default i3 config opens a terminal when you press meta-enter, which is a pretty great idea for a keybinding, so we'll be keeping that.
It's quite nice that all our various stuff aimed at making the terminal nicer to use still works in console mode. That's not an accident, we spent time on it when we originally did the things. It makes these rare experiences far more pleasant.
Okay, good, i3 has a feature to check the syntax of our config file without actually messing with the running system. That will save a huge amount of time.
We've already changed some keybinding. The i3 website was pretty up front that they use a thing that's like vi keys but shifted one column right... Even without trying it, we know that's not what we want.
Okay! We now have konsole running. That wasn't too bad.
We tried to start Firefox and it, uh, remembered our open browser windows from before (good) and opened each one in a vertical strip half an inch wide, making the entire screen unusable (bad).
We already know the key binding to split window containers, because we had to change it so as to not conflict with our change to use the proper vi keys. So maybe that will help...?
It would be pretty useful to have Firefox working as we continue to mess with stuff. For one thing, the i3 website is where the tutorial is........
Interestingly, using loginctl to log out kills our tmux session. We very explicitly do not want it to do that. Very annoying.
Probably we should just kill the i3wm process to log out.
There we go. Doing that left our tmux session intact, which means we can reattach it and immediately have all the stuff we were doing in the terminal back in front of us.
We've previously tweeted about our tmux setup.
There we go, we got rofi working.... That's the application launcher we use, we had a thread a while back where we spent a lot of time styling it.
The actual rofi config just works fine, as it should since rofi has been carefully designed to not care what window manager we use. What we needed to configure was a key binding to invoke it.
For that we needed to look up what the actual invocation we've been using is. Unfortunately, because KDE is a giant pile of mutable state, we had to go digging in config files to find that. With Nix-managed i3 config we can file things better, so we won't have to dig next time.
Okay, we got our default font size in konsole fixed, which means, you know, a few keystrokes we won't have to do every time we restart i3. So that's nice.
Still no Firefox, we wound up doing the stuff we definitely knew how to do first.
Oh cool i3 has a restart-in-place feature. That's really nice. We learned this by reading the config file (we started with an autogenerated one and have been modding it).
It also has a reload-config feature, but we know that won't work for us because of how the Nix store works. It's technically a different file every time, that's how Nix allows old versions to coexist with new ones.
Okay we made the window titlebar font no longer illegibly small. This also seems to have affected miscellaneous status bars.
Interestingly, it seems to be using the same font we carefully picked out under KDE, even though most parts of KDE should no longer exist from the perspective of the currently running system.
We want that font, so, great, we just don't like mysterious hidden global mutable state. Where did KDE actually configure this? Looks like maybe Pango (the text layout library)?
Oh! Good! This is actually a thing we did through Nix. That's much better.
The nice thing about Nix is it lets us organize our config files however we want, so it's easy to find things again even if we totally forgot we did them. Heh.
It's actually a fontconfig setting, as it turns out.
Global *immutable* state is fine, as long as it's well organized and version controlled.
Good news! We figured out how to get Firefox to open as several dozen *horizontal* strips, all confined to the right side of our screen. This is a significant improvement because we can still read our terminal on the left side while we figure out the next step.
i3 appears to have some sort of status bar that tells us where in the window containers hierarchy we are. As much as we love compact UI, that's probably a good thing while we're learning; we will resist the urge to turn it off.
okay we have our two dozen Firefox windows displayed in i3's "stacked" mode now, and that's surprisingly decent although it does use more than half the available screen space just on their titles.
the "right" fix for this is probably to figure out i3 workspaces and move most of these to task-focused workspaces. under KDE we had a 3x3 grid of virtual desktops; not sure if that concept makes sense here.
now that Firefox works, we are acutely aware that nothing has configured our trackpad's scrolling direction, and thus it's "wrong". how upsetting. we didn't want to rely on KDE for that in the first place, but still, we should look for a way to configure it...
it appears that NixOS has libinput support and that that is the modern tooling that we want for this.
from reading our Nix config, it appears we had previously enabled libinput but never set any options for it. cool. that's easy then, because we know libinput already works well with the rest of our setup.
for some reason we keep habitually typing control-W as if it's a command prefix for something. did we... use this somewhere in our stack at some point? that's an inconvenient habit to have since it closes windows...
we're gonna rebind close-window to meta-q because that's a key combo we have no prior habits around, so we won't hit it by accident.
our brain, sadly, is not amenable to rapid reconfiguration in the way that digital computers are.
ohhhhh control-W is the prefix for moving between panes in vi. the i3wm UI is sufficiently vi-esque that our brain muddles them. that's pretty cool! long term, this will make us happy.
oh bother, control-W isn't an i3 command at all, it's a Firefox command. how do we change that...
okay, this is probably what we'll do at some point but we don't really want to recompile Firefox right now, so not right this moment. shallowsky.com/blog/tech/web/…
Nix does make it pretty easy to write our own patch and rebuild everything to use it, so it's not nearly as tedious or fragile a solution as it probably sounds.
this thread is mostly us syslogging, by the way, people can chime in with advice if they want but please don't be hurt if we just skip over it. we're very fast researchers so we've probably solved the problem by the time you reply.
interestingly, our nix libinput stuff isn't happening. why not? what service is supposed to do this? time to run ripgrep on the nixpkgs repo
running the command manually definitely fixes the scroll direction, it just doesn't seem to be doing that otherwise...
very very cool, now we have our browser tabs all organized into workspaces. that is going to save a lot of tedium.
the bad news that goes with that is that we haven't figured out how to get i3 to *save* it, so we can't reload X until we have...
we like the i3 stacked-window container mode, it maps well to how our brain thinks of things. this is going to be very useful for us. we definitely need to mess with the color scheme though, right now the aesthetic says "edgelord" and we want it to say "high femme".
we're using numbered workspaces for now. the primary one is chat+code (these are messy and intertwined activities for us, so no point separating them).
then we left a gap for miscellaneous stuff we want to do. then the following ones are uh... academic stuff we want to read; fiction we want to read; technical documentation we want to read; then some blank ones, with email at the far end.
apparently "thing we want to read" is the fundamental meta-category our brain uses, or at least the one it uses while coping with the pandemic.
we took a chance and verified that, yep, i3 does preserve which workspace things are on when we fast-restart it. now if only it could do that across Firefox restarts, that would be great...
ah, hmmmm. we now understand the basics of i3 layout saving, and it's pretty cool. in our experience, stuff that tries to do this automatically never works, so having to modify a config file makes sense to us.
unfortunately Firefox doesn't seem to export enough information to do anything useful when we have so many windows open... hmmmmmmm
okay, so it looks as though part of the solution here is probably to replace firefox tabs with i3 tabs. we like that for several reasons. messing with firefox css now.
that way at least the window title will always be the title of the same website... which makes things easier for i3. it's not a full situation because, sadly, we still use various web apps that vary their titles based on stuff...
it's unrelated but we've also been taking this as a chance to set up some shell aliases that have been a long time coming, just turning on colorization by default and things like that
hmmm this approach of removing the firefox tab bar is also going to require us to have separated out our tabs into subcontainers. time to do that :)
okay, cool! the tabs are all separated out. now it should be safe to install this custom Firefox CSS and restart Firefox... hmmm, except that i3 won't put them back where we want, so we need to finish that part first...
right, and we need to turn off "open links in tabs instead of new windows". and get used to not using control-T.
we're really liking how i3 now puts Thunderbird exactly on par with our various other email-like windows, in terms of allocating screen space to them and stuff. still need to mess with the color scheme, but this is gonna be really good.
oh! the natural scrolling issue was that we didn't check our libinput change into git, so it wasn't being invoked. no wonder.
(we never make changes directly to /etc/nixos. we always check them into git and pull them down. even one-line changes. code is communication, and in particular, version history is very useful if we mess things up or get called away and need to reconstruct what we did...)
we're noticing that, because we are now doing all window-management tasks using keyboard shortcuts, we often don't know where the mouse pointer is. we should probably figure out how to embiggen it at some point.
lots of other stuff to do before we get around to that, though
by the way, we don't think we ever actually said, but a lot of our goal with tweeting all this is to share our process with people so all y'all can kind of passively learn more about how to do this stuff
as always, we're particularly interested in doing that for all the queer, plural, and disabled beings who follow us.
it's fun and motivating to babble while we work, but if that were our only goal we could do it privately :)
hmmm we need a color picker to design a pastel version of our titlebar purple
hmm this doesn't feel like it's quite there yet, it feels busy...
this feels substantially better (that's the same pink we use for our terminal background, and in rofi)
why do people want lines between everything? it's spurious :)
oh! right! we already designed a perfectly good pastel green with about the same lightness and saturation as that pink, to use in rofi for contrasting lines. we should use that instead of our weird purple.
much, much better
as you can see, we still haven't reloaded Firefox to pick up that change to hide the tab UI. still need to get window restoration properly working.
a thing we've noticed while messing around, which we're looking forward to when everything else works so we can play with it, is that i3 lets us design arbitrary modal states for key bindings
this is great because we absolutely hate typing chords of modifiers. our brain just isn't able to keep track of it.
okay, we got Firefox restoring to pretty much work. some stuff winds up in places we don't expect but they're difficult cases for various reasons, and we know enough now to fix them up by hand. which is really no worse than what we were having with KDE's window manager.
that also means we no longer have to see the unnecessary Firefox tab bar :)
So that was a good day's work, tbh. It's nice to do things to improve our environment every so often.
It's pretty much doing everything it's supposed to at this point. We still need to mess with the status bar, but that's pretty self contained.
Thanks for reading along!
• • •
Missing some Tweet in this thread? You can try to
force a refresh
The lesson to take from this, by the way, is that walled-garden software ecosystems are, fundamentally, centralized power structures which are going to create a conflict over who controls them.
If something is fully decentralized (an ideal which very few existing technologies or social structures live up to), there is nothing to fight for control of.
With app stores, we see corporations attempting to impose their own content policy rules... and we also see governments making rules about the rules.
okay! we would like to start a discussion about what it would take to make Linux *fun* for newcomers. please chime in with your ideas!
we've personally always found it fun, we're in the crowd where it's more important to be able to tinker with things than for the things to actually *work*. however, we recognize that this is a minority position.
we do think that there needs to be a lot of work on usability. just, like... taking all the "how to debug" wisdom that's currently spread out across the ArchWiki and a million Bugzilla threads, and turning it into UI that guides people towards the solution.
there's a lot of people who are taking firm stances on this latest anthology that's been going around trans circles, and it's just, like...
we realize you're convinced of your stance. also, many of you were just as convinced of the *diametrically opposed* stance last year when Isabel's story was published.
try not to be mired in the moment like this. try to think about whether the objections that seem so real right now, ... whether you'll even remember them next year.