After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 110737 - gtk_viewport_realize() does not honor initial scroll offset
gtk_viewport_realize() does not honor initial scroll offset
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.2.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2003-04-14 08:00 UTC by Michael Natterer
Modified: 2011-02-04 16:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to fix the bug (673 bytes, patch)
2003-04-14 08:02 UTC, Michael Natterer
none Details | Review

Description Michael Natterer 2003-04-14 08:00:07 UTC
gtk_viewport_realize() creates viewport->bin_window always at
position (0,0), this makes it impossible to change the viewport's
adjustment to acheive an initial, computed scroll offset.

When doing so, a scrolled window shows up with its scrollbars
scrolled to the correct initial position, but the content of
the viewport still being at position (0,0).
Comment 1 Michael Natterer 2003-04-14 08:02:29 UTC
Created attachment 15697 [details] [review]
patch to fix the bug
Comment 2 Michael Natterer 2003-04-14 08:04:21 UTC
The attached patch fixes the problem, the computation of
attributes.x and .y was taken from
gtk_viewport_adjustment_value_changed().

OK to commit?
Comment 3 Owen Taylor 2003-05-21 18:32:54 UTC
Looks fine to commit to me (gtk-2-2 and HEAD). 

Can you figure out why the value_changed handler has the
check for?

      if (viewport->hadjustment->lower != (viewport->hadjustment->upper -
                                          
viewport->hadjustment->page_size))

I can't ... 
Comment 4 Michael Natterer 2003-05-22 13:06:12 UTC
Hm, they actually say:

if (the adjustment can be moved at all)
  set_the_value_from_adjustment's_value;
else
  leave_the_value_at_0;

Looks as if the code is assuming that adjustment->lower is
*always* equal to 0, which is not true, since the lower/upper
bounds of adjustments set using gtk_viewport_set_[vh]adjustment()
are never checked to be correct unless the viewport receives
a size_allocate().

So IMHO the checks need to be removed since they are useless
given the adjustment->lower == 0 constraint is true, plus,
external adjustments set using gtk_viewport_set_[vh]adjustment()
need to be modified to have proper lower/upper/page_size.
Comment 5 Owen Taylor 2003-06-06 18:31:25 UTC
I'm thinking that likely at one point GtkViewport scaled 
the adjustment coordinates or that this is a cut-and-paste
from some widget that did, since what:

      if (viewport->hadjustment->lower != (viewport->hadjustment->upper -
                                          
viewport->hadjustment->page_size))
 
Looks most like to me is a division-by-zero check for a division
that is no longer there.
Comment 6 Owen Taylor 2003-06-06 23:14:54 UTC
Fri Jun  6 16:25:44 2003  Owen Taylor  <otaylor@redhat.com>
 
        * gtk/gtkviewport.c: Many fixes, along with extensive cleanups and
        refactoring of code to reduce duplication; fixes include:
 
        - gtk_viewport_realize(): Position the window correct from
adjustment
        values. (#110737, Michael Natterer)
 
        - Remove some division-by-zero checks in places where there is no
        longer division. (#110737)