Code was using different places to compute the icon size when layouting
and when doing size requests. This resulted in non-matching behavior in
obscure cases. And that lead to iconviews that were too small.
This ensures that items stay left-aligned instead of slowly expanding into
empty space when widening the iconview. It's also what the iconview did
pre-refactoring.
Note that for cases where natural width != minimum width, the cells
might still expand and shrink back.
Always assume max-columns and min-rows. The old approach was kinda
insane.
As an example, try to write an algorithm that optimizes the minimum size
for infinite (take a reasonably large number like 2520) word-wrapped
Monospace text cells containing the text "XXXXX XXX XXX XXXXX" (keep in
mind that this is the easy problem, because it's assuming equal cell
renderers). There's 4 ways to reasonably lay out this text:
19 glyphs (19x1):
XXXXX XXX XXX XXXXX
18 glyphs (9x2):
XXXXX XXX
XXX XXXXX
21 glyphs (7x3):
XXXXX
XXX XXX
XXXXX
20 glyphs (5x4):
XXXXX
XXX
XXX
XXXXX
The best thing to do usually is using the 9x2 approach, but that's
neither the one using the natural nor the one using the minimum size.
As a side note, this does not include spacing and padding, which might
also influence the decision. Nor does it include height-for-width
considerations. Look at this table (numbers given in glyphs, not pixels,
as for pixel-sizes it gets even more interesting):
given best solution
width columns sizing glyphs per cell
6 1 6x4 20
7 1 7x3 21
8 1 7x3 24
9 1 9x2 18
10 1/2 9x2/5x4 20
11 1/2 9x2/5x4 22
12 1/2 9x2/5x4 24
13 1/2 9x2/5x4 26
14 2 7x3 21
15 3 5x4 20
16 3 5x4 21.3
17 3 5x4 22.7
18 2 9x2 18
19 1/2 19x1/8x2 19
20 1/2/4 19x1/8x2/5x4 20
21 1-4 any 21
22 1-4 any 22
23 1-4 any 23
24 1-4 any 24
25 5 5x4 20
26 5 5x4 20.8
27 3 9x2 18
28 3 9x2 18.7
29 3 9x2 19.3
30 3/6 9x2/5x4 20
Now of course, nobody wants the number of columns to randomly change in
inexplicable ways while they enlarge or shrink an iconview, so we not
only have to optimize for smallest or other size measurements, but we
also have to optimize for "most pleasing to the eye".
And last but not least, I'd like to once again remind you - if you kept
up until now - that this discussion was for identically-sized cells
only.
Instead of just returning the last allocated numbers, we now compute the
proper sizes from scratch. This is a bit less trivial, but it results in
proper height-for-width handling.
This is a huge quest to remove all caching from GtkIconview to simplify
the code. As it turns out, iconview performance is a joke, so the caches
are kinda unnecessary.
If we need caching, we can add it in a useful way later.
If we use
&item->cell_area
instead of
(GdkRectangle *) item
there is no need anymore to keep the cell_area as the first member of
the the item. And we cget compile-time checks for changes to the item
struct.
This can cause lagging when scrolling as it causes us to repaint
on every scroll event. This wasn't historically a great problem,
but with smooth scrolling we get a lot more events, so this
now creates visible lagging on slower machines.
The widget window is usually covered by the bin_window.
Its background color will become relevant when we introduce
kinetic scrolling with overshooting.
As the draw handler expects the items to be laid out already, we cannot
queue a layout here to avoid a race condition with the resize that is
queued immediately after, which in turn would lead to a segfault later
in the paint_item() implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=663138
which are SHIFT and MOD2 on the Mac, and SHIFT and CONTROL otherwise.
Use the new define all over the place and rename variables and
members to not say "shift" or "control".
Render GtkIconView cell items with the prelight state flag when they're
being mouse hovered.
This works basically in the same way it's done for GtkTreeView cells,
and e.g. GtkCellRendererPixbuf will need to have its follow-state
property to opt in to prelight rendering.
https://bugzilla.gnome.org/show_bug.cgi?id=615501
The code sets old_adj_ptr to the location containing the old weak ref,
but then wants to remove a weak ref from &view->old_hadj, causing warnings
when disposing the widget.
This commit introduces a new setting, gtk-visible-focus, backed
by the Gtk/VisibleFocus X setting. Its three values control how
focus rectangles are displayed.
'always' is equivalent to the traditional GTK+ behaviour of always
rendering focus rectangles.
'never' does what it says, and is intended for keyboardless
situations, e.g. tablets.
'automatic' hides focus rectangles initially, until the user
interacts with the keyboard, at which point focus rectangles
become visible.
https://bugzilla.gnome.org/show_bug.cgi?id=649567
