I’ve figured it out! You may remember I was trying to get a Exposé-type behaviour with Skippy in Openbox: move the mouse in a screen corner and Skippy launches to show you all non-iconified windows on that workspace. Well, I’ve found a solution using Xautolock.

As the name suggests, Xautolock is meant to launch a screen locker, such as xlock, automatically when the mouse cursor is inactive in one or more of the screen corners. It can, however, easily be used to launch any type of application.

Here is how you can use it with Skippy. Add the following line to your Openbox autostart file:

xautolock -locker  "xte 'key Scroll_Lock'" -corners 0+00  -cornerdelay 1 &

This will launch xte (-locker “xte ‘key Scroll_Lock'”) when the mouse cursor has been in the upper right corner (-corners 0+00) for a full second (-cornerdelay 1). You can specify many more options; have a look at the very detailed man page for more info. Xautolock runs very light (80 kb on this computer), so it shouldn’t slow things down.

Xte comes with xautomation. It simulates a key press, in this example of the Scroll_Lock key, which is the key I use to launch Skippy. If you launch Skippy with a different key (the default is F11), make sure to change the above xte command appropriately. You obviously need to have Skippy running for this to work. Unfortunately Skippy is not in the Hardy repositories (though it was in the repos from Dapper to Gutsy), so you’ll have to build it from source.

And that’s it! Whenever you move the mouse cursor into the upper right corner Skippy will show you all non-iconified windows. Here is a picture:

This should also work in Fluxbox or other window managers. Pekwm still has issues with Skippy, unfortunately, so this won’t work as elegantly in that window manager.

As is probably clear to the reader of this blog, I mainly use two window managers: Pekwm and Openbox. Both look very differently on this computer, though. My Openbox session is dark blue and purple; my Pekwm session, on the other hand, looks orange and black.

Up until very recently, the first thing I often had to do after I logged into either sessions, was to edit the .gtkrc-2.0 file and (re)set the appropriate Gtk theme settings. I have suggested elsewhere to use both the xfce-mcs-manager and the gnome-settings-daemon to avoid clashing themes between sessions, but I prefer not to load these daemons.

Here is my current solution. First, I created two new gtkrc files that contain the Gtk settings I use in Openbox and Pekwm: ~/.gtkrc-2.0.Openbox and ~/.gtkrc-2.0.Pekwm. I then added the following line to my (auto)start file to overwrite the default ~/.gtkrc-2.0 file with the gtkrc file for Pekmw/Openbox:

For Openbox:

	cp /home/USERNAME/.gtkrc-2.0.Openbox /home/USERNAME/.gtkrc-2.0 &

For Pekwm:

	cp /home/USERNAME/.gtkrc-2.0.Pekwm /home/USERNAME/.gtkrc-2.0 &

And voilà! No more Gtk settings that conflict with the Pekwm/Openbox theme or wallpaper. This solution is probably very obvious to many, but perhaps some of you will find it helpful. This will, of course, also work if you use Openbox and a destkop environment (as separate sessions); just uncomment everything your custom Gnome/Xfce gtkrc file (as above), so that its daemon can set the themes properly.

Do you often end up with a cluttered desktop where you have several instances of the same application running? You need quick access to a particular application (often a file manager or terminal in my case) and instead of looking for the current open instance you launch a new one. After a few hours, you notice you have 4 terminals running and three Thunar windows, where one instance of each would suffice. If you often end up in a similar situation, despair no more!

Vaughn Dickson posted a very handy script on the Openbox mailing list and his wiki that either launches an application or gives it focus if it is already running.

I have modified the script a little and created a second one for Thunar. In my version, it moves the open instance of Thunar or the terminal to the current desktop (rather than moving me to the desktop where that window currently is running). You can find my Thunar script here, and my Terminal script here. If you would like to open a new Terminal/Thunar window if there is none on the current desktop, instead of moving the existing window to the current desktop, replace the last line of the script with $terminal_exec & or $thunar_exec &. Note that you need to have wmctrl installed to use this script (it should be in the repositories of most distributions).

Make the script executable (chmod +x path to the script) and assign a keybinding to it. I bound these two scripts to the keys I normally use to launch the xfce4-terminal and Thunar (Mod4+F3 and Mod4+F4). It speeds everything up enormously, since I no longer have to wait for the application to launch (or go looking for it among my open windows).

Thank you very much, Vaughn! This is a great tool :D

Judging from the search engine terms that show up in my WordPress dashboard, a lot of the visitors to this blog are searching for a comparison between either Fluxbox and Openbox, Openbox and Pekwm, or Pekwm and Openbox (search terms such as Pekwm vs. Openbox, or Openbox vs. Fluxbox are rather common).

To satisfy the desires of my dear readers, and to help those who want to know more about some window managers, I have therefore created the following table comparing four very popular window managers (or three very popular ones and one that I happen to like a lot :-)): Icewm, Fluxbox, Openbox and Pekwm.

Icewm, Fluxbox and Openbox have a wide user basis, and a very loyal following. Pekwm is a lesser known window manager that deserves more attention. I mainly use Openbox and Pekwm, and occasionally Icewm.

Please note that this table is not an indication of the most versatile, most developed or ‘best’ window manager. If a window manager lacks a feature, it may have some different strengths. Openbox, for example, does not support pixmap themes, but its theme options are the most complex and elaborate theme options of these four window managers (which makes creating themes for Openbox so much more fun!). Some features may also be primitively implemented: Pekwm supports dockapps, for instance, but its harbour is not very well developed. Nor does this chart provide an exhaustive list of features for these window manager. Icewm, for example, has a number of unique features that are not mentioned in this table (such as an email indicator and some system monitoring tools for the taskbar), and a lot of the basic features of window managers are left out.

I created the table so you could easily find out what each window manager can or cannot do. Choose whichever window manager you like best. Using one over the other doesn’t make you superior. :-)

There is a reasonable possibility that this table contains some errors. If you find any, please let me know. If I can think of more categories, I’ll add those later.

Icewm Fluxbox Openbox Pekwm
First release 1997 2001? 2002 200?
Last stable release 1.2.34
(17-04-2008 )
Language C++ C++ C C++
Based on Blackbox originally Blackbox originally aewm++
EWMH standards partial partial yes partial
Panel yes yes no no
Support for dockapps no yes (slit) yes (dock) yes (harbour)
Native wallpaper support yes yes no no
Alt-tab dialog yes (vertically and horizontally!) no yes yes
Command dialog yes (in taskbar) yes (fbrun) no yes
Xinerama support yes yes yes yes
Native (fake) transparency no yes no no
Pixmap themes yes yes no yes
Multiple workspaces yes yes yes yes
Viewports no no no yes
Add/remove workspaces no no yes no
Usable screen edges no no no (in git version) yes
Strut support no no yes no
Right-click desktop menu yes yes yes yes
Configurable client menus no no no yes
Keyboard shortcuts in menus yes yes yes no
Dynamic menus no yes yes (pipe-menus) yes
Additional custom menus no yes yes yes
Icons in menus yes yes only in client-list-menus no (only in client-list-menu of git version)
Grouping/Tabbing of windows no yes no yes
Opaque moving/resizing yes yes only resizing yes
Minimize window to tray yes no no no
Hide windows yes no no no
Tiling yes (vertically and horizontally) no no (GrowTo… actions) no (‘MaxFill’ actions)
Per-app settings yes only grouping yes yes
Configurable key bindings yes yes yes yes
Chainable keygrabber no yes yes yes
Configurable mouse behaviour Some in the preferences file yes (in keys file) yes yes
Session management/
Autostarting applications
yes yes yes yes
Confirm logout yes no yes (3.4.7) no
Shutdown/reboot control no no yes (3.4.7) no
Graphical configuration tools plenty Fluxconf, Fluxmenu Obconf, Obmenu no

Thanks to the infinite knowledge of Mikachu, I’ve finally figured out how to switch window managers while running Openbox without having to terminate any running applications. Using the Openbox ‘restart’ action, you can launch a different window manager. To do so, add the following to your menu.xml file (using Pekwm as an example):

	<item label="Pekwm"> 
	<action name="Restart"><command>Pekwm</></> 

You won’t be able to do this through Obmenu, but text files aren’t that scary. ;-)

For all you Pekwm enthusiasts: you can do the same thing easily in Pekwm using the RestartOther action ({ Actions = “RestartOther openbox” } for example). I’m not sure how that works in other window managers; you might not be able to switch back to Openbox without logging out.

During my recent stint with Firebox, and before that while I was trying out wmii, I’ve grown very quickly accustomed to dmenu. After only using it for a few hours, I fell in love with it: it is so convenient to launch an application when you don’t have your hands on the mouse; launch dmenu, just type a few letters from the application name, make sure you have the right app selected, press enter and your app shows up.

Unfortunately, Firebox is still too unstable to use as a primary window manager, and I haven’t grown accustomed to tiling window managers (yet?). So I began to wonder whether it is possible to run dmenu or something similar in Openbox and Pekwm, and – guess what? – it is very easy! (Why did I ever think otherwise?)

First, you’ll need to install dmenu. You can download the source code from the dwm/wmii website and install that (‘sudo make clean install’ in Ubuntu). To launch dmenu in Openbox and Pekwm, I use the following command:

	$(dmenu_path | dmenu -b -nb '#E0E9D0' -sb '#a6b38d' -sf '#070806')

This launches dmenu at the bottom of the screen (-b), with a colour scheme to match the Aeterna Openbox and Gtk theme. You can change the settings (everything that comes after ‘dmenu’ in the above command) to suit your preferences; read the man pages (‘man dmenu’) to see what options you have.

I have this bound to Alt+F3 in both Pekwm and Openbox (Alt+F1 launches the root menu and Alt+F2 launches gmrun). In Pekwm, I added the following to keys file:

	KeyPress = "Mod1 F3" { Actions = "Exec  $(dmenu_path | dmenu -b -nb '#E0E9D0' -sb '#a6b38d' -sf '#070806') &" }

To get dmenu to work in Openbox was a little more complex. If I added the above command to the rc.xml file dmenu wouldn’t launch (Openbox-Message: Failed to execute ‘$(dmenu_path | dmenu’)': Failed to execute child process “$(dmenu_path” (No such file or directory) say the xsessions-errors.). I’ve tried adjusting the command in several ways, but couldn’t find one that did work, so I ended up creating a script to launch dmenu in Openbox. It is very straightforward:

	exec $(dmenu_path | dmenu -b -nb '#E0E9D0' -sb '#a6b38d' -sf '#070806')

I saved the file as OBdmenu in ~/.scripts, where I keep all my scripts, made it executable (chmod +x ~/.scripts/OBdmenu), and added the following to the rc.xml file

For Openbox, this is what I added in the <keyboard> section of the rc.xml file:

    <keybind key="A-F3">
      <action name="Execute">

Here is a screenshot of dmenu running at the bottom of the screen in Openbox:


The only downside to using dmenu in this way is that the applications launched by it don’t show up with their application name in your favourite system monitor, but as the command you used to launch dmenu (OBdmenu in my Openbox session, $(dmenu_path etc. in my Pekwm session). I have no idea how to get around this, but it is only a detail. Otherwise, dmenu is fantastic. It won’t replace my right-click root menu, but it is a great addition to any window manager.

Update: As Tami points out in a comment below, you can get around this problem if you use the following command to launch dmenu:

	`dmenu_path | dmenu -b -nb '#E0E9D0' -sb '#a6b38d' -sf '#070806'` && eval “exec $exe”

In Pekwm, you can use this command in the Keys file, but in Openbox you’ll still have to use a script to launch dmenu (as explained above).

This should also work in other window managers, such as Fluxbox, or desktop environments like Xfce, though I haven’t tried it.

Frequently asked questions

January 29, 2008

I’ve added a section with some answers to frequently asked questions. These are questions that come up again and again on the Ubuntuforums or on the ‘search engine terms’ list of this blog, but that I didn’t answer (directly) in the Openbox guide. Most of these questions are also not addressed on the official Openbox FAQ. I will keep that section updated, and add to it when other questions increase in frequency.

This is just another thing I wish I had when I started exploring Openbox. Hopefully it will be helpful for all of you new Openbox users.

A new version of Openbox has just been released. Not much has changed, though. A few translations have been added or updated, a few bugs have been fixed, and a new feature has been added. You can now easily exit Openbox from the command line, with the command openbox –exit. That alone was enough for me to upgrade.

My karma is such that compiling any application that I really want always proves more cumbersome than I had expected. Something as simple as ‘./confgure, make, sudo checkinstall’ becomes much more troublesome, and I get unexpected error messages.

When I attempted to install Openbox 3.4.5 on my Dapper machine, ‘make’ told me it couldn’t find libobrender and libobparser. I remembered this had been an issue before, and I got around it with the following commands:

 sudo ln libobrender.so libobrender.so.1 
 sudo ln libobparser.so libobparser.so.1

Then I could compile the source with the usual:

 ./configure --prefix=/usr 
 sudo checkinstall

Gutsy probably won’t give as much trouble installing this version of Openbox; I’ll try that out later. If you are an Arch user, use the pkgbuild.

Perhaps this is another sign that it might be time for me to upgrade all my computers to a more recent distro ;-)

More experienced users will probably laugh at my ignorance, but I just discovered something very handy: an XML validator!

Occasionally, due to clumsiness, I mess up my rc.xml or menu.xml files. I want to add something to either of these, make some changes to the file, save it, reconfigure Openbox, and all of a sudden clicking on the desktop with any mousebutton has no effect, the window menu disappeared, I can’t switch desktops, or a part of my root menu just vanished. If I remember exactly what I added, this is easy to fix, but on several occasions it took me quite a while before I found the bad line of text. Normally the culprit is a tag that is not closed, but finding it is a pain, especially in a non-syntax-highlighting text editor like mousepad.

But I no longer need to undergo such hardships, for I have found online XML validators! Hurray! :-) If, like me, you had never heard of such a thing before, do a search for ‘xml validator’. They basically check for errors in the structure of xml documents. The one I currently use is this one (with the “Well-formedness only” checked).

Those that helped me fix errors in my xml files in the past, and found the bad code nearly instantly, suddenly seem less god-like. ;-)

Earlier I wrote about my attempts to make Pekwm behave more like the default behaviour of Openbox. I have been using Openbox for quite a while now, and I am used to have my window manager do certain things in very specific ways. Whenever I experiment with another window manager, I always try to make it do what I am used to, and my fondness for the new kid generally reflects on how successful I was at that.

This may be seen as an unfair standard of judgement (since the application might have been created precisely to do things very differently), but what I am really exploring is how customisable the application actually is. Customisability is a major feature for me, and most of the applications I like are either very strong in it (like Opera and Openbox) or are so simple that they don’t need any customisation (like Mousepad/Leafpad or docker). If I can make a window manager work like my Openbox setup even though its defaults are very different, it is a good and flexible window manager.

Sometimes, though, I see good things in other window managers and then try to replicate those in Openbox. Here are a few things I immediately liked in Pekwm and tried to apply in Openbox.

Easy resizing of windows

To resize a window in Pekwm is very convenient. You don’t have to move to the window border and (especially if these are rather small) try several times to click on the right spot. Rather, if you hold the Alt key (Mod1), right click on the window client (the main window) and drag your mouse, the window will resize in that direction. If you’ve used this feature even for just a short time, you understand how handy this is!

This configuration is default in Pekwm, and as soon as I was back in Openbox I wanted Openbox to behave likewise. This is, of course, very simple. Just add the following to the your rc.xml file, in the mouse section, under <context name=”Client”>

	<mousebind button="A-Left" action="Drag">
	   <action name="Resize"/>
	   <action name="Focus"/>
	   <action name="Raise"/>

Reconfigure Openbox, and you can resize all those Gimp, Mousepad, Terminal and Thunar windows so much smoother!

Make a window fill the screen

Apart from the ‘Maximize’ command, Pekwm has by default also a ‘Fill’ feature. If you apply this to a window it grows until it reaches either a window border or the screen edge. You can make a window fill horizontally, vertically, or both (in all directions). It is a neat feature that I find more useful than tiling (as I rarely want to see all open windows at once). I only have a need for this occasionally, but it is handy to have it around for when it is needed.

It turns out that Openbox allows you to do this as well. It is not enabled by default, but it can be easily achieved with the ‘GrowToEdge*’ actions. In true Openbox spirit, you get more options than Pekwm has. You can not just fill the window horizontally, but upwards (North), downwards (South), to the right (East) and left (West). I have set this up so that when I press the windows key and one of the arrow keys, the window will grow in that direction. Here is what I added to my rc.xml in the keyboard section:

	<keybind key="W-Left">
	   <action name="GrowToEdgeWest"/>
	<keybind key="W-Right">
	   <action name="GrowToEdgeEast"/>
	<keybind key="W-Down">
	   <action name="GrowToEdgeSouth"/>
	<keybind key="W-Up">
	   <action name="GrowToEdgeNorth"/>

This doesn’t work as smoothly as Pekwm’s ‘Fill’ command, though, as Openbox recognises


window borders, even those of windows that are in a layer far below the layer it is in. Still, it is a useful feature. If you’d like to have the window grow vertically or horizontally (in both directions) or in all directions, you can combine two or more of the above actions for a single keybind or mousebind.

(While searching for this, I also discovered Openbox has ToggleMaximizeHorz and ToggleMaximizeVert actions, which are in the default configuration bound to a right click and a middle click on the maximize button respectively. I doubt I’ll use this very often, but it is nice to know)

Kill a window with a right click

Besides a ‘Close’ command, Pekwm also has a ‘Kill’ command that can be used to kill windows that you are unable to close with ‘Close’. The command is not used in the default configuration of Pekwm except in a keychain, but some themes bind it to a right click on the close button by adding the following line to the close button settings:

	Button = "3" { Actions = "Kill" }

Openbox does not have a Kill action, but you can achieve nearly the same if you use xkill. Add the following to your rc.xml in the mouse section under <context name=”Close”>

	<mousebind button="Right" action="Click">
	  <action name="Execute">

With this setting, right clicking on the close button launches xkill. Click again with the left button and the application is killed. It requires an extra click and is not quite as elegant as Pekwm, but it does the job.


Conclusion: Openbox passed my test, once again. It is great to discover how many features it has, and though it is obvious that you can configure Openbox any way you want, doing so is always exciting and good clean fun. My Openbox setup has just become even more closely attuned to my needs and wants.

I find It also practical to have the applications I use frequently behave in the similar ways. Otherwise I keep wondering why my system is unresponsive or why application xyz no longer functions properly, or I start disliking it for totally unvalid reasons. :-) This is especially true for window managers. A window manager should have plenty of options to use and be (potentially) aesthetically pleasing, but it should remain in the background. In my world, a good window manager is one that you don’t notice, either positively or negatively, since all it has to do is manage windows, not entertain. ;-)


Get every new post delivered to your Inbox.

Join 80 other followers