I took the time to go through your qt6_cmake_joshua branch in detail, thanks for the work!

On the strategy side, this is exactly the direction we want to go: a full commitment to KF6 rather than a dual Qt5/Qt6 setup, which matches the plan (ship one last Qt5/KF5 stable release first, then move fully to Qt6).

Two things to fix before going further:

1. In fetch_kdeaddons.cmake, the output variable is now named KF6_PRIVATE_LIBRARIES, and the main CMakeLists.txt was updated accordingly. But the test CMakeLists.txt files (tests/catch, tests/googlemock, tests/googletest, tests/qttest) still reference the old KF5_PRIVATE_LIBRARIES name, which no longer exists anywhere in your branch. Result: the tests will fail to link. These 4 occurrences need to be replaced with KF6_PRIVATE_LIBRARIES.

2. There's at least one QRegExp left that hasn't been ported to QRegularExpression (elementslocation.cpp around line 783), and possibly other Qt6 compatibility cases not covered yet. There's a PR (#505 by ispyisail) that did fairly thorough work on this kind of fix (QVector/QList, setCodec, QDomDocument::ParseResult, ambiguous std::min, etc.) — worth comparing and pulling in whatever's still missing on your side rather than redoing it from scratch.

If you can push a fix for point 1, I'm happy to look at the rest with you to progressively bring this branch in as the base for the Qt6 migration.

Thanks again for the work, it's clearly heading in the right direction.

Best regards,
Laurent

I merged PR #533 from geri1701: it fixes the Qt-only build (`-DBUILD_WITH_KF5=OFF`), which was broken because of an incorrect CMake check (`DEFINED` instead of checking the actual flag value).

This matters in practice because KF5 is deprecated on NixOS, so packagers there need the Qt-only path to build QET at all.

Along the way, it adds two small Qt-only replacements for `KColorButton` and `KColorCombo`, used only when KF5 is disabled — the default KF5 path (Windows/macOS) is untouched.

Just to avoid any confusion given our past discussions on this topic: contrary to what I initially thought, this PR itself does not touch `KAutoSaveFile`. That said, a separate commit already in master does add a Qt-only `KAutoSaveFile` replacement (crash-recovery logic) under the same `nokde/` reimplementation effort. Its test coverage is Unix-only, so please don't rely on it on Windows or macOS builds — those should keep using the KF5 path.

Let me know if you spot any issue.

Add cliff.toml, configured to group commits by keyword (fix/feat/
refactor/etc. in FR+EN) since the project history doesn't follow
Conventional Commits. Handles QET's tag format (X.Y / X.Y.Z, no v
prefix), excludes the floating "nightly" tag, dedupes repeated commit
messages per release, and truncates commit bodies to their summary
line to keep the generated changelog valid Markdown.

rustup update stable
cargo install git-cliff

Usage:

export GITHUB_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxx
git-cliff --config cliff.toml <last_tag>..HEAD --prepend ChangeLog.md

thanks for yours works and your feedback, for macOS I have mac mini M2 funded by user donations, see https://qelectrotech.org/forum/viewtopic.php?id=2393

I haved checked Hombrew but not possible to get qt5-sqlite-plugin even wih brew install sqlite3... database export didn't work, so I passed to C.Gilles maintener of DigiKam and used this macports scripts.
https://invent.kde.org/graphics/digikam … type=heads

https://qelectrotech.org/wiki_new/doc/macosx,

It takes a long time – the full build framework compiles all entire the night – but I don’t do this every day, only when a new version of Qt is released.

For now I not used Qt6 on macOS séquoia, I just finished some CI/CD for Windows, refresh and polished https://github.com/qelectrotech/qelectr … _arm64.sh, add new features in code Displays terminal names on contact symbols in Xref Contact mode and cross mode, adds native, clickable hyperlinks to PDF exports: cross-references jump
directly to the related component on its folio, framing the target element.

Fix pushed: texteditor: set font size spinbox minimum to 4pt to prevent SIGSEGV

The static text size QSpinBox (m_size_sb) in the element editor had no minimum value set, allowing it to reach 0 when the user scrolled the mouse wheel rapidly. A QFont with a point size below 4 is invalid on Linux/Wayland and causes a SIGSEGV during glyph rendering (drawCachedGlyphs in Qt's raster paint engine).

Testing confirmed that values 1, 2 and 3 still trigger the crash — only 4pt and above render correctly on all platforms.

This bug was reproducible on Linux (Wayland and XCB sessions) across all QET versions (0.7, 0.8, 0.9, 0.100.x). On Windows the spinbox happened to stop at 1 due to different wheel event pacing, which is why the crash was Linux-only.

Fix: add setMinimum(4) on m_size_sb so Qt clamps the font size to a safe minimum value before applying it to the QFont.

File changed:

sources/editor/ui/texteditor.cpp
Fixes: SIGSEGV in QGraphicsTextItem::paint() / drawCachedGlyphs when scrolling the font size spinbox rapidly with the mouse wheel.

BTW, you could check my latest dmg aarch64? when I click to export PDF with clickable hyperlinks to PDF exports i saw an blackscreen and an mouse pointer that can moving so.... run command + tab help me, the exported PDF run very well with clickable hyperlinks.

I asked  Claude Code:
1. The cause of the black screen is most likely in your own Info.plist. Look, in the ‘Known Issues’ section:
<key>NSHighResolutionCapable</key>
<string>YES</string>
<key>NSHighResolutionMagnifyAllowed</key>
<string>NO</string>

NSHighResolutionCapable = YES on your 4K Retina display is exactly what triggers the QPrintPreviewWidget compositing freeze under Sequoia.
A quick, low-cost test, without recompiling: edit qelectrotech.app/Contents/Info.plist, change NSHighResolutionCapable to NO, and relaunch. If the black screen disappears (at the cost of a slightly less sharp preview), we’ve found the culprit and it’s a one-line fix in misc/Info.plist.

you can still try one last workaround that specifically targets the 4K trigger:

QT_ENABLE_HIGHDPI_SCALING=0 QT_SCALE_FACTOR=1 ./qelectrotech.app/Contents/MacOS/qelectrotech

If the black screen disappears with this, it’s definitive confirmation that it’s the Retina/4K + misaligned Qt5 combination — and the MacPorts rebuild will sort it out properly.

I'm tried also with no results to 1, or 0.

QT_MAC_WANTS_LAYER=1 /Applications/./qelectrotech.app/Contents/MacOS/qelectrotech

Edit:
2026-05-31 12:14:41.933 qelectrotech[2712:49999] The class 'NSSavePanel' overrides the method identifier.  This method is implemented by class 'NSWindow'
12:14:47.097 Debug: Help code for QT 6 or later (sources/print/projectprintwindow.cpp:604, void ProjectPrintWindow::savePageSetupForCurrentPrinter())

Thanks to Joshua, Laurent, plc-user, and everyone for their work to date on this migration effort!

For the last few weeks I've been working on building and running QElectroTech on macOS Apple Silicon, motivated in part by my 2015 MacBook's SSD dying recently. I'm a very inexperienced developer, so it was the perfect excuse to try applying AI coding tools — notably Claude and Claude Code, with Understand-Anything for static codebase analysis. I've tried to let those tools inform rather than replace understanding before making changes, however I don't know what I don't know — thanks in advance for going easy, while still holding me to the highest coding standards and best practices on anything my new friend Claude and I might hopefully contribute.

Here's a summary of what's been achieved to date:

Build environment

- Mac Mini M4, macOS Tahoe (26.5)
- Qt 6.11.1 via Homebrew
- KDE Frameworks 6 (v6.22.0) — built from source via the branch's BUILD_KF6=ON option (CMake FetchContent), not system packages
- CMake build targeting qt6_cmake_joshua

State of the build

- Clean build from source ✓
- Application launches and runs ✓
- No significant functional regressions observed during testing relative to the branch baseline

Branch: hairykiwi/qelectrotech-source-mirror, branch qt6_cmake_joshua

Fixes so far

(9 commits ahead of upstream; full log available on request)

Runtime correctness — old-style SIGNAL/SLOT string connections that compiled but silently failed under Qt6:
- Folio auto-numbering: added the missing BorderTitleBlock::setAutoPageNum slot and moved the connection to new-style (compile-time-checked) syntax
- Window title now updates again: reconnected to BorderTitleBlock's actual informationChanged signal (the old code referenced a signal that doesn't exist on that class, so it silently never connected)

Qt6 API migrations:
- QFont weight: Qt5 serialised Thin as weight 0, which Qt6's setWeight() rejects (valid range 1–1000). Added QETApp::sanitizeFontString() applied at all 11 fromString() call sites, plus the two direct setWeight() sites reading QSettings — so existing Qt5-origin .qet files (and Qt5-written settings) have their font weights read correctly under Qt6. (Note: this is the read/import direction — I haven't tested whether a file saved under Qt6 round-trips back into an old Qt5 build.)
- QSignalMapper::mapped() → mappedInt / mappedObject (+ qOverload for map())
- QWheelEvent::delta() → angleDelta().y()
- qHash signatures uint → size_t
- qsizetype → int narrowing via static_cast

macOS / build system:
- Qt6 + KF6 (FetchContent) build on Homebrew: disabled hanging network fetches during configure, worked around empty-destination install errors, and resolved duplicate-target errors from KF6 building against Homebrew's newer extra-cmake-modules
- Dev builds run from the build dir now resolve elements/titleblocks/lang via relative paths (Debug) rather than bundle-relative Release paths

Known remaining issues

(at time of writing — live list tracked here)
- sources/main.cpp: app name temporarily set to "QElectroTech-Qt6" to avoid a SingleApplication conflict with the Qt5 build — to be reverted before any PR
- "The requested buffer size is too big" — Qt6 SVG renderer is stricter
- qAsConst() → std::as_const() warnings throughout (not yet addressed)
- Display menu missing entries for Collections and Templates windows (reachable via Help → Search "Collections") — appears to be a pre-existing Qt6 migration issue
- "QDomDocument called with unopened QIODevice" — Qt6 stricter I/O, seen when loading titleblock templates
- "QWidget::setLayout: Attempting to set QLayout on StyleEditor which already has a layout" — element editor
- "QBoxLayout::insert: index out of range" — on new diagram creation
- "QObject::disconnect: wildcard call ... AutoNumberingDockWidget" — fires on quit, minor
- Font weight inconsistency in Qt5-origin .qet files — elements saved with explicit Thin weight render lighter than Normal; cosmetic, not introduced by the Qt6 migration

General caveat: as someone unfamiliar with several of QET's subsystems, there are surely issues I haven't encountered or wouldn't know to look for.

On the tooling side: I used the Understand-Anything plugin for Claude Code to generate an interactive architecture map ("knowledge graph") which is helping both me and Claude Code navigate QET's large and unfamiliar codebase. The knowledge graph is committed to my fork, so anyone interested can reuse it without running the analysis from scratch — though whether such a generated graph belongs in an upstream PR is the lead devs' call, not something I'd assume. More on the Understand-Anything tool in a later post.

I'm happy to raise a PR when the lead devs think it's useful.

If it would help, I'm also willing to write up a macOS build walkthrough in the style of Joshua's MSYS2 doc — covering the Qt6 + KF6-from-source workflow on Apple Silicon, which differs a fair bit from the Linux package-install path.

I look forward to engaging with any constructive feedback, positive or negative!

Thanks,
hairy_kiwi

Todo:
https://www.msys2.org/docs/ci/
https://github.com/marketplace/actions/setup-msys2

Après quelques petits tests sur mes anciens fichiers ici chez moi, cela me semble bien fonctionner en Qt6 aussi bien qu'avec Qt5, bravo a tous ceux qui y on contribués.!

Comme l'a fait remarqué plc-user: un projet sauvegardé avec une version Qt6,  s'il on l"ouvre malencontreusement plus tard avec une ancienne version de QET en Qt5 les polices textes fonctionnent autrement et peuvent rendre le projet difficile à lire ou travailler.
https://qelectrotech.org/forum/viewtopi … 434#p22434

Il est donc obligatoire d"incrémenter la version de QET quand on fera le merge, afin d'avertir l"utilisateur!

De mon coté par manque de temps et une santé précaire, je n'ai encore rien préparé pour tous les scripts et environnements de packaging avec Qt6.... : "Windows, macOS  x86, aarch64, Debian stable, unstable x86, AppImage x86 and arm64, flatpak, PPA and Snap packages... "

Je rappelle que Qt5 a été annoncée "end or life" par Qt eux mêmes il y a un an il me semble...  et que depuis cette année les distributions Linux ne prendront petit a petit plus Qt5 en charge, il est donc urgent pour nous de migrer sur la dernière version du framework Qt6..

• pour la sécurité (fail zero day), corrigé que sur les versions  dites: "Qt5 for commercial license holders" !
  Soit la version payante pour les très grosses entreprises!

  
  

  Du coté de l'open source de Qt5 ces patchs ne seront disponibles qu' une fois cette nouvelle version sera declarée open-source, donc en résumé: elle ne sera libérée et disponible q"un an plus tard, au contraire de Qt6 ou les versions seront patchées rapidement.

• Pour re tester de mon coté les avancées des frameworks Qt6+ Webassembly qui ont bien progressé depuis 2022, afin de tester voir travailler sur une version SaaS ?

  Pour les novices, SaaS: est une version de QET installable sur un serveur web ou d'entreprise tournant dans un navigateur web.
  * Tres souvent demandé par de nombreux investisseurs.

The documentation is managed by git, feel free to create a new one in English (in a new folder named 'en' please). The readme.md ( https://github.com/qelectrotech/qelectr … /README.md ) have now a link to this documentation under the section development.

Tested under my debian sid and a fresh ubuntu 25.04 vm.

Dependency :

sudo apt install git qtcreator cmake qt6-tools-dev qt6-svg-dev libsqlite3-dev libkf6coreaddons-dev extra-cmake-modules libkf6widgetsaddons-dev

Hi Carl, done.

Best regards,
Laurent

It's sad that elevatormind is no longer participating here!
He contributed several pull requests for eliminating KF5/KF6 and introduced a number of changes to QETs code to compile/work under Qt6, which he also explained and described here in the forum.

Considering the number of changes since the last official release, I would be in favor of making a release now before the Qt6 port, and then another once the port to Qt6 is done.

Another random note, last I looked the most recent git version when trying to use the DXF importer links to Antonio's github to download dxf2elmt. It's probably worth updating to mine so people are being pointed at the most up to date version of dxf2elmt. Since my laptop died right before I went on holiday, I'm not in a good spot to try and submit a pull request with the update myself right now, but perhaps I can get to it next week when I'm back unless someone wants to update it in the mean time.

Hi Joshua,

As a whole I agreed, the KF6 libraries are pretty well tested and if they can be used instead of re-implementing them it makes sense. Why take on the extra work and possibly introduce bugs, if it's not necessary.

My main question here comes down to Windows. As I understand it KF6 can build on Windows, but I haven't succeeded yet. I was trying to get QET building on my Windows based work machine to see what I could do to help with the Qt 6 progress. The sticking point was KF6, the Windows build instructions that have been mentioned in the forum use vcpkg. Vcpkg only has KF5, and I found some issues and forum posts, it doesn't look like KF6 is coming to vcpkg any time soon. I started looking into getting KDE Craft set up so I could compile KF6 on Windows and maybe getting it working with a Qt6 version of QET, but didn't get it working before I went on vacation (I didn't bring my Windows based work laptop with me, and I won't be back for another few days).

If I recall correctly Laurent said somewhere in the forums that the official Windows release is cross-compiled from Linux. If that is the case, and it's working fine with Qt6 and KF6, than perhaps getting QET and KF6 building directly on Windows isn't that big of a deal, although I think it would be nice to actually be able to build the program on Windows itself.

Have you tested your branch on Windows, or tested cross-compiling it?
Is this branch publicly available if I wanted to try and do some testing on it?

https://qelectrotech.org/forum/viewtopic.php?id=3058

is gone with QT6?

Translated english
Résultat de la traduction

Hello, during my vacation I tested switching to qt6 and kf6 on a new branch based on the master (with a mix of commits from the qt6 cmake branch). It's not quite finished yet, but it's coming along nicely. However, I have no problems with the KF6 libraries. Why remove kautosavefile and kwidgetaddon, only to reimplement them ourselves? I don't see the point. I would much rather keep code from KF6, which has been extensively corrected and tested, than reinvent the wheel. Have I missed something?