This turns GdkWin32DragContext into a proper GdkDragContext subclass.
Because we now correctly initialize GdkWin32DragContext in
gdk_drag_context_new, we no longer crash immediatly when a DnD
operation is initialized (the find_window, drag_status, ... vfuncs
where all pointing to 0x0 instead of their proper win32 implementations).
We now try to consistently refer to GdkDragContext as "context",
GdkWin32DragContext as "win32_context" and the ole2 related
target_drag_context and source_drag_context as "ctx".
Members of GdkWin32DragContext only used by the ole2 DnD codepaths
are now explicitly marked with a ole2_dnd_ prefix.
gdk_cairo_region_create_from_surface doesn't work correctly on PPC.
This is most prominently seen with the GTK window resize grip, the
shape of which is mirrored every eight pixels horizontally.
At the same time, use an A1 surface for the resize grip shape to
eliminates an A8->A1 surface conversion.
Add GDK_MODIFIER_INTENT_SHIFT_GROUP to enum GdkModifierIntent
and handle it in gdk_keymap_get_modifier_mask(). Add an X11
impl of the method and return keymap_x11->group_switch_mask.
Return 0 from the default impl because we don't know.
If the keyboard group shifting modifier is *also* a normal
accelerator modifier, we need to special case it when calling
gdk_keymap_translate_keyboard_state(), so we get the right
key symbol for accelerators (for example we want Option-O,
not Option-Ø displayed in menu items). This patch should only
affect quartz where the Alt key both shifts the group and can
be used as accel modifier, and not X11 or Win32 where AltGr
is not used for accelerators.
- fix quartz' gdk_keymap_translate_keyboard_state() to return
the right consumed_modifiers
- add _gtk_translate_keyboard_accel_state() which does the
special casing
- use it everywhere instead of gdk_keymap_translate_keyboard_state()
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.
There is no particular reason to special case this, we want to handle all
sort of normal events. The only special thing we keep is that
as an optimization we pump the message loop extra during a WINPOSCHANGED
in a modal operation as that will cause us to repaint faster.
Also, bump the arbitrary number of mainloop iterations for the timer.
I don't see why we need it at all, but at least doing more than one
iteration if needed should be nice.
When you start a window resize or move via the window menu and
don't actually change anything we're not getting an exitsizemove.
In order to work around this we also look for WM_CAPTURECHANGED.
This moves all the code from WM_SIZE, WM_MOVE, and WM_SHOWWINDOW into
one place, cleans up the code and makes sure we only send a single
configure event even if both size and position changes.
We don't pass in raise anymore, but already_mapped.
Also, already_mapped must be used rather than MAPPED, as we already
synthesize the MAPPED in the generic code (and thus we don't have
to synthesize it again).
Calling PeekMessage can cause reentrant calls into the window procedure
for sent (as opposed to posted) messages, so its not safe to call
when we're not expecting reentrancy. Instead we call GetQueueStatus
when we're just looking for availible messages.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=552041
By reverting gdk_drag_find_window_for_screen logic to what it was
before eb21a7df29.
The old logic knew how to ignore drag_window when searching
for dest_window, but that code was removed (I guess by accident).
https://bugzilla.gnome.org/show_bug.cgi?id=616544
Commit 5ebb32d1ff didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
The button highlighting in testgtk works again, even with
GDK_NATIVE_WINDOWS. Unfortunately testgtk:menus still does
not work for the forced-native-window-case.
In _gdk_window_move_resize_child it tries to decide whether to pass
SWP_NOSIZE and SWP_NOMOVE based on whether the new size and position
is different from the window's existing position. However it seems
that GDK now ends up updating the window's position before calling
_gdk_window_move_resize_child so this would mean it would think the
window never changes size or position so SWP_NOSIZE|SWP_NOMOVE would
always be set. This causes child windows to never be resized.
This patch changes it so that it never passes either flag to
SetWindowPos. I don't know whether this will cause any side effects
but you'd think it shouldn't do any harm to reassert the current size.
https://bugzilla.gnome.org/show_bug.cgi?id=628049
Signed-off-by: Hans Breuer <hans@breuer.org>
Allows more modern browsers eg. firefox 5+ to use gtk/broadway
Auto-detects protocol version, and can switch between them at
as you connect a different browser.
This works to some extent, but seems to hang sometimes, for
instance the "button box" test in testgtk never shows up.
Don't try to remember the current keyboard modifier and mouse button
states from the last event, because that isn't always right, and don't
set event.state = 0 for generated events. Instead, add private functions
to get the current states, and implement them with API that retrieves
these states independently from an event.
_NET_WM_STATE_FOCUSED is a new _NET_WM_STATE hint which allows us to
implement a meaningful GDK_WINDOW_STATE_FOCUSED under X11. If the window
manager doesn't support this hint we keep GDK_WINDOW_STATE_FOCUSED set since
that is what gtk+ implicitly assumed historically.
https://bugzilla.gnome.org/show_bug.cgi?id=661428
This state means that the toplevel window is presented as focused to the user,
i.e with active decorations under an X11 window manager.
If the GDK backend doesn't implement this flag, it will just remain set after
mapping the window.
https://bugzilla.gnome.org/show_bug.cgi?id=661428
which effectively nails down the MOD1 == ALT assumption that is valid
in all other parts of GTK+. After the modifier abstraction fixes for
OSX, the virtual mapping is now (correctly) used in more places, and
caused problems with the common default PC keyboard layout on X11 that
colocates ALT and META on the same key.
Fixes e.g. crashs when dropping from finder.
Turn the "getting_events" boolean into a counter to handle poll_func()
being called recursively, and track the loop depth correctly by
changing its counter before bailing out in run_loop_observer_callback().
This way we reallocate our autorelease pool at the right time, and
don't kill memory that is still in use by outer run loops.
Also drain, not release the pool, just for some defensive forward
compatibility.
(cherry picked from commit ef9a92d225)
When an NSEvent does not have the window field set, we already assumed
the event was not for us and discarded it. But for NSMouseMoved events
we now make an exception, because such events generated after
using/clicking the main menu bar have the window field set to NULL while
the application window still has focus.
We used to experience a loss of motion events after using the menu bar,
this could be seen in buttons that stopped prelighting and first
clicks often being ignored unless you clicked somewhere else first.
These issues are fixed by this patch.
Since the wmspec_check_window doesn't have a corresponding GdkWindow we can't
rely on the get_event_window() return value to get the XID from. Just use the
XID from the XEvent directly.
https://bugzilla.gnome.org/show_bug.cgi?id=662953
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.
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.
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)
gdk_x11_device_manager_core_list_devices returns a new allocated
list, which has to be freed.
valgrind output:
==18686== 160,176 (80,088 direct, 80,088 indirect) bytes in 3,337 blocks are definitely lost in loss record 25,347 of 25,378
==18686== at 0x4C256DD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18686== by 0x6CD7752: g_malloc (in /lib64/libglib-2.0.so.0.3000.0)
==18686== by 0x6CEE2B6: g_slice_alloc (in /lib64/libglib-2.0.so.0.3000.0)
==18686== by 0x6CCB37D: g_list_prepend (in /lib64/libglib-2.0.so.0.3000.0)
==18686== by 0x654CADA: gdk_x11_device_manager_core_list_devices (gdkdevicemanager-core-x11.c:836)
==18686== by 0x6531489: gdk_display_pointer_is_grabbed (gdkdisplay.c:1270)
==18686== by 0x5162E1E: filter_func (ui.c:140)
==18686== by 0x6558B50: gdk_event_apply_filters (gdkeventsource.c:83)
==18686== by 0x6558CB3: _gdk_x11_display_queue_events (gdkeventsource.c:197)
==18686== by 0x6530680: gdk_display_get_event (gdkdisplay.c:311)
==18686== by 0x65589F1: gdk_event_source_dispatch (gdkeventsource.c:356)
==18686== by 0x6CD0A0E: g_main_context_dispatch (in /lib64/libglib-2.0.so.0.3000.0)
https://bugzilla.gnome.org/show_bug.cgi?id=660676
Those if() blocks don't have any reason being there, as x and y are not
pointers. If the window is destroyed, just set the out values to zero
and return.
As seen in valgrind:
==3306== Conditional jump or move depends on uninitialised value(s)
==3306== at 0x624C74F: gdk_window_get_root_coords (gdkwindow.c:6933)
==3306== by 0x5E193C3: gtk_tooltip_show_tooltip (gtktooltip.c:1160)
==3306== by 0x5E19C05: tooltip_popup_timeout (gtktooltip.c:1282)
==3306== by 0x623B102: gdk_threads_dispatch (gdk.c:754)
==3306== by 0x8592F3A: g_timeout_dispatch (gmain.c:3907)
==3306== by 0x859174C: g_main_context_dispatch (gmain.c:2441)
==3306== by 0x8591F47: g_main_context_iterate (gmain.c:3089)
==3306== by 0x8592494: g_main_loop_run (gmain.c:3297)
==3306== by 0x5D2E501: gtk_main (gtkmain.c:1362)
==3306== by 0x5C5652F: gtk_application_run_mainloop
(gtkapplication.c:115)
==3306== by 0x7C47C9D: g_application_run (gapplication.c:1323)
==3306== by 0x447B5F: main (nautilus-main.c:102)
==3306== Uninitialised value was created by a stack allocation
==3306== at 0x624D48A: gdk_window_get_device_position
(gdkwindow.c:4952)
gdk_unicode_to_keyval(uc) returning (uc | 0x01000000) is not an
error return value but simply the way to encode 24-bit unicode
characters directly as keyvals.
