Re: [Rhythmbox-devel] Support for organizing by multiple genres per song.

Le mercredi 02 mars 2005 à 09:11 -0500, John Russell a écrit : 
>On Wed, 02 Mar 2005 15:02:12 +0100, Gabriel de Perthuis
><Gabriel de-Perthuis laposte net> wrote:
>> Le mardi 01 mars 2005 à 18:52 -0800, Jonathon Watney a écrit :
>> >On Tue, 2005-03-01 at 16:43 +0000, Bastien Nocera wrote:
>> >> On Tue, 2005-03-01 at 11:21 -0500, John Russell wrote:
>> >> > This is one of those rare cases where Reply-All is the right way to
>> >> > go.  I'm not an RB developer so I have no idea how hard this is.
>> >> > Anyone else know?
>> >>
>> >> You guys are looking for the "Smart playlists" which are already
>> >> implemented. They should be fairly to extend to have additional tests
>> >> and metadata to filter.
>> >
>> >Mmmm, does 'Automatic Playlist' equal Smart Playlist?
>> >
>> >If so, it looks like it cannot do what I would like it to do. Not out of
>> >the box anyway. If I create two playlists, one that lists 'Metal' in the
>> >genre and another that lists 'Jazz' in the genre both lists do not
>> >appear to have the songs that have both a jazz and metal genre comment
>> >defined. (I suppose I could comma delimit genres in one field...)
>> >
>> >And the pane views are so much easier to use to be able to filter down
>> >to certain songs. With the playlist idea I have to manually edit the
>> >playlist criteria. This involves right clicking and typing where as the
>> >using the panes just requires clicking. Also using playlists if I just
>> >want certain albums in a genre I need to create a totally new playlist
>> >and stuff more criteria in there. With the pane view I just 'click on
>> >down'.
>> >
>> >I would have liked to uninstall the playlist mentality when I
>> >uninstalled XMMS. ;-)
>> >
>> >I hope I am missing something here. Any ideas?
>> >
>> Yes, the panes allow multiple selection but that only permits to OR the
>> criteria.
>> Here is my idea of a GUI for quickly selecting things from a database -
>> a group-sort widget. This
>> is a bit daunting to me. I don't know yet if one should just write a
>> tree model, or inherit from the tree view as well.
>> --
>> Gabriel
>I don't see why all this is necessary.  Why can't you just change the
>way RB ( or gstreamer I suppse ) reads the tags so that if there are
>multiple kinds of a tag, e.g. two artists, or two genres, that the
>song will appear in both categories.

OK, this is what I think would be the best UI to query a flat song
database like you describe (where a song can be tagged with multiple
genres, authors, albums, etc). It may be unnecessary. However, note that
currently the UI is a hierarchy - selecting an artist drops selected
albums, selecting a genre drops the albums & artists.

The immediate problem to solve to handle these tags is the internal
representation of songs. The rhythmdb keeps songs in a tree of
genre->artist->album->song (from the INTERNALS text in the source). The
panes are currently relying on this, but they could use the
RhythmDBQuery interface instead if the rhythmdb changes to a flat db.
The other solution is to keep the tree and just duplicate entries. As
long as multiple tags aren't widely used, the db wouldn't grow much. The
entry list would filter the duplicates at the end. The gamin part would
need changes.

>So if all my Police stuff is under 
>genre: Rock, Classic Rock 
>artist: Police, Sting
>Everything looks the same, but 
>if I go to Rock-> Sting, its all there
>if I go to Classic Rock->Sting, its all there
>if I go to Classic Rock ->Police its all there
>and guess what happens if I go to Classic Rock->Sting?
>This is exactly how vFolders work in evolution.
>No changes to the UI and the categories are correct.  The only issue I
>can think of here is that depending on how randomness is handled,
>songs with multiple tags may get played more often.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]