Media Devices and Collections

[Maximilian Kossick]

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.