I agree, a similar effort is happening in Qt as well.

Yeah, the Qt plan was sort of the instigator for this one :)

I used clazy to detect overloaded signals, in some cases the signals had already been un-overloaded so I just added clazy:exclude=overloaded-signal comments, to silence the warning. Some changes have already been merged, and here is what remains:

• ktexteditor: for a start created https://invent.kde.org/frameworks/ktexteditor/-/merge_requests/137
• bluez-qt
• kconfigwidgets: https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/39
• kdeclarative
• kitemmodels
• knotifications: https://invent.kde.org/frameworks/knotifications/-/merge_requests/43
• ktextwidgets: https://invent.kde.org/frameworks/ktextwidgets/-/merge_requests/10

• plasma-framework: this one I don't understand, there are identical signals e.g.:

void formFactorChanged(Plasma::Types::FormFactor formFactor);

it exists in Applet and Containment, is it needed in both places because of the QProperty stuff?

@ahmadsamir Isn't this practically the same as T14370?

I mean we could move this task to "Waiting on KF6 branching" when it is no linger actionable ;)

Actually they are two different tasks, this one is about actually deprecating/un-overloading the signals; the other task is about cleaning up the API docs, i.e. removing the // clazy* exclude rules... etc.

the other task is about cleaning up the API docs, i.e. removing the // clazy* exclude rules... etc.

Okay, I thought this would be part of the cleanup after KF6 branching.

Updating the list of remaining Frameworks:

• ktexteditor
• bluez-qt
• kdeclarative
• kitemmodels
• plasma-framework

plasma-framework

I honestly don't get why there are warnings for overloaded signals emitted. Those signals are in entirely different classes and I don't see a case where one class extends from both 🤔

https://invent.kde.org/sdk/clazy/blob/master/docs/checks/README-overloaded-signal.md

Here is says that it should only apply to signals with different signatures from the same class.

When looking at the bluez-qt warnings you see sth. like

/home/user/kde/src/bluez-qt/src/imports/declarativemanager.h:55:5: warning: signal usableAdapterChanged is overloaded (with /home/user/kde/src/bluez-qt/src/manager.h:77:1) [-Wclazy-overloaded-signal]
    void usableAdapterChanged(DeclarativeAdapter *adapter);

These signals are from different classes, where one extends from the other. If one uses the PMF syntax no qOverload or casting stuff is needed.

IMHO this looks like a false positive and the usages seem valid to me.

Yeah, that makes sense.

@smartins

@ahmadsamir KCMUtils is taken care of with the last overloaded signal having an open MR,

Also I un-overloaded a signal in kwidgetaddons of the rating widget.

kitemmodels

Here private signals are overwritten and no overload is specified.

Is there anything actionable at this point?

In T13986#263041, @alex wrote:

@ahmadsamir KCMUtils is taken care of with the last overloaded signal having an open MR,

Also I un-overloaded a signal in kwidgetaddons of the rating widget.

kitemmodels

Here private signals are overwritten and no overload is specified.

So that the sub-class in KItemModels can emit the signal, where the base class has specifically made that signal private; two different signatures.

The question then becomes is this useful? do the QProperty declarations in e.g. kdescendantproxymodel.h work?

@dfaure

But in this task we don't have to worry about any qOverload usages for those signals :)

@ahmadsamir With kcmutils & kparts being taken care of, is this task actionable anymore?

I think only this is left:

In file included from /home/ahmad/dev/kdeclarative/src/qmlcontrols/kquickcontrolsaddons/qiconitem.cpp:8:
/home/ahmad/dev/kdeclarative/src/qmlcontrols/kquickcontrolsaddons/qiconitem.h:56:5: warning: signal smoothChanged is overloaded (with /usr/include/qt5/QtQuick/qquickitem.h:97:1) [-Wclazy-overloaded-signal]
    void smoothChanged();
    ^
/home/ahmad/dev/kdeclarative/src/qmlcontrols/kquickcontrolsaddons/qiconitem.h:57:5: warning: signal stateChanged is overloaded (with /usr/include/qt5/QtQuick/qquickitem.h:97:1) [-Wclazy-overloaded-signal]
    void stateChanged(State state);
    ^

Isn't that the same as T13986#261203 since these signals are in different classes?

Right; I tested and that seems to work, so it's a false positive (and apparently I am slightly confused about this issue).

/home/nico/kde6/src/kwidgetsaddons/src/kcolorcombo.h:86:5: warning: signal activated is overloaded (with /usr/include/qt6/QtWidgets/qcombobox.h:23:1) [-Wclazy-overloaded-signal]

/home/nico/kde6/src/kwidgetsaddons/src/kcharselect_p.h:81:5: warning: signal activated is overloaded (with /usr/include/qt6/QtWidgets/qabstractitemview.h:25:1) [-Wclazy-overloaded-signal]

/home/nico/kde6/src/kwidgetsaddons/src/kpagewidget.h:125:5: warning: signal currentPageChanged is overloaded (with /home/nico/kde6/src/kwidgetsaddons/src/kpageview.h:49:1) [-Wclazy-overloaded-signal]

/home/nico/kde6/src/kwidgetsaddons/src/kmultitabbar.h:167:5: warning: signal clicked is overloaded (with /usr/include/qt6/QtWidgets/qabstractbutton.h:22:1) [-Wclazy-overloaded-signal]

/home/nico/kde6/src/kwidgetsaddons/src/kmultitabbar.h:235:35: warning: 'KMultiTabBarTab::initStyleOption' hides overloaded virtual function [-Woverloaded-virtual]

/home/nico/kde6/src/kwidgetsaddons/src/kcolorcombo.h:86:5: warning: signal activated is overloaded (with /usr/include/qt6/QtWidgets/qcombobox.h:23:1) [-Wclazy-overloaded-signal]
/home/nico/kde6/src/kwidgetsaddons/src/kcharselect_p.h:81:5: warning: signal activated is overloaded (with /usr/include/qt6/QtWidgets/qabstractitemview.h:25:1) [-Wclazy-overloaded-signal]

But those do not force one to use the qOverload/casting stuff, because the overload is defined in another class.

Another problem is FileSystemFreeSpaceJob in KIO

https://invent.kde.org/frameworks/kio/-/merge_requests/1354