On Wed, 2008-02-20 at 11:24 -0500, Lindley M French wrote: > I've asked this question on several Gtk forums on previous occasions, but never got much of a response. As this list seems a bit more active, perhaps my luck will be better here. > > I'm trying to implement a zoomable + scrollable window which remains centered on the same point while it zooms. To this end, I have the following hierarchy: > > vbox > scrolled_window > draw_area > hscale the short answer is that you can't do this at present. GTK uses window-system-level level routines to implement the move/scroll part of this. When you change the adjustment, the window is moved using (on X11) XMoveWindow. If you do not change the zoom at the same time, this is exactly what you want - the area of the window that is newly displayed gets redrawn by a suitably constructed expose event and everything is good. However, if you wanted to change the zoom as well what actually happens is that the window gets low-level moved by the adjustment change, and the later redraw of the entire window (required by your zoom change) comes along later. There is nothing in the X API (and hence in the GTK API) that can stop these two visual effects being completely disjoint from each other. Sometimes you get lucky - the speed of the X server in handling the requests and the synchronization with the screen's vertical redraw timing means that you don't see them as two separate effects. But most of the time, you (or your users) are not so lucky, and the glitch is clear. This at least is my conclusions after deep investigative work trying to do the same thing as you in the context of the GnomeCanvas. You need a new kind of widget that never ever uses lowlevel window moves as a way to accomplish scrolling, or rather, uses them only when the widget users makes it clear that no accompanying zoom is scheduled. That is, when doing "scroll+zoom", it would skip the lowlevel window move and just lead to a redraw of the entire window. I do not know of any GTK widgets that can trivially be adapted for this purpose. Most of those involved in scrolling use the position of the scroll adjustment to indicate the amount by the which the larger window has been offset using lowlevel window motion. The moment you skip a lowlevel window move as part of a scroll is the moment that these widgets completely lose track of what is being displayed. I currently consider this one of the most egregious design flaws in GTK, although there are no too many of these so thats not saying much :) --p _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
