I spent today implementing Addins in Muine. We already had our own plugin framework. However, it's awkward and requires a lot of mess in the main code. The main code (particularly PlaylistWindow.cs) implements an interface in a library which is shared with the plugins (Muine -> PluginLib <- Plugin).
The Mono.Addins framework requires little in the way of code in the main project. It also has an A -> B <- C model similar to the PluginLib but it is much more advanced. Instead of overriding methods in the main program, you just define "Extension Points" within the program where plugins can jump in. This does, however, require XML descriptions in for the main program and each addin. However, that's fine as it means addins also get a name and a description and such instead of just being nameless assemblies. Also, more than one plugin can attach at a point. So if ToolbarButtons was a point, several addins could add buttons there.
It didn't take much to implement a simple "Hello, World" plugin for Muine. However, 90% of my time was spent wrestling with autotools... God, I hate autotools! So, how about we do what I said a few years ago and split the audio playing, database, C portion (libmuine) into it's own tree with its own build-system. libmuine can use autotools, configure, make, all that. That would mean Muine could shift to NAnt. Unless someone has a favorite build-system they would like to promote. I loathe trying to program in XML, that's why I created a series of XSLT templates called AutoNant to ease the pain. I want to be rid of the autotools/make mess!
1 comment:
Neat. Python has a nice entry points system too in the form of setuptools. I was only made aware of it a couple of weeks ago when I was writing a plug-in for a CAPTCHA TurboGears tool. The concept seems to work really well!
Post a Comment