Media Devices and Collections

[Bart Cerneels]

On Thu, May 29, 2008 at 8:32 AM, Maximilian Kossick
<maximilian.kossick at googlemail.com> wrote:
> On Thu, May 29, 2008 at 4:22 AM, Alejandro Wainzinger
> <aikawarazuni at gmail.com> wrote:
>> -- Note: sorry for the repost on this list, I shot off to the general
>> mailing list by mistake --
>>
>> Hey,
>>
>> So I've been looking into Media stuff, haven't gone through it all
>> just yet, because I've been going through Collection stuff too.  I've
>> got a skeleton for a MediaDeviceCollection set up so I can play with,
>> though I'm not sure what I'm going to do next.  From what Nikolaj
>> tells me, a Collection already handles the view pretty much by itself,
>> by adding itself to a CollectionTreeView class.  I need help in
>> figuring out what Media* stuff to keep, and what to toss out, since a
>> lot of that code is specifically for display.  Here's what I'm
>> figuring, please correct me where I'm wrong.
>>
>> I'm guessing MediaDeviceCache stays since it interfaces with Solid.
>> MediaDeviceConfig and MediaDevicePluginManager stay as they just deal
>> with standard configuration.  MediaDeviceAlbum/Artist/Genre/Track are
>> gone, as the MediaDeviceCollection's Meta stuff will be handling that.
>>  MediaView is gone since the view is handled by a CollectionTreeView
>> class.  I'm not sure what an analog for MediaQueue would be.
>> MediaItem is either gone or needs to be refactored, since it is based
>> on Q3ListView and the Collection will be using a CollectionTreeView
>> class.
>>
>> For classes like MediaDevice and MediaBrowser, I'm unsure what to do
>> as it blurs the line of what is code that deals with backend device
>> stuff, and what is used to display it.
>>
>> Collections:
>>
>> I used the daap code as a skeleton, but daap was only dealing with
>> forming one very particular type of KUrl, whereas in media devices,
>> iPods will have one type of KUrl to be formed using libgpod (where the
>> ipod songs are just at some mountpoint), and mtp devices don't even
>> mount and its stuff is dealt with by libmtp (haven't looked into how
>> it works just yet).  How should I design the MediaDeviceCollection to
>> be generic enough for all media devices?
>>
>> Help appreciated,
>>
> i have got some code on my laptop which might be helpful. It's very
> incomplete, but might give you an idea how t tackle this problem. I'll
> send you the code tomorrow evening. Basically you'll need a second
> layer of abstraction beneath the MediaDevice meta classes if you want
> to create a generic media device collection (!= a collection
> specifically for generic media devices). each media device would then
> provide implementations for that second layer, which you could model a
> bit closer to what you actually need.
>
> Regarding the MediaView:
> We'll need a gui to handle podcasts/playlists/anything else on media
> devices at some point. CollectionTreeView is not designed for this
> (although you might be able to achieve your goal using a fake
> collection, but it'd advise against it), so we'll need a view for
> media devices at some point.

Both Podcasts and Playlists on mediadevices can be shown in the
Playlistbrowser. The steps needed for this are:
 1) implement PlaylistProvider and PodcastsProvider in your mediadevice class
 2) implement Meta::Playlist and Meta::PodcastChannel/Episode
 3) register the Providers with PlaylistManager

 4) have Playlist and Podcasts magicaly appear in their respective
categories in PlaylistBrowser

The UI of PlaylistBrowser is obviously not finished. What is needed is
a way to show/hide Playlists and Podcasts from specific Providers
(i.e. Collections/MediaDevices) and a way to sort them based on
Provider.

Bart