aboutsummaryrefslogtreecommitdiff
path: root/doc/ewmh-support.gnumeric
diff options
context:
space:
mode:
authorMathias Gumz <akira at fluxbox dot org>2010-09-18 15:51:30 (GMT)
committerMathias Gumz <akira at fluxbox dot org>2010-09-18 15:51:30 (GMT)
commit0ef76292c5447127dc3fd39d6272f6d88a63d145 (patch)
tree167e28347f69bcc8db8dfc38f04a01f70f21df2b /doc/ewmh-support.gnumeric
parentc9c741c88da3cc5e74f0399c3c5c1f0e70163a7a (diff)
downloadfluxbox_paul-0ef76292c5447127dc3fd39d6272f6d88a63d145.zip
fluxbox_paul-0ef76292c5447127dc3fd39d6272f6d88a63d145.tar.bz2
changed the way we create the '~/.fluxbox' directory to avoid race conditions
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.
Diffstat (limited to 'doc/ewmh-support.gnumeric')
0 files changed, 0 insertions, 0 deletions