_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
Don't handle mouse button events greater than 5 so
they can bubble up to be used by the application.
This was causing nautilus list view to not go forward
and backwards when pressing the extra mouse buttons
designated for that.
Fixes bug 673441
Signed-off-by: Nelson Benitez Leon <nbenitezl@gmail.com>
This is not ideal, we should have a real classic windows theme,
but at least its better than everything being pink, which is what
happens otherwise when theming is not enables.
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.
gtk_application_set_app_menu(), gtk_application_set_menubar():
Mention that you probably want to call this in the startup signal
handler. If you do it earlier you will likely get a warning about
a missing D-Bus connection, because doing it earlier does not
make sense anyway.
Since we check for !list->next (and !list->prev for RTL) to set the
GTK_REGION_LAST flag, we have to filter out invisible columns before
looping; if we don't do that we might end up assigning GTK_REGION_LAST
to an invisible column.
https://bugzilla.gnome.org/show_bug.cgi?id=672937
When a homogeneous grid has no visible children, we were
accidentally doing a division by zero. Instead, just bail
out early in this case, there is nothing to allocate anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=672763
