In order to eliminate g_test_expect_message() (which doesn’t work with
G_LOG_USE_STRUCTURED), make the warning about the fallback theme not
existing be conditional on the icon theme search path containing a
system path. Any application code which modifies the search path does so
through appends and prepends, so this should not affect whether the
warning is emitted in production.
https://bugzilla.gnome.org/show_bug.cgi?id=769485
:toggled is triggered on :clicked, so using :toggled lead to the menu
to be popped up at the same time, while allowing to use the toggle state
and avoiding any need to a hack to prevent recursion, which somehow
wasn't enough for double emission of GtkMenuToolButton:show-popup.
https://bugzilla.gnome.org/show_bug.cgi?id=769287
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
This changes the group/level semantic.
Previously W32 backend used "group 0/1" to denote "AltGr OFF/ON"
and "level 0/1" to denote "Shift is OFF/ON".
Now "group" means "keyboard layout" and there can be up to 255 groups,
while AltGr and Shift are combined into a single level enum that
takes values between 0 and 4.
Unlike X, W32 doesn't do effective group overriding, meaning that
it will never tell the caller that a different group was actually
used (even for universal keys, such as Enter), because key symbol
table is completely fabricated and there's no point in trying to
save a few of kilobytes of RAM by not duplicating universal key
records for all groups.
Also contains many whitespace changes (tab elimination, fixed
indentation) and cleanup (axed a few global variables, these are
now accessed via the default keymap).
https://bugzilla.gnome.org/show_bug.cgi?id=768722
GTK+ has two directories for translations: the default 'po' and the
additional 'po-properties' for the GObject properties translation
domain.
Since the content of the translations directories are filled by
autoreconf and gettext, and are duplicated between the two gettext
domains we use, we should handle this ad hoc inside git.mk, instead of
trying to catch up by adding po-properties files in GITIGNOREFILES.
The contents of the macro directory are too complicated for git.mk to
handle: the contents are filled by autotools and may change between
systems or autotools releases; and we additionally ship our own m4
macros.
To avoid unnecessary noise on the `git status` output we should simply
add an ignore file specifically for the macro directory.
The new positioning-related properties had some quality of
implementation issues, such as incorrect initial values and
excessive change notification. This broke the notify test.
It tried to set the expand state if either xexpand/yexpand where true.
Due to a missing queue_compute_expand when adding a child it actually
only computed the expand state in case a child queued after being added
or in case a child had the expand property set (see optimization in
gtk_widget_set_parent)
In my case this broke layouts as a child of GtkCombBox started setting
an exand flag with 3.20 which queued a compute_expand, which in turn
propagated an expand child props set for a cell in the same table up
and overrode the expand child prop of a parent GtkBox.
This removes the custom compute_expand implementation to match the
behaviour of GtkBox (don't propagate child prop expand flags
but let child expand flags override the child props) and not get random
expand behaviour depending on whether and when child widgets set their
expand state.
https://bugzilla.gnome.org/show_bug.cgi?id=769162
gtk+/demos/gtk-demo/css_blendmodes.c: In function ‘update_css_for_blend_mode’:
gtk+/demos/gtk-demo/css_blendmodes.c:49:26: error: format not a string literal, argument types not checked [-Werror=format-nonliteral]
blend_mode);
^~~~~~~~~~
https://bugzilla.gnome.org/show_bug.cgi?id=769236
The error was:
gtk3-scan.c:193: undefined reference to `gtk_shortcuts_label_get_type'
collect2: error: ld returned 1 exit status
It's since commit 7543cd8ce4, which made
the GtkShortcutLabel class public.
Introduce a private API meant for abstracting how to get a handle
of a window that can be shared with other processes. The API is
async, since some implementations will require that. Currently,
only X11 is supported, which doesn't.
Based on a patch by Jonas Adahl.
When there's no useful shortcut accelerator set,
GtkShortcutLabel doesn't show any useful information.
To work around that, add a new property to set the
text to be displayed when there's no accelerator
available.
https://bugzilla.gnome.org/show_bug.cgi?id=769205
GtkShortcutLabel is a widget that displays a single
shortcut accelerator or gesture in the user interface,
and is currently used by the shortcuts window.
This widget, however, has public value as other applications
also may want to expose their own shortcuts. For instance,
it'll be useful for the Keyboard panel on Control Center and
the new shortcut editor in Pitivi, among others.
This patch exposes GtkShortcutLabel as a public widget,
and adds the necessary documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=769205
Scroll history must refer to a timespan for the values to be valid, otherwise
we return FALSE, in this case the stored event(s) should be discarded anyway.
It could be the case that the last scroll event is received long after any
previous scroll event, in this case the last scroll event discards all "old"
scroll events, and scroll_history_finish() returns FALSE because there's no
time/offset deltas in the scroll history.
This is desired so we don't trigger the deceleration effect if there was no
effective velocity, we still must reset the installed scroll cursor, so take
it out of this if() condition.
I thought I needed ot rearrange the ordering of the animation-direction
values for the parser, overlooking the fact that we already parse them
backwards to address this very problem.
It is important to know whether the returned object can or cannot
change, for a certain widget. For example to connect to the
GtkStyleContext::changed signal.
https://bugzilla.gnome.org/show_bug.cgi?id=769047
Always return an error if we fail to get a dbus proxy; the callers
are only looking whether error is set, not whether the return value
is NULL.
Use the same function for the inhibit proxy as well, and clean up
the sm_proxy in finalize.
