Displaying a popup before the main window

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Displaying a popup before the main window

Nicolas Courtel
Hello,

As my program needs a few seconds to start, I would like to display a
popup to tell the user that it's working.
Looks pretty simple, but for some reason the popup shows up empty, and I
can't figure out what I've done wrong.

I would be grateful for any clue, here's a short example which shows the
problem.

#!/usr/bin/perl -w

use strict;
use Gtk2 -init;

my $window = Gtk2::Window->new;
$window->set_title ("My window");

my $popup = Gtk2::MessageDialog->new ($window, 'destroy-with-parent',
'info',
                                      'none', "Please wait for 10
seconds...");
$popup->show;
sleep 10;

my $label = Gtk2::Label->new ("Hello, world!");
$window->add ($label);

$popup->destroy;
$window->show_all;
Gtk2->main;

--
Nicolas
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Displaying a popup before the main window

Emmanuele Bassi
On Tue, 2010-09-14 at 19:58 +0200, Nicolas Courtel wrote:
> Hello,
>
> As my program needs a few seconds to start, I would like to display a
> popup to tell the user that it's working.
> Looks pretty simple, but for some reason the popup shows up empty, and I
> can't figure out what I've done wrong.

to borrow the phrase from those damn kids today: you're doing it wrong.

> sleep 10;

do not *ever* call a blocking function when using a mainloop-based
toolkit like gtk+.

*any* blocking call will prevent the main loop to spin, which will
prevent redraw operations and event handling from ever happening.

ciao,
 Emmanuele.

--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Displaying a popup before the main window

Grant McLean
On Tue, 2010-09-14 at 21:59 +0100, Emmanuele Bassi wrote:

> On Tue, 2010-09-14 at 19:58 +0200, Nicolas Courtel wrote:
> > Hello,
> >
> > As my program needs a few seconds to start, I would like to display a
> > popup to tell the user that it's working.
> > Looks pretty simple, but for some reason the popup shows up empty, and I
> > can't figure out what I've done wrong.
>
> to borrow the phrase from those damn kids today: you're doing it wrong.
>
> > sleep 10;
>
> do not *ever* call a blocking function when using a mainloop-based
> toolkit like gtk+.

More info in the FAQ ...

http://live.gnome.org/GTK2-Perl/FrequentlyAskedQuestions#Why_sometimes_the_UI_does_not_update.3F

Cheers
Grant

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Displaying a popup before the main window

Kevin Ryde
In reply to this post by Nicolas Courtel
Nicolas Courtel <[hidden email]> writes:
>
> the popup shows up empty, and
> I can't figure out what I've done wrong.

It's only drawn when a map/expose/etc comes back from the server, by
which time you're off doing other things.

A window with a background pixmap can show without any action from the
app program.  Eg. per below, except that recent gtk has broken
set_cursor() on new windows like this, so you don't get the busy cursor.
It ought to send an XSetCursor, but for some reason waits to interact
with the server :-(.

Making the image is a bit tedious.  Is there a library to do a whole
temporary popup already?  You'd probably want a sub-window to avoid a
window resize tiling with the image.  Or turn that off in the wm hints,
or use 'popup' window type, or all three :).




#!/usr/bin/perl -w

use strict;
use Gtk2 -init;

my $pixbuf = Gtk2::Gdk::Pixbuf->new_from_file
  ('/usr/share/doc/libgtk2-perl-doc/examples/gtk-demo/apple-red.png');
my $width = $pixbuf->get_width;
my $height = $pixbuf->get_height;

my $popup = Gtk2::Window->new ('toplevel');
$popup->set_default_size ($width, $height);
$popup->realize;
my $win = $popup->window;
my $gc = $popup->style->bg_gc('normal');
my $pixmap = Gtk2::Gdk::Pixmap->new ($win, $width, $height, -1);
$pixmap->draw_rectangle ($gc, 1, 0,0, $width,$height); # clear
$pixmap->draw_pixbuf ($gc, $pixbuf, 0,0, 0,0, $width,$height, 'none', 0,0);
$win->set_back_pixmap ($pixmap);
$win->set_cursor (Gtk2::Gdk::Cursor->new('watch'));

$popup->show;
$popup->get_display->flush;
sleep 30;


my $window = Gtk2::Window->new;
$window->set_title ("My window");

my $label = Gtk2::Label->new ("Hello, world!");
$window->add ($label);

$popup->destroy;
$window->show_all;
Gtk2->main;
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Displaying a popup before the main window

Dave Howorth
In reply to this post by Nicolas Courtel
Nicolas Courtel wrote:
> Hello,
>
> As my program needs a few seconds to start, I would like to display a
> popup to tell the user that it's working.
> Looks pretty simple, but for some reason the popup shows up empty, and I
> can't figure out what I've done wrong.
>
> I would be grateful for any clue, here's a short example which shows the
> problem.

There are various possible ways. The main problem with your version is
that you didn't process the events that occur when you try to show the
splash screen. The version below is one way to do it:

> #!/usr/bin/perl -w
>
> use strict;
> use Gtk2 -init;
>
> my $window = Gtk2::Window->new;
> $window->set_title ("My window");

# my $popup = Gtk2::MessageDialog->new ($window, 'destroy-with-parent',
# 'info',
#                                      'none', "Please wait for 10
# seconds...");

my $splash = Gtk2::Label->new("Please wait for 10 seconds...");
$window->add($splash);
$window->show;
> $popup->show;

# Process the events so the show actually does something

Gtk2->main_iteration while Gtk2->events_pending;

# The sleep is only here because this is an example, right?
# You wouldn't do this in real-life

> sleep 10;

# The splash needs to be destroyed before you add the real content.
# Build real content in a main container widget then destroy the
# splash, then add the container to the window

> my $label = Gtk2::Label->new ("Hello, world!");

$splash->destroy;

> $window->add ($label);

# $popup->destroy;

> $window->show_all;
> Gtk2->main;
>

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Displaying a popup before the main window

Dave Howorth
Ooops didn't copy the mods into the email properly. Add one more line...

Dave Howorth wrote:
> my $splash = Gtk2::Label->new("Please wait for 10 seconds...");
> $window->add($splash);
> $window->show;
>> $popup->show;

$splash->show;

> # Process the events so the show actually does something
>
> Gtk2->main_iteration while Gtk2->events_pending;

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Displaying a popup before the main window

Emmanuele Bassi
In reply to this post by Dave Howorth
On Wed, 2010-09-15 at 10:30 +0100, Dave Howorth wrote:

> # Process the events so the show actually does something
>
> Gtk2->main_iteration while Gtk2->events_pending;

no, no, no. no, please, for the love of all that's sacred and good and
pure in the Universe: don't.

manually, and forcefully, spinning the main loop is the equivalent of
taking some ibuprofen to stop the headache that you get when you bang
your head against the wall to bang a nail in with your forehead. the
ibuprofen is masking the fact that *you're banging your head against the
wall to bang a nail in*.

in this case, spinning the main loop is just masking the fact that
you're blocking the main loop. the correct way to deal with this is *to
stop blocking the main loop*.

split your operations in small chunks.

use worker threads and signal the main UI thread when done.

spin off worker processes and use a pipe to feed data to them and read
back the results.

split your application in a D-Bus activated daemon and use D-Bus as the
IPC mechanism for remote object manipulation.

this particular problem space has been flogged to death, and then some,
like the proverbial horse. spinning the main loop is *not* the solution,
it's just a hack. ${DEITY}, I'd love to deprecate those functions in gtk
itself, so that people stopped abusing them and just *fixed their
programs*.

ciao,
 Emmanuele.

--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Displaying a popup before the main window

Dave Howorth
Emmanuele Bassi wrote:
> in this case, spinning the main loop is just masking the fact that
> you're blocking the main loop. the correct way to deal with this is *to
> stop blocking the main loop*.

We are discussing a splash screen that is shown during initialization
while the GUI is being constructed and before the main loop is reached.

You're proposing a complicated alternative mechanism and to what end,
I'm not sure. Perhaps if you gave a reference to a good explanation of
your rationale, instead of simply pouring scorn on people, it would be
more helpful.

Cheers, Dave
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Displaying a popup before the main window

Emmanuele Bassi
On Wed, 2010-09-15 at 11:45 +0100, Dave Howorth wrote:
> Emmanuele Bassi wrote:
> > in this case, spinning the main loop is just masking the fact that
> > you're blocking the main loop. the correct way to deal with this is *to
> > stop blocking the main loop*.
>
> We are discussing a splash screen that is shown during initialization
> while the GUI is being constructed and before the main loop is reached.

the premise is, in this case, irrelevant: you're blocking the main loop,
spinning it is pointless and dangerous.

actually, by showing a splash screen you're *delaying* the start up of
your application: don't use splash screens. it's no 1997 any more.

if your application starts slowly, bring up the UI as soon as possible
and fill it up with real data lazily; using a splash screen is just
papering over the issue that you're blocking the user because. wait,
that's *exactly* like manually spinning the main loop! who would have
thought.

> You're proposing a complicated alternative mechanism and to what end,
> I'm not sure.

my end is to ensure people write *correct* application code, and use the
toolkit in the *correct* way.

>  Perhaps if you gave a reference to a good explanation of
> your rationale, instead of simply pouring scorn on people, it would be
> more helpful.

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.

--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Spinning the main loop

Sergei Steshenko-2


--- On Wed, 9/15/10, Emmanuele Bassi <[hidden email]> wrote:

> From: Emmanuele Bassi <[hidden email]>
> Subject: Re: Displaying a popup before the main window
> To: [hidden email]
> 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Spinning the main loop

Dov Grobgeld-2
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@.../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 <[hidden email]> wrote:


--- On Wed, 9/15/10, Emmanuele Bassi <[hidden email]> wrote:

> From: Emmanuele Bassi <[hidden email]>
> Subject: Re: Displaying a popup before the main window
> To: [hidden email]
> 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list


_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Spinning the main loop

Sergei Steshenko-2
In reply to this post by Sergei Steshenko-2
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 <[hidden email]> wrote:

From: Dov Grobgeld <[hidden email]>
Subject: Re: Spinning the main loop
To: "Sergei Steshenko" <[hidden email]>
Cc: [hidden email], "Emmanuele Bassi" <[hidden email]>
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@.../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 <[hidden email]> wrote:





--- On Wed, 9/15/10, Emmanuele Bassi <[hidden email]> wrote:



> From: Emmanuele Bassi <[hidden email]>

> Subject: Re: Displaying a popup before the main window

> To: [hidden email]

> 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

[hidden email]

http://mail.gnome.org/mailman/listinfo/gtk-perl-list






     
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Displaying a popup before the main window

Nicolas Courtel
In reply to this post by Dave Howorth
Dave Howorth a écrit :
Nicolas Courtel wrote:
  
Hello,

As my program needs a few seconds to start, I would like to display a
popup to tell the user that it's working.
Looks pretty simple, but for some reason the popup shows up empty, and I
can't figure out what I've done wrong.

I would be grateful for any clue, here's a short example which shows the
problem.
    

There are various possible ways. The main problem with your version is
that you didn't process the events that occur when you try to show the
splash screen. The version below is one way to do it:
  
[...]
# Process the events so the show actually does something

Gtk2->main_iteration while Gtk2->events_pending;

[...]
Thanks for your help, this works fine.

I might not be safe gtk programming, but initializing my application after have started the gui, as Emmanuele suggested, doesn't look so easy, as I would need to do so without blocking the main loop.

--
Nicolas

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Displaying a popup before the main window

Dave Howorth
In reply to this post by Emmanuele Bassi
Emmanuele Bassi wrote:

> On Wed, 2010-09-15 at 11:45 +0100, Dave Howorth wrote:
>> Emmanuele Bassi wrote:
>>> in this case, spinning the main loop is just masking the fact that
>>> you're blocking the main loop. the correct way to deal with this is *to
>>> stop blocking the main loop*.
>> We are discussing a splash screen that is shown during initialization
>> while the GUI is being constructed and before the main loop is reached.
>
> the premise is, in this case, irrelevant: you're blocking the main loop,
> spinning it is pointless and dangerous.

You haven't given a single example or description of what is dangerous.

> actually, by showing a splash screen you're *delaying* the start up of
> your application: don't use splash screens. it's no 1997 any more.
>
> if your application starts slowly, bring up the UI as soon as possible
> and fill it up with real data lazily;

What do you expect a user to want to do with a UI that's incapable of
doing anything because it has no data?

> using a splash screen is just
> papering over the issue that you're blocking the user because. wait,
> that's *exactly* like manually spinning the main loop! who would have
> thought.

Sorry, I have no idea what that means.

>> You're proposing a complicated alternative mechanism and to what end,
>> I'm not sure.
>
> my end is to ensure people write *correct* application code, and use the
> toolkit in the *correct* way.

So again, please provide a reference to a description of "the *correct*
way".

>>  Perhaps if you gave a reference to a good explanation of
>> your rationale, instead of simply pouring scorn on people, it would be
>> more helpful.
>
> 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.

Again, you have not given any characterisation or example of what such
an issue might be. You're just blustering.

Cheers, Dave
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Spinning the main loop

Dov Grobgeld-2
In reply to this post by Sergei Steshenko-2
Here are a couple of reasons why you don't want to freeze the GUI:
  • To abort the calculation
  • To report progress
  • To show partial results
  • To allow interaction with the previous results
  • To view help or change preferences
  • To 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 <[hidden email]> 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 <[hidden email]> wrote:

From: Dov Grobgeld <[hidden email]>
Subject: Re: Spinning the main loop
To: "Sergei Steshenko" <[hidden email]>
Cc: [hidden email], "Emmanuele Bassi" <[hidden email]>
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@.../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 <[hidden email]> wrote:





--- On Wed, 9/15/10, Emmanuele Bassi <[hidden email]> wrote:



> From: Emmanuele Bassi <[hidden email]>

> Subject: Re: Displaying a popup before the main window

> To: [hidden email]

> 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

[hidden email]

http://mail.gnome.org/mailman/listinfo/gtk-perl-list









_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Spinning the main loop

Sergei Steshenko-2
In reply to this post by Sergei Steshenko-2
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 <[hidden email]> wrote:

From: Dov Grobgeld <[hidden email]>
Subject: Re: Spinning the main loop
To: "Sergei Steshenko" <[hidden email]>
Cc: [hidden email], "Emmanuele Bassi" <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> wrote:



From: Dov Grobgeld <[hidden email]>

Subject: Re: Spinning the main loop

To: "Sergei Steshenko" <[hidden email]>

Cc: [hidden email], "Emmanuele Bassi" <[hidden email]>

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@.../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 <[hidden email]> wrote:











--- On Wed, 9/15/10, Emmanuele Bassi <[hidden email]> wrote:







> From: Emmanuele Bassi <[hidden email]>



> Subject: Re: Displaying a popup before the main window



> To: [hidden email]



> 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



[hidden email]



http://mail.gnome.org/mailman/listinfo/gtk-perl-list




















     
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Spinning the main loop

Dov Grobgeld-2
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 <[hidden email]> 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 <[hidden email]> wrote:

From: Dov Grobgeld <[hidden email]>
Subject: Re: Spinning the main loop
To: "Sergei Steshenko" <[hidden email]>
Cc: [hidden email], "Emmanuele Bassi" <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> wrote:



From: Dov Grobgeld <[hidden email]>

Subject: Re: Spinning the main loop

To: "Sergei Steshenko" <[hidden email]>

Cc: [hidden email], "Emmanuele Bassi" <[hidden email]>

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@.../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 <[hidden email]> wrote:











--- On Wed, 9/15/10, Emmanuele Bassi <[hidden email]> wrote:







> From: Emmanuele Bassi <[hidden email]>



> Subject: Re: Displaying a popup before the main window



> To: [hidden email]



> 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



[hidden email]



http://mail.gnome.org/mailman/listinfo/gtk-perl-list























_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Spinning the main loop

Sergei Steshenko-2
In reply to this post by Sergei Steshenko-2
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 <[hidden email]> wrote:

From: Dov Grobgeld <[hidden email]>
Subject: Re: Spinning the main loop
To: "Sergei Steshenko" <[hidden email]>
Cc: [hidden email], "Emmanuele Bassi" <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> wrote:



From: Dov Grobgeld <[hidden email]>

Subject: Re: Spinning the main loop

To: "Sergei Steshenko" <[hidden email]>

Cc: [hidden email], "Emmanuele Bassi" <[hidden email]>

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 <[hidden email]> 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 <[hidden email]> wrote:







From: Dov Grobgeld <[hidden email]>



Subject: Re: Spinning the main loop



To: "Sergei Steshenko" <[hidden email]>



Cc: [hidden email], "Emmanuele Bassi" <[hidden email]>



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@.../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 <[hidden email]> wrote:























--- On Wed, 9/15/10, Emmanuele Bassi <[hidden email]> wrote:















> From: Emmanuele Bassi <[hidden email]>







> Subject: Re: Displaying a popup before the main window







> To: [hidden email]







> 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







[hidden email]







http://mail.gnome.org/mailman/listinfo/gtk-perl-list
















































     
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Spinning the main loop

Sergei Steshenko-2
In reply to this post by Sergei Steshenko-2
Before writing my app I read all those GUI dogmas. And they are wrong
for me.

There are two scenarios with my app:

1) just one slider is moved and the calculations should be performed;
2) a number of sliders should be moved first an only then the calculations
should be performed.

Because of the two scenarios I have a toggle button which controls whether
the calculations start immediately upon slider movement.

In any case, during the calculations the GUI is disabled.

Regards,
  Sergei.


--- On Wed, 9/15/10, Dov Grobgeld <[hidden email]> wrote:

From: Dov Grobgeld <[hidden email]>
Subject: Re: Spinning the main loop
To: "Sergei Steshenko" <[hidden email]>
Cc: [hidden email], "Emmanuele Bassi" <[hidden email]>
Date: Wednesday, September 15, 2010, 9:36 AM
[snip]

The event queue shouldn't be purged. It should be responded to as soon as possible by someone dedicated to the job.

[snip]




     
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Spinning the main loop

Kenneth Swanson
On 09/15/2010 12:08 PM, Sergei Steshenko wrote:
> In any case, during the calculations the GUI is disabled.

I think the point is that there is a difference between "the GUI is disabled" and "the GUI is frozen and cannot even process its own events".

One of those should be avoided.

-Ken
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
12