The DF Lab

At the end of 2007, Google did a wonderful thing and added AIM to their built-in chat in Gmail. This was an awesome convenience, since I could now chat with both my used protocols right from my email window. Not to mention I got a nice consolidation of my chat logs accessible from anywhere to boot. Of course, I was leaving all the conveniences of my desktop client behind, such as not being dependent on my browser window to chat. But it seemed all worthwhile, since I usually had a browser window open anyway, and I didn’t have a ton of spare resources (RAM, screen real estate) on my laptop, my sole machine.

Now I’m in the situation where I want to go back to the desktop client. I’ve got a nice new computer with lots of RAM and lots of screen real estate. But I’m now slightly dismayed, because my wonderfully accessible chat logs are now no longer going to be “all” with my mail. I say “all” because before a certain point they weren’t, but from that point on, I was golden. Now, if I switch back, I’ll have all my logs to a certain point on my computer, then a bunch in “the cloud,” and then most of them on my desktop, and some in my browser, for when I’m away from my computer. Not ideal.

What I really want it some “neutral” location for my logs that both the Gmail client and my desktop application (currently Pidgin) will respect and send their logs to. I’ve got web space out there, so I’ve got a location, but how to make it work? One way I could think of is to run something like a Greasemonkey script which keeps track of what it’s sent over time (so when I come back to the computer it’s installed on, it sends the new conversations) and sends new conversations off periodically. So that could be done with Greasemonkey, or with a Firefox Plugin. A modification to Pidgin sounds relatively trivial to me at this point, at least compared to writing a Firefox plugin. In any case, I’m going to ponder this… Any thoughts on the matter, technical or otherwise, are welcome.

Uncategorized

This evening, with a few helpful suggestions on IRC at #gnome-do on freenode, I was able to work around (but not solve) an issue I’ve been having with Gnome Do, the Quicksilver-like launcher for GNOME.

My issue was as follows: every time the program started up on GNOME session start, it would revert to an unfashionable theme that I didn’t want. The configuration showed that it was on the Glass theme, as I wanted, but it was clearly not. Every time I ran the program otherwise, it would successfully take on the appropriate theme.

Long story short, it turns out the issue is likely related to compiz not being fully started yet, so it defaults to its non-pretty theme. I first wrote a script that waits for compiz to start then runs, but the process “compiz” existing was not good enough. So I created a 3-line script to delay Gnome Do’s startup by 2 seconds, and it works:

#!/bin/bash
sleep 2
gnome-do

Heck, this could be a one-liner, but whatever. I actually tried to use GNOME’s built-in session manager to invoke the sleep, but it didn’t work out for me at first and I didn’t feel like trying again, so this works just fine.

Uncategorized

This is just a small tidbit, in good part for my own future reference, on what I’ve been spending the last number of hours figuring out. I’ve actually done a lot of configuration of my new Gentoo install I wish I’d documented now, but alas, it’s too late.

In any case, I have two hard drives in this machine, and none of them were mounting automatically on my shiny new GNOME desktop. I thought it was a problem with NTFS, then with the gnome-volume-manager. I spent a bunch of time verifying I had the right drivers (ntfs-3g) and the latest software installed. Turns out I found my solution in an unlikely place: the Arch Linux wiki. Anywho, the fix was to change around some policy setting. A one-liner fix, as so many of them seem to be in the end. *sigh*

In order to make this experience even more exciting, I decided I’d try and use the same file and configurations to have HAL ignore /dev/sda1, which is my Acer recovery partition. I don’t particularly want to see that from Linux, and I certainly don’t want to mount it in case I accidentally end up doing something horrible to it. I came across this blog post, and adapted its instructions like so (for the file /etc/hal/fdi/policy/10-ntfs3g.fdi) by adding the following section:

<device>
<match key="block.device" string="/dev/sda1">
<merge key="volume.ignore" type="bool">true</merge>
</match>
</device>

Much to my surprise, it worked! (after I changed my bleary-eyed mistake of “/dev/hda” to “/dev/sda1″ ).

I probably should make a point of posting some more of these gems, and where I found their solutions. If it takes me more than 20 minutes to find them, it can’t be all that easy to find. In any case, I’d say this is a job well done!

Uncategorized