GUI state has nothing to do with it. As far as I am concerned an application does not respond or repaint its contents on exposure events, then that's a bug that should be fixed. And that's what happen when you hand over the precious cpu cycles of the gtk main thread to your calculations. And after you have done it once, it is just as simple using another thread for your calculations. The event queue shouldn't be purged. It should be responded to as soon as possible by someone dedicated to the job.
Dov On Wed, Sep 15, 2010 at 18:19, Sergei Steshenko <sergst...@yahoo.com> wrote: > As I wrote in my original Email, the calculations are based on GUI state, > i.e. the GUI is the supplier of inputs to calculations. > > So,CLI suggestion is irrelevant in this case. > > The only solution with unfrozen GUI acceptable to me is: > > upon the calculations completion the whole event queue is purged and if > the GUI state is different from the one which triggered calculations, they > should be performed again _just_ _once_ - that's why I need to purge the > event queue. > > So, I chose a simpler solution - I don't let the GUI state change during > the calculations. > > Regards, > Sergei. > > > --- On Wed, 9/15/10, Dov Grobgeld <dov.grobg...@gmail.com> wrote: > > From: Dov Grobgeld <dov.grobg...@gmail.com> > Subject: Re: Spinning the main loop > To: "Sergei Steshenko" <sergst...@yahoo.com> > Cc: gtk-perl-list@gnome.org, "Emmanuele Bassi" <eba...@gmail.com> > Date: Wednesday, September 15, 2010, 7:13 AM > > Here are a couple of reasons why you don't want to freeze the GUI: > To abort the calculation > To report progressTo show partial results > To allow interaction with the previous results > To view help or change preferencesTo give a professional look and response > to the application. > If you don't need interaction, then you might as well run the calculations > in cli and just have the GUI as a viewer of your finished results. > > > Dov > > On Wed, Sep 15, 2010 at 14:02, Sergei Steshenko <sergst...@yahoo.com> > wrote: > > What for do I need to have a sensitive GUI if I want to discard produced > > by it events during my heavy calculations in the first place ? > > > > Thanks, > > Sergei. > > > > > > --- On Wed, 9/15/10, Dov Grobgeld <dov.grobg...@gmail.com> wrote: > > > > From: Dov Grobgeld <dov.grobg...@gmail.com> > > Subject: Re: Spinning the main loop > > To: "Sergei Steshenko" <sergst...@yahoo.com> > > Cc: gtk-perl-list@gnome.org, "Emmanuele Bassi" <eba...@gmail.com> > > Date: Wednesday, September 15, 2010, 4:50 AM > > > > 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
