Many people go from fluxbox to openbox (and back again.) The openbox docs are excellent, and this information is in there, but this an effort to simplify things for fluxbox users.
I've seen people get into flame wars over which is better. I think it's a matter of taste. I like them both, but tend to be more comfortable with Fluxbox.
One could, I suppose, argue that Openbox follows the Unix way more closely, do one thing and do it well. I've seen people argue whether the lack of a toolbar in Openbox 3.x is a plus, showing simplicity, or a minus, something that Fluxbox has that Openbox lacks. Some folks seem to like arguments.
Fluxbox has simple keybinding syntax while Openbox uses an xml file. At present, the default is to have keybindings as part of the $HOME/.config/openbox/rc.xml file. One starts with a sample file, usually found in /etc/xdg/openbox (or /usr/local/etc/xdg/openbox in FreeBSD).
My keybinding needs are very simple. I want to be able to launch an x terminal (depending upon what system I'm using, it will either be mlterm or uxterm) and start a few applications. I want to be able to turn the decorations (the border around an application's window) on and off and to minimize a window. Lastly, one of the most important things for me is to be able to move the windows around the screen with keystrokes.
Openbox's rc.xml file requires a bit of care--if you leave a tag open, just as in html, it might cause errors with the entire file. I've sometimes had to go through through the 700 plus line file, trying to figure out where I made a mistake. It's almost always forgetting to close a tag, for example </action> or leaving off the final >.
Also note that all keybindings have to be within the <keyboard></keyboard> tags or they are ignored. Although a # can work as a comment, it's more common to use the html like <!-- --> tags. My choice of keybindings have logic to me, for various reasons. You, no doubt, have your own favorite keybindings. For example, I prefer using vi keybindings to move a window around. I use p for firefox because I created the keybindings back when it was called phoenix. If you were to replace any of my keybindings with the arrow keys, both Fluxbox and Openbox use Up, Down, Left, and Right for the different arrow names.
Fluxbox refers to the alt key as mod1 and the Windows key as Mod4. The control key is called, oddly enough, Control, and shift follows the same pattern, being called Shift. Openbox calls alt A, the Windows key W, control C, and shift S.
A fluxbox keybinding will almost always be on one line, for example
Mod4 l :MoveRight 50 |
An openbox keybinding can be written one line, for example
<keybind key="W-c"><action name="Iconify"><action></keybind> |
However, the default rc.xml file usually puts things on separate lines such as
<keybind key="W-p"> <action name="Execute"> <command>firefox</command> </action> </keybind> |
Another interesting thing is that sometimes you can make it a bit simpler. For example, typical keybinding to exit X in openbox might be
<keybind="W-q"> <action name="Exit"></action></keybind> |
<keybind="W-q"> <action name="Exit"/></keybind> |
This only works when there is nothing in between the < > and </ > tags. In other words if the syntax were
<command="firefox"></command> |
you would be able to do <command="firefox"/> and it would work. Unfortunately, that particular syntax is <command>firefox</command>. Therefore, in most cases you need both the opening < > and the closing </ > tags.
Here are some keybindings I use for Fluxbox and their Openbox equivalents.
| Action | Fluxbox | Openbox |
| Close X | Mod4 q :quit | <keybind
key="W-q"> <action name="Exit"/></keybind> |
| Open the root menu | Control Mod1 :RootMenu | <keybind key="C-A-m"> <action name="ShowMenu"> <menu>root-menu</menu> </action></keybind> |
| Move Window Up | Mod4 k :MoveUp50 | <keybind
key="W-k"> <action name="MoveRelative"> <y>-50</y> </action></keybind> |
| Move Window Down | Mod4 j :MoveDown50 | <keybind
key="W-j" <action name="MoveRelative"> <y>50</y> </action></keybind> |
| Move Window right | Mod4 l :MoveRight50 | <keybind key="W-l"> <action name="MoveRelative"> <x>50</x> </action></keybind> |
| Move Window left | Mod4 h :MoveLeft50 | <keybind key="W-h"> <action name="MoveRelative"> <x>-50</x> </action> </keybind> |
| Minimize Window | Mod4 c :Minimize | <keybind key="W-c"><action name="Iconify"/></keybind> |
| Toggle Window Decorations | Mod4 t :ToggleDecor | <keybind key="C-t"> <action name="ToggleDecorations"/> </keybind> |
| Open Firefox | Mod4 p :ExecCommand firefox | <keybind key="W-p"> <action name="Execute"> <command>firefox</command> </action></keybind> |
| Open an xterm and run mutt | Mod4 m :ExecCommand xterm -e mutt | <keybind key="W-m"> <action name="Execute"> <command>xterm -e mutt</command> </action></keybind> |
While some people like the fact that Openbox has no toolbar, others, moving to Openbox, miss it. It was apparently present in Openbox 2 but removed from Openbox 3.
There are various recommendations. One is Pypanel. Pypanel isn't in the Fedora repos but can easily be installed from source. You have to have python (which is usually installed by default, probably python-devel (which I always install, so I haven't tested this without it, python-xlib, imlib2 and imlib2-devel. Download the source code from the link above. Then untar it, cd into it and run the setup script. At time of writing it's at version 2.4. This probably won't change as its creator has said he's not developing it anymore, though he will accept patches.
tar zxvf Pypanel-2.4.tar.gz cd Pypanel-2.4 python setup.py install |
I prefer to add it to my .config/openbox/autostart.sh. However, if you just use pypanel & it might not start properly. What seems to work better is letting it sleep a bit so that Openbox is fully started. My autoshell line is
(sleep 3 && pypanel) & |
There is a configuration file, pypanelrc. If you install from a distribution that that has it as a package, it will probably be in /usr/share or /usr/local/share or similar. FreeBSD has it in /usr/local/share/pypanel. If you install from source, the default file is in the Pypanel-2.4 directory that you used once you untarred the source code.
By default, Pypanel is transparent and takes up the full width of the screen. I prefer it centered and somewhat translucent. (I'm old and the transparency can be hard on my eyes.)
There's a section for Panel Spacing and Location. I usually set the P_WIDTH to somewhere between 650 and 800, depending upon distro and monitor and the P_START at about 150. This usually gives me a centered Pypanel, but I often have to experiment.
After a discussion on bsdnexus.com's forums Roddierod from the forums patched the file. He has put it up on his pages. You can now comment out or change the default P_WIDTH and P_START lines in .pypanelrc and use percent and LEFT, RIGHT, or CENTER to align it. His page explains it, but basically, take his pypanel and replace yours with it. There's no need to rerun setup. Also, the alignment word and percentage should be in single quotes, e.g. '66%' and 'CENTER'. I know from discussions on various forums that I'm not the only one who appreciates his time and effort--but thanks Rod. :)
The fbpanel's configuration file is a bit easier, allowing you to choose a center alignment and give the width as a percent. I choose center.
The configuration file is usually put into /usr/share or /usr/local/share. Make a directory in your home directory called .fbpanel. (Note the period before the name.) Copy the config file, called default, into your $HOME/.fbpanel to override defaults.
For example, the default clock is called dclock and is blue in color. In the default file it's specified with
# Digital Clock
Plugin {
type = dclock
config {
ClockFmt = %R
TooltipFmt = %A %x
Action = xmessage Please define some command &
}
|
in the plugins section. To change it from its default of blue, you can add a line under the Action = xmessage, such as
color = black |
Just make sure you put it above the } bracket that closes the clock section. There is also a more traditional looking tclock plugin. It's a simple text clock giving the digital time. If you prefer it (and your distro has it--probably in /usr/share/fbpanel/plugins) you can change the entry shown above from tclock to dclock.
There are other panels available as well. Those are the two that I prefer, and I tend to switch back and forth between them. If there is a difference in speed or resources used, it's minimal
Going back to the two window managers in question I haven't noticed any difference in speed either--top actually showed Openbox using more resources, but on modern hardware, I don't think it's really noticeable. Many people say that they find Openbox quicker, but they seem about the same to me.
Openbox, like Fluxbox, allows you to have windows without decoration. This is covered in their FAQ. If you're already used to their syntax, it's fairly simple. Within the <applications></applications> tags, you can specify an application either by name or by class. Be careful though. The default file has a very long comment section beginning with the usual <!-- that goes on for about 100 lines, ending with -->. If, like me, you're careless and put your application configuration commands inside the comment, it will, obviously enough, be ignored.
If you have the xprop program you can determine the application name and class by, while the application is open
xprop |grep WM_CLASS |
Now, click the mouse on the application. For example, if I do it with mlterm I get
WM_CLASS(STRING) = "mlterm", "mlterm" |
In this case it's obvious. Sometimes, though, there will be things slightly different than expected. For example, running linux-opera in FreeBSD I get Opera and opera. The first one is what you use if you choose to use application name, the second is what you use if you use application class. For example, with urxvt (rxvt-unicode) I would get
WM_CLASS(STRING) = "urxvt", "URxvt" |
In most cases, it doesn't matter if you use application class or application name. In this example, taken straight from their wiki, we remove decorations on all windows
<application class="*"> <decor>no</decor></application> |
However, if you use uxterm, the xterm that handles Unicode, you will find doing xprop gives you xterm as the name and UXTerm as the class. So you would use class in the application, to make sure you don't get ordinary xterm.
Openbox processes the rc.xml file in order, meaning that if you want to override this with one application, you do it after the command above. For example, if I want urxvt to have window decorations I would put
<application name="urxvt"> <decor>yes</decor></application> |
somewhere below the class="*" line. If I put that line above the class="*" cofiguration option, it would be overridden by the "*". So if something isn't working, look for a line below it in your rc.xml file that contradicts what you want. The last one wins. Make sure it's not accidentally enclosed within a long comment section.
The mlterm program has one little oddity in Openbox, though not in Fluxbox. If my .mlterm/main file has borderless defined as true, I can't toggle the window decoration in Openbox. Even if I use my ToggleDecorations key binding, mlterm ignores it. If I comment out the borderless option in my .mlterm/main configuration file, it works as expected--I can toggle the decorations and determine whether mlterm's default is with or without a decoration in my rc.xml file.
I tend to, while playing with window managers, switch back and forth, though I always come back to fluxbox. I made a simple window choosing script that I'm almost embarrassed to put up here, but it might be useful for a novice. It keeps me from having to go back and forth to edit my .xinitrc. The below is the syntax for FreeBSD.
I would suggest backing up your current .xinitrc first, in case there's something different enough in your file to make the script break something. It just checks to see which line is not commented out, which is how it determines what will run when you type startx.
Linux users please note:
You'll see that I have sed -i ''. Those are two separate single quotes,
not a double quote. In FreeBSD, it's necessary if you're using sed with
the -i flag and don't want a backup file created.
Linux's sed is a little different. It doesn't require the two single quotes, so if using Linux, change that to sed -i without the ''.
The sed lines containing a variable ($WINMAN) use double quotes rather than the typical single quote. This is because it's the easiest way I've found to get sed to correctly interpret a variable.
Feel free to use it if you find it helpful. Please don't send me suggestions to fix or improve it, it was a quick hack that does what I want, and doesn't merit any more of my time and effort.
#!/bin/sh WINMAN=$(for i in fluxbox openbox;do grep -v "#" ~/.xinitrc|grep -o $i;done) echo "Your current Window Manager is $WINMAN. Is this OK? (y/n)" echo "" read YESNO case $YESNO in [yY][eE][sS]|[yY]) echo "Exiting now. Type startx to begin" exit;; [nN][oO]|[nN]) echo "" echo "Please choose (1/2)" echo "" echo "1.) Fluxbox" echo "" echo "2.) Openbox" read WINCHOICE case $WINCHOICE in 1) echo "using fluxbox" sed -i '' "/$WINMAN/s/^/#/" ~/.xinitrc sed -i '' '/fluxbox/s/#//' ~/.xinitrc echo "To begin your session, type startx";; 2) echo "Using Openbox" sed -i '' "/$WINMAN/s/^/#/" ~/.xinitrc sed -i '' '/openbox/s/#//' ~/.xinitrc echo "To begin your session, type startx";; esac esac |
Openbox and Fluxbox are both excellent window managers. Which one you choose is a matter of taste.