Simon Budig posted that he was not going to be able to organize
a booth at Linuxtag this year, and asked if anyone was going to
be able to make it. Jens Finke said that the Gnome booth would
have enough room and that GIMP people were invited to join in
promoting Gnome/GIMP. Daniel Egger offered to demonstrate the
GIMP for a day. Rebecca J. Walter also offered time at the booth,
but warned that she spoke no German and wasn't a coder.
Tom Rathborne had so much fun last year at Linuxtag that he was
trying to make it there again this year. He offered to help
with the booth if he could make it.
Marc Lehmann said he would be there, and also warned
... I am a total idiot at these kind of
things, so it's best NOT to think about letting me do that
Hans Breuer posted the following question about
compiling the Gimp from CVS on win32.
One problem is the missing of string.h in the following autgenerated files:
Sven Neumann said pdbgen used memcpy in the autogenerated code. he
also committed a change that added string.h to lib.pl
although I have looked into pdbgen.pl, the only thingh I've got is headache -
Perl is definitely not my language :) Could someone else try to fix it (or
should I workaround with a small makefile hack) ?
Another issue is a small removement of duplicated code:
app/asupsample.c and libgimp/gimpadatipvesupersample.c are the same.
The left one can be removed, if the right one is moved to libgimpcolor.
Chuck Mason posted an interesting variation on the crop tool from the TODO file, whereby crop_image_by_color and crop_image_by_blending could be added. Sven Neumann pointed out that TODO.xml was the up-to-date version of the file and TODO was no longer maintained. Sven also mentioned the original intent of the TODO item was to give the user better feedback about what was outside of the crop area, not to create an alternative method of cropping. He pointed to http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome&dir=gimp as the location of the real TODO.xml
Johannes Zellner had the following problems compiling the Gimp from CVS source
Raphael Quinet mentioned
As announced on GIMP News (http://www.xach.com/gimp/news/) by
Zach Beane on the 15th of January, the CVS version is currently *very*
unstable and should not be used except if you are a developer.
Several developers (mostly Sven and Mitch) are rewriting large parts
of the code, so for the moment you will only get less features than
the 1.2.x version (not more features like 1.1.x compared to 1.0.x).
It will probably take several weeks or months to get something stable
and usable.
Raphael also added
I do not know which switch causes the problem, but "-funroll-loops"
and "-malign-double" should be safe. "-ffast-math" should be safe as
long as the code does not try to do stupid things like sqrt(-1).
Maybe one of the other options is causing the problem. Just a wild
guess: this could be related to the new MMX code, or some other
asm-optimized code that could be upset by "-freg-struct-return" or by
"-mpreferred-stack-boundary=2".
Matthias Kleine asked if it were possible to locate a
pixel of a particular color in an image (say red 255,0,0)
Example: I am using a webcam to observe an area. In this
area, a red object is moving around. Now, the webcam is
delivering images to some client program (gimp plugin?). This
program now should calculate the current position of the object
in the observed area.
Lourens Veen suggested winding the pixel in the first image, then searching from the last known position outward in a spiral pattern in all subsequent images. Lourens added that it would be necessary to filter out an red areas larger than the maximum object size. Sven Neumann suggested an app called "motion" on freshmeat.
Tamito Kajiyama posted
On a GIMP BBS I've heard that script-fu scripts cannot get the
effect of pushing the "Auto" button in the Image->Colors->Levels
dialog. Here is a patch to add the procedure gimp-levels-auto,
an automatic version of gimp-levels.
Seth Burgess thought it was a good idea, but mentioned that
the *_cmds.c fiels are autogenerated by the tool pdbgen and
as a result the patch really needed to be on different files.
Tamito pointed out that the HACKING file was not part of the
Gimp distribution, so people working from source tarballs
missed this information. Tamito then submitted a patch to the
correct files. Seth said he considered this a bug fix, so it
would probably go into the 1.2.x branch.
There were no more posts in this thread
lasm asked if there was a web interface to the Gimp CVS tree. Rebecca J. Walter pointed out that the gimp cvs is part of the gnome cvs. Dave Neary directed people to http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome&dir=gimp
Jason Maskell posted an error encountered when running the SOID Console under windows for
batch more script-fu. The error was
ERROR: wta to car (errorobj 123324) - Ok, the 123324 is one of my arguments,
but is the error message supposed to be in English?
ERROR: wta(1st) to quotient (errorobj 150) - Again, one of my args, and
another nonsensical sounding error message..
Simon Budig said the arguments were acceptable and that car
could only be called on lists and cons.
Austin Donnelly posted that wta might mean "wrong type for argument"
Sven Neumann agreed about the meaning of "wta" and thought
that bad error messages were
even more difficult when they had to be translated from English first.