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 #7 For 1 Jan 2000

By Alex Harford

Table Of Contents


Welcome to the New Year's issue of Kernel Cousin Gimp. My name is Alex Harford, and I am going to be doing KC Gimp, hopefully releasing it every Saturday.

This issue is going to be a learning curve, so bear with me if there are any technical difficulties.

Mailing List Stats For This Week

We looked at 44 posts in 140K.

There were 24 different contributors. 9 posted more than once. 1 posted last week too.

The top posters of the week were:

1. Gettext Causing Infinite Loop

26 Dec 1999 (4 posts) Archive Link: "gettext in on_signal caused infinite loop"

People: SHIRASAKI YasuhiroMarc LehmannSteinar H. Gunderson

SHIRASAKI Yasuhiro wrote:


_() in the gimp signal handler sometimes caused infinite loop:
#0 0x2836ae7a in dcgettext__ () from /usr/local/lib/
#1 0x2836b73d in dgettext__ () from /usr/local/lib/
#2 0x2836b75e in gettext__ () from /usr/local/lib/
#3 0x2836aca4 in gettext () from /usr/local/lib/
#4 0x810b5c0 in on_signal (sig_num=11) at main.c:471
#5 0xbfbfffac in ?? () "

He also provided some additional debugging information, and suggested removing _().

Marc Lehmann replied, "The right thing is to remove superfluous code when it makes problems ;)"

Steinar H. Gunderson pointed to line "#4" in SHIRASAKI's post, and said, "Signal 11 is a segfault (what Windows would have called an Access Violation, or GPF). We should fix that segfault..."

SHIRASAKI replied, "Yes, I know that. The problem is that segfault happens in the signal handler for segfault itself. _() for segfault message was worked well in many situation, but once something wrong happened, it causes infinite loop."

There were no more messages in this thread.

2. Layer Deletion Bug In 1.1.14

26 Dec 1999 - 27 Dec 1999 (5 posts) Archive Link: "bug in 1.1.14"

People: Blue LangGarry R. OsgoodGarry R. Osgood

Blue Lang wrote that he had found a bug that would delete the wrong layer in a delete operation. He posted his exploit:

He also wondered aloud if there was a Gimp bug tracker anywhere.

About a gimp bug tracker, Garry R. Osgood replied, "Review current ones at: Enter new ones at" ". He added, "You can also use conventional e-mail. Instructions at: Find out what's been changed in the last twenty four hours at: Other useful announcements and links at" .

Regarding the bug found, Garry had some additional questions on how to reproduce it. He suspected that it had something to do with accidentally clicking on or in the vicinity of the eye icon.

Blue Lang confirmed the problem, and quoted tigert as saying that he had also noticed the bug several weeks ago, and had found that pressing PageUp or PageDown to select the layer (or selecting the layer from the Layer menu) was a workaround.

3. Minimal Gimp Install

28 Dec 1999 - 30 Dec 1999 (16 posts) Archive Link: "minimal install?"

People: Seth GolubMarc LehmannManish SinghTom RathborneMichael J. HammelNick LambSven NeumannDaniel Egger

Seth Golub wrote, "It would be nice if there were a configuration option for a minimal install that left out (and didn't bother to compile) most of the plugins. Given enough disk space, sure, I'll install whirlpinch, but 55MB is more than I can afford on my school account." He added that once he removed all the plugins except jpeg, pnm, png, xpm, blur, and despeckle, the installed footprint dropped from 55MB to 7.5MB (and gimp startup time was dramatically reduced).

After a couple of exchanges, Sven Neumann suggested that Seth hack up the '' script and come back with a patch. Seth replied that he had other free software projects to work on, and didn't want to write a patch for a feature that might be unwanted. Marc Lehmann replied, "Making some kind of plug-in installation manager is currently in the planning phase," and asked for Seth's help. He also suggested, "OTOH, if you can code and just want a minimal install, why not just hack the lines out of that build the extra plug-ins you don't want? Removing these is _exactly_ the same amount of work as selecting which plug-ins you want and which you don't want."

Manish Singh added, "Or just skip the toplevel plug-in dir, and make a little shell script to install the plugins you want. With the 1.1.x series, you can simply to "make GIMP_PLUGINS=" to skip. Each plugin has it's own makefile target which you can call individually."

Elsewhere, Marc also replied to Seth's original post, pointing out that on his machine the gimp only took up less than 13MB. He added that this was not, however, a reason not to have a mechanism for a minimal install.

Tom Rathborne replied that his gimp build was 17MB, still much smaller than 55MB. He suggested, "It may be that Seth is compiling with tons of debugging information in there, is not stripping his binaries, and is not using '--disable-static'. It may also be that he's on a platform without shared libraries :)"

Michael J. Hammel also replied to Marc, saying that on his system the gimp was 58MB, installed from the 1.1.14 source, built with Gimp Perl disabled. However, he disagreed with Seth, saying:

I read through this thread and wondered whether adding installation support should really be part of the Gimp source itself. After thinking it over for a time, I believe distribution issues are separate from core development and should be addressed using external resources.

For example, it would not be exceptionally hard to build a binary distribution placed on a CD which used a modified version of Loki's setup utility to perform some varations of installation. This might also be possible (though a bit more convoluted) to provide source distributions which only build the parts of interest. But the responsibility of letting the user determine what should be installed falls in the setup tool, not in the Gimp. Gimp should build everything and let an installation tool provide installation options.

Marc agreed in principle, but replied, "But think about it this way: you can configure almost everything, including menu shortcuts. Why shouldn't you be allowed to configure your menus as well?" But he added, "This is not the ame as the feature that was requested, of course ;)" He also thought he knew why some installations were over 50MB, and some were under 20. If he compiled the gimp with debugging info enabled, his build got to be over 50MB. Without it, it was much less.

Michael wrote, "Nick Lamb pointed out the "make install-strip" option to me last night. You're right, compiling with debug info isn't necessary for the average person. Unfortunately, there is no reference to this option in the INSTALL file. So it's not "intuitively obvious to the casual observer.""

Marc hadn't known about that feature, and felt it should be documented before 1.2 came out; and Daniel Egger replied with a patch for it.

4. Color Picker Inconsistancies

28 Dec 1999 (2 posts) Archive Link: "color picker inconsistancies"

People: Sven NeumannSven Neumann

Alan Bailward noticed that the color picker that came up in drop shadow was different than what came up when clicking the foreground/background color in the main program. He suggested using the same color picker for scripts as for the main program, especially since the drop shadow color picker had fewer features and incompatibilities with color transfers. Sven Neumann replied:

This is a known problem. The core color dialog can not be used easily from plug-ins since it is implemented in the core, not in libgimp. Of course there is more than one way how this could be changed and it is possible that we decide to go one of them later, but we have a working solution already:

You can use DND between all color-pickers. The colorbutton used in Script-Fu is a DND source and target. So if you want a specific color and prefer the core colorselector, use it and drag the color over to the Script-Fu dialog. You can also right-click the colorbutton and use the menu which offers to import the foreground / background color.







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.