On Sat, 11 Mar 2000, Marc Lehmann <marc@xxxxxxxx> 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 interface (besides the warning box). Without any user interface,
it is hard for a newcomer to know what the script is supposed to do
and what its parameters are. So even if this means reducing the
number of cool features available to the user, I prefer to skip the
installation of anything that appears to be obsure or confusing.
Especially because the user interface becomes a bit unpredictable: the
novice user does not know in advance which entry in the menu will
generate a warning and which one will work fine, because the Perl
scripts install themselves in many locations.
> 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! Maybe gimp-perl has been
discussed so often because of the way you reply to some messages and
because several people on this list tend to loose their temper a bit
to easily. If this is a hot topic, this indicates that there are some
problems. Whether these problems are technical, philosophical or
purely imaginary does not matter: the discussions indicate that some
people disagree and we should all (not only you) try to solve these
problems in the best possible way.
To start with, it would be nice if you would not say something like the
following...
> 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:
... 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. If not, I hope that this
message will help.
> 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?
Please, read my message again. This is _not_ what I suggested and I
think that Sven and the others understood my message correctly.
Although an easy solution to the problems with Perl-Fu scripts could
be to disable all of them, this solution is a bit extreme and that's
why I wrote that "most" of them should be disabled. By "most", I mean
all those that depend on a module that is not present. And as I wrote
above, a module that uses Gtk (even if it is optional) should be
considered as requiring it.
This is where we disagree. You seem to consider that providing these
scripts that can only run with the default values is a service to the
user (and as a bonus, it would encourage them to install the missing
Perl modules). I disagree because I think that they will confuse the
user and give them a bad opinion of the Gimp ("half-broken").
Especially when the user is not the one who installed the software.
For example, I do not have the AAlib on my PC. All I got is _one_
warning during the "configure" step and then I never had to bother
with this again. Same with the MPEG library. I am probably missing
some great features, but at least I have something that works well and
that does not remind me at run-time that I should install some missing
libraries.
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.
[... big snip ...]
> In any case, I would suggest to ignore Raphael's suggestion and
> concentrate on fixing existing bugs.
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. I was suggesting something else that would be
nicer for the user. Please do not dismiss this solution by claiming
(more or less) that I do not know what I am talking about. Ignoring
the problem and criticizing those who report it is not a good way to
solve it.
After we solve the installation problem, we could also solve the other
bugs that I detected (the fact that most scripts cannot run, even with
the default values). As I said, my previous message was not intended
to be a bug report and I am sorry if you assumed that it was my
intent. I simply included the error messages as a way to illustrate
the problems and I thought that these problems had been known for a
long time and that everybody could reproduce them easily. But I am
willing to help you fix these bugs. Do you want me to post (to you or
to the list) a list of all error reports from the scripts when I start
them with the default values? I did not post that because the full
list would be a bit long and I doubt that I can provide any info that
you could not get easily by yourself. But if I can help in any way,
please tell me.
-Raphael
