queue_resize basically tells the parent widget that it may need
to pick a different size/layout. However, for a hidden child widget
that should never be needed. It may be that the widget is in a
sizegroup that has ignore_hidden == FALSE though, so it may
affect the size group calculations.
However, if a widget is not visible and not in a size group then
its safe to avoid the resize, as the widget will be resized on
becoming visible anyway.
This avoids a lot of size allocation for hidden things like menus
and tooltips.
GtkWindow always queues a resize on style updates if there is
a grip, because it may have been the grip size style properties
that changed. However, even if it *were*, and it likely wasn't
that would not affect the windows size request, so no need
to queue a resize.
For almost all properties the initial value does not need computing.
If we skip computing these then gtk_css_value_initial_compute goes
from > 6% to 2% in my testcase profiles.
This returns TRUE for all css values that always compute to themselves
and thus does not need computation. This is useful for the initial
values as these are static and we can avoid computing them in a lot of
cases.
Almost all array computations lead to no changes (99% in nautilus)
so we avoid the upfront allocation and delay it until we know its
needed. This drops the allocate/free from the profile.
These are internal apis, and any external issues should have been
caught by checks at public API points. We use the internal checks
here because these checks show up in a non-neglible way on profiles.
pasteboardChangedOwner is not called as reliably as we'd want to get it,
so keep track of [pasteboard changeCount] and drop clipboard ownership
when a change happened. Also better unset the clipboard content redundantly
in a few places rather than missing one, and reorder the code in
gtk_clipboard_set_contents() so that the new aggressive unsetting
won't unset the clipboard under our feet when we call
[pasteboard declareTypes].
(cherry picked from commit f2b74db5dc)
We now support the keywords (like xx-small, medium, larger, smaller...)
and I've changed the default value to be "medium".
This required some shuffling of the "get default font size" code. But
all is well now.
The default font is no longer handled like a custom style sheet that
overrides everything, but as the initial value. This is the same
behavior as in web browsers.
And it allows the theme to actually use the 'font-family' and
'font-size' properties. Of course, a well behaved theme will respect the
setting as much as possible and for example use relative font sizes
(which aren't yet supported, but will be soon).
This gives a GtkSettings object for resolving system-dependant things -
like the default font family and font size.
No code does this yet, but we have an API.
Only GtkSettings implements this.
The new css tree may change the order of selectors (keeping the
same semantics). This affects how the selectors are printed later,
which causes some css parsing tests to not match the references.
Fortunately the order is consistent between runs given the same
css, so we just have to switch around the order in some of the
.ref.css files.
Now we use the selector tree everywhere, so there is no need to
keep around the linear selectors unless we're using them to
verify the tree correctness, so free them.
We add some "artificial" ordering to the otherwise unordered
tree nodes. This means the tree will be the same every time for the
same input. This is good because e.g. tree order affects the
reordering of the simple selectors, which may affect how
css providers are printed, which need to be consistent for
the css tests to work.
