Snippet XML import dialog shows snippets but fails to actually import them (Windows)

[ultraleetj]

Environment:

• OS: Windows 11, though I would presume all of them given your typical apathy for win users.
• Frescobaldi version: 4.0.4 (August 2025)

Bug Description:

The snippet XML import feature fails silently on Windows. When importing snippets via the Snippet Manager Menu→Import:

1. The import dialog opens correctly
2. The XML file is parsed successfully and snippets are displayed in the dialog
3. User selects snippets and clicks OK
4. Dialog closes with no error message or anything,
5. No snippets are actually added to the snippet manager

The dialog appears to work correctly but performs no actual import operation.

Steps to Reproduce:

1. Export any existing snippet to XML (Menu→Export)
2. Delete the snippet from the snippet manager
3. Attempt to re-import the snippet via Menu→Import
4. Select the snippet in the dialog and click OK
5. Observe that the snippet does not appear in the snippet manager

Root Cause:

Turns out that Frescobaldi depressingly stores snippets in the Windows Registry at:
HKEY_CURRENT_USER\Software\frescobaldi\frescobaldi\snippets
or even
HKEY_USERS\Software\frescobaldi\frescobaldi\snippets
Given this, whats most likely, is that the import function appears to fail when writing multi-line string values (REG_SZ) to the registry. This is a known Windows limitation where multi-line REG_SZ values exported from the registry cannot be re-imported from .reg files - they must be encoded in hex(1) format for import to work.

Why This Is Problematic:

Storing user-editable content like snippets in the Windows Registry is already questionable design practice. It makes the data:

• Non-portable (can't easily copy between machines)
• Difficult to backup
• Harder to version control
• Inaccessible in locked-down enterprise/school environments

But what makes this particularly frustrating is that the XML import/export feature was presumably created to solve these exact problems - yet it doesn't actually work on Windows. So Windows users are stuck with the worst of both worlds: registry-based storage without the ability to import/export snippets that the feature promises.

It's especially ironic given that LilyPond itself is all about human-readable plain text files, yet Frescobaldi chose to store snippets in the Windows Registry - the antithesis of plain text. And when Windows users encounter issues stemming from this architectural choice, they're often met with "works fine on Linux" responses. Well, yes - Linux doesn't use the Windows Registry, so it avoids this entire class of problems.

The "install for current user only" option suggests Frescobaldi doesn't need admin/registry access, which makes the registry storage choice even more puzzling.

Workarounds:

Option 1 (Immediate fix): On Windows, use the Windows Registry API (via ctypes/winreg in Python) or PowerShell via subprocess to write registry values directly instead of generating/importing .reg files. This avoids the multi-line limitation entirely.
Option 2 (Better long-term solution): Store snippets in XML/JSON files in %APPDATA%\frescobaldi\snippets\ instead of the Windows Registry.

Additional Notes:
This bug affects Windows 7, 10, and 11 (likely all Windows versions) as it's a limitation of the Windows Registry Editor's .reg file format, not a specific Windows version issue.
The XML export feature works correctly - only import is affected.

[bmjcode]

Thanks for the exceptionally detailed report. I just have time now for a couple quick comments...

...given your typical apathy for win users.

The hostility is unnecessary, though frankly I find it hilarious as a Frescobaldi maintainer who's also a full-time Windows user.

Turns out that Frescobaldi depressingly stores snippets in the Windows Registry at: HKEY_CURRENT_USER\Software\frescobaldi\frescobaldi\snippets or even HKEY_USERS\Software\frescobaldi\frescobaldi\snippets Given this, whats most likely, is that the import function appears to fail when writing multi-line string values (REG_SZ) to the registry. This is a known Windows limitation where multi-line REG_SZ values exported from the registry cannot be re-imported from .reg files - they must be encoded in hex(1) format for import to work.

Frescobaldi doesn't specify what storage mechanism to use for snippets. It just uses whatever QSettings defaults to, which on Windows happens to be the Registry. If this is causing problems we could change it to explicitly request a different mechanism.

Storing user-editable content like snippets in the Windows Registry is already questionable design practice. [...] It's especially ironic given that LilyPond itself is all about human-readable plain text files, yet Frescobaldi chose to store snippets in the Windows Registry - the antithesis of plain text.

This wasn't a deliberate design decision on our part. Again, Frescobaldi relies on QSettings, which on Windows defaults to using the Registry unless another mechanism is specified.

And when Windows users encounter issues stemming from this architectural choice, they're often met with "works fine on Linux" responses.

Have you received such a response from anyone here recently? If so, I'd like to have a word with them.

[ultraleetj]

Thanks for reading all of this and the clarification about QSettings! I understand now that this wasn't a deliberate design choice but rather Qt's default behavior for NativeFormat. That makes much more sense. However, this might actually present an opportunity to improve Frescobaldi across *all* platforms, not just Windows. According to the provided Qt documentation <https://doc.qt.io/qt-6/qsettings.html>, QSettings supports multiple storage formats, including QSettings::IniFormat which stores settings in INI files in the user's config directory (%APPDATA% on Windows, ~/.config on Unix/Linux). Proposed Solution: Switch to IniFormat for Snippets I'd like to suggest explicitly using QSettings::IniFormat for snippet storage. Here's why this would benefit all platforms: Benefits for All Platforms: 1. *Portability*: Snippets become actual files that users can: - Copy between machines easily - Backup with standard file backup tools - Version control with git - Share via cloud storage (Dropbox, etc.) - Edit directly in a text editor if needed 2. *Consistency*: All platforms would use the same storage format and behavior, reducing platform-specific bugs 3. *Philosophical alignment*: File-based storage aligns with LilyPond's plain-text philosophy.. find it a bit funny too but it is what it is 4. *Debugging*: Users and developers can inspect snippet files directly without registry editors or platform-specific tools 5. *Access*: Works in locked-down enterprise/educational environments where registry/system modifications may be restricted Windows-Specific Fixes: - Solves the XML import bug (INI files don't have the registry's multi-line string limitation) - No more registry permission issues - Faster snippet operations maybe? (no registry API overhead) Implementation: The change would be straightforward - when creating the QSettings object for snippets, could probably explicitly specify something like: settings = QSettings(QSettings.IniFormat, QSettings.UserScope, "frescobaldi", "snippets") Instead of relying on NativeFormat. Migration Path: For existing users, Frescobaldi could: 1. Check for snippets in the old location (registry on Windows, etc.) 2. If found, automatically migrate them to the new INI file format on first run or when importing 3. Display a one-time notification about the migration This would be completely transparent to users while solving the import bug and improving snippet portability for everyone. ------------------------------ Have you received such a response from anyone here recently? If so, I'd like to have a word with them. No, not here. I apologize if that came across as an accusation toward this project's maintainers. That was a general frustration about cross-platform software development culture, not directed at anyone on the Frescobaldi team. Would you be open to this IniFormat approach? I could help to test it or try to contribute a PR if that would be helpful. El jue, 9 oct 2025 a las 19:51, Benjamin Johnson ***@***.***>) escribió:

…

*bmjcode* left a comment (frescobaldi/frescobaldi#2103) <#2103 (comment)> Thanks for the exceptionally detailed report. I just have time now for a couple quick comments... ...given your typical apathy for win users. The hostility is unnecessary, though frankly I find it hilarious as a Frescobaldi maintainer who's also a full-time Windows user. Turns out that Frescobaldi depressingly stores snippets in the Windows Registry at: HKEY_CURRENT_USER\Software\frescobaldi\frescobaldi\snippets or even HKEY_USERS\Software\frescobaldi\frescobaldi\snippets Given this, whats most likely, is that the import function appears to fail when writing multi-line string values (REG_SZ) to the registry. This is a known Windows limitation <https://stackoverflow.com/questions/153879/how-do-i-add-a-multiline-reg-sz-string-to-the-registry-from-the-command-line> where multi-line REG_SZ values exported from the registry cannot be re-imported from .reg files - they must be encoded in hex(1) format for import to work. Frescobaldi doesn't specify what storage mechanism to use for snippets. It just uses whatever QSettings <https://doc.qt.io/qt-6/qsettings.html> defaults to, which on Windows happens to be the Registry. If this is causing problems we could change it to explicitly request a different mechanism. Storing user-editable content like snippets in the Windows Registry is already questionable design practice. [...] It's especially ironic given that LilyPond itself is all about human-readable plain text files, yet Frescobaldi chose to store snippets in the Windows Registry - the antithesis of plain text. This wasn't a deliberate design decision on our part. Again, Frescobaldi relies on QSettings, which on Windows defaults to using the Registry unless another mechanism is specified. And when Windows users encounter issues stemming from this architectural choice, they're often met with "works fine on Linux" responses. Have you received such a response from anyone here recently? If so, I'd like to have a word with them. — Reply to this email directly, view it on GitHub <#2103 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKDNA42TLSXUKU2EEDXKCSL3W37ITAVCNFSM6AAAAACIXZLG4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOBXHA4TQNZTGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[fedelibre]

I'd like to suggest explicitly using QSettings::IniFormat for snippet storage.

I agree!

By the way, when I documented where the settings are saved in each platform, I've learned about Qt's NativeFormat. As far as I've understood and IIRC, native format is preferable for general settings because a) users find the same settings infrastructure they are used to in their platform and b) binary native formats like the Registry on Windows are reported to work better (don't know if this is actually true but I've read that Windows switched from .ini files to the Registry so I guess it was for a good reason).

That said, the snippets should be handled separately from the general settings, for all the good reasons you've perfectly described.
Related issues:

• External directory (preference) for templates #1201

[bmjcode]

I agree with storing snippets separately using INI format. That should be an easy fix too; we already have install/update.py to update the storage structure.

[...] binary native formats like the Registry on Windows are reported to work better (don't know if this is actually true but I've read that Windows switched from .ini files to the Registry so I guess it was for a good reason).

That was the rationale. It's debatable how well it's worked in practice, but the theory is perfectly sound. (At the risk of getting off topic I think this is true of a lot of design decisions in Windows.)