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>
Installs MSYS2's hidapi and turns on QET_ENABLE_SPACEMOUSE with the
hidapi backend, so the Windows package reads a 3Dconnexion SpaceMouse
directly over USB, with no 3Dconnexion driver (discussion #599).
The existing transitive DLL scan copies libhidapi-0.dll into the package,
and both installers take everything in bin/. Two checks make a silent
loss fail the build instead: CMake only warns when hidapi is missing, so
the exe must link against it, and the DLL must be deployed, or
QElectroTech.exe would not start.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Use a bound VACUUM INTO path and remove the stale SQLite
handle declaration. Fix shell continuations in Windows CI and
Debian installation instructions.
windeployqt runs with --no-translations, so standard buttons (OK/Cancel)
and dialogs stayed in English. Copy each qtbase_XX.qm from the MSYS2 Qt
translations into files/lang/qt_XX.qm, where QETApp::setLanguage() looks,
with aliases for QET languages Qt only ships with a region (pt, zh).
Recent Homebrew bottles (brotli, webp, sharpyuv) reference their deps as
@rpath/libX.dylib, which macdeployqt skips. Copy them from /opt/homebrew/lib
into Contents/Frameworks after macdeployqt, and abort if any @rpath or
/opt/homebrew reference remains unresolved. Drop the ineffective -libpath.
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.
- build-windows-qt6: install kwidgetsaddons/kcoreaddons/extra-cmake-modules,
switch -DBUILD_WITH_KF=OFF to ON, add -DBUILD_KF=OFF to use precompiled
MSYS2 packages instead of building KF6 from source via FetchContent
- build-windows: swap unsuffixed kwidgetsaddons/kcoreaddons (actually KF6
packages after MSYS2's renaming) for the -qt5 suffixed ones, add
-DBUILD_KF=OFF so the installed packages are actually consumed instead
of being ignored by the default FetchContent-from-source build
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.
Weekly cron replaced with a monthly run (1st of each month, 02:00 UTC)
to reduce unnecessary CI load.
retention-days raised from 14 to 40 across all six artifact uploads
(Qt5 + Qt6 tracks) to cover the new monthly interval with a safety
margin -- 14 days was shorter than the gap between two cron runs,
so the latest build's artifacts could expire before the next one
replaced them.
↓
windows-build.yml
├── build-windows → generates an exe file + zip + portable artefact
└── deploy-pages → clears old files, uploads the exe file + zip to the ‘release nightly’ repository
↓ (workflow_run: completed + successful)
windows-msi.yml
├── uploads the portable artefact
├── builds the MSI with WiX v7
├── deletes the old .msi, uploads the MSI to the nightly version
└── generates and deploys GitHub Pages ← the 3 URLs are known here
The GitHub Pages page is no longer generated by windows-build.yml but by windows-msi.yml once the MSI is in the release
Use 7-Zip is already installed on all GitHub Windows computers (C:\Program Files\7-Zip\7z.exe), and it is much faster than Compress-Archive when dealing with 9,931 files.
ispyisail