GitLab

The gtk_show_uri API doesn't let us specify a parent window. With
portals, there may be an intermediate dialog, for which it is nice
to have parent window information, to place it properly.

flatpak creates a file called /run/user/1000/flatpak-info that we
can use to determine whether we are in a sandbox or not.

Bail out cleanly when we see GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER
or GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER.

Mention the portal case in the general native file chooser docs,
and give some details.

With GTK_USE_PORTAL=1, try to use the portal even if we if we use
unsupported features. With GTK_USE_PORTAL=0, never use the portal,
as before. What we really want here is to detect the situation
of "sandboxed without full $HOME access" and use the portal in
those cases. If we make the portal smart enough to hand back
direct uris for files that the app can access, we may simplify
the check to just "sandboxed".

Show the fallback dialog in cases where we tried to call out to
portal, but it didn't work.

We can get a D-Bus error back here, and we need to free
the reply in any case.

Send the current_name, current_folder or current_file fields to
the portal.

This will be used to send filters of D-Bus in future commits.

This fleshes out the portal file chooser some more.

The maximum content size does not increase the minimum request
but only ensures that both minimum and natural requests do not
exceed the maximum setting.

Widgets should support size requests before being realized in general,
otherwise this can cause flicker/resize at initial display time as
the toplevel window can make a request before realize/allocate.

This also makes the added testsuite/gtk/scrolledwindow.c test work again,
this was broken because we only ever calculate whether we are going
to use overlay scrollbars once the scrolled window is realized (and
the test case does not realize any window).

This patch does a couple of things:

  o Removes the obscure 'extra_width' and 'extra_height' variables
    making the request code exceedingly difficult to read

  o Fixes the max-content-size properties introduced in bug 742281
    so that they do not grow the minimum request.

  o Cleanup of request code in general:
    - min/max content sizes are clamped around the child request as needed
    - scrollbar requests are only added in one place, after child request
      sizes are calculated and without the extra_width/height thing.

Commit 023f406c has a typo that results
in this error:

../../../testsuite/gtk/notify.c: In function 'test_type':
../../../testsuite/gtk/notify.c:679:54: error: expected expression
before ')' token
    (g_str_equal (pspec->name, "max-content-width") ||)
                                                      ^

A wl_buffer has a max size of 4096 bytes, of which 8 are needed for the
header and another 4 for the string argument length (in this case), so
make sure the we only save the first 4083 bytes that are still valid
UTF8.

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

The allowed values for the max-content- properties depend
on the value of the min-content- properties, in a way that
our simple test is not prepared to deal with. Just skip
them for now.

xdg-shell allows desktop environments to extend the list of states
within a given range.

Use this possibility to add a new state for tiled so that gtk+ can
benefit from this.

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

- make visible regardless of colors used
- make larger and more inset

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

remove box-shadow from colorbutton colorswatch when an ancestor has
the osd styleclass applied.

define outline-color generally using alpha(currentColor, 0.3),
which avoids setting it in a bunch of different places.

If gtk_scrolled_window_add() has added a GtkViewport,
  gtk_container_remove (GTK_CONTAINER (scrolled_window), child_widget);
or
  gtk_container_remove(GTK_CONTAINER(scrolled_window),
                       gtk_bin_get_child(GTK_BIN(scrolled_window)));
removes both the added child widget and the viewport.

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

We can have wrapped or ellipsized labels at an angle nowadays.
Still no selections though.

This is a very longstanding bug; time to finally put it to rest.

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

This is a long-standing problem of GtkScale.

https://bugzilla.gnome.org/show_bug.cgi?id=766372
https://bugzilla.gnome.org/show_bug.cgi?id=578626
https://bugzilla.gnome.org/show_bug.cgi?id=79229

We must allow resetting the properties to -1.

This removes leftover code from when classes where added to the style
context.
Now that they get added directly to css nodes, the classes can exist
without a style context.

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

With the FTS5 query syntax, when using quotes to delimit the search phrase
the '*' token must happen after the quote, or will otherwise be considered
a character to match, go through the tokenizer, and end up ignored in
result.

This reverts commit 0943c9f6.

The commit caused unexpected breakage in gtk3-widget-factory,
and also broke the just-added max-content-size properties.

This gives a nice example of these properties in action,
in the "Open" popover on page 3.

Needed to adjust this again after applying commit 4e5ecb70
for bug 742281. Now that we also have max content size properties,
pushed the addition of possible scrollbar sizes to after the
clause which clamps the child request size into min/max content
sizes.

Commit a01fe140 changed the behaviour of popovers when the focus leaves
them to stop child popovers being hidden when the focus leaves their
parent. However they are now a bit too reluctant to hide - if the
focus passes to an unrelated popover the first popover is not
hidden. Also if the focus passes to another widget that does not
perform a gtk grab then the popover isn't hidden until the user
presses a non-movement key or clicks outside the popover.

The solution is to go back to checking if the focused widget is a
descendant of the popover, but to include popovers and their related
widgets in the ancestry chain.

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

This patch causes the scrolled window default behavior to change in
such a way that the natural size request of the child is unconditionally
reported, which probably should have been the case since day 1.

This should not cause significant fallout since a scrolled window is
normally used to expand/fill, eating up remaining space for scrollable
content - it will however cause the scrolled window to compete for
additional space with siblings, proportionally to the size of the
scrolled window's content.

gtk_tree_view_get_path_at_pos() mistakenly identifies the first
pixel of all but the first column in a tree view as belonging to
the previous column.

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

Old patch found in bugzilla, it still applies and doesn't
cause the test to fail.

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

This was broken ever since we started looking at the
source device of the event.

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

This string can be long, and we don't want to break the ui