Add a command-line option to the "fluxbox" binary to force it to run only as a window manager (no toolbar or other graphical widgets able to be turned on). This will help with the integration of fluxbox into other desktop environments as needed.
which parts should be considered to be not part of that mode? currently this comes to mind:
toolbar (including systemtray)
slit
open for discussion:
menus?
keybindings?
in any case: such a -wmonly flag should not override or change the regular config-resources coming from .fluxbox/init because that would change the fluxbox-setup when the user switched back to regular mode.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The toolbar definitely. I am not terribly familiar with the slit, but it sounds like another method for displaying a particular type of window (dockable apps) in particular locations on the screen. This would also possibly conflict with an application that has it's own desktop system in place, so I guess that should also be disabled then.
I would keep the keybindings in place though. Most apps have their own method for detecting keyboard shortcuts which take precedence, so the only time that the Fluxbox keyboard shortcuts would be triggered is if the event was not already swallowed by the app. This provides a nice "fallback" method for people to use across all the different desktops that might be running fluxbox underneath.
For menu's, you definitely want to keep the window menu around (since that provides control over the windows), but the root/workspace menu might not be needed (again, assuming that the desktop has it's own routines in place for the root/desktop window). Maybe this is a good option for one other CLI flag (--no-rootmenu) instead of including it within the -wm-only flag?
I was thinking that if a CLI flag is set, it simply sets an override boolian within fluxbox that causes it to skip reading certain settings values. It doesn't need to actually change the settings value - just ignore it internally.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
sllit: yep, it shows (contains) dockapps. similar to the systemtray which contains systemtray-applets.
keybindings: i don't think we should ignore certain keybindings (workspace-menu) etc when something like "-wm-only" was given: everyone and his dog assumes different things what's part of a "-wm-only" flag. i think, a flag which overrules the referenced key-file from .fluxbox/init and points to a special crafted keys-file is the better way. maybe we need an "include" statement to allow the user to have common-keybindings which are shared between the different instances she is running it and than the once that are provided by the desktop-environment to make sure the least interference with the rest of the DE.
i also would prefer -no-toolbar -no-slit -no-whatever instead of the one holy flag. we never had the situation when fluxbox was considered as "just the wm-component" of a DE, that's why no such flags exist. if the flag is set fluxbox would skip initializing the slit or the toolbar, that should come naturally.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
which parts should be considered to be not part of that mode? currently this comes to mind:
open for discussion:
in any case: such a -wmonly flag should not override or change the regular config-resources coming from .fluxbox/init because that would change the fluxbox-setup when the user switched back to regular mode.
The toolbar definitely. I am not terribly familiar with the slit, but it sounds like another method for displaying a particular type of window (dockable apps) in particular locations on the screen. This would also possibly conflict with an application that has it's own desktop system in place, so I guess that should also be disabled then.
I would keep the keybindings in place though. Most apps have their own method for detecting keyboard shortcuts which take precedence, so the only time that the Fluxbox keyboard shortcuts would be triggered is if the event was not already swallowed by the app. This provides a nice "fallback" method for people to use across all the different desktops that might be running fluxbox underneath.
For menu's, you definitely want to keep the window menu around (since that provides control over the windows), but the root/workspace menu might not be needed (again, assuming that the desktop has it's own routines in place for the root/desktop window). Maybe this is a good option for one other CLI flag (--no-rootmenu) instead of including it within the -wm-only flag?
I was thinking that if a CLI flag is set, it simply sets an override boolian within fluxbox that causes it to skip reading certain settings values. It doesn't need to actually change the settings value - just ignore it internally.
sllit: yep, it shows (contains) dockapps. similar to the systemtray which contains systemtray-applets.
keybindings: i don't think we should ignore certain keybindings (workspace-menu) etc when something like "-wm-only" was given: everyone and his dog assumes different things what's part of a "-wm-only" flag. i think, a flag which overrules the referenced key-file from .fluxbox/init and points to a special crafted keys-file is the better way. maybe we need an "include" statement to allow the user to have common-keybindings which are shared between the different instances she is running it and than the once that are provided by the desktop-environment to make sure the least interference with the rest of the DE.
i also would prefer -no-toolbar -no-slit -no-whatever instead of the one holy flag. we never had the situation when fluxbox was considered as "just the wm-component" of a DE, that's why no such flags exist. if the flag is set fluxbox would skip initializing the slit or the toolbar, that should come naturally.
http://git.fluxbox.org/fluxbox.git/commit/?id=ab2eef49371b2c9e45efea128fc84f3d556d1901
first draft, will make it into 1.3.7