D25561: Remove unused signal we can use directly "signal(const QUrl&)
David Faure
noreply at phabricator.kde.org
Wed Nov 27 17:47:42 GMT 2019
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191127/8e328b66/attachment.html>
More information about the Kde-frameworks-devel
mailing list