GIMP: The Wish List

Here is the first online version of the Master Wish List. It includes all the info I garnered from the discussions on the user and developer lists. Please note that these items aren't all my ideas nor do I necessarily agree with them all. But they are here either because there is interest (and someone to do the work) or because someone suggested it and the idea has some merit worthy of discussion.

Table of Contents


Please volunteer for some of these projects, but only if you have the time and motivation to follow through on them. If you are interested, please send email to the Wish List Coordinator.

Entry formats:

Each item listed is a project unto itself. Each item has one or more of the following tags. If any of these is missing it is assumed to be "TBD" - To Be Determined.

Features what does this item include
Impact how will this impact the overall system
Advantage why should we do this
Work what work needs to be done
Assigned who is working on this
Time Frame when will it be ready
Status what is the current status of this item

One thing about what happens when things move off of this list: If the item is removed because its not going to be done (for whatever reason) or if it has been completed (including documentation), then the item will be listed in the FAQs in the appropriate sections. This list is only for items which are currently being worked or which haven't yet been determined to be a plausible project for the GIMP.

Shared Memory configuration Option (X and OS versions)

X Shared Memory can be turned off now with the -noxshm option on the command line which forces slower screen updates This is a runtime option, not a build option, and should work for anyone who has an X server which does not support X Shared Memory (such as some DOS/Windows X servers and some X Terminals).
Impact: significant performance issues; removing OS shared memory forces sending images through pipes which requires much larger memory requirements.
Advantage: Only real advantage for removing shared memory support is for systems which do not have support for it.
Work: See assigned
Assigned: Peter Mattis has some configuration work that needs to be integrated into the source so that GIMP will build on systems without X shared memory.
Time Frame: Unknown

New! Updated! Core code changes

gdk/gtk is platform inspecific windowing interface, which will allow GIMP to be ported to other platforms. gdk is the low level (X) interface, and gtk is a windowing abstraction layer in which the GIMP and plug-ins will be written.
Impact: Portability to other platforms increases, but requires gdk-level libraries be written by someone for those other platform.
Advantage: Portability increases.
Work: gdk and gtk need to be completed, then GIMP needs to be ported. After a testing phase to prove stability, the plug-ins will need to be ported to the new API provided by gtk.
Assigned: Peter and Spencer are working on the gdk/gtk libraries.
Status Version 0.6 Alpha is now available.

Peter Mattis has started doing some preliminary work on overhauling the plug-in api and the plug-in protocol. His goal is to make everything more general and to add more capabilities. That is, no more restrictions on the size of strings that can be passed back and forth (etc), and new things, like querying and calling other plug-ins. Unless there is great disagreement, his current plan is to drop the dialog support from the protocol and to introduce similar functionality as a library of routines which will use gtk directly. This is because you can get much more power and control out of using gtk directly without much more complexity. And since gtk will almost undoubtedly be compiled as a shared library, there won't be much of an increase in plug-in binary size. (Probably a decrease if libgimp is made into a shared library as well).

New! Other items desired in the core code:

Plug-in Distributable

Create a set of binary distributions of the available plug-ins and make the compilation and configuration of new plug-ins in both source and binary forms as consistent and easy as possible. Allow the use of a system-wide configuration file prior to loading the user's configuration file.
Features Simplify the initial configuration and configuration modifications of the GIMP at sites where there are many users. Conflicting assignments for plug-in name/menu location, hotkeys, etc. are taken from the user's configuration files (ie the one loaded last).
Advantage Professional look, ease of use
Work Build structure has to be formalized, common format for plug-ins source has to be finalized. Installation requirements need to be defined, including gimprc format

Modify GIMP to check for a system wide GIMP configuration file before looking at the user's configuration file ($HOME/.gimprc).

Assigned Ingo Luetkebohle, Adam, Mena Quintero Federico, Michael J. Hammel, Jim Geuther (AIX)

Plug-In rc files

Allow plug-ins to keep configuration caches or other user configurable options between repeated invocations in the same session, and between sessions of the GIMP
Features This may also include configuration of the plug-in without user interaction if the plug-in is called by another plug-in.
Work libgimp must be expanded to check for and load plug-in specific configuration files (suggested location $HOME/.gimp/xxxrc), as well as save and load the settings for those plug-ins that have been used in the current session.

Runtime configurator

Allow user to configure gimprc at run time.
Features Allows the automatic addition of new plug-ins to the user's .gimprc without manual editing of the .gimprc by the user by querying the plug-in for its default settings. Conflicting assignments for plug-in name/menu location, hotkeys, etc. are taken from the user or system configuration file.
Work Probably needs to be considered with the Plug-In Distributable work, since the two processes are fairly related.

libgimp will need updates to handle automatic query process. Modify GIMP to do some sort of configuration search for plug-ins that weren't already in the user or system configuration files. This should be made as unobtrusive as possible, so that users aren't faced with long delays each time GIMP is started.


Allow for the addition of pens, tablets, and other special input devices to the GIMP.
Advantage Allow support for graphics specific input devices (as opposed to just a mouse or keyboard)
Assigned MJHammel, Larry Ewing
Status In discussion. It is reported that XFree86 now has support for "pen angle" on the input tablet in the latest beta.

Visual Schnauzer

Provide a visual display of directory contents.
Features: file list including file type, file conversion, file copy, file remove file move, preview
Work: TBD - potentially a plug-in
Assigned Jim Geuther

GIMP Documentation Project

Provide complete documentation for the GIMP and plug-ins. I've decided to take on this project myself since I seem to be really good at gathering info and organizing it anyway. There will be a page devoted to the GIMP Documentation Project with the details needed by plug-in authors for creating their documents. I can tell you it will probably be an SGML template. Don't be put off by this - I read through the LinuxDoc stuff and its very much like Latex (if you used that) and can all be done in any text editor you like. The template will have all the necessary fields for you to fill in, plus an area for details. I haven't gotten deep enough into it yet to know how to handle figures/tables/images yet, but I'm sure that won't be difficult either.

And as the document editor, I'm here to help. So ask questions if you have problems and we'll see what can be done.

For those who are interested in SGML in general, try Please note that as of this moment I haven't looked at this site so can't recommend any of the tools there specifically (except LinuxDoc, if its there).

Features: User's Guide, Programming Guide, Porting Guide, FAQs, Plug-In Tutorials, Style Guide for Plug-Ins
Assigned Michael J. Hammel (Docs) and Miles O'Neal (FAQs) (and Stephen Robert Norris?)
Marc Bless is working on the Latex version of the GIMP Programmer's Reference Book, so I'll be talking to him about the conversion to SGML.
Status Some documentation has been converted to HTML already:
  1. GIMP 0.6 Beta Announcement
  2. GIMP Developer FAQ
Most of this was quick and dirty and isn't really the way things will be in the future when documentation will be formatted with SGML.

New! Plug Ins

New plug ins that are needed
  • load/save postscript
  • program launcher for non-gimp related programs
  • animation
    File loading/saving one frame at a time only (may need the plug-in rc file/parameter saving to work properly).
  • 3D perspectives
  • Warping/Morphing
  • extended Bezier path selections (may be dependent on brush API)
  • A real lens flare
  • Shadow - provides a shadow behind an image.
  • New! PhotoCD support
  • New! Version information available from all plug-ins
  • New! TWAIN capable scanner support
Assigned TBD - probably to a plug-ins coordinator since plug-in development should be a seperate issue from core functionality development Some volunteers for specific plug-ins:

File Preview

Provide an icon-sized preview of a file in the image selection dialog.
Features When the user is selecting a file to open, the File Preview feature would create an on-the-fly image icon for the currently selected file, including image size and color type/depth.
Work This would be integrated into the GIMP as a replacement for the current file selection dialog. It would probably need to wait for the new gtk/gdk to be complete.

Programming Language and Macros

Provide an interface for users and plug-in developers to perform common tasks
Assigned - Quartic

Updated! Extended Plug-In API

Provide graphics primitives to Plug-Ins, including but not limited to 2D graphics primitives like boxes, circles, and so forth.
Assigned Peter Mattis
Status In discussion. It is reported that XFree86 now has support for "pen angle" on the input tablet in the latest beta.

libgimp shared library support

Allow the libgimp library to be built and used as a shared library
Assigned Jim Geuther
Status It has been reported that this already works, but possibly only because only one plug-in is running at a time. This may change if one plug-in can call another.

Does the current build process automatically build shared libraries?

Builtin Help Facility

Provide some way of the user getting help while running the GIMP.
Features The best method would be having a file .hlp (or whatever) in the same directory as the plug-in or a parallel plug-ins-help directory. The virtue of external help files is that they are easily edited without recompiling the plug-in itself, and they can also easily be distributed in multiple languages with a single binary. The drawback is that it is easier to lose a help file if it is separate from the plug-in.

Might be useful to be in HTML format, since the GIMP Documentation Project can maintain the source and easily provide the online help for distributions.

Plug-In Debug interface

Allow plug-in authors a way of debugging their code that is compile-time configurable.
Status Linking in gdb to the running plug-in works well already. Just fire up gdb after the plug-in has started, but before you press "ok" and have gdb link to process-id the running plug-in.

We could use a tutorial page for this, if anyone wants to volunteer. It shouldn't take too much time to do.


Provide communication functionality for multiple copies of GIMP to work collaboratively.

URL support

Allow network file i/o

PVM Support

Allow distributed image processing
Status Its been mentioned that the overhead for doing this is not worth the effort (ie there is no real value add to the program by trying to distribute the processing). Andreas Dilger is the person to contact if you think you have valid reasons why this should be included in the GIMP.

Updated! Inter-plugin communication

Allow plug-ins to communicate with each other, so one plug-in can make use of another plug-ins functions
Features Allow a plug-in to be called with specific command-line parameters which set/override the default plug-in parameters, and then run the plug-in without user interaction.
Work Make libgimp re-entrant (ie it doesn't have any global variables, and can be running multiple plug-ins at the same time). Enhance the libgimp plug-in API to allow setting the plug-in parameters without user interaction. This is closely related to the Plug-In rc file and the Libgimp API enhancement projects.
Status Matthew Secor has a modified version of gimp.c (v0.54) that he's written which allows plug-ins to be called from other plug-ins, by allowing the parameters and input/output images to be specified on the command line for the plug-in being called. I've not heard how well this works and I've not tried it myself yet.

In order to use the modified gimp.c, you need to recompile libgimp.a and all of the plug-ins, except for plug-ins which normally pop up dialog boxes. For these plug-ins, you need to make a few small changes to allow the plug-in to read its parameters from the command line if it is not invoked interactively. Matthew has already modified a bunch of the existing plug-ins, and for most, the changes take at most two or three minutes.

I also have written an Tcl/Tk interface that runs as a plug-in, and allows other plug-ins to be called interactively through scripts or directly.

The GIMP Plug-in Library

A set of generally well-used functions available for the plug-ins.
Assigned Tom Bech
Status Functions to do RGB<->CMYK or RGB<->HSV are already used in several plug-ins, and should be added in a library, (although if we can have plug-ins calling other plug-ins, then we don't need to expand the API, we just need to write a single very simple plug-in to do the conversion, and have the other plug-ins call it).

New Brushes

Add a set of new brushes or an API for adding brushes similar to (if not actually part of) the plug-in API

API support for File Selection window

Add support to the plug-in API for a File Selection window. Doesn't this already exist?

erase to last saved
extended blend tool

Submitted by Heiko Goller. The "erase" function would be like in ph*t*sh*p: you can use a brush/airbrush or a pencil to erase. The extended blend tool would be like the Powertools Gradient Designer, allowing the user to choose more colors for blending and to choose how they are placed (look at the Gradient Designer to get the idea).


Should be in 0.6, I believe.


Provide a small preview window which shows how the effect shows up on the image. This makes sense only if the image is a canned one, not a preview of what the user is about to try.

Things which should not go in the GIMP core code:

These last two should not be handled by the GIMP, but by plug-ins. There should be no reason to add support for these if support for inter-plug-in communication is provided in the future.

Let the discussions begin. Start Volunteering for Work!

Again, I'm coordinating all the work so we can try to have some focus on problems and ideas about when things will be done (at least status on whats going on).

I expect there will be teams of people working on specific areas (like the Macro language or XInputExtension). Coordination amongst the teams will need to be taken care of by those teams. If possible, I'd like to see if Peter or Spencer could set up individual mailing lists for the teams (and only the team members so the lists don't overflow with excessive discussions) once the teams have been established. For now, all discussions should be on the developer list only, since all of this is only wishful thinking at this point.

Back Back to The Gimp Page

(clear space) Michael J. Hammel <>
(clear space) Created: July 20, 1996
Updated: August 25, 1996