css: Do get_change directly on the tree without matching first
Rather than first collecting matches and then getting the change
for them we do the change collection directly on the tree. This
is about twice as fast.
Colin Walters [Fri, 7 Dec 2012 19:05:58 +0000 (14:05 -0500)]
Fix build by un-translating org.gtk.Settings.FileChooser
At the moment, gtk+ doesn't depend on intltool, which is the program
that knows how to translate schemas. Attempting to translate them
causes a build failure, so for now, let's leave them in en_US.
quartz: fix crash in the recent clipboard "fix", and really fix it
We must not release the GtkClipboardOwner in pasteboardChangedOwner
becaue we don't own a reference to ourselves (NSPasteboard does).
Instead, release the owner right after setting it, transferring
ownership to NSPasteboard
Also, fix repeated setting of the same owner by keeping the
owner around in GtkCLipboard, and re-use it if "user_data"
doesn't change. To avoid clipboard_unset()ting our own contents
in the process, add an ugly "setting_same_owner" boolean to
GtkClipboardOwner, set it during re-setting the same owner,
and avoid calling clipboard_unset() from pasteboardChangedOwner
if it's TRUE.
(cherry picked from commit 4a8df7a33c298d22bf78b947d0e861fc03ec70e1)
treeview: Don't invalidate whole tree unless needed
We currently invalidate the whole tree every time the style state
changes in the tree view. The primary reason for this is to catch
default font changes as that may affect text cell renderers. But
cell renderers could *potentially* also read other style properties
(although that seems weird and unlikely).
We handle this by invalidating only when some state that affects sizes
is changed. This includes all the font properties.
With pango handling changes to the PangoLayout there now is no
style changes that can affect the layout for the entry, so we don't
have to reset the layout whenever the style is updated.
GtkLabel: Rely on the new pango support for context change tracking
Now that Pango tracks changes to the context automatically there is
no need to do it manually in e.g. style-updated or direction-changed,
in fact the only case we have to care about is when we re-create
the PangoContext due to a screen change, so we only have to clear
the layouts in GtkLabel in screen-changed.
This means we're not clearing all the layouts whenever the state changes,
which happens to every widget when the window is unfocused, which helps
performance a lot.
Require new pango with automatic tracking of PangoContext changes
Pango 1.32.4 has a feature where any PangoLayout automatically handles
the case where a PangoContext is changed. We want to rely on this to
avoid having to clear layouts too often, so we make this a hard dep.
This is for a very simple reason: The getter is returning a const value
and the font isn't const anymore. So we need to store the font
description somewhere but we can't reuse it as it's changing all the
time (yay animations, yay inherited values). Sucks.
So keep the hack in here but deprecate the function.
Benjamin Otte [Thu, 6 Dec 2012 01:47:24 +0000 (02:47 +0100)]
gtk: Use context's font
Instead of using gtk_style_context_get_font() in
pango_context_get_metrics(), use pango_context_get_font_description().
The context contains the font description we are about to use after all.
Benjamin Otte [Wed, 5 Dec 2012 17:41:40 +0000 (18:41 +0100)]
stylecontext: Always recompute font
This is necessary because values in a GtkCssComputedValues can change
now. So if the font-size is inherited or animated, the cached value will
be outdated.
treemodelfilter: Make the constructor binding friendly
This means reffing the root in the set property implementation,
rather than in the constructor. We don't need to unref the root
on set, as it's a CONSTRUCT_ONLY property.
Don't unnecessarily queue resize in GtkWindow.style_updated
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.
Don't queue resize for hidden widgets without a size group
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.
css: Avoid allocations in gtk_css_value_array_compute
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.
css: Use internal return_if_fail in some commonly called code
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.
Marek Kasik [Tue, 4 Dec 2012 14:48:08 +0000 (15:48 +0100)]
printing: Call mark_printer_active() with correct parameters
Revert the second part of the commit 6ad6f719c6b2fc7cf797c86b406f4e61d9fca4d1. mark_printer_active()
was called without its second parameter in g_list_free_full().
Bug 626499 - GtkClipboard unnotified on change of OS X pasteboard owner
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 f2b74db5dcbd28a1e27431f413c66d2a5d50b2bd)
Benjamin Otte [Sat, 1 Dec 2012 00:49:06 +0000 (01:49 +0100)]
css: Move default font handling
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.
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.
css: Don't reorder some selectors when building selector tree
When building the tree we generally reorder the selectors inside
the same simple selector in order to pick a good first selector
to balance the tree better. However, some kinds of selectors
can't really be reordered, even thought they are simple.
This is since the matching code for some types handle
the existance of a directly preceeding selector differently:
REGION and ANY selectors look for a DESCENDANT previous
POSITION selector look for a REGION previous
From a set of GtkCssSelectors and the rulesets they match to
we create a large decision tree that lets us efficitently match
against all the rules and return the set of matched rulesets.
The tree is created such that at each level we pick the initial rule[1]
in all the considered selectors for that level and use put the
one that is in most selectors in the node. All selectors matching that
are put in the previous part of the tree.
This returns true if the matcher matches *anything*. We need
to check this later, because such matchers are dangerous in loops
that iterate over all parents/siblings since such loops would not
terminate.
With the previous commit all loads of the same icon will share a single
GtkIconInfo, which typicallty means the pixbuf is shared via Info->pixbuf.
However, atm we don't share symbolic icons, which causes these to be re-read
and re-parsed every time. This is especially bad if the icon is used many times
in some form of list. So, we cache the pixbufs and reuse them.
In order to avoid loading and keeping around the same icon multiple times
we keep a cache of all outstanding GtkIconInfo objects for a given theme.
Additionally we return to the app not the normal pixbuf from the info,
but rather a proxy copy of it sharing the same data, but no extra
reference. This allows us to track when the app is no longer using
the pixbuf, and we can thus ensure that the GtkIconInfo in the cache
stays around for at least as long as the pixbuf is alive.
When the app unrefs the pixbuf we put the Info on a short LRU list
to keep it alive a bit longer, in case the app needs it in a short
while.
projects / ~andy / gtk / log