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)
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
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.
