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.
regards,
js
-><-
http://wiki.gimp.org/gimp/SummerOfCode2008ideas
-----------------------------------------------------------------
[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
well.
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
As).
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.
Benchmarking
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
[email protected]
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
