Yosh announced that GIMP 1.1.18 is out:
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.
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.
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.
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.