|
Git
ChangeLog News Hacking Bugzilla Mailing Lists Screenshots Plug-In Development API Reference Writing A Plug-In Plug-In Template Conference GIMPCon 2000 GIMPCon 2003 GIMPCon 2004 GIMPCon 2006 Developer FAQ Standards About |
GIMP Developers Conference 2006The GIMP Developers Conference 2006 was held as a sub-event of the Libre Graphics Meeting in Lyon, France, on the 17th, 18th and 19th of March.
The GIMP Developers Conference, also known as GIMPCon, is a gathering of GIMP and GEGL developers from all over the World. It is a vital opportunity for GIMP developers to meet each other and discuss the direction which the software will take over the coming years. There have been four GIMP Conferences previously: two in Berlin, Germany hosted by the CCC (the Chaos Computer Club), one in Kristiansand, Norway as part of GUADEC 2004 and one in Stuttgart, Germany as part of GUADEC 2005. During LGM, we had two sessions dedicated to GIMP: one on Saturday afternoon (16:30-18:00) and one on Sunday (10:30-16:00). The following points were on the agenda:
SIOXGerald explained the current status of SIOX and its future developments:
New tools
Google's Summer of CodeDave pointed out that the Summer of Code is coming soon and ideas are needed. GIMP is one of the projects which can offer tasks to be solved. Ideas and Tasks are needed soon, probably around the beginning of May. Preparation for the 2.4 releaseMichael pointed out that some terms in the GIMP UI uses are misleading and very different from other image manipulation programs. One example is the misleading dpi instead of ppi. Michael proposed a Texttool PDB and also new features: multiple styles for a line of text, more control over text. Unfortunately, GIMP does not currently support all pango features. Sometimes ligature problems occur with Bitstream Vera Sans. Various other issues were also discussed: undo handling of vector operations, improvements to the full screen mode (some plug-ins cannot display progress bars), etc. TODO
The manual currently features nine languages, five are activly worked on. Russian and Norwegian will be added after the 0.10 release. DocBook/XML is a barrier for new contributors, but there is currently no valuable alternative available. For PDF creation we should use dblatex instead of the dead project db2latex. The more translation an XML file holds the more difficult it is for contributors to concentrate on their content. Maybe we should split up the content directory-wise instead of profiling. Michael proposed way users can comment on HTML pages like the PHP documentation. The problems are: what will happen to comments after an update of the documentation, how and who manages comments, which system will suit our needs. TODO
GEGLPippin pointed out that GEGL does not yet support calculation over regions of interest. Some of the code that does that is currently 8-bits only, but the reference buffer implementation would be 32bits float per pixel. Yosh proposed to generate all the code needed for this from a template. Pippin: GEGL is undead. Mitch suggested that the integration of GEGL should be in small steps. The plug-in API should be GEGL only, but will provide backwards compatibility from old plug-ins for 8bits only. UI and Usability problems are also caused by the indexed mode. We concluded that it should be available if the user exports his image to an indexed format, like GIF or PCX. For some indexed images, the order of the colors in the palette is significant. Raphaël proposed to handle these images through GEGL as 16bits images with the 8 least significant bits representing the original palette index so that it can be restored later when saving. Gerald mentioned that Apple may already be doing something similar. TODO
The current project page for gimp.org is not really structured and not very easy to get in touch with the developers. It would help to show to the potential contributers a list of tasks that GIMP developers consider relatively easy and useful for the next version. We could also use the task list for the Google Summer of Code or for bounties, etc. We should make sure that people feel welcome when they read the GIMP mailing lists. For example, we should avoid criticizing those who mention GimpShop or commercial programs such as Photoshop. Some suggestions were discussed, such as introducing aging in the list of GIMP authors. The About dialog would first list those who contributed to the current version and then a longer list of previous contributers. Sven and Yosh remarked that we are not really using the mailing lists for discussing GIMP development. Most of the discussion happens on IRC or directly between people. This could be improved. There was also some debate about how to avoid pointless discussions on the gimp-web mailing list. TODO
Peter Sikking helped us to formulate a product vision for GIMP. The vision helps to define what standard installation of the GIMP is: what plug-ins are standard and what plug-ins are optional. It shouldn't be a simple cost-and-benefit analysis of what it means to support a feature. The current problem of the product vision is too broad to be practical. Peter proposes that our product vision should address a kind of Gauss curve of what users GIMP is made for. Currently we have the experts and newbies, but a low point for the intermediates. Good defaults would be chosen depending on our vision, not by inventing new scenarios for each thing that we want to evaluate. The user scenarios would be written down in advance. These scenarios should not be changed afterwards because it would lead to too much discussion. The goal is to cut down all this discussion. The product vision is to be used as a filter. For example: If someone comes with the request that the UI of GIMP should be like Photoshop, we can simply state: “We are not trying to be like Photoshop, because we have a different product vision.” Though, the feature requests should still be examined carefully. Targeted user baseGIMP targets experienced users. If we acknowledge that GIMP is not (primarily) for beginners, we cut off a lot of problems such as “do we need to support that,” etc. Peter noted that a “GIMP Light” would not just have some options cut off from the menus: it would have a completely different user interface, even if it would use the same code under the hood. Some developers work on GIMP to promote the Free Software movement and would probably not contribute if GIMP was not free. Others think that GIMP should provide fun for its developers, although our user base has grown a bit large for just doing fun experiments. We have to acknowledge that we address a user base that may be more experienced in image manipulation than we are, so the developers are partially out of the target group. Before converging towards a definition of the GIMP target groups and GIMP vision, there were several discussions involving examples and use cases, whether GIMP should be the best image manipulation program in the universe (best for who?), whether those working on icons and those working on photos have the same needs (number of images open, relative sizes), whether people need to switch frequently between GIMP and other applications (browser or editor for web work), whether we will support painting with shapes and natural media, etc. Eventually, a GIMP vision emerged... What GIMP is:
What GIMP is not:
TODO
Minutes written by Roman Joost and Raphaël Quinet. Photos by Jean + Karine Delvare and Raphaël Quinet. |
