Multiple changes:
- actions are now available unconditionally, but only work in the right
state. This mirrors other actions.
- instead of adding actions manually, they invoke the action on the
GtkCellAccessibleParent interface.
Tests have been updated to reflect the changes
Treat the empty string as if it was a NULL icon name instead of
rendering GTK_STOCK_MISSING_IMAGE.
This used to be the previous behavior of GtkCellRendererPixbuf and
applications might still rely on it.
We need to save the icon size locally for GtkCellRendererPixbuf, since
its properties are set again every time it's drawn (resetting the icon
size on the helper by means of _gtk_icon_helper_clear() each time).
The code is very similar; having two slightly different code paths is
bad and can lead to bugs. Refactor the code to use the same height
request function.
For maximized windows, titlebars cannot be used to reposition or
scale the window, so if an application does not use it to convey
useful information (other than the application name), the screen
space occupied by titlebars could be put to better use.
Add a new window property which requests from the window manager
to hide titlebars when windows are maximized to account for this.
https://bugzilla.gnome.org/show_bug.cgi?id=665616
If the scale has an origin (it will have one by default), GtkRange will
render the two sides before/after the current value with different style
classes, making it possible for themes to use different colors and
properties for the two areas.
This was possible in GTK 2 with style details, but got lost during the
road to 3.0.
https://bugzilla.gnome.org/show_bug.cgi?id=665140
In many cases we used to set focus_child to NULL all the way up
to the top and then to the right value, even if there was
a common ancestor, meaning these see a temporary NULL value for
focus_child. Only when the new focus widgets direct parent was
in the previous ancestor list did we stop early.
This fixes that by always stopping propagation when reaching
the common ancestor.
The casting used to calculate the child allocation is confusing MAX().
As a result, width and height end up with negative values, which makes no sense.
https://bugzilla.gnome.org/show_bug.cgi?id=666109
There was a corner case where the changed signal was not emitted.
If rows were built like this:
1 (not selected)
+ 2 (selected)
+ 3 (not selected)
And row 1 was removed, no signal would be emitted.
I like it when writing tests actually finds bugs that have been around
since 2003 - introduced by 4a03ea2334
actually. :)
We get certain cases, in particular with SELECTION_MULTIPLE, where we
cannot figure out in advance of real_set_cursor() if the selection will
actually change.
Previously, the cursor would just become invalid, which used to
reselect the first row in the treeview later on (without a
cursor-changed signal). This leads to a crash now with the recent
refactorings.
The patch is longer than I'd like it to be, but the situation is kinda
complicated, because we want to make sure to move the cursor to a good
row. It works like this:
1) From the deleted row, search forward for the first row that is not
going to be deleted and is not a separator.
2) If no such row exists, search backwards for a row that is not a
separator.
3) If no such node exists, clear the cursor.
