The callback function gtk_window_on_theme_variant_changed is only used on the
X11 backend (where GtkSettings is used for the settings information.)
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=674207
We can't safely examine allocations synchronously using
gtk_main_iteration(), as there might be not enough time for a new paint
clock tick to have expired and the allocation set on the widget.
Work this around adding g_usleep() calls before processing pending
mainloop events.
With the following code:
#define INVALID_CHAR GDK_KEY_VoidSymbol - 1
gtk_accelerator_get_label (INVALID_CHAR, GDK_SHIFT_MASK | GDK_CONTROL_MASK);
we would get this label:
Shift+Ctrl+
instead of this label:
Shift+Ctrl
https://bugzilla.gnome.org/show_bug.cgi?id=694075
The default windows timer resolution is 16msec, which is too little
for fluent animations (say at 60Hz). So, while a paint clock is
active we temporarily raise the timer resolution to 1 msec.
Add an API to start or stop continually updating the frame clock.
This is a slight convenience for applcations and avoids the problem
of getting one more frame run after an animation stops, but the
primary motivation for this is because it looks like we might have
to use timeBeginPeriod()/timeEndPeriod() on Windows to get reasonably
accurate timing, and for that we'll need to know if there is an
animation running.
https://bugzilla.gnome.org/show_bug.cgi?id=693934
gdkwindown-win32.c included windows.h directly rather than via gdkwin32.h
which broke the build for me at least. Instead rely on it being included in
gdkwin32.h and things work right.
We only draw the main entry on should_draw (widget->window), because
otherwise we also draw it on the GtkTextHandle widgets.
This is necessary due to the recent change for that to not return
TRUE and swallow the rest of the drawing operation.
This was causing warnings on widget unparent like:
Gdk-CRITICAL **: gdk_window_has_native: assertion `GDK_IS_WINDOW (window)' failed
Becasue the window was not properly removed from the lists on unrealize.
