snorp.net

Several people have asked for a little standalone app that uses ipod-sharp, since not everyone uses Muine and keeps all of their music on their PC. So this weekend I wrote Dopi.

Dopi, after adding the album ‘Mezmerize’

You simply DnD folders/files onto the song list there to add stuff. The delete key deletes (surprise!). To try it, you’ll need the latest ipod-sharp. It has been moved into Mono’s SVN, so if you have the stuff from baz, that is out-of-date. Also, ipod-sharp depends on libipoddevice in GNOME CVS, so you’ll need that too. And lastly, Dopi itself is in my baz archive, here.

I just committed ipod-sharp to CVS, a library for manipulating iTunesDBs. It’s written entirely in C#. Currently you can use it to add/remove songs, and manipulate any existing playlists. There is also a cheesy little tool that lists the songs/playlists in a given iTunesDB.

I mostly wrote it to add iPod syncing to Muine. I have a patch which does this, but it needs a lot of work still. I haven’t yet totally worked out how the HAL integration will happen, for instance. For starters, I patched gnome-volume-manager to mount the appropriate partition when it sees an iPod and invoke ‘muine –ipod-sync ‘. But that doesn’t cover unmounting. Also apparently you need to ‘eject’ the device for the iPod to put up the happy “ok to disconnect” screen.

You can get the code from the ‘ipod-sharp’ module in gnome CVS, or here. Hopefully I’ll get the Muine patch in a useable state soon.

Kris “released” his whir2il code today. I haven’t tried it yet, but the results he has had with it so far are very promising. PInvoke is great and all, but being able to actually compile existing C/C++ code to bytecode is just so freaking sweet.

I totally wanted to go to GUADEC, but couldn’t for various reasons (time and money, mostly). It was almost like being there, though, when I was able to make fun of Dave during his talk by proxy. Seriously. I think next year each room should have a projector showing a moderated IRC channel where people can ask questions.

Work has been going well lately, finally getting back into the groove after being pulled in different directions for a while.

Wedding plans are progressing, invitations went out last week. Really starting to hit home now

Yesterday a thunderstorm passed through. There was lightning. Apparently some of it got close enough to fry some of my electrical things. Specifically, the stereo, gamecube, and wifi AP. Also, the laptop’s AC adapter was destroyed (but I have a new one thanks to IBM and all is well).

So today at lunch I went and bought a new wifi switch. I picked up a Linksys WRT54G, the one that has open firmware. So far it rules. No, I mean it totally rules. You should run, not walk, to the nearest Best Buy (or whatever). The open firmware lets you do local dns stuff. So you can have actual dns names for the machines on your LAN. This is the feature I have wanted most in these sort of boxes, and none of them appear to have it (except for this alternative firmware, from sveasoft). Also supposedly the sveasoft firmware has other neat stuff like a VPN server.

Red Carpet

Also I’ve worked the rest of the bugs out of the yum support for rcd. I think it’s pretty solid now. It even avoids downloading the headers you already have (much like yum itself does). I should commit it soon. I know Shaver and Vlad have been using rcd on FC2, so it might be nice to get some of the yum repos that don’t also have apt ones.

I’ve been thinking about writing a tool that creates an open carpet repo out of a yum or apt one. That way apt/yum repo maintainers can just run this magical script without having to do the (relatively painless) process of setting up an open-carpet repo ‘from scratch’. I wonder if something like this would help open-carpet adoption?

Oh, I forgot to blog about this earlier, but anyone that has seen the “rcd eats 99% of my cpu” bug will be happy to know that the latest release fixes it. If you use rcd and see this bug in the latest release please report it. I promise I will hunt it down and kill it dead. Either that or I will get smart people like Tambet or Dan Winship to do it for me (who fixed it in the first place).

GNOME

A long time ago (like a year or more) I worked on some code that allowed you to migrate windows from one display/screen to another. Basically it was just some X message passing stuff that ended up calling gtk_window_set_screen(). I wrote a spec for it and posted it to wm-spec-list, but nobody really seemed that interested. I’ve started working on it again, and I think I’ll give the spec/patch another go. There is lots of badness in gtk+ with closing displays, and that sucks. Also there doesn’t seem to be an async way of opening a display, so if you try to migrate a window to someplace that’s not listening on the right port or whatever, it blocks the GUI.

I took some time today to update my wireless patches to latest GNOME CVS, and the latest development release of wireless-tools. If you would like to try it, here are instructions:

1. Get the latest wireless-applet and wireless-tools patches
2. Get the latest wireless-tools (version 27pre22) and apply iwlib_jwillcox_scanning_27pre22.diff to it, install it, etc.
3. Unpack the wireless-applets patch tarball thingy in the root of the gnome-applets tree. Apply the gnome_applets_jwillcox_wireless_v4.diff patch. Run autogen, make, etc.
4. Enjoy.

This still only works on Red Hat systems due to the usage of consolehelper. You can fix that by putting appropriate root-getting-and-essid-setting-and-renew-dhcp-lease bits for your distro in the wireless-applet-helper script.

Update:

Screenshot for those of you who haven’t seen it.