The previous way of manually juggling the visibility of the
labels doesn't work anymore, now that gadgets of invisible
widgets don't allocate space anymore.
Add a gtk_style_context_to_string function that can serialize
a CSS node or tree of nodes, optionally including CSS properties
as well.
This will be useful in writing tests.
It turns out we don't really need to use a separate gadget for the
infobar, if all we do is chaining up to the parent GtkBox which already
uses a gadget.
Just remove all the boilerplate.
The notion of a separator being wide or not does not make sense when a
theme can set any CSS property on it, and
separator-width/separator-height are on their way out for
min-width/min-height.
Instead, just rely on the CSS gadget; we can stop using wide-separators,
separator-height and separator-width, and at the same time deprecate the
space-size style property of GtkToolbar.
67ab00e01e removed the fake configure code in gtk_window_show() and
replaced it with a simple gtk_widget_realize(). The initial allocation
code in realize() only allocates the natural size or the last requested
size which now no longer is set, resulting in a too small first allocation.
This builds a configure request to compute the allocation size instead
which includes default size, CSD etc..
This problem could be seen in case of a GtkPaned in a GtkWindow with a
default size set and the pane position set as well. The first allocation
would be the natural size of the GtkPaned which would clamp the pane
position if too larg. Only the second allocation would fill the parent
window using the now wrong pane position.
https://bugzilla.gnome.org/show_bug.cgi?id=759705
In that case, code expects an arrow gadget to be present but we're not
creating it in every occurrence.
Fix it by ensuring there will be an arrow gadget when reserve_indicator
is TRUE.
GtkViewport currently tries to draw a background over the bin window.
The feature is a bit broken at the moment, as it does not take into
account padding that might have been set on the GtkViewport, but in
general it does not seem very useful, and goes somewhat against the CSS
box model where every widget/gadget is responsible to draw its own
background. For a fix, we could either have the viewport gain a "bin"
gadget, or we could stop drawing the background.
As it isn't clear that there are any users of this feature, stop drawing
the background; a client can achieve the same effect by drawing the
background on the widget inside the viewport itself.
