ryudo as a daily driver
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.
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.
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
.
startryudo
in turn calls ryudo
with the arguments you supply in ~/.ryudo.conf
as well as running whatever you put in ~/.ryudorc
. My .ryudo.conf
looks like this:
-virtuals 6 -term alacritty
I use Alacritty, Nitrogen, and xbindkeys to provide the rest of the main desktop environment; Other programs that I use to complete my session include dmenu, dunst, xosview, and xclock; my .ryudorc
looks like this:
#!/bin/sh # misc low level stuff xset -b sudo powertop --auto-tune & redshift -x; redshift -O 6000K & xbacklight -set 50 & # mbsync wrapper if ! pgrep sirius.sh; then ~/src/zenUtils/sirius.sh & fi # pipewire is great. no more pulseaudio taking 100% cpu on relogin if ! pgrep pipewire; then pipewire & sleep 0.3 pipewire-pulse & fi # serve local copy of my website for testing darkhttpd /home/nilix/src/nilfm/www/ --port 9001 --daemon # handle monitor biz case $(~/src/zenUtils/extdisplay.sh status) in "connected") ~/src/zenUtils/extdisplay.sh solo;; *) :;; esac # real session stuff plumber & nitrogen --restore & xcompmgr & # sleep 0.3 ~/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(){ hasPanel=0 if [ ! -z "$1" ]; then if pgrep tint2; then hasPanel=1 killall tint2 fi case $1 in desktop) ~/src/zenUtils/extdisplay.sh solo ;; laptop) ~/src/zenUtils/extdisplay.sh off xrandr --dpi 96 ;; dualleft) ~/src/zenUtils/extdisplay.sh left-of ;; dualright) ~/src/zenUtils/extdisplay.sh right-of esac nitrogen --restore if pgrep ryudo; then killall xclock; xclock -strftime "%Y-%m-%d %H:%M" -geometry -0-0 & fi if [ ${hasPanel} -eq 1 ]; then tint2 & fi fi }
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.