Return Playdarcollection from "the Dead" ;)

[Bart Cerneels]

On Wed, Feb 23, 2011 at 19:06, Stefan Derkits <stefan at derkits.at> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hey,
>
>>> Yeah, Leo and I talked about putting together a 'dummy service' for
>>> it, which would allow enable/disable and configuration, and I still
>>> think that's a good idea, but it was decided way back when that it is
>>> a Collection rather than a Service, (though it does have
>>> characteristics of both).  Also, I think it fits more as a 'local
>>> source of music' since one of the goals of Playdar was to make
>>> disparate sources all appear local.  Also, for recommendations and
>>> such, (e.g. top tracks from similar artists), to be useful, it needs
>>> to be queried when the other collections are.
>>
>>> However, I feel rather strongly that being able to configure
>>> collection plugins in the same way that services can be configured is
>>> a great idea, especially with the number of collection plugins
>>> available now.
>
> Some Services have Collections ... I think it could stay as a Collection
> where it is and be enabled/disabled & configured via a Service ... could
> that be possible?
> Only thing is that I think every Service creates an "Entry" in the
> Internet and maybe the Collection of a Service doesn't find it's Place
> inside Local Music.
>

I'm against the idea of having a playdar service just for
configuration. Unless it has actual usable content, like for instance
your own GPodderService, it should not pollute the internet service
list. Configuration of a collection can be done using the
CollectionDelegate actions  (they appear when hovered over the root
items in Local Music. If requested we can make a page for it in the
settings. There is also a branch by Rick that allows complete
disabling on a plug-in basis [1] this can support configuration for
each individual plugin, like playdar.

[1] http://quickgit.kde.org/?p=amarok.git&a=shortlog&h=refs/heads/rickc-pluginselection