Add ability to save and switch named sets of parallel modules.

[LAfricain]

Solves #639

UI:

• 'Sets' menu button in the parallel view toolbar; clicking it shows
  a popup menu of saved sets plus 'Manage...' which opens Preferences
  directly on the Modules > Parallel page
• GtkComboBoxText in Preferences > Modules > Parallel to select which
  set is being edited; 'New set...' creates a new set from the current
  parallel module list

Storage (settings.xml, [modules] section):
parallel_set_names=NT,AT
parallel_set_current=NT
parallel_set_NT=BSB,FreCrampon,FreINT
parallel_set_AT=BSB,FreCrampon,WLC

Fully backward-compatible: falls back to existing parallel_list if no
sets are defined.

New helpers in settings.c:
get_parallel_set(name) - returns module list for a named set
save_parallel_set(name) - saves module list for a named set"

[LAfricain]

I just fixed the problem for Windows, but in doing so, I discovered another one: a new set isn't saved—once Xiphos is closed, it disappears. And there's no option to delete sets. I'll take care of that as soon as possible.

[LAfricain]

I just discovered an issue after the last commit. I'm currently working on fixing it. Please wait a little while before merging.

[karlkleinpaste]

I'm going out of town for a few days but I'll look into the state of your several PRs when I get back.

Do I understand correctly that the PR for keysymdef.h in Windows is working? Looks like it, from the logs. That one would be straightforward to merge.

[LAfricain]

Do I understand correctly that the PR for keysymdef.h in Windows is working?

Yes!

I like the feature of this PR! It's too bad I didn't look into this sooner. Once you've merged all the PRs, I'll create a PR with the French and Italian translations. Your new scroll feature looks amazing, too!

[karlkleinpaste]

Apparently one of the other PRs I just completed has caused a conflict here. Please adjust, then I'll see about local testing on my own and merge if all is well.

[karlkleinpaste]

I've just pulled down the patch of this PR, tried applying it to my tree for testing, and find that there are things being re-done, causing patch to assume a reversed patch. Notably, CMakeLists.txt files are repeating what's already done with the keysymdef.h PR.

diff --git a/src/editor/CMakeLists.txt b/src/editor/CMakeLists.txt
index 29239d743..a954d6ba0 100644
--- a/src/editor/CMakeLists.txt
+++ b/src/editor/CMakeLists.txt
@@ -84,6 +84,6 @@ if (WIN32)
   # add X11/keysymdefs.h
   target_include_directories(editor
     PRIVATE
-    ${PROJECT_SOURCE_DIR}/win32/include
+    ${X11_INCLUDE_DIR}
     )
 endif ()

...along with others.

I'm at a bit of a loss to understand [a] how this PR can be shown as "no conflicts" when it is clearly repeating previously-merged changes and [b] how much of this patch I should trust for moving forward.

Regrets for trouble, but when too many things get going at once, there are bound to be conflicts of one sort or another, whether GH, and git itself, can tell the difference. patch can surely tell the difference.

This may simply be in need of rebase to master.

[LAfricain]

Oh no! I created the PR branch on the wrong branch again... Could you do some cherry-picking? I'll be more careful next time when creating branches—I often forget to switch back to master!!

[karlkleinpaste]

Could you do some cherry-picking?

No, I can't, because I don't have access. Your branch isn't part of Xiphos' git repo, as shown in git branch -a. You're in exclusive control.

[LAfricain]

Ok I'll try tomorrow also for the tag issue. Le 29 juillet 2026 17:09:09 GMT+02:00, karl kleinpaste ***@***.***> a écrit :

…

karlkleinpaste left a comment (crosswire/xiphos#1348) > Could you do some cherry-picking? No, I can't, because I don't have access. Your branch isn't part of Xiphos' git repo, as shown in `git branch -a`. You're in exclusive control. -- Reply to this email directly or view it on GitHub: #1348 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>