RFC: disabled (or not yet enabled) collections in the browser

[Bart Cerneels]

On Fri, Mar 4, 2011 at 18:38, Mark Kretschmann <kretschmann at kde.org> wrote:
> On Fri, Mar 4, 2011 at 12:21 PM, Bart Cerneels <bart.cerneels at kde.org> wrote:
>> On Mon, Jul 19, 2010 at 15:37, Bart Cerneels <bart.cerneels at kde.org> wrote:
>>> I want to make it possible to list a collection in the CB but not
>>> actually enable it until the user has clicked on the collection root
>>> item.
>>>
>>> Use case for this:
>>>
>>> - UMS Collection is not scanned by default (huge resource drain). It's
>>> already listed in the CB but without tracks until the "Scan device"
>>> action is triggered. That action is only shown if the mouse is over
>>> the root item because it would cause to much visual clutter if always
>>> visible. As long as the collection is not enabled though there is no
>>> byline text either.
>>> If the root item would show "click to start scanning" it would be a
>>> lot easier to use for novice users already.
>>>
>>> - Nikhil's UPnP collection also needs to scan if the mediaserver does
>>> not support Search. This "directory-walking" uses network, CPU and
>>> memory resources in a serious intensive way. If a couple, or one very
>>> large, search-less UPnP mediaservers are on the network, this could
>>> bring amarok to it's knees. The user will click servers that really
>>> should be scanned.
>>>
>>>
>>> Currently the byline (text underneath the collection's name) is
>>> hardcoded to show track count. I would like to change this to show a
>>> different text when the collection is disabled and trigger some action
>>> when the item is clicked.
>>>
>>> I plan to add a state to Collection and use it in the browser with a
>>> hardcoded string. When state == disabled some function will be
>>> triggered to enable a collection ( perhaps re-using
>>> startIncrementalScan() ).
>>>
>>> Does anyone have a different use case that requires a custom byline?
>>> Perhaps we should not hardcode any of the bylines.
>>>
>>> Bart
>>>
>>
>> To come back to this ancient topic:
>> Rick (stuffcorpse) has implemented plugin enabling. So we can
>> brute-force disable some collections already, by not loading it's
>> plugin. Next step is disable on a resource level (for instance, UPnP
>> server A but not B).
>> Should we make this a GSoC project?
>
> Not sure if I'm misjudging the complexity here, but isn't this a bit
> too small a task for GSoC?
>

Considering this requires coming up with a very good architecture and
lots of refactoring I think it's probably more complex then you
imagine.