Re: Forcing update of widgets

["Mark R. Rubin" <markrubn pacbell net>]

Paul Davis <pbd Op Net> writes:

> >        while (g_main_iteration(FALSE))
> >            ;
> 
> this is the wrong design for "realtime display applications". if you
> want the GUI to update while other activity is happening, you should
> be using either idle handlers or threads. idle handlers work if the
> "other activity" is short lived. threads are necessary for other
> situations. with threads come some extra complications, as well as
> better performance.

o Thanks, Paul.  But I *don't* want "the GUI to update while other
  activity is happening".  I want to call something that will update
  the widgets all the way down to an XFlush() before returning
  control to the caller (me), all without accepting any input.

o BTW, the application has many independent flows of control (at the
  process, not Posix thread, level).


> widget->queue_draw() will mark a widget as needing an expose_event to
> be synthesized for it. the expose_event will be delivered during the
> next iteration of the GTK main loop.

o widget->queue_draw() sounds good if in fact an expose_event,
  synthetic or otherwise, is needed in additon to a widget state
  change to force a real redraw.  Re-entering the main loop (and
  risking asynchonous input) is the problem.

o Is there an API-exposed call for just that portion of the GTK main
  loop that does drawing?  I seem to recall that the old XtMainLoop()
  could be manually coded with a while loop calling a half-dozen
  lower-level functions.


--
MARK
markrubn pacbell net