Re: [Gimp-developer] Extending GIMP Plugins
On Tue, 2007-08-21 at 22:43 +0530, Amit Kumar Saha wrote: > 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. KPT or the PaintShop Pro FilterPack come to mind for artistic exploration. For automating tasks, a macro record/replay facility is desparately needed. For a graphical approach to plugins and filters, look at another graphics program, nip2, for ideas, maybe. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
On 8/27/07, Amit Kumar Saha <[EMAIL PROTECTED]> wrote: > Hello all, > > On 8/27/07, Øyvind Kolås <[EMAIL PROTECTED]> wrote: > > > According to the plan GEGL will replace all code in the GIMP that is > > accessing and or modifying pixels, some forms of GIMP plug-ins will > > most likely be entirely replaced by GEGL plug-ins instead. And as > > mentioned elsewhere in this thread, GEGL plug-ins can either be > > descriptions of graphs, or actual C code. Another option that should > > already be possible if someone is thus inclined, is actually to write > > a GIMP plug-in for GIMP 2.4 that allows GEGL plug-ins to be used > > directly by current versions of GIMP, this is less interesting than > > another bridge that will have to be written, which is a wrapper for > > (at least some of) the exisitng GIMP plug-ins to work from within > > GEGL, this will be needed to provide legacy support for > > some of the older plug-ins (these plug-ins will thus still work, but > > have limitations wrt bit-depth and such). > > > My current work at hand will possibly require me to write a plugin for > GIMP (current version) which will use GEGL for its image processing > operations. So if I proceed, I shall let the list know. > > Here a couple of more queries: > > 1. Does any of the developers here have some demo C code which takes > in a XML file specification of the operations and performs the image > processing tasks using GEGEL? The gegl binary found in the gegl/bin/gegl.c does just this, it can even be compiled without support for the GTK+ GUI which makes almost all the logic of processing happen in gegl.c, please do note that the format of the XML is not a finalized part of the interface to GEGL, and that there are some parts that are not even implemented yet. (The ability to specify a operation as a graph, stored as XML for instance, right now such meta operations need to be written directly in C which is a bit cumbersome for rapid prototyping.) > 2. Can I assume safely that most of the image processing operations > are "applying the same operation" to each pixel of the image? I do not understand what you mean by this question. It might also be an idea to take this discussion to the GEGL mailing list instead of continuing it here. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Amit Kumar Saha wrote: > 1. It seems from the documentation that, I can specify the operations > as a XML file as above instead of creating a DAG. How do i then use > that file to apply the operations? Looking again at the API there is the gegl_parse_xml() routine. There is an example of XML code being used to specify a set of operations to be performed as well as the execution of those operations in the gegl binary file (found in the gegl source tree). > What about error checking? What operations are supported? I haven't tried this recently. I'm not sure what happens if there are errors in the input XML file. You may get either an incomplete GeglNode structure (ie. one not containing all parts of the input XML) or NULL. The API doc doesn't specify which. All GEGL operations can be used in an XML file. > 2. Can I work with the individual pixels of an Image using GEGL? Say I > want GEGL to work with only certain range of pixels of my Image, is it > possible? I din't think it is possible to work on individual pixels of an image. Øyvind Kolås would be the person who could give you the more definite answer on this. -- Cheers! Kevin. http://www.ve3syb.ca/ |"What are we going to do today, Borg?" Owner of Elecraft K2 #2172 |"Same thing we always do, Pinkutus: | Try to assimilate the world!" #include | -Pinkutus & the Borg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Hello all, On 8/27/07, Øyvind Kolås <[EMAIL PROTECTED]> wrote: > According to the plan GEGL will replace all code in the GIMP that is > accessing and or modifying pixels, some forms of GIMP plug-ins will > most likely be entirely replaced by GEGL plug-ins instead. And as > mentioned elsewhere in this thread, GEGL plug-ins can either be > descriptions of graphs, or actual C code. Another option that should > already be possible if someone is thus inclined, is actually to write > a GIMP plug-in for GIMP 2.4 that allows GEGL plug-ins to be used > directly by current versions of GIMP, this is less interesting than > another bridge that will have to be written, which is a wrapper for > (at least some of) the exisitng GIMP plug-ins to work from within > GEGL, this will be needed to provide legacy support for > some of the older plug-ins (these plug-ins will thus still work, but > have limitations wrt bit-depth and such). My current work at hand will possibly require me to write a plugin for GIMP (current version) which will use GEGL for its image processing operations. So if I proceed, I shall let the list know. Here a couple of more queries: 1. Does any of the developers here have some demo C code which takes in a XML file specification of the operations and performs the image processing tasks using GEGEL? 2. Can I assume safely that most of the image processing operations are "applying the same operation" to each pixel of the image? Thanks -- Amit Kumar Saha [URL]:http://amitsaha.in.googlepages.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
On 8/26/07, Amit Kumar Saha <[EMAIL PROTECTED]> wrote: > Also, I would like to know, when GEGL is integrated into the GIMP, > will it be available for the Plugins to access the GEGL as well? The plan is that GEGL integration into GIMP will start after 2.4 is released and the 2.5 development cycle will be devoted to a process of gradual replacement, without changing the GUI significantly, thus 2.6 should be a version of GIMP that hasn't changed a lot of the GUI, but a development cycle that leads up to a GEGLified version of GIMP that can see further development and innovation. According to the plan GEGL will replace all code in the GIMP that is accessing and or modifying pixels, some forms of GIMP plug-ins will most likely be entirely replaced by GEGL plug-ins instead. And as mentioned elsewhere in this thread, GEGL plug-ins can either be descriptions of graphs, or actual C code. Another option that should already be possible if someone is thus inclined, is actually to write a GIMP plug-in for GIMP 2.4 that allows GEGL plug-ins to be used directly by current versions of GIMP, this is less interesting than another bridge that will have to be written, which is a wrapper for (at least some of) the exisitng GIMP plug-ins to work from within GEGL, this will be needed to provide legacy support for some of the older plug-ins (these plug-ins will thus still work, but have limitations wrt bit-depth and such). /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Hi Kevin Also, I would like to know, when GEGL is integrated into the GIMP, will it be available for the Plugins to access the GEGL as well? Regards -- Amit Kumar Saha [URL]:http://amitsaha.in.googlepages.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
On 8/26/07, Amit Kumar Saha <[EMAIL PROTECTED]> wrote: > > > 2. Can I work with the individual pixels of an Image using GEGL? Say I > want GEGL to work with only certain range of pixels of my Image, is it > possible? You mean a certain area of your image, rather than all of it? You would do that using the 'crop' operation (and you would later layer the result on top of the original image with a 'clear' operation to clear the area, and a 'normal' operation to overlay the result) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Hi Kevin, On 8/23/07, Kevin Cozens <[EMAIL PROTECTED]> wrote: > That looks similar to the types of things one can do with GEGL which is due to > be integrated in to GIMP after the 2.4 release. > I was just having a look at GEGL gallery (http://www.gegl.org/gallery/index.html) applications. The concept of XML file to specify a pipeline of Image processing operations is basically clear to me. However I would like to know a few things: 1. It seems from the documentation that, I can specify the operations as a XML file as above instead of creating a DAG. How do i then use that file to apply the operations? What about error checking? What operations are supported? 2. Can I work with the individual pixels of an Image using GEGL? Say I want GEGL to work with only certain range of pixels of my Image, is it possible? Thanks , -- Amit Kumar Saha [URL]:http://amitsaha.in.googlepages.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Amit Kumar Saha wrote: > The link is dead.Any chance you have some docs with you? The last version of the page (from Feb. 08, 2005) can be found at: http://web.archive.org/web/20050208090913/http://www.cse.psu.edu/~cg585/cantata-over.html About half of the images on that page are missing. -- Cheers! Kevin. http://www.ve3syb.ca/ |"What are we going to do today, Borg?" Owner of Elecraft K2 #2172 |"Same thing we always do, Pinkutus: | Try to assimilate the world!" #include | -Pinkutus & the Borg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Amit Kumar Saha wrote: > The others were about the commercial > products that uses that concept of "glyphs". Though i got a vague idea > of what it was, but more information is desired. Most systems used for creating visual effects for movies are node-based, and have been for over a decade. Look at Nuke (http://www.thefoundry.co.uk/promo/nuke.html) or Shake (http://www.apple.com/shake/) for current examples. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
On Sat, 25 Aug 2007 12:19:44 +0200, Amit Kumar Saha <[EMAIL PROTECTED]> wrote: > Hi Raphael, > > > On 8/23/07, Raphaël Quinet <[EMAIL PROTECTED]> wrote: >> On Wed, 22 Aug 2007 23:19:30 +0100, David Marrs >> <[EMAIL PROTECTED]> wrote: >> Not only in the music world. Around 1993 or so, I remember using a >> program called Khoros Cantata to design some image filters. A quick >> search on the web returned this tutorial with screenshots of the old >> X11 version that I used: >> http://www.cse.psu.edu/~cg585/cantata-over.html > > The link is dead.Any chance you have some docs with you? > > > Regards > google Khoros Cantata -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
On 8/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > google > Khoros Cantata That is the first thing I did when I got the dead link. One of the results I got was the dead Link. The others were about the commercial products that uses that concept of "glyphs". Though i got a vague idea of what it was, but more information is desired. Regards -- Amit Kumar Saha [URL]:http://amitsaha.in.googlepages.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Hi Raphael, On 8/23/07, Raphaël Quinet <[EMAIL PROTECTED]> wrote: > On Wed, 22 Aug 2007 23:19:30 +0100, David Marrs <[EMAIL PROTECTED]> wrote: > Not only in the music world. Around 1993 or so, I remember using a > program called Khoros Cantata to design some image filters. A quick > search on the web returned this tutorial with screenshots of the old > X11 version that I used: > http://www.cse.psu.edu/~cg585/cantata-over.html The link is dead.Any chance you have some docs with you? Regards -- Amit Kumar Saha [URL]:http://amitsaha.in.googlepages.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Hello Kevin, On 8/23/07, Kevin Cozens <[EMAIL PROTECTED]> wrote: > > That looks similar to the types of things one can do with GEGL which is due to > be integrated in to GIMP after the 2.4 release. I shall have a look at GEGL. Thanks -- Amit Kumar Saha [URL]:http://amitsaha.in.googlepages.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Renan Birck wrote: > Same with me; I would love something like a node-based editor (e.g. > http://pupuedit.sourceforge.net/screenshots/pihlaja_04_04_2007.png and > http://imaginit.rand.com/files/water_graph.gif ) > > This would let non-programmers, or programmers which aren't into image > processing, create their own plug-ins. That looks similar to the types of things one can do with GEGL which is due to be integrated in to GIMP after the 2.4 release. -- Cheers! Kevin. http://www.ve3syb.ca/ |"What are we going to do today, Borg?" Owner of Elecraft K2 #2172 |"Same thing we always do, Pinkutus: | Try to assimilate the world!" #include | -Pinkutus & the Borg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
On 8/23/07, David Marrs <[EMAIL PROTECTED]> wrote: > Amit Kumar Saha wrote: > > Am i thinking in a way that could possibly be implemented? or is the > > word "extensible" remotely applicable to my idea? > > > So what you're talking about here is a graphical interface to the API that a > user can use to build his own extensions? Essentially, it's a graphical > programming language. There are quite a few examples of these in the music > world > that allow the construction of modular synths (amongst other things). > > It sounds to me more like a separate companion program that's used to > construct > plug-ins than a plug-in itself. I like the idea very much. In some ways, this is essentially what /meta operations/ in GEGL is about, at the moment they are written in C, but they could just as well be created with an XML syntax and edited in a graph based environment. See GEGL (http://www.gegl.org/) and bug #465743. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Em Qua, 2007-08-22 às 23:19 +0100, David Marrs escreveu: > It sounds to me more like a separate companion program that's used to > construct > plug-ins than a plug-in itself. I like the idea very much. Same with me; I would love something like a node-based editor (e.g. http://pupuedit.sourceforge.net/screenshots/pihlaja_04_04_2007.png and http://imaginit.rand.com/files/water_graph.gif ) This would let non-programmers, or programmers which aren't into image processing, create their own plug-ins. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
On Wed, 22 Aug 2007 23:19:30 +0100, David Marrs <[EMAIL PROTECTED]> wrote: > Amit Kumar Saha wrote: > > Am i thinking in a way that could possibly be implemented? or is the > > word "extensible" remotely applicable to my idea? > > > So what you're talking about here is a graphical interface to the API that a > user can use to build his own extensions? Essentially, it's a graphical > programming language. There are quite a few examples of these in the music > world > that allow the construction of modular synths (amongst other things). Not only in the music world. Around 1993 or so, I remember using a program called Khoros Cantata to design some image filters. A quick search on the web returned this tutorial with screenshots of the old X11 version that I used: http://www.cse.psu.edu/~cg585/cantata-over.html Just imagine that the glyphs (the boxes that can be connected) could be the operations that GIMP offers through the PDB. It seems that Khoros Cantata has been acquired at least twice by different companies, has been ported to Windows, and is now sold as Accusoft VisiQuest: http://www.accusoft.com/products/visiquest/overview.asp The interface has changed a bit, but it is still based on the same ideas of connecting glyphs providing various functions. By the way, this brings back some memories about what I did in 1993 as an exercise for a course in digital imaging. Students were asked to write a new filter for Khoros and use it to perform some interesting image transformations. I decided to write a filter that would use various correlation methods to reconstruct an image in which the lines were shifted horizontally by some random amount. The default method was optimized for "un-shifting" images at TV resolution (PAL) that were shifted by one of three predefined offsets picked at random. The method worked surprisingly well. The code and the results were presented to the professor. He asked if, by any chance, this could be used to decode Canal+ images (a pay TV channel that was popular in several European countries). And the answer was yes. Not in real time because the 486 processors that were common at that time were not fast enough, but the method worked well with recorded TV streams (sometimes even without using inter- frame correlations). Ah, I still have fun when I remember this and when I consider that the professor gave one of the top marks for this exercise. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Amit Kumar Saha wrote: > Am i thinking in a way that could possibly be implemented? or is the > word "extensible" remotely applicable to my idea? > So what you're talking about here is a graphical interface to the API that a user can use to build his own extensions? Essentially, it's a graphical programming language. There are quite a few examples of these in the music world that allow the construction of modular synths (amongst other things). It sounds to me more like a separate companion program that's used to construct plug-ins than a plug-in itself. I like the idea very much. ---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)--- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
On Tue, 21 Aug 2007 15:48:15 +0530, "Amit Kumar Saha" <[EMAIL PROTECTED]> wrote: > Is there any way to make GIMP plugins themselves extensible. My point > here is that, can we make a GIMP plugin which allows itself modifiable > by a end-user to include a new functionality without much of a hassle > on part of the end-user. Does any one know of a method to do this or > any GIMP plugin which already does this? Besides the scripting languages mentioned by others, you could also take a look at the MathMap plug-in if you are good at math... MathMap home page: http://www.complang.tuwien.ac.at/schani/mathmap/ Nice examples of MathMap usage: http://www.flickr.com/groups/mathmap/ -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Amit Kumar Saha wrote: > Here is another way I thought I could give some form of > "extensibility" to a plugin user. Say, that I want my plugin to be a > single entry point to all the Image processing operations possible > with GIMP. Now your plug-in seems to become something I'd call GIMP. What use cases are you trying to handle, actually? Regards, Michael -- GIMP > http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki > http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins > http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Hello all, Here is another way I thought I could give some form of "extensibility" to a plugin user. Say, that I want my plugin to be a single entry point to all the Image processing operations possible with GIMP. What I do is display all the GIMP functions to the Plugin user via the Plugin User Interface(GUI). Then the user selects the operation that is to be performed and the plugin sets off to do the necessary job. I am assuming here that the functions of the GIMP that I list for the user is only those for which there exists a API entry in the libGimp. In the background when the user selects a particular operation, the corresponding API function is called. This is of course an assumption to simplify the thought process. Am i thinking in a way that could possibly be implemented? or is the word "extensible" remotely applicable to my idea? Waiting for your comments! -- Amit Kumar Saha [URL]:http://amitsaha.in.googlepages.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Hello Michael, 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 > 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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Hello Kevin, On 8/21/07, Kevin Cozens <[EMAIL PROTECTED]> wrote: > As Michael mentioned, using a scripting language such as Perl, Python, or Ruby > would be to do most things you might want to do. If you want to extend a > compiled plug-in that is also possible. > > Take a look at TinyScheme (used in the Script-Fu plug-in of the SVN version of > GIMP). It has the ability to use run-time loadable pre-compiled extensions. > The URL for TinyScheme is http://tinyscheme.sourceforge.net/. Could you please explain the "pre-compiled extensions"? Do you mean to say pre-compiled plugins loaded during runtime? > > The other scripting language plug-ins for GIMP also have ways to extend the > base language. The hooks used to allow scripts to tie in to GIMP use them. Please explain that in more details. Thanks a lot -- Amit Kumar Saha [URL]:http://amitsaha.in.googlepages.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Hello Michael, On 8/21/07, Michael Schumacher <[EMAIL PROTECTED]> wrote: > > Von: "Amit Kumar Saha" <[EMAIL PROTECTED]> > > Should it be more easy than writing e.g. a plug-in in Python? Yes. I am basically targeting end-users of GIMP,mainly GIMP. So learning Python for them might be not the best option due to variety of factors. Thanks -- Amit Kumar Saha [URL]:http://amitsaha.in.googlepages.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Karl Günter Wünsch wrote: > On Tuesday 21 August 2007, Michael Schumacher wrote: >> Should it be more easy than writing e.g. a plug-in in Python? > How about having a C++ virutal interface which you only have to fill in with > your own methods and GUI elements in a set dialog interface... > I have several things that I really would like to try and would require a > native compiled plugin. > But since there is no sound C++ interface to the innards of the GIMP :-(... There is no sound C++ interface for only one reason: nobody has written it yet. It should be fairly easy, especially since the C library GIMP builds upon was designed specifically to be easy to write wrappers for (GObject). - Martin Nordholts ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Amit Kumar Saha wrote: > Is there any way to make GIMP plugins themselves extensible. [snip] > I would appreciate even the slightest of insights. As Michael mentioned, using a scripting language such as Perl, Python, or Ruby would be to do most things you might want to do. If you want to extend a compiled plug-in that is also possible. Take a look at TinyScheme (used in the Script-Fu plug-in of the SVN version of GIMP). It has the ability to use run-time loadable pre-compiled extensions. The URL for TinyScheme is http://tinyscheme.sourceforge.net/. The other scripting language plug-ins for GIMP also have ways to extend the base language. The hooks used to allow scripts to tie in to GIMP use them. -- Cheers! Kevin. http://www.ve3syb.ca/ |"What are we going to do today, Borg?" Owner of Elecraft K2 #2172 |"Same thing we always do, Pinkutus: | Try to assimilate the world!" #include | -Pinkutus & the Borg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
> > Von: "Amit Kumar Saha" <[EMAIL PROTECTED]> > > Is there any way to make GIMP plugins themselves extensible. My point > > here is that, can we make a GIMP plugin which allows itself modifiable > > by a end-user to include a new functionality without much of a hassle > > on part of the end-user. 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? 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. 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. > Does any one know of a method to do this or > > any GIMP plugin which already does this? I'm not aware of any plugins that provide this though it wouldn't suprise me if someone had already done something similar. Plugin interfaces are a standard part of many applications these days but I think you'd be hard pressed to find any that don't require some level of programming expertise to use. -- Michael J. HammelSenior Software Engineer [EMAIL PROTECTED] http://graphics-muse.org -- Memory is a Net - Oliver Wendell Holmes, Sr. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
On Tuesday 21 August 2007, Michael Schumacher wrote: > Should it be more easy than writing e.g. a plug-in in Python? How about having a C++ virutal interface which you only have to fill in with your own methods and GUI elements in a set dialog interface... I have several things that I really would like to try and would require a native compiled plugin. But since there is no sound C++ interface to the innards of the GIMP :-(... -- mfg Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
> Von: "Amit Kumar Saha" <[EMAIL PROTECTED]> > Is there any way to make GIMP plugins themselves extensible. My point > here is that, can we make a GIMP plugin which allows itself modifiable > by a end-user to include a new functionality without much of a hassle > on part of the end-user. Does any one know of a method to do this or > any GIMP plugin which already does this? Should it be more easy than writing e.g. a plug-in in Python? HTH, Michael -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Extending GIMP Plugins
Hello all, GIMP plugins extend GIMP, we know that. Is there any way to make GIMP plugins themselves extensible. My point here is that, can we make a GIMP plugin which allows itself modifiable by a end-user to include a new functionality without much of a hassle on part of the end-user. Does any one know of a method to do this or any GIMP plugin which already does this? I would appreciate even the slightest of insights. Thanks a lot! Regards -- Amit Kumar Saha [URL]:http://amitsaha.in.googlepages.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
