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
A popover can go unmanaged for 2 reasons, when the widget it points to
gets destroyed, or transitionally in gtk_popover_set_relative_to(). In
both of these cases it makes sense to only unset popover information
about the previous widget managing it, if the popover is meant to
survive the unmanaging through extra refs.
Also, the focus widget prior to a modal popover being shown is considered
information about the relative_to widget, unset it on
gtk_popover_update_relative_to() with the rest.
https://bugzilla.gnome.org/show_bug.cgi?id=736193
This gives an opportunity for implementations to handle these events
differently, instead of hardcoding the WM-triggering behavior.
gtk_window_event() only forwards events for WM management if the event
widget is not the window (ie. caught when bubbling), so is safe to be
called here without triggering gtk_window_handle_wm_event() twice.
This commit is an adaption to master of
https://bugzilla.gnome.org/show_bug.cgi?id=736702#c1 by Cosimo Cecchi.
If !owner_events, the pointer window has been usually set to NULL if
the pointer fell outside the grabbing widget, but it was not being
checked that the pointer_window is actually a child of the grab
window, in which case it should be obtained as if ungrabbed.
https://bugzilla.gnome.org/show_bug.cgi?id=735749
On regular scrolling (ie. not natural scrolling), positive deltas in the
Y axis (downwards) should actually move the value towards the adjustment
minimum value to be more intuitive. This also makes the scrolling
directions match between the button and the popped up scale.
https://bugzilla.gnome.org/show_bug.cgi?id=736830
