After my recent fix for this, nautilus was still having problems
telling keeping F10 and Shift-F10 apart. With this change, we are
treating levels with the same symbol like inactive levels, ignoring
them entirely.
A change in xkeyboard-config 2.4.1 made it so that function keys
now have a shift level which has the same symbol, but 'eats' the
shift modifier. This would ordinarily make it impossible for us
to discriminate between these key combinations.
This commit tries harder to discriminate in 2 ways:
- XKB has a mechanism to tell us when a modifier should not be
consumed even though it was used in determining the level.
We now respect such 'preserved' modifiers. This does not fix
the Shift-F10 vs F10 problem yet, since xkeyboard-config does
not currently mark Shift as preserved for function keys.
- Don't consume modifiers that do not change the symbol. For
the function keys, the symbol on the shift level is the same
as the base level, so we don't consider Shift consumed.
For more background on the xkeyboard-config change, see
https://bugs.freedesktop.org/show_bug.cgi?id=45008https://bugzilla.gnome.org/show_bug.cgi?id=661973
This was showing up when using a combo box in list mode. After popping
up the list, the keyboard grab appeared stuck. What was stuck here is
only the client-side grab, since we forgot to clean up our grabs
when receiving an UnmapNotify.
This bug was introduced in 1c97003664.
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
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
_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
The code for calculating the per-monitor workarea was ignoring
the fact that the EWMH workarea property can only handle rectangular
workareas, and thus can't really do justice to general monitor
arrangements. As a workaround, we ignore it for anything but
the primary monitor. And we ignore it for the primary monitor
as well if it does not even cover it.
https://bugzilla.gnome.org/show_bug.cgi?id=672163
We want to avoid handling focus events for the private focus window,
otherwise the keyboard grab taken by for example buttons will cause a
spurious FOCUS_OUT/FOCUS_IN on the toplevel.
The code that did this seems to have been lost in the XI2 transition for
GTK3.
This patch reapplies db4a6040af which was
backed out in 18406b7b04 to give
developers a chance to get their X servers fixed. As we want to get this
bugfix in for 3.4, we need to commit it now.
https://bugzilla.gnome.org/show_bug.cgi?id=657578
XI2 provides us with an increment for each scroll valuator,
and by dividing the delta by the increment, we obtain normalized
values in some abstract 'scroll unit'.
For mouse wheels, the evdev driver reports an increment of -1,
so doing this division fixes the inverted scrolling with wheels
that we've seen recently.
If the Window Manager supports the _NET_WM_STATE_HIDDEN, we use it to use
the _NET_WM_STATE protocol when de-iconifying windows (iconification is
unchanged, via XIconifyWindow). Additionally, we no longer interpret all
UnmapNotify events for our window as the result of iconification.
(Based on patch by Tomas Frydrych <tf@linux.intel.com>)
XInput >= 2.1 allows for implementing smooth scrolling,
reporting the different scrolling axes as valuators.
Any change in those will be reported as GdkEventScroll
events with delta_x/y information.
the older kind of scroll events is still handled, and
emulated in devices able to provide smooth scrolling,
setting _gdk_event_set_pointer_emulated() in that case.
Translate XI_TouchBegin/Update/End to GDK_TOUCH_BEGIN/UPDATE/END
events.
At the same time,
set pointer-emulated flags on button events with XIPointerEmulated
and on touch events emulating the pointer.
This patch changes all uses of GDK_DEPRECATED(_FOR) in gdk headers
by the versioned variants, GDK_DEPRECATED_IN_3_x(_FOR). At the same
time, we add GDK_AVAILABLE_IN_3_x annotations for all API additions
in 3.2 and 3.4.
This last slave device (stored per master) is used to fill
in the missing slave device in synthesized crossing events
that are not directly caused by a device event (ie due to
configure events or grabs).
Move g_return_if_fail() stuff from the backends to the public
functions in gdkscreen.c itself, and some fixes for ugly formatting in
the various gdkscreen-backend.c files.
_gdk_x11_keymap_key_is_modifier() never tries to set min/max_keycode
if they haven't been set before, meaning that until another function
sets those, all the keys will be seen as non-modifiers.
This causes GdkKeyEvents to be wrongly tagged with "->is_modifier = 0"
when in actual fact the key is a modifier. This fixes keyboard
shortcuts captured with GtkCellRendererAccel in "raw" mode thinking
a modifier without any actual keys is a valid shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=670400
This implements the following part of the EWMH spec:
"The special value _NET_WM_MOVERESIZE_CANCEL also allows clients to cancel the
operation by sending such message if they detect the release themselves
(clients should send it if they get the button release after sending the move
resize message, indicating that the WM did not get a grab in time to get the
release)."
In particular, it fixes the case of clicking widgets that use
gdk_window_begin_[resize|move]_drag*() and the click "sticking", i.e. the
mouse button getting released but the resize or move operation remaining in
effect.
https://bugzilla.gnome.org/show_bug.cgi?id=669208
