before bringing up the first instance of Fluxbox we prepare the directory
and the files it needs. if the config version of exiting files is lower
than what we expect, we upgrade the config files. after that we bring
up Fluxbox.
the old way was problematic because setupConfigFiles() calls
'fluxbox-update_configs' which does its job in the background while
fluxbox continues to boot. 'fluxbox-update_configs' sends a USR2 signal
to the booting fluxbox (it might even be finished, no one knows) which
triggers 'load_rc()' which triggered 'setupConfigFiles()' again which
might trigger 'fluxbox-update_configs' again (on my machine
'fluxbox-update_configs' was called 3 times and left a pretty crippled
'keys' file when it was done).
bootstrapping before bringing up fluxbox resolves the issue. as a bonus:
no need to send USR2 to fluxbox to reload the config file because fluxbox
has not even tried to read it yet.
our users should migrate seamlessly to our new windows-cycling behaviour
without losing their current way of doing things. so, 'fluxbox-update_configs'
tries its best to add '(workspace=[current])' wherever it looks like a valid
place for it. such changed lines are marked by '!! FBCV13' at the end and can
be easily spotted in case the updater got it wrong.
addtional changes:
* added '-check' to 'fluxbox-update_configs' to check the version number in
'~/.fluxbox/init' vs. the version number of 'fluxbox-update_configs'
* moved the update-code for each version into its own function, easier
housekeeping
