This is still a draft !!!!
Axel Wernicke (lexA), Jakub Steiner (jimmac), Joao S. O. Bueno Calligaris, Manish Singh (yosh), Peter Sikking (guiguru), Martin Nordholts (Enselic), Garrett LeSage (garrett), Carol Spears (carol), Michael Schumacher (schumaml), Tor Lillqvist, Simon Budig, Øyvind Kolås (pippin), Michael Natterer, Kamila Giedrojć, Roman Joost, Karine Delvare
Releasing GIMP 2.4
Mitch pointed out that there are still 26 Bugs preventing GIMP 2.4 from being released, such as color management. Michael Schumacher asked if the Coverty investigation in GIMPs code base would produce release critical bugs. Those will only affect the security and handled like normal bug fixes (but with care). So the only things which need some work for GIMP to be released are color profiles, finalizing crop and selection tools, and printing. The rest of the bugs are considered minor problematic.
GEGL and beyond
The plan is to roll out GIMP 2.6 faster than the previous releases (not in a two year development timeframe).
We talked about how GEGL can be integrated into GIMP 2.6. Pippin proposed that a higher bit depth can be supported by using GEGL with a minimal amount of effort to integrate GEGL. Michael pointed out that the GIMP Developers should also think about Cairo. Krita performed much faster after using Cairo.
GIMP supports a lot of plugins. The GEGL integration can break many of them. Peter suggested to support only the really important ones (like Blur). Those features are already implemented in GEGL and don't need to be supported by plugins anymore. One problem though can be the plugin API, which needs to be ported.
Toolbox and More Tools
Mitch pointed out that every release has at least one flaw: some feature is completly broken because of the refactoring which takes place. Mitch would also like to see a more flexible toolbox for GIMP 2.6.
By integrating GEGL a lot of new tools will be available codewise. Peter should investigate how the UI can provide a good way to select 'subtools'. Pippin pointed out that the codebase already supports a lot more configurable tools (like an airbrush eraser). He also came up with some kind of 'pre-sets' for tools: a standard way of how tools work and the user should be able to configure their 'own' tools.
One other proposal was to implement the subtool selection which is provided by other proprietary software programs. Peter pointed out that 'copying' this awful behaviour won't solve any problems. It can be done much better. This new way of selecting 'subtools' can be put into a development version for testing by the GIMP community.
Another proposal was to provide transparent widgets. Providing transparent widgets in a platform independent way isn't achievable with reasonable effort.
We talked about backwards compatibility of GIMP to older hardware. Pippin pointed out that, by integrating GEGL, it wouldn't make any sense to support older hardware because of the complex floating point operations which need to be done.
Peter pointed out that there should be minimum support for a certain screen resolution. The team reached consensus on a minimum width of 1280 pixels.
Single vs. Multiple Windows Mode
Peter and Kamila proposed a single window mode in their talk. The menubar of the toolbox should be placed on the 'image window' and not on the toolbox. Though you first need to clarify what happens with the menubar if no image is openend. Peter proposed a window with menubar displaying a tip of the day.
The single window mode should be provided as a choice for the user to switch between single vs. multiple window modes. There were several proposals to implement a 'single window' like mode:
dock palettes to the image window
use tabs to switch between several images
The developers agreed to implement the 'mode behavior' consistently to avoid any mode switches.
Tip of the Day
The problem with the 'tip of the day' is that it is not geared towards power users but is good for new users learning to use GIMP. Peter proposed to refocus the tips towards experienced users by showing power tips that could help them to get to the next level. The dialog can probably be replaced by a better way of displaying tips: using the helpbrowser.
A good thing would be to have links to articles in the user manual for further reading. Even the tips can be collected out of the user manual. Although there is a difference on how the tips are currently implemented in GIMP and the user manual and how the translation is achieved. Mitch proposed to implement a new tooltip type which can provide links to the user manual in the help browser.
User Manual & Documentation
A new reference would be nice which displays all keys and mouse moves (e.g. shift+mousedrag + k = foobar).