including when the control modifier is present, i.e. when one is typing
control-I for instance.
Orca would convert them back to the corresponding ASCII letter anyway, and
when pressing control-tab, we do want to pass "tab", not pass "\t" that Orca
would erroneously convert to "control-I".
Fixes#1743
(cherry picked from commit 728f6869cb)
This updates the introspection build process that we also check on
changes in the Makefiles when we generate the NMake Makefile snippets
and file lists, so that any changes to the source file list can be
reflected. Also ensure that we build against the freshly-built
libraries.
Make the NMake Makefiles also output the built introspection items to
the output directories of the various Visual Studio versions, according
to the build configuration and architecture, so that we avoid confusion
for different Visual Studio build configs.
In GLib-2.57.3 and later, GStatBuf may not be a struct stat on Windows,
depending on the architecture and the compiler used, so we can't just
call fstat() on the GStatBuf.
Instead, we need to use the correct CRT function to call on the
GStatBuf, which is as follows:
-_fstat32() for Windows 32-bit builds on mingw-w64 and MSVC
-_fstat64() for Windows 64-bit builds on mingw-w64
-stat() for Windows 64-bit builds on MSVC, and on all other platforms.
We are not passing in the correct architecture to the script that we use
to generate the pkg-config files for Release/x86 builds and Debug/x64
builds. Fix this.
Just link to Cairo instead of looking for the Cairo .pc file as the
Cairo build system for Visual Studio currently does not generate a
pkg-config file for us. This will eliminate the need to hand-craft a
pkg-config file for Cairo to be able to use the pkg-config files that we
generate here.
Don't pass in G_LOG_DOMAIN=\"...\" to the CFlags that is passed into the
generation the NMake Makefiles. This will avoid the introspection scanner
from choking because the resulting NMake Makefiles may not have that
CFlag escaped properly, and it is not really needed for building the
introspection binary.
Replace "stat struct" with "GStatBuf" and "stat" with "g_stat" where
appropriate to fix cross-platform issues, specifically on Windows.
Code should be identical on *nix but fixes some serious issues
on Windows:
- Field widths of "struct stat" are not constant on Windows.
If the stat function does not match the stat struct used
it will cause overwrites and undefined behavior
- The Windows stat function needs a properly encoded filename.
In many places we pass an UTF-8 encoded value which breaks as soon
as non-ASCII characters are involved.
https://bugzilla.gnome.org/show_bug.cgi?id=787772
If the name of the bookmark is NULL, using it with the printf %s format
specifier is undefined behaviour per the C Standard. Besides, it would
result in a completely unhelpful tooltip even if it were well-defined.
We already have an else case for when nothing is selected, which avoids
trying to use the name, so ensure we go there if it's NULL or empty too.
https://gitlab.gnome.org/GNOME/gtk/issues/1169
In 01455399e8 ("gdk: do not deactivate surface on keyboard grabs"), we
made gdk avoid deactivating surfaces when another application takes a
keyboard grab, by using has_focus_window instead of has_focus. That however
broke activating surfaces when the gdk application acquired a grab itself,
in which case has_focus_window is false but has_focus is true.
We thus actually need to use both: surfaces should be activated either
because we have normal keyboard focus, or because we grabbed the keyboard.
This also renames HAS_FOCUS to APPEARS_FOCUSED to better reflect its
role.
Fixes#85
(cherry picked from commit 3287ac96e02ff236d74db10164c5b0c1e7b2b0bf)
(cherry picked from commit 039285deb92b6baf6ef594b0d718e8f7a7e1d0ac)
In case something happens between monitor counting and monitor
enumeration, repeat until the count matches up.
enum_monitor is changed to ignore any monitors past _gdk_num_monitors
and just keep increasing the count past that number.
GCC 8.1 added some new warnings, including warning about parentheses
with no effect in variable declarations. GTK2 headers have a few of
these, which produce a lot of warnings in projects using GTK2.
The warnings look like:
/usr/include/gtk-2.0/gtk/gtkfilechooserbutton.h:59:8: warning:
unnecessary parentheses in declaration of ‘__gtk_reserved1’ [-Wparentheses]
void (*__gtk_reserved1);
^
Removing the parentheses is harmless and fixes the warnings.
When we found an icon with exactly the requested size, we'd stop
searching immediately (good), but we'd neglect to set the returned
min_difference to 0 (bad). This caused theme_lookup_icon() to
prefer other, potentially much worse, matches over the exact one.
Cherry-picked from 5aa939dc (gtk-3-22)
https://bugzilla.gnome.org/show_bug.cgi?id=792738
When pressing e.g. a window manager shortcut, which acquires keyboard grab,
Xorg would send FocusOut NotifyGrab then FocusIn NotifyUngrab. Currently
gdk would then deactivate the current surface, which makes accessibility
screen readers think that we have switched to a non-accessible application
and came back again, and thus reannounce the application frame etc. which we
don't want when e.g. just raising volume.
And actually, receiving FocusOut NotifyGrab does not mean losing the
X focus, it only means an application aqcuired a grab, i.e. it is
temporarily stealing keyboard events. On Wayland, this isn't even
notified actually.
This commit makes gdk only deactivate surfaces when there was an actual
focus switch to another window, as determined by has_focus_window (instead
of just has_focus), which happens either normally through FocusOut with
NotifyNormal, or during grabs through FocusOut with NotifyWhileGrabbed.
Fixes#85
(cherry picked from commit 01455399e8)
When a project has a bundled copy of our macro included in tarball
source releases, typically in a m4/ or aclocal/ directory, aclocal
uses the serial number to determine whether the system copy in
/usr/share/aclocal is newer or older than the bundled copy. Without
a serial number, the bundled copy will always be used and will not
be overwritten, even if it is outdated.
Signed-off-by: Simon McVittie <smcv@debian.org>
glib-2.54.3 changed API, compared to glib-2.52.3 and gtk+-2.24.31's
expectations. This commit fixes the resulting issue in a backwards
compatible way.
See-Also: https://bugs.gentoo.org/650536
The GLib main loop blocks on MsgWaitForMultipleObjectsEx to
determine if there are any incoming messages while also allowing
for background tasks to run. If all available messages are not
processed after MsgWaitForMultipleObjectsEx has signaled that
there are available, CPU usage will skyrocket.
From my limited understanding (by inspection of profiling
under Visual Studio):
Key is pressed - MsgWaitForMultipleObjectsEx unblocks, and
sends message to GDK's event handler. Some event is now queued.
g_poll unblocks, calls the g_event_dispatch which finally
resolves to gdk_event_dispatch. This then calls
_gdk_win32_display_queue_events, but since a message is already
queued, it fails to call PeekMessage and returns immediately.
At the next iteration, g_poll again calls MsgWaitForMultipleObjectsEx
which queues yet another event and returns almost immediately, since
there are events available which haven't been processed by PeekMessage.
The dispatch function is then called and the process repeats.
https://bugzilla.gnome.org/show_bug.cgi?id=771568
Due to the recent changes introduced in glibc 2.27 "%OB" is the
correct format to obtain a month name as used in the calendar
header. The same rule has been working in BSD family (including
OS X) since 1990s. This simple hack checks whether "%OB" is supported
at runtime and uses it if it is, falls back to the old "%B" otherwise.
Closes: #9
