Hi there!

We have some ideas for Google Summer of Code project in the wiki, but 
all of tehna re dangling since last year.

Mos t of tehm look good, but some may have been obsoleted in the 
current devel cycle, or would involve changes in code that is going 
away in the cycle.

I am posting the full set of ideas bellow and asking for commetns on 
ideas, new ideas, and overall, people who would be willing to mentor 
a stundet through some of them.


[BOTTOM][TOP]GSoC2008 Project Ideas
 Please note that, although you are welcome to look at what is here, 
this 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 it. 
Note to people who add stuff here: Please try to add information about 
a prorpsal's overall complexity and experience that could be helpful. 
E.G. experience with GTK+, image manipulation algorithms, web 
application development, ... 
 Filetype registration 
There is currently no way to register a file type to open with GIMP 
from within GIMP itself. On some desktop environments and platforms, 
this makes registering types to open with GIMP awkward. We need a 
configuration GUI within GIMP, which does show the available types 
and/or file extensions, and a means (a backend) to register them 
according to the platform/environment. The latter should probably be 
modular and extensible, because this is different on each of them. 
 Resource management. 
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, so this would greatly enhance the user 
experience. It has been suggested that this should not be a finite 
set of categories, bug rather tags. 
 Create an SDI manager widget. 
Would allow all of GIMP's windows to be contained in a single parent 
window, as requested hundreds of times by Windows users. (This would 
be optional, not forced on people who don't want it.) 
 Plug-in stability effort 
Tests have shown that it is possible to crash plug-ins when feeding 
them bogus data via the PDB API, for example when calling them from 
scripts (another interesting approach might be to run file loader 
plug-ins with [WWW] zzuf). Needed: a test framework to find the bugs, 
and then time to fix them. 
 Additional file format plug-ins 
There is a number of file formats that GIMP should support, but 
doesn't or at least doesn't support fully, for example MNG. The MNG 
save plug-in needs to be modified to save images in MNG-LC profile. 
Then a loader can be easily written to work similar to the GIF 
loader. It also needs support for JPEG chunks. 
 On-canvas text editing 
Right now, the text tool opens a dialog window where the text has to 
be put. Nearly every other option of the text toold is in its tool 
options dialog, so it would be nice to get rid of this dialog as 
 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). 
 Unified UI for scripting 
We have three major scripting interfaces, Script-Fu, ?PyGimp and 
Perl-Fu. All of them allow to create an interface for a script 
easily, just by registering a function with their respective 
parameters. However, all widgets look a bit different depending on 
the binding. 
 Redesign and reimplementation of Save and Export in GIMP. 
Change the semantics of Save and Save As so that images are always 
saved in the XCF file format. Only the native GIMP format really 
saves all the image information and allows to lossless continue 
editing later. So only saving as XCF should clear the dirty flag of 
the image. 
Saving to other formats than XCF is done by exporting the image. The 
File menu should have an Export menu item (and perhaps also Export 
 Unit testing framework 
GIMP currently doesn't have a test framework that API changes or 
internal changes could be tested against. This is crucial to avoid 
regressions, especially with the major rewrite we will seen when GEGL 
is introduced. 
 Work on GEGL 
[WWW] GEGL is a graph based image processing framework. It will be 
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 [WWW] presentation given at FOSDEM this year. 
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 [WWW] 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. 
In many cases, image manipulation is compute-intensive - many 
operations are loops which go over all pixels of an image. Sometimes, 
there are more efficient algorithms for a particular method. But does 
it have other drawback? Or is the time spent at an entirely different 
place, e.g. code that does check something on every loop while it 
would be sufficient to only do it once? Can it be changed safely? 
 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 [WWW] | bug #119240. 
 Categories for brushes, fonts, gradients and palettes 
If one adds too many fonts or brushes to GIMP, they quickly become 
un-manageable through the existing UI. Implementing a way of 
organizing these resources in sub-categories, in a way that one 
resource could be present in more than one category (like thrugh the 
use of tags) in a nice UI could overcome these limitations; 
 Font Selector Widget 
We need something better. Something that is reusable. Something to 
turn choosing fonts into a pleasure, rather than a pain. Something to 
leave the competition on the dust. 
 Your own proposal 
Feel free to come up with other possible projects - the [WWW] 
enhancement proposals in Bugzilla may contain some additional viable 
project ideas. 

Gimp-developer mailing list

Reply via email to