Ahem.
This is in preparation for future changes and is not meant to stay this
way. But I want to change the hash table's keys and this is way easier
when nobody is using them.
I could have tried to make GtkContainerCellAccessible implement
GtkCellAccessibleParent, but the current implementation of that
interface doesn't make sense for it.
Instead of just storing the least significant bit of the row number,
store the full row number. This will soon be useful for accessibility.
But CSS could like it, too.
Add missing GDK linking to GIR build and examples:
GISCAN Gtk-3.0.gir
CCLD gtk-query-immodules-3.0
./.libs/libgtk-3.so: undefined reference to `gdk_keymap_get_modifier_mask'
./.libs/libgtk-3.so: undefined reference to `gdk_modifier_intent_get_type'
./.libs/libgtk-3.so: undefined reference to `gdk_window_begin_resize_drag_for_device'
./.libs/libgtk-3.so: undefined reference to `gdk_event_triggers_context_menu'
collect2: ld returned 1 exit status
CCLD grid-packing
../gtk/.libs/libgtk-3.so: undefined reference to `gdk_keymap_get_modifier_mask'
[...]
https://bugzilla.gnome.org/show_bug.cgi?id=664027
The default (out) transfer mode is "full", but the passed "model" pointer gets
set to gtk_tree_view_get_model() which is "transfer none". This caused Python
programs to free the model after calling this, causing crashes.
g_checksum_get_digest checks to ensure that the passed digest_len is long
enough to hold the digest, before setting it to the actual length of the
digest returned. Digest_len is uninitialized in the code, so if you're
lucky it will be larger than 20 and everything will work fine. If you're
unlucky, g_checksum_get_digest will return either -1 or some number less
than 20, and the g_assert(digest_len==20) will fail.
Wake up the run loop unconditionally (don't check if it is waiting) because
it might go into waiting state right after we checked for it. Fixes GIMP
startup (which has a lot of GIOChannel I/O but zero NSEvents) from several
minutes to a few seconds.
(cherry picked from commit 0729cdc9a1)
We now do proper handling of existing invalid regions, and
we use ScrollDC which allows us to specify the right clip
region rather than just the bounding rect.
Positioning windows at 0,0 post creation failed, because it
was mapped with CW_USEDFAULT, but private->x/y still said 0,
so moving it to 0,0 did nothing. We now always position the
window at the right place, even when not mapped, but we
create it at CW_USEDEFAULT initially and store that position
before moving it to the right place.
This fixes the window sizing test in testgtk and the inital
position for the gimp toolbar.
The synaptics trackpad driver has some weird behaviour on scroll.
It pops up a window over the mouse pointer (looking like a scrollbar).
This has two problems:
* We get extra enter/leave events for the trackpad window
* We get back the trackpad window when we look for the window
under the mouse to deliver the mousewheel message.
So, we add some trackpad specific hacks to avoid this (sigh) based
on the trackpad window window class.
This fixes bug #542777 and was partially based on a patch there
from Peter Clifton.
gdk_flush() should gdk_display_sync() on all open displays.
Both for display_flush and display_sync it seems useful to call
GdiFlush, but we don't have anything extra to do for display_sync,
as there is no inherent roundtrip on win32.
This should close bug #84314
Windows with transients: center on parent
Splash screens: center on monitor
Also properly ignores initial moves of unmapped
windows that are not override redirect or HINT_POS
Fixes bugs #324254 and #612359
There were still cases where we didn't get a WINDOWPOSCHANGED after
a SetWindowPos() call, like e.g. with a larger minimum size than
the set size (bug #574935)
So, we revert the previous fix and now just always manually emit
a configure notify after the move_resize call. Also, we inhibit
the WINDOWPOSCHANGED configure event during the move_resize operation
to avoid multiple Configures.
There are some cases where we don't get a WINDOWPOSCHANGE such that
we generate a configure event, even if we called gdk_window_move_resize()
or similar. For instance:
* The window is fullscreen
* The window is maximized
* The specified pos/size is the same as the current one
However, as per X11 ConfigureNotify semantics we *always* want one, or
we could run into issue like e.g. bug #537296 where we're waiting for
the CONFIGURE to call gdk_window_thaw_toplevel_updates_libgtk_only().
We always get the WM_DESTROY message anyway, and we remove it there.
Bug #336416 even claims this could be a leak if the WM_DESTROY
message was not seen before the DestroyWindow call returned, as
the WM_DESTROY message could not be handled later without the
window in the handle table. I'm not sure this can happen, but we
might as well remove it.
