Fix Windows GTK3 build - #1363
Open
LAfricain wants to merge 5 commits into
Open
Conversation
* Move to long-deprecated WEBKIT1 backend, but at least it gives us a shot at GTK3 * Use GTKTVEDITOR in the builds TODO: Something is still pulling in gtk-2 in the images. That should be sorted out before everything is fully merged
Setting XDG_DATA_DIRS before g_get_system_data_dirs() (used for SWORD_PATH) changed where SWORD_PATH pointed, moving installed modules into the Xiphos install dir instead of the usual system location. Now GSETTINGS_SCHEMA_DIR/XDG_DATA_DIRS are set after SWORD_PATH is computed, and XDG_DATA_DIRS appends to any existing value instead of replacing it.
_load_text_into_buffer() builds "<html><body>%s</body></html>" via g_strdup_printf() with the given text. Two call sites could pass NULL (a studypad file that failed to read, or a note/bookmark with no content yet). On glibc this silently printed "(null)"; on MSVCRT/UCRT (Windows/MinGW) passing NULL to %s aborts the process immediately — this was the reported "strdup" crash when opening the editor. A third call site already guarded against this with text ? text : ""; apply the same pattern here.
Removes the Windows-specific fallback (manual MM.DD text entry) that was added because GtkCalendar was presumably broken on Windows under the previous GTK2/WebKit1 build. Windows now uses the same calendar+popover UI as Linux; entry_devotional is kept unshown as internal date storage, as it already was on Linux.
g_get_system_data_dirs() caches its result on first call, for the lifetime of the process (documented GLib behavior). Calling it to compute SWORD_PATH — regardless of whether that happens before or after we set XDG_DATA_DIRS — permanently poisons the cache with whichever value was current at that moment, and GTK's internal icon theme lookup (which also goes through g_get_system_data_dirs()) inherits that cached value for the rest of the run. The fix is to stop calling g_get_system_data_dirs() for SWORD_PATH entirely, using ALLUSERSPROFILE/PROGRAMDATA directly instead (which is what the original commented-out code already hinted at). This way XDG_DATA_DIRS can be set freely before gtk_init() without anything having poisoned the cache beforehand.
Contributor
|
@karlkleinpaste If you have no objections, I'll merge this. If we don't get major bugs related to it, we can consider beginning the removal of GTK2 specific code at that point as nothing remaining would use GTK2 pathways. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Windows GTK3 build (
test/windows-build-gtk3)Starting point
After moving to GTK3/GtkBuilder/WebKit1, two blocking issues showed up at runtime on Windows (tested via Wine): icons weren't rendering, and opening the Preferences dialog silently crashed the app. Several other issues surfaced and were fixed along the way.
1. Missing icons & Preferences crash
Diagnosis: The cause:
win32/CMakeLists.txtinstalled the GTK3 DLLs but not three runtime resources GTK3 needs:gdk-pixbufloadersGtkFileChooserButtonin Preferences)Missing 3 caused a fatal
GLib-GIO-ERROR: No GSettings schemas are installed, killing the process on Preferences open.Fix (
win32/CMakeLists.txt): addedinstall()rules for the icon theme, pixbuf loaders, and compiled schemas.Follow-up bug: even with resources bundled, GTK/GLib didn't discover them automatically at runtime — needed
GSETTINGS_SCHEMA_DIRandXDG_DATA_DIRSset explicitly. Added this insrc/main/main.c, computed dynamically viaxiphos_win32_get_subdir("share").Regression 1: setting
XDG_DATA_DIRSbefore the existingg_get_system_data_dirs()call (used forSWORD_PATH) redirected installed modules into the Xiphos install dir instead of the system location.Regression 2 (root cause, fixed properly):
g_get_system_data_dirs()caches its result for the life of the process on first call (documented GLib behavior). Calling it forSWORD_PATH— before or after settingXDG_DATA_DIRS— poisons that cache, and GTK's internal icon theme lookup (which uses the same cached call) never sees our override. Fixed by computingSWORD_PATHfromPROGRAMDATA/ALLUSERSPROFILEdirectly instead of callingg_get_system_data_dirs()at all, soXDG_DATA_DIRS/GSETTINGS_SCHEMA_DIRcan be set freely beforegtk_init()without anything having poisoned the cache first.Result: icons render correctly, Preferences opens without crashing, modules stay in the correct location. ✅
2. Editor ("studypad") crash — fatal
strdupSymptom:
xiphos va s'arrêter sur une erreur strdupingtktextview_editor.c:469, building"<html><body>%s</body></html>".Diagnosis: On glibc (Linux),
printf("%s", NULL)prints"(null)"and continues; on MSVCRT/UCRT (Windows/MinGW), passingNULLto%saborts the process immediately. Two call sites to_load_text_into_buffer()could passNULLtext:_load_file()— when reading a studypad file failseditor_load_note()— when a note/bookmark has no content yet (e.g. brand-new note)A third call site already guarded with
text ? text : ""; applied the same pattern to the two unguarded ones.Result: editor/studypad no longer crashes. ✅
3. Daily devotional: enable GTK3 calendar on Windows
Context: a
#ifdef _WIN32fallback showed a manual MM.DD text entry instead of theGtkCalendarpopover, with the comment "Windows: GtkCalendar is broken." This was presumably true under the old GTK2/WebKit1 build.Fix: removed the Windows-specific fallback in
src/gtk/dictlex.c(widget creation#ifdef _WIN32/#else/#endif, and the#ifndef _WIN32guard around the calendar/button signal connects), so Windows now uses the same calendar+popover UI as Linux. Theentry_devotionalwidget is kept unshown as internal date storage, matching prior Linux behavior.Result: calendar popover opens and date selection works. ✅
Known remaining cosmetic issue: the devotional date button shows as a blank/gray box — no visible label text (not even the initial
"--") — though it's fully functional (clicking still opens the popover correctly, and the box size is fixed regardless of window resizing, ruling out a layout/reflow issue). This looks like a GTK3 "wimp" theme-engine text rendering quirk under Wine specifically, rather than an app bug — pending confirmation on native Windows (not yet tested outside Wine).