[Glade-devel] Commit -- fix selection
Owen Taylor
otaylor@redhat.com
23 Jun 2003 16:45:34 -0400
On Mon, 2003-06-23 at 16:39, Joaquin Cuenca Abela wrote:
> Hi!
>
> Owen wrote:
> >
> > On Fri, 2003-06-20 at 03:08, Joaquin Cuenca Abela wrote:
> > > Just a little heads up.
> > >
> > > I've changed how selection works.
> > >
> > > What was broken?
> > >
> > > First, the handlers that draw the nodes:
> > >
> > > There were two version, one for GladeWidget, and one for
> > > GladePlaceholders. The GladeWidget one was using the
> > GdkWindow of the
> > > widget directly, instead of using the double buffered window. No
> > > wonder it didn't work correctly, needing the "event_after" hack etc.
> >
> > Probably not important, but this doesn't make sense... during
> > expose handling, the double buffered pixmap is all that is
> > available ...
>
> Then, I don't understand how all that works...
>
> Let's see, I though that if you have an expose handler, you should draw
> on the expose->window, which is the window that gdk creates just before
> the expose event (the double buffered one).
>
> The code was instead drawing on the widget->window (or on the window of
> one ancestor). This is the window that I called "the GdkWindow of the
> widget". We were able to saw the nodes, just because we were not taking
> in account the damaged region, and we were drawing at each expose the
> whole rectangle with the nodes. The damaged region will be redrawed
> when the expose propagation ends with the double buffer (that we didn't
> touch), and thus we saw the nodes everywhere except in the damaged
> region.
>
> So, am I on crack? It makes sense for me, but I believe you much more
> than myself on anything that concerns gtk.
Likely what's going on is that you have a widget like GtkEntry where
the main drawing area is in a subwindow of widget->window.
Then when you get an expose on event->area, you were drawing on
widget->window with IncludeInferiors set in the GC, which *did*
draw on the real X window event->area instead of the backing pixmap
(since GDK can't intercept IncludeInferiors drawing) and then
the backing pixmap when flushed wrote over your nodes.
Regards,
Owen