Gimp Traffic #11 For 28 Jan 2000

Hi all,

while browsing and hacking many plugins I noticed that pressing "Cancel" in a plugin dialog causes the plugin's return value to be set to STATUS_EXECUTION_ERROR.

While this has no effect in normal plugins, it causes a "save failed" message box to appear for all save plugins. I find this really annoying, because pressing cancel is just a normal mode of operation, not an error.

Well, none of the current return values gives gimp a hint that "Cancel" was pressed. I suggest to add "STATUS_CANCEL" to the enum which could be treated specially.

Why shouldn't it be possible to cleanly cancel a save from the Save dialog? Cancelling it later while the save is in progress is another thing, but that's not what Michael was talking about.

IMHO the "Save failed" message is really annoying and adding a STATUS_CANCEL for this purpose might be worth the effort.

Yes, plugins should be frozen now.

I've removed them.

I haven't looked but I assume this is my kaleidoscope plugin. I haven't approved it being added to CVS, and if nobody removes it before I get around to it I'll do so myself. If nothing else, the UI needs a lot of work before it should go in a production version.

Somebody please kick Martin in the butt for me.

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.

Good ;) However, it seems that scripts converted from script-fu to perl have a large tendency to crash the gimp (yes, in ever unpredictable ways).

The layers dialog was (is?) pretty much broken at some days ;) This is probbaly being fixed soon.

In the meantime, your bug-report has vastly improved ;-> Only the case b) seems to be "the script-fu bug" itself.

Glossy will not work until script-fu is fixed (there are, I think one or two others who depend on script-fu as well). I don't believe in script-fu getting fixed before 1.2, though.

Well, telling "us" about it didn't help in the past, so why should it now? "us" should mean "the script-fu maintainer", and not me nor you.

I, for example, reported that bug and how to reproduce it in minute detail at least 3 times (maybe even more) during the last 15 months(!).

So yes, I do not believe that script-fu will work in 1.2. I also believe that script-fu needs a real maintainer who cares for it, not somebody like you who should better do other things.

Fact is, however, that script-fu is basically unmaintained. The bugs that I reported during the last year did not get fixed (with rare exceptions when you, mitch or me did it), and it is less then clear who is "responsible" for that plug-in.

Well, since nobody wanted to take the job and I do like Script-Fus I registered myself as Script-Fu maintainer a while ago. I have since then (and before) tried to fix all Script-Fu related bugs that I knew of. Have a look at the bug-tracking system. IIRC there's not a single open Script-Fu bug listed there. I do however see some Perl-related bugreports, but I'm starting to get off-topic...

Oops, then I must have thought it was related to the other bugs that got fixed. I can't remember a detailed bugreport however. You should know that to be sure that a bug gets attention and isn't forgotten there is only one proper way to report it: use the bug-tracker on bugs.gnome.org.

I really don't know what bug you are talking about actually, so please, would you take the time to file a proper bugreport?

I must admit that I have no idea how to edit bugreports or do anything else about them. I did *try*, but the pages are not very helpful in explaining how to use them.

I filed it, it got ignored. I reported it to the list, it got ignored. I did more to get that bug fixed than you could expect from anybody (because _I_ get asked about it twice a month)! I tried to contact people personally about that bug (and a couple of others) about that bug, and nobody reacted.

Each and every one working actively on the gimp should make herself familiar with the bug-tracker, should be subscribed to bugs@gimp.org and should look into the buglist frequently.

So, please read: http://bugs.gnome.org/Reporting.html
http://bugs.gnome.org/Developer.html
http://bugs.gnome.org/server-control.html
and look at: http://bugs.gnome.org/db/pa/lgimp.html

the most critical one is:

"start a script-fu plug-in noninteractively, and things start burning".

start burning means: either script-fu segfaults, gimp segfaults, both segfault, perl gets an error but gimp runs unstable etc...

There are probbaly two bugs here: the first one causes script-fu to return garbage, and the second one (in gimp) allows gimp to become unstable because script-fu returned garbage.

I would like to kindly suggest that we at least give a configure option to avoid the stacktrace stuff that happens when gimp crashes.

I'm currently developping a distributed perlfu server and it would make life much much easier if gimp would simply crash without hanging still around only due to a segfault handler.

I also remember having big problems with a segfaultet gimp started from the gnome panel (or any other non-shell commandline means) and gimp crashing while still having grabed the mouse.

I know that the stack trace thing is useful, I only want to have an option to avoid it WITHOUT the need to always fiddle the source code.

If I knew a bit more about configure (I know next to nothing) I would do it myself IF we could reach consensus that it woudl be a Good Thing(TM).

YES. Especially with the grabbed mouse. I am casting my vote for this 100%, little as it may be worth =)

Since the only advantage of this is the stack-trace for non-developers, why don't we just have it dump stack, then die, by default, unless you're running it under GDB or with a --do-annoying-stack-trace-crap option? I usually launch GIMP from a button, although nowadays I am actually running xterm -iconic -e gimp, so that when it dies I can just kill the xterm. (and hope that it wasn't grabbing the pointer...)

If I am not mistaken, the call to isatty() is already done inside glib. In glib (gerror.c), if the current terminal is not a tty, then the program will immediately exit instead of asking for a stack trace or whatever.

I know a bit of configure, so if nobody else is interested in implementing this simple change (a couple of lines, I think), then I will do that tomorrow.

How about --enable-stack-trace=[yes/no/query] and set it to query by default. We'll set the default to no for stable releases.

This should just set the default setting that gimp uses at runtime. There should be runtime options that parallel to override.

The consensus was to remove it in release versions. So if the only advantage is for non-developers, why not remove it altogether?

(It must be removed from the plug-in anyway, since it cribbles over the signal handlers prepared by the plug-in, rendering signal handling useless).

BTW: the stacktrace option has never worked on my machine(s), unless you call "endless loop" working. Also, I could never get out of that signal handler. Gimp just started to suck 100% cpu time when I tried to "e"xit.

I doubt that this thing is useful for anybody (I tried it even on a stock redhat 6.1 system). It is a constant annoyance.

A configure option is a bad choice, simply because you cannot change it without recompiling. That means that some packages' INSTALL file will read like this:

"if you want to use this package, you need to recompile your gimp".

This impairs usefulness of gimp quite a lot, since only a minority of users will recompile their gimp.

Here is how I see it:

• I like Yosh's suggestion to have a configure option that allows to choose between "yes/no/query" for the stack trace. The "yes" option triggers a direct call to g_on_error_stack_trace() when a SIGSEGV is received, the "no" option exits immediately, and the "query" option calls g_on_error_query() as it does now. The same choices would be available on the command-line regardless of the default value choosen while compiling. The main advantage of the configure option would be to set the default so that it is not necessary to use the command-line option every time, and this could help those who build binary packages.
• The default for the code in CVS would always be "query". This ensures that all developers (those who use the CVS code) can easily debug the code without having to re-start with different options if they forgot to enable the stack trace (some heisenbugs can be difficult to reproduce).
• The default for the "released" code (in tar files) for the "unstable" versions would be "--enable-stack-trace=yes", so that the users would get a stack trace that they could easily report (if they have gdb) without having any nasty problems with pointer grabs.
• The default for the "released" code for the "stable" versions (1.2.x) would be "--enable-stack-trace=no" because we expect that the GIMP would never crash (ha!) and we hope that any crash occuring while running the program could be reproduced by running it a second time with the command-line option that enables the stack trace.

Sorry, but _developers_ can always use gdb on the corefile. Having a signal handler just destroys the stack frame (and the backtrace) in many cases (here it almost always does).

The problem is that (shell-started) perl plug-ins always suffer from the backtrace, so a configure option wouldn't help.

Why is that signal handler installed at all, I ask? The signal destroys the stacktrace anyway. Why catch sigsegv at all? Why _exit_, and not dump core with all trace and ip information intact?

A commandline option would also have no effects on the plug-ins itself, which suffer from exactly the same problem.

I buy the argument that users can do bug reports better with an automatic stacktrace, but I don't buy that it makes it easier for developers.

Your proposal is a very good first step, and something lie that would be a workaround for the problems. However, I still think that the stacktrace code has done more harm than use, and I will never understand why mindlessly scribbling over 8 signals just because you are a gimp plug-in is ever going to help.

You are absolutely right there.... so I would suggest disabling it for normal use and enable it for distributions....

I know you like those small patchlets... so here is your personal one... :))