On Tue, 2005-04-26 at 16:07 +1000, Nicholas Gill (mythagel) wrote: > I'm developing support for rb to automatically sync a playlist with a > flash based mp3 player (the kind that g-v-m automounts). I have written > a prototype as a standalone app, however i think it would be more useful > as part of rb itself. I don't actually have a MP3 player (yet), but it sounds like something that would be pretty useful. I've used them a bit, but not that much, so take what I'm suggesting with a grain of inexperienced-flavoured salt. > The idea is to make it "Just Work". A use case may be something like: > > "Nick plugs in his new mp3 player, rhythmbox opens with a new playlist > named after the device. He copies some songs onto the playlist and > closes rb. It syncs the playlist to the device and he unplugs it, with > all the songs copied" > > I spoke with David Zeuthen from the utopia list, and he informs me that > g-v-m can be extended to do the same kind of thing it does for digital > cameras. He also showed me a file > (http://cvs.freedesktop.org/*checkout*/hal/hal/fdi/information/10freedesktop/10-usb-music-players.fdi?rev=1.2) that shows HAL already has the ability to identify mp3 players (though the device database could use a lot more devices to be useful). Also he gave a simple suggestion, that using that file and gstreamer, to transcode music into the format supported by the particular player. What are you thinking in relation to trying to copy songs that aren't in a supported format? > I need some input as to how this should interact with users. For > example, if a user copies songs onto the playlist, should it copy it > straight away, or should there be a "sync" button? Should rb eject the > device after syncing? etc. My feeling would be to start copying immediately, but have a "copy in background" button, so that the user could continue looking for more songs to copy. If they dragged more songs over it would just add them to the list of songs to copy. Having a column with a flag indicating whether the song has been copied yet or not could be useful. If we did the above, I'd say that you would want to wait until the app exited to eject; although having a "eject now" item in the context menu would be good. If they tried to exit/eject while it was copying pop up a dialog with "Stop copying" and "Cancel, and continue copying". > Note that this may take me a little longer as i am normally a c++ dev. I had the same problem when I started hack on RB, my biggest issue was remembering not to use C++ style comments. Cheers, James "Doc" Livingston -- To bowl a maiden over: i. Remove Cover and Extra Cover. ii. Move fine leg to square leg. Hmm, I can't seem to think of a way to finish this. -- Sid on RHOD
Attachment:
signature.asc
Description: This is a digitally signed message part