Media Devices and Collections

[Jeff Mitchell]

Quoting Alejandro Wainzinger <aikawarazuni at gmail.com>:

> I'm guessing MediaDeviceCache stays since it interfaces with Solid.

Yes.

> MediaDeviceConfig and MediaDevicePluginManager stay as they just deal
> with standard configuration.

Yes.

> 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.

Have you checked to make sure that MediaDeviceCollection can implement  
enough custom actions?  I don't know how malleable the Collection  
system is.

> I'm not sure what an analog for MediaQueue would be.

Probably a second model/view system similar to the "simple" playlist  
toggled with the star button.  It just needs to be a list of tracks,  
containing URLs or Meta pointers or some such thing under the hood.

> MediaItem is either gone or needs to be refactored, since it is based
> on Q3ListView and the Collection will be using a CollectionTreeView
> class.

Sounds good.

> 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.

True.  For MediaDevice, rip out what you don't need, but keep it the  
base class that other devices can rely/depend upon.  As all device  
plugins subclass it, it really shouldn't have more functionality than  
needed -- keep it basic and simple.

I don't actually think that MediaBrowser does that much GUI stuff  
(although I believe the MediaQueue class currently lives inside those  
files too).  MediaBrowser should contain the functions and GUI  
elements necessary for all devices -- connect, switch device,  
disconnect, configure, etc.  I'd recommend keeping it simple too, if  
you refactor things, but do be careful...

> 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?

Keep in mind that any device (including generic, through Taglib)  
should be able to get you basic metadata -- title, track number,  
artist, album.  (Although -- scanning a generic device with Taglib  
every time someone plugs it in could be infuriating, which is why  
Amarok 1.4 simply showed filenames and hoped the users organized into  
proper folders (which they did if they used Amarok 1.4 to upload  
them)...you may want to consider something similar, if you can control  
what elements are shown in the collection view.)  So I would try to  
look at what kinds of track information are in common across the  
libraries, and use inheritance to keep specific device info specific  
to that device.

Hope this all helped.  I may have email tonight, but otherwise I won't  
until at least Sunday.

--Jeff