ClientPatterns might be tricky to get right. Instead of fiddling around in
either the keys-file or the apps-file and restarting fluxbox to see if the
changes had any effect / matched the right windows, 'ClientPatternTest' and
the fluxbox-remote should make this easier:
$> fluxbox-remote "clientpatterntest (title=.*vim*)"
This causes fluxbox to store the list of matched windows in the
_FLUXBOX_ACTION_RESULT property onto the rootwindow. This property might
then be read by:
$> xprop -root _FLUXBOX_ACTION_RESULT
or
$> fluxbox-remote result
The format of the list is:
win_id \t title_of_window \n
win_id is '-1' when fluxbox wasn't able to parse the given ClientPattern.
win_id is '0' when there are no windows matching the given ClientPattern.
The previous check relied upon the (undocumented) return value of
XChangeProperty to determine the exit status; at least, on my gentoo system,
the function seems to return 1 even when it fails to change the property
due to contrived, and invalid, parameters. However, setting an error
handler allows proper detection of this case. So, now the return status
properly indicates whether or not the property was changed (but not
whether fluxbox liked the command!).
