GitLab

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.

We could just as well remove these calls here, since they
have no effect.

...and deprecate it, recommending GtkStack as an alternative.

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

Draw them inside of the icons, which is where the text scrolls.

We don't want to maintain this information in two places,
so just link to the online documentation here.

This was causing navigation in the online docs to be confused.

When we emit ::draw, the widget should not have alloc_needed set
anymore. If this happens, it indicates a broken situation. Add a
warning to help tracking down why this might occur.

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

Update the font: syntax to follow css.

Make sure it's obvious what if block it belongs to.

Show only the currently visible child to a11y.

The type is used in widget-factory.ui, so add a dummy definition here to
keep the test working.

since it doesn't always inherit 'color' color as it should.

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