--- On Sun, 11/23/08, Kevin Ryde <[EMAIL PROTECTED]> wrote:
> From: Kevin Ryde <[EMAIL PROTECTED]>
> Subject: Re: calling main_quit from signal_connect - is it possible/legal ?
> To: [EMAIL PROTECTED]
> Cc: [email protected]
> Date: Sunday, November 23, 2008, 1:55 PM
> Sergei Steshenko <[EMAIL PROTECTED]> 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.
_______________________________________________
gtk-perl-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
