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

[Mark Kretschmann]

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?

-- 
Mark Kretschmann
Amarok Developer, Senior Software Engineer at Nokia
Fellow of the Free Software Foundation Europe
http://amarok.kde.org - http://fsfe.org - http://nokia.com