Re: [Gimp-developer] Extending GIMP Plugins

2007-08-28 Thread Øyvind Kolås
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

2007-08-27 Thread Øyvind Kolås
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

2007-08-27 Thread Amit Kumar Saha
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

2007-08-27 Thread Kevin Cozens
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 disclaimer/favourite |  -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

2007-08-25 Thread Amit Kumar Saha
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

2007-08-25 Thread Amit Kumar Saha
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

2007-08-25 Thread gg
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

2007-08-25 Thread David Hodson
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

2007-08-25 Thread Kevin Cozens
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 disclaimer/favourite |  -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

2007-08-25 Thread Amit Kumar Saha
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

2007-08-22 Thread Amit Kumar Saha
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

2007-08-22 Thread Michael Schumacher
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

2007-08-22 Thread Raphaël Quinet
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

2007-08-22 Thread David Marrs
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

2007-08-22 Thread Raphaël Quinet
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

2007-08-22 Thread Renan Birck
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

2007-08-22 Thread Øyvind Kolås
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

2007-08-22 Thread Kevin Cozens
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 disclaimer/favourite |  -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

2007-08-22 Thread Amit Kumar Saha
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

2007-08-21 Thread Michael Schumacher
 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


Re: [Gimp-developer] Extending GIMP Plugins

2007-08-21 Thread Karl Günter Wünsch
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

2007-08-21 Thread Michael J. Hammel
  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

2007-08-21 Thread Kevin Cozens
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 disclaimer/favourite |  -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

2007-08-21 Thread Martin Nordholts
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

2007-08-21 Thread Amit Kumar Saha
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

2007-08-21 Thread Amit Kumar Saha
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