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>)
_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
Conflicts:
gdk/x11/gdkkeys-x11.c
When the X server does not support the shape extension (as some
vnc implementations seem to), our DND code was always seeing
an empty input shape, so drops always missed their target.
http://bugzilla.gnome.org/show_bug.cgi?id=620240
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.
(cherry picked from commit ac943bf69a)
The monitor change detection code in _gdk_x11_screen_size_changed() and
process_monitors_change() goes to some length to make sure its only emitted
when there is an actual change to the data visible via the GdkScreen monitors
api.
However, commit 662e69ad added some code that always emits "monitors-changed"
in _gdk_x11_screen_size_changed when we have randr13 and get a ConfigureNotify
on the root window (even though we may already have emitted it in the
RRScreenChangesNotify event!).
As far as I can tell this is due to a comment in the bug referenced by the
commit (https://bugzilla.gnome.org/show_bug.cgi?id=601712#c4) where it says:
This version of the patch changes GdkDisplay to emit "monitors-changed" when
the primary monitor changes (see the change in _gdk_x11_screen_size_changed).
And, if you remove this part of the change the signal is not emitted when just
the primary is changed. However, this is not really the right approach. We
should just also check for if the primary changes in process_monitors_change()
to avoid spurious signal emissions.
https://bugzilla.gnome.org/show_bug.cgi?id=643216
(cherry picked from commit 0b0f110152)
Conflicts:
gdk/x11/gdkscreen-x11.c
If a level 1 key maps to a key value passed to
gdk_test_simulate_key(), raise the GDK_SHIFT_MASK flag so the reqested
key value is generated. Also add a regression test for this fix.
Allow -1 for the hotspot coordinates in gdk_cursor_new_from_pixbuf,
if the pixbuf contains the x_hot/y_hot options with appropriate values.
Bug #632140.
Add the composite overlay window to the cache, as this can be a reasonable Xdnd proxy as well.
This is only done when the screen is composited in order to avoid mapping
the COW. We assume that the CM is using the COW (which is true for pretty
much any CM currently in use).
https://bugzilla.gnome.org/show_bug.cgi?id=601731
Bug 628656 - _gdk_windowing_get_startup_notify_id memory leak
get_display_name() returns a newly allocated string, which was being fed
directory info a g_strdup_printf() call.
(cherry picked from commit bf3b5f785e)
