This gets the current cell area of a particular item. Its similar
to gtk_tree_view_get_cell_area().
The code is extracted from gtk_icon_view_set_tooltip_cell which now
just calls the old code.
https://bugzilla.gnome.org/show_bug.cgi?id=678418
If the icon view is empty, we cannot get a reasonable size request from
the cell renderers. So all values we would compute are pretty much
useless.
So we special case it.
This also gets rid of a bunch of crashers from div-by-0 in corner cases.
https://bugzilla.gnome.org/show_bug.cgi?id=677809
This is useful for 2 reasons:
(1) Items actually exist and are clickable
(2) Size computations don't divide by 0
I've not seen problems with this in the wild (mostly because
item-padding defaults to non-0), but noticed this while fixing other
bugs.
Minimum size is necessary so you can see the item. If we can't get that
we need to scroll.
Natural as the maximum is used so that the spacing between items doesn't
increase when resizing the iconview, but empty space is added to the
right/bottom instead.
https://bugzilla.gnome.org/show_bug.cgi?id=677809
While working on the "iconview: Don't shrink items" patch I noticed that
gtk_icon_view_compute_n_items_for_size modifies the natural and minimum
item sizes it got from gtk_icon_view_get_preferred_item_size when
calculating the max number of items which will fit, but later on it
checks against these sizes when calculating the item_size, and these
checks expect these values to be unmodified.
This patch fixes this by modifying the natural and minimum values in
advance and doing all computations with modified values.
https://bugzilla.gnome.org/show_bug.cgi?id=677809
The previous code assumed that the width was always enough for more than
one column, which is obviously not correct when a number of columns is
hardcoded.
With this patch, it will now always check that the width is enough and
otherwise cause scrolling.
https://bugzilla.gnome.org/show_bug.cgi?id=677809
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
