Re: gtk_widget_draw()

[Federico Mena Quintero <federico ximian com>]

On Tue, 2010-08-10 at 01:59 +0200, Benjamin Otte wrote:

[Widgets that own multiple windows]
> My current idea on how to implement it is to give the widgets a hint
> as to wether they are repainting a window or wether they are painting
> to something else. Something like gdk_cairo_get_current_window() which
> would return the currently invalidating GdkWindow or NULL. That would
> basically replace event->window and then all you need to do is check
> that the order of the draw calls is the window's stacking order and
> you're all set.

If gtk_widget_draw(w, cr) really means "paint thyself", then we need to
make widgets with subwindows have no extra work to do.

Let me throw some ideas:

- If you have an "event" signal in GdkWindow, like you proposed, then we
can make widgets responsible for connecting to their subwindows.  In
theory the (client-side) window system will send those signals in Z
order.  We may need a hint to say "send me an expose for this parent
window even if a child window obscures it" for if you want to have
transparent windows - you want the parent to paint its background, and
then the child to overlay its stuff.

- We can have gtk_widget_register_subwindow(w, window), called by widget
implementations.  Then the stock GtkWidget code magically connects to
"expose" on those GdkWindows, and calls ::draw() as appropriate.  I
guess this is roughly similar to moving gdk_window_set_user_data() into
GTK rather than GDK.  Then the "draw" method would be called with a clip
region set to the appropriate subwindow, or something.

I like the second idea better.  The summary is that even widgets with
subwindows should really paint everything to whatever is on the cairo_t
passed to draw().

  Federico