Probably more for my own amusement (especially in a year’s time) than for anyone else’s, and in an attempt to document the evolution of my aesthetics, I here give a summary of my own 2008, in screenshots.

The wallpapers I use for my desktops generally reflect my mood, and have some special significance for me at the time. What follows is therefore not just a collection of screenshots, but a reflection of what has been on my mind the last year. Not all the screenshots I’ve taken the past year are here. I’ve left out the odd desktops (like this one or this one) that didn’t last very long.

The screenshots are arranged per computer, roughly chronologically. Yantra is my main computer, on which I do most of my work. Grantha is the computer at my office. Mitra is the old Dell Inspiron 2500 laptop I wrote about earlier.

Most of the screenshots are of Openbox, which I started using in early 2007 (if my memory serves me well…). By the end of 2007, I discovered Pekwm and used that window manager almost exclusively for a few months in the beginning of 2008. In the summer, I started experimenting with Awesome 2.3, which became the standard window manager on one of my computers (mitra), and which I use frequently on another (yantra). All of these screenshots are of Debian or Ubuntu systems. Early in 2008, grantha still ran Windows XP, but that now runs Debian Testing (lenny). One of the early mitra screenshots may be one of Arch Linux, which I had installed on that laptop for a few weeks when I just started using it.

I’ve been using the same themes on grantha and mitra for months now (see the last screenshots for both). The themes on yantra tend to change more often, though I’ve been alternating a lot the last few months between the Children of the Earth themes and the Mythos theme.

I’ve had a lot of dark desktops this year, and have used a couple of dark Gtk themes often (Royalty, Mythos and Eidolon). It really is very pleasant on the eyes, especially at night, even if not all websites go well with it.

For all of you with a slow internet connection: know that this is quite a lengthy post, with more than 40 300×225 thumbnails!

Read the rest of this entry »

Advertisements

I finally decided to try out Awesome, the window manager all the cool kids are using. Awesome is a tiling window manager, like Wmii or Xmonad, and is very light and stable. In the past I have briefly experimented with Wmii and Xmonad, which I both liked but never found really practical for my needs. So far I’m rather liking Awesome.

My Awesome setup

There is plenty of good information available on Awesome. Shearn89‘s introduction to awesome on the Ubuntuforums, the Awesome Wiki, Calmar‘s files, and the documentation that comes with Awesome have been particularly helpful for me. I don’t intend to replicate here all of the information that those sources contain. The following only mentions (a) a few things I wanted to figure out, but didn’t find any info on, or (b) some things I did with Awesome. What follows is not meant as a guide, but just as a document explaining how I made my first slow steps with Awesome, that might be useful to others new to this window manager. Don’t expect a complete overview of Awesome, nor any revolutionary insights πŸ˜‰

I installed Awesome 2.3.1, building it from source. All of what follows works with this version. The syntax of the configuration file tends to change with every release, so some of this may not work with earlier (or later) versions of Awesome. Only Awesome 2.0 is in the Hardy Ubuntu repositories; 2.3.1 is available in Intrepid.

Though tiling is neat and sometimes handy, I find it rather inconvenient to work with most of the time. I have a small screen and mainly use applications that are best viewed full-screen (Opera, OpenOffice, Stardict, etc.). I mainly control my window manager from the keyboard, and the tiling window managers offer great keyboard control, but I also look to work with the mouse. This determined the way I configured Awesome: I limit the tiling layout as default to one of my five tags, added window decorations and a root menu, and used some more ‘traditional’ keybindings for Awesome actions (Alt-Tab to switch windows, Ctrl+Alt+arrows to move between tags, etc.).

Awesomerc

The syntax of the ~/.awesomerc file is fairly straightforward, but can easily be intimidating for new users. If you are unsure of the options you can use, have a look at the commented default ~/.awesomerc on the Wiki (or if you know French, see this helpful page).

To give you an idea of what I did with it, I have uploaded my ~/.awesomerc file. The keybindings are largely those I use in other window managers (Ctrl+Alt + left and right arrows to move workspaces/tags; Alt-Tab to switch between windows; Ctrl+Alt+r to restart the window manager; Alt+F2 for gmrun; Alt+F3 for awesome-menu/dmenu; Windows+F1-12 to launch applications; Ctrl + up and down arrows to change the volume levels; Ctrl+Alt+space to play/pause mpd, etc.)

The structure of the configuration file is relatively simple:

<section> [name]
{
<option> = <value>

<section> [name]
{
<option> = <value>

}

}

Examples of a <section> are mouse, rules, keys, screen, etc. Most sections can have subsections: statusbar, for example, is a subsection of screen, tasklist is a subsection of statusbar, and in my configuration file tasklist has a mouse subsection. You can have more than one instance of some sections: if you use two screens, you can have two screen sections, if you want more than one statusbar you can add more statusbar sections, and if you use widgets, you’ll probably use more than one iconbox or textbox. If you can use more than one section of a kind, you’ll have to specify a name for the section: thus in the default configuration file, screen is called “0”, statusbar is called “mystatusbar”, etc. Some sections, like mouse, key, rules, or layout, can only have one of its kind and therefore do not need a name, though the mouse, key, and styles sections can also be added as subsections to other sections, to govern the style and the mouse and key behaviour of those sections (thus, if you’d want awesome to do xyz when you right click on the tasklist, you would add a mouse section to the tasklist, or if you want the taglist to have a blue background when unfocused, you would add a style section to the taglist section). Examples given below might clarify this more.

<option> and <value> configure the section they are in. They can be colour settings, mouse actions, key actions, position, etc, and are sometimes unique to the section they belong to. Have a look at the default configuration file for some idea of what these can be. All the options as well as all the (sub)sections must be placed within { }. Make sure you keep that structure intact or your configuration file won’t load.

It is easy to make a typo, accidentally delete a bracket, or misplace a particular option into the file. If your configuration file contains errors, Awesome will load the default configuration file when it restarts. You can check for errors in the file before you restart Awesome with the command awesome -k.

Most of the key and mouse bindings should be straightforward: you specify the modifier key(s) and the regular key or mouse button that trigger the actions. If you want to launch applications, use the command spawn with the argument exec application_name. If you want to use Awesome actions, you use whatever action you want to use as the command, possibly with an argument (e.g. command = “tag_setlayout” arg = “+1”, to cycle forwards through the tags), as shown in the keys and mouse section further down in the configuration file). If you want to perform more than one action with a single key (or mouse) press, you’d use the following syntax (as I did with mpc and osdsh):

key { modkey = {"mod keyname"} key = "keyname" command = "spawn" arg = "exec command_one|command_two" }

Autostarting applications

Awesome doesn’t have a session manager. When you login, Awesome is launched and that is it. If you want to autostart applications, you could add them to your ~/.xinitrc, or (if you use a display manager like GDM and regularly switch between window managers) create an autostart script. I modified the Awesome.desktop file (in /usr/share/xsessions/) to load a script that is saved in my home directory, where I can easily add whatever applications I’d like to autostart.

Here is what my /usr/share/xsessions/Awesome.desktop looks like:

[Desktop Entry]
Encoding=UTF-8
Name=Awesome
Comment=Awesome window manager
Exec=/home/urukrama/.awesome/awesome_start.sh
Icon=
Type=Application

The awesome_start.sh script is a simple bash script. Here is what it looks like:

#!/bin/bash
export OOO_FORCE_DESKTOP=gnome
nitrogen --restore &
/home/urukrama/.config/osdsh/osdsh_script_awesome &
#Status bar clock & remind
/home/urukrama/.awesome/awesome-clock.sh &
/home/urukrama/.awesome/awesome-remind.sh &
thunar --daemon &
unclutter -idle 8 -root &
exec /usr/local/bin/awesome

If you decide to use a similar method, make sure both files are executable. There is more info on the awesome-clock and awesome-remind scripts below.

Statusbar and widgets

I love what you can do with Awesome’s statusbar. If you’ve visited desktop threads on the Ubuntu or Arch forums long enough you’ve probably seen plenty of screenshots of Awesome showing statistics for network traffic, battery status, cpu and memory usage, weather, disk usage, mpd, and whatnot. A lot of this is adequately documented on the Awesome Wiki, so there is no need to repeat that information here. (Besides, I don’t find all those stats either useful or aesthetically pleasing, but to each his own).

The statusbar is relatively easy to edit, once you’ve understood the ~/.awesomerc syntax. Awesome comes by default with a single statusbar, position at the top of the screen, but you can easily add more or move that to the bottom, left or right of the screen. If you want to create an additional statusbar, just create an additional statusbar section in the configuration file, and populate it with the widgets you’d like it to display. Make sure you name it differently than the current statusbar (the default is named mystatusbar)!

By default Awesome displays the following widgets on the statusbar: the taglist, layoutinfo, tasklist, and the awesome logo (an iconbox). You can move these around as you please (or remove them, or move them to a different statusbar). The widgets are displayed on the statusbar in the order that they appear in the ~/.awesomerc file.

The widgets will follow the colour and font settings of the main style (defined in the “style” section, at the beginning of the config file), unless you specify different settings for a widget. To do so, add a line like this to the widget’s section:

style { fg = "#B23308" font = "nu 8"}

This will use the fg colour as well as the font specified here, and use the defaults for everything else. If you want to change the colours of a widget that can have both focused and normal colours (like the tasklist), add something like the following:

styles
{
normal { fg = "#ECDDA6" bg = "#000000" border = "#000000" }
focus { fg = "#B23308" bg = "#000000" border = "#000000" }
}

I wanted to add only two widgets to the statusbar: a clock and a widget that displays my reminders (using the application remind). Here is how I did it.

Clock and calendar

For the clock, I modified a script found on the Wiki, which I saved as ~/.awesome/awesome-clock (and made executable with chmod +x). Whatever script you use, and wherever you save it, make sure it is always called “awesome-name_of_the_widget_in_awesomerc“. I added the following lines to the very end of the statusbar section of my ~/.awesomerc (to have the clock display in the far right of the statusbar):

textbox clock
{
align = "right"
style { fg = "#B23308" bg = "#000000" }
}

With this in Awesome’s configuration file, whenever I load the script ~/.awesome/awesome-clock, the clock will load in the taskbar, at the position the above section occurs in the configuration file. To have it load whenever I log into awesome, I added the script to my Awesome autostart script (~/.awesome/awesome-clock &).

But I wanted more than this. Wouldn’t it be neat to have a calendar built into this clock widget? Sure, and luckily there is dzen2, which I used to get a script to launch a calendar. I added the following two lines to the clock widget in my ~/.awesomerc (make sure you keep the { } structure intact!):

textbox clock
{
align = "right"
style { fg = "#B23308" bg = "#000000" }

mouse {
button = “1”
command = “spawn”
arg = “exec /home/urukrama/.scripts/dzen_calendar_awesome” }
mouse {
button = “3”
command = “spawn”
arg = “exec osmo” }
}

This launches a dzen calendar script when I left click on the clock, and Osmo when I right click on it.

My calendar script

You can add such lines (with or without a key modifier such as Shift, Mod4, etc.) to any of the widgets (you’ll see that the tasklist and the layoutinfo widgets already have some).

Remind

I use remind to show today’s events of my religious calendar, and I wanted to show those reminders in the statusbar, next to the clock. To do so, I modified the above script to display today’s reminder, saved it as ~/.awesome/awesome-remind, made it executable, created a textbox widget called “remind” before my clock widget, and added the appropriate line to my autostart script.

I also wanted to see a list of upcoming reminders when I right click on today’s reminders, and created a script with dzen2 to accomplish this. This script shows the reminders for the coming four weeks, with today’s reminder in red (this page explaining how sed works was extremely useful to get this done!). Only ten lines are shown, but you can scroll up and down in the list to view the other lines. Right clicking on the list makes it disappear.

My reminders

This is what the appropriate section in my ~/.awesomerc looks like:

textbox remind {
align = "right"
style { fg = "#ECDDA6" bg = "#000000" }
mouse
{ button = "1"
command = "spawn"
arg = "exec /home/urukrama/.scripts/dzen_remind_awesome" }
}

Layouts and Tags

Awesome has a lot of different layouts: tiled, left tiled, top tiled, bottom tiled, spiral, floating, maximized and dwindle. I don’t have any use for many of these (I only use tiled, maximized, and float), and having them all can be rather annoying if you want to quickly switch between two layouts. If you don’t want to use a particular layout, you can remove them or comment them out from the “layout” section. Only the layouts that are specified in this section will be used by awesome. You can cycle through these layouts, either by clicking the layoutinfo widget in the statusbar or by pressing Mod4+space; the order in which you cycle through them is the order specified in this section of your ~/.awesomerc.

Tags are like virtual workspaces, but better. Each tag can be set with a default layout, in the “tag” section of your ~/.awesomerc, but their uses are greater than that. Within a tag all the windows that have that tag are shown. The great part of it is that you can assign more than one tag to an application or window, so that it shows up in both tags. If you want an application to appear in more than one tag, you have to set up a rule (in the rules section). This is what it would look like if you want to thunar to show on both tag ‘one’ and ‘five’:

rule { name = "thunar" tags = "one|five" }

I’ve also configured Awesome such that if I middle click on a tag name, the currently selected window is moved to that tag. Here is the relevant portion of my ~/.awesomerc (in the taglist section of the statusbar section):

mouse { button = "3" command = "tag_toggleview" }

If you want to view the windows of all tags in a single tag, use the action tag_view (assigned to Mod4+Print in my configuration). The action tag_toggleview works similarly, but doesn’t show the applications that are on the current tag. You can undo both actions by clicking on a tag name and triggering the action you have configured to that mouse action (thus, in my setup, middle clicking will move the active window to that tag; left clicking will just move to that tag; etc.)

To have an open window appear on all tags, use either the client_tag action, or the client_toggletag action if you want to be able to easily undo it.

You can easily create new tags whenever you want, with the tag_create action. Thus the following action creates a new tag called “six”:

key { modkey = {"Mod4", "Control"} key = "F6" command = "tag_create" arg = "six" }

Root menu

I’ve been using Openbox for way too long to be comfortable now in any window manager without a root menu that pops up when I right click on the desktop. πŸ™‚

If you’d like a right-click root menu in Awesome, like you have in Openbox and Fluxbox, you can use 9menu, a component of 9wm that can be easily used with other window managers. To use it, you’ll need to create a menu file (here is mine), and launch it with the following command:

9menu -popup -bg "#000000" -fg "#F2EDD7" -font "-*-nu-*-*-*-*-*-*-*-*-*-*-*-*" -teleport -file /path/to/your/custom/9menurc

Change the bg and fg colours as well as the font to whatever you prefer. For more options with 9menu, check its man page.

To make things easier, create a script to launch this: create an empty file called 9menu_script (I keep it in ~/.awesome), add #!/bin/bash at the top of that file followed by the above command, save it, and make the script executable (chmod +x /path/to/9menu_script). (The advantage of using a script, rather than adding the command directly into your ~/.awesomerc, is that if you have multiple instances of it in your ~/.awesomerc, you will only have to change its settings once when you want to change its colours and/or font to match a different theme.)

To launch 9menu when you right click on the desktop, find the following in the mouse section of your ~/.awesomerc:

root { button = "3" command = "spawn" arg = "exec xterm" }

This launches an xterm when you right click on the desktop. Change that to this:

root { button = "3" command = "spawn" arg = "exec /path/to/your/9menu_script" }

9menu

If you’d also like to have the menu bound to Alt+F1, as some window managers have it, add the following to the keys section:

key { modkey = {"Mod1"} key = "F1" command = "spawn" arg = "exec /path/to/your/9menu_script" }

If you’d like the menu to launch from the Awesome icon on the statusbar, edit the “iconbox logo” section in the default configuration file as follows:

iconbox logo
{
image = "/usr/local/share/awesome/icons/awesome16.png"
mouse
{ button = "1"
command = "spawn"
arg = "exec /path/to/your/9menu_script" }
}

(The default launches Awesome’s man page: xterm -e man awesome).

You could also use dzen2 to create a root or panel menu (see here and here). It is a lot harder to accomplish this with dzen2 than it is with 9menu, but you can do a lot more with it: submenus, more colours, icons, etc. I tried it and had some success, but gave up as I didn’t think it worth the trouble.

Window decorations

By default, Awesome does not use window decorations, but you can easily add those. In the screen section, add something like the following:

titlebar
{
position = "top"
text_align = "left"
styles
{
normal { fg = "#ECDDA6" bg = "#000000" border = "#000000" }
focus { fg = "#B23308" bg = "#000000" border = "#000000" }
}
height = "13"
}

The position of the titlebar can be top, bottom, left or right.

If you want to disable the titlebar for some applications, or have some applications with the titlebar in a different position, you can specify that in the “rules” section: specify the application, and use the following option titlebar { position = off } (you can replace “off” with any position you’d like).

Awesome does not support buttons on the titlebar, like echinus does, but having the titlebar for some applications is handy when you are in floating mode, as it allows you to easily move windows around with the mouse. In the mouse section you can tell Awesome what to do when you press a particular mouse button on the titlebar. I make it close the window when I middle click on it, as well as toggle maximize fully, vertically and horizontally when I press Mod4 and left, middle or right click on it. Note that when you maximize a window with togglemax, it looses its window decorations until you unmaximize it again.

Awesome-menu

And finally, there is Awesome’s menu. It resembles dmenu, though it isn’t as refined: it doesn’t automatically select the first match of what you type, and doesn’t search for matches within a word (‘unar’ does not bring up ‘thunar’ for example, as it does in dmenu). Nevertheless, it is handy, and the Wiki explains some of its potential.

I initially used it, but have now gone back to the much loved dmenu.

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
(27-12-2007)
1.0.0
(08-10-2007)
3.4.7
(17-04-2008 )
0.1.6
(28-05-2007)
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

I’ve recently found a very comprehensive and informative overview of window managers for Linux: ‘The Window Manager Report’.

I’m sometimes amused by the number of persons that still direct new users of Linux for more information about window managers to Xwinman.org (where Window Maker still heads the charts as most popular window manager and Openbox or Pekwm aren’t even choices in the poll). I used to think that was the only overview of window managers available (other than Wikipedia), and was therefore very pleasantly surprised to find this excellent site.

Giles Orr, the creator of the website, gives a comprehensive table of window managers, giving a brief description, linking to its homepage, Wikipedia, and Freshmeat page (where applicable), and mentioning when the wm was last updated. You can sort the table according to your preferences (name, version number, release date, etc.).

He also provides a Bloodlines chart, showing who borrowed ideas and/or code from whom.

If that wasn’t enough, he also created a table of the memory usage of window managers, indicating how light or heavy a window manager runs as well as on how many libraries it depends. If you only want a window manager written in a particular language (C++, Python, etc.), you’ll be happy to know that he also has a page for that.

The site is regularly updated. The last update for the window manager overview was done yesterday (April 7 2008). Giles Orr started with reviews of window managers last year, but hasn’t added any lately.

This site has helped me discover some unknown window managers, as well as a few neat ‘helper applications‘ (even, or especially, if that page mentions some archaic apps). Many thanks Giles! πŸ™‚

Firebox

February 5, 2008

In my search for fun window managers to fool around with, I recently came across Firebox, a light and actively developed window manager, “something between Openbox and wmii: small, quite fast, eye candy and keyboard oriented, with some or[i]ginal features” (according to the website).

I haven’t been able to test the latest version yet (0.5), as I couldn’t meet its dependencies on my experimentation machine running Ubuntu Dapper (please don’t ask me why I use a semi-outdated OS on an experimentation machine :-)), so for now I’ve only been playing with the previous release (0.4), which is about half a year old. So far, I’m liking it a lot. Sometime soon I’ll install 0.5 on a more recent OS, as, according to the changelog, it seems to have improved substantially in features (tabbed browsing, compositing support) and performance.

So what is Firebox like? Here is a screenshot, using the default Firebox theme:

Firebox

As you can see it resembles Openbox: it has a root menu, but no taskbar, and its alt-tab and desktop switching dialog looks very much like those from Openbox 3.3. Firebox also has a nice configuration application, fbconf, which resembles Obconf. Like Openbox, the Firebox configuration is done in xml files. The website states that Firebox “is not forked from Openbox, Fluxbox, Blackbox or even Hackedbox; it is written from scratch, in C lang[u]age”, but it is clear where the developer(s) took some inspiration from.

Here is a picture of Fbconf, the configuration application of Firebox:

Fbconf

One of the neatest things about Firebox is its dmenu. Users of wmii are familiar with this: press Alt+P and a menu bar comes up containing all the installed applications; type the first letters of the application you want to launch, and it shows all the applications that start with those letters. By default the dmenu bar appears in the middle of your screen, but you can also set it to display at the top or bottom.

Firebox dmenu

You can add entries to the dmenu, both to launch applications and to perform internal Firebox actions, though I have to admit I didn’t quite understand yet how exactly this works. Unlike in wmii, Firebox’ dmenu can display icons, though by default it doesn’t do so.

As far as I could tell, the root menu can unfortunately not be configured, which makes it rather unusable, and the developer is even considering dropping it all together. The combination of the dmenu and the root menu is great, though, and I hope both continue to be developed. Firebox has some nice touches, like the window geometry which is shown in the title bar (instead of the usual pop-up) when you resize or move windows.

The documentation for Firebox is fairly decent. If its comments on the configuration seem rather brief (“Please use the preferences editor.”), that is because all the configuration can be set in the preferences editor (fbconf). The theming documentation is very elaborate, which is always a good thing. πŸ™‚

There are six themes available, but those don’t seem to work with 0.4 (they either crashed Firebox or didn’t load at all). The themes that are available are not quite along my aesthetic lines, but that is alright. The theme engine supports some pixamps. The theme options are a little confusing at first, but there are plenty of options to work with.

Firebox runs slightly lighter than Pekwm or Openbox, but the version I used, runs very slow at times, especially when you exit the dmenu or root menu. Since Firebox is still in relatively early stages of development, it is still rather limited in what it can do, and a lot of configuration options I’d like to see are still absent. Firebox 0.5 seems to have improved considerably over 0.4, the version I talk about here, and hopefully it continues to mature that way. The next release will be focused “on making the manager more keyboard oriented: tiled windows, improved keybindings and constraints.”

The occasional bugginess of the dmenu, its crashes, and the unconfigurable root menu make this release of Firebox not very suitable to work with, but I’ve developed a certain fondness for it. Sure, it crashes at times, and has a few occasional glitches, but this project has potential. If it becomes more stable and increases its functionality (keyboard bindings, more window management options, tiling windows, perhaps even a dock/slit) this will be a solid window manager. At the moment it appears to be largely a one man project (the only developer is Cyrille Bagard), but hopefully others will join and help out. Though I won’t be using Firebox as a working environment anytime soon, I’ll use it as a play ground and will keep an eye on its development. Perhaps I’ll even create a theme or two for it, just to support it in a way that I can.