Hi all!
I've been using the Perl plug-in logulator for logos for quite a while, and
I ran into several
(probably) little troubles, but I am clueless on whether other people are
having them, so I would like to call for someone to share their experiences
and tests of this powerful and nice tool. I am really incredibly curious to
know whether someone out there have got a perfectly running copy of the
logulator...
I am running a quite (IMHO) updated linux box, with latest gtk+ (1.2.6),
Perl Gtk (0.7000), and perl (5.000_03), gimp (cvs tree 17Jan00, with a nice
fix of the layers dialog bug , which made the latest 1.1.15 release hardly
reliable). I am running the same gimp version and libs and perl modules on
two linux boxes, one (A) with a self compiled perl under egcs-1.1.1, the
other with a SuSe Linux 6.2 shipped perl (B).
1) The Xtns/Render/Inbevel plug-in runs fine on A and B, but on B if I
invoke the layers dialogue after it has normally and gracefully exited, a
gimp sigsegv follows (argh). On A instead this message is issued:
Gdk-CRITICAL **: file gdkwindow.c: line 1390 (gdk_window_get_size):
assertion `window != NULL' failed.
The layers window is then opened, but the three layers resulting have an
incredibly long name, which corresponds to a full path to a file in the perl
directory, ending with #<number> [I'll paste this long path if someone will
answer me ;)].
2) The logulator shows problems when invoking the SOTA Chrome, the Glossy
and Neon scripts, the Particle trace script, The Web header logo script
(last one in the menu).
a) In the SOTA Chrome script, the chrome factor bar won't accept other
values than the default one (0.8).
b) The Glossy script is also tricky, because it will stop if the 'Accept
bumpmap defaults' is checked, with an error message to the STDERR, stating
that another process is waiting for input ("shouldn't happen" ends the
message). Furthermore the Flatten image option doesn't work, and the image
is 'always' flatted, even when the button isn't pressed (default).
c) The Neon script is the most mysterious, though... Basically, with a text
layer with a font which isn't so big as the default Blippo 150px, an error
'logulator: gimp_edit_fill procedural database execution failed at line 1902
(ERROR)' is issued. I've tried some humble hacking around in the logulator
itself, and discovered something: if I run the script over a big enough text
layer, it tends to work (but not consecutively, and not using different
fonts). I also was successful trying to resize the layer and shrink it by
some (10-20) pixels than the image... In latter case the
gimp_selection_shrink at line 1917 failed next. The oddest here is that
while in the trace a few lines above gimp_selection_shrink(0, 0.51) () seems
to work fine, when later (l. 1917) it is called by the script, the second
parameter isn't 0.51 any further, but '0'... How is this possible? When it
stops, the $inc_shrink value is all the time 0.51, but gimp_selection_shrink
is called with (0,0)...
d) In the Particle Trace script no errors are issued, but unfortunately the
final result hasn't much to do with the one obtained running the script-fu
original script... The green despeckled text gets covered by the shadow (is
this relating to the despeckle plug-in?)
e) In the last script, finally, Web Header Logo, an error is issued because
the gimp_color_picker isn't called with enough parameters. I added the
needed parameters according to PDB, and the script worked, but I never
understood whether the gray (?) background I obtained was really in the mind
of the person who initially wrote the script! ;)
I've already been in contact with Marc Lehman, the creator and mantainer of
the Perl Plug-in, who suggested me I could have hit here the script-fu bug.
Shall we conclude that the perl plug-in will never work without a new
version of script-fu? So my question is, whether some of the gimp developers
are interested in fixing this up, since the perl plug-in is really making of
gimp an even more powerful and astonishing tool than it ever was.
Mike
