Re: frozen GUI!!! urgent help required!

[RevX]

Hello all,

while(g_main_iteration(FALSE)) did help!!! That's great.
Anyway, I think I'll go the multithreaded approach
(more elegant and 'clean'). Just takes more time...

Thanks to you all for the fast replies and given help!!!
Many cheers,
Michael.

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: frozen GUI!!! urgent help required!

[Joe Pfeiffer]

[EMAIL PROTECTED] writes:
 > Oh hell!!!
 > 
 > Now I'm scared! Why did nobody tell me before? Is that common
 > with all GUI toolkits?

Pretty much (it's true of all X toolits that I know of).  And every
new GUI programmer gets bitten by it.

 > > Not unless you create a separate thread for the calculations. When the
 > > calculations finish, you should be able to interact with the GUI again.
 > 
 > The problem is: I'm no (good) thread programmer and for what I've read
 > in here it seems that Gtk+ wasn't design to be used with threads and
 > there will be much trouble ahead. Am I right?
 > And the other thing is: it was planned that the calculations stop with
 > the click of a button (it's a continuos online calculation/data processing)
 > but thus the button is not clickable under heavy system load there
 > has to be another way around. 
 >
 > Isn't there a way to shortly stop calculations (for a necessary minimum
 > of time) and let the GUI gather possible events? Could this work
 > this way somehow? Any suggestions?

Yes.   See FAQ 5.14

5.14. Why doesn't my widget (e.g. progressbar) update?
Why doesn't my widget (e.g. progressbar) update?

You are probably doing all the changes within a function without
returning control to gtk_main(). This may be the case if you do some
lengthy calculation in your code. Most drawing updates are only placed
on a queue, which is processed within gtk_main(). You can force the
drawing queue to be processed using something like:

while (g_main_iteration(FALSE));

inside you're function that changes the widget.

What the above snippet does is run all pending events and high
priority idle functions, then return immediately (the drawing is done
in a high priority idle function).

-- 
Joseph J. Pfeiffer, Jr., Ph.D.   Phone -- (505) 646-1605
Department of Computer Science   FAX   -- (505) 646-1002
New Mexico State University  http://www.cs.nmsu.edu/~pfeiffer
Southwestern NM Regional Science and Engr Fair:  http://www.nmsu.edu/~scifair
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: frozen GUI!!! urgent help required!

[rsteinke]

From: Paul Davis <[EMAIL PROTECTED]>
>
> yes, it is common to more or less all GUI toolkits, regardless of OS
> platform. 
>
> >Isn't there a way to shortly stop calculations (for a necessary minimum
> >of time) and let the GUI gather possible events? Could this work
> >this way somehow? Any suggestions?
>
> somewhere inside your calculations, call this reasonably often:
>
> while (gtk_events_pending()) {
> gtk_main_iteration();
> }
>
> that will update the GUI while your calculations proceed.

Or, better, do:

while(g_main_iteration(FALSE)); /* No body */

which skips the gtk wrappers around the glib main loop.
In 2.0, you'll want to do:

while(g_main_context_iteration(NULL, FALSE)); /* No body */

since g_main_context_iteration() is deprecated in 2.0 (the API changed
a bit when they added support for multiple main loops).

Ron Steinke

___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: frozen GUI!!! urgent help required!

[Paul Davis]

yes, it is common to more or less all GUI toolkits, regardless of OS
platform. 

>Isn't there a way to shortly stop calculations (for a necessary minimum
>of time) and let the GUI gather possible events? Could this work
>this way somehow? Any suggestions?

somewhere inside your calculations, call this reasonably often:

  while (gtk_events_pending()) {
  gtk_main_iteration();
  }

that will update the GUI while your calculations proceed.

--p
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: frozen GUI!!! urgent help required!

[RevX]

Oh hell!!!

Now I'm scared! Why did nobody tell me before? Is that common
with all GUI toolkits?

> Not unless you create a separate thread for the calculations. When the
> calculations finish, you should be able to interact with the GUI again.

The problem is: I'm no (good) thread programmer and for what I've read
in here it seems that Gtk+ wasn't design to be used with threads and
there will be much trouble ahead. Am I right?
And the other thing is: it was planned that the calculations stop with
the click of a button (it's a continuos online calculation/data processing)
but thus the button is not clickable under heavy system load there
has to be another way around. 

Isn't there a way to shortly stop calculations (for a necessary minimum
of time) and let the GUI gather possible events? Could this work
this way somehow? Any suggestions?

Every idea is welcome. Thanks again!
Many cheers,
Michael. 

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: frozen GUI!!! urgent help required!

[Marco Lettere]

On Tue, 12 Mar 2002 [EMAIL PROTECTED] wrote:

> Hello all,
>
> I've the following situation in/with my GUI (actually
> I'm using Gtk--, but that shouldn't matter because
> Gtk-- is only a wrapper for Gtk+):
> A checkbutton gets pressed and calculations
> begin (involving retrieving of images from a
> video camera and processing them). And
> at this moment the GUI is frozen, no buttons
> are clickable anymore and the window isn't
> redrawn when temporary overlapped by other
> windows. It looks like as if everything is frozen.
>
> So, what is going wrong??? Does the GUI of
> Gtk+ not run parallel to the calculations to fetch
> X events or is it a fault I just don't see?!
> I hope someone can help me (soon).
> Thanks for helping in advance.
>

this is because when you start doing the heavy computations your program
won't be able to catch gui events ... it will be able to catch them again
when the computations complete and the sequential flow of your program
enters a gtk_main again.
if you want to compute and process events in a parallel/concurrent fashion
you will have to use threads/processes.
M.

  _
|  _ \  ___ ___  _ __| |
| | | |/ __/ _ \| '__|  _|
| |_| | (_| (_) | |  | |___
|/ \___\___/|_|  |_|


___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: frozen GUI!!! urgent help required!

[Dave Reed]

> From: [EMAIL PROTECTED]
> X-Priority: 3 (Normal)
> X-Authenticated-Sender: #[EMAIL PROTECTED]
> X-Authenticated-IP: [128.131.86.231]
> X-Flags: 0001
> Content-Type: text/plain; charset="us-ascii"
> Sender: [EMAIL PROTECTED]
> X-BeenThere: [EMAIL PROTECTED]
> X-Loop: [EMAIL PROTECTED]
> X-Mailman-Version: 2.0.8
> Precedence: bulk
> List-Help: 
> List-Post: 
> List-Subscribe: ,
>   
> List-Id: General discussion of GTK+ 
> List-Unsubscribe: ,
>   
> List-Archive: 
> Date: Tue, 12 Mar 2002 14:55:47 +0100 (MET)
> 
> Hello all,
> 
> I've the following situation in/with my GUI (actually
> I'm using Gtk--, but that shouldn't matter because
> Gtk-- is only a wrapper for Gtk+):
> A checkbutton gets pressed and calculations
> begin (involving retrieving of images from a
> video camera and processing them). And
> at this moment the GUI is frozen, no buttons
> are clickable anymore and the window isn't
> redrawn when temporary overlapped by other
> windows. It looks like as if everything is frozen.
> 
> So, what is going wrong??? Does the GUI of
> Gtk+ not run parallel to the calculations to fetch


Not unless you create a separate thread for the calculations. When the
calculations finish, you should be able to interact with the GUI again.


> X events or is it a fault I just don't see?!
> I hope someone can help me (soon).
> Thanks for helping in advance.

Dave
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

frozen GUI!!! urgent help required!

[RevX]

Hello all,

I've the following situation in/with my GUI (actually
I'm using Gtk--, but that shouldn't matter because
Gtk-- is only a wrapper for Gtk+):
A checkbutton gets pressed and calculations
begin (involving retrieving of images from a
video camera and processing them). And
at this moment the GUI is frozen, no buttons
are clickable anymore and the window isn't
redrawn when temporary overlapped by other
windows. It looks like as if everything is frozen.

So, what is going wrong??? Does the GUI of
Gtk+ not run parallel to the calculations to fetch
X events or is it a fault I just don't see?!
I hope someone can help me (soon).
Thanks for helping in advance.

Cheers,
Michael.

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list