Re: Problems with expose_event->region patch

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On 8 Mar 2001, Owen Taylor wrote:
> 
> > Tim Janik <timj gtk org> writes:
> 
> > For NO_WINDOW widgets, gtk_widget_get_parent_window (widget) === widget->window.
> > 
> > No?
> 
> sure, but not necessarily
> gtk_widget_get_parent_window (child) == child->parent->window, so
> he should check for child->window == event->window.
> you talked about container, then said "widget->window" while the
> function just has "container" and "child", so i guess i confused you
> saying "widget" meaning "child" with you saying "widget" meaning "container".

OK, sounds like we are agreeing on the check.
 
> > > urm, just looked at that function to see what it does, i'd actually
> > > have it expected to queue an expose event, but instead you
> > > also dispatch that right away through gdk_event_func (gtk_main_do_event).
> > > since the caller might be anywhere in a deep callstack i'm not so sure
> > > this is a good idea...
> > > why couldn't that simply be:
> > > gdk_window_queue_updates();
> > > while (g_main_pending ())
> > >   g_main_iteration (FALSE);
> > 
> > The idea is that you want to update a window _without_ running
> > the main loop.
> > 
> > Did you also worry about the caller being in a deep call stack
> > when they called gtk_widget_draw(widget)?
> 
> no, gtk_widget_draw() had its own signal and didn't call gtk_main_do_event().

If I call gtk_main_do_event() with events I know - expose events,
I don't see the difference, really.

(gtk_widget_draw() would typically synthesize large number of expose
events, since the default implementation of ::draw was to synthesize
an expose...)
                                        Owen