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 Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
