Frequently Asked Questions

Table of Contents

Below you will find a collection of frequently asked questions regarding development of the GIMP.

GIMP Development

Who coordinates GIMP development?

GIMP development is coordinated by Wilber the GIMP along with a loosely knit team of GIMP developers. The developers can be reached mostly through IRC (see the Discuss page) and the bug tracking system.

Every once in a while, GIMP developers can get together for a few days. See the Conferences section.

Who coordinates the GIMP translation efforts?

Translations is organized by teams for each language. The recommended way is therefore to contact the specific team for your language (each team may have different rule, their dedicated page will give you specifics). Any help with translations is appreciated.

Note that you usually don’t need to get in touch with developers to start and translate GIMP since everything happens through GNOME localization infrastructure. Yet if you want to discuss with developers, or if you have any problem with the aforementionned procedure, all contributors are happy to mingle. Feel free to get in touch with developers.

How do I make a stack trace?

A stack trace is a list of function calls that leads to some point in the program. 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 good stack trace or logs can be found in our document named “Debugging Tips”.

What is the best way to submit a patch?

If you are a developer who wants to start contributing code to GIMP, the best way to get to know its structure is by fixing bugs reported in Gitlab. 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 and contribute a merge request.

The Core Development section is where you want to start.

What is the preferred coding style used in GIMP?

We do have an own “GIMP Coding Style”. Please follow the coding style document throughout the GIMP project. This coding style is enforced for every new code in the official repositories.

How can I configure my editor for this coding style?

We provide configuration files for a few editors and welcome more configuration files for anyone wishing to contribute one for their favorite editor or Integrated Development Environment (IDE).

Where can I find documentation for the GIMP API?

See the GIMP API reference page.

There is another way to support GIMP development?

Yes. There are other non-technical ways of supporting the development of The GIMP as well. See the [“Get Involved”] (https://www.gimp.org/develop/) page of GIMP web site on how to offering your help.

Last, but not least, donating to GIMP supports a lot the development, especially as several developers are trying and make a living by developing GIMP full-time.

Plug-In Development

Is there a plug-in template available?

Sorry but no. Better, please check the nice tutorials, which will teach you through the process of writing and understanding your plug-in.

How do I debug a GIMP plug-in?

See: “Debugging Plug-ins” document

How do I get my plug-in included in GIMP?

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 by creating a merge request.

However, we have been trying to limit the number of plug-ins included in the standard distribution to the most common usage only. Therefore do not expect this to to happen if your proposed plug-in caters to a specific usage.

Will my 2.x plug-in work with GIMP 3.x?

No. A major release is the occasion to fix wrong design choices, therefore the API compatibility is usually broken. It means some part of your plug-in will have to be rewritten.

What you need to rewrite is mostly infrastructure code (how the plug-in is registered) and a few calls to glue internal logics and your plug-in logics. In the end, porting your code may be frightnening but it can be done very quickly.

GEGL

What is GEGL?

GEGL is the Generic Graphical Library. It is replaced the handling of various image processing tasks in GIMP, starting from 2.8. Its usage became more pervasive since GIMP 2.10.

What is GEGL able to do?

GEGL is 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 is also independent of the data type being processed and is able to handle high bit depth images, ICC profiles and parallel processing of image tiles.

What does all that gibberish mean for GIMP?

Many highly requested features of GIMP are 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 are easier because GEGL does not make the same assumptions about color spaces and data types that 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.