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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list