https://bugs.kde.org/show_bug.cgi?id=408240
--- Comment #8 from vialav <d...@bk.ru> --- Oh, Nikita, that Qt v5.9.5 installation on your system too came as a positive surprise to me! Which KDE frameworks are you using, if I may ask? I had to, very-very selectively get rid of the specific Qt 5.10.0 very-very few commit(s) in KDE 5.58.0 frameworks tests (such as fancy QML autotest for example, thoroughly verified, anyway I didn't need them) to wed it to Qt 5.9.5. Then I had the whole KDE universe accessible. I think, it is where the issue may nest, in the KDE limited to << Qt 5.10.0 (my KDE 5.58.0 was specifically *backported* to the lower Qt 5.9.5, so it behaves identically like under Qt 5.10.0 and up). May you try compile your Cantor under Qt 5.10.0 - Qt 5.11.1 + KDE 5.50.0 - KDE 5.58.0 and see where it goes? You may either set-up quickly a VM with the cosmic Ubuntu distribution (in this case the eoan Ubuntu KDE sources needs to be back-compiled) or set-up the eoan Ubuntu distribution (in which case the lower bound would be, unfortunately, Qt 5.12.2) The result, it is my wild guess, may or may not highlight the referred issue. Or, may be, someone may volunteer for this. In any case, it is not the question of interacting KDE with Qt, but rather about the compatibility of the Cantor with the latest releases of KDE (which on some distributions unfortunately drags into play newer Qt releases, so, backporting was a very good solution to this problem), which might be of interest for you future Cantor development process. I am aware that it could sound too much for an isolated issue, so it is up to your availability. @Alexander Semke > do you clean your build folder when switching between the different commits? > Can you please do make clean and try again with the current master? When switching between the different commits I am using separate tarballs in separate directories which are cleaned up by the packaging process even though I always begin manually removing the whole tree, and unpacking the sources from a snapshot tarball. I think, it rules out any "dirty" tree which might interfere with the building/packaging process, but thank you for letting me clarify this. $ git describe --tags v19.04.1-57-g27d29471 was the last commit I tried yesterday, which still bears the reported issue. There was just one commit fixing a typo "direct" -> "directly" after that. $ git checkout master $ git describe --tags v19.04.1-58-gf401718d -- You are receiving this mail because: You are watching all bug changes.
