Hello Michael, On 8/21/07, Michael J. Hammel <mjhammel@xxxxxxxxxxxxxxxxx> 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 _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
