Todo on boolean item in "window rules".

[Teika Kazura <teika lavabit com>]

Hi. (Mainly for Chris.)

There's a problem in the boolean item of "window rules". Although they
look "yes/no" choice, only "yes" is effective. So, what should be
done? Ideally, it's simple: the checkbox alone suffices, so remove the
yes/no button. This means that the (un)checking changes the value
of the variable.

If this is difficult in the current implementation, what about a
button (or whichever), but can't be toggled, always "enabled".

This is a modified version of the last Chris' try which I reverted.
Its problem was that it could be switched off, but it'd still read
"enabled". This is really misleading, so worse then yes/no in a
sense. (Users may find a "bug", where an option is "enabled" but it
doesn't result as expected.)


At the same time, for some items yes/no choice is good. "focus when
mapped" is an example. It's a per-window (W) option, and there's also
a global (G) option "focus-window-when-mapped".

1. If not G but W, then that window is focused. OK.
2. If G is t and W not set, then the window is focused. OK.
3. IF G is t and W is "no", then *it should be* that the window is not
   focused. (This is actually useful; I've been using this hack.)
   Currently only G affects, and the window is focused.

Yes/no widget sets the valule to #f (= nil) when "no" is chosen, but 
for this new usage, it is better to set it explicitly to 'no. The
widget's name is "scheme-boolean" now, but this new yes-no is not
boolean, but has three states (unset, yes, and no), so I propose
"three-states". (Ternary sounds too technical, tristate is a different
widget, and yes-no sounds like boolean.) Of course, the new boolean
explained above has to be called "boolean".

Another item to which this new yes/no is suitable is "iconified"; it'd
be good if set to no, Sawifsh would un-iconify it even when the client
makes the window iconified.

Regards,
Teika (Teika kazura)