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

[Sergei Steshenko <sergstesh yahoo com>]

--- On Sun, 11/23/08, Kevin Ryde <user42 zip com au> wrote:

> From: Kevin Ryde <user42 zip com au>
> Subject: Re: calling main_quit from signal_connect - is it possible/legal ?
> To: sergstesh yahoo com
> Cc: gtk-perl-list gnome org
> Date: Sunday, November 23, 2008, 1:55 PM
> Sergei Steshenko <sergstesh yahoo com> writes:
> > But there are some odd problems with this temporary
> window - label not
> > being displayed if it's a 'top_level'
> window,
>
> You might have to "flush" the display to send
> initial drawing out.
>
> > if it's a 'popup' window, but no window
> decorations in this case ...
>
> No decoration might be normal for popup class.
>
>
> As a bit of shameless self-promotion, my
> Gtk2::Ex::WidgetCursor can
> conveniently set the busy "watch" pointer to show
> app windows will be
> unresponsive, turning it off automatically when the main
> loop resumes.

Again, my problem is _not_ that the widgets do not respond, but, rather,
the opposite - even though the widgets do _not_respond, they register 
events, like mouse in, out, and these events - which normally I _do_ need,
but during update/unresponsiveness I do _not_ need, screw things up for me.

The GUI gets screwed up after the period of non-responsiveness.

Regarding the 'popup' window - it remains without decorations even when I
force it to be decorated through set_decorated(TRUE) method.

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.

Thanks,
  Sergei.