Re: calling main_quit from signal_connect - is it possible/legal ?

[Sergei Steshenko <sergstesh yahoo com>]

--- On Tue, 12/2/08, muppet <scott asofyet org> wrote:

> From: muppet <scott asofyet org>
> Subject: Re: calling main_quit from signal_connect - is it possible/legal ?
> To: "Sergei Steshenko" <sergstesh yahoo com>
> Cc: "gtk-perl-list gnome org List" <gtk-perl-list gnome org>
> Date: Tuesday, December 2, 2008, 6:22 PM
> On Nov 23, 2008, at 5:27 PM, Sergei Steshenko wrote:
> > Other than lack of decorations the 'popup'
> window seems to solve the
> > problem - I hide  the main window and show the
> 'popup' one, so there are no
> > events to be registered by widgets since there are no
> widgets.
>
> Unresponsive UIs, with no progress indication and no Cancel
> button, are a horrible, horrible thing.  Your users will
> despise you.
>
> You can still fork your app to have the main work run in
> another process, and communicate progress info to the other
> process, so allow pulsing a progress bar and watching for
> the user to hit a "Cancel" button.  The subprocess
> is preferable to a thread here because the cancel action can
> be simply "kill $child".

It's much more complex, and the child processed should _never_ be killed.
It calculates something which is all or nothing, i.e. part of work does not
make any sense.

Some kind of progress bar can be made, i.e. there are clearly distinct
stages in the child process - currently progress is indicated by messages
printed to console - it's an "internal" application in the meantimes.

Thanks,
  Sergei.