Gimp Traffic #22 For 5 Jun 2000

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."

28 May 2000 - 29 May 2000 (4 posts) Subject: "installation in non-standard location / configure bug"

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."

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 ;->"

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.

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.

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?

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."

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"

1.	28 May 2000 - 30 May 2000	(2 posts)	Toolbox Resizing Problems
2.	28 May 2000 - 29 May 2000	(4 posts)	Problems Installing The Gimp In Non-standard Locations
3.	29 May 2000 - 31 May 2000	(4 posts)	New Feature: Rotate Brush While Following A Path
4.	30 May 2000	(12 posts)	Licensing Issues With XCF Loader
5.	30 May 2000	(3 posts)	Gimp Plugin Template Questions
6.	31 May 2000	(2 posts)	Adding Transparency In Perl-Fu

Gimp Traffic #22 For 5 Jun 2000

By Alex Harford