GTK2 uses different gtk.def files on 32-bit and 64-bit Windows. GTK2
source tarballs ship pre-generated gtk.def for 32-bit Windows. If the
user wants to build for 64-bit Windows, the pre-generated gtk.def must
be deleted before the build to force regeneration, or it will fail to
link with 'symbol not defined' errors because the 32-bit Windows build
includes more legacy functions than the 64-bit Windows build.
While users who want to build for 64-bit Windows can delete gtk.def in
the build script, which is currently what most build scripts do, doing
so breaks out-of-source build. On AUR, MinGW packages are usually built
and packaged in the following order:
1. Run 'configure' and 'make' to build for i686-w64-mingw32.
2. Run 'configure' and 'make' to build for x86_64-w64-mingw32.
3. Run 'make install' for i686-w64-mingw32.
4. Run 'make install' for x86_64-w64-mingw32.
It fails because step 3 sees gtk.def left by step 2, which is generated
for a different build. In step 3, make sees the gtk.def change and runs
libtool to relink libgtk-win32-2.0-0.dll. libtool fails to find a lot of
necessary libraries, decides that it is not possible to build a DLL with
-no-undefined, and produces only the static library. It then tries to
relink executables with the static library, and fails with undefined
reference to 'IID_IUnknown' because -Wl,--start-group isn't used and
the use of -Wl,-luuid prevents libtool from using the correct order.
To resolve the problem, move gtk.def to builddir so different builds can
have different gtk.def files while sharing the same source tree. This
also means that the source tarball will no longer include pre-generated
gtk.def file, which should be acceptable because it is already broken on
64-bit Windows.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3029
Segfault occurred when displaying two windows on different X11 displays.
valgrind said:
Invalid read of size 8
at 0x4A20962: _gtk_style_init_for_settings (gtkstyle.c:398)
by 0x49ED785: gtk_rc_get_style (gtkrc.c:2036)
by 0x4AC39C2: gtk_widget_reset_rc_style (gtkwidget.c:6601)
Address 0x70b8e80 is 560 bytes inside a block of size 1,024 free'd
at 0x48399AB: free (vg_replace_malloc.c:530)
by 0x51180D6: g_type_free_instance (in /usr/lib/libgobject-2.0.so.0.6000.6)
by 0x49E98CE: gtk_rc_reset_styles (gtkrc.c:1702)
by 0x49E9A0C: _gtk_rc_context_get_default_font_name (gtkrc.c:1740)
by 0x4A20961: _gtk_style_init_for_settings (gtkstyle.c:396)
by 0x49ED785: gtk_rc_get_style (gtkrc.c:2036)
by 0x4AC39C2: gtk_widget_reset_rc_style (gtkwidget.c:6601)
Block was alloc'd at
at 0x483877F: malloc (vg_replace_malloc.c:299)
by 0x51BD289: g_malloc (in /usr/lib/libglib-2.0.so.0.6000.6)
by 0x519F673: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6000.6)
by 0x51A62BA: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.6000.6)
by 0x5119141: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.6000.6)
by 0x513563D: ??? (in /usr/lib/libgobject-2.0.so.0.6000.6)
by 0x5136A54: g_object_new_with_properties (in /usr/lib/libgobject-2.0.so.0.6000.6)
by 0x5136B51: g_object_new (in /usr/lib/libgobject-2.0.so.0.6000.6)
by 0x49ED774: gtk_rc_get_style (gtkrc.c:2035)
by 0x4AC39C2: gtk_widget_reset_rc_style (gtkwidget.c:6601)
CREATEPROCESS_MANIFEST_RESOURCE_ID is a macro defined in winbase.h,
so we need an include to resolve that macro to its value, 1.
Without that it stays as a literal CREATEPROCESS_MANIFEST_RESOURCE_ID,
and ends up in the .exe file as-is, and Windows can't find it by that name,
resulting in UAC manifest not working and gtk-update-icon-cache bringing
up UAC prompt.
This updates the introspection build process that we also check on
changes in the Makefiles when we generate the NMake Makefile snippets
and file lists, so that any changes to the source file list can be
reflected. Also ensure that we build against the freshly-built
libraries.
Make the NMake Makefiles also output the built introspection items to
the output directories of the various Visual Studio versions, according
to the build configuration and architecture, so that we avoid confusion
for different Visual Studio build configs.
In GLib-2.57.3 and later, GStatBuf may not be a struct stat on Windows,
depending on the architecture and the compiler used, so we can't just
call fstat() on the GStatBuf.
Instead, we need to use the correct CRT function to call on the
GStatBuf, which is as follows:
-_fstat32() for Windows 32-bit builds on mingw-w64 and MSVC
-_fstat64() for Windows 64-bit builds on mingw-w64
-stat() for Windows 64-bit builds on MSVC, and on all other platforms.
Don't pass in G_LOG_DOMAIN=\"...\" to the CFlags that is passed into the
generation the NMake Makefiles. This will avoid the introspection scanner
from choking because the resulting NMake Makefiles may not have that
CFlag escaped properly, and it is not really needed for building the
introspection binary.
Replace "stat struct" with "GStatBuf" and "stat" with "g_stat" where
appropriate to fix cross-platform issues, specifically on Windows.
Code should be identical on *nix but fixes some serious issues
on Windows:
- Field widths of "struct stat" are not constant on Windows.
If the stat function does not match the stat struct used
it will cause overwrites and undefined behavior
- The Windows stat function needs a properly encoded filename.
In many places we pass an UTF-8 encoded value which breaks as soon
as non-ASCII characters are involved.
https://bugzilla.gnome.org/show_bug.cgi?id=787772
If the name of the bookmark is NULL, using it with the printf %s format
specifier is undefined behaviour per the C Standard. Besides, it would
result in a completely unhelpful tooltip even if it were well-defined.
We already have an else case for when nothing is selected, which avoids
trying to use the name, so ensure we go there if it's NULL or empty too.
https://gitlab.gnome.org/GNOME/gtk/issues/1169
GCC 8.1 added some new warnings, including warning about parentheses
with no effect in variable declarations. GTK2 headers have a few of
these, which produce a lot of warnings in projects using GTK2.
The warnings look like:
/usr/include/gtk-2.0/gtk/gtkfilechooserbutton.h:59:8: warning:
unnecessary parentheses in declaration of ‘__gtk_reserved1’ [-Wparentheses]
void (*__gtk_reserved1);
^
Removing the parentheses is harmless and fixes the warnings.
When we found an icon with exactly the requested size, we'd stop
searching immediately (good), but we'd neglect to set the returned
min_difference to 0 (bad). This caused theme_lookup_icon() to
prefer other, potentially much worse, matches over the exact one.
Cherry-picked from 5aa939dc (gtk-3-22)
https://bugzilla.gnome.org/show_bug.cgi?id=792738
glib-2.54.3 changed API, compared to glib-2.52.3 and gtk+-2.24.31's
expectations. This commit fixes the resulting issue in a backwards
compatible way.
See-Also: https://bugs.gentoo.org/650536
Due to the recent changes introduced in glibc 2.27 "%OB" is the
correct format to obtain a month name as used in the calendar
header. The same rule has been working in BSD family (including
OS X) since 1990s. This simple hack checks whether "%OB" is supported
at runtime and uses it if it is, falls back to the old "%B" otherwise.
Closes: #9
If the call to set_parent() failed, we were still adding the child to
the internal list of children, despite that it was not really added.
That meant we could later try to do invalid stuff with that non-child.
Fix that by asserting and giving up if the child that the user is
attempting to add is already parented.
https://bugzilla.gnome.org/show_bug.cgi?id=701296
…from priv->button. My refactor to g_signal_disconnect_by_data()
included this widget, when I shouldn’t have as both modes use it.
In GTK+ 3, this broke opening a CB by keyboard that was in menu mode,
if it had been in list mode initially (e.g. due to the theme).
Fix by moving to disconnect_by_func() and only removing in each mode’s
destroy() method the signals that it set on the button in its setup().
https://bugzilla.gnome.org/show_bug.cgi?id=788577
This gives consistent behavior with e.g. Qt, Mozilla's suites and
LibreOffice (with non-truly native backends like "gen" and "gtk",
but unlike "gtk2" and "gtk3" ones that probably use true GTK menus).
This behavior is expected by at least some accessibility users, and
it seems good to behave like other common applications and toolkits
in this area. There should be no issue in doing so either for current
users, as it only enters the submenu instead of not doing anything.
https://bugzilla.gnome.org/show_bug.cgi?id=778811
ComboBox warned in the doc for :row-span-column that the value must not
exceed :wrap-width, but :wrap-width does not interact with the number of
rows; it’s the :column-span-column that’s relevant.
Also: Warn that spans must be > 0 for rows too, & that column spans <=
:wrap-width are also not useful for items at menu column positions > 0.
Rrefer to items having spans, not values, as we’re already talking about
values in the model (& rows in the menu). And clarify :wrap-width a bit.
This was requested in bug 554926.
Backport of original commit e3bd926c1ef83027c756488ba19f4353930fc6db by
Gabor Kelemen, kelemeng at gnome dot hu, applied to GTK+ 2.90.5 on Tue,
10 Aug 2010 04:13:22 +0000 (UTC).
https://bugzilla.gnome.org/show_bug.cgi?id=785165
Various disconnections had the wrong flags and/or data, so we failed to
disconnect a pile of signals, shown by 0 returned by the disconnect_*()
functions. Fix this, and use the nicer disconnect_by_*() while here.
set_transient_for(toplevel) was only called in list_setup(). It was easy
to make a test showing a NULL :transient-for instead of the correct one.
So, move the call from list_setup() to real_popup(). Also do the same
for window_group_add_window(), which means not calling it redundantly.
(I tried using a ComboBox:parent-set handler, but the Inspector’s CB
didn’t like that: it calls popup_for_device() twice and closes on button
release. Anyway, using popup() is much more concise than a new handler.)
The screen for the list-mode popup_window was only being set in
set_popup_widget(), i.e. when changing modes, so if the ComboBox was
moved to a different screen later, the popup would appear on the
original one, which is wrong.
Worse, this broke opening some combos in the Inspector in GTK+ 3.
Fix this by moving the call to set_screen() to real_popup(), so
the popup_window is put on the correct screen each time around.
https://bugzilla.gnome.org/show_bug.cgi?id=468868https://bugzilla.gnome.org/show_bug.cgi?id=786771
Bad actors, such as our very own FileChooserButton, may connect to the
:popped-up property and alter the model as the menu becomes in/visible.
We were getting an iter to the model while popped-up, then doing
popdown(), then using the iter, which may have just been invalidated by
the errant notify::popped-up handler. If so, we quickly crash fatally.
This is clearly bonkers, but until such patterns are removed, we have to
work around them. So, set_active() from the clicked item while it is
known to be valid, by moving the call to set_active() before popdown().
While here, change set_active_iter(iter) to set_active_internal(path) to
avoid pointlessly going through the iter to get the path we already have
https://bugzilla.gnome.org/show_bug.cgi?id=729651
In gtk_container_real_set_focus_child(), we try to scroll to the
position of the new :focus-child if we have h or v adjustments.
gtk_widget_translate_coordinates() returns FALSE if neither widget is
realized or in other situations that cause output parameters x and y not
to be set. Thus, if the caller did not initialise x/y and uses them even
if the function returns FALSE, they are using uninitialised variables.
In gtk_container_real_set_focus_child(), we did not check the return
value but merrily went ahead and used x and y regardless. This is UB, as
caught by Valgrind, as well as being pointless.
The trivial fix is to exit early if (!gtk_widget_translate_coordinates).
https://bugzilla.gnome.org/show_bug.cgi?id=776909
Our ::query-tooltip handler first checks whether the pointer is over any
of the icons, returning their tooltip if so, and if not chains up to
Widget::query-tooltip in order to show the text for the widget overall.
But ensure_has_tooltip(), which exists to update :has-tooltip based on
whether ::query-tooltip is needed, only set :has-tooltip to TRUE if any
icon had a tooltip, without caring whether the widget as a whole does.
That is asymmetrical and meant that if the Entry had a tooltip, but
subsequently all icons had their tooltips unset, :has-tooltip would be
set to FALSE, and hence the tooltip for the widget would become lost.
The fix is to set :has-tooltip to TRUE if the widget has a tooltip of
its own, and we only need to check the icons if that is not the case.
https://bugzilla.gnome.org/show_bug.cgi?id=785672
