Yosh announced yet another 1.2 Pre-Release. It can be downloaded from ftp://ftp.gimp.org/pub/gimp/v1.1/v1.1.23/
If you haven't downloaded your 1.1 version yet, please do so now. It is important that all the bugs get found so the developers can release 1.2!
Nem W Schlecht is having a couple problems w/
gimp-1.1.x that I've been trying to figure out. The Gimp toolbox doesn't
come up correctly (there is "blank" column on the right hand side),
and each successive time I run the Gimp, the toolbox gets smaller and
smaller.
He was also having problems with the window geometry being reported
incorrectly. I don't know about the second
problem - I'm guessing there's nothing wrong in session.c, but rather the
window geometry is reported incorrectly to session calls. I don't have any
other geometry problems with any of the other windows (I usually have layers,
brushes, patterns, palettes, and gradient dialogs open).
He continued
by describing his setup, I'm running Solaris
8 x86, gcc 2.95.2. I've had tried both glib/gtk 1.2.7 and 1.2.8, with gimp
1.1.x (started around 17 or 18, if I remember correctly). I've been looking
into it more w/ 1.1.21 & 1.1.23.
Keith Parks replied that he reported the shrinking
behaviour as bug Bug#9683.
He is thinking that the bug is caused by CDE in Solaris.
Warren Hedley writes:
I've just compiled and installed gimp 1.1.22 under Irix, but have done so in a non-standard (ie. not /usr/local) location so as not to interfere with other users on the network.
My problem is that the executable seems to expect user_install to be in /usr/local. I get this message when it starts trying to create my personal directories
/usr/local/share/gimp/1.1/user_install does not exist. ...
My configure line set the prefix like this:
./configure --enable-perl=/product/perl/bin/perl --disable-nls --prefix=/product/gimp
I've tried setting the GIMP_HOME environment variable to /product/gimp, and added /product/gimp/lib to my LD_LIBRARY_PATH.
He also adds that the configure script is not looking for perl where he specified, but is looking in the standard location.
Marc Lehmann replied that the --enable-perl option
specifies the perl prefix to install the perl modules, not the perl
executable path. Specifying a file will be disastrous.
Raphael Quinet suggested that
the option should be named "--enable-perl-prefix" instead of the shorter "--enable-perl", in order to avoid confusion. This would be more consistent with the other options, and longer names are not a problem because they are not used very often anyway. The help string should then be changed to "--enable-perl-prefix=PFX".
If someone wants an option to specify the path to the perl executable, then it should be "--with-perl=...". Maybe adding the "--with-perl" option would make people think twice before making incorrect assumptions?
Raphael Quinet had some suggestions for improving brushes. He would like to
add an option to rotate a brush automatically
according to the local tangent of the path that the brush is following. To
make it even nicer, the user should be able to specify what is "local": how
many pixels should be taken into account for calculating the angle.
He tried playing with making brushes that could do this and came to the conclusion that it would be better to have brushes that can be dynamically rotated depending on the path. He concluded that making brushes with enough static frames to do this would be a huge memory hog, and it would be easier to have the CPU handle it.
Tom Rathborne replied that he was thinking about the exact same thing. He
added that brush spacing is also
important in this case - you would want to be able to stroke with,
say, a rainbow line, and have both edges of the stroke come out
perfectly smoothly, as if you had stroked with a couple dozen parallel
single-pixel brushes.
He also noted that brush
pressure/alpha/transparency is also important. When you're stroking a
circle, you don't always want the inside of the circle to be more opaque
just because the brushstrokes are somehow "denser" there. You _do_ want this
if you're trying to imitate natural media, though.
Adrian Likins wrote that he thought this is
something I would like to see as well. The simplest approach would be
increase the "angular" resolution of Pipes, and then just generate a pipe by
rotating the brush shape. The primary reason I would like to see this, is to
make it possible to create a "gimpressionist" style painting tool. The
plugin currenty works by taking a single brush shape, rotating it X number
of times, and then painting to the image with whatever rotated brush fits
closest to any edges it finds in the image. No reason we cant do that with a
painting tool ;->
David Hodson replied that he had written:
a short piece on implementing this sort of thing a while ago. Wrote the code and it seemed to work OK; but I was having trouble deciding on the best way to incorporate it into the existing GUI, and I thought that 1.2 was closer than it has turned out to be, so I left it for later. The writeup is at:
http://www.ozemail.com.au/~hodsond/gimpbrush.html
for those who might be interested.
Federico Mena Quintero announced that
Jens Finke <pearl@darkride.net> has sent me an amazing patch to add support for XCF file loading to gdk-pixbuf. I would really like to have this sort of functionality so that simple programs like EOG can view GIMP files.
However, there is the issue of licensing. Gdk-pixbuf is released under the LGPL, and the XCF loader uses big chunks of GPLed code from the GIMP. I am not sure what is the best way to proceed.
Phil Schwan asked if Federico knew who the copyright holders were. Kelly
replied that they were At least myself, Peter, Spencer, and Adam Moss. There are
almost certainly others.
Austin Donnelly said that he couldn't recall if he had added some code, but gave his permission for the copyright to be changed if needed. Michael Natterer said that he had done the GimpUnit loading/saving code, and gives his permission to make it LGPL.
The discussion continued in several subthreads. Even Alan Cox got into the discussion. Nobody
really came to a final agreement on this, and Marc Lehmann summarized the problem quite
well, saying, The problem, of course, will be S&P, which
are very difficult to contact. It took quite a long time until I had the
license changed from GPL to LGPL for a single file in libgimp, so whoever
weants the license changed should act soon ;)
There were no more messages in this thread.
Kevin Turner had some questions about the GIMP plugin template. He asks:
What is the purpose of including src/plugin-intl.h in the template? Does #include "plugin-intl.h" do something that #include <libgimp/gimpintl.h> does not?
How are individual user installations supposed to work? (is there a target that installs to ~/.gimp?)
are config.sub and guess necessary for most plug-ins?
In response to the first question, Sven Neumann replied:
Yes, a lot!
Actually plugin-intl.h as shipped with gimp-plugin-template is the equivalent to libgimp/std-plugins-intl.h which is included from all plug-ins in the standard distribution.
plugin-intl.h includes <libgimp/gimpintl.h> and builds a wrapper around the basic internationalisation macros defined their. By including it you get two macros:
INIT_I18N() and INIT_I18N_UI()
that do the dirty work of binding your application to the libgimp's and its own textdomain. I'd suggest you take a short look into plugin-intl.h, it should be self-explanatory.
Sven also replied that he didn't think it was necessary to have a target for ~/.gimp, but config.sub and guess are necessary if the plug-in is going to use configure.
Kevin responded that the usual way for people
to install plug-ins they downloaded has been "gimptool --install" (or
"gimptool --install-bin" called by the Makefile), which installs to the gimp
directory in $HOME. So I think that is the expectation based on Gimp history.
And unless we have decided that everyone who uses gimp is either a sysadmin
or on a single-user box, it makes sense to keep that behaviour.
Gunjan Kapoor writes, Could someone help me out
with this. I need to specify a transparent colour for the entire image. Is
that possible with Perl-fu. e.g: specify white as the transparent colour.
Additionally, I need to make the background transparent for a programmatically
generated image. The image contains only one drawable. I've tried adding an
alpha channel programmatically but perhaps did not know the proper procedure
and the desired results were not achieved.
Marc Lehmann asked
What do you want to do? Do you want to replace white by transparency? This is easy (not only in perl-fu, btw), just use plug_in_colortoalpha, e.g.:
$layer->colortoalpha(WHITE);
If you just want to replace a specific colour index (e.g. in an indexed image) you can also use select_by_color and selection_clear.
In response to the question about adding Alpha, Marc said that it is usually done with a "$layer->add_alpha"
There were no more messages in this thread.