---- Reported by jim@yorba.org 2011-07-22 15:44:00 -0700 ----

Original Redmine bug id: 3870
Original URL: http://redmine.yorba.org/issues/3870
Searchable id: yorba-bug-3870
Original author: Jim Nelson
Original description:

When Shotwell firsts run the horizontal scrollbar for the checkerboard page
appears even though the layout should be narrow enough to prevent it being
required.  (This can be confirmed by clicking the mouse anywhere on the
checkerboard page; although the layout remains the same the scrollbar
immediately disappears.)

Additionally, when resizing the window the horizontal scrollbar will appear
and disappear as the window resizes.  If you stop moving the mouse (but keep
the button pressed) at a point that the scrollbar is still present, it will
disappear when you release the mouse button, regardless if the layout changes.



---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:39:00 -0700 ----

### History

####

#1

Updated by Adam Dingle about 2 years ago

  * **Target version** set to _0.12_

####

#2

Updated by Adam Dingle about 2 years ago

  * **Priority** changed from _Normal_ to _High_

####

#3

Updated by Lucas Beeler about 2 years ago

  * **Description** updated (diff)
  * **Assignee** set to _Lucas Beeler_

####

#4

Updated by Lucas Beeler about 2 years ago

@Jim:

I'm now attacking this bug. Didn't you say at some point that you had some
inkling as to what might be causing this? If you could post your suspicions to
this ticket that'd be incredibly helpful to get me started.

I hope you guys are enjoying Orlando...

Lucas

####

#5

Updated by Jim Nelson about 2 years ago

First, note that the obvious solution -- simply turn off the horizontal
scrollbar by setting the Policy to NEVER -- doesn't work. Or, at least, it
didn't work in GTK+2. GTK would layout a fixed scrollbar that was essentially
inactive. The only solution we had was to make the horizontal policy AUTOMATIC
and arrange the checkerboard in such a way that it was never activated by GTK.
This turned into quite a task.

Another solution I looked into was getting a ref to the scrollbar widget and
hiding it, but it turned out that this caused some unacceptable flickering.

So: under GTK+3, either of these two approaches may solve the problem. It's
worth looking into.

They way I dealt with this problem under GTK+2 was to track the flow of
events, which go something like this:

  * Empty checkerboard is created. No scrollbars. The CheckerboardLayout (a Gtk.Drawable) is, by default, set to a size smaller to or equal to the viewport.
  * The checkerboard's ViewCollection is populated with CheckerboardItems. reflow() is called to determine the layout of all the items. At the end of reflow() the CheckerboardLayout's dimensions are resized to fit all the items and their margins.
  * This causes the on_viewport_resized handler to be called. This handler could be called either because we reflowed the layout **or** the user resized the window. An internal flag is used to differentiate.
  * Because the CheckerboardLayout is now larger than the viewport (assuming enough items are present), the vertical scrollbar is placed on the screen by GTK. This causes the viewport to be resized (narrowed) to accommodate.
  * The on_viewport_resized() handler is called again. The CheckerboardLayout now needs to be resized to fit inside the viewport's width.
  * reflow() is called again to layout the items in the new dimensions.
  * Often (not every time) the CheckerboardLayout's height must be extended to accommodate the new layout. This causes on_viewport_resized() to be called again. The internal flag (and other calculations) are used to prevent resizing the layout again (which would be unnecessary at this point).

I know this sounds needlessly complex, but this is how it works with a
dynamically reflowing widget system combined with our requirements with
CheckerboardLayout. What's more, this system also deals with the case where
items are added or removed at runtime (due to user operation or monitoring) or
the items' sizes have changed (i.e. thumbnail is cropped or rotated) and the
layout has to be reflowed.

The problem, I believe, is that when the initial event flow happens, a
calculation somewhere isn't done properly causing the layout to be slightly
wider than the viewport, causing the horizontal scrollbar to be activated.
Part of the gymnastics above is due to resizing the CheckerboardLayout at the
right time -- that is, at the moment that we know for sure what the viewport's
dimensions are. Remember, in GTK+2 the size a widget requests is not the same
as what the widget is assigned.

This has changed in GTK+3 with its new allocation model. More reading:

http://developer.gnome.org/gtk3/3.1/ch25s02.html#id1499013

http://developer.gnome.org/gtk3/3.1/GtkWidget.html#geometry-management

http://developer.gnome.org/gtk3/3.1/GtkContainer.html#container-geometry-
management

There's a TRACE_REFLOW #ifdef that can be turned on. It's quite verbose, but
carefully walking through it can reveal what events are firing, in what order,
and with what values they're dealing with.

####

#6

Updated by Lucas Beeler about 2 years ago

  * **Status** changed from _Open_ to _5_
  * **Resolution** set to _fixed_

Fixed in fa3c93a9ba6ee305e96354b20209cc879d20ba04

####

#7

Updated by Adam Dingle about 2 years ago

Hooray!

####

#8

Updated by Adam Dingle about 2 years ago

...and I'm glad that in the end this was essentially a 1-line fix. Go Lucas!

####

#9

Updated by Charles Lindsay 7 months ago

  * **Status** changed from _5_ to _Fixed_



--- Bug imported by chaz@yorba.org 2013-11-25 21:53 UTC  ---

This bug was previously known as _bug_ 3870 at http://redmine.yorba.org/show_bug.cgi?id=3870

Unknown Component 
   Using default product and component set in Parameters 
Unknown milestone "unknown in product shotwell. 
   Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.