Re: bug in gtk_adjustment_clamp_page()?

[jcupitt gmail com]

On 27 November 2015 at 12:21, Thomas Martitz <kugel rockbox org> wrote:
> Am 26.11.2015 um 16:24 schrieb jcupitt gmail com:
> > Or maybe I've misunderstood what clamp_page is for. Is this a bug?
> >
> > The context here is tabbing focus into a scrolled window triggers
> > gtk_adjustment_clamp_page(), which always scrolls back to the left/top
> > because of these swapped tests. I'm working on an image viewer and I
> > obviously don't want to move the image around when I tab into that
> > window.
> >
> > If I swap the < and >, everything seems to work for me at least.
>
> I can't tell if that's the fix, but I also experience the erroneous
> behaviour you describe.

Thanks to Florian Muller I found the fix.

I had a GtkDrawingArea inside a GtkScrolledWindow, and the drawing
area could be tabbed to (I want various keyboard actions for image
navigation).

When you tab to something inside a container, if the container has
scrollbars, they will automatically scroll to make the object visible.
This code is in gtkcontainer.c:

https://git.gnome.org/browse/gtk+/tree/gtk/gtkcontainer.c#n2680

The problem I had (and I guess you have?) is what happens if the
object being made visible is larger than the viewport. The code in
gtk_adjustment_clamp_page() will move the scrollbars to the top or
left of the object, even if as much of the object as possible is
already being displayed.

The fix for me has been to make the scrolled window rather than the
drawing area the thing you can tab to. If the drawing area isn't a tab
target, you won't get the inappropriate auto-scroll behaviour. I
attach my key event handler to the scrolled window and then translate
event positions to drawing area coordinates myself.

I suppose another solution would be to change the behaviour of
gtk_adjustment_clamp_page() for objects larger than the viewport, but
I doubt if there's much enthusiasm for that.

My code is here, if it's any help:

https://github.com/jcupitt/vipsdisp

John