Qt 6.0 development and qelectrotech (Page 7 of 7)

French :
Bonjour, durant mes vacances j'ai testé sur une nouvelle branche basé sur le master (avec des mélanges de commit provenant de la branche qt6 cmake) la bascule avec qt6 et kf6. Tout n'est pas encore fini mais ça avance bien. Par contre je n'ai aucun problème avec les bibliothèques KF6. Pourquoi avoir supprimé kautosavefile ainsi que kwidgetaddon, pour les réimplementé nous même ? Je n'en vois pas l'intérêt, je préfère largement garder du code provenant de KF6 qui est grandement corrigé et testé que de réinventer la roue. Ai je raté quelque-chose ?

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?

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?

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.

Hello everyone, I created a new branch named qt6_cmake_joshua based on the current master at the date of 27/01/2026 (and the work of plc_user in branch qt6-cmake) available on our git repository.
It compil well (with qt6 and kf6). There is a lot of things who doesn't work probably due to change make by Qt6, but it's a good start I think.

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

Salut Joshua,
tout d'abord bravo à tous ceux qui y contribué: plc-user, elevatormind, vadoola Joshua, etc...

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.

Hi everyone,

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