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, and go back and forth, liking Openbox better for a month or two, then going back to preferring 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.
The increasingly popular LXDE window manager uses Openbox. Therefore, all of the Openbox keybindings below can also be used with LXDE. (In Fedora and Ubuntu, LXDE's xml file will be $HOME/.config/openbox/lxde-rc.xml. To change the window manager to fluxbox, and therefore, use flux's keybindings, the file to edit should be $HOME/.config/lxsession/LXDE/desktop.conf for a specific user and /etc/xdg/lxsession/LXDE/destkop.conf for all users).
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 also needs the action name=Execute as shown above, and then the <command>firefox</command>. Therefore, in most cases you need both the opening < > and the closing </ > tags. (Although I have't tested in a couple of years, this might have changed.)
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 m :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="W-t"> <action name="ToggleDecorations"/> </keybind> |
| Open Firefox | Mod4 p :Exec firefox | <keybind key="W-p"> <action name="Execute"> <command>firefox</command> </action></keybind> |
| Open an xterm and run mutt | Mod4 m :Exec xterm -e mutt | <keybind key="W-m"> <action name="Execute"> <command>xterm -e mutt</command> </action></keybind> |
In the "I should get a life," category, I once counted the difference in keystrokes between moving a window 50 pixels in both window managers. The fluxbox command was 21 characters, the openbox one 79.
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.
Since May 2008 or so, there is now a panel specifically written to work with openbox, called tint. I have come to prefer it, and its default configuration works quite well for me. If not avaiable in your distribution, it can be gotten from code.google.com. Install it and put it in autostart.sh as described above. (It is now called tint2.)
The last time I downloaded it from code.google.com, however, there was a lack of clarity in the installation instructions. The INSTALL.txt file says to make a directory build and run cmake, etc., from there. However, if one untars the source code, and then, inside that directory, makes the build directory and tries to work within said build directory, errors occur. I found that just untarring the directory, then, running the cmake, make and make install, work. So, just ignore the first two lines of instruction--if you're in the untarred directory of tint2, don't make a build directory, just run cmake, make and make install as directed.
The directions only give the dependencies for Debian and Gentoo based installations. Unfortunately, the error message just says you're missing some, but doesn't say which ones. Judging from a Fedora specfile, if building on RHEL6 or equivalent, you will need cmake, gtk2-devel, pango-devel, cairo-devel libXinerama-devel, imlib2-devel, libXdamage-devel, libXcomposite-devel libXrender-devel and libXrandr-devel. I wasn't able to get it to build on CentOS 5.x, but didn't try to solve it, as CentOS 6.x is coming out very shortly.
Tint, known as tint2, is nowadays (many years later, 2019) available in most distributions and BSDs.
All of these panels are good--though I prefer tint, I can't say that I've noticed any difference in speed, and I never bothered to check which uses more resources.
One random note. Adding a menu item to openbox is not quite that straightforward. There are dynamic and static menus, various menu makers that look at programs installed, and most things one finds when googling are aimed at using these. The wiki's instructions were unclear to me, and had no examples.
In my case, I like to use openbox with x2goclient. When I use it, my keyboard shortcuts don't work, so I wanted to add dmenu to the root menu, so that if I right click on the remote desktop, I have it handy. In the end, I edited $HOME/.config/openbox/menu.xml. It had several entries, including several <separator/> lines. After one of these, I added, (after a lot of trying, if I followed some other examples in the file, it didn't work.
<item label="dmenu">
<action name="Execute">
<command>dmenu_run</command>
</action>
</item>
<separator/>
|
Back to panels, sometimes, all I want is a clock. One can get the lal clock for a dock. It works in both openbox and in fluxbox's slit. I've found that I prefer it in fluxbox as well. In $HOME/.fluxbox/init I choose false for session.screen0.toolbar.visible, and in my .xinitrc just start off with
lal & |
(That goes above the line calling fluxbox or openbox.)
If your distribution doesn't have a package for it, it should be easy to build. Download the tarball, then
tar xvf lal-<version-number>.tar.gz cd lal make make install |
On FreeBSD, which doesn't have it as a port, you have to use gmake. On FreeBSD, before running make install, edit the Makefile and change the line that reads
cp docs/lal.1 /usr/local/share/man/man1 |
to read
cp docs/lal.1 /usr/local/man/man1 |
Its default color is white, with a width of 64 and format of hour:minute:seconds in 24 hour time, with a font size of 12. I make a few changes. This can be done in $HOME/.Xdefaults. As I have a light colored theme, making white difficult to see, I want the type to be black and bold, and I also don't want seconds. In my .Xdefaults I have
lal*color:black lal*format:%R lal*bold: true |
For the format see man(3) strftime. %R means 24 hour time format, hours and minutes. The default is %T which is hours, minutes, seconds, also in 24 hour format.
The man page gives instructions on setting the options either from the command line or in .Xdefaults. The only thing that might not be clear to the newcomer is the format of the settings in .Xdefaults. So, if we were to change every default, then .Xdefaults might have this
lal*color:black lal*format:%R lal*bold:true lal*fontsize:14 lal*width:80 lal*font:Arial |
It may be necessary to increase the width to include your desired time format.
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 |
Fluxbox has a $HOME/.fluxbox/apps file where one can choose if a particular application has decorations, if it should be visible in all workspaces, and so on. For example, at work, I want gbuffy, an email notifier, to always be in the upper left and always be visible, no matter what I might have open. I also want it on all desktops. In fluxbox, I would add the following to my $HOME/.fluxbox/apps file. I also want it without decorations.
[app] (gbuffy)
[Deco] {NONE}
[Position] (UPPERLEFT) {0,0}
[Sticky] {yes}
[Layer] {6}
|
The [Deco] {NONE}, obviously enough, means no decoration, that is, no border. The [Sticky] {yes} means that it will be visible in all workspaces. The [Layer] {6} means it will always be on top. This is explained in the man page, there are various layers, with 6 being always visible.
In OpenBox, it will be somewhat different. Rather than a separate file, it will be included in the applications section of rc.xml. As explained above, use xprop to get the name and class. In this case, the name will be gbuffy. Having no decorations was covered above, but at any rate, the entry to give the same result as the fluxbox apps file would be
<application name="gbuffy"> <decor>no</decor> <layer>above</layer> <position><x>0</x><y>0</y></position> <desktop>all</desktop> </application> |
If using a dockapp, like the previously mentioned lal, one can specify position with TopLeft, BottomLeft, BottomRight, etc. If Openbox doesn't consider it a dockapp, You might have to specify manually. X and Y at 0 is the top left. X at 0 is the far left and Y the top. On CentOS 6, if you want to change the vertical position, use the Y setting, and if you want to change the horizontal position, use the X setting. On some other systems, such as Fedora 15 (with the Noveau driver, not sure if that made a difference), this was reversed.
Recently, I've also begun using the openbox ResizeRelative option. I find it useful, at times, to resize a window. To resize a focused window 10 pixels at a time.
<keybind key="W-S-right"> <action name="ResizeRelative"><right>-10</right></action> </keybind> |
This will resize the focused window, making it 10 pixels smaller. Add a second keybinding with 10, rather than -10, and that will grow the window 10 pixels to the right. One can also use up and down to grow or decrease the window size vertically.
Fluxbox's version will also grow and shrink a window, though it seems to only grow a window down or to the right. For example, using Mod4, Shift, and the Right arrow to grow a window to the right.
Mod4 Shift Right :ResizeHorizontal 10 |
Changing it to -10 will shrink the window to the left. I find the window will grow down, with MoveVertical 10 but rather than growing up, it will only shrink towards the top of the window with -10. Same for horizontal, -10 will shrink it to the left. The key combos mentioned above for openbox work the same way.
Another one that I find handy is MoveToEdge
<keybind key="W-right"> <action name="MoveToEdge"><direction>west</direction></action> </keybind> |
That will, with the Windows key and left arrow, snap the window to the left edge of the screen. Using east, snaps the window to the right, north to the top, and south to the bottom.
With fluxbox, one has to use coordinates. To remember which is x and which is y axis, I use the mnemonic y to the sky. So, to snap to the right edge with right arrow, I use
Mod4 Shift Right :MoveTo 00 * Right |
This works with everything but the bottom edge, where one has to put the y coordinate. If, in ~/.fluxbox/init you have session.screen0 showwindowposition set to true, it will show a windo's postion if you drag it around with the mouse. For example, on one laptop, it shows it as 435, though in practice, to get it flush with the bottom, I have to make it a little more, like 460.
For example, if you have a 24 inch monitor and a setting of 1920x1080, and want something at lower left of the screen, the X setting would be 0 and the Y setting, for gbuffy, which is probably less than 50 pixels in height, might be 1030.
For those who like tiling window managers, but still like the *box managers, fluxbox has a rudimentary tiling option, ArrangeWindows. One can set a keyboard shortcut in ~/.fluxbox/keys. Openbox doesn't, as far as I know, have such an option, but there is now a third party app available, at time of writing, in the ArchLinux AUR, which will tile your windows with some reasonable defaults, and can be further configured if desired. I didn't get it to work on CentOS 5.5, but didn't try that hard, especially as CentOS 6 should be out very soon. On the other distributions where I tested it, it worked quite well. Alt+a will tile the windows and alt+u will untile them. One can grow a window with alt+l and decrease its size with alt+h.
Openbox and Fluxbox are both excellent window managers. Which one you choose is a matter of taste. For those to whom it matters, Fluxbox is written in C++ and Openbox in C, and openbox may be slightly faster. However, on modern systems, one won't notice, as they're both very light weight.