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 #19 For 31 Mar 2000

By Alex Harford

Table Of Contents


Gimp 1.1.19 is out. You can get it from

Mailing List Stats For This Week

We looked at 60 posts in 184K.

There were 29 different contributors. 12 posted more than once. 4 posted last week too.

The top posters of the week were:

1. Gimp and Perl version problems

22 Mar 2000 - 26 Mar 2000 (2 posts) Archive Link: "Compilation dies at perl/Gimp/Lib.c"

People: Kresimir KumerickiMarc Lehmann

Kresimir Kumericki was having some problems getting Gimp to work with Perl. He writes "The problem is that compilation of Gimp 1.1.18 dies on me at the 'make' stage (while compiling perl/Gimp/Lib.c) with the error pasted below. Machine is PC with Linux 2.0.36 (RedHat5.2), Perl 5.004_04, PDL 2.003, gtk-1.2 and Gtk-Perl-0.6123. If I configure with --disable-perl, gimp compiles all right. I would be grateful for any help."

Marc Lehmann replied that it would be best to upgrade perl or downgrade PDL to 2.000, since there are compatibility problems. He continued by saying "Given that 5.004 is now two versions behind, with perl5.6 now being current, I suggest upgrading perl to _something_ newer. Especially since PDL suffers from subtle errors in this version as well :("

End of thread.

2. Improving Installation Dialog

25 Mar 2000 - 30 Mar 2000 (20 posts) Archive Link: "Gimp User Installation Dialog."

People: Simon BudigSven NeumannSHIRASAKI Yasuhiro

Simon Budig had some comments on the new installation dialogs:

Regarding the first item, SHIRASAKI Yasuhiro asked if Simon was using XFree86 3.9.x or 4.0. Sven echoed his concerns. He noted that Xfree 4.0 was having some problems with fonts and GDK. Simon confirmed this, and was recommended to downgrade to 3.3.6 to avoid these problems.

Sven had some additional comments for Simon. Regarding the dialog size he writes that "We already thought about that when we designed the dialog. We do not change the default font size in the dialog. I think it is safe to assume that people working with 640x480 do not change their GTK default font to a larger font. Using the default font the dialog easily fits on the screen."

Further down in his message, he explains that he does "not like the blue very much. Yesterday I have changed the color to a slightly less drastic orange. The Wilber with the helmet is cute. The reason why we decided to reuse the pixmap that is used for the icon was memory usage. It doesn't really make sense to include a pixmap that is only used once at the very first start of the program... We could change this to load the pixmap from disk, but that might lead to other problems..." He also explained that the default image size is set to find bugs where width != height. This will be changed for 1.2.

3. Suggestions For Gimp 1.2

27 Mar 2000 (7 posts) Archive Link: "Wishlist & Buglist for gimp 1.2"

People: Marc LehmannSven NeumannKevin Cozens

Ar't writes:

xtra/perl-fu/bricks -> xtra/perl-fu/paterns/bricks
------------/Random Art ->------------------/Random arts
Does this really have to be separated ?

script-fu is about scripts, that means files translated on-the-run for example perl, scheme, python, basic (yuck) and so on...

which in general should be all in one - I suggest to rearrange the menu connected with scripts (to all translators - SORRY FOLKS 8-)

scripts which need to be repaired, they work but they don't register (in menu):

these scripts don't work at all:

these are not getting copied to $gimp_dir

In the above text some plugins are in a form of filenames or procedure names

Is "2x2 Blur"(perl) and "Blur"(C) not the same, if so then why double the same plugin (and keep your hands away from the C version)

after Gimp crash, and this is quite often these days:( the units and many other settings disappear. If we happen to have small HDD (or quotas) and we are running out of disk space it behaves the same way.

Proposition: we save all the configuratoin files in a safe way.

cp old new
write to new
if no problem {

mv new old

} else {

rm new mesage: file save failed



When I click the arrows in image space (navigator or so) I get: initial_sub_region:: error :: src->w * (src->bytes + 1) > 512

Ununified Gimp interface

What resolution is Gimp written for ?? As I presume many people start with 640x480 and is happy with 800x600(15") not 2millions x million ;-)

Lack of localization for scheme scripts

I don't think you can remove tips (many applications under windblows:) have help and tips and that does not seem to be a problem

Why colour brushes can be animated and grayscale can not ? (Telling me to stop using the colours is not the answer:).

Marc Lehmann responded to number 1:

No. In an ideal world, Logo scripts would be in Xtns/Logo/whatever, not seperated by language-isms. Nobody should need to memoize wether a plug-in is implemented in c, python or scheme to use it.

IMHO, the perl way (group plug-ins by function, rather than by implementation language) is the right way.

Reorganization efforts in that direction will certainly clean up the menus.

Sven covered some of the later points:

5) Huh? Could you please try to explain that in more words? Eventually I might get what you are talking about then.

6) More details? There's a clear distinction between tools and filters. We try to make the dialogs as compact as possible. A lot depends on the font size you use however. For small displays, I recommened not to change the gtk+ default size (or even choose a smaller one). Of course it's not always easy to keep the dialogs small enough for all screen resolutions. If you think a dialog is excessively large, please write a bug-report (and please be a little more verbose than you did here).

7) We are working on this. In fact, the menu paths already are internationalized and the rest of the GUI is prepared for i18n too. All we need is a parser that extracts the translatable strings out of the script-fu-register calls in the scripts. The rest of the infrastructure is already present.

8) Huh? You can disable tooltips in the Preferences!?

9) This is definitely a design mistake in the animated brushes. We will however not change this before 1.2.

Kevin Cozens wanted to know if it "won't change due to the feature freeze or because it would take too much work to change this close to a release or both?" . Sven replied that it was both. "Since it is problem with the overall design of the animated brushes (they are a special case of PixmapBrushes instead of a special case of a GimpBrush), it would mean to rewrite lots of working code. This would mean lots of work and of course it would very likely introduce new bugs. Actually if the changes to the tool_switching code Mitch introduced just recently turn out to actually work, most of the showstoppers are gone and it looks like a release is pretty close. We only have to figure out how to deal with the problem of iconified dialogs that don't want to go away."

4. Suggestions For Global Locking

27 Mar 2000 - 28 Mar 2000 (6 posts) Archive Link: "Global Locking for Gimp :-("

People: Simon BudigSven NeumannAustin DonnellyMichael Natterer

Simon Budig writes:

I see, that Gimp can be crashed very easily when trying to use multiple tools at the same image/layer. Michael adressed this: from the changelog:

2000-03-25  Michael Natterer  <>

        * app/cursorutil.[ch]: new global variable "gimp_busy" which gets
        set/unset whenever busy cursors are added/removed.
        Here starts the ugly workaround which simulates something like
        locking. If it works, it will close lots of bugs, if not, it's
        easy to remove again.

        So far, I didn't find strange side effects but Gimp is told to be
        a complex program :-) Please test this.

Well - unfortunately this disables "user multitasking" with working on multiple images. Admittedly I dont do this too often, but sometimes it is nice to paint something while waiting for a big image to rotate. (just tested - multiple plugins do work! :-)

Is there any chance to do this on an "per image" base without hazzeling too much? Or - if this is too hard to implement - do you think that this limitation is better than crashes which could be avoided if the user knows that parallel operations on an image will fail and result in data loss?

Sven noted that "It's not only parallel operations on an image. Gimp doesn't like you to change the tool while it is active. So you can't rotate an image (using the transform tools; using the rotate plugin should work) and change to the paint-tool to paint even if you do this on another image. Tools are global, so we have to disable tool-changes globally."

Austin Donnelly replied that he:

I proposed to add per-image locking a while ago, but apparently this wasn't too well liked. I'm can't remember why.

There are 2 tricky parts (as far as I can see):

  1. plug-in.c needs to take out an image lock when starting a plugin operation, and release it on normal (or equally importantly) abnormal plugin termination.
  2. what happens when acquiring a lock fail? Do you queue the operation up on the lock (hard) or do you fail it (easy)?

Simon had some additional ideas for Austin:

I think, proper locking is among the first things that should go in Gimp 1.3. However, it may be a little bit late for 1.2 :-(

What Im thinking about is: Every user action starts in the image window. When we prevent

  1. clicks in the image to take effect
  2. selection of menu items (graying out?)

if this image is "locked" we have a lot of potential crashes fixed. We could even give some sort of feedback through the cursor.

Well, when a script or plugin randomly accesses the locked image then this is bad luck, but I think this should not happen too often.

The way described above eventually could be handled inside the callbacks. Mitch: Do you see a chance to get it working this way? Is this reasonable?

Michael Natterer explained why he made the changes. "Implementing real locking as proposed by Austin is however too late for 1.2 and I fear that it is the only way to get the lock per image. I tried to block display events only for the image the current tool is working on, but then I noticed that of course any display event may trigger a tool operation which is a bad idea while the tool is active. Once tools are GtkObjects it should be easy to ref the tool while it's active and simply allocate a new one for a simultaneous operation on another image. When the old tool finishes it's operation it will be unref'ed and disappear automatically if it's no longer ref'ed as active one."







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.