Padding adds up. A selector like "actionbar box" matches any box
inside an actionbar, so nested boxes accumulate more and more
padding. The intention clearly was to just give padding to the
topmost box that is the direct child of the actionbar's revealer.
https://bugzilla.gnome.org/show_bug.cgi?id=762036
Clip children to their window's size. That way no overdraw happens for
these widgets. But don't clip the handle.
We might in the future consider not clipping un-shrinkable children.
https://bugzilla.gnome.org/show_bug.cgi?id=762021
This requires adding code to do math on number values:
gtk_css_number_value_multiply()
and
gtk_css_number_value_try_add()
were added to achieve that.
Some tests are included.
GtkCssNumberValue is now a base class for numbers.
Actual numbers are now implemented in GtkCssDimensionValue. The name is
borrowed from the CSS spec, so there.
This is in preparation for calc(), as calc(50% - 5px) is valid CSS
but has 2 units. Instead, add a function to query a value's dimension
(so we can differentiate lengths from numbers) and add a function to
query if the value contains percentages.
Margins can be negative, and if we are not careful, then
content+padding+margin can end up with negative dimensions,
which can upset pixman and others. This commit ensures
that a gadget will not request or draw boxes with negative
dimensions, and get_border_allocation and get_content_allocation
will not return boxes with negative dimensions.
This fixes a crash in the paned separator drawing code that
can be reproduced by setting separator padding to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=759657
With the location entry up in the header bar in save mode, we can
end up with the search model being in use when the user types in
the location entry. In this case, we don't make the Save button
sensitive as we should.
Having two entries in the dialog is somewhat confusing anyway,
so just stop the search when the user starts typing in the location
entry.
https://bugzilla.gnome.org/show_bug.cgi?id=761757
This reverts commit 572e9a0402.
_gtk_box_get_children was not doing exactly the same than
gtk_container_get_children does, because the latter uses the forall
implementation of GtkBox that takes into account the children pack mode while
the former just iterated the list of children. This broke the order of
the buttons in a GtkButtonBox when they were packaged with PACK_END.
