Feature idea: easily switch between different QET configuration profiles

[ispyisail]

Forum request: https://qelectrotech.org/forum/viewtopic.php?pid=8830#p8830

Problem

Nuri (translator, working with multiple clients) reports needing different QET configurations per client, and currently switches between them by manually renaming OS-level settings files (qelectrotech.conf_A/qelectrotech.conf_B) before relaunching. Requested: a menu option to load a saved configuration, accepting that QET would need to restart. scorpio810 confirmed it's feasible but labor-intensive (Linux/macOS store settings as text files, Windows uses the registry); Joshua later reported finding a cross-platform-compatible approach.

What exists today

• Preferences are stored via QSettings with organization/application name "QElectroTech" (sources/main.cpp:208,210), using Qt's native per-platform backend — a text file at ~/.config/QElectroTech/QElectroTech.conf on Linux, the registry under HKEY_CURRENT_USER\Software\QElectroTech\QElectroTech on Windows, a plist on macOS. This is exactly the split scorpio810 described.
• There's already a --config-dir=DIR CLI flag (QETApp::overrideConfigDir(), sources/qetapp.cpp:1221-1230, enabled by default in both build systems — cmake/start_options.cmake:26), but it doesn't actually solve this: QETApp::configDir() is only consulted for a handful of specific paths — element text patterns (sources/elementtextpattern.cpp:47,132,205), the custom stylesheet (sources/qetapp.cpp:1748), and directory creation at startup (sources/qetapp.cpp:2312-2313). It never touches QSettings itself, which uses Qt's own OS-native storage independent of this override. So the bulk of actual preferences — shortcuts, autosave interval, recent files, UI layout, etc. — aren't affected by --config-dir at all today.
• No import/export/profile mechanism exists for QSettings anywhere in the codebase. Nuri's manual file-renaming workaround is the only option there is, which matches exactly what's missing.

Proposed scope

Two new entries under the Configuration menu:

• Enregistrer la configuration sous... — write every key currently in the live QSettings out to a chosen .conf file, via QSettings(path, QSettings::IniFormat) rather than the platform-native backend.
• Charger une configuration... — read a chosen .conf file the same way and copy its keys into the live QSettings, then prompt to restart (the same restart Nuri already said was acceptable).

Using QSettings::IniFormat for the saved/loaded file specifically (regardless of what the live settings backend is on that platform) is what makes this portable: the export/import is a plain key/value copy loop (allKeys() + value()/setValue()), identical code on Windows, Linux, and macOS, without needing to touch the registry format at all — this is the shape Joshua's "cross-platform-compatible" comment on the thread points at.

Why this shape

A full live-reload-without-restart is out of scope: QET doesn't have a settings-changed signal wired through every consumer (autosave timer, shortcuts, docks, etc.), so faking that would be far riskier than asking for the restart the original request already anticipated. Scoping this to plain export/load also means it directly replaces Nuri's existing manual workaround (renaming files) with an in-app equivalent, rather than trying to solve a broader "live profile switching" feature nobody asked for yet.

Not proposed here

• Live reload without restart.
• Automatic per-client profile detection/switching.
• Cloud sync or built-in sharing of profiles (Joshua's comment about sharing configs with clients is naturally covered by "it's just a file you can hand someone," without needing dedicated sharing infrastructure).

Happy to build this if the scope above sounds right.

[ispyisail]

Built this: #640

Matches the scope above: two Configuration menu entries going through QSettings::IniFormat for the saved/loaded file specifically (a plain key/value copy loop, identical across platforms), import clears the live settings before copying the file's keys in (so switching profiles is a clean swap, not a merge), and it restarts rather than attempting a live reload — same reasoning as the discussion: no settings-changed signal reaches every consumer, so faking a reload risks stale UI state.

Verified via a real Xvfb session, including the actual scenario: exported the live config, simulated drift by hand-editing a setting on disk while QET was closed, relaunched, loaded the earlier export back in, confirmed the restart-confirmation dialog, and confirmed after restart (genuinely a new process, different PID) the drifted setting reverted to exactly what was in the loaded file. Details on the PR.

[ispyisail]

Status: in progress — PR #640: #640