One of the great features of Pekwm is the ability to use the screen edges. Just like the desktop, you can click on the screen edges to perform certain actions. In the default settings, right clicking on the screen edges brings up your root menu, middle click on it and you see your client menu, left click on it and you will switch to the next workspace in that direction.

The beauty of the screen edges is that, unlike the desktop, they remain available when you have maximize windows or windows in full-screen mode. This means you can still use the mouse to call up the root menu (without setting a margin, as you would in Openbox), or perform other actions. I really hope this is implemented in one of the future releases of Openbox (and hope any of the Openbox devs is reading this! :-)).

Earlier I have written about how you can use the screen edges to semi-autohide the harbour, but their potential is much greater. I will describe two examples here, and hint at a few more uses .


Tilda is drop down terminal. Though I rarely use it myself, it is a handy app if use the terminal regularly, but don’t want to switch to the open terminal whenever you need it: Just press a key (F1 by default) and your terminal window drops down from the top of the screen.

Tilda only appears with a keypress, though, so you’ll have to translate or simulate the keypress with a command. After much searching and asking, I finally found several ways of doing this. The easiest is by using xautomation. First install the application:

	sudo aptitude install xautomation

Xautomation allows you to control X from the command line, and consists of several applications. The one you will need here is xte, which generates fake mouse or key inputs. To have F1 pressed and released, you would use the following straightforward command:

	xte "key F1"

(A more complex way of doing this is by using xmacro as explained here)

Now you will have to bind this to a mouse action on a screen edge. Since Tilda is a drop down terminal, I prefer the upper edge (‘Up’) and add the following line to my mouse file (in ~/.pekwm) in the ScreenEdge Up section:

	ButtonRelease = "1" { Actions = "Exec xte 'key F1'" }

Reload Pekwm and whenever you left click on the top screen edge, Tilda will appear (provided Tilda is running obviously). If you would like Tilda to appear whenever the mouse moves over the top screen, use the following line:

	Enter = "Any Any" { Actions = "Exec xte 'key F2'" }


The real reason I started playing with Pekwm’s screen edges was to play with one of my much-loved applications: skippy, a full screen task switcher

I wanted to see if I could create a Mac exposé-type effect: if I move my mouse in a particular corner of the desktop, skippy automatically launches and I get a miniature version of all open applications on my screen.

Using Pekwm’s screen edges and xte, this is fairly easy to achieve, were it not that skippy doesn’t actually work like it is supposed to in Pekwm. Skippy launches fine, but remains under the open applications. I’ve tried several things, and the only workaround I have now is to raise the skippy window with wmctrl, but even that is problematic.

If you haven’t done so already, install wmctrl first (sudo aptitude install wmctrl). You now need to get the id for the skippy window. To do this, launch skippy as usual and keep the window miniature windows open. In a terminal type “wmctrl -l” and you will get an overview of all running windows, like this:

	0x02a00001 -1    N/A N/A 
	0x01e00004  0 yantra Blank page 
	0x01a00003  0 yantra urukrama - File Manager 
	0x0240001e  0 yantra Terminal 
	0x01800002  0 yantra [pekwm-users] Skippy and Pekwm 0.1.6 - Opera 
	0x01600003  1 yantra System Monitor 
	0x00c00003 -1 yantra panel 
	0x01000001 -1    N/A netwmpager

The first column contains the window identity as a hexadecimal integer, the second the desktop number (-1 is a sticky window), the third contains the name of your computer, and the final column shows the window title. In the above list, Skippy is the first entry (where the title is given as N/A). You will need the window id of this (in this case 0x02a00001) to raise skippy automatically to the top whenever it is launched. Then open your ~/.pekwm/mouse file and add the following lines to the ScreenEdge section (choose whichever screen edge you prefer; I add it to the right one):

	ButtonPress = "2" { Actions = "Exec xte 'key Scroll_Lock'" } 
	ButtonRelease = "2" { Actions = "Exec sleep 1 && wmctrl -i -r 0x02a00001 -b add,above" }

I have configured skippy to launch when I press Scroll_Lock, so these settings will launch skippy whenever I middle click on the (right) screen edge. Replace Scroll_Lock with whatever key you have bound to skippy. The second line is used to make wmctrl raise the skippy window to the top a second after it is launched.

There are several important disadvantages of this workaround. First of all, skippy’s id changes with every session, which means you’ll have to edit the above entry at the beginning of every session. The second downside is that skippy won’t be raised if it first needs to take a snapshot of all open windows, as that takes more than a second. In such a situation, you’ll need to launch skippy twice.

Despite its limitations, I think this is rather neat 🙂 I am not sure who is to blame here – Pekwm or skippy – but I hope it is Pekwm because that would increase the chances that this problem gets fixed (skippy is no longer developed). If you know of a simpler way to go around this problem (or how to solve it!) please let me know.

Other uses

The potential of the screen edges is great, as you’ve probably guessed by now. Though the mouse has only a few buttons, you can combine those with modifier keys (Ctrl, Alt, Mod4), which gives you a few more options to use on the four screen edges you can play with.

Here are a few more ideas: use the screen edges to launch osdsh to display the time (osdctl -t 4), or the state of your laptop battery (osdctl -b “Battery Power”,$(acpi|cut -d “,” -f2|cut -d “%” -f1|cut -d ” ” -f2)), launch an application launcher like apwal, hide panels or taskbars like visibilty or tint that don’t support hiding (this will be a bit slower, no doubt, but it works), tile windows with tile, etc.


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.


January 22, 2008

I’ve updated the Openbox guide. Don’t get all excited, though. Nothing shocking or ground breaking has been added. I’ve just cleaned up some bad code, added quite a number of links, added a section on pagers, did some light editing of the text, and removed some of the typos.

I’ve also added a Screenshots section to this blog. It is a collection of the desktops I am most fond of and return to regularly. This will be a record of my ‘weird’ aesthetics (dixit el mariachi).

A simple Pekwm guide

January 10, 2008

I have posted a simple guide to install and configure Pekwm on the Ubuntuforums.

Don’t expect anything extraordinary. I only tried to help those new to Pekwm to install the latest stable version and give them some hints of what Pekwm can do. If you know the official documentation of Pekwm, this little guide will not contain anything new for you.

I’m in the mood to post a picture, so here is the Pekwm howto in Epiphany, with the black ubuntuforums userstyle:

Free Image Hosting at

Hopefully this will create some more interest in Pekwm among Ubuntu users, so that when I run into problems, there is someone to help me 😉 .

If you have any feedback on the guide, I am, as usual, very happy to hear from you.

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 
 sudo ln

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. 😉

One of the nice features of Pekwm is that it allows you to use dynamic menus, menus and entries that display the output of a script that is run each time the menu is accessed. Here is how you can display the time and date in your root menu (or window menu, if you’d like that). I’ve adapted what follows from here.

Create a new file in a place that is convenient for you. (I keep such dynamic menus in a subdirectory called “menu” in the ~/.pekwm directory.) Add the following to that file:

echo "Dynamic {"
echo " Entry = \"`date +'%a, %e %B - %H:%M'`\" { Actions = \"Exec osmo & \" } "
echo " }"

Make the script executable (chmod +x /path/to/script), and add the following to your menu file (in ~/.pekwm):

Entry = "" { Actions = "Dynamic  /path/to/the/script"}

If you reload Pekwm, you will have a menu item that displays the time and date. If you click on the time and date, Osmo, a nice light calendar, todo list and contact management application, will launch. Replace it in the above command with any other application you like (Orage, dzen with a calendar script, etc.). If you prefer not to have any application linked to the entry, use the following line in the above script (instead of line 3):

echo " Entry = \" `date +'%d.%m.%y - %H:%M'`\" { Actions = \"Exec source /dev/null & \" } "

If you want the date and time to display in its owm submenu, add the following to your menu file:

Submenu = "Date and Time" {
	Entry = "" { Actions = "Dynamic  /path/to/the/script"}

You can also easily change the date and time format to your liking. Below are two screenshots; the first shows the date and time on the main menu with the command `date +’%d.%m.%y – %H:%M’`, the second shows it in a submenu with the command `date +’%a, %e %B – %H:%M’`.

Pekwm time and date