[Gimp-developer] Extending GIMP Plugins

[Amit Kumar Saha]

Hello Michael,


On 8/21/07, Michael J. Hammel <mjhammel at graphics-muse.org> 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
> configuration.
>
> 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
> instead.
>
> 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.

Artists basically.

Thanks & Regards
-- 
Amit Kumar Saha
[URL]:http://amitsaha.in.googlepages.com