The new file defines GDK_DISABLE_DEPRECATION_WARNINGS so it can happily
use deprecated APIs.
This commit moves those functions there that use deprecated functions
and currently cause warnings.
With this commit, GDK compiles without deprecation warnings.
After consulting with Carlos, we agreed that it should be enough to grab
the core pointer instead of doing a full grab. If it turns out that's
wrong, we need to adapt the internal API for resizes to take the device
doing the resize.
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
It turns out that simply using XIGrabKeycode instead of XGrabKey
makes the DND keyboard support mostly work (there seem to be some
minor issues with modifiers). This means we no longer grab the
keyboard actively during DND, which in turn makes Alt-Tab and
other window manager shortcuts work again during DND.
At the same time, bring the DND key handling code into the
multi-backend work, by checking for X11 and XI2 at runtime,
in addition to compile time.
Rounded corners now will always work, using XShape in case we're not
running a composite manager.
Also, setting an RGBA visual (if available) on the tooltip toplevel
enables them to be transparent if the theme specifies so.
https://bugzilla.gnome.org/show_bug.cgi?id=599617
