As the program executable name has 'update' in its filename,
gtk-update-icon-cache.exe is considered to be an installer program on 32-bit
Windows [1], which will cause the program to fail to run unless it is running
with elevated privileges (i.e. UAC).
Avoid this situation by embedding a manifest file into the final executable
that tells Windows that this is not a program that requires elevation.
Also make the autotools build files dist the new script and use the new script
to generate the manifest and rc files, instead of hardcoding the generating
bits in gtk/Makefile.am
Fixes issue #3632.
[1]: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc709628(v=ws.10)?redirectedfrom=MSDN,
under section "Installer Detection Technology"
Currently when GTK3 is compiled without G_ENABLE_DEBUG, the inspector
can't be opened with GTK_DEBUG=interactive because it doesn't parse
this env var without G_ENABLE_DEBUG.
Since the inspector is always good to have, this commit now always
parses the GTK_DEBUG env var but only keep the "interactive" flag if
G_ENABLE_DEBUG isn't defined.
fmin() is a function that is introduced with C99/C++11, so check for the
presence of it and provide a simple implementation for it if it does not
exist.
Also update the config.h.win32.in template accordingly, since this
function is provided on Visual Studio 2013 or later.
The size of the cursor depends on either the gtk-cursor-aspect-ratio
GtkSetting or as of the previous commit on the GtkSetting or the
cursor-aspect-ratio style property. GtkTextView was only considering the
style property.
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/3441
The gtk-cursor-aspect-ratio GtkSetting was only recently introduced and
replaced the cursor-aspect-ratio style property. This was causing old
configurations that used CSS to modify this property to no longer apply.
This commit introduces a fallback from the GtkSetting to the style
property if the value of the setting is unchanged.
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/3441
The gtk-cursor-aspect-ratio property got added as a float property.
However there is no parser for float values from keyfiles which meant
that it could not be changed from settings.ini.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3441
When the notebook page does not have a label, it should not fallback to
asking its child accessible for extent, since the child might be asking
exactly the converse when it is a socket, thus getting in an infinite
loop. When the page does not have a label, is does not really make sense to
give it an extent anyway.
Fixes atk#18
The $button_fill hack for button.circular is pretty awkward and is
currently broken. Instead of relying on it, allow the button() mixin to
have an additional background-image optionally.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3354
The existing treeview header button border in GTK3 is close to
invisible. The preferred way to find the border for a treeview column
is to hover the mouse near the beginning of the header button text
expecting the default cursor to switch to 'col-resize' cursor. This
works only when all column headers in the view are left aligned. After
adding a few numeric columns to the view, whose headers are right
aligned, it becomes really hard to find the location of the border
between a left aligned and right aligned column header.
This change addresses the issue by using high contrast colors for
borders of treeview header button - in line with the colors used in
Adwaita theme in GTK4.
See merge request GNOME/gtk!2467
When the level does not include the style, we only
include one face of each family in the list. But we
were just choosing the first face (typically, a light
or extra-light style). Improve this by picking the
default face (normally, the regular face), which is
the expected behavior.
The last event, matching lifting the finger/releasing the mouse button,
is important when there's a large delay between it and the previous events,
as in when performing a movement, stopping, then releasing fingers as
opposed to doing a swipe.
If this event is skipped, doing this will result in kinetic deceleration
matching the previous finger movement, while the expected behavior would
be no deceleration.
See also 97f540622a for a similar fix in
GtkEventControllerScroll.
When GtkApplication starts listening to the screensaver's D-Bus
status, the screensaver-active property is not initialised and
applications making use of the property are out of sync until the
first state change. Any application starting when the screensaver is
active will think it's inactive.
To fix this, we set the property when we first start monitoring the
screensaver.
See https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1091
While it’s true that you can pass the results of
`gtk_file_chooser_get_filename()` straight to `open()` or `fopen()` on
Linux, you can’t do so on Windows as it expects the filename to be in
the ANSI codepage. Using the GLib wrappers `g_open()`/`g_fopen()`
instead means that the appropriate UTF-8 → UTF-16 → `wopen()`/`wfopen()`
conversions are done.
Spotted by Fabian Keßler in
https://gitlab.gnome.org/GNOME/glib/-/issues/2212.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When a plug is embedded in a socket, we need to also plug the at-spi
tree, so that screen readers can find the at-spi content of the plugged
widgets.
This change does this plugging automatically: on the plug widget, an
additional _XEMBED_AT_SPI_PATH property is set to provide the at-spi path
(just like we have _XEMBED_INFO for other X11 information), and when
embedding it, the socket reads it, and makes it as its only child.
Since GtkPlugAccessible can not inherit both from AtkPlug (a child of
AtkObject) and from GtkContainerAccessible (a child of AtkObject), we
actually make GtkPlugAccessible a child of an AtkPlug, and that's what
will be embedded (in at-spi terms) into an AtkSocket.
Similarly, GtkSocketAccessible can not inherit both from AtkSocket and
GtkContainerAccessible, so we make it a parent of the AtkSocket that
embeds the AtkPlug.
This change depends on atk 2.35.1 which implements the at-spi technical
details.
This separates out atk-bridge-2.0 dependency, which is not part of atk,
but of at-spi2-atk.
This implementation is based on gtk_text_view_scroll_to_iter() and
thus shares its limitations for the sake of simplicity.
A single offset is opportunistically picked to build the iterator
needed for gtk_text_view_scroll_to_iter(). That means that substrings
spanning over multiple lines or larger than the current window might
not be displayed optimally after scrolling.
Partially closes#1625, the toPoint() variant has been discarded.
_gtk_settings_get_style_cascade() checks for the given GtkSettings to be
non-NULL, but does so after using the pointer to get the
GtkSettingsPrivate.
Make sure we use the GtkSettings pointer only after the precondition is
verified.
https://gitlab.gnome.org/GNOME/gtk/-/issues/2780
On gdk_display_close(), the GtkSettings attached to the display are
freed.
Yet the gtk CSS code may still be called from the widget unparent,
leading to a segfault.
Check if the GtkSettings is not NULL and bail out nicely if not.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2780
When installing the scroll cursor, add a weak ref to scrolled_window
that clears it if finalised. Unset the weak ref when the uninstalling
the cursor, and when the widget is destroyed.
Patch by Michael James Gratton
Fixes: #749
In gtk_tree_view_build_tree with recurse=TRUE, the TEST_EXPAND_ROW
signal might invalidate the child iterator. Getting the iterator after
the signal (instead of before) fixes the issue.
Fixes https://gitlab.com/inkscape/inkscape/-/issues/1879
Due to the deprecation in gtkshow.h, there is proper deprecation warning
for C code. But, for bindings (python in one case), there is no warning,
due to missing "Deprecated:" annotation in gtkshow.c
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3166
This is not only a GdkEventButton but can also be a GdkEventTouch.
Having this annotation wrong causes bindings code to fail whenever a
wrongly typed event comes through.
Given it does seem likely Tracker is going to miss the goal to get all
applications ported to Tracker 3, the scenario where there's applications
linking to Tracker 2.x while GTK was built with Tracker 3 support becomes
more likely.
Avoid the upcoming GType clashes if that were the case, and resort to the
good (I lie) old Tracker 2 search engine.
