I tried to use the Perl-Fu scripts in 1.1.21 and I saw that all of
them abort with the following error displayed on the console:

  ** ERROR (recursed) **: could not find handler for message: 65536

And this message is displayed in a pop-up box:

  [/path/to/script]: the gimp is using a newer version of the plug-in
  protocol than this plug-in.

Marc, I suppose that you are aware of this and that you can fix it?
I suppose that this was a consequence of the recent changes in the
wire protocol.  Hi Mitch!  ;-)

But I also noticed that something else has changed in the Perl-Fu
scripts: in the previous versions that I tried (under Solaris), these
scripts were always registered at the bottom of the menus, instead of
being mixed with the C plug-ins.  Now it seems to be the contrary: the
Perl-Fu scripts are listed first in each menu, followed by the usual C
plug-ins.  This is very distracting.

Would it be possible to avoid this?  I would prefer to have the
Perl-Fu scripts separated from the C plug-ins.  Either by adding a
separator in the menus, by adding a little mark next to their names,
or by creating a separate Perl-Fu menu similar to the Script-Fu menu.

I am asking for this on the list because I expect that many developers
have different opinions about the placement of Perl-Fu scripts (or
Python-Fu).  I think that the Perl-Fu scripts "feel" different from
the C plug-ins and it would be nice to know beforehand if an entry in
a menu is mapped to a C or Perl plug-in.  They behave slightly
differently (e.g. undo is not always supported, there is a delay of a
couple of seconds before the plug-in starts) and their parameters
dialog have a different layout compared to most C plug-ins.  I suppose
that some of these differences (e.g. the Gimp-Perl logo in the
dialogs) were introduced on purpose to make these scripts stand out
from the others, but then why should they be mixed?  I'm not asking
for a vote or anything like that, but I would like to hear some
opinions... (no flames please)


Reply via email to