dfaure added a comment.
Yeah, but these days with lambdas, we can find out who emitted the signal,
without the need for an identifier as signal argument...
connect(urlLabel, qOverload<>(&KUrlLabel::leftClickedUrl), this, [this,
urlLabel]() { selectFolder(urlLabel->url()); } );
should work too.
This way the application can choose whether it wants the URL or the KUrlLabel
pointer in the slot, or whatever else.
I'm not 100% sure what's best -- e.g. QPushButton has clicked() without
arguments, while KJob as result(KJob*) because it's convenient for the slot.
With lambdas we don't really need the KJob* anymore. Capturing the local job
variable instead would even remove some static_cast to subclasses in a number
of cases. But the porting effort would be huge, so I'm reluctant :-)
I guess this is most closely related to QPushButton though. In the simple
case (different slot for each button or URLLabel) the signal with 0 arguments
was always enough, and for the dynamic case (N buttons or N URLLabels) we have
lambdas nowadays. Seems true for both, so I vote for deprecating the signals
with an argument, and for porting KMail to my lambda above right away.
Opinions?
REPOSITORY
R236 KWidgetsAddons
REVISION DETAIL
https://phabricator.kde.org/D25561
To: mlaurent, dfaure, kossebau
Cc: cfeck, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
