For an example of how to use an additional thread and have it communicate
with the mainloop thread see my example at:

http://www.mail-archive.com/gtk-app-devel-l...@gnome.org/msg14213.html

This is the correct way of doing anything time consuming without
interrupting the gui flow. There is no contradition to the setting of the
busy state to disable widgets or changing cursors. But the you don't
interrupt the GUI by delegating your work into a different threads.

Regards,
Dov


On Wed, Sep 15, 2010 at 13:30, Sergei Steshenko <sergst...@yahoo.com> wrote:

>
>
> --- On Wed, 9/15/10, Emmanuele Bassi <eba...@gmail.com> wrote:
>
> > From: Emmanuele Bassi <eba...@gmail.com>
> > Subject: Re: Displaying a popup before the main window
> > To: gtk-perl-list@gnome.org
> > Date: Wednesday, September 15, 2010, 4:17 AM
> > On Wed, 2010-09-15 at 11:45 +0100,
> [snip]
>
> > the rationale is: by spinning the main loop you're masking
> > issues in
> > your application. don't do that. I thought it was clear by
> > the amount of
> > scorn I used.
> >
> > ciao,
> >  Emmanuele.
>
>
> In my reality I have a set of calculations which might take up to a minute,
> and tens of seconds typically. The calculations take as input the GUI
> state and are triggered by it.
>
> So, I intentionally spin the main loop. This is because there is an event
> queue, and if I let the GUI to be responsive, it may accumulate the events
> while the heavy calculations are in progress. When that happens, after the
> completions of one round of the heavy calculations another one immediately
> starts, so, it may take up to several minutes for the whole thing to
> settle down. I think once it took half an hour or so.
>
> Actually, not only I spin the main loop, I also hide the sensitive GUI
> elements which may cause new events, i.e. there is, for example, no
> physical possibility to change state of normally existing slider (called
> "Adjustment") because the sliders are temporarily hidden.
>
> One may find it ugly, but to mess up with the event queue might be even
> uglier (for example, purging it until the last state change).
>
> Regards,
>  Sergei.
>
>
>
> _______________________________________________
> gtk-perl-list mailing list
> gtk-perl-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-perl-list
>
_______________________________________________
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Reply via email to