Along the code, we're basically asking for 1) the total count of
touchpoints, and 2) the number of active touchpoints (not denied
nor ended).
Wrap both usecases into a _gtk_gesture_get_n_physical_touchpoints(),
and replace all occurrences.
The gestures that don't want touchpad gesture events are majority,
even those that want such events will only listen to subsets (eg.
pinch, swipe,...).
So it makes sense to ignore touchpad events by default, and let
subclasses opt those in.
This will be used right before handle_event() in order to filter
out events, useful to make the previous "no touchpad events" behavior
the default, and have gesture subclasses include manually the touchpad
events they handle.
For all other events, we run the bubble phase deep in the specific
::motion/button-press/release/touch handlers.
For touchpad events, it doesn't make sense to use GtkWidgetClass
slots if the intended way to deal with these are gestures, so we
run the bubble phase directly from gtk_widget_event_internal().
Each gesture type has its separate GdkEvent struct, and begin/update/
end/cancel event types.
There is support for multi-finger swipe (3-4 fingers), and 2-finger
rotate/pinch gestures.
Do not call _gtk_icon_helper_clear explicitely when the properties
are set, since the corresponding _gtk_icon_helper_set_* method
already calls clear internally.
While at it rename the reset function to make it clear that it
is calling notify for the previous image type and avoid the
notification if the image type is not changing.
We have a testcolorchooser test, with a --edit option. It was
supposed to make the color chooser come up in edit mode, but
it didn't work ever since we dropped the ::response handler.
Fix it by resetting show-editor on unmap, instead of on map.
This way, users can set show-editor before showing the dialog,
and it will take effect.
Since we're dealing with networks, terms like "Eject" or
the eject button are misleading, since we're not actually
ejecting but disconnecting.
Fix that by showing the appropriate icon and tooltip.
We are not showing the URL of network locations
anymore, since they are distracting and not
necessary.
The code, however, forgot to cleanup the URL,
so we are still showing the URL for network
locations.
Fix that by properly cleanup the URL for network
locations.
The .button:link .label selector matches any label "inside" a
link button. And a label inside the context menu counts as inside
for this purpose. This causes the text-decoration property to
leak into the context menu, even though the property is not
inherited. Avoid this by tightening the selector to
.button:link > .label.
https://bugzilla.gnome.org/show_bug.cgi?id=753451
When we connect to a server, the default and expected
behavior is going to the default location, which usually
is the home directory or a writable directory.
GtkPlacesSidebar behaves properly, while GtkPlacesView
doesn't.
Fix that by jumping to the default locations instead of
the root location.
Don't use gtk_widget_show_all() on row widgets because that would
unconditionally show all of its children. This might be unwanted in case
the row implementation wants to keep some of its children hidden.
This commit changes it to use show() instead of show_all() and relies on
the row widget to control the visibility of its children itself as
appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=753392
GtkFileSystem has a complicated way to handle cancellables.
You keep the cancellable pointer that is returned by
_gtk_file_system_get_info and similar methods so that you can
cancel the operation, but you do not own a reference to it.
The only place where it is ok to unref a cancellable is in
your callback, which gets handed a cancellable that you need
to unref at the end. You are expected to compare it to the
pointer you stashed away to find out if the operation has
already been superseded by a newer call, in which case you
disregard the results.
GtkFileChooserButton was following these rules for most of
the cancellables it keeps around, but it was sometimes unreffing
the cancellables that are stored in the model, which could lead
to refcount confusion and crashes. This commit makes it follow
the rules for that case too, which fixes the crash in the bug
below, and does not show up any leaks in valgrind under light
testing.
https://bugzilla.gnome.org/show_bug.cgi?id=737804
The recent change to the enum declaration for GtkCssChange actually
relied on compiler-dependent behavior, which also breaks the build on
some non-GCC compilers, such as Visual Studio. As noted in the
G_STATIC_ASSERT line just beneath this declaration, we need to change
this enum declaration to #define's, in order to fix the build in such
situations.
https://bugzilla.gnome.org/show_bug.cgi?id=752814
