Now that I have a big monitor and I gave up on my vertical setup using the laptop screen as the lower one (since the external monitor ended up being too high up and I started feeeling some back pains), the laptop screen is only intended for running “monitors” (htop and iotop, in my case) and stays aside, to my right.
At first I was experimenting with spectrwm and let one specific workspace to be show at this screen and everything was kind of okay for some time.
But later I switched back to Fluxbox (yet again) and having these two windows in the “clients list” and, thus, being “visited” by NextWindow (or Alt+Tab, in my case) is extremely annoying, so I decided to fix that.
What I found was that using what would be “the proper way”, by manipulating X11::Protocol::WM_TAKE_FOCUS, is actually quite hard, so I went by an alternative route, that is changing the xprop WM_WINDOW_ROLE.
I investigated whether my lxterminal windows had any “role” and found that, no, they hadn’t, so I thought it would be safe to set if kind of freely, since I could use a client pattern in Fluxbox to match against this value - "hidden" was the chosen word.
So I’ll admit this research was done after everything was already working, but it’s useful to know these details, nonotheless.
If you open a “Open file” dialog box on a GTK based program and inspect the window properties with xprop you’ll see that this window role is
WM_WINDOW_ROLE(STRING) = "GtkFileChooserDialog"(It’s easy to to that: just type xprop | grep ROLE and click on any window with the crosshair cursor.)
But most “normal” windows has no role at all. Netsurf does not assign roles to the settings window, for instance (I checked that because in theory Firefox does).
So it’s already a nice thing to know: that you can control much better how some dialog boxes are going to behave if you filter by the window role.
But, anyway, it seems each program is free to choose the value, a string, and there’s no pre-stablished list of valid values or something like that.
I made the following script, intended to be called by Fluxbox, to set the currently active window role to hidden:
#!/bin/bash
# Current window ID:
wid=$(xprop -root | grep '_NET_ACTIVE_WINDOW(WINDOW)' | sed 's: ::g' | cut -f2 -d'#')
# Set window role:
xprop -id $wid \
-f WM_WINDOW_ROLE 8s \
-set WM_WINDOW_ROLE "hidden"I called it ~/bin/win-focus-hidden.sh.
The NextWindow command (man page), as many others, accept a “client pattern”. A “client” is a window, and it allows you to match against many values, like Name, Class, Title, Stuck, Shaded, etc., in theory including the use of regexes.
So my key binding for cycling through windows became like this:
Mod1 Tab :NextWindow {groups} (workspace=[current]) (Role!=hidden)That is,
{groups} means to not cycle through tabs in windows tabbed together;{workspace=[current]} means to no cycle through windows of other workspaces;(Role!=hidden) means to not cycle through windows whose Role (or WM_WINDOW_ROLE equals hidden.I really love window managers that let you control every aspect of them, specially if it’s achieved through well defined and simple configuration files.