Disable/Enable collections on the fly?

Maximilian Kossick mkossick at gmx.de
Sat Jul 7 12:02:29 CEST 2007


On Saturday 07 July 2007, Jeff Mitchell wrote:
> Maximilian Kossick wrote:
> > On Friday 06 July 2007, Jeff Mitchell wrote:
> >> Max--
> >>
> >> Is there a way to on-the-fly enable or disable collections?  I'm
> >> thinking about this in the context of portable devices, where a user may
> >> not want to automatically mount/connect a device or may want to
> >> unmount/disconnect it at a given time.  If there were a way to
> >> enable/disable collections, then this would in effect be an appropriate
> >> way to determine whether to connect the portable player or not.
> >>
> >> --Jeff
> >
> > Assuming that the the portable device should always appear in the
> > collection browser, check out CollectionManager::addUnmanagedCollection,
> > CollectionManager::removeUnmanagedCollection, Collection::remove,
> > CollectionFactory::newCollection
> >
> > Using this method you can decide at any time to add or remove
> > collections.
> >
> > Cheers, Max
>
> Sounds good, but I was also wondering if there was some more GUI way to
> do it (perhaps this is a question for someone else).  If we get rid of
> the device browser -- which makes sense considering all the various
> Collection methods available -- we'd need a way to connect and
> disconnect a device, which would be implemented alongside adding and
> removing the device's collection.  Is there a standard planned way to
> show a list of available collections (possibly populated on the fly, so
> things like devices detected in Solid would show up as appropriate), and
> have them toggle-able?
>
> --Jeff

There's no GUI way to do that yet. We might still need a device browser to 
make it possible to manage playlists/podcasts/some other stuff that you can 
put on a media device in a central location. It's probably possible to split 
this out across multiple browsers( fx adding songs in the collection browser 
and managing playlists somewehere else), but i don't think that that's a good 
idea.

I talked to Kevin Ottens about Amarok's media device plugins yesterday. He'd 
like to have kioslaves for the media devices which would allow users to 
manage the media devices from a file browser too. When porting the old media 
device code (which is unfortunately necessary, because they use items all 
over the place) we should think about abstracting some of the code to make it 
easier to add ioslaves for them. Kevin's idea was basically to write a (thin) 
kde abstraction layer around the media-device specific libraries like 
libgpod. Amarok could use the abstraction layer directly to make it possible 
for us to do more advanced stuff like syncing playcount, and then we could 
write a kioslave which exports the tracks, playlists, podcasts and anything 
else as a virtual file system.

Cheers, Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20070707/4465a51f/attachment.pgp 


More information about the Amarok-devel mailing list