Frequently Asked Questions

GIMP development is coordinated by Wilber the GIMP along with a loosely knit team of GIMP developers. The developers can be reached through the GIMP developer mailing list.

If you are a developer who wants to start contributing code to the GIMP, the best way to get to know its structure is by fixing bugs reported in Bugzilla. Pick a bug, perhaps ask the advice of another developer as to whether he/she thinks it will be an easy bug or not, and then fix it. Sounds easy, doesn't it?

After helping with a couple of bugs, people will start to recognize your immense talent, and you will be on your way to becoming a GIMP hacker. Any time you feel able, you can pick a smaller enhancement request and have a go at implementing it. It's that easy.

There are several mailing lists associated with the GIMP project. Developments related issues can be brought up on the GIMP Developer mailing list.

The GIMP has its own IRC channel on GIMPNet where most of the active developers hang out. Join us in #gimp on irc.gimp.org.

Every once in a while the GIMP developers get together for a few days to throw a GIMP Developers Conference, also referred to as GIMPCon.

You can pass --enable-gtk-doc to the gimp configure script. This requires having gtk-doc installed. After running make you can find the GIMP API reference in the devel-docs directory.

Pre-generated API documentation is included in the official GIMP tarballs.

The API reference will normally be installed in PREFIX/share/gtk-doc/html. An on line version of the GIMP API reference can be found here.

A stack trace is a list of function calls that leads to some point in the program. Debugging tools like gdb can get stack traces from crashed applications so that developers can figure out what went wrong. By including a stack trace with your bug report, it will be much easier for the developers to fix the reported problem.

Information on how to make a stack trace can be found in the document Capturing Stack Traces.

The best way to submit a patch is to open a bug report in Bugzilla and attach the patch there along with a description of what it does and why it should be applied.

An introduction to how this is done can be found in the How To Create and Submit a Patch document.

We encourage you to follow the GIMP coding style throughout the GIMP project. For the core components (application and libs) this coding style is enforced. The GIMP coding style is defined as follows:

Try to make use of GLib's object system as much as possible. Do not create wrappers around functions of parent classes. If you end up duplicating code, try to create a common parent class and implement the common methods there.

Don't include headers in headers except where unavoidable (e.g. for deriving objects). Opaque typedefs go to app/base/base-types.h, app/core/core-types.h etc. See devel-docs/includes.txt for a detailed description of the include policy.

Don't use the GTK wrappers around the GLib object and signal system.

The above coding style, along with other useful information, is documented in the file HACKING.

Your editor will not be able to do everything for you, but you can configure most editors so that they use two spaces for indentation, use spaces instead of tabs, etc.

Any help with translations is appreciated. If you want to help, please get in contact with the people from the GNOME Translation Project who coordinate all translation efforts for projects hosted in the GNOME GIT repository.

More information about GIMP and localisation can be found in the file README.i18n.

By using GIMP and reporting any bugs you find to Bugzilla you're helping a great deal. But there are other non-technical ways of supporting the development of The GIMP as well.

GIMP has a web site, application documentation, lots of tutorials, and more. Unfortunately, as GIMP develops over time, much of this documentation needs to be re-written or freshened up, documentation needs to be added for new functionality, the web site needs to get a new lick of paint and so on.

If you're interested in helping out you should drop an e-mail to the GIMP developer mailing list offering your help.

Yes. An official GIMP plug-in template is available in the gimp-plugin-template git module. Snapshots are available at ftp.gimp.org.

Yes. Simon Budig has written a fill-in-the-blanks Script-Fu template which is available here.

The best way to make your plug-in available to the World is to submit it to the GIMP Plug-In Registry.

If you are certain that your plug-in will be useful to all GIMP users, then you can ask the GIMP developers to consider it for inclusion in future GIMP release. The best way to do that is to suggest it on the GIMP developer mailing list or to open an enhancement request in Bugzilla. However, we would like to limit the number of plug-ins included in the standard distribution and encourage all users to use the registry.

Eeek! The plug-in you're working on has a bug in it! And the fix isn't completely obvious, so you want to use debugger to see what is going on. But hmm, how does one start a plug-in under a debugger if GIMP is the one who is starting the plug-in...

To address this issue, libgimp has some hooks controlled by the GIMP_PLUGIN_DEBUG environment variable. The idea is that you can attach a debugger to the pid of the plug-in you want to debug. The process is described in the file debug-plug-ins.txt.

The short answer is yes. GIMP 2.2 and 2.4 are binary compatible with plug-ins compiled for GIMP 2.0. The API is also backwards source compatible, so your plug-in should also compile cleanly against GIMP 2.2 and 2.4.

If the plug-in you compiled for 2.0 does not work with 2.2 or 2.4, there is one change which has been made which is not backwards compatible, since the old behaviour was considered incorrect. If you create a temporary drawable, using for example gimp_layer_new(), you are now required to add it to an image before calling any functions with the drawable as an argument.

Please put a short explanation of the change on the first line. Then, after an empty line, you can describe the change in more detail using as many lines as you need. Try not to exceed 72 colums.

If the commit fixes a bug or part of a bug please use the bug number and description as the first line of the commit message. It's most convenient to just copy the line from the Bugzilla bug page.

GEGL is the Generic Graphical Library. It is supposed to replace the handling of various image processing tasks in GIMP in a not too distant future (planned for GIMP 2.6).

GEGL will be a general image processing library. It uses a directed acyclic graph, a DAG, to represent image processing operations. In the DAG, images are edges, and operations are nodes. It takes advantage of this DAG to minimize regions which are processed, provide efficient caching of operations, and efficient redrawing when a parameter of the graph changes.

GEGL should also be independent of the data type being processed and will be able to handle high bit depth images, ICC profiles and parallel processing of image tiles.

Many highly requested features of the GIMP will be easier to do using GEGL. Layer effects, layer groups, and adjustment layers are quite easily represented (and efficiently calculated) using the DAG organization of GEGL. CMYK and high bit depth support will be easier because GEGL does not make the same assumptions about color spaces and data types that the GIMP does.

The reusability of image processing operations means that plug-ins will be able to be designed in a much more modular way. The brush system will be able to become more flexible, especially when filter plug-ins are able to be used as procedural brush plug-ins.

The GIMP project uses GNOME Bugzilla for tracking of bug reports, enhancement requests etc.

A beginners tutorial describing how to report a bug can be found in the How To Report GIMP Bugs document.

An easy to use interface to reporting GIMP bugs can be found on bugs.gimp.org.

If the status of a bug is changed to NEEDINFO it means the GIMP developers need more information from the bug reporter in order to resolve the bug.

More information about the meaning of the Bugzilla status field codes can be found in A Bug's Life Cycle.

The best way to refer to a bug is “bug #nnnnn”, where nnnnn is the bug number. Using “bug” before the number allows Bugzilla to link to the corresponding bug report automatically. Using “#” before the number is optional for Bugzilla but makes it easier to locate references to bug reports in the ChangeLog or in e-mails.

When referencing multiple bugs, it is better to be a bit redundant by writing “bug #xxxxx, bug #yyyyy and bug #zzzzz” instead of “bugs #xxxxx, #yyyyy and #zzzzz” in order to allow Bugzilla to link all bugs automatically.

A bug report describing the same bug as a previous bug report should be marked as DUPLICATE of the older one. In some exceptional cases, it is possible to mark an old bug report as DUPLICATE of a newer one (e.g., when the newer bug report has a significantly better description than the older one).

Another exception is when the same person submits the same bug report several times (same description): in this case, it is better to mark the additional copies of the bug report as INVALID in order to avoid inflating the statistics about the number of duplicates.

When fixing a bug, always mention the bug number in the commit message. Once the changes are in git, paste the relevant part of the commit message (or all of it) in the comment field and mark the bug as RESOLVED FIXED. These cross-references help a lot when trying to find when a bug was fixed, its relations to other bugs, and potential regressions.

A bug that is fixed in git or in an unstable release should be marked as RESOLVED FIXED. Optionally, the reporter or someone other than the one who fixed the bug can mark it as VERIFIED after some testing. When the fix is part of a stable release, it can be marked as CLOSED.

This is explained further in A Bug's Life Cycle except for the difference between stable and unstable releases.

The GObject documentation has a nice tutorial that you might want to have a look at.

Charles Poynton has collected a set of Frequently Asked Questions about Color.

A good source of information is the comp.graphics.algorithms list of Frequently Asked Questions.

There is no user FAQ available at the moment. However there has been discussions about creating one. If you would like to help with this please drop a mail on the GIMP developer mailing list.

If you would like to contribute to this FAQ, send an e-mail to the GIMP developer mailing list with the exact text you think should be included (both question and answer).

With your help this FAQ will grow and become more useful.