On 03 Mar 2003 11:54:42 +0100 Michael Natterer <mitch@xxxxxxxx> wrote: > Again, you should understand how GObject signals work. They operate > purely synchronously. A signal handler cannot be "too slow" because > the only thing your program is doing while emitting the signal is > emitting the signal. When the call to g_signal_emit() returns all > handlers have been called in order of connection. But signal handlers can do anything they want, and so I assumed that they could also could also somehow invoke the main loop to process new events. I know at least one signal handler that works in this way. The rendering function for my preview indirectly calls the gtk main loop to process new events, because the user must be able to scroll and zoom the preview even while the rendering function is executing. But from your comments I guess that this is an exceptional case and that this is something that "good" signal handlers will not do. > The solution I propose is simply updating the preview in an idle > function. This way you can change the underlying model as often > as you like and the idle logic will make sure subsequent changes > are compressed into a single update of the GUI. > > Actually, the preview should update itself when it gets exposed. GTK > already compresses and idles updates of the GUI, so everything that > should be needed is calling gtk_widget_queue_draw() or > gtk_widget_queue_draw_area() on the parts of the preview you want to > update and the "expose" handler will do it's job of re-rendering at > just the right time, namely immediately before the stuff is drawn to > screen. This seems a good idea. I have just rewritten my widget this way and it appears to be working fine. greetings, Ernst
