The Windows portable ZIP ships "Lancer QET_qt6.bat", but the script only
looked for "Lancer QET.bat", so it stopped at its first check and never
registered anything. It now tries the ZIP's name first and falls back to
the installer's.
It also wrote to HKEY_CLASSES_ROOT, which a standard (non-admin) Windows
account cannot create keys in. It now writes to
HKEY_CURRENT_USER\Software\Classes: per-user, no elevation needed, and
Windows merges it into HKEY_CLASSES_ROOT for that user.
qet_uninstall_file_associations.reg removes the HKCU keys first, then the
old HKEY_CLASSES_ROOT ones as before.
Tested under Wine 10 on the git10275 nightly ZIP: the old script aborts
("Lancer QET.bat ... n'a pas ete trouve"), the new one registers .qet,
.elmt and .titleblock under HKCU with nothing under HKLM, the uninstall
file removes them, and the "Lancer QET.bat" fallback works. Wine does not
enforce admin rights, so the non-admin case itself is not proven there.
Reported in #1148.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Most Windows users have no Python, which the MCP server needs. The
installer now offers "Python for the AI assistant", unticked by default:
the official embeddable package from python.org (3.14.7, ~12 MB, no
registry, removed with QElectroTech), in <folder>\mcp\python. The
portable folder and the MSI, which pack all of files/, carry it.
The workflow downloads it pinned by version and by python.org's own
sha256 for the file (checked against python.org's download API), and
fails the build on a mismatch. The script stays plain text beside it.
Checked under Wine (64-bit, qet-wine-smoke image), on an installer built
with makensis 3.10 (0 warnings, strings in all 29 languages):
- a silent default install puts mcp\qet_mcp.py in place and no Python;
the same installer with the section ticked by default installs it, so
the check tells the two apart;
- the installed Python runs the installed server: 15 tools listed,
qet_project_info on an example answers as on Linux, and the server
finds bin\QElectroTech.exe and elements\ by itself.
Not checked: a real Windows machine; the CI download step (fork run).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The MCP server (misc/qet-mcp) was only reachable from a source checkout.
It now ships with every package, next to the program, and finds that
QElectroTech and its element collection from where it sits:
- make install (Linux distributions, snap, flatpak):
<prefix>/share/qelectrotech/mcp/qet_mcp.py, executable, with its README.
- Windows installer: a new "AI assistant (MCP)" component (on by default,
~200 KB), installed to <folder>\mcp. The workflow stages files/mcp, so
the portable folder and the MSI, which packs all of files/, carry it too.
The server learns the Windows layout (<root>/mcp beside <root>/bin, whose
program is QElectroTech.exe, and <root>/elements), in addition to
<prefix>/share/qelectrotech/mcp. A copy saved anywhere else, even beside
some bin/ folder, is not taken for an installation.
The installer strings are given in all 29 installer languages: French
translated, the others in English until translated, which is what NSIS
would fall back to anyway but without its warning 6040 per language.
Checked: make install into a scratch prefix, then from the installed
script with nothing configured and no qelectrotech on PATH, an SVG export
and a qet_edit placing a common:// element both succeeded. makensis 3.10
compiles the installer with 0 warnings before and after (removing the
French description gives warning 6040), and the installer contains
mcp/qet_mcp.py. Suite 274/274 none skipped; each layout check was
removed in turn and a test failed. Snap/flatpak: installed by the same
CMake rule; launching their QElectroTech from outside is untested.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Qt6 PrintSupport records Cups::Cups as a third-party dependency
(qprint_p.h includes <cups/ppd.h>), so find_package(Qt6 PrintSupport)
runs FindCups at configure time and fails without the CUPS headers.
Build-time only, nothing is staged.
windows-build.yml:
- Remove the Qt5 build job (build-windows). Qt6 is now the sole
Windows track built in CI.
- publish-nightly-assets: only delete/replace .exe and .zip assets
tagged "qt6" on the nightly release. Assets without "qt6" in the
name (the last Qt5 build ever published) are left untouched and
stay downloadable indefinitely as a frozen legacy build.
- Release notes: drop the "Try Qt6 — soon the only track" notice,
add a line explaining the Qt5 (frozen) vs Qt6 (maintained) split.
windows-msi.yml:
- Matrix reduced to the single "qt6" entry (flavor string kept as
"qt6", not renamed, since it seeds the MSI ProductCode and a
rename would break upgrade detection for existing installs).
- Sign the Qt6 MSI via SignPath (previously Qt5-only). Guard is now
just the upstream-repo fork check; no per-flavor exclusion left.
- deploy-pages: also detect legacy (non-"qt6") release assets and
pass them to generate-page.py as LEGACY_INSTALLER_URL /
LEGACY_PORTABLE_URL / LEGACY_MSI_URL.
generate-page.py:
- Drop the old Qt5/Qt6 dual-track rendering; INSTALLER_URL /
PORTABLE_URL / MSI_URL now point at the Qt6 build directly.
- Add an optional "Windows — x86_64 — Qt5 (legacy, unmaintained)"
card, rendered only when LEGACY_* URLs are set, with a frozen/
no-longer-updated notice.
Before merging: manually trigger the current (pre-merge) "Windows
Build" + "Windows MSI" workflows once to publish an up-to-date,
signed Qt5 snapshot — that run becomes the frozen legacy reference,
since the Qt5 job won't exist to re-run afterwards.
No changes to QElectroTech.wxs (Qt5/Qt6-agnostic, only
QtPlatformArgs varies and is already handled at the CI level).
The Windows Qt5 build is going to be removed from CI/CD soon (Qt6/KF6
is becoming the sole supported track). Replace the 'experimental'
warning wording on the nightly download page and in the nightly
release body with a call to action inviting users to switch to Qt6
now and report issues, ahead of the Qt5 removal.
switch runtime/sdk to org.kde.Platform/org.kde.Sdk 6.10
migrate qelectrotech module from qmake to cmake buildsystem
add config-opts: QT_VERSION_MAJOR=6, BUILD_WITH_KF=ON, BUILD_KF=OFF,
PACKAGE_TESTS=OFF, BUILD_PUGIXML=OFF, QET_EXPORT_PROJECT_DB=ON
drop fix-the-installation-paths.patch (qmake-only, obsolete under cmake)
re-attach fix-appdata.patch, previously unreferenced in sources
document open verification points for Qt6 private headers and the
SQLite driver, which have no Flatpak build-depends equivalent
a) using a system provided KF6
b) downloading and compiling KF6
c) using the vendored-in re-creation of the functionality
The behaviour for both Qt5 and Qt6 is steered with the same two variables which were renamed to become version agnostic:
a) BUILD_WITH_KF=ON BUILD_KF=OFF
b) BUILD_WITH_KF=ON BUILD_KF=ON
c) BUILD_WITH_KF=OFF
The version is automatically derived from the chosen Qt major version.
The MSI registers both shortcuts with the arguments QET needs to find its
data ("Point directly to qelectrotech.exe with all required arguments"),
but the QElectroTech.Document\shell\open\command registry value was
written without them:
"[INSTALLDIR]bin\qelectrotech.exe" "%1"
Launching from the Start Menu therefore works, while double-clicking a
.qet file does not: Explorer sets the working directory to the document's
folder, and the compiled-in data paths are relative, so nothing is found
there. The most visible symptom is the interface always coming up in
French, because no translation loads and the source strings are French.
Give the file association the same arguments as the shortcuts.
Reported by mr-rfh in #554, who diagnosed it and arrived at exactly this
registry value by hand.
Qt 5.15.x added libxcb-cursor0 as a hard runtime dependency of the xcb
platform plugin (libqxcb.so). The kf5-5-110-qt-5-15-11-core22 content
snap does not bundle this library, so when the snap runs on an Ubuntu 24.04
host the dlopen() of the plugin fails with:
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in ""
even though it was found.
Staging libxcb-cursor0 from the Ubuntu 22.04 archive satisfies the
dependency without changing the snap base, Qt version, or any other
dependency. No ABI mismatch: the plugin and the staged library are
both built against the core22 (22.04) ABI.
Fixes issue #373.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Without a source-tag or source-commit, snapcraft pulls the latest
HEAD of qet_tb_generator-plugin on every build. This makes builds
non-reproducible and risks breakage whenever the upstream repo changes.
Pin to the only published release tag (v1.31, commit d6ee3cf) so
the snap always builds against a known-good version of the plugin.
Closes#202
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
+ AllowSameVersionUpgrades="yes" to <MajorUpgrade>
windows-msi.yml — in the ‘Extract version’ step, calculate a unique GUID
based on the commit’s SHA, then pass -d ‘ProductCode=$productGuid’ to the WIX build
This ensures that each build will have a different ProductCode → MajorUpgrade will always be triggered
- Use SetProperty + WixQuietExec two-step pattern to pass runtime
INSTALLDIR to a deferred CustomAction (fixes WIX1077 and WIX0400)
- Add WixToolset.Util.wixext/7.0.0 extension (required for WixQuietExec)
- Fix condition syntax: collapse multi-line conditions to single line
- Add -ext WixToolset.Util.wixext to wix build command in windows-msi.yml
**`build-aux/windows/QElectroTech.wxs`**
- Desktop and Start Menu shortcuts now point directly to `bin\qelectrotech.exe` with all required arguments (`--common-elements-dir`, `--common-tbt-dir`, `--lang-dir`, `-style windowsvista`) — no `.bat` wrapper needed
- Added a deferred `CustomAction` that runs after `InstallFiles` and recursively sets all files in `elements\` to read-only using an inline PowerShell command
**`.github/workflows/windows-msi.yml`**
- Replaced the step that created `Lancer QET.bat` with a step that removes it from the artifact before the WiX build, so it is not embedded in the MSI
- The `.bat` file remains untouched in the ZIP portable build (managed by `windows-build.yml`)
- No console window flashing when launching QElectroTech from the MSI shortcuts
- The `elements\` directory is properly set to read-only after installation, as required
- Cleaner MSI package — no `.bat` file shipped to end users installing via MSI
ispyisail