Before, right click events were still let through into GDK. In this
case, also middle/right button events with x-coordinates in the range
[-3, 0] are processed, resulting in failures/crashes in the window
finding code because no GdkWindows are present in this range.
GDK_EVENT_2BUTTON_PRESS and GDK_EVENT_3BUTTON_PRESS can't be used from
some bindings because they'd translate to something syntactically
invalid. Add GDK_EVENT_DOUBLE_BUTTON_PRESS and
GDK_EVENT_TRIPLE_BUTTON_PRESS aliases to work around that.
https://bugzilla.gnome.org/show_bug.cgi?id=671025
Add a fallback-c89.c for the gdk/ subdirectory as there is code that uses
functions that are introduced by C99. This currently adds fallback
implementations for MSVC for isnan() and isinf()
Dist this "new" source file as well
.. instead of the previous stable version.
This ensures that if we use GDK_DEPRECATED_IN_3_6, it will actually emit
a warning in GTK 3.5, and not wait with that until GTK 3.7. This is
particularly useful for stuff that gets deprecated right now. This code
should emit warnings right now, so we know what we're doing while
deprecating.
GtkPlug directly handles X KeyPress/Release events, instead of using
translation in GDK (which expects XI2 events for XI2). When this
was done, the handling of the group was stubbed out and never replaced.
Export gdk_keymap_x11_group_for_state() and gdk_keymap_x11_is_modifier()
so we can fill out the fields correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=675167
This allows combo box popup windows to appear in the correct place. This is a
workaround emulating root coordinates by calculating the offset for a chain
of windows that that are relative to each other.
Since the event will be ignored anyway after it's translated (slave
devices are disabled), don't let it run in the smooth scroll code path,
as it will burn our caches for the actual event we're interested in.
https://bugzilla.gnome.org/show_bug.cgi?id=673644
In the Quartz backend, there are two methods by which windows are
resized. The first method is fully handled by Quartz and does not appear
in the event stream the application resizes. The second method is when
we resize windows by ourselves. In OS X this happens when a GTK+ resize
grip is used. This resize grip is larger than the Quartz resize grip.
When the resize is started outside the "Quartz area", we have to handle
it by ourselves.
This patch fixes this manual window resizing by ignoring events while we
are in the process of resizing (such that the events actually arrive at
the sendEvent handler of GdkQuartzWindow where this resize is handled).
When the resize has finished we break all grabs such that GDK is not
stuck thinking the cursor is still in the resize window.
_gdk_x11_moveresize_configure_done() isn't called for wmspec
moves/resizes so we don't have a way to notice when a wmspec
move/resize ends and consequently untrigger the sending of
_NET_WM_MOVERESIZE_CANCEL which results in this message always being
sent on the next button release event. In that case we are marking
that event as handled so it isn't processed further which breaks
button press/release event handling in several widgets.
To fix this we simply allow the normal event handling machinery to run
after sending the _NET_WM_MOVERESIZE_CANCEL message.
https://bugzilla.gnome.org/show_bug.cgi?id=673328
Since the order in which _NET_WM_STATE and _NET_WM_DESKTOP are set, or
even *if* they are set, isn't defined, we could end up unsetting
GDK_WINDOW_STATE_FOCUSED given that both handlers for these two X
properties end up doing window state changes for all states. As we
want GDK_WINDOW_STATE_FOCUSED to be set by default we need to set its
master flag by default as well.
https://bugzilla.gnome.org/show_bug.cgi?id=673125
We now have a proper MASTER/SLAVE input device split, where
the masters are virtual core input devices and we add fake hw
slave devices for the system pointer and real slave devices for
wintab devices.
We also set the proper source_device on the events so you can
tell which device sent it and properly decode the axis info.
