printoperation: add some assertions

Let's assert that we schedule the idle callback exactly once.

These assertions are not perfect because if the callback executes before
we schedule it, then the assertion itself would be a use-after-free,
since I'm using the PrinterFinder to track whether the callback that
frees it has been scheduled. But in practice when using loupe's print
dialog, I was noticing the callback scheduled twice before it was
executed. The assertion would have caught this problem.

printoperation: fix another case where operation may complete twice

This is a little tricky. At first, I thought we had a codepath where we
fail to schedule the idle that completes the print operation: if we take
the gtk_print_backend_printer_list_is_done path for each printer
backend, then printer_list_done_cb() is never executed and we never
schedule the idle. But in fact, in this case, then backends == NULL at
the bottom of find_printer(), and we'll schedule the idle there, so it's
OK. Except it's not really OK, because we'll schedule it even if a
printer was already found, resulting in the callback completing twice
and a double free.

Simplify this. Schedule the idle in find_printer() only if there are
*initially* no backends, not also if all backends are immediately ready
and already removed from consideration. Instead, always call
printer_list_done_cb() for every backend in find_printer_init(). After
the previous commit, printer_list_done_cb() will schedule the idle when
appropriate.

printer_list_done_cb() additionally disconnects signals that we did not
connect in this codepath, but it does so using
g_signal_handlers_disconnect_by_func, which is harmless. Otherwise, the
only extra work it's doing is scheduling the idle, and that's exactly
what find_printer_init() is missing.

printoperation: fix case where operation may complete multiple twice

If we are the final backend, then after removing ourselves there is no
backend remaining. We will schedule the idle even if it has already been
scheduled. This idle is required to run exactly once and executing it
twices results in a double free that crashes loupe when printing. It
also causes the user callback to execute twice, which could cause
similar problems.

Fixes #6122

gsk/gl: use GdkArrayImpl for tracking modelview

Like the previous change, this uses GdkArrayImpl instead of GArray for
tracking modelview changes. This is less important than clip tracking
simple due to being used less, but it keeps the implementation synchronous
with the Clip tracking code.

gsk/gl: use GdkArrayImpl for Clip tracking

We can end up spending a lot of time in g_array_maybe_expand() through the
use of g_array_set_size() for clip tracking. That is somewhat due to the
simple nature of GArray being size-dynamic. Instead, we can use
GdkArrayImpl and let the compiler do what it does best to elide some
work and hoist other work into the calling function.

This also fixes a potential UAF in gsk_gl_render_job_push_contained_clip().

gdk: add missing G_END_DECLS to gdkarrayimpl.c

broadway: Do not add an extra reference when caching textures

We just created a GdkTexture, so we don't need to acquire a reference if
we're transferring the ownership to the node cache.

broadway: Plug another leak

When getting a colorized texture we're downloading the texture as a
Cairo surface, and then feeding it to another texture, but we never drop
the reference of the new surface.

docs: Clarify the behaviour of gdk_texture_new_for_surface()

Cairo surfaces are not GObject instances, so we should be more explicit
in the behaviour of the memory management, to avoid leaks.

broadway: Plug a leak in the GSK renderer

We are leaking the Cairo image surface when creating a new node.

Fixes: #6120

array: Compute new size properly

Using "1 << x" means that we are shifting a signed 32bit integer, but we
want a gsize, which is an unsigned 64bit integer.

So now we don't overflow anymore if the array reaches a size of 2GB.

gdk: Fix compiler warning

gcc's -Wlto-type-mismatch found the hack, where we copied the wrong
prototype.

treeview: Fix crash in assertion

The fix in commit a267dfac5d25d4ba5c1a95c82999d008fee07ac3 is wrong.
The function can return FALSE in normal operation.

Instead do a check for node == NULL that gracefully returns FALSE instead.

Fixes: #6114

Improve FOO_DEBUG=help output

Explain the all value a bit better.

dialog: Check header bar type before calling track_default_decoration()

Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/6116

header-bar: Add a precondition to track_default_decoration()

gtk-demo: Fix a refcounting mishap

gtk_font_dialog_button_new's argument is
transfer full.

Fixes: #6113

docs: Mention for what GtkStringObject:string is useful

docs: Link GtkStringObject from GtkStringList

A frequently asked question is: "what is the object type inside a
GtkStringList", so let's make the answer more obvious.

docs: Add a link to the DropDown:selected property

The main description is a bit too coy, and some newcomers don't
understand the concept of properties and notification.

Update German translation

Update Lithuanian translation

Update Brazilian Portuguese translation

Update Polish translation

Update Esperanto translation

Update Persian translation

Update Hungarian translation

Update Basque translation

Update Ukrainian translation

Update Kazakh translation

Merge branch 'fix-issue-6080-gtk-4-12' into 'gtk-4-12'

GdkWin32: Unref GdkMonitor after calling gdk_monitor_invalidate () [4.12]

See merge request GNOME/gtk!6412

Update Czech translation

Update Galician translation

Updated Spanish translation

Updated Spanish translation

Update Georgian translation

Update Turkish translation

Update Swedish translation

Post-release version bump

4.12.2

gtk4-demo: Fix a crash

This conversion of GtkStatusbar was a bit too
quick.

Fixes: #6107

gdk/wayland: Use toplevel surface for activation

At the moment of launching/activating an application, the
keyboard focus may be on a transient surface that quickly
disappears after activation. If this happens, and the
compositor handles surface destruction before the activated
application gets to reply, the activation request may be
deemed outdated, and the "demands attention" paths be taken.

Peek the toplevel from the focus surface, as that has larger
guarantees to remain valid for the whole duration of the
operation.

Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5820

gtkwindow: Pick a suitable widget to continue the implicit grab

When a widget in the GtkPointerFocus stack becomes insensitive, we've
so far broken the implicit grab entirely. This has the side effect of
breaking accounting of the active state on the widgets that are
ancestors of the widget that became insensitive.

The easiest, and most consistent thing to do (i.e. giving widgets
in the GtkPointerFocus stack certain level of isolation wrt state
changes in other widgets) is to transfer the implicit grab to the
topmost actor of the GtkPointerFocus stack that can keep handling
events.

This fixes the unbalanced accounting of active state on ancestors
of widgets becoming insensitive, and avoids thorny questions about
how to handle implicit active state with broken implicit grabs.

gtkwindow: Clear active state on sensitiveness changes

When altering the broken implicit grab due to sensitiveness changes,
also ensure to clear the active state from the affected actors. This
fixes unbalanced implicit active state accounting on the widgets going
insensitive.

Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5529

gtkmain: Drop redundant code

The common ancestor is already figured out at the beginning of the
function, no need to find it again.

text: Respect focus-on-click property

It does make sense to have GtkText not focus on click in some cases,
such as when its editable property is set to false.

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

colorbutton, fontbutton: Propagate focus-on-click to inner buttons

These widgets wrap a GtkButton internally. Make it possible to prevent
the inner button from grabbing focus on click by propagating the value
of the focus-on-click property from the widget to the inner button.

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

gsk: Fix clipping error when drawing shadows

When shadows were offset - in particular when offset so the original
source was out of bounds of the result - the drawing code would create a
pattern for it that didn't include enough of it to compose a shadow.

Fix that by not creating those patterns anymore, but instead drawing the
source (potentially multiple times) at the required offsets.

While that does more drawing, it simplifies the shadow node draw code,
and that's the primary goal of the Cairo rendering.

Test included.

gl: gradients should transition in unpremultiplied space

So make the gradient shaders do that.

inspector: Don't set a NULL fontdesc

The font dialog button does not like that.

Fixes: #5988

treeview: No gcc, node is not NULL

... so I'll add an assertion just for you.

treemodelfilter: Yes gcc, both if branches are empty

... if assertions are disabled.

render-node-tool: Actually load files properly

gl: Change rounded_rect_shrink()

The code now follows gsk_rounded_rect_shrink() and with it the behavior
of the Cairo renderer and Webkit.

The old code did what the GL renderer and Cairo do, but I consider that
wrong.

I did not test Chrome.

Test attached

css: Snapshot opacity filter as opacity node

We were using color-matrix because it was easier, but opacity can often
be optimized when color-matrix needs offscreens.

glrenderer: Shadows without offset do exist

Not for opaque contents, but stuff can be semi-transparent.

Testcase included.

rendernode: Shadow nodes need offscreen for opacity

Otherwise the shadow will not be properly computed as opaque regions
become translucent after applying opacity.

Testcase included.

switch: Fix CSS nodes documentation

A switch contains two GtkImage's whose nodes are named 'image',
not 'label'.

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

switch: Respect text direction

In RTL, we want the active state to mean the handle is on the left.

Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/1489

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

gl renderer: Don't assume an atlas

The source uniform may or may not point
to a glyph atlas. The optimization we do
for color nodes is only possible if it does,
so check this.

Fixes: #6094

gl renderer: Keep track of source

We have an optimization that depends on having
the source be a glyph atlas, so keep track of
that information in the render job.

rendernode: Fix handling of color glyphs

The rendernode parser was mixing up its flags.

Test included.

Related: #6075

macOS: Fix typos

Fix documentation of gdk_display_put_event()

This function is deprecated, but we should still document it properly.
It appends, not prepends. This is clear enough from its implementation,
but also we have practical experience with WebKit in:

https://github.com/WebKit/WebKit/pull/8663

Matthias prefers to avoid the prepend, append, start, and end
terminology altogether.

wayland: Bind correct xdg_wm_base version

Otherwise we won't get the suspend state.

Fix typo

rendernode-tool: Fix array size

Also add an assertion, so things explode properly if we forget to
update the array size when adding new nodes, instead of writing random
memory.

rendernode: Fix Cairo rendering of repeating gradients

Cairo and the GL renderer have a different idea of how to handle
transitioning of colors outside the defined range.

Consider these stops:
  black 50%, white 50%

What color is at 0%?

Cairo would transition between the last and first stop, ie it'd do a
white-to-black transition and end up at rgb(0.5,0.5,0.5) at 0%.
GL would behave as it would for non-repeating gradients and use black
for the range [0%..50%] and white for [50%..100%].
The web would rescale the range so the first stop would be at 0% and
the last stop would be at 100%, so this gradient would be illegal.

Considering that it's possible for code to transition between the
different behaviors by adding explicit stops at 0%/100%, I could choose
any method.
So I chose the simplest one, which is what the GL renderer does and
which treats repeating and non-repeating gradients the same.

Tests attached.

entry, searchentry: Fix measuring baseline

If the entry has icons, we may end up increasing our minimum and natural
height compared to the values the text child returned. In that case, we
should also adjust the baseline values to account for the text being
shifted down.

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

centerlayout: Fix measuring in presence of baselines

The measure logic (unlike the allocation logic) was enforcing strict
baseline alignment of child widgets even if no child widget had valign
set to baseline. This was causing GtkCenterLayout to request more size
than it actually needed.

Instead, bring the logic closer to that of GtkBoxLayout by introducing
explicit have_baseline and align_baseline variables. We track and report
baseline if have_baseline gets set, but it only affects our reported
minimum and natural sizes if align_baseline ends up set, which happens
if there's a child widget that has valign set to either one of the two
baseline values, and itself reports a valid baseline.

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

theme: use relative font sizes

This allows text to properly scale when changing the default font size.

composetable: Warn for things we can't handle

The compose table stores the keyvals to match against
in a guint16 array, so it can't handle directly encoded
Unicode codepoints (which have a high bit set). Warn
if we encounter those.

composetable: Accept short compose sequences

Followup to 8931169e0026b2db. That commit did
not do enough work to actually accept sequences
of lenth 1, as pointed by Mike Fabian.

Add test case for single char compose sequence

gsk: Clean up standalone headers

We require folks to include gskglrenderer.h in order
to create a GL renderer. So we be careful to only
include header in gskglrenderer.h that won't trigger
ugly warnings.

See !6363

testsuite/gsk: add explicit dimensions to <svg> elements

Without an explicit width, height, and viewBox, there is no single
correct way to render an SVG. In the absense of said information,
librsvg is capable of making a guess by rendering the SVG to a Cairo
surface and then analyzing that surface; however, this process is
merely heuristic.

There are three GTK tests for SVG images that are missing dimensions.
While this is not a violation of the SVG specification, it does
implicitly couple the test to the librsvg rendering heuristic. In this
commit we add that dimension information so that the expected result
is unambiguous.

snapshot, gsktransform: Mention that rotation happens around (0, 0)

...and not around the center of the render node, as one could expect
given that the render node syntax for rotation, transform: rotate(90);,
happens to match the CSS syntax for the same thing, and CSS does rotate
around the center by default.

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

snapshot: Fix push_repeat () with empty child bounds

The logic would confuse empty child bounds (in which case nothing should
get rendered) with NULL child bounds (in which case the child node's own
bounds should get used). In fact, if the child bounds are empty, we can
discard the descendant render nodes completely, getting a nice little
optimization.

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

demo: Fix a bug without GL

The gears widget was just not unrealizing properly
when GL is not available. Fix that.

Fixes: #6059

GdkWin32: Unref GdkMonitor after calling gdk_monitor_invalidate ()

Ensure that we have a reference when calling gdk_monitor_invalidate ()

Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/6080

Update Dutch translation

Update Chinese (China) translation

Update Chinese (China) translation

Update Latvian translation

Update Slovenian translation

Merge branch 'macos-gtk-4-12' into 'gtk-4-12'

macOS: Clamp damage region to surface size [GTK 4.12]

See merge request GNOME/gtk!6389

Update Italian translation

macOS: Clamp damage region to surface size

...in _gdk_macos_cairo_context_begin_frame ()

GdkMacosCairoContext needs regions that are clamped to the
actual surface size.

Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/5812

Merge branch 'gtk-4-12-ssd' into 'gtk-4-12'

[4.12] win32: Fix minimize and maximize buttons missing on ssd

See merge request GNOME/gtk!6367

Update Brazilian Portuguese translation

Updated Spanish translation

Update Indonesian translation

Update Korean translation

Update Czech translation

Update Hungarian translation

Update Galician translation

Update Lithuanian translation

Update Danish translation

Update German translation

win32: Fix minimize and maximize buttons missing on ssd

Completely fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/5142