D29281: Deprecate defunct functions

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> kossebau wrote in abstractrunner.cpp:221
> Given EXCLUDE_DEPRECATED_BEFORE_AND_AT is used with KRunner, you want to also wrap all the implementations of the now deprecated API with the BUILD variant of the macro, so here for example:
> 
>   #if KRUNNER_BUILD_DEPRECATED_SINCE(5, 70)
>   void AbstractRunner::createRunOptions(QWidget *parent)
>   {
>       [...]
>   }
>   #endif
> 
> This allows to build KRunner itself without any of the deprecated API actually part of the build.
> Test yourself by setting the cmake var EXCLUDE_DEPRECATED_BEFORE_AND_AT=CURRENT  (e.g. edit the var in the cmake cache).

And best practice seems to be not to do mass wrapping of many methods, but do explicitely per method. While more code/lines, has the advantage to be easier to read/understand, as usually begin/emd are in view, and also avoids that actually wrong code is wrapped (e.g. when methods get added later and by accident are placed amid the wrapped ones.

> alex wrote in abstractrunner.h:154
> That makes sense, but I want to express that this method has been defunct  since version 5.0
> so that the maintainers of existing plugins can be sure that they can savely remove the method calls.
> Whats the best way to express this?

I would just say in the docs "@deprecated Since 5,0, this feature has been defunct".  This is what has been done elsewhere where API got retrroactively tagged as deprecated. This is just text in the docs, now with up-to-date information, so other than the macros will not affect anything.

REPOSITORY
  R308 KRunner

REVISION DETAIL
  https://phabricator.kde.org/D29281

To: alex, #plasma, broulik, davidedmundson, vkrause
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200429/6ac3b091/attachment.html>