Now that widget paths are allowed to have a state, use that state when
querying style properties. This uses a fast path in gtkcssprovider.c and
that is great.
Header-bar and action-bar buttons used to be bigger then others
now everything is as big as those, maintaining two different sizes
for default widgets depending on the placement is a maintainance
nightmare and having controls the same size is good from a usability
point of view.
The toplevel_window was never set, and the only place where it
was used was causing us to hide tooltips needlessly. So removing
it is a double win.
https://bugzilla.gnome.org/show_bug.cgi?id=733321
Add yet another tab for showing information about a widget that
does not quite fit into any of the other tabs (not a property,
not style information, etc...).
For now, we show the widget state, as well as the default and
focus widget for windows.
GtkArrow is deprecated and is not used internally anymore by the
menu button. Document also the fact that if no direction is specified
then the view-context-menu icon is shown.
https://bugzilla.gnome.org/show_bug.cgi?id=733441
People expect to be able to call gtk_widget_show_all on the dialog
to make action widgets visible, as seen e.g. in
https://bugzilla.gnome.org/show_bug.cgi?id=733431
To keep this working, we can't always set no-show-all on the
action_box. Only set it when the action_area is not used and empty.
The accel label in menus was getting a small allocation that
caused its draw code to always omit the accelerator string.
Fix that by setting halign to fill. To keep the menu label
left-aligned, set xalign to 0 to compensate.
Make gtk_widget_path_append_for_widget() add the state flags of the
widget, too.
This enables the ability to select pseudoclasses on all elements in a
selector.
Don't take a state when constructing the CSS matcher. Instead, rely on
the newly introduced state in the widget path.
This way, the state can be queried not only on the first element, but on
all elements of the widget path.
Set the widget path state flags with the state flags of the style
context.
We do not update the state flags but replace the previous one because we
want to be able to have save()/restore() unset state flags.
Make backdrop insensitive state more similar to the focused
windows one, mostly to make dark variant more usable and
focused -> backdrop transition less distracting.
Add left/right/top/bottom style classes according to which edge(s)
of the progressbar the progress is adjacent to. Only for a fraction
of 1.0 will we set more than one edge.
