nilFM

ryudo as a daily driver

2021-11-14

Off and on, I've been using ryudo as a daily driver for the better part of the past year. Now that it's reached version 1.1 1.2, I think it may be about time for a rundown of the setup and workflow.

Ryudo desktop with 2 terminals, one showing uname output and disk usage, the other editing some uxntal code in micro; xosview and xclock are in the corners

philosophy

Since my first flirtations with plan9 and rio, I loved it. The perfect balance between minimalism and functionality was intoxicating. I used rio from plan9port as my main window manager for a long time, and once my programming chops got up to snuff, I forked it and ryudo was born.

My goals with ryudo were to provide plan9port rio with keybindings, but I ended up with a more stable and better-behaved window manager as a result. Since starting with ryudo, I've also used KDE Plasma, and while I love the customizability and outward polish of that environment, it has a number of things that leave a foul taste in my mouth: the clutter it hides in your ~/.config directory, the number of processes it spawns, the reliance on a systemd-compatible seat-management service, the use of Javascript as an extension language, and a few things having to do with tactless release cycles. Ultimatley, I prefer a simpler and more elegant computing environment where I can actually track what every process in pstree is doing.

An alacritty window showing clean pstree output of an almost-empty ryudo session

I switched back and forth between Plasma and ryudo alternatively, a few months on each, for a while. Workflow-wise, Plasma with Bismuth offers most everything I need. But philosophically I'm at odds with it, for all the reasons given above. I recently switched back to ryudo, and I think this time I'm going to leave Plasma behind me for good (on both of my machines! I have migrated to Fluxbox on yggdrasil, which is comparable in UX to Plasma but without the cruft).

flow

I keep it simple, logging into tty1 and launching startx. ryudo 1.1 features an xsession .desktop file and a session wrapper script modelled after Fluxbox and Openbox. Session processes can be put in ~/.ryudorc and ryudo options can be put in ~/.ryudo.conf; so my .xinitrc is just exec startryudo.

I use Alacritty, Nitrogen, and xbindkeys to provide the rest of the desktop environment, so my .ryudo.conf looks like this: -virtuals 6 -term alacritty

Other programs that I use to complete my session include dmenu, dunst, xosview, and xclock; my .ryudorc looks like this:

# misc low level stuff
xset -b
sudo powertop --auto-tune &
redshit -x; redshift -O 6000K &
xbacklight -set 50 &

# my mbsync wrapper
if ! pgrep sirius.sh; then
  ~/src/zenUtils/sirius.sh &
fi

# pipewire is great. pulseaudio used to sometimes just take 100% cpu for no reason after logging out and back in
if ! pgrep pipewire; then
  pipewire & sleep 0.3
  pipewire-pulse &
fi

# here is the real session stuff
plumber &
nitrogen --restore &
xcompmgr &
~/src/zenUtils/batAlarm.sh &
xosview --geometry +0+0 &
xclock -strftime "%Y-%m-%d %H:%M" -geometry -0-0 &
export GTK_THEME=steppenwolf-dark
export WINIT_X11_SCALE_FACTOR=1
xbindkeys -f ~/.xbindkeysrc

The transsetter.sh script included in the ryudo source tree is used to provide selective transparency with the help of a compositor. As of version 1.2, ryudo has support for setting window transparency by class in the config.h file -- it just needs a compositor running for the transparency to take effect. I use xcompmgr as the compositor because, despite being unmaintained and lacking a bunch of features, it's the lightest on resources of all the standalone X compositors and does what I need it to do.

My .xbindkeysrc looks like this:

"sudo /home/nilix/src/zenUtils/logout.sh -p"
  Control + Alt + BackSpace

"/home/nilix/bin/9/dmenu_exe"
  Alt + space

"slock"
  Mod4 + Escape

"/home/nilix/bin/zenbar/nmtuiWin.sh"
  Mod4 + F1

"notify-send -c power battery [$(cat /sys/class/power_supply/BAT0/capacity)%]"
  Mod4 + F2

"datetime=$(date +%H:%M); notify-send -c time time [$datetime]"
  Mod4 + F3

"amixer set Master 5%+; notify-send -u low -c volume volume $(amixer get Master | grep % | head -n 1 | awk '{print $5}')"
  XF86AudioRaiseVolume

"amixer set Master 5%-; notify-send -u low -c volume volume $(amixer get Master | grep % | head -n 1 | awk '{print $5}')"
  XF86AudioLowerVolume

"xbacklight -inc 5; notify-send -u low -c brightness brightness [$(xbacklight -get)%]"
  XF86MonBrightnessUp

"xbacklight -dec 5; notify-send -u low -c brightness brightness [$(xbacklight -get)%]"
  XF86MonBrightnessDown

"amixer set Master toggle"
  XF86AudioMute

"amixer set Capture toggle"
  XF86AudioMicMute

"redshift -x; redshift -O 4500K; notify-send -u low -c brightness color [4500K]"
  Mod4 + XF86MonBrightnessDown

"redshift -x; redshift -O 6000K; notify-send -u low -c brightness color [6000K]"
  Mod4 + XF86MonBrightnessUp

I also use this little shell function to manage switching between ksatrya's builtin display and my external monitor; it wraps one of my zenUtils scripts, extDisplay.sh, which itself wraps xrandr, and in addition to switching the displays it also resets my wallpaper and repositions xclock:

mode(){
  case $1 in
    desktop)
      ~/src/zenUtils/extdisplay.sh solo
       ;;
    laptop)
      ~/src/zenUtils/extdisplay.sh off
      ;;
  esac
  nitrogen --restore
  killall xclock; xclock -strftime "%Y-%m-%d %H:%M" -geometry -0-0 &
}

thoughts

Between the psuedo-tiling, mouse control, the possibility for autostick windows, and the improved positioning and focus behavior over plan9port rio, a ryudo session provides a spartan but complete and comfortable experience. It does this in a way that keeps the process tree and filesystem free of clutter and the user's mind on the task at hand.

My ryudo session, and perhaps the fact that I use ryudo at all, is an expression of my unique relationship with technology. I don't expect anyone else in the world to use it, but I provide the opportunity in case any like minded folks want to give it a shot.

As I mention in the ryudo project page, there are a few bugs to work out, and I hope to hunt them down. Mostly it's just the obvious improvements that could be made to the focus model (currently, the click used to focus a window is not passed through), and the strange bug that happens if you rapidly switch back and forth between two virtual desktops with visible windows (if you loop/scroll in one direction it doesn't trigger the bug).

It's good to be home.