Gimp Traffic #17 For 10 Mar 2000

By Alex Harford

Table Of Contents

Introduction

Yosh announced that GIMP 1.1.18 is out:

ftp://ftp.gimp.org/pub/gimp/unstable/v1.1.18/ (ftp://ftp.gimp.org/pub/gimp/unstable/v1.1.18/)

Mailing List Stats For This Week

We looked at 50 posts in 156K.

There were 24 different contributors. 8 posted more than once. 15 posted last week too.

The top posters of the week were:

1. Suggestions for Improving Gimptool

25 Feb 2000 - 4 Mar 2000 (12 posts) Subject: "gimptool"

People: Robert L Krawitz, Marc Lehmann, , Manish Singh

Robert L Krawitz said:

Gimptool has no specific way to echo the name of the Gimp installation directory. There are options for installing things, for getting flags, and such, but nothing to simply report where the Gimp is installed.

The issue here is that I'd like change the printer descriptions inside the print plugin to use a control file of sorts rather than having all the capabilities hardcoded in the driver (forcing a recompile to make even minor changes). Right now I can get by with --install-bin and such, but that won't help me if I need to install auxiliary files.

Marc Lehmann noted that:

For backwards compatibility, with 1.0 I use

($plugins = `$GIMPTOOL -n --install-admin-bin /bin/sh`) =~ s{^.*\s(.*?)(?:/+bin/sh)\r?\n?$}{$1}}

(I only need it in the testsuite, which is not run when we're inside the gimp source tree)

Robert replied that this will work for any system with Perl, but wondered what the output is for Gimp 1.0.

In another sub-thread, Manish Singh said that Robert could use "gimptool --prefix" and "gimptool --exec-prefix". Robert wasn't satisfied. He wanted to know the exact directories that were used. Manish replied that gimptool could be altered to give almost any variable used during installation. Robert replied that he wanted to provide some printer descriptions in text files, but needed to know where they could be installed. Manish asked if gimptool providing a $(gimpdatadir) (like ${prefix}/share/gimp) would be satisfactory, and Robert agreed. EOT.

2. Compilation Problems

2 Mar 2000 - 3 Mar 2000 (2 posts) Subject: "Missing Makefile.in in /intl"

People: Jens Reimer, Daniel Egger, 

Jens Reimer said, "Hello, i have a problem compiling the cvs versions of gimp: After starting the autogen.sh there is no Makefile.in in /intl. If i try to start ./configure manually sed is missing this file also. What is wrong with it?"

Daniel Egger replied that the "files in /intl are produced by gettextize. You need a working gettext-0.10.35 (available from your favourite GNU mirror) to compile the gimp yourself WITH nls."

3. Disabling Perl-Fu

8 Mar 2000 (7 posts) Archive Link: "Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present"

People: Raphael Quinet, Seth Burgess, Tom Rathborne, 

Raphael Quinet asked about disabling Perl-Fu, "I think that it would be better to disable the installation of all Perl-Fu scripts if any of the required modules (Gtk, PDL, Data::Dumper, Parse::RecDescent) are not detected by the configure script or, more exactly, by Makefile.PL."

He provided several reasons why he thought it should be done this way, and continued by saying, "For these reasons, I think that it would be better to use the "safe" method: do not install any (or most of the) Perl-Fu scripts if the required modules are missing during the "configure" phase. And rely on the fact that the person who installed the Gimp will re-install it easily if the Perl modules are installed later."

Seth Burgess agreed. "As far as PDL and Gtk goes, I'm in agreement that it shouldn't install those scripts with those dependencies uless those packages are detected. gimptool should be able to install them later for users wishing to upgrade later - its the way everything else in gimp works."

Tom Rathborne asked "Why can't those scripts just _not_register_themselves_ if the required modules are not available? gimpmagick does this and the only problem is that it has to be re-probed every time the GIMP starts. The only reason I can think of to not install these scripts is to avoid the delay at startup."

Raphael replied:

Yes, and this "only reason" is quite significant for me. On a multi-user system that mounts all Gimp files over NFS, querying all plug-ins and scripts at startup takes more than 40 seconds (depending on the network and server load) with a default installation of 1.1.18. This is much too slow, but fortunately this is a one-time thing and after that everything runs smoothly.

After the first run, the Gimp starts in about 10 seconds (5 of these are taken by Script-Fu). If more scripts would be queried every time at startup, the delay in starting the Gimp would be unacceptable. Fortunately the situation is a bit better on a single-user system or a system which has all files on a local disk, but I think that any additional delays during startup should be avoided.

This means that it is better to skip the installation of a script or plug-in that has some unsatisfied dependencies than to install it anyway at the expense of some additional startup delays.

4. Changes to edit_selection.c

8 Mar 2000 (3 posts) Subject: "recent commit..."

People: Adam D. Moss, Tor Lillqvist, 

Adam D. Moss had some questions about the recent changes to edit_selection.c. "I'd kinda like to see this reverted and fixed at the WIN32 GDK level -- if gdk_event_get() fails straight after a gdk_events_pending() succeeds in a single-threaded app then it's not just GIMP that's going to have a problem... unless this is documented cross-platform behaviour, of course! Tell me if I missed something."

Tor Lillqvist explained that this could happen on X11 as well. "After all, gdk_events_pending() just checks for (gdk_event_queue_find_first() || XPending(gdk_display)). If the event queue is empty, but XPendig() returns TRUE, that still doesn't mean that any of the X events that are waiting will necessarily generate any GDK event, does it? If gdk_event_translate returns FALSE, no GDK event will be put on the queue." Adam replied that he was cool with this change, and there were no more messages in this thread.

 

 

 

 

 

 

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 kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.