I keep switching between KDE and Gnome on various boxes, just to get a feel for what each desktop system can do. One thing I dearly miss in Gnome is the capabilities of kwin to "bind" (or "tie") an application's windows to a specific workspace. I use a lot of workspaces, and some of my apps keeps littering these workspaces with windows, in particular Pidgin. This makes it easy to miss someone's important proxy server related questions, and people get cranky.

While poking around for a solution to this, I ran into this little gem of a tool called devilspie. My Fedora distribution has this packaged already, so it was just a matter of doing

# yum install devilspie gdevilspie

(gdevilspie is a GUI rule builder). Now, what does devilspie do, you ask? It can do a lot of things related to managing your X11 windows, as they are created! This seems like the perfect solution, I just need to figure out how to create a Pidgin rule, that detects everytime Pidgin creates a new instant message window, and move those to Workspace #7. I decided to use gdevilspie to create this rule, but you can do it all from command line and your favorite text editor (i.e. emacs).

Step 1: Create a new rule

Step 2: Define the matching property (or properties)

I've decided to match on the name of the application. I wasn't sure if it was "pidgin" or "Pidgin", so I clicked on the "Get" button (not showed below), and then just click on a Pidgin windows. It turns out, like many X11 apps, the application is named "Pidgin". Here's a screenshot:

Step 3: Define the actions to take

In my case, I always want to move any new windows to workspace #7, and this is easily configured in the "Actions" tab:

Step 4: Start Devilspie

( if 
( and 
( is ( application_name ) "Pidgin" )
) 
( begin 
( above )
( set_workspace 7 )
( println "match" )
)
)

I upgraded my dev box to Fedora Core 9 yesterday, which mostly worked well (except, it botched the grub boot loader, and failed to upgrade ~4GB's worth of FC6 packages). Most things went well, except the migration to PulseAudio. It ended up starting in a "broken" state, and then Gnome gets really unhappy (including any Gnome apps). Looking in syslog, I'd see

May 18 22:57:05 loki pulseaudio[2733]: main.c: Called SUID root and real-time/high-priority scheduling was
requested in the configuration. However, we lack the necessary priviliges:
May 18 22:57:05 loki pulseaudio[2733]: main.c: We are not in group 'pulse-rt' and PolicyKit refuse to grant us
priviliges. Dropping SUID again.

Adding my user to the pulse-rt group seems to have fixed this particular problem, so things are happy again. Getting Firefox and Flash to work was a whole different story, doing a number of web searches, a few suggestions to use libflashsupport. However, digging deeper, setting the environment variable FIREFOX_DSP also does the trick. E.g. something like this in your firefox startup script:

export FIREFOX_DSP="aoss"

As of a few Firefox updates ago, and/or my update to Fedora Core 6, I've had all sorts of stability problems with Firefox on my Linux system. I'm fairly certain it's related to Flash Player (v9). I've tried reinstalling everything (including Firefox and Flash), as well as completely nuking my FF profiles. Neither has helped.... I am using the proprietary nVidia drivers for my X11 server.

Looking around for something different, I ran into something that sounded similar to what my problem is. I honestly don't know what it does, but adding the following to my Firefox startup script seems to help:

export XLIB_SKIP_ARGB_VISUALS=1

Another option is to disable the "Composite" feature in your X11 (Xorg) configuration.

So, I'm obviously not a huge WIndows user, but when I write web pages etc, I obviously need to test my creations on at least Firefox and IE6/IE7. I found this little nugget somewhere (can't remember now) called ies4linux, and I have to say it worked surprisingly well.

After downloading and installing the software, I simply ran

% ies4linux --beta-install-ie7

and that was it! It does have a few dependencies, wine for a starter obviously, but also cabextract. Fortunately both of these packages are available for Fedora.

So, at some point, my X11 server in FC stopped accepting connection on the "default" TCP port, 6000. This wasn't a big deal until I started running another Linux distro in a VMWare VM (thanks VMWare for giving out free "enthusiasts" licenses a while ago!). Anywho, I did some poking around, and realized that gdm has changed it's default setting for listening on the TCP port.

I quickly edited /etc/gdm/custom.conf, and changed

DisallowTCP=false

After restarting gdm (and X11 obviously), everything is working fine again.