Re: Spinning the main loop



No, it doesn't happen that way. The application is single-threaded from
my point of view, and upon calculations completion I flush events by
iterating in the main loop.

As I said, the application should _not_ respond - because all the events
during the calculation should be discarded anyway.

Try to model my situation - create an application with one slider and
make its value_changed callback calling 'sleep(30)' with a diagnostic
message.

Then move the slider during those 30 seconds, say, 10 times and watch
how much time it will take from your application to settle down.


Regards,
  Sergei.


--- On Wed, 9/15/10, Dov Grobgeld <dov grobgeld gmail com> wrote:

From: Dov Grobgeld <dov grobgeld gmail com>
Subject: Re: Spinning the main loop
To: "Sergei Steshenko" <sergstesh yahoo com>
Cc: gtk-perl-list gnome org, "Emmanuele Bassi" <ebassi gmail com>
Date: Wednesday, September 15, 2010, 9:36 AM

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 <sergstesh 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 grobgeld gmail com> wrote:



From: Dov Grobgeld <dov grobgeld gmail com>

Subject: Re: Spinning the main loop

To: "Sergei Steshenko" <sergstesh yahoo com>

Cc: gtk-perl-list gnome org, "Emmanuele Bassi" <ebassi 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 <sergstesh 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 grobgeld gmail com> wrote:







From: Dov Grobgeld <dov grobgeld gmail com>



Subject: Re: Spinning the main loop



To: "Sergei Steshenko" <sergstesh yahoo com>



Cc: gtk-perl-list gnome org, "Emmanuele Bassi" <ebassi 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-list 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 <sergstesh yahoo com> wrote:























--- On Wed, 9/15/10, Emmanuele Bassi <ebassi gmail com> wrote:















From: Emmanuele Bassi <ebassi 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




















































[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]