Some of you may use, have used or know of tint task manager (ttm), a simple light weight task list with a pleasant and configurable aesthetic. The project showed very little progress, until someone else (?) decided to hack on the code and come up with an improved version of the task list: tint2.

The improved version added extra configuration abilities as well as drag/drop support, but is clearly intended to be more than just a task list. The latest release, 0.6, added among other things a configurable clock, and launchers seem to be planned. Like some panels, Tint now also automatically sets a margin for it so that other windows cannot overlap it and the task list always remains visible (unfortunately, you can’t make this optional, as far as I can tell, so I cannot use 0.6 for my tabbed desktop effect…)

To install it on Ubuntu Hardy, you’ll need to install the following dependencies: libcairo2-dev libpango1.0-dev libglib2.0-dev libimlib2-dev libxinerama-dev

The configuration file is still fairly straightforward, but contains a lot of extra features over ttm. If you get lost in all the settings, you’ll be happy to know that a manual with pictures (in pdf format) is available on the tint2’s website.

If you like minimalistic configurable panels this is a project to keep an eye on. If they add a system tray and launchers, I’m sure many users will replace pypanel with tint2.

One of Openbox’ great strengths is that you can control every aspect of the window manager with your keyboard, provided you spend some time configuring your keybindings. Since I use my computer extensively to process text, I have configured Openbox such that I only need to use the mouse when I really want to, and don’t have to move away from the keyboard. It speeds things up considerably, once you are used to it!

Below I give all the keybindings I use in Openbox. Some of these keybindings I don’t use very regularly. The ones that I use extensively are those that launch applications (Win+F1-9 to launch applications, or Alt+F1-6 to launch menus or application launchers); those that control the volume (Ctrl-Up/Down) and mpc (Ctrl-Alt + other keys); those to switch windows (Alt-Tab and Win-Tab) or to switch workspace (Ctrl-Alt-Left/Right); those for basic window actions, such as close (Win-A-C), maximize (Win-A-M), iconify (Win-A-I), send to bottom (Win-A-B), etc; those to move windows in the current workspace (Win + some direction key); to move windows to the next workspace (Win-A-N) or previous workspace (Win-A-P); or to follow windows to the next (Win-A-Shift-N) or previous workspace (Win-A-Shift-P).

When I mention “(with osdsh)”, it means that the action that is performed is shown on screen with osdsh. Thus, when I reconfigure Openbox, the message “reconfiguring” on my screen, or when I turn the volume up it says “volume up”. (I know osdsh has a mixer display, but that uses a lot of CPU in Hardy!). When I mention “(with script)” in the launcher section, I launch a script to raise the application if it is already running or to open a new instance if it isn’t. The shutdown and logout keybindings (Win-O-S and Win-O-E) launch a gmessage script that gives me the option to reboot, shutdown, logout, or lock the screen.

As you will see below, I make extensive use of keychains. Keychains are great! They enable me to keep most of my keybindings fairly simple and straightforward: Win-A starts the keychain for window actions (thus ‘Win-A + C’ closes the focused window, and ‘Win-A + N moves it to the next workspace); Win-O governs all the Openbox related actions (Reconfiguring, editing the configuration files, etc.).

I have also posted my current rc.xml file, for those interested. I’m pretty sure there are some additional keybindings in that file (probably duplicate actions) that are not mentioned below; if that is the case they are keybindings I no longer use, but forgot to remove.

		#########################
		## Launchers and Menus ##
		#########################
		Alt F1		root menu
		Alt F2		gmrun
		Alt F3		dmenu
		Alt F5		dmenu for configuration files
		Alt F6		client-combined-list

		Win F1		mousepad
		Win F2		notecase
		Win F3		xfce4-terminal (script)
		Win F4		thunar (script)
		Win F5		gmpc
		Win F6		epiphany
		Win F7		ooffice writer
		Win F8		opera (script)
		Win F9		stardict
		Win F10		gedit
		Win F11		gnome-alsamixer
		Win F12		Lock screen (xlock)

		Ctrl Alt Del	htop

		#########
		## MPD ##
		#########
		Ctrl Alt space	mpc toggle (with osdsh)
		Ctlr Alt Prior	mpc next (with osdsh)
		Ctlr Alt Next	mpc previous (with osdsh)

		####################
		## Volume control ##
		####################
		Ctrl Up		Volume up (PMC) (with osdsh)
		Ctrl Down	Volume down (PMC) (with osdsh)
		Ctrl Shift Up	Volume up (Master) (with osdsh)
		Ctrl Shift Down	Volume down (Master) (with osdsh)
		Ctrl Alt End	Volume mute (with osdsh)

		####################
		## Window actions ##
		####################
		Win a		Window actions
			m	Toggle maximize full
			v	Toggle maximize vertical
			h	Toggle maximize horizontal
			i	Iconify
			c	Close
			s	Toggle Shade
			t	Toggle always on top
			b	Send to bottom
			Shift b	Toggle always below
			Shift l	Send to normal layer
			Shift d	Toggle omnipresent
			d	Toggle decorations
			l	Lower, focus to bottom, unfocus
			p	Send to previous workspace
			n	Send to next workspace
			Shift p	Follow to previous workspace
			Shift n	Follow to next workspace

			g	GrowTo
				Left	GrowToEdgeWest
				Right	GrowToEdgeEast
				Down	GrowToEdgeSouth
				Up	GrowToEdgeNorth

		Win space	Show client-menu

		#############
		## Openbox ##
		#############
		Win o		Openbox actions
			r	Reconfigure (with osdsh)
			c	Edit rc.xml
			m	Edit menu.xml
			s	Shutdown (gmessage)
			e	Exit/logout (gmessage)
			l	Lock screen (xlock)

		###############
		## Worspaces ##
		###############
		Ctrl Alt Left	Go to the workspace on the left
		Ctrl Alt Right	Go to the workspace on the right
		Alt Shift Left	Send window to the workspace on the left
		Alt Shift Right	Send window to the workspace on the right

		Win Shift F1	Send window to workspace 1
		Win Shift F2	Send window to workspace 2
		Win Shift F3	Send window to workspace 3

		Win d		Show desktop

		######################
		## Window switching ##
		######################
		Alt Tab		Next window
		Alt Shift Tab	Previous window
		Win Tab		Next window (all desktops)
		Win Shift Tab	Previous window (all desktops)

		##################
		## Move Windows ##
		##################
		Win Left	Move window left
		Win Right	Move window right
		Win Down	Move window down
		Win Up		Move window up

		Win Prior	Move window to top right corner
		Win Next	Move window to bottom right corner
		Win Home	Move window to top left corner
		Win End		Move window to bottom left corner

		####################
		## Resize Windows ##
		####################
		Alt Left	Increase left edge
		Alt Right	Increase right edge
		Alt Up		Increase top edge
		Alt Down	Increase bottom edge

		Alt Shift Left	Decrease right edge
		Alt Shift Right	Decrease left edge
		Alt Shift  Up	Decrease bottom edge
		Alt Shift Down	Decrease top edge

		Alt F12		Toggle fullscreen

		Ctrl Alt d	Toggle autohide dock
		

K.Mandla has already written about my “tabbed desktop”. Here is a little more information:

To create the effect of a ‘tabbed’ desktop, I have been running tint2 at the top of my screen, covering the window decorations. With the right colour and size settings, you can easily create the appearance of a tabbed desktop.

Two things make this method somewhat practical: First of all, I run most of my applications maximized; smaller, ‘floating’ windows somewhat destroy the tabbed feel of the desktop. Secondly, since tint covers the window decorations and makes it thus unable to close, iconify or shade the window, make it sticky, or send it to another desktop, you should be able to perform these actions with the keyboard, through keybindings.

Since K.Mandla’s post, I’ve made a small adjustment to the desktop: I added a clock and remind to my top task bar, using dzen2 (I initially also had a volume bar in it, but dropped that). My dmenu scripts also load in that exact area, using the same colour settings and covering both tint and dzen.

If you’re interested, this is my dzen2 script, and this is my tintrc. The Openbox and Gtk theme I use is Bygone (somewhat modified).

I’m not entirely sure why you’d want to use this, but it does get asked from time to time: How can you use a different Gtk theme, icon theme and/or fonts for specific Gtk applications?

If you just want to change the Gtk theme, you can launch your application with the following command:

	GTK2_RC_FILES=/path/to/your/theme/gtkrc application-command

Thus “GTK2_RC_FILES=/home/urukrama/.themes/royalty/gtkr-2.0/gtkrc thunar” will use the Royalty theme for Thunar. Note that this will use the default font and icon theme, not the icon theme or font you specified in your ~/.gtkrc-2.0 or ~/.gtkrc.mine file.

If you’d also like to set a custom icon theme and font for the application, create an empty file, wherever you find convenient (for example in /home/USERNAME/.themes) and call it whatever you want (for example, custom.gtkrc). Then add the following to that file:

		#To set the Gtk theme
		include "/path/to/your/theme/gtkrc"

		#To set the icon theme
		gtk-icon-theme-name = "GnomeCorsair"

		#To set the font
		style "Sans"
		{
		font_name = "Sans 8"
		}
		widget_class "*" style "Sans"
		gtk-font-name = "Sans 8"

Change ‘GnomeCorsair’ to the icon theme you’d like to use, and “Sans” to the font you prefer. The /path/to/your/theme/gtkrc is what it says (for example /home/urukrama/.themes/royalty/gtkr-2.0/gtkrc). If you would only like to have a custom icon theme or font, only specify those and leave the rest out.

To launch Thunar with these settings, use the following command (If you saved the file elsewhere, adjust the path accordingly):

	GTK2_RC_FILES=/home/USERNAME/.themes/custom.gtkrc thunar

If you want to use this in a launcher such as Openbox’ menu, rather than the terminal, try the following:

	bash -c 'GTK2_RC_FILES=/path/to/your/gtkrc application-command'

I haven’t managed to get this working with either the gnome-settings-daemon or the xfce-mcs-manager running. It seems they override this.

As proof that this works, here is a screenshot of two instances of Mousepad running, one using the default theme, the other launched with a custom gtkrc:

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.

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.

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.

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" }

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.

Inspired by this, I created a dmenu script that gives me easy access to my most used configuration files (Openbox’ rc.xml and menu.xml, conkyrc, gtkrc-2.0, etc.). The script is entirely based on my source of inspiration; the only ’substantial’ thing I did (apart from creating all the necessary aliases) was to make it window manager independent and remove the Awesome components. The script is probably quite rough, and the same could perhaps have been accomplished in a simpler and more elegant way, but it works.

If you want to give it a try, download the script, saved it in a safe location (like ~/.scripts), make it executable (chmod +x ~/.scripts/config_dmenu_script), and map it to a keybinding in your window manager (I use Alt+F5).

You will need to adjust the script to be able to use it. All the aliases direct dmenu to the location of these configuration files on my computer; they won’t be located in the same place on yours (unless you are also named urukrama ). I use mousepad as my default text editor; replace it with whatever text editor you prefer. You can also adjust dmenu’s settings (colours, font, position, etc.) on line 45.

Judging from the screenshots that are posted on the Ubuntuforums and the Arch Linux forums, Pypanel is probably the most popular panels among Openbox users. Pypanel is no longer developed, and the latest version of Pypanel (2.4) is from 2005 (though a few patches have appeared recently; see here, here, and here). It doesn’t offer nearly as many features as some of the other panels, and doesn’t have any graphical tools to change its preferences. But its simple aesthetics and lightness have captured the attention of many (including me).

Configuring Pypanel is relatively easy: it all takes place in a single file, ~/.pypanelrc. Most of the settings in that configuration file should be fairly straightforward, and the default is well explained. You can specify the colours, fonts, looks, the size and position of the panel, set application launchers, modify the clock, etc. Restart Pypanel and the changes will be visible.

What many users don’t know, however, is that the clock and desktop sections of the panel can also be configured (beyond how they look). You can specify a number of actions that are performed when you perform a mouse action on it (left/right/middle click, scroll up and down). The default actions involve changing workspaces or iconifying all open windowns and showing the desktop. The type of actions Pypanel can perform, as well as the codes for the various mouse actions are specified towards the end of the pypanelrc file, under “Button Event Function Definitions”. But there is more to it than specified there.

The actions are of the following syntax: two letters, signifying the type of action that follows, followed by a dot, and the action name. pp stands for a Pypanel action; os (presumably) for an operating system action (e.g. pp.showDesktop()). The internal Pypanel actions are those specified in the default configuration file. They are actions like focusing a window, raising a window, minimizing it, changing the workspace, hiding the panel, and so on. Note that the showDesktop() action only works if your window manager supports minimizing all applications at once; the action will, for example, not work in Pekwm. The os actions can be used to launch applications. If you don’t want to specify an action you can use the command pass.

Here are a few examples. Below is the clock section of my current pypanelrc. Left-clicking on the clock launches a dzen2 script (modified from this) that displays a calendar; right-clicking on it launches Osmo, a personal organizer.

#--------------------------------
def clockButtonEvent(pp, button):
#--------------------------------
    """ Button event handler for the panel's clock object """

    if button == 1:
        os.system("/home/urukrama/.scripts/dzen_calendar &")
    elif button == 2:
        pass
    elif button == 3:
        os.system("osmo &")
    elif button == 4:
        pp.showDesktop()
    elif button == 5:
        pp.showDesktop()

Here is a screenshot of the dzen2 calendar (the pager on the right to Pypanel is netwmpager):

Similarly, the desktop area of the panel can also be used to trigger certain actions. You can, for example, use that area to launch an applications menu. If you’d like to use the menu of your window manager, you can use xte or xdotool to launch it. Alternatively, you could use something like Tabble (without the window decorations), or Apwal for a drawer-like effect.

Over the last few weeks, I have slowly been updating the Openbox guide. Openbox 3.4.7 has been out for a little while now, and Ubuntu Hardy was also recently released. I needed to update a few sections of the guide (mainly those covering the installation of Openbox, Obconf and Obmenu, and the shutdown/reboot section). The Openbox FAQ has been changed a little as well.

But this new version of the guide is more than just an update. I have thoroughly revised the entire guide, rewritten some parts of it, and added a lot of new material. So what has changed?

First of all, it has a table of contents now , which should make navigation easier and give the reader a better grasp of what areas the guide covers.

I have added a lot of new material to it: I have enlarged the sections on panels, docks, system trays, pagers and clocks. The list of ‘useful applications’ at the end of the guide is now much longer (it now contains eleven applications, whereas the old one contained three). I have tried to give KDE/Qt applications more attention, and included a section on how to deal with Qt themes in Openbox. The guide contains more information about font configuration and mouse cursor themes.

I have tried to clarify and explain the commands and applications more, hopefully making it more accessible and educational for persons relatively new to Linux and/or window managers. I have also added a lot more links to external sources of information, project websites and howtos/guides.

Here are some statistics:

The old guide contained 7275 words; the new version of the guide has 9343 words (2068 words more). The old version had 90 links to external sites, the new version has 159 links (69 links more).

The old guide was completed on 26 November 2007, and revised on 22 January 2008 (some minor changes were made in between and since then). Since it was posted, the Openbox guide has received 14,218 views (13,302 and 916 before it was moved to its own page). That is an rough average of 78 persons a day. Not the most frequented website in the world, but a lot more than I thought I would get when I wrote that guide. The entire blog has had 25,968 people over, so more than half of the views were for the guide. ‘(An) Openbox guide’ is the second most common search term that lead people to my blog (297; the first place is occupied by ‘dmenu‘ with 304 hits — it seems there isn’t that much information about dmenu available on the internet…).

Here is a picture of the stats for this blog:

And here is one for the Openbox guide alone:

Writing and maintaining the Openbox guide sometimes forces me to venture into areas I would normally not go: I don’t like docks, for example, but have tried some of them out so I could write about them. I no longer use xcompmgr and transset, but need to know how to use it as my of the readers of the guide are interested in it. I need to download, compile and install a lot of applications. One of my computers is (not exclusively) used for that. It started with a slim command-line Ubuntu Hardy install, and has now well over a thousand packages installed! I do discover a lot of interesting applications this way, though — especially old(er) ones, many of which are no longer developed, but are still handy, interesting and/or fun.

So that’s it. Go and have a look at the new guide I hope you find it useful. If you have any suggestions for improvements, or find some grave, less-grave or not-very-grave errors in the guide, please let me know. I love feedback.

The artwiz fonts, a set of bitmapped ‘futuristic’ fonts, are no longer in Ubuntu’s (Hardy’s) repositories. But don’t despair! Though installing these fonts is no longer as easy as apt-getting it, installing them manually isn’t that hard.

Download the fonts from this Sourceforge page. These are the ‘improved artwiz fonts’ that should work in Gtk2 and KDE3 applications. Once you reach the download page, you’ll see there are three versions available: German (de), English (en) and Swedish (se). These are basically the same fonts, but with different language encoding support (think ü, ö, etc.). You’ll only need one of them; pick the one you like.

If you want full ISO-8859-1 support, you can also use the artwiz latin1 fonts.

Extract the archive and move the extracted folder to /usr/share/fonts/X11/misc (the examples below use the English (en) font set)

	tar xvjf artwiz-aleczapka-en-1.3.tar.bz2
	sudo mv artwiz-aleczapka-en-1.3 /usr/share/fonts/X11/misc

Renew your font cache:

	sudo fc-cache -f -v

Reconfigure your fontconfig settings:

	sudo dpkg-reconfigure fontconfig

Enable the use of bitmapped fonts:

	sudo dpkg-reconfigure fontconfig-config

Answer the questions as follows. First select the font tuning method (I chose Native):

Set the subpixel rendering of the fonts to ‘Automatic’:

And finally, enable bitmapped fonts:

Once you have restarted X, you should be able to use the artwiz fonts in your Gtk, Qt and Openbox settings.

If you want to use the artwiz fonts in conky, you no longer have to disable xft. To display conky with the artwiz font snap, use the following settings:

	use_xft yes
	font snap-7

Finally, if you want the artwiz fonts to also show up in xfontsel, specify the path to your artwiz fonts in the “Files” section of your /etc/X11/xorg.conf. Here is what that section looks like on this computer:

	Section "Files"
		        FontPath        "/usr/share/fonts/X11/75dpi"
		        FontPath        "/usr/share/fonts/X11/util"
		        FontPath        "/usr/share/fonts/X11/100dpi"
		        FontPath        "/usr/share/fonts/X11/100dpi/:unscaled"
		        FontPath        "/usr/share/fonts/X11/75dpi/:unscaled"
		        FontPath        "/usr/share/fonts/X11/Type1"
		        FontPath	  "/usr/share/fonts/X11/misc/artwiz-aleczapka-en-1.3/"
	EndSection

Restart X, and you should be able to select them in xfontsel.

Thanks to Ubuntugeek and the Ubuntu Wiki.

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.