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

--- 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

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]