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