On Mon, 2004-11-29 at 17:31 +0100, Reinout van Schouwen wrote: > On Mon, 29 Nov 2004, Julien Olivier wrote: > > > You should try MrBurns: http://www.grawert.net/software/mrburns/ > > It's very simple, and still very BETA, but it works for me. It can burn > > OGG and MP3 files. Use it in combination with nautilus-cd-burn and you > > should have most of what you need. > > Neat! Although of course, this program screams to be integrated with > nautilus(-cd-burner). Actually, burning data and burning music are tasks so different that it'd be really strange to have them anywhere tied together. nautilus-cd-burner burns data, which is structured in one way (folders, trees, etc); my-music-cd-burner burns playlists, which is structured in a completely different way (ordered collection, maybe with grouping (think movements in a classical piece), maybe with information about the length of pauses between tracks, etc) (NB: Everything that follows is implicitly qualified by a IMO) What we need is a user level notion of a playlist, which can be created, edited, played, and burnt onto cds, and so on. This tasks would be done using a now imaginary gnome-playlist-editor---which most notably is -not- a music library manager. We do not need a playlist manager application, as nautilus is amply capable of doing anything that might be reasonably asked of a playlist manage. Iiuc, it is now possible to have nautilus show “Edit”, “Burn to CD”, “Play” (activated by default on double click...) items in the context menu for playlists. The organization of playlists is most naturally achieved using folders, which the user already uses for everything else, and deleting (and undeleting, for free) is already provided by the Trash, &c. The only hard part is handling the creation of playlists. It could be done using a template and the current “Create Document” item in the context menu, but it is generally agreed (and reasonable) that anything in ~/Templates should be put there by the user herself, so that does not really work. If we had a document-oriented top level menu, I'd put there the “Create Playlist” item, as a child of a “Sound & Video” item (there is also the problem of -where- the playlist will be created...) I'd also fold sound-juicer into this app, and add a “Create Playlist from CD” menu item (probably rephrased in a smarter way to somehow make explicit the ripping that will take place) It's a non trivial exercice in UI design to do this folding, I guess, but we have seen harder ones solved with such prowess that I am quite full of an agreeable expectation in that direction. I'd argue also that we would not need a music collection manager, either, if we had something like vfolders capable of looking into metadata attached to ogg's and mp3's. Maybe Beagle's nautilus folders can be used for that. A rhythmbox stripped of anything but its music-collection-manager capabilities would work here. Note this approach has the nice aspect that in the user's eyes one is only introducing a new object, and reusing the existing framework (nautilus, basically) to do all the manipulations required, except of course for the gnome-playlist-editor thingie. I think I can summarize what this rant is trying to convey: I really think that instead of adding applications to the desktop, we should be adding object types. Btw, re: what we have now: Muine is rather close to what I have in mind as an ideal gnome-playlist-editor, except I'd love to see an even simpler UI---sound-juicer-simple, or even spatial-forlder-simple. Rhythmbox (which I use all the time, when gstreamer HEAD allows me to) I have never been able to understand: it is too many things at the same time. Sound-juicer is one of the current epitomes of the It Just Works approach. Cheers, -- m -- Mariano Suárez-Alvarez <msuarezalvarez arnet com ar> http://www.gnome.org/~mariano
Attachment:
signature.asc
Description: This is a digitally signed message part