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 <quinet@xxxxxxxxxx> 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 <neumanns@xxxxxxxxxxxxxxxxxx> 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 <tomr@xxxxxxxxxxxx> 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 +-- --==---/ / _ \/ // /\ \/ / pcg@xxxxxxxxxxxxx |e| -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
