Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
[snip] > I have just send a better bug report to the bugtracker, hoping that it > will help you to fix the bugs in the scripts. However, I see that the > form on Xach's site wraps the text in a very ugly way, so my nicely > formatted bug report is now very difficult to read (#7732). I will > send a copy of the bug report to you by private e-mail. I just changed it so it doesn't wrap at all. [snip] > > Well, I still think that I understood the situation quite well. ;-) > The difference between you and me is mostly a matter of opinion. I > consider that running the Perl-Fu scripts with the default values when > there is no Gtk is a bad thing (because of the warning box, because it > is difficult to guess what the script will do without seeing its > parameters, because there is no help, because some scripts disable the > undo on the image and because of the crashes that will hopefully be > fixed). So that's why I consider that installing these scripts when > Gtk is not present is a bug, or at least a disservice to the user. I > understand that you disagree and you would prefer to install them > anyway. Well, we can at least agree to disagree... I stuck a simple poll up regarding this a few days ago for the #gimp channel. Participation was rather light. Maybe with some exposure from the list, a more meaningful result could be determined: http://www.moviegroups.org/poll/one-poll.tcl?poll_id=22 Zach -- Zachary Beane [EMAIL PROTECTED] PGP mail welcome. http://www.xach.com/pgpkey.txt
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
On Sun, 19 Mar 2000, Marc Lehmann <[EMAIL PROTECTED]> wrote: > On Mon, Mar 13, 2000 at 05:01:56PM +0100, Raphael Quinet <[EMAIL PROTECTED]> wrote: [...] > > So the current situation is: if you do not install the required Perl > > modules (especially Gtk.pm), most of the scripts do not produce any > > useful results. > > This is a bug that was easily fixed once I was told about it. If you had > filed a bug report on the gnome bugtracker, you would have been more than > right to complain (I cannot read it as often as I wished), but as it seems > you kept quiet until lately. OK, I should have used the bugtracker. Actually, I had a quick look at it some days ago (before sending my previous message) and I saw a few open bugs that were related to Perl scripts. I did not look at them (my connection was much too slow) and I though that they were reporting errors similar to the ones I saw, so I assumed that the problems were "well known". Well, I guess that I should double-check before I assume some things... [...] > > You could of course try to fix these crashes, because some of them > > look like real bugs in the scripts, but my message was not intended as > > a bug report.. > > I saw that, and I think this was very unfortunate :( OK. I should have spent a bit more time to make a complete bug report out of my message, instead of simply including the output from the crashes as an example. I spent some time testing all Perl-Fu scripts yesterday, so now I can send you a better bug report. [...] > I would guess reporting bugs in any way (I'd prefer mail on > gimp-developers or personal, to not clutter the list, but I understand the > need to scan the gnome bugtracker very well!) would help the situation > much more than asking for removing of plug-ins from the installation. Just > let the maintainer decide wether he can fix it, or wether the script > should be disabled, and bring the topic up when the maintaier (for > whatever reasons) does not do it. For example, when I was away and a > release needs to be made, disabling most or all of gimp-perl would be very > viable :) I have just send a better bug report to the bugtracker, hoping that it will help you to fix the bugs in the scripts. However, I see that the form on Xach's site wraps the text in a very ugly way, so my nicely formatted bug report is now very difficult to read (#7732). I will send a copy of the bug report to you by private e-mail. > > ... when this is clearly not true. I believe that I understand the > > situation very well and I thought that my previous message contained > > enough explanations to make this clear. > > However, I still don't believe you... ;) I didn't meant to insult you in > any way, I just wrote what I thought (and mostly still think). This is my > opinion. If I wrote it in an insulting way, let me apologize. It was not > what I intended. Well, I still think that I understood the situation quite well. ;-) The difference between you and me is mostly a matter of opinion. I consider that running the Perl-Fu scripts with the default values when there is no Gtk is a bad thing (because of the warning box, because it is difficult to guess what the script will do without seeing its parameters, because there is no help, because some scripts disable the undo on the image and because of the crashes that will hopefully be fixed). So that's why I consider that installing these scripts when Gtk is not present is a bug, or at least a disservice to the user. I understand that you disagree and you would prefer to install them anyway. Well, we can at least agree to disagree... > > Please, read my message again. This is _not_ what I suggested and I > > think that Sven and the others understood my message correctly. > > You did wrote this, whatever you really meant to write. And since you also > wrote verbosely about your reasoning (which was based on "facts" which were > wrong), I came to the conclusion that you lack a good enough understanding of > the situation. Well, I still don't understand why you think that my message was based on incorrect facts. I just re-read the first message that I posted in this thread, and I don't see any incorrect facts. You may think that the _conclusion_ is incorrect because I suggest to disable the installation of the scripts using some optional modules (e.g. Gtk) when these modules have not been downloaded from CPAN (even if the scripts can run with some default values when Gtk is not there). You may also think that it was wrong for me to suggest to disable the installation of "any (or most of the) Perl-Fu scripts" if the required modules are missing, but this is because most modules use Gtk (and, as I wrote before, they should be considered as requiring Gtk because they do not work well with the default values -- even if the bugs are fixed.) I mentioned "most" as an alternative to not installing "any" scripts, simply because it is easier to skip the installation of everything during
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
On Mon, Mar 13, 2000 at 05:01:56PM +0100, Raphael Quinet <[EMAIL PROTECTED]> wrote: > > Before all of you second his suggestions I would really appreciate it if > > people looked at the current situation. (I mean: think first!) > > Marc, it is unfortunate that you are replying in a defensive mode as No, I am not in defensive mode. I am in educating mode. I might be personally scared that people post things and try to make decisions based on a wrong understanding of the situation. Especially some people who could know better. I didnt feel personally attacked by your post... > is because a similar proposal that I sent several months ago was > rejected because you said that all my claims were FUD. At that time, > some of my assumptions were wrong and some other were right but my > suggestions were ignored as a whole. Indeed, that can happen easily :( > So the current situation is: if you do not install the required Perl > modules (especially Gtk.pm), most of the scripts do not produce any > useful results. This is a bug that was easily fixed once I was told about it. If you had filed a bug report on the gnome bugtracker, you would have been more than right to complain (I cannot read it as often as I wished), but as it seems you kept quiet until lately. > Besides, even if they would work, the pop-up messages warning the user > about the missing module are not very friendly and lead the user into > thinking that the Gimp is half-broken because the menus are cluttered > with entries that generate warnings. But neverteheless work (modulo scripts that di not supply defaults, but these were script errors). My reasoning was that the scripts do provide the basic effect, with at most the same number of user interactions (O.K.) as if Gtk were installed. I disabled this as people seemed to object (well, I only asked a few people, but they were enough ;). > > 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. > I agree, but this is _not_ what happened. This is exactly what happened. You might not have intended it, but that doesn't mean anything to me -> I was not angry at you anyway, so what counts is the result. > > 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. > > This is only partially true. Most of the scripts depend on Gtk. This is wrong, IMHO :) > are supposed to be able to run without it by using only the default > values, but this does not really work: all of them generate warnings, > most of them crash, and their usability is limited. This were/are bugs, most of which were fixed by a single fix inside gimp-perl. IF you had reported them earlier, it would have been fixed earlier. > I sincerely hope that you will not consider this message as a personal > attack. I didnt, don't and probably won't consider any of your messages as personal attack. I feel that your first message was deeply wrong, however, and went out to try to correct that. > > 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. > > OK, then you could just skip the installation of those scripts, and This is _exatcly_ what is happening since many months. Why is it so difficult for me to communicate this to you? > That was my main argument. If Gtk is missing, the user will get many > warnings (one pop-up every time they try to use a Perl script) which > gives the impression that the Gimp is broken. Ok, so let's disable them for PR purposes. Fine with me... > After the warning, most of the scripts crash anyway. Ever occured to you that this was not a deliberate thing I did, but simply some kind of, well, lets call it a "bug"? > You could of course try to fix these crashes, because some of them > look like real bugs in the scripts, but my message was not intended as > a bug report.. I saw that, and I think this was very unfortunate :( > > 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. > > Please, stop taking this personally! Me != gimp-perl. It might be hard for you to understand that, but gimp-perl is not part of my very heart. I happen to argue for some things I have never touched myself, when I feel that they are attacked. In the past, I have defened other parts of the gimp (which were not "mine") similarly. > Maybe gimp-perl has been discussed so often because of the way you reply > to some messages However, I am deeply determined that I did not start this kind of action-reaction pattern. What makes it so bad is that I won't let FUD spread, regardless of what people might think of me. > that there are some problems. Whether these problems are technical, > philosophical or purely imaginary
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
On Mon, Mar 13, 2000 at 05:47:37PM +0100, Uwe Koloska <[EMAIL PROTECTED]> wrote: > What about making an extra package with all perl-modules required to run Gimp Making packages is very much a distribution-only thing. So far, the most what gimp does is support making a single source tarball, and it also has a "sometimes-updated" gimp.specs file for makingrpm packages, maybe soon to be complemented wiht a suse version that has support for seperate python/perl etc.. packages. > the whole power of Gimp. Some addition to the ./configure could lead to a > message "You don't seem to have some important perl packages installed. If you Already happens. What was needed was a change of definition of "needed", after which everything becomes clear :) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
Raphael wrote on Mon, 13 Mär 2000: > >As an end-user, I prefer a stable application that may have less >features than another that has more features but that crashes or >complains that my system is not correctly configured. > Hey, this is, why the most of us don't use Windoze, I think ;-))) >Back to the facts: currently, anyone installing the Gimp on a "normal" >UNIX system (i.e. from any major Linux distribution, or Solaris, and >so on, that has perl but not the optional modules from CPAN) gets a >version of the Gimp in which a large number of options do not work. I >consider that as a serious bug. > >If a user does not have the opportunity to download and install the >Perl modules from CPAN (no Internet connection, no administrative >rights, whatever) then the best workaround for the moment is "make >uninstall ; configure --disable-perl ; make ; make install". This is >not a good solution. Yes, this is really not a good solution!!! What about making an extra package with all perl-modules required to run Gimp with all powerfull features? Someone (not me, because I don't even understand what happens while perl installs some package:-(() can package all needed Perl packages, make a simple but nice configuration (only install those packages not present) and give any user (not only the perl wizards) the possibility to use the whole power of Gimp. Some addition to the ./configure could lead to a message "You don't seem to have some important perl packages installed. If you wish to use Gimp with all it's power, grab 'gimp-perl-packages.tar.gz' and install it. Then run configure again." And (don't take this seriously ;))) this can solve a lot of documenation updates! Yours Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
On Sat, 11 Mar 2000, Marc Lehmann <[EMAIL PROTECTED]> wrote: > 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!) Marc, it is unfortunate that you are replying in a defensive mode as if my message was a personal attack, because this is not the case. I tried to be as objective as possible and I took the time to check what I was talking about. Maybe I over-argumented my suggestions, but this is because a similar proposal that I sent several months ago was rejected because you said that all my claims were FUD. At that time, some of my assumptions were wrong and some other were right but my suggestions were ignored as a whole. Once bitten, twice shy. So I was more careful this time. I recently installed a new hard disk in my PC, so I decided to check everything on a "clean" system. I installed SuSE 6.3 (including perl, but not Gtk-Perl) and I downloaded, compiled and installed the latest versions of glib, gtk+ and the Gimp. First, I installed these packages with the versions 1.2.6, 1.2.6 and 1.1.17, respectively. Last week, I installed the versions 1.2.7, 1.2.7 and 1.1.18, respectively. So the current situation is: if you do not install the required Perl modules (especially Gtk.pm), most of the scripts do not produce any useful results. Besides, even if they would work, the pop-up messages warning the user about the missing module are not very friendly and lead the user into thinking that the Gimp is half-broken because the menus are cluttered with entries that generate warnings. > 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. I agree, but this is _not_ what happened. I suggested to skip the installation of most Perl scripts if their prerequisites were not satisfied. The fact is that most of them do not work without Gtk-Perl and even if some of them would work, running only with the default arguments is not very useful. Running with the default parameters means that the user has no way to change how the script works (of course), has no way to guess what the script could be doing by looking at its parameters and cannot use the help to get additional information (the latter is annoying for newcomers). > 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. This is only partially true. Most of the scripts depend on Gtk. Currently they do not require it (i.e. it is optional) because they are supposed to be able to run without it by using only the default values, but this does not really work: all of them generate warnings, most of them crash, and their usability is limited. If you prefer, you can re-phrase my suggestion in the following way: all scripts that can use Gtk should _require_ it and should not be installed if Gtk is not present during the "configure" step. The scripts that have no user interface and no dependencies on other modules can be installed if they are useful. I sincerely hope that you will not consider this message as a personal attack. I am not trying to blame you for anything (I repeat that the Perl scripts do work fine on a system that has all required modules). I am simply reporting the fact that if you install the current version of the Gimp on a clean system that has Perl without the optional modules, the user will get a bad impression because many entries in the menus will either not work at all or will not produce useful results. So I am suggesting a solution, which is to disable the installation of anything that would appear to the user as being broken. This does not necessarily mean to disable everything. > 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. OK, then you could just skip the installation of those scripts, and install those that have all their dependencies satisfied. > 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. That was my main argument. If Gtk is missing, the user will get many warnings (one pop-up every time they try to use a Perl script) which gives the impression that the Gimp is broken. After the warning, most of the scripts crash anyway. You could of course try to fix these crashes, because some of them look like real bugs in the scripts, but my message was not intended as a bug report... Even if the bugs are fixed, I think that it would be better to skip the installation of those scripts if they cannot have a user i
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
Hi, > 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? I didn't second to disable installation of _all_ scripts. I just aggreed that scripts that are not working due to unfulfilled dependencies should not be installed. IMHO the lack of Perl-GTK is such a reason. > 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. If this is the current situation, then I did not knew this. I must admit that in the last months I haven't tried to install gimp on systems that do not have all the necessary parts installed. If I did, I disabled Perl on configure. My experiences are probably not reflecting the current situation. Please excuse. Salut, Sven
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
Marc Lehmann wrote: > > 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. I would be pleased if there were a message after ./configure that said... Some errors occured during ./configure. If you would like to use the perl plugins you will need to upgrade the following packages from the CPAN archive package1 package2 package etc... Then provide the URL to the CPAN site so folks who don't know what is can find it. Might also be cool to list the command for configuring without the perl stuff that way the user has a choice. I'm the type who will go and find the modules and install them to get the full power of the GIMP. -- Jon Winters visit the Obscura Lounge in OpenVerse http://www.openverse.org/
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
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 overs
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
Hi, > 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. The delay at startup for probing the scripts would IMHO be very annoying. I don't see why people wouldn't prefer to reinstall the perl parts after they installed missing packages. That's how it works for all other plug-ins (jpeg, tiff, ...). Salut, Sven
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
Raphael Quinet wrote: > This has been suggested before, but I would like to bring it up > again... 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. Oh yes, please. I'm fairly sure that a working gimp-perl installation is wonderful, but I can vouch that a semi-disabled installation is definitely hair-rippingly more painful than a completely-disabled one. --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ "Due to recently uncovered copyright restrictions, Bucketheadland is no longer able to employ the man dressed in the Leatherface costume. If you see him in the park please contact Bucketheadland security immediately."
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
Hi, > This has been suggested before, but I would like to bring it up > again... 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. I second this suggestion. Salut, Sven
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
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 > 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. 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. -Raphael
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
On Wed, Mar 08, 2000 at 05:40:44PM +0100, Raphael Quinet wrote: > On Wed, 8 Mar 2000, Seth Burgess <[EMAIL PROTECTED]> wrote: > > 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. > > I'm glad to see that someone agrees... :-) 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. Regards, Tom -- --Tom Rathborne[EMAIL PROTECTED] -- http://www.aceldama.com/~tomr/ --"All that glitters is not gold; all that wander are not lost."
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
On Wed, Mar 08, 2000 at 01:07:52PM +0100, Raphael Quinet wrote: > This has been suggested before, but I would like to bring it up > again... 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. Parse::RecDescent is used only by the script-fu to perl-fu converter, AFIAK. I get Data::Dumper installed as part of perl-base. If there's a perl distro without that, it probably won't be terribly useful for developing perl based scripts (guessing). In any case, if Parse::RecDescent is affecting running of any plug-ins, I'd call that a bug. 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. > perlotine: the gtk perl module is required to open a dialog > window, running with default values (perl_fu_perlotine) > perlotine: No horizontal or vertical guides found. Aborted. at >/usr/lib/gimp/1.1/plug-ins/perlotine line 176. (ERROR) This error anyway is legit - you need guides to run perlotine! It would tell you so in a dialog box, but its not availble for lack of Gtk. In this case, I think the commandline is pretty clear. Were the color related PDB errors pre or post Gimp-Edit-Fill changes? Seth Burgess [EMAIL PROTECTED]
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
On Wed, 8 Mar 2000, Seth Burgess <[EMAIL PROTECTED]> wrote: > On Wed, Mar 08, 2000 at 01:07:52PM +0100, Raphael Quinet wrote: > > This has been suggested before, but I would like to bring it up > > again... 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. > > Parse::RecDescent is used only by the script-fu to perl-fu converter, > AFIAK. I get Data::Dumper installed as part of perl-base. If there's > a perl distro without that, it probably won't be terribly useful for > developing perl based scripts (guessing). In any case, if > Parse::RecDescent is affecting running of any plug-ins, I'd call that > a bug. If Parse::RecDescent is not needed for "normal users", i.e. those who do not have to use scm2perl or scm2scm, then maybe the Makefile.PL should not complain about it. The Gimp configure script does not complain if perl is missing, although it is required for developers who want to use the pdbgen. But this is a minor issue. As for Data::Dumper, it is indeed part of the default perl installation, but I think that some versions older than 5.005 had it as an option only. I do not know which versions exactly, but I know that I had to install the Gimp on some systems that had an old (and probably buggy) version of perl without Data::Dumper. > 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. I'm glad to see that someone agrees... :-) > > perlotine: the gtk perl module is required to open a dialog > > window, running with default values (perl_fu_perlotine) > > perlotine: No horizontal or vertical guides found. Aborted. at >/usr/lib/gimp/1.1/plug-ins/perlotine line 176. (ERROR) > > This error anyway is legit - you need guides to run perlotine! It would > tell you so in a dialog box, but its not availble for lack of Gtk. In > this case, I think the commandline is pretty clear. That's right. Sorry, that was a bad example. I should try that script again with some guides defined. > Were the color related PDB errors pre or post Gimp-Edit-Fill changes? > I captured most of these errors yesterday just after installing gimp-1.1.18 and before re-applying my gimp_edit_fill() patches. So these come from an unmodified 1.1.18 distribution. -Raphael
Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
This has been suggested before, but I would like to bring it up again... 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. The argument for installing the scripts anyway is that the user can install the missing modules later. However, I think that it currently does more harm than good. Note that I am not criticizing the Gimp-Perl plug-in itself, only the way the Perl-Fu scripts are installed. I have installed the Gimp on many systems (Linux and Solaris) and the Perl-Fu scripts are working fine on the systems that have perl and all the required modules. But on the systems that do not have perl (it comes with all Linux distros but it is optional) or those that do not have the required modules (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 makes a bad impression and the best solution is usually to uninstall everything, then re-configure with --disable-perl, re-compile and re-install. This extra hassle should not be necessary. Here are a few reasons why I think that the configure script should skip the installation of the Perl-Fu scripts if any of the required modules is missing: - All other plug-ins take the "safe" approach of not installing themselves if any dependency is not satisfied. As far as I know, the Perl plug-in is the only one that tries to install everything and hope that the user will install the missing things later. - I think that most users are updating the Gimp (re-compiling, re-installing) more frequently than they are updating Perl (even if 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. One reason for updating the Gimp more frequently is that it is easier to get a single tar file for the Gimp than to have to search for separate modules on CPAN, especially on a computer that has no direct connection to the Internet. Another example: on a multi-user system, the user may not have the required priviledges for installing the Perl modules in the system directories (although the modules could be installed in a private directory if the users take care of modifying their environment.) - 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 included below. Besides, these crashes are not very informative for the user if he is not the one who installed the software and who knows what these messages mean. - The modules that do not crash during start-up will fail anyway when they are used. Except for some things such as the Perl Server, I haven't found a script that was usable without Gtk-Perl. When I attempted to use these scripts, they all started by popping up a dialog box that warns about the missing module, then start some operations and crash before producing any result (which brings another dialog box for reporting the error). Again, for a user who is not the installer, it only makes the Gimp look bad because the menus are cluttered with unusable entries that do nothing else than popping up error boxes. See the second example below. 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. -Raphael -- Example 1 -- Here are the messages that are displayed every time the Gimp starts, taking 5-6 seconds on a Linux PC that has perl but does not have the required modules from CPAN: 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. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.005/i586-linux/Gimp/UI.pm line 5. BEGIN failed--compilation aborted at /usr/lib/gimp/1.1/plug-ins/avi line 10. ** WARNING **: wire_read: unexpected EOF (plug-in crashed?) 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. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.005/i586-linux/Gimp/UI.pm line 5. BEGIN failed--compilation aborted at /usr/lib/gimp/1.1/plug-ins/colorhtml line 9. ** WARNING **: wire