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
_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
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 gtkimcontextsimple and gtktreeview, which are the easy places,
but also true bugfixes, because on OSX we can't use the virtual META
here, we needs MOD2 as delivered in key events.
gobject_introspection's G-ir-scanner doesn't like the -xobjective-c
option needed to compile ObjectiveC features in quartz implementations
of certain gtk functions. This rearranges the compiler flag environment
variables in Makefile so that G-ir-scanner doesn't see them.
This fixes bug 653289, in gtk+-2 gtk_tree_view_stop_editing() was previously
responsible for notifying with gtk_cell_editable_editing_done(), this detail
was missed when porting the cell renderer management to GtkCellArea.
This bug is resolved by fixing two things in
gtk_tree_model_filter_row_deleted():
(1) It is possible for an elt to have elt->visible_siter == NULL, when
it is deleted. Only call g_sequence_remove() if this pointer is
non-NULL.
(2) For the case len (level->seq) > 1, free the elt->children level
if non-NULL. Failing to do this means the level will stick around.
If this child level was not referenced, it will still have a zero
ref count on its parent which cannot be removed!
For both bugs unit tests have been added in the preceding commit.
This tests a case where gtk_tree_model_filter_row_changed() is run
for a node with visible_siter != NULL, however its parent has
visible_iter == NULL. For this case, no valid paths can be generated
as the node cannot be accessed (because the parent is invisible).
Thanks to Kean Johnston for pointing this out.
There are a few places in GTK that use "struct stat",
and then g_stat(), rather than using GStatBuf.This breaks things on
Windows. Since the size of struct stat can vary depending on other
flags specified, this has the potential to cause overwrites and is
trivial to fix.
Based on patch submitted by Kean Johnston
