Plugins API early sketch

[T.R.Shashwath]

Looks nice...

On Monday 12 Mar 2007 4:36:06 am Jeff Mitchell wrote:
> 1) Please chime in with functions, members, etc. that you think various
> Plugins must have.  I'll be adding more, but those of you with more
> experience with for instance engines and music stores have a much better
> idea about how to handle those.

First of all, I think we need to identify which plugins need (user) 
configuration, and how that should be done. This would come in two parts:
a) A UI for configuring the plugin
b) A function for getting the settings to save (serialization).

Possibly some plugins may need to save data that's not user config data - 
maybe this should be integrated into (b) above?

> 3) Solid, though hal/udev should support most modern devices (Creative if
> you have libmtp, iPods, etc) but not some of the older ones (Rio Karma, for
> instance, although libkarma could maybe add udev rules in the future).  It
> also autodetects whether something is a MassStorage or Proprietary device.
> What I'm getting at is do we want to remove manual device addition?  This
> would make things a lot easier on our end, but I'm not sure whether or not
> it would end up limiting us.  If so, we could still support any Volume that
> Solid supports (for things like USB sticks that plug into players), and
> simply store whether or not to use a particular Solid UDI or not. 

I don't think it's a good idea to rely totally on Solid, but when Solid starts 
supporting something, we could just switch over to that version instead of 
our own. The reason for this is that there are many devices that may or may 
not have Solid support, at least initially. Sooner or later, Solid will 
support practically every device we'll care to use (I hope :-) ), and we can 
drop our own implementations immediately.

> 4) I haven't yet defined any capabilities although I have good ideas for
> many. I have yet to figure out how these would be defined...in code
> somehow?  As a programming document only?  The idea is that they're nuggets
> of API; e.g. if an engine claims the CanCrossfade capabilitiy, it should
> implement a setCrossfade( bool ) function.  The benefit of this over what
> we have now is we don't pollute our top-level classes with tons of
> functions and members that only make sense to one or a few plugins but are
> inhereted by all, but we still have a programming model that allows Amarok
> to find out what different plugins are capable of and make use of them in a
> standard fashion (i.e. an iPod plugin's createPlaylist function doesn't
> have a bool return value while an iRiver plugin's createPlaylist function
> has a QString return value).  It also lets different plugins mix and match
> what they can do while still sharing a general parent.

One question that needs to be answered is what happens if some plugin doesn't 
implement a certain function. To use your example, if a plugin claims to 
crossfade, and doesn't, what do we do? Do we check on plugin load and refuse 
to load those that don't at least implement those functions or handle it when 
trying to call that function?

This won't be a problem with plugins we develop, but third-party ones, which 
are sure to appear, I don't want to trust so easily. So, what do we do about 
those?

Also, I think we need a way for PluginManager to connect signals and slots 
from plugins to other plugins. My idea is for one plugin to just say "I want 
to send this kind of data to all plugins that are interested in this type of 
data", and the manager will connect it to all interested parties. This may 
make sense to other parts of Amarok also, like say the collection browser, 
but I'm not sure how we could handle that.

Anyway, I'm attaching a few modifications to the UML that reflect these ideas.

Shash
-- 
'Would you tell me, please, which way I ought to go from here?'
 'That depends a good deal on where you want to get to,'
 'I don’t know where. . .'
 'Then it doesn’t matter which way you go,'
--Lewis Carroll, Alice in wonderland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Amarok_plugins.xmi
Type: application/x-uml
Size: 30227 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20070313/58e92672/attachment-0001.bin