GNOME Bugzilla – Bug 662308
Scrollbars seem to unconditionally reserve a space for grips
Last modified: 2011-10-21 20:32:33 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
Created attachment 199547 [details] nautilus screenshot
Created attachment 199548 [details] gedit screenshot
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.
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.
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.
(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.
Review of attachment 199578 [details] [review]: Looks much better, and works fine in my testing.
The following fix has been pushed: 18a638a GtkRange: use the right widget for coordinate translation
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.