Media Devices, 2.0
trshash84 at gmail.com
Fri Sep 15 13:56:12 UTC 2006
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
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
> 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.
> Amarok mailing list
> Amarok at kde.org
"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."
More information about the Amarok