Since events can be paused independently for each window during processing,
make _gdk_display_pause_events() count how many times it is called
and only unpause when unpause_events() is called the same number of
times.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Unqueuing events from the windowing system when paused could result
in weird reordering if event filters resulted in application-visible
behavior. Since we now resume events when the frame clock is frozen,
we now no longer count on low-level event handling running while
event handling is paused.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
When we have pending motion events, instead of delivering them
directly, request the new FLUSH_EVENTS phase of the frame clock.
This allows us to compress repeated motion events sent to the
same window.
In the FLUSH_EVENTS phase, which occur at priority GDK_PRIORITY_EVENTS + 1,
we deliver any pending motion events then turn off event delivery
until the end of the next frame. Turning off event delivery means
that we'll reliably paint the compressed motion events even if more
have arrived.
Add a motion-compression test case which demonstrates behavior when
an application takes too long handle motion events. It is unusable
without this patch but behaves fine with the patch.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
There are cases where crossing events aren't generated by input devices themselves
but rather through programmatical means (windows being moved/hidden/destroyed while
the pointer is on top).
Those events come from X as sourceid=deviceid, and GDK does its deal at lessening
this by setting a meaningful source device on such events, although this caused
some confusion on the mechanism to block/synthesize touch crossing events that
could possibly cause bogus enter events on the new window below the pointer.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=691572
the backing GdkTouchGrabInfo will be needed if the overriding device
grab finishes before the touch does in order to send events back to
the implicit grab window. Instead, wait until the touch is physically
finished before removing the matching GdkTouchGrabInfo
If the touch sequence happens on a window with GDK_TOUCH_MASK set,
a GdkTouchGrabInfo is created to back it up. Else a device grab is
only created if the sequence emulates the pointer.
If both a device and a touch grab are present on a window, the later
of them both is obeyed, Any grab on the device happening after a
touch grab generates grab-broken on all the windows an implicit
touch grab was going on.
Anytime a touch device interacts, the crossing events generation
will change to a touch mode where only events with mode
GDK_CROSSING_TOUCH_BEGIN/END are handled, and those are sent
around touch begin/end. Those are virtual as the master
device may still stay on the window.
Whenever there is a switch of slave device (the user starts
using another non-touch device), a crossing event with mode
GDK_CROSSING_DEVICE_SWITCH may generated if needed, and the normal
crossing event handling is resumed.
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.
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
GDK_NATIVE_WINDOWS was a way to keep some old apps running that did weird
things in gtk2. We should not have to carry this forwards in gtk 3.x.
We do however keep a g_warning() call reminding people of this fact to
ease debugging when they try to port their applications.
https://bugzilla.gnome.org/show_bug.cgi?id=644119
The previous function gdk_drag_get_protocol_for_display() took native
window handles, so it had to be changed. Because it didn't do what it
was named to do (it didn't return a protocol even though it was named
get_protocol) and because it doesn't operate on the display anymore but
on the actual window, it's now called gdk_window_get_drag_protocol().
... and all APIs making use of it.
That code like it hasn't been touched in years, Google codesearch
didn't find any users and most importantly it's a horrendous API, so
let's just make it die instead of having to port it over to
non-GdkNativeWindow usage, which would be required for multi-backend
GDK.
http://mail.gnome.org/archives/gtk-devel-list/2011-January/msg00049.html
slave devices don't have coordinates themselves, as they depend
on a master, this only changes if they have a grab in effect,
so only keep toplevel tracking enabled in such situation. Fixes
Bug #640313 - BadDevice X error when ungrabbing a SLAVE device,
noticed by Jesse van den Kieboom.
There's no usecase for them, so remove them before we have to commit to
keeping an API.
Make the hooks private for now, actually removing them will come in
followup patches.
Its usecase was GERD - http://testbit.eu/~timj/historic/gerd/ - and that
project is long since dead.
I couldn't find any app using it after asking around and googling either.
Its usecase was GERD - http://testbit.eu/~timj/historic/gerd/ - and that
project is long since dead.
It has been superseded in GTK 2.2 by GdkDisplayPointerHooks anyway.
We want to have different window types for different displays, so we can
write code like this:
#if GDK_WINDOWING_X11
if (GDK_IS_X11_WINDOW (window))
{
/* do x11 stuff */
}
else
#endif
#if GDK_WINDOWING_WAYLAND
if (GDK_IS_WAYLAND_WINDOW (window))
{
/* do wayland stuff */
}
else
#endif
{
/* do stuff for unsupported system */
}
This requires different GdkWindow types and we currently don't have
that, as only the GdkWindowImpl differs. With this method, every backend
defines a custom type that's just a simple subclass of GdkWindow. This
way GdkWindow behaves like all the other types (visuals, screens,
displays) and we can write code like the above.
This commit hides the GdkDisplayManager instance and class structs,
adds vfuncs for listing displays, opening displays, and getting and
setting the default display. The X11 backend has a derived
GdkDisplayManagerX11.
The gdk_display_manager_get() function is responsible for deciding on
which of the compiled in backends to use. Currently, it consults the
GDK_BACKEND environment variable and falls back to x11.
This commit hides GdkDragContext and GdkDragContextClass, adds
vfuncs for most drag context functionality, and turns the X11 DND
implementation into GdkDragContextX11. We also add vfuncs to
GdkDisplay for gdk_drag_get_protocol and to GdkWindow for
gdk_drag_begin, and implemenet them for X11.
Other backends need similar treatment and are broken now.
Add a GdkDisplay::get_app_launch_context vfunc, and a
gdk_display_get_app_launch_context that for X11 returns a subclass.
For win32 and quartz, the implementations were trivial, so we
just return a new GdkAppLaunchContext without subclassing. Since
the type of the context now depends on the display,
gdk_app_launch_context_set_display is deprecated.
The old functions to get core pointer and devices list are gone as
well. This slice is entirely replaced internally by multidevice
handling and may just go.
This function may be used to know the hardware device that triggered
an event, it could resort to the master device in the few cases there's
not a direct hardware device to relate to the event (i.e.: crossing events
due to grabs)
* _gdk_device_set_associated_device() did not allow NULL device
* GdkDisplay should dispose device manager to avoid devices
trying to touch the display in finalize
* GdkDeviceManagerXI did not ref devices in id hash
* GdkDisplayX11 did not ref devices in ->input_devices
This function makes a better replacement for
gdk_display_get_core_pointer(), wherever it might yet be needed, for
XI2 resorts to XIGetClientPointer(), for the others return the only
core pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=621685
This commit was created using a script that searched for all docstrings
containing a parameter and the string 'or %NULL'.
Gdk backends and demos excluded as they are not part of a public API
https://bugzilla.gnome.org/show_bug.cgi?id=610474
The Gdk-custom.c file in gir-repository contained a number of
introspection annotations. Merge those into the GDK source files.
Some documentation was moved from the tmpl/ files to accomodate
the addition of annotations.
https://bugzilla.gnome.org/show_bug.cgi?id=592279
This has two advantages:
1) In many backends, this is faster as we can terminate the window
hierarchy traversal earlier
2) When used in gdkdisplay.c::get_current_toplevel() to get the
current toplevel that has the pointer we now correctly return
a toplevel with the pointer in it where the pointer is inside
some foreign subwindow of a toplevel window.
The second advantage fixes some bugs in client side event generation
when the pointer is inside such a foreign child window.
Some applications make weird assumtions on Gtk+ that do not work anymore
with the new client-side windows support. For instance SWT/Eclipse reorders
the stacking order of the X windows directly without telling gdk this,
which breaks gdk drawing as gdk now relies on knowing the stacking order
for window clipping.
This introduces a GDK_NATIVE_WINDOWS environment variable, which if set
causes Gtk+ to always use native windows. Its more compatible with
pre-csw Gtk+ behaviour if you do weird X-specific hacks, although it does
limit the size of GdkWindows to 65535x65535.
When we ungrab the pointer we don't get enter events for the window the
pointer is in at the time of the ungrab, so we manually query for the
window the pointer is in. The same thing actually happens on re-grab if
the previous grab was !owner_events (meaning we don't get crossing events
for windows other than the grab) but the new grab is owner_events (and
thus non-grab windows need to get crossing events).
This factors out some common code and enables it also for the re-grab
to owner_events case.
If we get a nonlinear enter/leave notify on the toplevel we need
to set nonlinear in all the events we send, even if the in-toplevel
tree is linear.
This fixes combobox menus popping down immediately when you click
(not hold). (bug #587559)
we now use gdk_offscreen_window_set_embedder() instead of a signal
to get the parent. This also replaces set_has_offscreen_changes.
Rename "parent" in all embedding related names to "embedder" to make it
more obviously different than the normal parent.
Rename gdk_window_get_offscreen_pixmap to gdk_offscreen_window_get_pixmap
to match the other offscreen calls.
Rename gdk_window_offscreen_children_changed to gdk_window_geometry_changed
as this is more descriptive.
We use the offscreen signals for getting parent, picking
children at a point and mapping coordinates between windows
embedding offscreens and offscreens.
This means we have two hierarchies more or less, one visible to apps via
the standard APIs and for drawing where the offscreens are their own
separate toplevels, and another one for event handling where embedded
offscreens appear as if they were children of the embedding window.
We returned the innermost child that has the pointer, which is not right.
Only the direct child that has the pointer in it should be reported (if any).
