extragear/multimedia/amarok/src/servicebrowser/lastfm

[Shane King]

Maximilian Kossick wrote:
> If we ignore the question whether a tree view is really the right user
> interface for last.fm, making last.fm a collection and reusing the
> collection view create a few problems. I don't know what you layout
> you have in mind for that tree, but at the very least we'd have
> something similar to global tags in A1, so we'd need a Global Tags
> node which would have a child node for each global tag. The problem is
> that the Global Tag node is not a real node[2]. For example, adding
> all child nodes of the Global Tags node to the playlist does not
> really make sense from a UI POV, although it's technically possible.
> Removing that item from the context view would mean modifications to
> the collection view and/or the model, and we all know that these two
> classes unfortunately contain lots of black magic. Then there's the
> problem how we'd insert the Global Tags node into the collection view
> anyway? Using another Meta class to fake it, e.g. Meta::Genre, results
> in each track having the genre "Global Tags". And I am completely
> against extending the CollectionModel with support for further "fake"
> nodes. Adding Various Artists was bad enough, and we don't have to try
> and break it again.

I'd basically given up on the idea of making it a collection, it just 
doesn't fit into the current collection model. The collection works of 
"special" fields like artist, album, genre, etc. As you say, the only 
way to shoe-horn something like last.fm into that is to fake up things 
like genre fields.

Either last.fm needs to do it's own tree (if it's going to be a tree), 
or the collection stuff needs to become more of a generic hierarchy that 
doesn't use a fixed set of fields in its construction and can instead 
use any metadata. The later idea is interesting in itself (would allow 
custom hierarchical views of any collection on arbitrary user set tags) 
but the former is probably much easier to implement. :)

Shane.