I just wanted to note that the suggestion of Raphael is based on
assumptions that were either never true, or were true many months ago.

Before all of you second his suggestions I would really appreciate it if
people looked at the current situation. (I mean: think first!)

Disabling all perl-plug-ins because somebody didn't want to check the
facts is, for me, a very big decision that should not be made lightly.

On Wed, Mar 08, 2000 at 01:07:52PM +0100, Raphael Quinet <[EMAIL PROTECTED]> wrote:
> of all Perl-Fu scripts if any of the required modules (Gtk, PDL,

No script will show up in the menu if it depends on something not installed.
For PDL, the scripts won't be installed in the first place.

Ok, povray is an exception, but since I didn't have time to work on it'll
be better to disable it in 1.2 anyway. And, maybe, some script slipped
through this. If that is the case just pretend it's a bug.

1. If PDL is missing, no scripts depending on it will be installed.
   I don't see why all the majority of scripts not using PDL should also
   be disabled.

2. If Data::Dumper is missing, some(!) scripts loose the ability to
   "RUN_WITH_LAST_VALS". I don't see why they should be disabled because
   of that. After all, perl5.004 is dead and I think it works extraordinarily
   good with that version despite that.

3. No plug-in depends on Parse::RecDescent. The installation of scm2perl (the
   only user) should be disabled - this is on my TODO.

4. Gtk is a major problem. I feel that an effect running with (sane) default
   arguments is better then no script at all. It costs just the same
   mouse-clicks to use these scripts. If people disagree then this is the
   place to discuss it.

> Note that I am not criticizing the Gimp-Perl plug-in itself, only the
> way the Perl-Fu scripts are installed.

Yes, this is fine. I am still angry, for the following reasons: In the
past it has happened very often that somebody suggest to disable gimp-perl
in various ways, for reasons that ranged from "Marc isn't fast enough in
fixing" over "Marc doesn't fix the bugs that were never reported" over
"Perl is an ugly language" over "I am neglecting the situation and spread
FUD" to "well, there are real problems not being addressed".

The latter reason was rare, however :(

I don't think that any other part of gimp got attacked in these ways so
often than gimp-perl. I already have the feeling that gimp-perl bashing is
some kind of sports.

I do not mind if some people (like Raphael) make suggestions based on a wrong
understanding of the situation. I am, however, astonished that even people
like Sven, who _does_ _know_ _better_ takes it so lightly:

On Wed, Mar 08, 2000 at 06:29:18PM +0100, Sven Neumann <[EMAIL PROTECTED]> 
wrote:
> I second this suggestion.

Sven, how can you second the suggestion to disable all perl scripts? I
would think it would be quite insane to disable all plug-ins, just because
configure found out that one of them does not run on this system?

According to this logic, the lack of perl5.004 or higher should definitely
result in NO plug-ins installed AT ALL.

I'd say the current situation, i.e. install the plug-ins that _do_ work and
leave out the ones who don't work, should be fine.

> (because the user did not download them from CPAN), the Perl-Fu
> scripts crash when the Gimp is started or when they are accessed from
> the menus.

This is indeed very bad. And I am absolutely determined to fix those bugs.
However, are you _sure_ that these scripts are no left-overs from previous
installations?

In any case, I'd suggest reporting these problems: You can't expect
problems to get fixed without notice.

> - All other plug-ins take the "safe" approach of not installing
>   themselves if any dependency is not satisfied.

gimp-perl _does_ this. Everything else is a bug, and two of these bugs
(povray and scm2perl) are on my TODO.

>   As far as I know, the Perl plug-in is the only one that tries to

What you "know" directly clashes with what I "know".

>   it is only some modules).  So there is no reason to force the
>   installation of the Perl-Fu scripts if they could easily be
>   installed later, after having installed the missing modules.

That's why the current situation (some scripts do not register themselves)
will be addressed (again, look at my TODO).

> - The Gimp takes 5 to 6 seconds longer to start if the required Perl
>   modules are missing, because some Perl-Fu scripts crash during
>   start-up and are queried again every time.  See the first example

This is a gimp bug, which I have reported a few times already (yes, also
using the bug tracker(s!)).

> Can't locate Gtk.pm in @INC (@INC contains: /usr/lib/perl5/5.00503/i586-linux 
>/usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i586-linux 
>/usr/lib/perl5/site_perl/5.005 .) at 
>/usr/lib/perl5/site_perl/5.005/i586-linux/Gimp/UI.pm line 5.

Raphael. If you had reported this earlier, it would have been fixed much
earlier. This is indeed an oversight, but easy to fix.

I would have cost you, me, and the others on this list a lot LESS time if
you just reported this.

Why people report bugs for other parts of the gimp, but not for gimp-perl,
escapes me....

> The second example shows some errors that occur when I attempt to

These errors have nothing to do with missing modules, instead these are
errors in these scripts (I'll have to check).

Again: reporting these bugs (so they can get fixed) would be much more
productive than to just disable all of perl :( But one can't expect this
from gimp-developers, can one?

On Wed, 8 Mar 2000, Tom Rathborne <[EMAIL PROTECTED]> wrote:
> Why can't those scripts just _not_register_themselves_ if the required
> modules are not available? gimpmagick does this and the only problem

This is the current situation (modulo bugs), and due to the cited gimp
bugs this is very sub-optimal, and not clean in any case.

> > delay at startup.
> Yes, and this "only reason" is quite significant for me.  On a

Why not fix the existing bug in Gimp anyway?

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

It is better not to install anyway. Nevertheless you blame the wrong code for
that problem :(

In any case, I would suggest to ignore Raphael's suggestion and
concentrate on fixing existing bugs.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       [EMAIL PROTECTED] |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Reply via email to