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)
