extragear/multimedia/amarok/src/servicebrowser/lastfm

[Maximilian Kossick]

The idea of the collection framework and in particular the Meta
framework [1] is to hide the implementation details of the music from
other core components like the playlist or the engine. I just had a
look at the shoutcast service again, and it looks like the "expand
track" capability that we talked about a while ago never actually was
implemented as far as i can tell. So forget what I was saying about
the shoutcast service. That capability would create a problem though.
What we would essentially be doing, if we'd actually use that or a
similar capability, is to make other parts of Amarok aware of
implementation details of that collection/Meta implementation, even if
we slap another abstraction layer on top of those implementation
details. Doing that would require special code to handle those
details, which results in additional if/else statements (and I really
dislike if/eslse statements if they can be replaced by a proper
architecture). This can be avoided by keeping the implementation
details internal to the component where the tracks are originating
from.

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 am sure that we won't end up with 20 similar models/views if we
approach this problem properly btw:)


--Max

[1] slightly off-topic: the Meta framework is what ties all pieces in
Amarok together, collections are actually optional. You can use amarok
perfectly fine if you just drag files from the file browser to the
playlist
[2] yes, it's similar to the existing Various Artists node. Why is it
ok to add that node but not other special nodes? The various artists
node is required to make the local collection look like A1 in the
collection, and the local collection simply is more important than
other collection implementations.