Previously, with STATE_FLAGS_REPLACE we would unset _all_ the state
flags on children, not just the ones that do propagate. This caused the
RTL/LTR flags to get lost.
We add a separate gtk-a11y.h single-include header for
them. This header will work much the same as gtkx.h. It
will be installed in /usr/include/gtk-3.0/gtk, but you
have to include it separately.
Since we are going to install these headers soon, we need
to make their mutual includes work in the installed location
as well. Also, avoid including individual gtk headers, to
avoid trouble with single-include guards.
This commit exposes the get_type() functions and standard
headers for accessible implementations. This makes it possible
to derive from the GTK accessible implementations without
GType magic tricks. This is necessary, because we require the
a11y type hierarchy to be parallel to the widget type hierarchy.
So, if you derive a widget and need to adjust its a11y implementation,
you have to be able to derive its accessible implementation.
This commit probably exposes more than is absolutely necessary,
it also exposes accessibles of widgets that are unlikely candidates
for deriving from.
Since not every theme renders a background for a GtkViewport (and
Adwaita master doesn't), ensure the grid+viewport we use to emulate a
text view here uses the "view" style class.
It already paints the css border, so let's make it also honor css
background. This is needed to have a box of a different color around
some widgets (e.g. latest gnome-clocks design)
If you want to get rounded corners on an hbox, instead of
:first-child {
border-top-left-radius: 5px;
border-bottom-left-radius: 5px;
}
:last-child {
border-top-right-radius: 5px;
border-bottom-right-radius: 5px;
}
you now need to write:
:first-child, :last-child:dir(rtl) {
border-top-left-radius: 5px;
border-bottom-left-radius: 5px;
}
:last-child, :first-child:dir(rtl)
{
border-top-right-radius: 5px;
border-bottom-right-radius: 5px;
}
If you want to get rounded corners on an hbox, instead of
:first-child {
border-top-left-radius: 5px;
border-bottom-left-radius: 5px;
}
:last-child {
border-top-right-radius: 5px;
border-bottom-right-radius: 5px;
}
you now need to write:
:first-child, :last-child:dir(rtl) {
border-top-left-radius: 5px;
border-bottom-left-radius: 5px;
}
:last-child, :first-child:dir(rtl)
{
border-top-right-radius: 5px;
border-bottom-right-radius: 5px;
}
If you want to get rounded corners on an hbox, instead of
:first-child {
border-top-left-radius: 5px;
border-bottom-left-radius: 5px;
}
:last-child {
border-top-right-radius: 5px;
border-bottom-right-radius: 5px;
}
you now need to write:
:first-child, :last-child:dir(rtl) {
border-top-left-radius: 5px;
border-bottom-left-radius: 5px;
}
:last-child, :first-child:dir(rtl) {
border-top-right-radius: 5px;
border-bottom-right-radius: 5px;
}
This function is just a sophisitcated optimization.
If we know the GDK window's background will be opaque, we mark it as
opaque. This is so GDK can do all the optimizations it does for opaque
windows and be fast.
This is mainly used when scrolling.
The previous code didn't get this right, in particular it didn't enforce
a transparent background when it knew the background was not opaque.
The code path where we update the tooltip text property doesn't set
the state and value variables, and so doesn't need to call
notify_state_change().
Return early, and move the if block at the beginning of the function for
clarity.
There are some registred stock ids like gtk-discards that have no icons,
and you could also pass a non-registred stock id. Both of these means
gtk_style_context_lookup_icon_set returns NULL, which causes
a critical in gtk_icon_set_render_icon_pixbuf.
We avoid this by just making these render as EMPTY.
We used to use GTK_RESIZE_QUEUE, but that is problematic for e.g
a GtkScrolledWindow with NEVER scroll policies, as size changes
in ancestors will never get propagated to the scrolled window, causing
it to not have the correct size.
This is a slight performance hit, but in practice its not bound to be
problematic. In typical UIs there is only a single "large" GtkScrolledWindow
visible at a time, so a size requeust propagating out of such a window
will only hit the smaller amount of widgetry outside the scrolled window,
and additionally all such widgets will have their size request caches
still valid.
https://bugzilla.gnome.org/show_bug.cgi?id=690099
We don't get an automatic queue resize on realize anymore, which
was papering over this bug where we did not set the child window
size/position at realize time.
We use the new g_type_get_type_registration_serial() so that we can
cache and properly invalidate the result of g_type_from_name().
This bumps the glib requirement to 2.35.3 to get the new function.
https://bugzilla.gnome.org/show_bug.cgi?id=689847
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.
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.
