On 8/21/07, Michael J. Hammel <[EMAIL PROTECTED]> wrote:
> The trick here isn't creating an extensible plugin. The trick is
> defining what "without much hassle on the part of the end-user" really
> means. Who's the end user? Joe Artist or Edward Engineer? Sven's
> granny or a bunch of kernel developers?
Joe Artist comes closest :) I am targeting end-users who are primarily
using the plugin to get their jobs done and if needed learn some bits
and pieces to extend the functionality.
> In general, making a piece of software extensible requires two main
> components: a grammer understandable by the core software and an API
> accessible through that grammer to core functionality. One problem
> you'll have to address is what parts of the API are visible to the
> plugins and what parts are not.
> To make a piece of software extendable you could ignore the API portion
> and create a simple grammer that end users could use to essentially
> configure the plugin. Imagine a simplistic scripting language that
> simply sets a bunch of variables that the main plugin normally requires
> you to set manually using a series of dialogs or tabs. Wouldn't even
> require anything as complex as Perl or Python - it could just be a
> series of name/value pairs. But this isn't really extension, its
> More complex examples would include exactly what GIMP already does with
> it's language extensions. You can load a dll easily enough or embed an
> interpreter like Perl or Python. But is programming in Perl or Python
> "easy" to your end user? A more common approach these days is to allow
> extension via XML. You can easily embed an XML parser into a plugin
> (I've used libXML2 in my plugins to save configuration data). But then
> you have to decide if writing XML by hand is easy for your users. Not
> to mention defining the XML Schema or DTD for the language. In the end,
> though, what you've done is create a new programming language. If
> you're doing that, and started with the intention of making it easy to
> use, you might as well use a well known language like Perl or Python
> You could provide a series of core features in the plugin that could be
> used in a reorderable stack and then build a GUI that used drag and drop
> to rearrange that stack. Sort of like arranging a series of existing
> plugins to be run in any given order. The plugin would then process in
> the order defined by the stack. The problem here is that you're simply
> providing a mechanism for using existing features, not allowing the user
> to extend that feature set.
You are spot-on. Its not extending the features.
> So before you decide on the mechanism, you have to define who will use
> it and what you're really trying to allow them to do.
Thanks & Regards
Amit Kumar Saha
Gimp-developer mailing list