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
Putting includes in the second argument of AC_TRY_LINK is not safe. If
a header having inline functions is included inside the main function,
it becomes a nested function. This is not supported by clang.
https://bugzilla.gnome.org/show_bug.cgi?id=792720
We need to notify ATK the description changed when the tooltip text
associated with the widget changes and gail_widget_get_description()
would use it as the description.
https://bugzilla.gnome.org/show_bug.cgi?id=779009
This custom drawing code was broken, which meant the current mode
indicator/character did not show, severely hindering XIM users.
Fix by simply removing the custom drawing and just being a GtkWindow, by
cherry-picking these two from GTK+ 3:
commit 211ccb5c73
commit c750cea4e57ed3bcb5ba7eada95d0be380aa2fe5t
https://bugzilla.gnome.org/show_bug.cgi?id=696624
Ensure that the /DYNAMICBASE linker option (which is actually the
default option) is enabled, as we inadvertly disabled it in our
projects.
Also, for x64 builds on MSVC 2012 or later, use the /HIGHENTROPYVA
linker option to improve the security of the built bianries.
Pointed out by Ignacio Casal Quinteiro.
If the call to set_parent() failed, we were still adding the child to
the internal list of children, despite that it was not really added.
That meant we could later try to do invalid stuff with that non-child.
Fix that by asserting and giving up if the child that the user is
attempting to add is already parented.
https://bugzilla.gnome.org/show_bug.cgi?id=701296
…from priv->button. My refactor to g_signal_disconnect_by_data()
included this widget, when I shouldn’t have as both modes use it.
In GTK+ 3, this broke opening a CB by keyboard that was in menu mode,
if it had been in list mode initially (e.g. due to the theme).
Fix by moving to disconnect_by_func() and only removing in each mode’s
destroy() method the signals that it set on the button in its setup().
https://bugzilla.gnome.org/show_bug.cgi?id=788577
This gives consistent behavior with e.g. Qt, Mozilla's suites and
LibreOffice (with non-truly native backends like "gen" and "gtk",
but unlike "gtk2" and "gtk3" ones that probably use true GTK menus).
This behavior is expected by at least some accessibility users, and
it seems good to behave like other common applications and toolkits
in this area. There should be no issue in doing so either for current
users, as it only enters the submenu instead of not doing anything.
https://bugzilla.gnome.org/show_bug.cgi?id=778811
Ditch two items that were white and so weren’t visible on our standard
theme anyway, and use the new space to test extra grid-mode properties.
Note if we do this then, as before, set the ListStore on the CB before
before appending to it, that (at least in GTK+ 3) gave warnings like:
Gtk-CRITICAL **: gtk_menu_attach: assertion 'left_attach < right_attach' failed
I didn’t look into that yet, but it may indicate that attaching items
vs. recognising their spans don’t occur in the correct order. For the
purposes of testing this, I just create the CB after filling its model.
We need floating-point division… Otherwise, only fully-on inputs can
produce any output. This fixes some of the colours wrongly being black.
While here, remove the unused rowstride variable, to shush a warning.
ComboBox warned in the doc for :row-span-column that the value must not
exceed :wrap-width, but :wrap-width does not interact with the number of
rows; it’s the :column-span-column that’s relevant.
Also: Warn that spans must be > 0 for rows too, & that column spans <=
:wrap-width are also not useful for items at menu column positions > 0.
Rrefer to items having spans, not values, as we’re already talking about
values in the model (& rows in the menu). And clarify :wrap-width a bit.
Various disconnections had the wrong flags and/or data, so we failed to
disconnect a pile of signals, shown by 0 returned by the disconnect_*()
functions. Fix this, and use the nicer disconnect_by_*() while here.
set_transient_for(toplevel) was only called in list_setup(). It was easy
to make a test showing a NULL :transient-for instead of the correct one.
So, move the call from list_setup() to real_popup(). Also do the same
for window_group_add_window(), which means not calling it redundantly.
(I tried using a ComboBox:parent-set handler, but the Inspector’s CB
didn’t like that: it calls popup_for_device() twice and closes on button
release. Anyway, using popup() is much more concise than a new handler.)
The screen for the list-mode popup_window was only being set in
set_popup_widget(), i.e. when changing modes, so if the ComboBox was
moved to a different screen later, the popup would appear on the
original one, which is wrong.
Worse, this broke opening some combos in the Inspector in GTK+ 3.
Fix this by moving the call to set_screen() to real_popup(), so
the popup_window is put on the correct screen each time around.
https://bugzilla.gnome.org/show_bug.cgi?id=468868https://bugzilla.gnome.org/show_bug.cgi?id=786771
Bad actors, such as our very own FileChooserButton, may connect to the
:popped-up property and alter the model as the menu becomes in/visible.
We were getting an iter to the model while popped-up, then doing
popdown(), then using the iter, which may have just been invalidated by
the errant notify::popped-up handler. If so, we quickly crash fatally.
This is clearly bonkers, but until such patterns are removed, we have to
work around them. So, set_active() from the clicked item while it is
known to be valid, by moving the call to set_active() before popdown().
While here, change set_active_iter(iter) to set_active_internal(path) to
avoid pointlessly going through the iter to get the path we already have
https://bugzilla.gnome.org/show_bug.cgi?id=729651
In gtk_container_real_set_focus_child(), we try to scroll to the
position of the new :focus-child if we have h or v adjustments.
gtk_widget_translate_coordinates() returns FALSE if neither widget is
realized or in other situations that cause output parameters x and y not
to be set. Thus, if the caller did not initialise x/y and uses them even
if the function returns FALSE, they are using uninitialised variables.
In gtk_container_real_set_focus_child(), we did not check the return
value but merrily went ahead and used x and y regardless. This is UB, as
caught by Valgrind, as well as being pointless.
The trivial fix is to exit early if (!gtk_widget_translate_coordinates).
https://bugzilla.gnome.org/show_bug.cgi?id=776909
