This page is a a very un-organized list of ideas/suggestions that were discussed by GIMP developers. It contains enough ideas for enhancement requests and other small changes, and it should be the perfect place for new GIMP developers to find an idea on what should they do.
I'm rating the ideas by an approximation of how hard do they seem so you'll know what to tackle first. However, remember that this is just an approximation.
More accepted separator characters inside GimpNumberPairEntry
Estimated Hacking level: easy
GimpNumberPairEntry is the widget used in all the rectangle selection tools, for specifying the ratio between the width and height of the selection. This widget is like a regular entry, except for the fact that it can accept two numbers separated by some predefined separator character.
It was recently discussed on the IRC (July 2010) that GimpNumberPairEntry's should have the possibility of accepting any non-digit character as a separator. For example :/ are a valid separators for ratios, xX,are a valid separators for exact sizes and in some cases even more separators would be considered logical.
Instead of trying to guess what should be considered a valid separator, it was suggested that any non-digit character would be accepted as a separator (we don't say that just punctuation characters are valid since then we ignore x and X). Now, in order to not change the api of the widget we can't omit the separator argument on the constructor.
We should either add a new function that enables using any non-digit character as a separator or make this the default behaviour. If anyone wants to do this, consult guiguru before also about what to do with erroneous inputs (such as "100:50:20" - should this be 100 and 50? or maybe 100 and 5020? The current behaviour is that if an erroneous input is given, it's ignored and the previous state is restored).
Export/Save specifications for non-dirty (clean) images
Estimated Hacking level: ?
Should we allow to re-export/re-save an image which was opened and no changes were made to it?
In addition to the fact that there doesn't seem to be any reason to export what you just imported back to the same file, this may even cause loss of quality/information. For example, when using lossy formats such as JPEG you will probably lose quality with each time you import and then export. Also,this is especially critical with images that were imported from one of the non-native formats (i.e. non XCF formats) since we may loose information in every such export (For example, gimp can import PSDs and ignore features it doesn't support, but if we re-export it the original information which is not supported by gimp will be lost). It doesn't seem smart to encourage this loss of quality and information...
Note that this should probably be consistent between saving and exporting; We won't allow saving an image to the original file if it wasn't modified only if we also apply the same restriction on exporting.
One last note: some file plugins import images and make changes to them during the import (for example, the JPEG plugin can rotate an image during import based on it's exif data). Should we allow these plugins to mark the imported image as dirty so that it can be saved again? [Editors note]: As far as I know there is no function to mark an image as dirty, so this will probably require the addition of a new PDB procedure.
Add support for angular guides
Estimated Hacking level: Easy-Medium Medium-Hard
In short: add support for guides with an arbitary angle (and not limited to 0 degrees/90 degrees. You'll need to take a look (at least) at the following files app/display/gimpdisplayshell-draw.c, app/core/gimpimage-guides.c, app/core/gimpguide.c).
Edit: Actually, any api change you'll make to existing function will force you to change these:
That's many many files - so annoying... It may be easier to introduce angular guides as new types of objects...
Support capturing the cursor inside the Screenshot plugin for Windows
Estimated Hacking level: Easy (If you have some windows programming expirience)
As the title states, unlike the unix version of the screenshot plugin, the windows version can not capture the cursor. Adding a support for this would be great! For thos who want to get a reference, you can see an article about how to get the bitmap of the cursor here: http://msdn.microsoft.com/en-us/magazine/cc301524.aspx. Note that some of the links in the article are broken, but you should be able to find the ones with the code.
Support layer modes/masks in transform previews
Estimated Hacking level: ?
Layer blending modes are currently disabled during transformation previews, due to the fact that they require a bit more processing. A small enhancement would be to add a check-box to enable layer modes during transformation previews. This is sometimes essential for getting the transformation right =) The same goes for enabling layer masks during transformation previews.
Support selecting guides by location with the align tool
Estimated Hacking level: Easy-Medium
Allow to pick a guide by it's x/y location with the align tool instead of fighting the cursor to select it
Create a plugin for laying out text inside the selection
Estimated Hacking level: ? Requires some knowledge of pango and cairo
Create a plugin that will allow taking a text layer and adding spaces/line-breaks so that it will flow into the selection. You may get some basic hints on how to do this from the following mail that was sent to the Pango mailing list - http://email@example.com/msg01373.html