RSS/Atom feed Twitter
Site is read-only, email is disabled

Bug 132698 - Script-Fu constants vs DB Browser

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

12 of 12 messages available
Toggle history

Please log in to manage your subscriptions.

Bug 132698 - Script-Fu constants vs DB Browser Kevin Cozens 29 Jan 18:27
  Bug 132698 - Script-Fu constants vs DB Browser Sven Neumann 29 Jan 18:45
   Bug 132698 - Script-Fu constants vs DB Browser Kevin Cozens 29 Jan 20:00
    Bug 132698 - Script-Fu constants vs DB Browser Sven Neumann 29 Jan 22:06
     Bug 132698 - Script-Fu constants vs DB Browser Kevin Cozens 29 Jan 23:12
  Bug 132698 - Script-Fu constants vs DB Browser Marc) (A.) (Lehmann 30 Jan 15:01
   Bug 132698 - Script-Fu constants vs DB Browser Kevin Cozens 30 Jan 17:57
    Bug 132698 - Script-Fu constants vs DB Browser Marc) (A.) (Lehmann 30 Jan 19:06
     Bug 132698 - Script-Fu constants vs DB Browser Kevin Cozens 30 Jan 20:19
      Bug 132698 - Script-Fu constants vs DB Browser Marc) (A.) (Lehmann 31 Jan 02:24
       Bug 132698 - Script-Fu constants vs DB Browser Kevin Cozens 01 Feb 20:39
    Bug 132698 - Script-Fu constants vs DB Browser Sven Neumann 02 Feb 14:42
Kevin Cozens
2004-01-29 18:27:44 UTC (about 20 years ago)

Bug 132698 - Script-Fu constants vs DB Browser

Greetings.

I reported something I saw as a bug [bugzilla #132698] and Sven replied that DB Browser shows enum values used for arguments (ie. GIMP_RGB_IMAGE) as they would be used from C plug-ins. It would seem I haven't been following the GIMP development closely enough since I wasn't aware of this. It raises a number of questions though.

Is the - vs _ use in function names by C vs. Script-Fu historical (as in typical of the respective languages)?

Barring the issue of - vs _, why should we have a different set of enum values for plug-ins based on different languages? DB Browser shows GIMP_RGB_IMAGE for an image type (for C) but its only RGB-IMAGE for Script-Fu scripts and I have no idea off-hand what it would be for Perl plug-ins (a third set of enums?).

One could also argue against the C format being chosen for display in DB Browser since a GIMP user would find it much easier (and would be more likely?) to develop their own plug-ins at first in Script-Fu (or possibly Perl) since all they need is a text editor and there are other scripts which can be used as a starting point.

I'm also raising issue also because I thought that one of the goals for the 2.0 release is to simplify/tidy-up some things. Having more consistency in the enums used (regardless of language used for a plug-in/script and ignore - vs _ issues) makes sense (to me at least). Trying to get DB Browser to display different information based on you telling it which type of plug-in one wants to create is probably not a good alternative. I think it would add too much complexity and be hard to maintain.

Comments?

Cheers!

Kevin. (http://www.interlog.com/~kcozens/)

Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg

Sven Neumann
2004-01-29 18:45:27 UTC (about 20 years ago)

Bug 132698 - Script-Fu constants vs DB Browser

Hi,

Kevin Cozens writes:

I'm also raising issue also because I thought that one of the goals for the 2.0 release is to simplify/tidy-up some things. Having more consistency in the enums used (regardless of language used for a plug-in/script and ignore - vs _ issues) makes sense (to me at least). Trying to get DB Browser to display different information based on you telling it which type of plug-in one wants to create is probably not a good alternative. I think it would add too much complexity and be hard to maintain.

What are you advocating instead? Perhaps I just missed something but I have not been able to figure out what change you are proposing.

The issue you raise has been around forever and it seems that so far you are the first one to find it disturbing enough to talk about it. Perhaps something should be done about this but I don't think it's a severe problem that would justify an incompatible change to any of the language bindings. IMO any language should be free to use the GIMP enum values in the way that is typical for the particular language. Script-Fu uses hyphens traditionally; why should we force it to using the (uglier) underscores that have to be used in the C language?

Sven

Kevin Cozens
2004-01-29 20:00:18 UTC (about 20 years ago)

Bug 132698 - Script-Fu constants vs DB Browser

At 12:45 PM 01/29/2004, Sven wrote:

What are you advocating instead? Perhaps I just missed something but I have not been able to figure out what change you are proposing. The issue you raise has been around forever and it seems that so far you are the first one to find it disturbing enough to talk about it.

I thought I had explained it in the bug report I filed but I will me try to make it clearer.

In regards to the second point, perhaps it has disturbed other people but not enough to have mentioned it. you said yourself, Sven, in a comment to a bugzilla entry something to the effect that no one has expressed an interest in Script-Fu. I am still interested in Script-Fu. I am involved in a number of other projects so I haven't made the time to learn how to do a C-based plug-in. I find it easier to use Script-Fu to make a script that automates a set of steps I came up with to automate a procedure.

In regards to the first point, I am advocating that the enum values shown in DB Browser (for C) be the same as the ones used in Script-Fu scripts (and other language bindings) to provide a better level of consistency across all plug-ins. That way, something you learned to use in one plug-in language doesn't have to be unlearned when you use a different language for plug-ins.

For example, if I look in DB Browser for creating a new image, one of the enums shown for argument type is GIMP_RGB_IMAGE. So, since I know for Script-Fu scripts I use - in place of _, I would use GIMP-RGB-IMAGE. When I try running a script with this as things stand now, I will get an error message and be left scratching my head wondering what is wrong with the script since I followed the information shown in DB Browser.

You, I, and many people on this list may have the source code available on their machines to figure out what the Script-Fu constants are as compared to what is shown in DB Browser but how many others will? Lately, I only update the collection of scripts on my web page to work with the latest GIMP when API changes. This means it can be a long time from one session of working with Script-Fu to another at my end. The handiest reference I have to refresh me on Script-Fu functions and their arguments is the DB Browser.

An alternative would be to have a section of the help system explain that the information in DB Browser is for C plug-ins and provide a list showing the mapping between C enums to those of Script-Fu. This would still mean I have to dig through the help system when the DB Browser is still the quickest "help" system to access. Also, the help system can lag behind the state of the code at times too so it is not the best method during times of big changes.

It would be easier if I could use GIMP-RGB-IMAGE in Script-Fu scripts as I would be led to believe from DB Browser. The only change needed to DB Browser would be adding the display of a comment before (or after) the functions entry information stating something like "For Script-Fu scripts, change the _ in function names and arguments to -".

Perhaps something should be done about this but I don't think it's a severe problem that would justify an incompatible change to any of the language bindings.

If we are to make such a change, now is the time to do it. After all, we are going from a 1.2 release to a 2.0 release so it is to be expected that changes would need to be made to plug-ins from 1.2 to make them work in the new 2.0 version. The next opportunity to make a change would be for 2.2 which might be another year or two down the road but one wouldn't expect such incompatibilities in a "minor" bump in version (2.0 to 2.2).

Changing enums (if one doesn't add new ones and make the old ones deprecated for a while) would mean most (or all) supplied scripts would need to be updated. I have a perl script which updates Script-Fu scripts from the 1.2 to 2.0 versions of the GIMP (except for three functions which have different argument lists). If enums were to change for Script-Fu it would be relatively easy to enhance my script to handle changes to enums as well. BTW, I will make the script available soon for others to try in case there are others out there who find old scripts they want to use with the 2.0 version of GIMP.

PS. To all, please don't reply to messages I post to the list AND CC: me as well. Doing so gives me two copies of your message and I get enough e-mail already. I have been a subscriber to this list, and made my small contributions to the GIMP, since the days of the 0.9 series of the GIMP. I have been on gimp-announce too since late 1997.

Cheers!

Kevin. (http://www.interlog.com/~kcozens/)

Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg

Sven Neumann
2004-01-29 22:06:49 UTC (about 20 years ago)

Bug 132698 - Script-Fu constants vs DB Browser

Hi,

Kevin Cozens writes:

For example, if I look in DB Browser for creating a new image, one of the enums shown for argument type is GIMP_RGB_IMAGE. So, since I know for Script-Fu scripts I use - in place of _, I would use GIMP-RGB-IMAGE. When I try running a script with this as things stand now, I will get an error message and be left scratching my head wondering what is wrong with the script since I followed the information shown in DB Browser.

So the easiest solution would be to make script-fu accept the enums with or without prefix.

If we are to make such a change, now is the time to do it.

The point is that it is already way too late to do any major incompatible change. Our API was frozen from the moment we did the first 2.0pre release.

However I don't see any problem in accepting a patch for Script-Fu that makes it accept enums prefixed with "GIMP-". Should be a trivial change.

The next opportunity to make a change would be for 2.2 which might be another year or two down the road but one wouldn't expect such incompatibilities in a "minor" bump in version (2.0 to 2.2).

Since we want 2.2 to be API compatible with 2.0, we couldn't do an incompatible change for 2.2. On the other hand 2.2 is scheduled for this summer, not in a year or two.

Sven

Kevin Cozens
2004-01-29 23:12:12 UTC (about 20 years ago)

Bug 132698 - Script-Fu constants vs DB Browser

At 04:06 PM 01/29/2004, you wrote:

So the easiest solution would be to make script-fu accept the enums with or without prefix.

That would be the easiest solution and maintains compatibility with existing scripts.

The point is that it is already way too late to do any major incompatible change. Our API was frozen from the moment we did the first 2.0pre release.

I realize that. I had no intention of suggesting a change to the API. Just a change to the enums/constants used by Script-Fu.

However I don't see any problem in accepting a patch for Script-Fu that makes it accept enums prefixed with "GIMP-". Should be a trivial change.

Since it was my suggestion, I suppose that falls in my lap. :-) I'm fairly certain it is trivial. It is more a matter of ensuring that the additions to what is accepted match against what is shown in the DB Browser. If all "internal" enums/constants start with GIMP- then no problem.

The only remaining question is whether the old (non "GIMP-" prefixed) enums for Script-Fu should be deprecated for later removal and how that should be indicated (or just documented). I will check the help documentation to see if there is any information about Script-Fu scripts that would need to be updated/changed.

Cheers!

Kevin. (http://www.interlog.com/~kcozens/)

Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg

Marc) (A.) (Lehmann
2004-01-30 15:01:50 UTC (about 20 years ago)

Bug 132698 - Script-Fu constants vs DB Browser

On Thu, Jan 29, 2004 at 12:27:44PM -0500, Kevin Cozens wrote:

Is the - vs _ use in function names by C vs. Script-Fu historical (as in typical of the respective languages)?

Yupp.

values for plug-ins based on different languages? DB Browser shows GIMP_RGB_IMAGE for an image type (for C) but its only RGB-IMAGE for Script-Fu scripts and I have no idea off-hand what it would be for Perl plug-ins (a third set of enums?).

Just FYI, perl uses the enums.pl from the gimp core which lists all the enums. It does, however, do this:

$const =~ s/^GIMP_//;

i.e.., strip the GIMP_-prefix, so the contants are the names with "_" (easier to type in perl than "-"), but withouth the prefixes. Looks like a third set to me.

(Also, perl isn't updated automatically, you have to run a script, so it might be sightly out of sync).

Kevin Cozens
2004-01-30 17:57:32 UTC (about 20 years ago)

Bug 132698 - Script-Fu constants vs DB Browser

At 09:01 AM 01/30/2004, Marc Lehmann wrote:

Just FYI, perl uses the enums.pl from the gimp core which lists all the enums. It does, however, do this:

$const =~ s/^GIMP_//;

i.e.., strip the GIMP_-prefix, so the contants are the names with "_" (easier to type in perl than "-"), but withouth the prefixes. Looks like a third set to me.

A third set? I was afraid that might be the case.

(Also, perl isn't updated automatically, you have to run a script, so it might be sightly out of sync).

I will take a look at the way gimp-perl does things. The script should be invoked during a build process as it is for the core part of GIMP.

Sven isn't sold on the idea of deprecating some of the constants yet. We already have deprecated constants as you can see in the comments in the siod-wrapper.c file.

Another way to look at this is from he point of view of help/documentation. Someone has to create information somewhere that documents the constants used for plug-ins (whether they be C-based, Script-Fu, or Perl). If we have one set of constants for use in all plug-in languages the constants only need be documented once for C. For other languages you would need a one liner explaining whether they are the same as for C or whether you need to change _ to - and you are done. Otherwise, you need to have two or three lists all of which need to be updated if/when the API changes.

Cheers!

Kevin. (http://www.interlog.com/~kcozens/)

Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg

Marc) (A.) (Lehmann
2004-01-30 19:06:04 UTC (about 20 years ago)

Bug 132698 - Script-Fu constants vs DB Browser

On Fri, Jan 30, 2004 at 11:57:32AM -0500, Kevin Cozens wrote:

i.e.., strip the GIMP_-prefix, so the contants are the names with "_" (easier to type in perl than "-"), but withouth the prefixes. Looks like a third set to me.

A third set? I was afraid that might be the case.

Well, a set extremely similar and in-sync (at least loosely) to the C contants, so while technically different constant names, there is a very easy rule to convert from C to Perl: drop the GIMP_. The gimpdoc program already converts between C and Perl method syntax, so it could just be extended to drop DIMP_ for Contants, too.

The pdb documentation is "almost" parseable nowadays (or at leats when I last looked).

I will take a look at the way gimp-perl does things.

Constants are hardcoded in Gimp.pm, and there is a program named insenums which will replace these in-place.

The script should be invoked during a build process as it is for the core part of GIMP.

Not so quickly ;) Changes in these enums will immediately break existing scripts, which is a very bad thing. Also, some wild renaming during the 1.3 era resulted in duplicated constants that had to be resolved differently, so this usually involves some manual work, which is why the script has to be run manually, too.

Another way to look at this is from he point of view of help/documentation. Someone has to create information somewhere that documents the constants used for plug-ins (whether they be C-based, Script-Fu, or Perl). If we have one set of constants for use in all plug-in languages the constants only need be documented once for C.

I am not sure wether I understand your concept of "sameness". To me, GIMP_RGB_IMAGE, RGB-IMAGE and RGB_IMAGE is exactly the same constant, just as gimp-drawable-add-layer is the same as gimp_drawable_add_layer and $drawable->add_layer.

For other languages you would need a one liner explaining whether they are the same as for C or whether you need to change _ to - and you are done.

This is the situation with perl right now, although that line is probably hard to find, but people don't read this type of documentation anyway, they just look at other scripts, and then consistency really pays off.

Kevin Cozens
2004-01-30 20:19:56 UTC (about 20 years ago)

Bug 132698 - Script-Fu constants vs DB Browser

On Fri, 2004-01-30 at 13:06, pcg@goof.com wrote:

On Fri, Jan 30, 2004 at 11:57:32AM -0500, Kevin Cozens wrote:

A third set? I was afraid that might be the case.

Well, a set extremely similar and in-sync (at least loosely) to the C contants, so while technically different constant names, there is a very easy rule to convert from C to Perl: drop the GIMP_. The gimpdoc program already converts between C and Perl method syntax, so it could just be extended to drop DIMP_ for Contants, too.

I will take a look at the way gimp-perl does things.

Constants are hardcoded in Gimp.pm, and there is a program named insenums which will replace these in-place.

For Script-Fu, the leading GIMP- part was being dropped. I will leave the gimp-perl stuff alone for now but for consistancy, it should be updated to accept the "new" versions of the enums as well as the existing (backwards compatible) ones.

I am not sure wether I understand your concept of "sameness". To me, GIMP_RGB_IMAGE, RGB-IMAGE and RGB_IMAGE is exactly the same constant, just as gimp-drawable-add-layer is the same as gimp_drawable_add_layer and $drawable->add_layer.

It is a case of "a rose by any other name" or in this case "a constant by any other name" to paraphrase Shakespeare. Yes, GIMP_RGB_IMAGE, RGB-IMAGE, and RGB_IMAGE are numerically the same. If you use numerical values for function call arguments, then you use the same numbers regardless of plug-in language. On the other hand, if you want to create a new image using an indexed palette its easier to remember to use GIMP_INDEXED_IMAGE rather than 4 or was that INDEXED_IMAGE, or INDEXED-IMAGE? What type of plug-in am I writing again? :-) You get the idea.

For other languages you would need a one liner explaining whether they are the same as for C or whether you need to change _ to - and you are done.

This is the situation with perl right now, although that line is probably hard to find, but people don't read this type of documentation anyway, they just look at other scripts, and then consistency really pays off.

Thats right. People often don't RTFM apart from the difficulty one often has finding relevant documentation. If you go to http://www.gimp.org/, click on documentation, scroll down to the PDB section, then click on the "Procedural Data-Base" link you get a page called pdb.html. Under "Browsing the PDB", it states the following:

Because the PDB includes info about plugins, scripts, and extensions, it is very dynamic. The easiest way to search and browse the PDB is to use the DB Browser extension included with the gimp. This is located under the Xtns menu on the main toolbar and allows you to browse and search through the PDB. Very handy.

Followed a bit further down with: A typical use of the PDB is to write scripts or plugins.

Very handy indeed, and no reference to differences in the named constants based on whether you are writing a script or a (C-based) plug-in. Another reason to keep things close to what is listed under the DB Browser. People are told to use the DB Browser information and yet, it provides misleading information that could frustrate the budding new script writer out there.

And finally, on line 263 of plug-ins/script-fu/siod-wrapper.c is a comment which reads:
These are for backwards compatibility; they should be removed sometime

Following that comment are statements which allow the parser to understand the older constants (ie. the ones not starting with GIMP-). I ran a CVS annotate on this file and that comment and the start of the code below to which allows the accepting of the older forms of constants was in the file since the 1.1 version entered by user mathieu and dated July 17, 2001.

It appears in the end that I have merely finished something that was started a long time ago. My patch to accept both old and new forms of the constants is attached to the bug report. I also have the patch and my script to convert from the 1.2 API to the 2.0 API on my web page at: http://pages.interlog.com/~kcozens/software/gimp/updates.html

If you want to include the conversion script as part of the GIMP source (as a replacement for plug-ins/script-fu/convert-script) feel free to do so.

I have made my case for making the change and provided a patch (sorry I forgot to include a ChangeLog entry), and script to update things to the 2.0 API. I now leave it in the hands of the judges...er...core GIMP developers to decide what they want to do with this. At least I will have a patch I can apply to my own copy of the GIMP should the patch not become part of the official GIMP source.

Marc) (A.) (Lehmann
2004-01-31 02:24:58 UTC (about 20 years ago)

Bug 132698 - Script-Fu constants vs DB Browser

On Fri, Jan 30, 2004 at 02:19:56PM -0500, Kevin Cozens wrote:

regardless of plug-in language. On the other hand, if you want to create a new image using an indexed palette its easier to remember to use GIMP_INDEXED_IMAGE rather than 4 or was that INDEXED_IMAGE, or INDEXED-IMAGE?

In perl, INDEXED-IMAGE needs to be quoted rather unnaturally (&{'INDEXED-IMAGE'}), so perl users won't bother thinking about this. Also, perl, unlike C, has mostly working namespaces, so prefixing each and everything with an application/module name like GIMP_ is not necessary.

Things are similar for script-fu (there are no namespace issues in script-fu because it's self-contained and _ looks rather unnatural, I think).

If somebody wants to write a plug-in in perl who only ever had written plug-ins in C will have to think twice (at least), there is no doubt. But a user having used perl before will look at some existing script anyways (nobody writes plug-ins from scratch).

Think about the GIMP_ prefix as C's way to handle namespaces. As such, it's part of the C calling convention only. This is handled different in perl (Gimp::INDEXED_IMAGE or just INDEXED_IMAGE) and script-fu (script-fu does not have a module or library concept to my knowledge, the the problem of namespaces does not apply).

What type of plug-in am I writing again? :-) You get the idea.

Frankly, people forgetting which type of plug-in (in which language) they are currently writing need professional help *g*.

I am rather convinced that the number of people who can't remember that they are currently writing C as opposed to scheme is rather low compared to people that are aware of this.

DB Browser. People are told to use the DB Browser information and yet, it provides misleading information that could frustrate the budding new script writer out there.

The DB Browser information should be consistent (i.e. for C _or_ scheme). The information in the DB Browser will never apply to perl (python...) unless it would have a "perl mode", as perl simply is a different language with different calling conventions.

Constant names are a much smaller difference than calling conventions between languages. It is, in general, impossible to use an API for one language in another without adapting it to the target language.

And finally, on line 263 of plug-ins/script-fu/siod-wrapper.c is a comment which reads:
These are for backwards compatibility; they should be removed sometime

It appears in the end that I have merely finished something that was

Cleaning up things by removing cruft like this is very useful, and often being overlooked. Thanks for doing this :=>

I'd also find it cool if you looked into the DB Browser and made it "fully scheme" or "fully C", i.e. consistent at least to one language. However, the idea of having the same API, character-for-character, in all languages is futile. Don't bother with it.

Changing script-fu to comply with this sounds ok, changing the Browser to comply with script-fu is better, but more difficult (right now it's a mix of both, or maybe the "abstract PDB language"?).

Perl specifically has a tool named gimpdoc, which shows calling conventions in perl, e.g.:

layer = gimp_layer_new (image,width,height,type,name,opacity,mode) layer = $image->layer_new (width,height,type,name,opacity,mode)

Which is close to actual perl, and should give developers the right idea. It should convert constant names to perl form, too (it currently doesn't, AFAICR). Having this info in the DB Browser might be useful, but making the interface support all languages is quite difficult.

One could also argue that the DB Browser does things the "abstract PDB" way, and is fine this way, although a bit unspecified, as long as rules exist to convert them to specific implementations. In the case of perl, these rules are stated in the Gimp manpage, which is a must-read if you want to develop plug-ins from scratch.

Kevin Cozens
2004-02-01 20:39:57 UTC (about 20 years ago)

Bug 132698 - Script-Fu constants vs DB Browser

At 08:24 PM 01/30/2004, you wrote:

What type of plug-in am I writing again? :-) You get the idea.

Frankly, people forgetting which type of plug-in (in which language) they are currently writing need professional help *g*.

You are right, the probably would need help. :-) Of course, what I was getting at is a given individual that writes plug-ins using different languages. For example, I have been working with Script-Fu scripts recently and I have now started to look at porting a C-based plug-in to the latest API so I will need to remember that now I need to add GIMP_ to the start of constants.

I went back and updated the script on my web site to convert only those named constants listed in siod-wrapper.c as deprecated to the current API (and without the leading GIMP-). Later on, I may add a switch to allow all constants to be updated to the current API (and let it include the GIMP-). I will run the script against the current Script-Fu scripts which come with GIMP and produce a diff of the results to see how many (if any) need to be updated to allow later removal of the compatibility code in the siod-wrapper.c file.

I will post a new message shortly regarding the comments related to DB Browser as I feel they belong in a new thread since that discussion is not directly related to the current thread.

Cheers!

Kevin. (http://www.interlog.com/~kcozens/)

Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg

Sven Neumann
2004-02-02 14:42:35 UTC (about 20 years ago)

Bug 132698 - Script-Fu constants vs DB Browser

Hi,

Kevin Cozens writes:

Another way to look at this is from he point of view of help/documentation. Someone has to create information somewhere that documents the constants used for plug-ins (whether they be C-based, Script-Fu, or Perl).

Are you talking about the API docs at developer.gimp.org?

Sven