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"
- many moons and some iterations later, these are the suggested
general typographic styles. Already being referenced in apps like
Banner Viewer (for now shipping custom definitions)
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1808
Touchpad gestures have only a single event sequence. The current
'center' of the gesture is the starting point + accumulated deltas.
Update gtk_gesture_get_bounding_box_center() accordingly.
When we have a default action set on the infobar, activate it
for clicks anywhere in the infobar. Also add an .action style
class in this case, so we can add a hover highlight to the infobar
just for this case.
When a remote instance of a GTK application implementing the Startup
Notification protocol gets spawned it will pass the startup sequence
ID as "platform data" to the main instance. Thus, we need to make sure
that the startup sequence gets completed in that case, since the remote
instance won't do it by itself, since it won't map any top level window.
Checking for this "platform data" in the implementation of the after_emit()
virtual method in the primary instance should be a good place to do so, since
the existence of such data proves that a remote instance has been spawned.
https://gitlab.gnome.org/GNOME/gtk/issues/1084
The problem is caused by gtk_im_multicontext_set_slave(), which forgets
to disconnect these signal handlers:
* gtk_im_multicontext_retrieve_surrounding_cb
* gtk_im_multicontext_delete_surrounding_cb
If slave GtkImContext emits signal after GtkIMMulticontext context is
destroyed, this leads to reading freed memory, sometimes causing a crash.
Fixes: #2365
Always insist on at least 1px, even if the thumbnail we're turning into
an icon was 256 * 3 and should be scaled to 32 * 3/8.
(cherry picked from commit 6769db160d)
It's currently used only to not include the insert emoji option in the
context menu, but it's still possible to show the emoji chooser in both
GtkEntry and GtkTextView using the key bindings.
See also https://bugs.webkit.org/show_bug.cgi?id=205609.
On touchpads gtk_gesture_get_sequences() was called without a
corresponding g_list_free(). The same was true for touchscreens
if due to some reason only a single sequence was found.
priv->is_switch is used to get hint if the gesture happened
on the switch. On touch devices, ::enter-notify-event may
not be emitted, and so priv->is_switch may not be set.
Let it be set when ::pressed gesture is emitted so that
the switch is toggled when the gesture occurs regardless
of whether a pointing device is present or not.
The new_with_model() method is a constructor, and it returns a GtkTreeModelSort
instance, even if the C API returns a GtkTreeModel for the convenience of C
developers.
Fixes: #1077
Decoration node for drawing is used only for client side decorated
windows, but corners from opaque region is subtracted also for
normal windows.
Rename function to better reflect what it does and do not subtract
corners if decoration node was not used for drawing.
Directly coloring labels can create a lot of unintended behaviors.
Unfortunately we can't avoid directly coloring `label:disabled` because
it can be used individually. This, however, tries to inherit color from
the parent element of labels wherever possible.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1643
This removes the remaining cases in 6f6070b5 by replacing them with a
simple placeholder selector.
`%button.flat.suggested-action` has been replaced by
`%selection_mode_button_flat`, because it's difficult to replace the
compound selector with a simple placeholder selector, and it doesn't
seem like a proper selector for `.selection-mode button.titlebutton` to
inherit.
The CSSs were generated with libsass 3.5.5 to minimize the git diff, but
I've confirmed that no warning happned with libsass 3.6.3 anymore.
See https://gitlab.gnome.org/GNOME/gtk/issues/2237
The bug was introduced in commit:
9b7640b8 by Benjamin Otte, 2012-03-26 17:24:02
styleproperty: Make _gtk_style_property_parse_value() return a CssValue
In that commit, `values` changed from `GValue*` to `GtkCssValue**`,
but one `!G_IS_VALUE (&values[8])` was left untouched. As a result,
if `border` shorthand contains anything after color, it might crash,
depending on memory layout.
New test included.
Fixes: #751
Unlike what commit d01ea18dc3 says, X11 is
not a requirement for Wayland, so a Wayland-only build is possible. We
just use the same logic as other non-X11 platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=784615
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
(cherry picked from commit f431e28ce3)
They are no longer supported by sass and broken with libsass 3.6.3
(https://github.com/sass/libsass/issues/3033)
This removes some of them by replacing them with a placeholder selector.
This at least brings the resulting CSS size down a bit so gtk can be build
again.
The remaining cases I don't know how to convert because I haven't found a way to
reproduce the old output.
The CSS was generated with libsass 3.5.5.
See #2237
preventing conversion attempt and timer being started on broadway
backend.
first iteration for #1630
Author: Fredy Paquet <fredy@opag.ch>
Signed-off-by: Aurélien Pupier <apupier@redhat.com>
Instead, use the standard library().
This is a meson best practice.
Fixes#2248.
Fixes -Ddefault_library=static not having any effect.
Cherry-Picked-From: bb9c07d8fe
We cannot create similar surfaces that are smaller than 1x1 on X11, so
we should always ensure that we clamp the surface size to 1x1 when
calling gdk_window_create_similar_surface().
Fixes: #2226
The new check/radio style increased their specificity, but it was not
synchronized in the menu styling.
This commit increases the specificity to match the updated check/radio
styling.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/2096
