Hacking:Developer FAQ

From GIMP Developer Wiki
Jump to: navigation, search

Below you find a collection of frequently asked questions regarding development of the GIMP. If you find questions that are not answered yet, then feel free to change it!


GIMP Development

How can I support GIMP development?

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.

Currently the top priority in development is porting all plugins to GEGL and making GEGL faster.

You can also have a look at bug reports filed for GIMP and pick something. You can use bugzilla to find bug reports you could take care of, but we encourage you contacting us beforehand to find out if the task you picked is still valid. It's best to discuss working on something in either mailing list or IRC channel before beginning to fix things and implement features. This is because requests have to be checked against bigger design decisions. We'd hate if you wasted your time on something that shouldn't have been done.

Major planned changes are listed at the feature roadmap page. Some miscellaneous ideas are here

Contacting the team is essential when starting to solve bugs or realizing enhancements/features.

Which GIMP related projects can I contribute to?

Module Description
babl Pixel format conversion library
gegl Generic Graphical Library
gimp GIMP and the standard set of plug-ins
gimp-data-extras GIMP Data files such as brushes, gradients, patterns and the like
gimp-gap GIMP Animation Package, a set of plug-ins that provide video editing functionality
gimp-help-2 GIMP User Manual
gimp-perl GIMP Perl bindings and a bunch of nice gimp-perl scripts
gimp-plugin-template GIMP Plug-In Template, a starting ground for plug-in developers
gimp-ruby GIMP Ruby-based scripting plug-in
gimp-tiny-fu GIMP Tiny-Fu, a drop-in replacement for Script-Fu
gimp-web the GIMP web site, available at www.gimp.org
gimp-web-devel the source of developer.gimp.org (currently being migrated to this wiki)

There are also some archived projects:

Module Description
gimp-data-min The archive of data files for GIMP, such as brushes, palettes and patterns.
gimp-help The archive of the former GIMP help. Obsolete, please use gimp-help-2 instead.
gimp-plugins-unstable GIMP plug-ins from the past, a collection of unstable and unmaintained plug-ins.
gimp-resource-repository GIMP Resource Repository, a proposal for GIMP's GSoC participation 2003.
gimp2 Archived brainstorm for the technical architecture of GIMP2.

They have been unmaintained for long and the chances to get support for them are quite low.

What should I know when starting with open source development?

If you're new to open source development, the article '10 golden rules for starting with open source' from Tobias Schlitt offers useful and worth knowing hints.

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 through the GIMP developer mailing list.

Who is planning Gimp's development?

GIMP team's approach to planning is a little different. We do not have time-based schedules, instead we rely on a feature roadmap.

We use Git branches for developing major new features. If a feature is ready for inclusion into the main branch, it is merged. The decision, whether it's ready, is made by the core team (currently: mitch, Alexia), typically on IRC.

How can I become a GIMP developer?

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 developer. Any time you feel able, you can pick a smaller enhancement request and have a go at implementing it. It's that easy.

For more information see also the developer documentation.

Where should I go for help when I need it?

There are several channels of communication:

  1. GIMP developer IRC channel: irc://irc.gimp.org/#gimp. Users without IRC client can connect using one of the many online IRC clients, such as: Mibbit.
  2. GIMP mailing list for developers (gimp-developer-list |at| gnome.org), but it's of course slower than IRC.

See also the overview of Gimp mailing lists.

Where can I discuss GIMP development?

There are several mailing lists associated with the GIMP project. Developments related issues can be brought up on the [https://mail.gnome.org/mailman/listinfo/gimp-developer-list GIMP developer mailing list.

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

Once in a year the developers of GIMP and other open source graphics software get together to throw the LibreGraphicsMeeting, formerly known as GIMPCon. To see what's going on there see the summaries of the former meetings.

Where can I find documentation for the GIMP API?

There are several ways, see Hacking:API documentation.

How do I make a stack trace?

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.

What is the best way to submit a patch?

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. This page describes how you can submit a patch. You can also post it to the mailing lists GIMP Developer or GEGL Developer, but this only applies to very small patches (at maximum 10 KB).

What is the preferred coding style used in GIMP?

See our Hackordnung.

How can I configure my editor for this coding style?

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.

If you are using Emacs, you can insert the following settings into your ~/.emacs file:

   ;; Merge this into your custom-set-variables section if you already have one
    ;; Syntax highlighting
    '(global-font-lock-mode t nil (font-lock))
    '(show-paren-mode t nil (paren))
   ;; use UTF-8 by default
   (prefer-coding-system 'mule-utf-8)
   ;; use the GNU style for C files, spaces instead of tabs, highlight bad spaces
   (setq c-mode-common-hook '(lambda () (c-set-style "gnu")
                               (setq indent-tabs-mode nil)
                               (setq show-trailing-whitespace t))) 

If you are using Vim, you can insert the following settings into your ~/.vimrc file:

   syn on           " syntax highlighting
   set expandtab    " use spaces instead of tabs
   set shiftwidth=2 " default indentation is 2 spaces 

If you are using another editor and you know how to configure it correctly, please tell us about it on the GIMP developer mailing list so that we can update this FAQ.

Who coordinates the GIMP translation efforts?

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.

Where do I find the code?

The GIMP source code lives in the gimp repository on the GNOME git server.

The current production branch has the name of the current version, i.e. gimp-2-8. Bugfixes go here.

The branch 'master' is the development branch. This is the place for bugfixes and new features.

See also 'Which GIMP related projects can I contribute to?'

What's the best way to download, compile and keep up-to-date Gimp's source code?

Compiling GIMP

  1. General: Hacking:Building
  2. Additional descriptions for Linux: Hacking:Building/Linux

Short guide:

  1. Pull the sources down from git.
  2. Configure and make babl.
  3. Configure and make gegl.
  4. Configure and make gimp.

Installing needed libraries on Ubuntu

apt-get build-dep gimp

Links to more detailed descriptions:

How to compile Gimp for Windows?

The chapter Hacking:Building/Windows approaches this topic in detail.

What are planned deadlines for next edititons of Gimp? Are there any?

Once we have a bigger team, we probably will have deadlines. At this point we don't have the resources to plan time-based releases.

What were the last changes in the code?

GIMP 2.8

GIMP master (the development version)

Plug-In Development

How can I get started with developing plug-ins?

See How to write a GIMP plug-in.

Is there a plug-in template available?

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

How about a Script-Fu template?

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

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

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.

How do I debug a GIMP plug-in?

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.

Will the plug-in I compiled against 2.0 work with GIMP 2.2 or 2.4?

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.


What is GEGL?

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.10).

What will GEGL be able to do?

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.

Where to contribute to the future of GEGL?

You can find a good start for GEGL here: http://gegl.org/contribute.html

What does all that gibberish mean for GIMP?

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.


What is Bugzilla?

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.

What is the meaning of the NEEDINFO status code in Bugzilla?

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.

What is the best way to refer to a bug in Bugzilla?

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.

What is the proper way of handling duplicate bug reports?

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.

What is the proper way of marking a bug as RESOLVED?

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.


How can I learn more about using git?

Here you find more information, including links to Git tutorials.

How do I commit to the Git tree?

GIMP uses GNOME's Git repository for source code storage. Please read their guidelines.

Please note that much like GNOME we want to work with you for a while before we can confirm that you are going to make a great upstream developer. Until then you can maintain your own branch on Github or Gitorious.

We also wrote a guide on submitting patches.

What should I put in the commit message when doing a git commit?

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.

How can I add such a nicely formatted summary of my commit to a bug report?

If your commit is the latest commit on the branch, use

 git show --stat

If you want to output a particular commit, use

 git show --stat 1234567 (where 1234567 is the SHA1 hash of this commit)

The output looks like:

commit 9b6201e2806920e66602302bfee3ae1341f38bd4
Author: John Doe <johndoer@src.gnome.org>
Date:   Sat Feb 1 08:45:21 2010 +0100

    Bug 8154711 - Add more tutorial links.
    Add more links to tutorial sites.

 links/index.htrw | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)


Where can I learn more about the GObject system used by GIMP?

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

Where can I learn more about color spaces, color space conversions and other color science topics?

Unfortunately, the theoretical foundations of colors and their internal representation are not as easy as seeing them in nature. Elle Stone wrote a good documentation of color spaces which is recommended reading.

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

In our Glossary we explain the relevant terms.

Where can I learn more about image manipulation algorithms?

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

What is ohloh.net for? Why developers are listed there and not on an official Gimp website?

The GIMP project itself doesn't maintain a site with an overview of the developers. If you want to know who are most active developers in the project, you can look at ohloh.net statistics of the last 12 months. Ohloh.net is free, public directory, a web service and online community platform that aims to map the landscape of open source development (see the description in the English Wikipedia). It collects information from public available source code repositories and creates statistics from it. To read more about ohloh.net, visit the ohloh.net self-introduction .

What is buildbot? How to use Buildbot for GIMP?

Why is it on https://gimptest.flamingtext.com:9090/ and not on official Gimp's website?

What are the most common uses of the Buildbot?


Is there a GIMP user FAQ available?

Yes, you find it here.

How can I contribute to this FAQ?

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.