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
kvm(3) is considered a deprecated interface, so make
GMountOperation::show-processes use the recommended sysctl(3) interface
instead. This also removes the need to link with libkvm.
https://bugzilla.gnome.org/show_bug.cgi?id=661835
Bid farewell to G_DISABLE_DEPRECATED and the build errors it causes as
warnings are now used to deter people from using deprecated GLib items
in a more subtle manner
_fstat32 is only introduced with msvcrt80.dll (i.e. Visual C++ 2005), in
which using this function will break compilation with MinGW, which links
against msvcrt.dll. The msvcrt.lib in the Windows DDK which links to
a later incarnation of the msvcrt.dll in later Windows systems may have
this symbol defined, but that needs to be checked upon to be sure.
Thanks to Dieter Verfaillie for pointing out this problem.
Create a synthetic NSMouseLeftDown to store in the GtkQuartzDragSourceInfo
rather than relying on the NSWindow's latest event being the right one (or the
right kind).
Clear the Drag paste board just before the info->context is released.
This way the GtkDragSourceOwner is released just before the drag context
is and thus can pasteboard:provideDataForType: not accidentally access
an already released drag context
When compiled with older SDKs, the original change for this bug caused a
compiler warning about NSWindow not being able to handle a setStyleMask
message. This tricks the compiler into thinking that it can.
and finish the port to using the new modifier abstraction API.
This commit has some evilness, it uses the default display for
the lack of a widget context, and the change to gtkstock.c
is very ugly, but I can't think of anything better given
GtkStockItem needs an accel mask instead of a proper accel
string.
In 2.x, the !HAVE_XCONVERTCASE fallback of keyval_convert_case() was
implicitly used as implementation for all !X11 backends.
In 3.x, when this function was virtualized in GdkDisplayManager,
this fallback was moved to the X11 backend and the other backends
"equipped" with /* FIXME implement */ implementations of
keyval_convert_case() which don't convert anything.
Move the fallback code back to gdk/ as default implementation
of GdkDisplayManager::keyval_convert_case() and remove its
implementations is all backends but X11. Also remove the
implementation in Wayland which was a plain copy of what
is now the default implementation.
(cherry picked from commit f46c1b76d8)