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!
- 1 GIMP Development
- 1.1 How can I support GIMP development?
- 1.2 Which GIMP related projects can I contribute to?
- 1.3 What should I know when starting with open source development?
- 1.4 Who coordinates GIMP development?
- 1.5 Who is planning Gimp's development?
- 1.6 How can I become a GIMP developer?
- 1.7 Where should I go for help when I need it?
- 1.8 Where can I discuss GIMP development?
- 1.9 Where can I find documentation for the GIMP API?
- 1.10 How do I make a stack trace?
- 1.11 What is the best way to submit a patch?
- 1.12 What is the preferred coding style used in GIMP?
- 1.13 How can I configure my editor for this coding style?
- 1.14 Who coordinates the GIMP translation efforts?
- 1.15 Where do I find the code?
- 1.16 What's the best way to download, compile and keep up-to-date Gimp's source code?
- 1.17 What are planned deadlines for next edititons of Gimp? Are there any?
- 1.18 What were the last changes in the code?
- 2 Plug-In Development
- 3 GEGL
- 4 Bugzilla
- 5 GIT
- 6 Miscellaneous
- 6.1 Where can I learn more about the GObject system used by GIMP?
- 6.2 Where can I learn more about color spaces, color space conversions and other color science topics?
- 6.3 Where can I learn more about image manipulation algorithms?
- 6.4 What is ohloh.net for? Why developers are listed there and not on an official Gimp website?
- 6.5 What is buildbot? How to use Buildbot for GIMP?
- 6.6 Is there a GIMP user FAQ available?
- 6.7 How can I contribute to this FAQ?
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.
Contacting the team is essential when starting to solve bugs or realizing enhancements/features.
|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:
|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:
- 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.
- 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 (custom-set-variables ;; 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 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.
What's the best way to download, compile and keep up-to-date Gimp's source code?
- Pull the sources down from git.
- Configure and make babl.
- Configure and make gegl.
- 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?
How can I get started with developing plug-ins?
Is there a plug-in template available?
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 <email@example.com> 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?
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.