Media Devices, 2.0

[T.R.Shashwath]

Seems OK to me. I'd also like to see the view classes being managed outside 
the plugins. This removes a lot of the current complexity from the plugins, 
and gives a common UI. Perhaps devices with and without directories will have 
problems with this, but we could use your multiple inheritance technique to 
handle that.

On Friday 15 September 2006 14:33, Jeff Mitchell wrote:
> 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
> preferred).
>
> 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.
>
> --Jeff
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok

-- 
"Where shall  I  begin, please your Majesty ?" he asked.
"Begin at the beginning,", the King said, very gravely, 
"and go on till you come to the end: then stop."