Looking for an alternative to the bloat of gnome-terminal? I was. I tend to use multiple terminals (I have 5 open right now) and I’m not a fan of tabbed terminals. I vaguely remembered using aterm once upon a time, so I fired it up. By default, aterm is quite ugly but uses much less resources than it’s GNOME counterpart.

Because aterm was built as an xterm replacement, it will honor Xresource settings for xterm, as well as it’s own Xresource settings. You can also customize it from the command line, which is what I did.

stone@moradin:~$ more ~/bin/aterm
/usr/bin/aterm -title ‘Terminal’ -bg black -shading 30 -fade 90 -fg #cecece -tr +sb -sr -si -sk

I’m pretty pleased with the results. I nice, clean terminal and considerably less memory usage. What more could a boy ask for?

Where does the time go?

This past week has been pretty hectic. I’ve spent most of my time working on a ‘Related Search’ engine for work. Basically, if someone searches for ‘cat’, it can suggest alternate searches, such as ‘cat food’, ‘cat toys’, ‘pet care’, etc. It’s a fairly large project — one that I’ve been working on in one shape or form for a year now. My original prototype worked with only a limited subset of data, but worked fairly well. I expect that this new and improved system will work orders of magnitude better.

It’s kind of silly the the way deadlines work. I was supposed to deliver implementation documentation before the system was assembled. I managed to delay that until, you know, we had decided on how we were going to implement it. Then there’s the actual act of deployment; it would be really nice if I had the hardware to deploy it on. Right now, it’s all running off of a single three year old development server with 512M of ram. With a database into the tens of gigabytes (and growing rapidly), this poor server is straining under the load. I just know that the question of when we can actually start selling this service and I’m going to have a minor battle on my hands to get the necessary hardware.

At least I have one thing to look forward to: five days til election day. I hope that there is a clear cut winner by the end of the day. I’m afraid of what will happen if this drags out like last year. I enjoy watching news and debating politics but there’s only so much partisan bickering I can take before I want to move to a shack in Montana and start a letter-writing campaign.

podlet: syncronization and Gnome2::VFS

I’m making good progress on podlet. I started working on the syncronization logic. There are a few important things to take into consideration before copying files to the iPod:

  • What files need to be copied?
  • Does the target have enough free space?
  • Do we need to prepare the music before copying it?

ped recursively through my music folder, I found a few non-music items that I wouldn’t want to sync. I need to figure out a way to limit what files get syncronized. I can check file extention or mime type (assuming that checking the mime type does more than look at the extension). I also want to only syncronize music formats that the iPod support.

Checking that there is enough is critical, and there should be some kind of resolution progress if I’m trying to sync more data than the device can hold. I’m considering some kind of ‘conflict resolution’ dialog, so that if I can’t copy all of the music, the user can opt to not transfer files to the iPod, or let them open the iPod browser to remove some files.

Lastly, is there any processing we need to do on the file before we transfer it. This is more of a future enhancement (once the gstreamer-perl bindings are ready). Say you have an iPod mini that you use while jogging. For this, you’re more concerned with the quantity of music, rather than the quality. This option would let you to downgrade your music to a different format/bitrate so that you can fit more on a device.

I’ve found the Gnome2::VFS call to get the free space on the device. Once I decide on how check the file type (and I’m leaning towards mime type), I can calculate the needed space and then handle resolving any conflicts.

I’m working towards a 0.10 release sometime in the next week or so. I want to get the basics of syncronization working, so that I can get a few people to test that out while I start to add the bells and whistles like the iPod browser.

podlet: auto-detection done

I finished integrating the code to auto-detect the iPod via HAL/Gnome2::VFS. I still need to test the VFS cleanup – making sure there are no leaks and whatnot. I also need to tackle automake/autoconf, or whatever it is that supplies ./configure and such. I’m not sure how I’m going to handle dependancies yet. libgnome2-vfs-perl in sid isn’t new enough. The latest version, along with Gnome 2.8, still sits in experimental.

I think for now I’ll worry about the ./configure stuff and make a note in the install file. It’s fairly easy to install the latest libgnome2-vfs-perl and it shouldn’t impact anything else on the system.

podlet: iPod detection

I finished writing the iPod auto-detection code tonight, which means i’m almost ready to move on to syncronization.

This was a fun bit of code to work on. It was my first time working with Gnome-VFS. It took a little while to get the perl binding to work. That ended up being an old version of the library in Debian. Once I installed the latest version, it worked like a charm.

stone@moradin:~/src/internal/podlet/tests$ ./
iPod detected at /dev/sda2

Essentially, it gets a list of all mounted volumes and iterates through them, checking for the existance of the iTunesDB on the volume. When it finds the file, we’ve found the iPod. I have to add a couple signals to detect insertion and removable of volumes and I can call this piece done.

podlet – preferences

I spent my lunch figuring out how to use Glade2 and Perl. Gtk2::GladeXML makes it painfully easy to integrate Glade components.

I have a big chunk of the framework in place and I’ve started attaching widgets. First on the plate is the preferences dialog. The first tab sets the stage about how we’ll recognize and communicate with the iPod. Automatic mounting, or discovery, will use DBUS and HAL to know when the iPod is attached and mounted. Manual will simply probe the mount point and wait for the iPod to be mounted. There are two supported formats – iTunes and GNUPod. GNUPod is great if you only use your iPod with Linux, but if you ever want to sync between Windows, Linux, and a Mac, stick with the iTunes format.

podlet preferences
Gtk2 pretty. Glade2 rocks.


I’ve talked about working on iPod support for Rhythmbox, and iPod support in general under Linux. I did do some work with Rhythmbox, but in the end I faltered and gave up on it. The future of Rhythmbox isn’t clear to me, and from the start I had qualms about writing application-centric support for something like the iPod. After much internal debate, I’ve decided to take a fork in the road.

I’ve been using Perl quite a bit lately. Then I discovered GNUpod. The wheels began to turn. I started to play with gtk2-perl. More cogs began to spin.

Thus was born podlet, a perl application that uses Gtk2::TrayIcon (which follows the System Tray specification). In essence, it will be a complete syncronization tool, not just for music but also contacts, calendar, and tasks (not limited to, but including this bounty).

Proposed look of podlet, sitting in the Notification Area. The icon changes based on the current status – idle, syncronizing, or disconnected.

One- and two-way syncronization of music. I use my iPod with my laptop, but I don’t want to keep a full backup of it on there. One-way syncronization would let me syncronize music to the iPod without filling my hard drive. Two-way syncronization, as you would expect, would make sure that your library on your iPod is a mirror of that on your computer.

Calendar, contact, and task syncronization should work with any application you choose to use. There will be a plugin system to support various sources for this PIM data, so you can sync your iPod with Evolution, vcards, Thunderbird, Sunbird, etc.

In the end, I think podlet will make a pretty decent little syncronization tool. I’ve thrown my work into CVS and started to hack out the core of what needs to be done. I’ve also started to play with Glade. There will be a preferences dialog to manage podlet’s settings, and possibly a druid to be run on first run to walk the user through setting up syncronization.

Automating Mozilla to create Thumbzilla

I love my job. One of my ideas got the green light a month or so back and I’ve been building it (while juggling other projects) ever since.

It wasn’t a unique idea, but it was one that would compliment our other image-related ad services: Web Thumbnails. Essentially, create a small thumbnail of a rendered website and use that as a visual representation of a link before someone clicks on it.

Something like this:

Ars Technica Ars Technica: The PC enthusiast’s resource
Ars Technica. Power users and the tools they love, without computing religion.
Oh yeah Ars Technica review: The Sims 2. Posted September – 63k – CachedSimilar pages

(Web result borrowed from Google)

Creating the actual thumbnail is not that impressive of a feat. There are dozens of ways of doing that. The real trick, in my book, is creating an automated method of doing so. No technology is worthwhile, in my opinion, of it doesn’t make some task easier.

With the help of Mozilla and Gtk2::MozEmbed, I build Thumbzilla (okay, the name is cliche and taken, but for an internal project, it works). I almost immediately ran into a pickle of a problem: Javascript. Some of the sites I was attempting to thumbnail did not want to play very well with an automated process. When I logged in to check Thumbzilla’s progress I was greeted with a slew popups, alerts, and confirmation dialogs. Nasty stuff.

Obviously, anything requiring manual intervention is a wrench in the cogworks of my project so I did a little digging. I ultimately found this:

Suppose you’re annoyed by pop-up advertisements and want to prevent all
web pages from opening new browser windows. You can do this by adding the
following line to your Mozilla user preferences file (user.js):

user_pref("", "noAccess");

Throw in a little:

user_pref("capability.policy.default.Window.prompt", "noAccess");
user_pref("capability.policy.default.Window.alert", "noAccess");
user_pref("capability.policy.default.Window.confirm", "noAccess");

and my system is now chugging along quite nicely, with some of the annoyances of Javascript disabled. It will be several weeks minimum before Thumbzilla is publicly unveiled, during which time it will get tested, poked and prodded by various people. Still, I have to say I’m quite proud of how it turned out. I think this kind of visualization could be a useful part of searching the web. Let’s just hope I’m not the only one who thinks so.