This adds both a compile time check for the SDK version being
compiled against, as well as a runtime check in the case the
resulting binary is run against an older SDK.
https://bugzilla.gnome.org/show_bug.cgi?id=735054
Add some docs/example about the possible event handling ordering issues
that may appear on GtkGesture::begin between multiple gesture groups.
Mostly relevant for state changes.
The remaining code assumes that the dialog doesn't get destroyed, but
it actually does on delete-event.
In particular, the filter function and the preview text are lost as
soon as the dialog is created and thus when we create a new dialog we
don't have those properties to set on it anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=719936
Factor out the typename-to-get-type mangling as a separate
function, for easier testing.
Also fix some cases where it doesn't, currently, like
GString -> g_string_get_type and
GdkRGB -> gdk_rgb_get_type
The scale in the selectable listbox in page 2 of gtk3-widget-factory
has the flaw that the row is getting selected even when one only
interacts with the scale - unlike e.g. the checkbutton and button
further down in the listbox.
The problem is that GtkRange is trying to claim the sequence for
the drag gesture from the ::pressed handler of a multipress
gesture. Since the drag gesture hasn't seen the sequence at this
point, that is ineffective.
The fix here is to rearrange the gestures so that the multipress
gesture sees the sequence before the drag gesture, and then
claim the sequence from the ::drag-begin handler.
Binding signals can return a boolean indicating whether they
handled the event. Use that here and return FALSE if the
inspector keybinding is disabled.
Loading a builder file with a window leaves a ghost behind, since
windows need to be explicitly destroyed. Avoid that by using
gtk_builder_add_objects_from_resource.
When closing the inspector before the main window, we must take
care to sever all signal connections and weak refs, otherwise
things will go bad when the window is closed later.
When GtkGestureMultiPress::released happens, in_button should be unset
after emitting GtkButton::released, whose default implementation uses it.
Moreover, in_button should only be unset there for real touch events, not
guaranteed to trigger crossing events, as opposed to every pointer/touch
events from touchscreens.
https://bugzilla.gnome.org/show_bug.cgi?id=737297
Instead of hardcoding these actions, consult the settings.
Note that not all of the actions supported by gnome-shell are
implemented here, only maximize, minimize, lower, and menu.
https://bugzilla.gnome.org/show_bug.cgi?id=729782
These match the GSettings that mutter/metacity/gnome-shell have
for this. We change the default for the middle-click action to
none, since lower is just a terrible default.
We're slightly bending the rules here, since we're adding new
settings after .0, but a) it is just barely after .0, and b) settings
are not really application API.
https://bugzilla.gnome.org/show_bug.cgi?id=729782
Some recent refactoring changed things so that in_button is no
longer TRUE when released() is called for touch events. As a minimal
fix, let GtkButton do more of the work by chaining up to its
pressed and released handlers, which know how to handle touch
events. This could be further improved by leaving more of the
state handling to GtkButton, like it was done for GtkToggleButton.
If we have a fullscreen window that covers a monitor, desktop
chrome is not relevant for placing of menus and other popups.
Therefore, return the full monitor geometry instead of the
workarea in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=737251
