As general rule, all buttons that launch a menu should
not grab focus on click, because otherwise when the menu
is closed the focus goes back to the button instead of
the previously focused widget, which is the one the user
was interacting with.
GtkScaleButton and GtkVolumeButton set focus-on-click
to FALSE for this same reason.
Fixes#2557
As general rule, all buttons that launch a menu should
not grab focus on click, because otherwise when the menu
is closed the focus goes back to the button instead of
the previously focused widget, which is the one the user
was interacting with.
So this is also the case for the 'New Folder' button on
the filechooser.
Fixes#2557
If we have never seen a GtkTextTag in the GtkTextTagTable with the
invisible bit set, then we do not need to go through the process of
checking the accumulated tags.
Not using invisible tags is overwhelmingly the common case.
The 'selection-changed' signal is emitted unconditionally, even in the case
when there is no selection to be cleared. As a result, the subscriber receives
the initial signal and if he calls gtk_file_chooser_get_uri(), no value is
currently selected.
This might happen for slow filesystems where a fast-content-type might
be provided instead. Don't try to manipulate that content_type if it's
NULL, otherwise we'll either throw warnings (at best) or crash (at
worse).
.osd suggests a particular color/background/hover style, while .circular
only suggests roundness. So for buttons that use both classes, make sure
the former takes precedence with regard to background/hover.
We want expander arrows to be vertically centered in their row, so we
pass the cell area's height to the renderer.
However, if the cell area's height is an odd number while the
"expander-size" style property is an even number, or vice versa, the
arrow will be centered in a half pixel, and fuzzily rendered.
So, round the render height to the same parity as the expander-size.
(This is not necessary for the arrow width because it's assumed equal
to the "expander-size" style-property.)
An expander arrows's render width is supposed to be derived from the
"expander-size" style property.
However, we are actually rendering it for a width equal to
expander-size + 1. This results in ugly blurry rendering.
There is a comment justifying this "+ 1", which has been there for
almost 2 decades. But the justification doesn't seem to apply to
the current code, so the original motivation is likely obsolete.
Let's remove this "+ 1" to render the arrow to a width exactly equal
to the "expander-size" style property.
This reverts commit d6a29e1b8c.
It fixed blurry rendering of expander arrows.
However, it also introduced a regression in that the arrows are no
longer vertically centered if rows are taller than twice the
expander-size style property.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1464
Call gtk_widget_set_allocation after chaining up to parent class
to ensure that GtkInfoBar has correct allocation. Otherwise x and y
is set to zero causing wrong window position in gtk_info_bar_realize.
This fixes info-bar-message-types.ui reftest.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/1428
Epiphany is doing something weird after calling gtk_window_close(),
because by the time the callback executes, the window has no GdkWindow.
Frankly, I don't know what's happening there, but we should probably not
crash.
Fixes#2424
link target uses `$selected_bg_color` and `$selected_fg_color` for the
definition of some selectors (e.g. selected).
While `$link_color` and `$link_visited_color` are based on
`$selected_bg_color`, this does not seem coherent.
Replacing `$selected_*g_color` in link target style with link colors
defined in `_colors.scss file`.
GTK caches the settings per display in a static `GArray`, keeping a
reference to the `GdkDisplay` as the key.
However, when closing the display, the corresponding entry is not
removed from the cache in `GtkSettings`.
So when reopening again a `GdkDisplay`, if the new address matches one
of the previously closed display, the cache will return the existing
`GtkSettings` from the cache, which still holds a reference to the old
`GdkScreen` which was freed along the `GdkDisplay`.
To avoid the issue, make sure to remove the `GdkDisplay` and
corresponding `GdkSettings` when closing the `GdkDisplay`.
Also, care must be taken not to recreate the `GdkSettings` and re-add
the `GdkDisplay` to the cache once the display is closed, and make sure
callers of `gtk_settings_get_for_display()` can deal with a returned
value being `NULL` if the display is closed.
Fixes: commit 360a3c1690 - "Use a cheaper way to store settings per
display"
