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.
We link to the HowDoI for GNotification in the class description, but we
should be more verbose in the deprecation notices for each function of
the GtkStatusIcon class.
https://bugzilla.gnome.org/show_bug.cgi?id=743975
The a11y tests complain that org.gtk.Settings schemas are missing
and fail. This copies the code to build and include the schemas from
the reftests testsuite.
This IM context implementation goes through the gtk-text-input protocol,
leaving up to the compositor the actual interaction with IM engines. If
the protocol is not offered by the compositor, GTK+ will fallback to the
IMs as specified through GtkSettings.
The internal known_globals hashtable is used to carry accounting for
interfaces that depend on others (as ordering is not guaranteed), extend
its usage so it also keeps track of unimplemented interfaces (here at
least).
The API call will then use this to allow querying the globals offered by
the compositor, it will be useful to determine whether we can use
text-input protocols or should fallback to other IMs.
This fixes stuttering in animations that rely on the regularity of
gdk_frame_clock_get_frame_time.
https://bugzilla.gnome.org/show_bug.cgi?id=787665
BEFORE
gdkgears:
58 FPS and visibly stuttering
gnome-maps on a 59.95Hz monitor:
"paint" g_get_monotonic_time +17278μs, gdk_frame_clock_get_frame_time +17278μs
"paint" g_get_monotonic_time +17449μs, gdk_frame_clock_get_frame_time +17426μs
"paint" g_get_monotonic_time +17620μs, gdk_frame_clock_get_frame_time +17600μs
AFTER
gdkgears:
60 FPS and smoother
gnome-maps on a 59.95Hz monitor:
"paint" g_get_monotonic_time +18228μs, gdk_frame_clock_get_frame_time +16680μs
"paint" g_get_monotonic_time +15010μs, gdk_frame_clock_get_frame_time +16680μs
"paint" g_get_monotonic_time +17134μs, gdk_frame_clock_get_frame_time +16680μs
The annotation (allow-none) is wrong. Since
gtk_tree_view_is_blank_at_pos() also calls
gtk_tree_view_get_path_at_pos(), the same fields should have the same
annotations.
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
We are using a lot of deprecated API, and we know it.
Since the selection code is going to be replaced in GTK 4.0, there's no
real point in keeping the warnings enabled in 3.22.
Functional revert of commit 9c4892f291.
Fixes introspection scanner warnings like:
Warning: Gtk: gtk_drag_finish: Methods must belong to the same
namespace as the class they belong to
That is, the gtk_drag_* functions cannot be methods as they have a
"GdkDragContext" as the instance parameter, and that is not a valid
type for the Gtk namespace.
This is not an introspected ABI change, as the generated introspection
data ignores the annotation.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=692152
