Gimp Traffic #27 For 15 Jan 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 63 posts in 216K.

There were 38 different contributors. 9 posted more than once. 8 posted last week too.

The top posters of the week were:

1. Using GIMP Non-Interactively

28 Dec 2000 - 1 Jan 2001 (4 posts) Archive Link: "gimp 1.2.0--a few questions"

People: Chetan DhavseMarc Lehmann

Chetan Dhavse upgraded from 1.1.04 to 1.2.0 and had two questions, the first of which was:

for the information my old programs "used Gimp and Gimp::Fu"
The same programs do not run on newer 1.2.0. I had to change it to
use Gimp qw(:auto __ N_);
use Gimp::Fu;


and then I keep getting the following warnings
Subroutine gimp_text_get_extents_fontname redefined at /opt/other/src/perl-5.6.0/lib/site_perl/5.6.0/i686-linux/ line 539.
Subroutine gimp_bucket_fill redefined at /opt/other/src/perl-5.6.0/lib/site_perl/5.6.0/i686-linux/ line 539.

Marc Lehmann thought this was strange and thought the problem may be in the script itself. He asked Chetan to post a copy of the scripts, which Chetan did. There were no more posts regarding this problem

Chetan had a second question about "plug_in_autocrop"

The plug in "plug_in_autocrop" gives the following error if I use
plug_in_autocrop(1,$img,$layer); (as mentioned in DB browers)
rot: argument type Gimp::Drawable, Gimp::Layer or Gimp::Channel expected (not Gimp::Image) at ./rot line 32 (DIE)
but works fine if I use plug_in_autocrop(1,$layer);

Marc Lehmann pointed out that it was better to use RUN_NONINTERACTIVE or RUN_INTERACTIVE than 1 or 0 because 1 is a valid image id. He suggested using " plug_in_autocrop($img,$layer); plug_in_autocrop($layer); or even $layer->autocrop; " He also stated " This could also solve your problems above, since 5.6.0 is rather broken with regards to error handling (this has been fixed in later snapshots, so best use 5.005_03 or a current perl snapshot if you want sensible error reporting) so the above could just be the effect of a runtime error that doers not get reported but instead garbles perl's internal state. "

There were no more posts to this thread.

2. GTK-Perl And Windows

3 Jan 2001 - 5 Jan 2001 (14 posts) Archive Link: "perl script in gimp for Windows : is it possible ?"

People: Mark LehmannMarc LehmannTor LillqvsitTor LillqvistTor LillvqistHans Brauer

Eric Coutier asked if it was possible to run a perl script in GIMP for Windows.Marc Lehmann didn't think anyone had attempted to compile GIMP-perl. He said "I am quite sure it will not compile out of the box, but I only expect a relatively small number of unixisms in the Makefile to make problems." Tor Lillqvist had tried this before and thought the first hurdle was porting the GIMP-Perl module.

Peter Dove suggested looking at the MKS Toolkit perl distribution (

Wandered Inn suggested checking out UWin from att.research.

Marc Lehmann saw 2 problems, GTK (which would require gygwin) and GIMP-perl (which "is not that demanding, yet it still requires being able to successfully run a configure fragment. If we could hardwire the configuration somehow, the makefile itself should not be very dependent on unix utilities." )

Marc thought cygwin-ported perl would be the easiest because the makefile was unix-like and activestate perl would be the most difficult since it is ported more closely to windows. Tor Lillqvist tried this again and found some problems:

Marc Lehmann thought that most people building GIMP would be able to build GTK as well. He thought gtk-perl would require cygwin unix-like functionality. Tor Lillqvist said " The problem is producing a glib-config or gtk-config for people who download the headers and prebuilt libs (in a zipfile), and install them in some random place, and then would like to build some application." Marc argued that building a downloadable binary for windows should be possible, but was beginning to see the win32 problems. Tor pointed out that a potential developer could using the h:\ or a complex directory such as "\\redmond42\lusers\b\billgates." . Paolo Molaro agreed that cygwin would be the easiest route. Paolo also offered to integrate any patches generated if they are based against the cvs HEAD.

Tor Lillqvist also posted the problems:

Marc Lehmann thought this problem was unsolvable if the compiler was changed due to autodetect stuff going wrong. he thought the key was to use the same compiler for gtk+, gimp, and gtk-perl. Tor didn't think this should matter since " Nothing prevents mixing MSVC- and gcc-compiled DLLs and EXEs of GLib, GTK+. I don't think Gtk-Perl or Gimp-Perl should need to care either." Marc mentioned that there may be command line format issues with unix-like and win32 compilers. He admitted "What's even worse is the config-trickery I do in the makefile to increase the chances of libtool and perl coexisting. It *is* a crual world, even under unix...." Hans Brauer said "Mixing allocators between binaries from different compiler (c-runtimes) does no good as well ... The common case to build gtk+, etc. on win32 are hand-written makefiles. "

Tor Lillqvist also posted the problems:

Marc Lehmann said the better option would be to make glib compilable against perl. He was unsure as to the current state of activestate's perl, in regards to compatibility and compiler requirements. Tor commented that direct emulation in GLib had caused problems before and stated "I think it was wrong to include dirent emulation in libmingw32, and a <dirent.h> header, as that breaks being able to compile the same code with either gcc or MSVC."

Tor Lillqvist posted a final problem:

At this point I bailed out again... I have better things to do, like, eh, sleep?

Marc Lehmann thought the gtk-perl people would be interested any patch generated from the discussion, even if it only solved part of the problem. He noticed many unix-like things in the gimp-perl makefile, but they were limited to installation. He closed by saying "Even trying to build and fail (and you did more) should be very helpful to them I think. Just as I would expect that somebody whotried to build gimp-perl on win32 would end up saying "it bails out during Makefile.PL because it calls ./configure", and I would be happy with that ;)" Tor Lillqvist assumed a working Gtk-Perl was a prerequisite to GIMP-Perl. Tor pointed out "One problem I can think of right now is that the gimp modules want to use entry points in the gimp executable, and for that to work on Win32 you must mark those entry points for export when building the exe. I.e. build the exe kinda like you would build a DLL. There is no mechanism in auto* or libtool to handle that, I think. " Marc thought this would be a problem since the next version of the GIMP makes extensive use of modules.

Tor agreed that it seemed easier to use a perl running on cygwin to generate makefiles for GTK-Perl and GIMP-Perl. Marc agreed that Perl should be ported to mingw32, expect the windows environment and a unix build environment. Tor also pointed out that cygwin was an operating system, in a way, which would lead to cross-compilation (bad for Perl modules). Marc thought mingw32 + cygwin should work.

Hans Brauer mentioned he has ported pygtk and pygimp, which are located at (

Paolo Molaro requested any patches generated from the discussion.

There were no more posts to this thread.

3. GIMP 1.2.0 RPM Files

4 Jan 2001 (1 post) Archive Link: "GIMP 1.2.0 RPM files"

People: Kevin Cozens

Kevin Cozens uploaded GIMP 1.2.0 RPM files to (
He commented " You will find both .src.rpm files and .i386.rpm files. These files were created using the original 1.2.0 tar.gz file. The binary RPM files were built on a Redhat 6.2 machine. At the above site is a .tar.gz file which has the update spec file and two patch files for those who like to roll their own."

4. Suggestions For GIMP

6 Jan 2001 - 8 Jan 2001 (4 posts) Archive Link: "Suggestions for gimp"

People: Sven NeumannSven Neumann Daniel EggerAustin Donnelly

Orson Jones had a few ideas for the GIMP.

Sven Neumann pointed out " This is exactly what the "Color To Alpha" plug-in shipped with Gimp-1.2 does." Austin Donnelly posted that "Select Within" was like his pre-christmas patch to add a "tighten selection" item to the selection menu.

Daniel Egger suggested that bugtracker would be a good place to track this sort of thing.

There were no more posts to this discussion

5. MDI Interface For GIMP

6 Jan 2001 (4 posts) Archive Link: "Optional background window ?"

People: Guillermo S. RomeroSteinar H. Gunderson

Matts Kivik asked for an MDI interface to gimp, citing the learning curve for photoshop users. Steinar H. Gunderson thought this would be a big task under GTK+. Guillermo S. Romero suggested opening an Xnest server with the GIMP launched inside. He also suggested using a desktop to serve the same function, and finished by saying "Of course, I guess patches are welcomed. :]"

6. Submitting Patches

7 Jan 2001 - 8 Jan 2001 (6 posts) Archive Link: "Submitting Patches"

People: Sven NeumannAustin Donnelly

Oliver posted a unified diff against the current CVS (v1.3 source) for "dodge and burn" and asked the best way to submit patches. Sven Neumann said short patches may be submitted though the gimp-developer list or uploaded to He reminded oliver to update cvs before creating a diff, since his patch reverted a change to the preferences dialog. Austin Donnelly suggested this info be put in the HACKING file so it didn't need to be repeated. Sven applied the patch and asked Oliver to email his full name so it could be added to the changelog.

7. Histogram Tool

8 Jan 2001 - 9 Jan 2001 (2 posts) Archive Link: "Histogram patch"

People: Nick LambSven Neumann

Nick Lamb suggested a potential patch for the histogram tool in 1.2.x to address several problems in the 1.2.0 release tool. He suggested: "

  1. Don't say "Blue" when you're displaying "Value" etc.
  2. Give accurate stats FOR THE SELECTED CHANNEL, not for Value
  3. Try to survive stuff changing underneath us
  4. # of pixels is a (large) integer => %1.f not %8.1f in display
" Sven Neumann said the patch was available at (







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.