feat: convert bookmarks to tags with color highlighting

[LAfricain]

Voici le texte de la PR :

---

Title: feat: Convert bookmarks to tags with color highlighting

Closes: #968, #685

---

Summary

This PR converts the existing Bookmarks tab into a Tags system. Tags are a strict superset of bookmarks: every bookmark can be expressed as a tag entry belonging to a named, color-coded folder. This approach resolves both #968 (tags in text) and #685 (color for bookmark folders) in a single coherent feature.

Changes

Data model

• Added COL_COLOR column (G_TYPE_STRING) to the GtkTreeStore
• Extended the XML format with an optional color attribute on <Folder> nodes — fully backward compatible (existing files load without modification)
• Added xml_add_folder_to_parent_colored() and xml_get_folder_color() to xml.c/h

UI — Tag panel

• New dedicated dialog ui/folder.gtkbuilder (and folder.glade for Windows) with a name field, a GtkColorButton, and a "No color" button
• "New Folder" and "Edit Item" now open this dialog instead of the generic text dialog
• A Cairo-rendered color dot (14×14 px, with border) appears to the left of each colored folder in the treeview
• Drag and drop reordering is enabled by default (no need to activate it from the context menu)
• Removed the "Set folder color" context menu item — color is now set directly in the folder dialog

Verse highlighting in the Bible text view

• get_tag_color_for_versekey() in display.cc walks the GtkTreeStore and returns the tag color for the current verse using VerseKey OSIS normalization — this handles locale differences between the stored key format and the display engine format
• The highlight span includes color: computed from background luminance (ITU-R BT.709) so text remains readable on dark tag colors
• Multi-reference support:
  • Semicolon-separated refs (Act 16:31; 16:36): book name is propagated to partial refs
  • Comma-separated verses (Eph 2:8,9): expanded to individual verse checks
  • Verse ranges (1 Cor 15:1-4): checked numerically (book + chapter + verse range) to avoid lexicographic comparison bugs

Design decisions

Why disable the current-verse green highlight when a tag color is present?
When a verse has a tag color, the green highlight from settings.versehighlight would override or mix with the tag color, making the tag color invisible on the current verse. We chose to skip the green highlight when tag_color != NULL, so the tag color takes full visual priority. The user can still see which verse is current via the verse number anchor.

Why use VerseKey normalization instead of string comparison?
Stored bookmark keys use locale-dependent formats (e.g. "Actes 16:31" in French) while GTKChapDisp::display() iterates using English OSIS book names ("Act"). Direct string comparison always fails across locales. Normalizing both sides through VerseKey::getOSISBookName() + chapter + verse gives a locale-independent comparison.

Why use numeric comparison for verse ranges instead of OSIS string comparison?
Lexicographic comparison of OSIS refs like "1Co.15.10" vs "1Co.15.4" gives wrong results ("10" < "4" alphabetically). We compare vk->getVerse() directly against vk_start.getVerse() and atoi(dash + 1) as integers.

Why move the color picker out of the context menu?
The context menu item "Set folder color" required a two-step interaction (right-click → menu item → color dialog) and did not work on empty folders. Integrating the color picker directly into the "New Folder" and "Edit Item" dialogs makes it discoverable and works consistently regardless of folder contents.

Localization fix

Default bookmark folder names (Personal, What must I do to be saved?, etc.) were always created in English because xml_new_bookmark_file() was called before gui_init() initialized gettext. Fixed by calling gui_init() before init_bookmarks() in settings.c. gui_init() is idempotent (guarded by a static flag) so multiple calls are safe.

Backward compatibility

• Existing bookmarks.xml files load without modification — folders without a color attribute simply have no tag color
• A bookmarks.xml.bak backup is created on first run after upgrade (copied, not moved)

Files changed

• src/gtk/bookmark_dialog.c — new folder dialog, fixed button handling
• src/gtk/bookmarks_menu.c — color-aware save, new/edit folder dialogs
• src/gtk/bookmarks_treeview.c — COL_COLOR, Cairo dot, multi-ref navigation, drag & drop
• src/gtk/utilities.c — utilities_parse_treeview propagates color
• src/gui/bookmarks_menu.h — set_color widget, on_set_tag_color_activate
• src/gui/bookmarks_treeview.h — COL_COLOR enum, color field in BOOKMARK_DATA
• src/main/display.cc — tag color lookup, highlighting, luminance-based text color
• src/main/main.c — backup on first run
• src/main/settings.c — gui_init before init_bookmarks
• src/main/xml.c/h — xml_add_folder_to_parent_colored, xml_get_folder_color
• ui/CMakeLists.txt — added folder.gtkbuilder and folder.glade
• ui/folder.gtkbuilder / ui/folder.glade — new folder dialog UI

Please test!

[karlkleinpaste]

I will be looking at this closely in a few days. As I've mentioned, I'm traveling for work this week and have little spare time until I'm home again.

[karlkleinpaste]

One immediate observation: ui/folder.gtkbuilder
Do we need an equivalent .glade for windows, or will the windows build use the .gtkbuilder as it stands?

[LAfricain]

I need help for Windows, i'm becoming crasy. It's all the more frustrating because these new tags look great on Ubuntu! See what Claude says:

[Windows build] win64: missing webkitgtk-3.0 for mingw64, and folder/edit bookmark dialogs not working

Context:
We are working on the bookmarks2tags branch which adds color tagging to bookmark folders. This required a new folder.gtkbuilder (GTK3) and folder.glade (GTK2) dialog.

Problem 1 — win64 build fails:
The current win64 build uses -DGTK2=ON for both win32 and win64. We changed win64 to use GTK3 (removing -DGTK2=ON) so that folder.gtkbuilder and the languages file get packaged correctly by CPack. However, mingw64 only has webkitgtk-1.0 (mingw64-webkitgtk), not webkitgtk-3.0 or webkit2gtk. This means GTK3 win64 can't find a webkit dependency.

We tried -DGTKTVEDITOR=ON to bypass webkit, but this breaks Linux builds because XIPHOS_HTML_* macros are used unconditionally throughout the codebase.

Question: What is the recommended way to build win64 with GTK3 without webkit? Is there a mingw64 webkit package available, or should we protect all XIPHOS_HTML_* usages with #ifndef USE_GTKTVeditor?

Problem 2 — folder/edit bookmark dialogs do nothing on Windows:
Clicking "New folder" or "Edit bookmark" in the bookmarks panel does nothing on Windows. Root cause: folder.gtkbuilder and the languages file are not installed because ui/CMakeLists.txt excludes them when GTK2=ON:

if (NOT GTK2)
    install (FILES folder.gtkbuilder ... languages ...)

This is directly tied to Problem 1 — fixing the win64 GTK3 build would resolve both issues.