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.
https://bugzilla.gnome.org/show_bug.cgi?id=689584
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 4a8df7a33c)
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.
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.
https://bugzilla.gnome.org/show_bug.cgi?id=340066
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.
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.
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.
Fixes the fontchooser preview not updating.
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.
https://bugzilla.gnome.org/show_bug.cgi?id=680065
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.
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.
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.
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.
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.
https://bugzilla.gnome.org/show_bug.cgi?id=689081
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.
https://bugzilla.gnome.org/show_bug.cgi?id=689081
This was broken since commit b2aaa94 in 2008. Its commit message
clearly states that the intention was to check for GTK_GRAB,
GTK_UNGRAB and STATE_CHANGED. Lets do that, then.
This was found by Coverity.
... so we don't bump a refcount whenever we get the initial singleton.
We want to use this function instead of
_gtk_css_style_property_get_initial_value() everywhere where we compute
values, because some initial values may depend on settings soon.
Resizes are queued via
gtk_widget_propagate_state()
=> gtk_style_context_set_state()
=> gtk_style_context_queue_invalidate()
=> gtk_style_context_validate()
=> _gtk_widget_style_context_invalidated()
so there's no need to queue an extra one.
Symbolic colors are an implementation detail of the CSS engine and have
been superceded by GtkCssColorValue. We don't want them clobbering the
public API. In particular because the only use I could find in the
public API is people using it to shade colors.
Make _gtk_style_provider_private_get_color() return a GtkCssValue (a
GtkCssColorValue to be exact) instead of GtkSymbolicColor.
With this, the symbolic color usage inside GTK is minimized.
The documentation for gtk_file_chooser_get_filenames() states that the
returned filenames are absolute paths, and uses g_file_get_path() to
construct the filename. The same function is used to construct the
filename in gtk_file_chooser_get_filename(), so it should also return
absolute paths.
https://bugzilla.gnome.org/show_bug.cgi?id=371034
When event capturing is enabled, stop propagating scroll events
at insensitive widgets, but don't handle them (don't return TRUE),
so they can bubble up again and reach their handling widgets.
Render a background with gtk_render_background() in draw() instead.
Note that we still use gtk_style_context_set_background() for the header
window.
https://bugzilla.gnome.org/show_bug.cgi?id=688744
This reverts the size_allocate removal from commit
8449e05865. That code was using
_gtk_window_set_allocation() instead of gtk_widget_set_allocation(). And
that broke glade.
We can set for_size to -1 earlier than we did. Doing so makes sure we
only cache one value (as we should in the first place). In GTK 3.6, this
worked properly, but with Previously, this check was moved further up to
avoid interacting with size groups. But after recent refactorings, size
groups are handled way earlier anyway.
... instead of GtkSizeGroupMode. Orientation is what we're interested in
after all. When we need a GtkSizeGroupMode, we can do the translation
where we need it.
Application code can set shortcut folders that are already bookmarks.
This code causes the bookmarks to be refreshed after the shortcut is
added removing any possible bookmark duplicates
https://bugzilla.gnome.org/show_bug.cgi?id=577806
Expose GtkEntry icons as child accessibles of a GtkEntry, and provide
actions to simulate clicking them. Also, refactor the a11y children test
slightly to add a test.
https://bugzilla.gnome.org/show_bug.cgi?id=686347
