On Thu, May 11, 2000 at 08:54:44PM +0200, Michael Natterer <mitschel@xxxxxxxxxxxxxxx> wrote:
> > Yes... I wrote a few months ago that I would change that and implement
> > some kind of --enable-stack-trace option, but I never took the time to
> > do it.
>
> Now it's there :) We just have to convert the remaining g_print() to write()
> and the handler will be totally safe if enable_stack_trace == FALSE.
Raphael, Mitch. Just to be clear: what _I_ need is a way to not have the
plug-in signals changed behind my back. Installing signal handlers for
unsuspecting signals, therefore, is my _problem_. Even moving signal
initialization to somewhere before gimp_main would improve my situation.
Making it optional in a plug-in would be best.
I also argued (not independently enough, however, as the topics are
similar) that the stack-tracing stuff (and I meant cathing each and every
fatal signal) makes a lot of problems for the main _gimp_ app, as it's
often not working (no way to get out of the prompt, no sensible stack
trace anyway). It does not limit my "programming creativeness" (if there
is any), like the first problem. I am just afraid that getting a SIGSEGV
is better than looping around in the background.
Catching signals and not offering a menu (as mitch seemed to imply) does not
change the situation a bit.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
