Re: gtk+2 drawing on top of widgets

[Dennis Bjorklund <db zigo dhs org>]

On 31 Dec 2001, Havoc Pennington wrote:

> There is basically no supported way to do this - no one has thought
> about how it would work at all. So don't be surprised if it's
> impossible or difficult - but maybe you can figure out some hack. ;-)

If I turn of double buffering it seems to work to paint over widgets.

> > So I tried to turn of double buffer for the window and tried to
> > get the old bahviour by calling first
> >
> >  gdk_window_begin_paint_region (event->window, event->region);
>
> The docs for this function may help, and also check out the source
> code to gtk_main_do_event() to see when GTK calls it automatically.

I did see this sentence in the for doc gtk_widget_set_double_buffered:

"Double buffered" simply means that gdk_window_begin_paint_region() and
gdk_window_end_paint() are called automatically around expose events sent
to the widget.

which is why I thought it was going to work if I just called these two in
my expose-event handler. But by just inserting these in my handler is not
equivalent with the double buffer mode.

> You may want to try g_signal_connect_after() to run your expose
> handler _after_ the default handlers.

Yes, for the not double buffered case, this works. It paints over
everything else. With double buffer there is clipping.

> One problem you have is that exposes are per-window, and won't include
> subwindow-obscured areas; you need the union of exposes for a window
> and all its subwindows. So you might want to use GdkRegion to maintain
> a damage region that is the union of exposes received on a toplevel
> window and all subwindows;

Your solution above sounds like it can work. I'm going to try that.  I
could simply connect to the expose of all the children and when they get
an expose I can invalidate the same region in the parent.

The problem is that the child already have painted when it gets the
expose, which will make the image flick. Maybe I can pretend that the
expose is already taken care of so the child don't get it and then let the
parent generate new exposes for the child that it will use to really
paint.

This is getting more and more hacky :-)

There is no way to get hold of the invalidation calls to the children? So
I can invalidate the parent at the same time as the child is invalidated?
It seems that this is what is needed.

I just don't want to use the drag n drop method since when you move that
image there is usually a white box where the image was before. It is
quickly painted over, but very visible anyway.

But of course if it does not work I will use some another method, but I
will not give up just yet.

> You still have the problem that widgets can legitimately draw with no
> expose event involved, though GTK 2 normally does not do so, I can't
> think of an example.

I'm not planing to put any kind of widget there anyway, so I can choose
widgets that does not do this (or handle it if it's a problem).

-- 
/Dennis