Fabian Frederick posted that he had created a gallery make plug-in that did batch conversions (located at http://www.dtlord.com/gallery.) Fabian then inquired how to get this included in the distribution. Raphael Quinet said that posting a message to the developers list was the best way. Since it was a perl script, Marc would be the one to review it for distribution. Raphael also suggested including some examples of the output on the web page. Stefan Stiasny had several suggestions about cleaning up the code, covering some error handling and Gimp interface issues. Fabian posted again saying GalleryMaker had been fully reviewed and modified. Fabian also asked if it was mandatory it register the plug-in in order to reach the Gimp core application. Sven Neumann said registering a plug-in was a very good idea since it allows people to find it. Sven also added that plug-ins SHOULD be distributed outside the core package, but now suitable system had yet been devised. The goal was to have the new system ready for the 1.3.0 developers release. Dave Neary thought that plug-ins were not necessary to the Gimp, so they should be distributed separately. A plug-in package would solve this problem. Additionally, plug-ins should be in a different CVS module from the core. Garry R. Osgood said PLUGIN_MAINTAINERS was introduced into the distribution on Tuesday, January 04, 2000; in the five hundred and two days since that date, of the 162 core plugins cited in that file, 52 have maintainers. By this metric, only thirty-two percent of the core plug-ins are supported. Gary thought the question of maintenance and distribution were closely related.

Branko Collin asked when changing a few line of code made something a new plug-in and when the original author should be sent a patch. Raphael suggested that if useful features can be added without breaking the API, then a patch was in order. Raphael had four suggestions about submitting patches:

• Send them to the original author. But you should first try to estimate when this author made his/her last contribution to the Gimp because he might not be active anymore. Especially for Script-Fu, many scripts have been updated in CVS since the original author released them. In that case, the other three solutions are more appropriate because the original author might not have the latest version of the script.
• Post the patch to this list. The patch should be in "diff -u" format. This only applies to small patches. If your patch exceeds a few dozen lines, then you should consider the other solutions. People do not like to receive big files in their mailboxes if they haven't asked for them.
• Submit a new bug report to http://bugzilla.gnome.org/ describing what your patch does, set its severity to "enhancement" and attach the patch file to the bug report using the "create attachment" feature.
• Store your patch in the incoming directory of ftp.gimp.org and send a README file to the ftp admins, as described in the message that you will get when you enter the incoming directory.

Robert L Krawitz announced the alpha release of the print plug-in with Gimp Print 4.2. Robert asked what needed to be done about syncing up with the next Gimp release. Sven Neumann said it could be included if it was sufficiently tests and suggested the plug-in and the enxt version of the Gimp be released before the print plug-in was officially included.

Branko Collin wanted to discuss plug-in distribution, after it had been mentioned earlier in . First, Branko offered a definition of the problem area what are considered plug-ins? Everything that goes into the directory 'plug-ins'? Anything else? Branko felt that part of the problem centered around deciding which scripts belong in the core distribution and which don't. Branko suggested the following classes of scripts be included in the core distribution:

• those that perform a task that the GIMP should have provided for itself or will provide for in the future;
• those that will help other plug-in authors better understand how to write plug-ins;
• those that will make the GIMP look good when compared to other raster image editors; and
• those that perform a task the best in its field.

Sven Neumann agreed with Branko that it was time to have this discussion again. Sven stated Our goal is to have as much functionality as possible in plug-ins. This reduces the size of the core, makes it cleaner and improves maintainability of the core. This makes this rule questionable especially since "a task that the Gimp should provide" is much too vague. Sven disagreed that another package having some functionality was reason enough to distribute particular plug-ins with the Gimp. Sven took a different approach and discussed what a plug-in should look like and why they were there.

Guillermo said he would make a basic plug-in handler so users can remove and add them to menus, if installed, and let the real development focus on getting and installing the plug-ins. Guillermo suggested using a package system, which would mean a security audit for all UID 0 Sven agreed that dealing with binary packages would be cumbersome and that a solution would be to distribute source packages with a file (possible XML as described by Ingo) that describes the package to the next generation plug-in registry. Sven also added For the moment we want to keep all plug-ins in the core package until we have ported Gimp to Glib/GTK+-2.0. This is because we think that a lot plug-ins will be ported very easily and having them all in one place might ease this task. Once the port is done (and we are going to start it very soon now), we should think about moving most of the plug-ins out of the core CVS module. Hopefully we have made up our mind on the new plug-in system until then. Garry R. Osgood also agreed the Gimp developers did not have the resources to create binary plug-in distributions. Garry felt the general approach to plug-ins was useful, and mentioned that this could become a lot like a protocol. Branko added the issues sounded more like it centered around finding maintainers and offered the Debian tool as a means for packaging plug-ins. Sven pointed out that Debian tool was good for Debian users, RPMS were good for Red Hat users, and Binary was good for Windows Users.

Shlomi Fish asked where the Gamma Correction plug-in for the Gimp 1.2.x lived. Sven Neumann pointed to Image->Colors->Levels, saying the middle entry of the "Input Values" corresponds to Gamma. Michael Natterer added the display filter subsystem was disabled for 1.2.x because it was not finished and should be re-enabled in the HEAD to avoid bit-rot.

In relation to the discussion of plug-ins, Raphael Quinet mentioned the menus were too crowded and new users could easily get lost. To Raphael, distributing fewer plug-ins with the core distribution did not solve this problem. Raphael suggested different levels of detail, in a manner similar to GNOME.

• Dumb user (oops, I mean beginner): only some basic operations are visible in the menus and in the toolbox, and the Gimp allows you to do as much as the venerable XPaint (or Windows Paint).
• Apprentice: all core operations are visible, and only the plug-ins distributed in the core package are available.
• Normal: all plug-ins are available.
• Expert: some additional entries become available, such as the PDB browser, parasite editor and other things that are more interesting for a developer than for a normal user.

Branko Collin added that this sounded like the new menus in Windows, where the most important and most used items are displayed. Shlomi said the computers at the faculty PC-Farm were always reset to the initial values, making the system annoying. Sven posted that 'man gimp' was your friend, since the --gimprc option allowed an alternate path to the RC file. Raphael clarified that all plug-ins must still be available, if only through the PDB and not the menus. Additionally, Raphael did not think the keyboard shortcuts should be changed, and that the bloat that came with customizing the Gimp until it was unrecognizable (a la mozilla and XUL) would slight coolness factor, but no usefulness. Lastly, Raphael pointed out that changing menu layout would affect the tutorials. Tuomas Kuosmanen disagreed that the new Windows menus were useful, because the forced the user to reread the menu every time it was displayed. Simon Budig agreed that the new Windows style menus were distracting, but sorting a menu item by importance was attractive. Branko Collin suggested a "tutorial theme" or having tutorials switch the user into advanced mode. Oliver thought that the dynamic menus allowed the user to always end up in the wrong type of menu, making the entire application look bad.

On a side note, Shlomi Fish thought the aim of the Gimp 1.3.x was to be independent of the GUI library. Shlomi added that this would make porting to windows easier since it could use Win32 controls. Sven said the plan was not to be totally independent from the GUI toolkit. It's the Gimp Toolkit after all... Sven said the current focus was to move the GUI interface from the core.

Robert L Krawitz posted the following announcement about Gimp Print:

Branko Collin asked which parts of the Gimp required their own licenses. Are all of the plug-ins covered because the Gimp is GPLed, which covers components. Sven Neumann said Everything distributed with The GIMP should be GPL, LGPL or a compatible license. I know there are a few scripts/plug-ins that don't specify the copyright/license explicitely. If you want to go thru the hassle of fixing them, try to get in contact with the respective authors and ask if putting a GPL header is fine. Actually we assume that all plug-ins in the GIMP distribution are GPLed. Dave Neary thought that things that depended on the Gimp, but were not in the core, could be under any old license. This allows companys to release propriatary plug-ins and modules (something Dave couldn't see any use for). Sven added that libgimp was LGPL s other people could use different licenses, but this didn't mean that any non GLP scripts or modules would be distributed with the Gimp. Simon Budig confirmed that the LGPL allowed propriatary links against the LGPLed libraries. Guillermo S. Romero thought a propriatary Pantone module or plug-in would be both useful and salable.