We let these through in GtkEventController::filter, and handle
these especially on GtkGesture::update.

We let these through in GtkEventController::filter, and handle
these especially on GtkGesture::update.

Not too long though, the precautions to take are minimal.

This will make the gesture "center" the pointer position, plus
the accumulated dx/dy throughout the gesture progress.

These will be mutually exclusive with touch events, so it won't
be possible to trigger gestures through mixed input and whatnot.

The accounting of touchpad events is slightly different, there
will be a single internal PointData struct, stored in the hashtable
with the NULL event sequence/key (same than pointer events in
this regard), just that the events stored will be GdkEventTouchpad*,
so will hold information about all fingers at once.

But this difference is just internal, the GtkGesture API doesn't
make explicit assumptions about the number of points (the closest
to a per-point query API is gtk_gesture_get_sequences()). All
signals emitted just contain the last changed GdkEventSequence,
and API takes GdkEventSequences, so everything is consistent with
sequence=NULL for touchpad events.

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.

We'll be dealing with event types and touchpad gesture phases,
replace the switch by a battery of if/elses. Otherwise, it's
just an style change.

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().

The window/coordinates will need translation in the case of touchpad gesture
events, same than with other pointer events.

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.

David King authored Aug 11, 2015 and David King committed Aug 12, 2015

Help applicaiton authors who may already be binding GtkListBox to a
GListModel by describing the change for 3.18.

https://bugzilla.gnome.org/show_bug.cgi?id=753392

A few attribute types were missing from the support:
rise, letterspacing, fallback, font features. Add support
for these.

The first Escape clears the search entry, the second Escape
closes the dialog.

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.

As pointed out by Cosimo, we should sort the
items according to their path.

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.

clang doesn't like those.

This was just not implemented, and the sidebars solid white
background color was inherited by undershoot rectangle.

https://bugzilla.gnome.org/show_bug.cgi?id=753391

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

Make days gray that are not in the current month.

https://bugzilla.gnome.org/show_bug.cgi?id=753357

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

The type of xalign property of GtkLabel is float, not int. Using wrong type
crashes GtkFileChooser on x86_64 when compiling with clang.

https://bugzilla.gnome.org/show_bug.cgi?id=753284

Don't return that a key event was handled when the corresponding
scrollbar can not scroll.

https://bugzilla.gnome.org/show_bug.cgi?id=753256

- provide insensitive button state for GtkCalendar buttons

https://bugzilla.gnome.org/show_bug.cgi?id=753230

It works just as well here as it does in the file chooser, and
this lets us unify the right-click and long-press behavior a bit.
We used to switch directly to the editor on long-press, now we
can show the popover, just as we do on right-click.