Try to fetch the name from the application desktop file for the
fallback menu if possible, instead of forcing applications to use
g_set_application_name or hardcoding "Application".
https://bugzilla.gnome.org/show_bug.cgi?id=673882
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.
gtk_entry_completion_set_property() was setting many properties by
directly modifying priv values, bypassing notification invocation and
possibly another actions done by gtk_completion_entry_set_xxx ()
functions. Fix by invoking set_xxx() instead of setting the property
value directly.
The real bug observerd was that setting text-column property using
g_object_set() caused SIGFPE later when entry completion was about to
appear. gtk_entry_completion_set_text_column () apparently does way
more important things than just setting priv->text_column member.
https://bugzilla.gnome.org/show_bug.cgi?id=673693
Instead, just draw the children. The cairo code will keep track of
things, so there's no need to track things.
Also, the old code was doing it wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=672544
Style properties should not be cached, they should be queried live.
Also, this fixes the case where the expander size wasn't set when
constructing the widget which caused expanders to go missing.
This can cause lagging when scrolling as it causes us to repaint
on every scroll event. This wasn't historically a great problem,
but with smooth scrolling we get a lot more events, so this
now creates visible lagging on slower machines.
_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.
