kossebau added a comment.
In D24466#546952 <https://phabricator.kde.org/D24466#546952>, @dfaure wrote: > Maybe Qt doesn't have any deprecated signals? That would be nice :) A few there are though, e.g. see here some for QComboBox, only using `QT_DEPRECATED_SINCE` & `QT_DEPRECATED_VERSION_X`, but not `QT_MOC_COMPAT`: https://code.woboq.org/qt5/qtbase/src/widgets/widgets/qcombobox.h.html#223 Perhaps people forgot about it, the macro also not being documented anywhere. Now finally got around to do some test code to check deprecation with signal/slots: #include <QObject> #include <QCoreApplication> #include <QDebug> class Object : public QObject { Q_OBJECT public Q_SLOTS: Q_DECL_DEPRECATED QT_MOC_COMPAT void slotIt() { qDebug() << "handling signal"; } Q_SIGNALS: Q_DECL_DEPRECATED QT_MOC_COMPAT void signalIt(); }; int main(int argc, char *argv[]) { QCoreApplication app(argc, argv); Object object; QObject::connect(&object, SIGNAL(signalIt()), &object, SLOT(slotIt())); QObject::connect(&object, &Object::signalIt, &object, &Object::slotIt); emit object.signalIt(); return 0; } #include "main.moc" When building this gives: main.cpp: In function ‘int main(int, char**)’: main.cpp:29:40: warning: ‘void Object::signalIt()’ is deprecated [-Wdeprecated-declarations] 29 | QObject::connect(&object, &Object::signalIt, &object, &Object::slotIt); | ^~~~~~~~ main.cpp:20:10: note: declared here 20 | void signalIt(); | ^~~~~~~~ main.cpp:29:68: warning: ‘void Object::slotIt()’ is deprecated [-Wdeprecated-declarations] 29 | QObject::connect(&object, &Object::signalIt, &object, &Object::slotIt); | ^~~~~~ main.cpp:13:10: note: declared here 13 | void slotIt() { | ^~~~~~ main.cpp:31:26: warning: ‘void Object::signalIt()’ is deprecated [-Wdeprecated-declarations] 31 | emit object.signalIt(); | ^ main.cpp:20:10: note: declared here 20 | void signalIt(); | ^~~~~~~~ and when running just handling signal handling signal so no runtime warning about the compat signal or slot. Possibly as QT_NO_DEBUG is said to be defined for Qt release builds, so `check_and_warn_compat` will not be run. So having a _DEPRECATED with signal makes sense also for consumers connecting to the signal with memberfunction-pointer based connect. Will adapt the other patches accordingly. Not sure what to do about the QT_MOC_COMPAT, so far it should not hurt to keep them, but the question is how useful adding new ones is and whether this is future-proof. REPOSITORY R263 KXmlGui BRANCH deprecatedapi REVISION DETAIL https://phabricator.kde.org/D24466 To: kossebau, #frameworks, dfaure, mlaurent Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
