The old code used repeated calls to `ToUnicodeEx` to populate
the translation table, which is slow and buggy. The new code
directly loads the layout driver DLLs from Windows.
See https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4338
Unref private spool_io of GtkPrintJob before setting it to a new one
in gtk_print_job_set_source_file() and gtk_print_job_set_source_fd()
to prevent a leak.
Fixes: #4627
We are no longer using PangoFT2 APIs in this demo, so make sure that we build
it on all builds since we already depend on a HarfBuzz/Pango version that
provide everything that we need here.
Drop the unnecessary pangofc-font.h include as a result.
Like what was done on gtk/language-names.c, acquire the language names via the
native Windows NLS APIs, eliminating a run-time dependency on iso-codes on
Windows.
Instead of relying on the iso-codes package, use the native Windows NLS APIs to
acquire the localized (translated) language names so that we do not need to
incur an extra runtime dependency on Windows. It's not coverering 100% of the
languages that we would like to support through this, but should cover much of
the things that are required.
We aren't really using PangoFT2 for [language|script]-names.c, and are
always using items from them, so make sure they are being built.
Also always include the pangoft2 dependency in gtk_dep if it is found.
We were handling events in the wrong order,
by doing async calls for some of them, but not
for all of them.
And we were not taking into account that GFileMonitors
RENAMED events may or may not move a file on top
of an existing file.
Fixes: #3784
Document the return value and more importantly, specify that a call to
`gsk_renderer_realize()` needs to be matched with a call
`gsk_renderer_unrealize()`.
Prevents issues like https://gitlab.gnome.org/GNOME/gtk/-/issues/4625
Without building the demos, nothing gets installed into $prefix/share/icons/hicolor. Which makes running
`gtk4-update-icon-cache` on the machine causes an error. This is easily reproducible on a Windows machine with MSVC where
there is nothing pre-installed on hicolor icon theme and that makes building gtk without the demos fails with "No such file or directory".
libpng wants to receive samples in either RGB or RGBA order, whether
each sample is big-endian or not. This resolves test failures in
testsuite/gdk/memorytexture.c (and a lot of reftests) on s390x, and
probably the PowerPC family too.
Modifying the test to show the color in use and write out the PNG bytes
to a file, and running the memorytexture test on s390x, produces a PNG
that loads with the correct color values in GIMP (on an x86_64 machine),
which seems like evidence that this is the correct change and not just
compensating errors.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/4616
Signed-off-by: Simon McVittie <smcv@debian.org>
If we ended up on no output at all, keep the HiDPI scale as is, as it
likely means we were on a workspace that was switched away from. By
keeping the same scale, we avoid unnecessary scale changes that would
otherwise take place if the scale when on monitors would end up being
more than 1.
clang-tidy says:
gtklabel.c:1188:15: warning: Although the value stored to 'mid' is used in the enclosing expression, the value is never actually read from 'mid'
min = mid = text_width;
^ ~~~~~~~~~~
Which seems right since mid will be assigned to at the beginning of the
next loop iteration anyway.
If we have a GDK_ACTION_MOVE, we need to delete the selection. However,
previously this only worked when the drop target and drag source were
different applications, as the selection would get messed up along the
way.
Instead, we stash marks for the duration of the operation so that we can
delete the appropriate selection when completing the move.
