Here my unsed desktop's mouse and keyboard are plugged into the USB dongle, which through the magic of the kernel 2.6 input layer Just Works without any action at all.

When I want to use the desktop -- a monthly event generally -- I can just whip the USB adaptor from the laptop and plug it into the desktop. Then I can watch Windows XP fail miserably to handle hardware changing between reboots. It appears that although Windows managed to handle the keyboard moving from PS/2 to USB, it refused to acknowledge that the mouse wasn't plugged into the PS/2 port still.. I had to figure out the keyboard navigation for the login screen and then remove/insert the mouse again. Not a great pain, but I bet that will catch out some normal users.

Anyway, the iCurve totally rocks and is a great example of design via simplicity: it's just a curved piece of plastic but the laptop sits firmly on it. I recommend it to everyone who uses a laptop all day.

NP: Hold Your Colour, Pendulum

Well, things have come on a long way since then:

Now it's peaking at just under 400Kb! The 200Kb chunk is the Berkeley DB cache for my addressbook, and the size of that is tunable. After that come add_module and add_alias from libc's gconv implementation of iconv. Now I'm pretty sure the data they are loading should be made constant and shared among all processes. Anybody know of existing work in this area?

NP: Fear Of Fours, Lamb

• Add Set Geometry (Guido Boehm)
• Fix Set Window Type (Stefan van der Haven)
• Make Pin work as expected (Jean-Yves Lefort)
• Append new expressions, not prepend (Lars Damerow)
• Fix typos in README (Larry Virden)

Downloads are in the usual place.

Obviously make a copy of any contacts you'll send and replace any sensitive information (change all phone numbers to 1234, all addresses to Foo Bar Street, etc). As this has to test as many corner cases as possible vCards with entirely ASCII values produced by Evolution are pretty boring. Instead I'd like:

• Cards using non-ASCII locales. Finnish, Russian, Hindi, Korean, etc are all welcomed.
• Cards produced by programs other than Evolution. Even if you don't actually use an Apple, importing a few contacts from Evolutoin into the OS X address book and then exporting them again would be good.
• Bizarre fields actually being used. I'd like to see real-world cards using the linked (instead of embedded) photos, complicated use of the TYPE fields with custom entries, etc. Note that cards from Evolution don't count here, I can produce those easily.

Thanks! Email any vCards you have to me, although you must agree that they'll hopefully end up being distributed with evolution-data-server under the LGPL.

NP: Dreamland, Madeleine Peyroux

Jeff is correct and if I'd thought about it at the time I'd have realised that g-v-m is only responding to the "new media" signal from HAL, which has to wait for the drive to spin up. One idea is that maybe HAL should emit a pre-device-added signal so that g-v-m can pop up a notification area icon saying that something has been inserted and it's being probed.

However I'm not a great fan of Christian's proposal. Personally I'd prefer we invented some MIME types, i.e. application/x-device-cdda for "can play audio CDs" and g-v-m can then display lists of applications based on the MIME type keys, and also use the startup notification information in the .desktop files.

So. Someone puts in a CD. A while later, although there's no indication something is happening, sound-juicer pops up.

This is a bug in gnome-volume-manager: it doesn't give you any feedback that it is probing the new media, or starting Sound Juicer. I think a notification area icon for "new media inserted" would be good whilst it probes, and then the standard startup notification animation/panel entry when it starts up Sound Juicer.

1. The process of getting tracks from wherever blocks the rest of the UI. I should be able to play while this is happening.

The lookup of tracks does happen in a seperate thread, and starts when the UI unblocks. The interface blocks because Sound Juicer called open on the device node, and that is blocking until the drive has spun up. I may be able to put that section of code in another thread. Filed as #317860.

2. If I press 'play', nothing happens. I have to select the first track, then press play.

Weird. [looks for CD to test] Works for me, what version are you using? The 2.11.x series had lots of fixes for various issues like this, so you may need to upgrade.

3. While playing, the extract button is insensitive. So it seems I can't extract while playing? Fine, maybe I can play while extracting... No, can't do that either... It should be possible -- the first thing you want to do with a new CD is play it, and ripping it would be a close second. Two birds, one stone would be nice.

My stock argument for requests like this is that the playback functionality in Sound Juicer is intended as a guide to find the track the user wants to rip and not as a fully-featured player. However, that's just an excuse in this case for "looks tricky". I'm not expecting GStreamer to sanely handle playback and ripping at the same time, but maybe I'll give this a go when I switch to libcdio. Filed as #317862.

4. If there is an error in the disc, the whole UI blocks for a long time.

[Insert stock grumble about cdparanoia] The extraction is in another thread so is about as far removed as it can get from the mainloop as I can get, without forking.

5. When the ripping is finished, the disc is ejected. Great. When I put another in, it blocks the sound-juicer UI without any stated reason for 4-5 seconds, and then doesn't even read my new CD. I have to fiddle in menus to manually tell s-j to reread the disc. Duh...

The interface blocking is the same as (1). Sound Juicer used to re-read CDs correctly, so something has broken. I'm tempted to blame HAL, but I'm not sure if that is correct. I see this too so will try and get it fixed in 2.12.3. Filed as #317864.

6. Then, neither Rhythmbox nor Jamboree automatically adds these files to their libraries. There should be some way of adding files as they are finished writing, so that I can play them immediately. At the very least they should all be added when ripping finishes. Not sure how to do this though.

The standard solution here is that the applications should monitor the directories they read from with dnotify/inotify/whatever, so they are notified when a new file is created.

Hopefully this answered all of the complaints. Not a bad tally: two bugs not in Sound Juicer, a duplicate, a regression, and some bugs which are very non-trivial to fix.