GitLab

Following mockups and rewritting it completly to be able
to be used by other projects like gnome-builder and dconf-editor
and sanitize its code.
This GtkPathBar will be only "visual", so no file management is done,
and instead a subclass GtkFilesPathBar in a following patch will
implement file management for the use case of GtkFileChooser and Nautilus.

Useful to know which children cannot be shown, so clients
can manage themselves those.
A use case is GtkPathBar for the popup overflow menu.

It was using the whole allocation to distribute the space,
instead of the actual extra space.

I have to ask Rafał Lużyński why he added it... It makes everything
jumpy when reallocating.

Remove it for now.

i.e. The case of Nautilus and FileChooser GtkPathBar is that we always
want to show the end part of the path. However that might not be the
case for other uses, like gnome-software and its titles.

Extract a function, refactor, and manage the widget visibility
and child visibility at once, and use that for further checks.

This will be useful on a later patch when we add a property to choose
between hiding widget from the start or from the end, so we can allocate
or not children just checking the child visibility.

Instead of acronims

We didn't have a way to hide children given the allocation size
available set by the parent.
This is an use case for the GtkPathBar, which will be rewrote in future
patches where we will want to use a composite widget instead of a all
custom allocation widget.

For that, implement a container which hides widgets when the allocated
size is smaller than the requested size by its children.
The code is made by Rafał Lużyński for gnome-software and is adapted to
Gtk+ standards.

Now will follow a few patches improving the code and adding support
for some features needed by the GtkPathBar.

The Wayland protocol does not share XI2's wealth of information
about individual devices, but it does provide discriminating
information about the source for scroll events. Pass this on to
the application by creating separate slave devices for these,
and setting them as source device on the scroll events.

These devices can be discriminated by their input-source property:
wheel      - GDK_SOURCE_MOUSE
finger     - GDK_SOURCE_TOUCHPAD
continuous - GDK_SOURCE_TRACKPOINT

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

fix up

These changes were caused by the introduction of GtkStackAccessible.

We no longer add the redundant .slider style class in GtkSwitch.
Update expected results to reflect that.

We were not propagating direction changes in some places,
evidently. Now we do.

Embed the label in the middle of the separators instead of
putting it above the separator.

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

What it should look like:
  Bold
----
/Size/
  x 0.5
  x 1.0

What it looks like:
  Bold
  /Size/
----
  x 0.5
  x 1.0

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

This is now done in GDK, so we can just use the input type here.

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

This uses the same heuristics that are currently used in
GtkScrolledWindow.

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

Having this as an input source type will let us do the heuristics
in the GDK backends.

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

GtkHeadeBar checks the window type hint to determine if the regular
buttons such as menu, maximize or iconify should be visible in the
header bar.

However, an application may very well use a "normal" toplevel window and
set it transient and modal afterwards. In such a case, the iconify
button would remain visible, and the user can hide the window, but being
a modal, the parent window would remain insensitive.

Check for the window type, modality and transient relationship to decide
whether or not the regular toplevel buttons should be visible in the
header bar.

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

Print human readable names for axes and axis sources.