Media Devices, 2.0

Jeff Mitchell kde-dev at
Fri Sep 15 09:03:29 UTC 2006

As someone who's worked with the MediaBrowser class and authored a  
media device, I'll be the first to admit that the codebase is  
currently messy.  This is primarily because it was written with iPods  
in mind, and not with awareness of the different needs and  
capabilities of various devices, which had to be tacked on later.

I was thinking about this today and wanted to toss something on the  
mailing list for people to think about and discuss.  Here's my idea:   
take advantage of abstract data types and multiple inheritance, and  
define a set of different capabilities interfaces that different  
devices can inherit.  For instance, all media devices should inherit  
(e.g.) from MediaDeviceBase.  If they can handle podcasts, they should  
also derive from (e.g.) PodcastCapableMediaDevice.  Devices that  
support playlists can derive from (e.g.) PlaylistCapableMediaDevice.   
If they can use KIO for data transfers (and thus can handle slaves),  
they could derive from KIOCapableMediaDevice (this could be useful if  
either a native library or KIO could be used for transfers, and one is  

I'm not sure how this would affect linking times, but it does seem  
like this would make it easy to support device features that, as of  
yet, no one has thought of.  Simply add a new interface, which should  
be very implementation-agnostic, and plugin authors can implement the  
interface at will.  It's cleaner than cluttering up MediaDevice with  
tons of virtual or null functions, and would help make it clear which  
functions Amarok uses to support specific operations, so that plugin  
authors can easily figure out what functions they must override in  
order to support a feature on their device.

Devices could easily be queried to see if they support a function by  
either casting, or simply having member variables corresponding to the  
different types of interfaces available, set to 0 by default and set  
to 1 if the device supports that interface.

I look forward to hearing what you guys think, especially Martin and  
the various existin plugin authors.


More information about the Amarok mailing list