We have an event, so the correct thing to do is to pass
the device into the function that we are calling. GDK
just grew a variant that takes a device, for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=663444
Which handle accelerators with keycodes as well as keyvals,
so we can use it in applications that use GtkCellRendererAccel's
"Other" mode of operations (namely gnome-control-center and
gnome-settings-daemon).
https://bugzilla.gnome.org/show_bug.cgi?id=662755
I was trying to avoid including gtk.h here, but this breaks
some of our tests, and there's a good chance that 3rd party
code also relies on this include.
As the draw handler expects the items to be laid out already, we cannot
queue a layout here to avoid a race condition with the resize that is
queued immediately after, which in turn would lead to a segfault later
in the paint_item() implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=663138
Everything that deals with a group has to be fixed.
Plus, we have NULL checks without allowing NULL arguments; since NULL
arguments are perfectly fine, we can relax the argument checks.
https://bugzilla.gnome.org/show_bug.cgi?id=662870
A modifier of "0" is still a modifier and must be submitted normally.
A num_modifiers of 0 is essentially a noop in the server.
As mentioned by Peter Hutterer <peter.hutterer@who-t.net>
https://bugzilla.gnome.org/show_bug.cgi?id=662839
This is kind of a hack to get rid of infinite loops that occur when
child accessibles try to set their parent upon creation but the parent
accessible creates its children in the initialize vfunc. Because in that
case, the parent will not have an accessible set when the child tries to
access it, because it is still initializing itself. Which will cause a
new accessible to be created.
https://bugzilla.gnome.org/show_bug.cgi?id=660687
When the active page is switched, it's important
gtk_notebook_pages_allocate() is called after the bulk of
gtk_notebook_real_switch_page() is run, as the former allocates a
different space according to the currently active tab, which is set by
the latter.
gtk_notebook_pages_allocate() already calls gtk_notebook_redraw_tabs()
when the allocation changes, so just move its call down to
gtk_notebook_real_switch_page() to fix the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=662629
If we get a composited-changed signal before the tooltip is ever realized we
have nothing to do.
This actually prevents a segfault in maybe_update_shape() because calling
gtk_widget_get_window() on a non-realized widget returns NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=662467
- add gtkmodulesprivate.h and move stuff there from gtkprivate.h
- add gtkprivate.c and move stuff there from gtkmain.c
- add gtkwin32.c and move stuff there from gtkmain.c
- don't redefine GTK_DATADIR and friends in gtkprivate.h
- have _gtk_get_datadir() and friends on all platforms
- remove the horrid hacks where gtkprivate.h can't be included,
or must be included later due to redefinition of the compile-time
directories
GtkRange needs to check if its allocation intersects with the resize
grip allocation (trimming its own allocation if it does).
In order to do that, it needs to translate its allocation into window
coordinates, and before that, find the window to whose the allocation
is relative; code goes all the way finding the right parent widget, but
then doesn't actually use it when translating the coordinates, leading
to using the wrong rectangles for the intersection check.
https://bugzilla.gnome.org/show_bug.cgi?id=662308
