The default theme engine draws a fallback check/radio image, but
doesn't let you replace this. We now check if a background image
is set and if so render that instead of the default fallbacks.
We now support -gtk-win32-theme-part(class,part,state) in background
and border-image CSS properties. This renders the corresponding
theme part using DrawThemeBackground() and acts as a base for a
CSS based windows theme.
Note that we build the parsing code even on non-win32 so that
all themese will parse the same on all arches. We draw pink instead
of the actual theme parts on non-win32 though.
We want to move to a world where getting style properties can
allocate a new value, depending on the style property context.
In this world we can't expose "peeking" a property, as we neet
to return a ref to the property that is newly created.
So, we move the peek code into get_property and use get_property
from get_valist.
At the toplevel we have _gtk_theming_engine_get, which lets us pass
in a property context with (atm) the size to get the property for.
Then there is a lot of plumbing to push this down into the lower
layers of the style property code until finally hitting
the property resolvers.
I need this because I will be adding a property resolver for win32
theme parts, and they render differently depending on the size
(i.e. they don't scale linearly). The idea is that the code
to get the background properties will pass in the final size
and we will resolve the theme part specification to that particular
size.
If the old non-context calls are used we just hardcode a size
of 100x100.
We used to special handle gradient, but we want to be able to store
other sources (that will eventually resolve to cairo patterns).
For instance, this is needed to handle win32 theme part sources.
In gtk_tree_view_state_flags_changed() we were setting the background on
the bin_window without the necessary "view" style class, making the
treeview render with the wrong color in some circumstances (such as when
adding an empty treeview in a window, as spotted by Brian Smith).
We used to explicitly map and unmap the child GtkRecentChooserWidget when
mapping and unmapping the dialog, respectively. Now that GtkContainer actually
unmaps child widgets (instead of avoiding that), we can assume that the
child GtkRecentChooserWidget will be unmapped when we want it to be.
This fixes a warning from gtk_widget_verify_invariants(), as we were mapping
our child widget before calling our parent class' ::map() handler. Bug #659257.
Try to find keycodes for keysyms at level-0 in the keymap, but don't
fail to parse if we can find those in level-1. This fixes the
parsing of numerical keys on the keypad, which require a shift level
through Num-Lock.
https://bugzilla.gnome.org/show_bug.cgi?id=606727
This way, the a11y code knows if a column was reordered, added or
removed and can do the right things instead of trying to guess and
getting it wrong.
Also, this patch finalizes the changes so that only visible columns
exist to the accessibility interface.
In fact, invent our own function get_n_columns() which actually only
counts the visible functions, because that's the only ones we care
about.
The places where it's not used yet will be changed in the coming
patches.
