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.
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 |
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). |
Other items desired in the core code:
gimp_new_scale(dialog_ID, group_ID, min, max, start, prec, granularity);
| 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) |
| 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. |
| 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. |
| 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 |
|
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 http://viper.falch.no/people/pepper/sgmltool/. 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: 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. |
Plug Ins
| New plug ins that are needed | |
| Features: |
|
| 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: |
| 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. |
| Provide an interface for users and plug-in developers to perform common tasks |
| Assigned - Quartic |
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. |
| 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? |
| Provide some way of the user getting help while running the GIMP. | |
| Features |
The best method would be having a file 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. |
| 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. |
| 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. |
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. |
| 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). |
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 to The Gimp Page |
Michael J. Hammel
<mjhammel@csn.net>
Created: July 20, 1996