Fixes: #7043

All other code paths with goto fallback clear it, this makes the behavior consistent with them

wayland: Use the same default cursor size as gsettings schema

See merge request GNOME/gtk!7758

wayland: Clear settings_portal when going to fallback with no portal settings

See merge request GNOME/gtk!7759

Currently it's looked up only in /usr/share what is a problem for non-FHS distros like NixOS

wayland: Look for default cursor theme in XDG directories

See merge request GNOME/gtk!7767

Move the code that realizes an AT context if the parent is realized,
into to a separate function. This will make the next patch easier to
read.

No functional changes.

Upon joining the a11y tree. And do so recursively, as long as the parent
is also not a widget.

As for the explanation, please grab a mug of your favorite drink. It's
a little complicated.

GTK realizes AT contexts in 3 situations:

 1. When it's a toplevel, it's realized unconditionally
 2. When the widget is focused
 3. When the accessible is appended to a realized parent

Most importantly, GTK lazily realizes accessibles, and does not realize
child accessibles recursively.

Clearly, conditions 1 and 2 only ever happen for GtkWidgets, which are
accessible objects themselves. These two conditions will handle the vast
majority of cases of apps and platform libraries.

However, there are non-widget accessibles out there. GTK itself offers a
non-widget accessible implementation - GtkAtspiSocket - which is used by
WebKitGTK.

Now, let's look at WebKitGTK use case. It'll demonstrate the problem
nicely.

WebKitGTK creates the GtkAtspiSocket object *after* loading most of the
page. At this point, there are 2 possibilities:

 1. The web view widget is focused. In this case, the AT context of the
    web view is realized, and GTK will realize the GtkAtspiSocket when
    it is added to the a11y tree (condition 3 above).

 2. The web view widget is *not* focused. At some point the user focuses
    the web view, and GTK will realize the AT context of the web view.
    But remember, GTK does not realize child accessibles! That means
    GtkAtspiSocket won't be realized.

This example demonstrates a general problem with non-widget accessibles:
non-widget accessibles cannot trigger conditions 1 and 2, so they're
never realized. The only way they're realized in if they happen to be
added to an already realized accessible (condition 3).

To fix that, the following is proposed: always realize non-widget
accessibles, and also of their non-widget accessible parents. This is
not ideal, of course, as it might generate some D-Bus chattery, but GTK
does not have enough information to realize these objects at more
appropriate times.

[gtk-4-16] atcontext: Always realize non-widget accessibles

See merge request GNOME/gtk!7789

We no longer say GDK_DEBUG=gl-prefer-gl, we say GDK_DISABLE=gles-api.

The last part of logic in gtk_scrolled_window_measure () that accounted
for scrollbars was handling the hscrollbar first, and vscrollbar second.
For each of them, it looked at the orientation we're being measured in,
and either added or MAX'ed scrollbar's size request into ours (or not,
depending on scrollbar policy and whether overlay scrolling is used).

In case of GTK_ORIENTATION_HORIZONTAL, this resulted in

    // MAX in hscrollbar width.
    minimum_req = MAX (minimum_req, min_scrollbar_width + sborder.left + sborder.right);
    // Add in vscrollbar width.
    minimum_req += min_scrollbar_width;

whereas for GTK_ORIENTATION_VERTICAL, it was

    // Add in hscrollbar height.
    minimum_req += min_scrollbar_height;
    // MAX in vscrollbar height.
    minimum_req = MAX (minimum_req, min_scrollbar_height + sborder.top + sborder.bottom);

The former is correct and the latter is wrong: we should be adding the
size requests of the scrollbars together, and MAX'ing them with the
content size request.

Fix this by refactoring the logic to first handle the MAX'ing, and then
the addition.

This fixes the following criticals:

Gtk-CRITICAL **: 17:26:51.406: Allocation height too small. Tried to allocate 15x31, but GtkScrollbar 0x2a00fac0 needs at least 15x46.

that were happening when all of:
- scrollbar policy was set to ALWAYS,
- overlay scrolling was disabled,
- the scrollable child was really small.

Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>

Fortunately, it didn't impact string length.

Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>

It is possible that the window gets unrealized while a handle to its
surface is exported. This, naturally, invalidates the handle, so there
is nothing left to unexport. We should just note that and do nothing,
rather than crashing.

Fixes a crash when a portal-backed file dialog parented to a window is
closed after the window it was parented to.

Reported-by: Ivan Molodetskikh <yalterz@gmail.com>
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>

When setting a new paintable, we don't need to queue_resize() when it's
the same size as the old paintable.

This is especially useful when pictures are used in a listview or
gridview and different rows display images of the same size.

It is useful to track down mysterious crashes in ci, but it causes
sporadic test failures, so disable it for now, until we have another
mysterious crash.

The original intent was to only realize parents recursively for
non-widget accessible objects. The implementation, however, always
try to realize parents. In the case of GtkStackPage, which is a
non-widget accessible with a widget accessible child, this breaks.

Only realize non-widget accessible parents recursively if the
current accessible is not a widget as well.

Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/7058
Fixes 6074a18e


(cherry picked from commit 06f08ea8)

We only need a display to negotiate dmabuf formats. Pass that
directly, instead of getting the display of the GL context as
we did so far.

With this,

GSK_RENDERER=vulkan GL_DISABLE=gl gtk4-demo --run video_player

still uses dmabufs.

Related: #7048

Split this clearly into two cases: dmabuf or gl memory.

Calling gtk_media_stream_realize is not mandatory, but we can
still try to make dmabufs happen. Tested by removing the realize
call from GtkVideo and using GDK_DISABLE=gl.

This code had too many early exits and was leaking GL contexts
and Gstreamer elements. Simplify.

Separate out the caps for dmabuf, gl and memory and add them
when appropriate.

Add a uses-gl property to our sink implementation, and use
it in the paintable code. This avoids juggling a second gl
context, with the risk of leaking it.

Just create the context when it is needed.

[gtk-4-16] atcontext: Only recurse parents for non-widget accessibles

See merge request GNOME/gtk!7795

Fix testsuite setup

See merge request GNOME/gtk!7792

Fix testsuite setup

See merge request GNOME/gtk!7794

We may not have a surface (since realizing media streams is optional),
so use the display when creating a gl context.