On Tue, 2006-02-14 at 06:24 +1000, Jonathan Matthew wrote: > On Mon, Feb 13, 2006 at 09:39:53AM -0600, Jack wrote: > > Hi all. I'm a long time Rhythmbox user and browsed the code a little > > bit. Never had the guts to add full new features, but now I've got a few > > minor things I'd like to change and was wondering if they'd been > > considered and rejected, or if anybody was already working on it. > > > > 1. Queue Album option on the Browser album side. > > You can already drag albums from the browser into the queue. It doesn't > work quite how you'd expect, as the album browser doesn't know the state > of any of the other browsers, so it'll always add all songs with that album > name, even if you've only got one artist selected. An individual browser (RBPropertyView) knows nothing about the state of the other property views, so it can't currently do this. This means there are basically two options: 1) make property views know about the ones before it. 2) make a higher-level thing handle drag-and-drop, I'm of the opinion that property views shouldn't know about each other, so I would suggest (2). RBLibraryBrowser is the class that binds the views together, and knows about them all, so we could make that handle drag-and-drop. > > 3. More verbose "File is not a music stream" box (i.e. say "You need to > > install gstreamer-plugins-bad" if the files are .m4a or *at least* tell > > the user that Rhythmbox just can't play it... this confused my roommate > > to no end). > > This is definitely something that needs to be looked at. People who > work on this code tend to have already installed every plugin they can, so we > probably don't handle this case very well. I thought about this the other day. What we need is for rhythmdb to have a "unknown-media" signal, which gets emitted when a file can't be fully decoded. The signal would take the RBMetadata instance, so it knows about the file in question, and would also use g_signal_accumulator_true_handled so that handlers could signal that the files should be ignored. Distros could then write a plugin that connects to the "unknown-media" signal. It would a) return TRUE to stop processing, b) bring up a dialog telling the user that a plugin needs to be installed, c) ask gstreamer to reload the plugin registry (I think this is possible), and d) ask rhythmdb to reload the file once it has been installed. Some things that would need to be done: * change the RBMetadata so that it doesn't emit _ERROR_IGNORE conditions, RhythmDB should handle this. * add _contains_audio() _contains_video() and _contains_unknown() functions. * add some kind of "deep typefinding" so that we know what files actually contain. e.g. "application/x-id3; audio/mpeg" for id3-tagged mp3s. This may not be the best way of doing it, but are some ideas I'd like to chuck out there. Cheers, James "Doc" Livingston -- If at first you don't succeed, sky diving is *not* for you.
Attachment:
signature.asc
Description: This is a digitally signed message part