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

[Sergei Steshenko <sergstesh yahoo com>]

--- On Sat, 11/22/08, muppet <scott asofyet org> wrote:

> From: muppet <scott asofyet org>
> Subject: Re: calling main_quit from signal_connect - is it possible/legal ?
> To: "gtk-perl-list gnome org List" <gtk-perl-list gnome org>
> Date: Saturday, November 22, 2008, 9:28 AM
> On Nov 22, 2008, at 5:13 AM, Chas. Owens wrote:
>
> > On Mon, Nov 17, 2008 at 21:10, Sergei Steshenko
> <sergstesh yahoo com> wrote:
> > snip
> > > I am not going to call Gtk2->main_quit just for
> fun, I want to execute a
> > > really lengthy subroutine taking up to, say, 10
> seconds. I've noticed that
> > > shorter (a couple of seconds) subroutines work
> fine, but the long ones
> > > sometimes interfere with GUI behavior - it looks
> like some events are
> > > either lost or are recognized out of order.
> > snip
> >
> > The best way to deal with this is to continue to
> handle events during
> > you long subroutines.  You can handle all pending
> events by saying
> > Gtk2->main_iteration while Gtk2->pending_events;
> >
> > If your subroutine has loops, then it is a good idea
> to put the code
> > above at the top of the loops; otherwise, spread a few
> instances of
> > the code through your subroutine.
>
> If it's going to be really long, you might be better
> off using fork() and pipes to do the work in a subprocess
> and leave the ui responsive.  This also gives you the
> ability to add a "cancel" button to the ui, which
> would simply kill() the child process and clean up.

It's a big overhaul - currently all those subroutines taken up to 10
seconds are written in "C" and are called through "Inline C".

And too much data is passed to the subroutines - it doesn't take too much
times compared to execution times, but interface changes would be
painful.

The problem I have is not non-responsiveness of GUI, but rather wrong
responsiveness - too long to explain.

I have worked around the problem by simply temporarily replacing main
window with the one having no elements, thus no new events are generated
during this long period of non-responsiveness - that's good.

But there are some odd problems with this temporary window - label not
being displayed if it's a 'top_level' window, and label yes being displayed
if it's a 'popup' window, but no window decorations in this case ...

Maybe I'll be able to reproduced this problem with a small test case,
meanwhile I can live with no windows decoration window.

Thanks,
  Sergei.