[EMAIL PROTECTED] wrote: > This all works fine. The problem happens when part of the window is > obscured: > > | > 0 +-----------------------------| Obscuring > | | window > dy |=============================| > | +------------- > | | > | | > | | > h +------------------------------------+ Hi Dov. You need to use graphics_expose events to repaint this stuff. Take a look at widgets like gtk_list to get an idea how to handle this. The sequence is roughly: - do a gdk_window_copy_area() to scroll your window contents down by dy - you'll get a series of graphics_expose events back, one for each exposed rectangular area - for each of these exposes, either repaint immediately, or add that area to your list of pending repaints - each expose has a count field ... when this reaches zero, you've finished scrolling There are obvious ways to make this nicer. Rather than blocking, you can keep track of any pending graphics_expose events, and only block scrolling if the previous scroll action has not yet completed. Even better, you can allow multiple delayed scroll repaints across multiple windows. Which is somewhat hairy :-) This pain is necessary because X tries to be asynchronous. The idea is that your app should still work acceptably over a link with a 500ms latency. (you might be able to use gtk's scrolling infrastructure to handle most of this, I don't know. I guess you've tried gtk_layout and friends?) Hope this helps, John -- John Cupitt, [EMAIL PROTECTED], +44 (0)20 7747 2570 VASARI Lab, The National Gallery, Trafalgar Square, London, WC2N 5DN _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
