rootninja

Upgrading dependencies was not an option.

There may be a newer version of Avant Window Navigator (AWN) out that supports multiple docks across completely different displays, but I wanted to get this working in version 0.4.0 which relies upon a set of older libraries that I already have. I’m using Fedora, not Ubuntu, so I don’t know anything about PPA’s. I just took the source rpm and dove right in.

There are two ways to get multiple panels. I started with the easy method, but it didn’t support docks on different displays, so I moved onto slicing and dicing the source code to get what I wanted.

The easy way…

Multiple panels on the same display can be added quite easily if you’re willing to sacrifice a little ease of use. Bring up your trusty gconf-editor and add a “2″ to the list of panels in the gconf list:

/apps/avant-window-navigator/panels/panel_list

The default list is just a single item, “[1]“. If you make it into “[1,2]” then the next time you spawn avant-window-navigator, the 2nd panel will get created.

The big problem is you’ll need to add/remove applets and change settings by using gconf-editor or gconftool-2 directly because awn-settings has no way of differentiating between one panel and another. It will continue to function, but only affecting the original panel.

If you run multiple displays, such as a :0.1 and :0.1 for example, it doesn’t matter how many screens you set up, both panels will be on the first display. If you want to use the second display instead, add the display variable to ~/.config/autostart/awn.desktop

Exec=avant-window-navigator --display=:1.0 --startup

You can probably get away with manually setting it up once and never touching it again; show the taskmanager, maybe a widget or two and you’re done with the customizations.

For 90% of the users out there, this is probably fine, but I couldn’t figure out how to get the multiple panels setup on different displays. So….

The hard way…

This wasn’t enough for me. I need multiple panels on _different_ displays and full control of more than one panel at a time through awn-settings. Instead of trying to add the functionality to the program or beg others to add it for me, I decided to take the most straight-forward way out and duplicate the entire source code to get two binaries with two sets of awn-settings gui’s and separate trees of gconf keys.

sed / vi is your friend.

Appending a ’2′ to all occurrences of the word awn will pretty much do it. You have to be careful to not change things ilke “spawn” to “spawn2″, so the regex gets a little tricky. You don’t really need to change every instance of it, but you need to make sure anything you change is done everywhere.

I didn’t separate everything between the two code bases. I used the same applet location so installed applets would be available to all panels but I renamed them. I avoided removing the default applets, taskamanger, separator, preferences, and expander by adding a ’2′ to the end of their names too.

The safest way to do this is through a virtual machine so you can snapshot the system before installing the latest code. I’m doing this by building the rpm from source for the 1st panel, and rebuilding a copy of it and changing the name in the 2nd. Then I copied the rpm to the virtual machine and tried installing it. This way the rpm database doesn’t complain. Don’t force an overlap of any files (except for things like doc/html stuff of course, but you could just omit the documentation from the build)

Through much trial and error, I eventually got everything in the second instance of source code to create completely separate libraries and binaries.

If you find that you still can’t launch a second instance of the binary, make sure you changed the dbus namespace and path too. They are defined in awn-defines.h:

#define AWN_DBUS_NAMESPACE "org.awnproject.Awn2"
#define AWN_DBUS_PATH "/org/awnproject/Awn2"

If you don’t do a blanket find and replace for “awn”, then for any python code that imports awn, take advantage of python’s “as” to rename it in one place (per file).

import awn2 as awn

If you use anything out of extras, you’ll need to make a second copy of this too. Out of the box, other people’s applets won’t work until you reconfigure them yourself. Duplicating the schemas to use your second instance shouldn’t be too hard.

It’s a quick ‘n’ dirty pathetic hack, but it works flawlessly for me, at least until it’s time to upgrade, but then I’ll just move back to the official release version of awn.