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