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 662308 - Scrollbars seem to unconditionally reserve a space for grips
Scrollbars seem to unconditionally reserve a space for grips
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
3.2.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2011-10-20 16:08 UTC by Cosimo Cecchi
Modified: 2011-10-21 20:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
nautilus screenshot (24.67 KB, image/png)
2011-10-20 16:09 UTC, Cosimo Cecchi
  Details
gedit screenshot (42.49 KB, image/png)
2011-10-20 16:09 UTC, Cosimo Cecchi
  Details
Propagate the statusbar handling of the grip to GtkWindow (6.13 KB, patch)
2011-10-20 18:06 UTC, Cosimo Cecchi
rejected Details | Review
range: use the right widget for allocation coordinate translation (1.35 KB, patch)
2011-10-20 20:08 UTC, Cosimo Cecchi
accepted-commit_now Details | Review
GtkRange: use the right widget for coordinate translation (1.34 KB, patch)
2011-10-21 20:32 UTC, Matthias Clasen
committed Details | Review

Description Cosimo Cecchi 2011-10-20 16:08:18 UTC
- open an application which uses a scrolled window and a resize grip (e.g. GEdit or Nautilus) and make the view so that a scrollbar is shown
- enable the statusbar
- the space for the resize grip seems to be reserved both on the statusbar and the scrollbar, see attached screenshot
Comment 1 Cosimo Cecchi 2011-10-20 16:09:09 UTC
Created attachment 199547 [details]
nautilus screenshot
Comment 2 Cosimo Cecchi 2011-10-20 16:09:27 UTC
Created attachment 199548 [details]
gedit screenshot
Comment 3 Cosimo Cecchi 2011-10-20 18:06:06 UTC
Created attachment 199563 [details] [review]
Propagate the statusbar handling of the grip to GtkWindow

GtkRange has some logic to trim its allocation when there's a resize
grip showing for its toplevel GtkWindow.
Unfortunately this doesn't take into account the fact that a
GtkStatusbar could be visible, and handle the resize grip itself.
Fix this by having GtkStatusbar set an internal flag on the window as
long as it's mapped, and don't trim the range's allocation if such a
flag is set.
Comment 4 Matthias Clasen 2011-10-20 19:32:15 UTC
Review of attachment 199563 [details] [review]:

I don't think this is quite right. The code in gtkrange.c is trying to determine if there's any overlap between the range area and the resize grip. That code should already take care of not reserving space when there is a statusbar, since in that case, there is no overlap. There must be a bug in the overlap calculation that we should fix, instead of adding a separate property to work around it.
Comment 5 Cosimo Cecchi 2011-10-20 20:08:07 UTC
Created attachment 199578 [details] [review]
range: use the right widget for allocation coordinate translation

GtkRange needs to check if its allocation intersects with the resize
grip allocation (trimming its own allocation if it does).
In order to do that, it needs to translate its allocation into window
coordinates, and before that, find the window to whose the allocation
is relative; code goes all the way finding the right parent widget, but
then doesn't actually use it when translating the coordinates, leading
to using the wrong rectangles for the intersection check.
Comment 6 Cosimo Cecchi 2011-10-20 20:08:59 UTC
(In reply to comment #4)
> Review of attachment 199563 [details] [review]:
> 
> I don't think this is quite right. The code in gtkrange.c is trying to
> determine if there's any overlap between the range area and the resize grip.
> That code should already take care of not reserving space when there is a
> statusbar, since in that case, there is no overlap. There must be a bug in the
> overlap calculation that we should fix, instead of adding a separate property
> to work around it.

Yes, you're right; I misunderstood the purpose of GtkRange's check.
Attached patch should be much better.
Comment 7 Matthias Clasen 2011-10-21 02:35:07 UTC
Review of attachment 199578 [details] [review]:

Looks much better, and works fine in my testing.
Comment 8 Matthias Clasen 2011-10-21 20:32:30 UTC
The following fix has been pushed:
18a638a GtkRange: use the right widget for coordinate translation
Comment 9 Matthias Clasen 2011-10-21 20:32:33 UTC
Created attachment 199700 [details] [review]
GtkRange: use the right widget for coordinate translation

GtkRange needs to check if its allocation intersects with the resize
grip allocation (trimming its own allocation if it does).
In order to do that, it needs to translate its allocation into window
coordinates, and before that, find the window to whose the allocation
is relative; code goes all the way finding the right parent widget, but
then doesn't actually use it when translating the coordinates, leading
to using the wrong rectangles for the intersection check.