Hi - 

here are the ideas listed again. I had trimmed down the previous list,
as there are things that simply do not sound attractive enough for
anyone to pick.

Ideas for Gimp-python and the UF-Raw plug-in have been added. 
And we are still lacking mentors for pretty much everything else.  :-)  

Also, there is still a little time for adding some more ideas, or try 
to focus some more.



= GSoC2008 Project Ideas =

Please note that, although you are welcome to look at what is here, 
is a workspace for mentors to write down and modify their ideas, and
suggestions here should not be taken as necessarily viable projects 
until they have been finalized.  Also, the fact that something appears
here does not necessarily mean that anybody has volunteered to mentor

Note to people who add stuff here: Please try to add information about 
a proposal's overall  complexity and experience that could be 
helpful. E.G. experience with GTK+, image manipulation algorithms, 
web application development, ...

== Tagging of GIMP resources ==

Currently resources such as brushes, gradients etc are shown to the 
user in an unstructured way, only sorted alphabetically. This greatly 
limits the number of items a user can deal with. 

People love to make collections of things and think of them by names 
for these collections, like "sprinf flower brushes" or "fancy fonts". 
However, one resource can belong to more than one set, and there can 
be sets which are determined by other means than the content, maybe 
even without the user having to do anything manually - 
think "Favorites", "Most recently used" and "Most frequently used". 
It has been suggested that this should not be a finite set of 
categories, bug rather done by assigning tags.

The tasks in this project include:

 * adding a way for gimp resources to be tagged
 * decide which types of resources (i.e. which types of gimp objects) 
should be tagged
 * find a nice way for users to manage tags (add them, remove them)
 * present tags in the UI (i.e. how do you show them in the brush 
list, font list, ...?)
 * think about how tags can assigned to resources (or resources to 

== On-canvas text editing ==

 Right now, the text tool opens a dialog window where the text has to 
be put, thereby creating a new text layer. Nearly every other option 
of the text tool - font, font size, color, line height, ... - is 
available in the text tool options dialog, so it would be nice to get 
rid of this dialog as well. There have been feature requests about 
being able to edit text directly on the image, like for example 
Inkscape does it. 

It may be that getting to the point where editing text on the image 
canvas is possible isn't that much of work, actually. But this is 
where the interesting challenges do begin: eventually, we do also 
want multiple styles in one text layer. This is not so straight 
forward anymore if your enter text in the image. Not present right 
now, so not having it isn't exactly a showstopper, but making it hard 
to ever get there is.

And you will have to consider support for GTK+ input methods. They may 
be used to enter characters from languages (or, more precisely, 
scripts) beyond the simple Western scripts which define how our 
common keyboards are layed out. This is supported right now in any 
GTK+ text entry, not having it for on-canvas editing would be a 

Tasks for this project include:

 * port the text core to PangoCairo
 * get on-convas text editing implemented
 * figure out if we do still need a text entry dialog (even Inkscape 
still has it in the properties of the text object)
 * make sure that GTK+ input methods work this this new approach
 * think about making it possible or not making it impossible to style 
the text while editing it this way

== GIMP Python ==

mentors: Yosh or João

With version 2.4, python becomes the preferred method
of scripting plug-ins for GIMP. Python is an universal multipurpose 
language, adopted as scripting language by several applicatives, easy 
to understand,
with a feature rich set of standard libraries.

GIMP python scripting is possible since 1999, before version 1.2 and 
it allows
access either to GIMP's procedural database and to internal image 
pixel data, just like
plug-ins written in C.

However there are points that can be greatly improved. Things that can 
be done for a
Google Summer of Code project:
==== Properly map Gimp Widgets and objects to Python ====

 Wrap all libgimpwidgets to be acessible from python, so python 
plug-ins can have the same presentation as gimp components written in 
C (that is gradient and palette selectors,
scale entries). Additionally map all remaining gimp objects to proper 
python objects,
just as layers and images are already: palettes, gradients, brushes, 
patterns, fonts, 

==== Enhance the interface builder, add plug-in previews ====

Add optional parameters to the automatic interface builder in 
python-fu, to allow gtk+
expanders, parameter groups, different layouts and plug-in previews.

==== Enhance the python console ====

Add some GUI controls allowing more things to be
done from the python prompt with less typing. 
That could involve creating a utility python module to allow
for practical "CAD like" drawing from the python console, by typing
short drawing commands.

    Any of these tasks in pygimp could include adding missing 
Procedural Database calls in
    the gimp core (for example, not all paint options are accessible 
through the PDB)

== Work on GEGL ==
mentor: pippin

 [http://www.gegl.org GEGL] is a graph based image processing 
framework. It has been introduced into the GIMP trunk after 2.4 has 
been released. Processing is done by the nodes of the graph, which 
are implemented as so-called operations or 'ops'. A good introduction 
to the current state of GEGL is the 
[http://fosdem.org/2007/schedule/events/gegl presentation] given at 
FOSDEM in 2007.

 Possible topics for projects includes:
   * Prototype GEGL backend (with own set of operations) that uses a 
GPU instead of the CPU for rendering.
   * Networked buffers (and maybe distributed rendering).
   * Create a paint core and related plug-ins. A paint-core is the 
system used for drawing tools like paintbrush, airbrush, pencil, 
clone and other paint tools. The core should be made in a way that 
facilitates integration with a procedural brush system.
   * Frequency domain processing.
   * Any 
known bug or a number of bugs] fixed

== SVG brushes ==

 VBR brushes in GIMP - basic shapes like ellipses, rectangles and 
rhombuses; with additional spikes - are scalable. In SVN trunk, all 
brushes including the pixmap-based ones can at least be scaled down. 
We do not yet have means for more advanced brushes (think about a 
brush consisting of two disjoint circles) that can be scaled up in a 
lossless way.

 Using SVG files as brushes could help to solve this.

== UFRaw ==
mentor: Udi Fuchs

UFRaw is the GIMP plug-in responsible for opening raw files from 
digital cameras.
There are several possible projects for enhancing UFRaw.

==== 100% Zoom ====

Currently, when previewing the image to be converted, the maximal zoom 
is 50%. Simply generating the full 100% image will not work, because 
it take too much time for an interactive process. To implement this 
option one has to modify UFRaw to generate the 100% image in tiles. 
Later this feature could be used to multithread the process of 
generating the image.

==== User presets ====

The settings for image conversion can be saves in UFRaw ID files. 
Later those ID files can be used as presets for converting other 
images through the use of the command-line. The idea is to allow the 
user to switch between presets in the GUI. The GUI should give a 
natural way to modify and apply settings.

==== Multi-image workflow ====

Currently UFRaw is concentrated on the workflow for converting a 
single image. A multi-image workflow would show the user all the 
images in the directory, let him edit single images or apply presets 
to a group of images. The actual conversion would be applied in the 
background with feedback to the user on its progress.

The first two projects would involve substantial changes to the core 
code of UFRaw and require programming in C, C++.
For the third project one might be able to work with a scripting 
language, such as Python.

All three projects are complicated. I don't think that any of them can 
be completely finished during the given time frame. Still, it should 
be possible to make enough progress that will give substantial 
improvement to UFRaw.

== Enhancing Painting with parameter curves ==
   Currently there are quite a few options to use with the paint 
tools, however, mapping how these options could vary with pressure, 
tilt, speed, angle of painting is somewhat limited. A complete tabbed 
dock, where new curves could be added that would map one input 
variable to paint option could increase several fold the options 
available to artists. A request for this is drafted in 
[http://bugzilla.gnome.org/show_bug.cgi?id=119240 | bug #119240].

== Search-based menu browser ==

 The amount of menu entries in GIMP - either from plug-ins, scripts or 
internal functions - is huge. The name of a particular function might 
be easier to remember than its menu location. Being able to search 
for the function and applying it to the image without having to go 
through the menus can help (similar to Emacs' M-x feature).

== Your own proposal ==

 Feel free to come up with other possible projects - the 
enhancement proposals] in Bugzilla may contain some additional viable 
project ideas.
Gimp-developer mailing list

Reply via email to