First of all, what I wanted to say is that I am actually a pretty bad software user. I am a software developer myself too. I hate users like me.
The really bad thing about me as a software user is that I expect the software I am using mapped at least 90% of my existing usage pattern. 10 years ago the number might be 60%, but I am getting more and more immutable as I am now older. I can’t change myself to suit a software as I used to be. So, don’t listen to me reviewing software. That’s probably my prejudice about software rather.
So, here is the saga.
I used StumpWM for two years. It is the worst tiling window manager, according to one YouTuber.
Actually, I was quite happy with StumpWM. For 90% of the usage, it is super useful. As a matter of fact, it molded my computing behaviors. And it took around a year. I will talk about the nice things about StumpWM in Act 3. But let me talk about the problem.
I noticed the input delay with my mouse. The issue was very consistent across multiple Ubuntu machines. The input delay is so bad that it renders all Javascript dropdown menus not usable. Just to give one example: The input delay renders the dropdown menu of this website not usable at all.
At first, I thought that’s a Firefox issue. But when I switched to other browsers (Brave etc.), I had the exactly the same issue. And I probably only need to use mouse with Firefox.
The second though I had is that it might be the issue of the OS. But when I switched to the original Ubuntu, there’s no input delay. And then I realized the problem is StumpWM.
I tried to stay with StumpWM but the input delay got so frustrating to a point that I could play some games on Board Game Arena (e.g. Stella).
I need to switch away from StumpWM. But to what?
I don’t know I can use GNOME or KDE or Mate or whatever anymore. I tried to use GNOME for a bit. But I kept pressing the key combinations I defined for StumpWM. Then I realize I have reached a point of no return.
And I have tried AwesomeWM. Actually, it’s not bad. The out-of-the-box experience is really nice. But I can’t settle in AwesomeWM. And the issue is the following.
My productivity with AwesomeWM was not so much different from GNOME. And StumpWM has molded me into some really strange usage patterns.
What I need is for me to press a key combination (let’s say C-. b), an application (let’s say browser) runs. If I am doing something else with another application and press the same key combination, it should just switch to (or raise) the application associated with that key combination (my browser) to my focus again. This feature’s Common Lisp name is called “run-or-raise” and it is the most important feature for me. I actually realized I want the software to be full screen almost all of the time. I don’t need tiling actually. I just need a Window Manager that can “run-or-raise” so that I can’t switch context quickly. Not display two contexts at the same time by tiling them. So, my way of using StumpWM is more like GNU Screen or tmux, while AwesomeWM is not GNU Screen or tmux.
AwesomeWM has a feature similar to “run-or-raise” called “raise_or_spawn”, but I can’t make it work. Even if I could make this work, I actually don’t like the way AwesomeWM managing key combinations. It’s more like the traditional way which other users think about combincations. But the key combinations I am so used to is something like C-. b. And I am strange enough to arrange my prefix key to C-. for StumpWM (default is C-t). And I don’t think AwesomeWM can support strange users like me. And I don’t feel pressing something like Super-b is comfortable on my keyboard. My left pinky is resting on the left Ctrl all day, waiting to either enter emacs or StumpWM commands. I can press “.” with my right hand.
As I said at the beginning, I mapped my existing usage patterns to AwesomeWM, a new piece of software I am using. And it’s pretty unfair to the software.
The only WM that I can configure it like I use StumpWM is xmonad. And the “runOrRaise” function actually works. And the Haskell code is less verbose.
main :: IO ()
main = xmonad $ def
{
modMask = mod4Mask,
borderWidth = 6,
focusedBorderColor = "#61afef"
}
`additionalKeysP`
[
("C-. e", runOrRaise "emacs" (className =? "Emacs")),
("C-. [", spawn "rofi -modi drun -show drun"),
("C-. b" , runOrRaise "firefox" (className =? "firefox")),
("C-. c" , runOrRaise "gnome-terminal" (className =? "Gnome-terminal"))
]
(set-focus-color "#61afef")
(setf *normal-border-width* 6)
(stumpwm:set-prefix-key (stumpwm:kbd "C-."))
(defcommand xterm-1 () ()
"run an xterm instance or switch to it, if it is already running."
(run-or-raise "gnome-terminal --title=xterm1" '(:class "Gnome-terminal")))
(define-key *root-map* (kbd "c") "xterm-1")
;; by default it's bound to prefix e
(defcommand emacs () ()
"Start emacs unless it is already running, in which case focus it."
(run-or-raise "emacsclient -c" '(:class "Emacs")))
(defcommand firefox () ()
(run-or-raise "firefox" '(:class "firefox")))
(define-key *root-map* (kbd "b") "firefox")
(defcommand drun () ()
"drun"
(run-shell-command "rofi -modi drun -show drun"))
(define-key *root-map* (kbd "]") "drun")
I am still configuring XMonad. But my experience so far is quite okay. At least I can map my StumpWM usage pattern almost 100% to it.