Chris's Wiki :: blog/unix/FvwmStatesUnderstood

Understanding FVWM States, with better FVWM code for selecting terminal windows

February 12, 2012

Every so often I make an epic mistake, where I drastically misunderstand something. A discussion with one of the people behind FVWM in response to yesterday's entry on selecting terminal windows from the keyboard revealed that I had made one of them about an FVWM feature called (window) 'States'; a correct understanding of the feature leads to a better version of the FVWM code from my last entry.

What FVWM States are is effectively user-controlled tags for windows, given numbers from 0 through 31 instead of (say) text labels. Crucially, States are completely independent from each other; a given window can be in multiple States at once, and individual States are manipulated independently. Windows default to having all States turned off but can have this changed by FVWM Style commands or on the fly. States can be used for at least two separate things. The first is to keep track of actual window states, such as whether or not a window has ever been iconified; the second is to aggregate windows together into some sort of abstract category such as 'all terminal windows'.

(My mistake was thinking that a window could only be in one State at a time, which meant that using States to identify terminal windows would preclude using States for anything else involving them, more or less. This is wrong.)

The second sort of use of States is the interesting one for what I was doing in yesterday's entry, so here's revised FVWM code with commentary. First, we mark all windows we consider 'terminal windows' with a specific State through a Style command. I've picked State 2 here, but the choice is arbitrary (provided that you aren't already using the state number).

Style "XTerm"            State 2
Style "9term"            State 2
Style "Gnome-terminal"   State 2

Any time your FVWM configuration wants to specify 'this applies to terminal windows' it can now simply use 'State 2' as the matching condition. Specifically we can do this in my ToWindow function:

AddToFunc ToWindow
+ I   Current (State 2, "$0") Break
+ I   Next (State 2, "$0") ToWindow2

AddToFunc ToWindow2
+ I   Iconify False
+ I   Focus
+ I   Raise
+ I   WarpToWindow 80 20

Using a State to identify terminal windows has the great advantage that if you start using another form of terminal window, such as Konsole, you don't have to go through your FVWM configuration to add additional '|Konsole' matching conditions to everything; you just add a single Style declaration to identify Konsole as a terminal.

Style "Konsole"          State 2

(If you actually want all terminal windows to have the same window manager decorations and so on, you can do even better than this. FVWM allows for abstract styles, so you can create a 'terminal' style that decorates the window appropriately and also includes the 'State 2' setting, then simply say 'Style "Konsole" UseStyle terminal'.)

(I'd like to thank Thomas Adam for taking the time to patiently get enlightenment into my head.)

Comments on this page:

From 82.69.211.1 at 2012-03-21 08:02:04:

I wonder if there's scope for improving the FVWM man page?

-- Thomas Adam

By cks at 2012-03-21 12:30:44:

There's probably scope for improvement, but I think my misunderstanding wasn't because of any bad writing in the manpage; it was because I had never read the (current) manpage thoroughly. Partly this is because I've been using FVWM long enough that I've read previous versions of the manpage, and it's hard to sit down with something that is, oh, 70% familiar and read it carefully to understand the new 30% (or even spot the new 30%).

From 78.35.25.18 at 2012-03-21 21:12:08:

“Undertood”? :-)

—Aristotle Pagaltzis

By cks at 2012-03-21 21:59:05:

The most embarrassing typos are article slug typos. Now fixed, which is a total pain in the rear in this file-based wiki engine.

(I've had it happen before, but fortunately only a few times.)

From 78.35.25.18 at 2012-03-21 23:23:30:

And now the feed entries have re-appeared, which reveals that you’re also doing Atom wrong. :-) (The atom:id should be minted once and stay constant forever, no matter what else about the entry changes. That URIs sometimes change was precisely the (primary) rationale behind having a separate ID instead of just using the permalink for the purpose.)

–Aristotle Pagaltzis

By cks at 2012-03-22 00:25:47:

I am not so much doing Atom wrong as doing Atom in a bad environment. Metadata is one of the deep problems for file-based content engines; you don't necessarily have metadata about entries like original publication date or a unique, stable identifier for them. DWiki is especially badly off essentially because it is supposed to be a presentation layer over the filesystem.

(If you take a pure, metadata-less view of the filesystem you have no other identifier for objects other than their filenames.)

From 78.35.25.18 at 2012-03-22 16:34:20:

But isn’t it feasible to append a header (well, footer) line to an article file containing an ID, the first time the file is found not to have one? The user would have to refrain from editing it, but asking them to does not seem a problem to me.

Though, do you want to avoid opening files also? Then the problem in fact seems inescapable…

In that case you could set a xattr I guess… but that too will only work if the environment is just so.

Hrm.

—Aristotle Pagaltzis

By cks at 2012-03-26 10:22:49:

I decided to move my reply to an actual entry, AtomConstrainedEnvironments. The short version is that DWiki doesn't assume write permissions to the content it serves (and often doesn't have it).

Written on 12 February 2012.

«	How I select (terminal) windows from the keyboard in FVWM

Some things about changing from old X fonts to modern TrueType fonts