The idea of within-margin is to scroll as little
as possible to bring the mark within the margins
defined by the factor. The code was achieving
that when scrolling down, but not when scrolling
up. This change makes things symmetrical.
Fixes: #4325
Update the functions that were updated in the previous commit to have all
GdkSurface variables named as 'surface' instead of the GTK-3.x-era window, to
make things more consistent across the board. Also fix formatting a bit.
Make the toplevel surface respond to size computations unless it is just being
created, or maximized, made fullscreen or underwent an AeroSnap operation.
This will ensure that the surface size is properly computed in time, so that
surfaces can be resized as needed.
This will fix issues 3728 and 3799.
On Windows with nVidia drivers at least, when we create a legacy context
via wglCreateContext(), we may still get a (W)GL 4.x context. Allow
such contexts to also use GLSL version 130 instead of 110, so that
things do continue to work.
It turns out we can't just use the size returned
by the memory stream as-is, since it may contain
unfilled garbage at the end, which utf8 validation
will choke on. So, cut it off at the first '\0'
we find.
When the iter is at the end of the buffer,
gtk_text_view_get_iter_location returns a
rectangle with width 0, which in turn makes
gdk_rectangle_intersect return FALSE.
Avoid that by always giving the rectangle
non-empty dimensions.
Fixes: #4503
As far as I can tell, the code here is redundant and probably ended up
this way for historical reasons. A drag surface without
`->is_drag_surface` would be created if `gdk_display_create_surface`
were called with `GDK_SURFACE_TEMP`, but drag surfaces never seem to be
created that way.
In `gtk4-demos`, drag and drop and popovers seem to be working normally
with this.
Setting variations to their default value causes
them to show up in the serialization of the font
description - a font description has no idea about
the default values, so can't filter them out.
Avoid that.
Try to compute a min size that matches the current aspect ratio.
This means that when interactively resizing, we adapt the min size to
the current window area dynamically.
And that means that we always have a min size that is large enough, but
users can interactively cause it to be small-width x large-height,
large-width x small-width or anything inbetween.
Printing the affected widget leads people to assume that it is to blame
for the error. However, the widget is the object the function is being
called on, not the caller. And the caller is doing it wrong.
Usually the caller is the parent widget, so we could print that one, but
it's only usually, it can be an issue propagating from a grandparent and
it doesn't tell you from where the function is called (allocation or
measuring), so you need a debugger anyway.
So don't put anything there instead.
