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.
- Shade - just like the "Stick"-button
Styleresources:
window.shade.pixmap, window.shade.unfocus.pixmap, window.shade.pressed.pixmap
window.unshade.pixmap, window.unshade.unfocus.pixmap, window.unshade.pressed.pixmap
etc.
- MenuIcon - click on it provides the windowmenu, if the app
contains a pixmap (gvim, konqueror etc etc) the pixmap is displayed, a
little menu otherwise.
Styleresources:
windowmenu.pixmap, windowmenu.unfocus.pixmap windowmenu.pressed.pixmap
etc.
Example ~/.fluxbox/init - entry:
session.titlebar.left: MenuIcon Stick
session.titlebar.right: Shade Minimize Maximize Close
hint: if the app HAS a pixmap i use window.title.focus.pixmap (look
WinButtonTheme for reference)in pixmap-based-styles. this looks excellent and dont need
much extra-code to pipe that info into WinButtons.
fluxbox should handle the windows. default behavior is to handle
each available screen. closes#1159809. usage:
-screen <"all"|int[,int]>
eg:
$> fluxbox -screen 0,2 will run fluxbox on 0.0 and 0.2 so
one can run any other wm on 0.1.
$> fluxbox -screen all default, fluxbox manages all screens
