Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Gimp Traffic #44 For 21 May 2001

By Cris Flagg

The GIMP Homepage | The GIMP News Archive | The GIMP Mailing Lists | The GIMP FAQ

Table Of Contents

Mailing List Stats For This Week

We looked at 54 posts in 201K.

There were 21 different contributors. 10 posted more than once. 0 posted last week too.

The top posters of the week were:

1. Plug In Distribution and Gallery Maker

18 May 2001 - 19 May 2001 (29 posts) Archive Link: "Gallery maker ..."

People: Garry R. OsgoodRaphael QuinetBranko CollinSven Neumann

Fabian Frederick posted that he had created a gallery make plug-in that did batch conversions (located at 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: "

" Branko thought that useful might be subjective, and the core developers would probably need to judge that. The author of the script Branko modified copyrighted the script without mention of license. "Does that mean it is automatically GPL'ed, because the script is part of the standard GIMP distribution? I do not know if the law works that way. "

2. Print Plug-in

19 May 2001 - 20 May 2001 (3 posts) Archive Link: "Print plugin"

People: Robert L KrawitzSven Neumann

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.

3. Plug-In Distribution

20 May 2001 - 21 May 2001 (11 posts) Archive Link: "plug-in distribution choices"

People: Branko CollinGuillermo S. RomeroSven NeumannSven Neumann Garry R. Osgood

Branko Collin wanted to discuss plug-in distribution, after it had been mentioned earlier in Issue #44, Section #1  (18 May 2001: Plug In Distribution and Gallery Maker) . 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: "

" Guillermo S. Romero added that some modules, like colour selectors, could be considered plug-ins. Also, since interpreters were not part of the core distribution, scripts were really plug-ins to plug-ins and might not be part of the distribution. Plug-ins In regard to plug-ins to help developers, Guillermo said " That should be in a devel package. Why do a user need a plugin that does nothing or near nothing? It is like the test script fu, lots of controls and you get a plain ball. Or like devel packages, users do not need to waste space with .h files that will never use." Lastly, Guillermo added plug-ins that are maintained are different form those that aren't. All of the plug-ins could be included if they were maintained, if "... somebody finds a way to keep all plugins updated (pay a coder with comunity money like with a Perl one? create a company to support it?). :]"

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.

A very important point for distributing a plug-in is to have a maintainer that feels responsible for it. The core Gimp maintainers would like to only have a set of basic image manipulation tasks in the core package and they would feel responsible for keeping them up to date, handling bug-reports and discussing patches. Such basic plug-ins would include for example Blur, Gauss-Blur, Sharpen, Rotate, and a set of important file-plug-ins to give only a few examples. Other plug-ins could be grouped into smaller packages for special purposes. For example there could be a gimp-web-plug-ins package that adds functionality like GIF-Save, Anim-Optimize, ImageMap and others. Such a package would have a maintainer who is responsible to handle bug-reports and keeping the package in sync with the core. Installing gimp would then be a process of installing gimp-core and a set of plug-in packages that fit the needs of the user. Such an approach has some obvious advantages but also a bunch of drawbacks:

The packages would have interdependencies. The web-plug-ins package might include a gimp-perl script so it would require gimp-perl. Of course everything in the web-plug-ins package but this script would work w/o gimp-perl so actually gimp-perl is not required but only recommened. I can however only think of one binary package system that can handle those kind of weak interdependencies (debian). The packages should not overlap and they should share the menus intelligently. This would require some interaction between package maintainers. I think however that this should be doable. On multi-user systems the administrator who installs gimp can not decide what packages the users might want. One solution is to install them all. This would however lead to overcrowded menus. A problem that could be solved by a plug-in manager that knows about all plug-ins that are available and lets the user choose what plug-ins she wants to see in the menus. Having gimp split up into dozens of packages will make installation difficult. Again a plug-in manager that knows about all available plug-ins out there, collects and installs them would help. It turns out we need a plug-in manager. What functionality should such a beast have? Here's a list of things that came to my mind: It should read a number of plug-in lists: a list of all available plug-ins that is distributed with the core gimp and can be updated through the web. A list of plug-ins that are installed locally do not necessarily appear in the menus. It should have meta-packages of plug-ins similar to the task-lists Debian has so a user can install a bunch of plug-ins with a single click. One meta-package would be "All plug-ins", other tasks could be "Web Publishing", "Photo Retouching", ... It should be able to download and install precompiled binary packages or download sources, compile and install them. A solution for the binary packages would be to use the binary packaging system provided by the distribution. Since there are a bunch of different distrbutions out there, this might be tricky. That should be enough food for thought for now. Please comment.

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.

4. Gamma Correction

21 May 2001 (3 posts) Archive Link: "GIMP and Gamma Correction?"

People: Michael NattererSven Neumann

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.

5. Plug-Ins, Menus and User Interface

21 May 2001 - 28 May 2001 (15 posts) Archive Link: "Plug-ins, menus and user interface"

People: Raphael QuinetSven NeumannBranko CollinNick LambSimon BudigTuomas Kuosmanen

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. "

" Nick Lamb thought this sounded like themes, which he considered a good thing. It would allow customized versions of the Gimp to be tailored to particular applications. Themes could describe menu layout and keyboard shortcuts. Shlomi Fish thought this was a great idea. In order to allow flexible customization, Shlomi suggested dividing the themes into sections such as keyboard, menus, toolbox, etc.

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.

6. ANNOUNCE: Gimp-Print 4.0.5

26 May 2001 (1 post) Archive Link: "ANNOUNCE: Gimp-Print 4.0.5"

People: Robert L. KrawitzRobert L Krawitz

Robert L Krawitz posted the following announcement about Gimp Print:

This is a rerelease of Gimp-Print 4.0.5, which had some errors when released earlier this week. Thanks to Mike Sweet for managing this release. This is expected to be the last release in the Gimp-Print 4.0 stable line.

Gimp-Print 4.0.5 contains the following fixes and improvements over Gimp-Print 4.0.4:

  1. Added support for the EPSON Stylus Color 680 and 777
  2. Added support for the EPSON Stylus Pro 7500
  3. Fixed a bug in the GIMP plug-in GUI - the image scaling was not maintained properly.

7. Copyrights and Licenses

29 May 2001 (7 posts) Archive Link: "Copyrights and licenses"

People: Sven Neumann Branko CollinSimon BudigSven NeumannGuillermo S. Romero

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.







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.