Re: Spinning the main loop

[Sergei Steshenko <sergstesh yahoo com>]

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