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>
With some GL drivers, it may be the case that menus are not shown
correctly in fullscreen GL windows because DWM is deactivated in the
process.
Force WS_BORDER to be applied to the fullscreen GL window so that we have
a small 1px border when needed (by setting an envvar), so that DWM does
not get deactivated, hence enabling the menus to show. Also, when we
force WS_BORDER to be applied in this situation, we also deliberately
place the window just outside the top lefthand corner of the screen by
1px and make the window 1px larger than the screen size, so that we
effectively hide the 1px border from view.
Fixes issue #1702.
We need to mark the prototypes in the headers so that they get exported
properly from the reftest DLLs that we build, so that the reftest DLLs
and program will link properly. Include gtk-reftest.h in
reftest-snapshot.c so that the compiler picks up the export directives
as needed.
_gdk_win32_display_convert_selection() does not return anything,
it generates a selection notify event instead. Depending on how
successful it was, the event will have property=GDK_NONE or
property="GDK_SELECTION".
property="GDK_SELECTION" is the default return value for successful
cases, and it tells GTK to grab the data that GDK previously deposited
using selection_property_store().
The problem is that the clipboard branch of this function calls
open_clipboard_timeout(), which can't return anything meaningful (it's
normally a timeout function), and thus doesn't know whether the function
succeeded or failed. Due to my oversight, this resulted in GDK
generating two selection notification events - one from inside of
open_clipboard_timeout() (with the right property, if successful),
and one from the catch-all last line (always defaulting to "GDK_SELECTION").
This caused issue #2223, where GTK only expected exactly one
notification per request, and got confused because it was getting two.
I've looked at the code in open_clipboard_timeout(), and it seems to me
that it always generates a notification (a successful one or an
unsuccessful one). Thus the branch of the function that calls it
directly does not need to follow up with a catch-all notification and
can just return.
This seems to be fixing issue #2223, at least for me, but i'm not
entirely sure that this will not have any adverse side-effects.
Clipboard handling in GTK3 is a complicated mess.
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
The XIM input method can some times go into weird states, especially
when extended devices or in mixed environments with multiple input
methods installed.
Ideally, people should simply stop using XIM, which is utterly broken,
and use IBus instead; nevertheless, crashing is not nice.
Fixes: #61Fixes: #518
In the Vietnamese Quoted-Readable input method, punctuation following a
base letter is converted into diacritical marks, for example a( → ă.
(See <https://en.wikipedia.org/wiki/Vietnamese_Quoted-Readable>.)
A 2008 bug report in Ubuntu argued that this is a problematic default,
particularly when typing passwords, where the effect of the punctuation
is non-obvious.
According to the bug reporter, VIQR is popular with Vietnamese users
living elsewhere in the world, where Vietnamese keyboards are unlikely
to be readily available, but is not a popular choice within Vietnam,
where the Telex or VNI input modes are preferred.
Closes: #183
Bug-Debian: https://bugs.debian.org/895043
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/191451
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
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
Enabling one backend (Broadway, in commit 1882ff9b) implicitly disabled
all the others, which was probably not intentional. Bring the Autotools
build into line with Meson.
Signed-off-by: Simon McVittie <smcv@debian.org>
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
I couldn't get all reftests to work reliably, so the tests failing
on either CI or on my machine are skipped for now.
Installed tests are disabled by default and can be enabled with "-Dinstalled_tests=true"