*** Bug 408241 has been marked as a duplicate of this bug. ***

Could you please go to build directory, open CMakeCache.txt and check that variables QMAKE_EXECUTABLE and Qt5*_DIR point to system qt?
Also could you find your qdialogbuttonbox.h (for example, my path /usr/include/x86_64-linux-gnu/qt5/QtWidgets/qdialogbuttonbox.h) and mannually check that signals ::rejected and ::accepted.

If the signals and cmake use proper system qt, that will means, what your qt broken from June 1, for example, by update.

(For being slow and late I'm sorry, starting from Monday I have much less time for reporting.)

There were no doubts that it it the system-wide Qt installation, so to confirm:

$ pwd
/home/cantor/cantor-19.07.70+git20190603

$ cat $(find -type f -name CMakeCache.txt) | grep Qt5 | grep _DIR
Qt5Concurrent_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt5Concurrent
Qt5Core_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt5Core
Qt5DBus_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt5DBus
Qt5Gui_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt5Gui
Qt5Network_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt5Network
Qt5PrintSupport_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt5PrintSupport
Qt5Svg_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt5Svg
Qt5Test_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt5Test
Qt5Widgets_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt5Widgets
Qt5XmlPatterns_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt5XmlPatterns
Qt5Xml_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt5Xml
Qt5_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt5

$ cat $(find -type f -name CMakeCache.txt) | grep QMAKE_EXECUTABLE
QMAKE_EXECUTABLE:FILEPATH=/usr/lib/qt5/bin/qmake


$ locate qdialogbuttonbox.h | grep qt5
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qdialogbuttonbox.h
/usr/share/qt5/doc/qtwidgets/qdialogbuttonbox.html

$ dpkg -S /usr/include/x86_64-linux-gnu/qt5/QtWidgets/qdialogbuttonbox.h
qtbase5-dev:amd64: /usr/include/x86_64-linux-gnu/qt5/QtWidgets/qdialogbuttonbox.h

$ dpkg -l qtbase5-dev
…
||/ Name              Version             Architecture Description
+++-=================-===================-============-=================================
ii  qtbase5-dev:amd64 5.9.5+dfsg-0ubuntu2 amd64        Qt 5 base development files

$ cat /usr/include/x86_64-linux-gnu/qt5/QtWidgets/qdialogbuttonbox.h | grep -e rejected -e accepted
    void accepted();
    void rejected();

$ cd /usr/include/x86_64-linux-gnu/qt5/QtWidgets && grep -rnw -e rejected -e accepted
5.9.5/QtWidgets/private/qabstractitemview_p.h:171:        // Drag enter event shall always be accepted, if mime type and action match.
5.9.5/QtWidgets/private/qwidgetlinecontrol_p.h:545:    void accepted();
qdialog.h:89:    void accepted();
qdialog.h:90:    void rejected();
qdialogbuttonbox.h:147:    void accepted();
qdialogbuttonbox.h:149:    void rejected();

> If the signals and cmake use proper system qt, that will means, what your qt broken from June 1, for example, by update.

That could also mean the difference from Qt on your system and mine. I doubt you use Qt v5.9.5. You may find the full set of headers packaged in Ubuntu on:
https://packages.ubuntu.com/src:qtbase-opensource-src

and trace the changes by cloning:
git://code.qt.io/qt/qtbase.git

…then run 

git checkout $your_version
and
git log -p $the_file_in_question # down to Qt v5.9.5

Those were my thougts, if it is about a subtle particular change in API.

(In reply to vialav from comment #4)
> > If the signals and cmake use proper system qt, that will means, what your qt broken from June 1, for example, by update.
> 
> That could also mean the difference from Qt on your system and mine. I doubt
> you use Qt v5.9.5.

$ LANG=en_EN.UTF-8 dpkg -l qt5-default
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                  Version         Architecture    Description
+++-=====================-===============-===============-================================================
ii  qt5-default:amd64     5.9.5+dfsg-0ubu amd64           Qt 5 development defaults package

Also i had checked my qdialogbuttonbox.h and qdialogbuttonbox.h from source via diff and there aren't differents.

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?

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

Alternatively, you may temporary 'spice over' the code with multiple debug breakpoints/messages, which I would be happy to test on my system.

As a last measure I'll reinstall qtbase5-dev (remove and install again the same package), so to ensure it is the same.

(In reply to vialav from comment #8)
> 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 use KDE frameworks 5.49.0, builded from sources.

(In reply to vialav from comment #8)
> 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?
I had created VM with Ubuntu Cosmic with Qt 5.11.1 (qt5-default from repository) and KDE frameworks 5.50.0 (from repository) and build Cantor from sources (master branch).
No qt conection problems, Python backends (both) works as expected and pass all tests.

I will build KDE frameworks 5.58.0 and see, how it will work.

_ It is just to report, that I've re-installed qtbase5-dev, and re-compiled Cantor which still has the reported issue _

If you succeed with KDE 5.58.0 + Qt 5.11.1 and Cantor under those with no issues, I'll say I'm out of ideas, so 'code spicing' or marking the above as unresolvable for the time being…

(In reply to vialav from comment #13)
> _ It is just to report, that I've re-installed qtbase5-dev, and re-compiled
> Cantor which still has the reported issue _
> 
> If you succeed with KDE 5.58.0 + Qt 5.11.1 and Cantor under those with no
> issues, I'll say I'm out of ideas, so 'code spicing' or marking the above as
> unresolvable for the time being…

Okay, I had mark this as unresolvable.
But fair, I think that this is a problem with backporting KF5 on Qt or something like that.

Have you build KDE 5.58.0 and got the working Cantor? I meant 'if you succeed with KDE 5.58.0'.

(In reply to vialav from comment #15)
> Have you build KDE 5.58.0 and got the working Cantor? I meant 'if you
> succeed with KDE 5.58.0'.

Arg, got it. Still build KDE 5.58.

Ok, thank you. Because Cantor is on Ubuntu's eoan, and it has those KDE's. So, there could be "underwater stones" ahead of a new Cantor release if this issue remains latent. Best to you with getting that new development environment for testing ahead.

Successfuly build and run Cantor on Ubuntu Cosmic with builded KDE Frameworks 5.59

Created attachment 120588 [details]
Cantor on KDE Frameworks 5.59

Congrats. So, the issue has been narrowed to my backporting to Qt 5.9.5. You have confidently demonstrated that Cantor is compatible with the latest KDE.

I would be grateful for some guidance which lines of code in Cantor has changed  from 1 June which are responsible for Qt signalling, so I may try to chase it down in my backport, if you don't mind. 

I'll also try to build Cantor outside the debian packaging (I've never tried to explore that avenue).

(In reply to vialav from comment #20)
> I would be grateful for some guidance which lines of code in Cantor has
> changed  from 1 June which are responsible for Qt signalling, so I may try
> to chase it down in my backport, if you don't mind. 

All changes from June 1 with signals
$ git diff HEAD..68cfbad2de0257a7bd96406a94b49ba5e0f25c13  | /bin/grep connect
+ connect(m_process, &QProcess::errorOccurred, this, &JuliaSession::reportServerProcessError);
+ disconnect(m_process, &QProcess::errorOccurred, this, &JuliaSession::reportServerProcessError);
- // connect(m_expression, &Cantor::Expression::statusChanged, this, &PythonCompletionObject::extractCompletions);
+ connect(m_expression, &Cantor::Expression::statusChanged, this, &PythonCompletionObject::extractCompletions);
- // connect(m_expression, &Cantor::Expression::statusChanged, this, &PythonCompletionObject::extractIdentifierType);
+ connect(m_expression, &Cantor::Expression::statusChanged, this, &PythonCompletionObject::extractIdentifierType);
+ QObject::connect(&inputTimer, &QTimer::timeout, QCoreApplication::instance(), &QCoreApplication::quit);
+ connection = QObject::connect(&inputTimer, &QTimer::timeout, routeInput);
+ connect(m_process, &QProcess::readyReadStandardOutput, this, &PythonSession::readOutput);
+ connect(m_expression, &Cantor::Expression::statusChanged, this, &PythonVariableModel::extractVariables);

I have built Cantor outside the Debian/Ubuntu packaging, and… it works as intended. No issues whatsoever, and all the buttons work. Thanksfully to your hint with the recent KDE frameworks, it turns out it was never the issue of backporting, which I was sure about 100%.

I has investigated what was the difference since both were compiled against the same set of libraries/headers, and the cause was somewhat unexpected: 

If Cantor is to be compiled with the Link-Time-Optimization LTO flag -flto (**in my case** the CXXFLAGS/CFLAGS contain: -flto=jobserver -flto-compression-level=9), **then it loses Qt signals**. Perhaps unrelated, but _before_ compilation I've unset QT_IM_MODULE=ibus, however, the dividing difference was compilation with (also incompatible with parallel building in this case; make -j 1) or without LTO, which worked for me in the latter case. 

$ gcc --version
gcc (Ubuntu 9.1.0-2ubuntu2) 9.1.0

I have built the system-wide Cantor package without LTO, which works now under Debian/Ubuntu. I can only hope that the sage backend (#408176) will receive some love, and, perhaps, it could become possible to re-introduce LTO in later releases.

Thank you for your cooperation, it seems we all are learning something new out of encountering, and successfully dealing with, such rare events as the present issue.

(just a one-liner: could you check if you have the backends icons in File -> New under your normal developing environment [Qt 5.9.5], it seems we've lost them in transition; it would be also convenient to have the 'Open Recent' files in Cantor)

(In reply to vialav from comment #23)
> just a one-liner: could you check if you have the backends icons in File ->
> New under your normal developing environment [Qt 5.9.5], it seems we've lost
> them in transition; 

BUG 408336

> it would be also convenient to have the 'Open Recent' files in Cantor
Good idea, maybe we will implement it.

Looks like investigating Cantor and Link-Time-Optimization interaction will tooks a lot of time, so I think in this moment we don't not ready to do this (because there are more important and often bugs in Cantor).
So I had mark this as WONTFIX, but maybe in future we will handled this problem.

https://bugreports.qt.io/browse/QTBUG-43556