D25545: Rename signal for avoiding overload signal

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D25545#568090 <https://phabricator.kde.org/D25545#568090>, @dfaure wrote:
  
  > Looks good to me. Friedrich, what did we conclude about deprecating signals?
  
  
  From https://phabricator.kde.org/D24466#547023 & ff. I took with me that deprecating signals like methods should be fine, and will work WRT visibility and warnings at least with member-function-pointer-based connects.
  
  For the rest looks good also to me. Happy to see that ecm_generate_export_header usage can be applied as intended by somebody else than me :)
  
  Though one thing (which I also only fixed in later commits) is missing: instructing KApiDox & ecm_add_qch about the new deprecation macros (they need some help sadly). Cmp. e.g.
  R244:344565e7f6c6782b287d73373e7ce2319c80eab2 <https://phabricator.kde.org/R244:344565e7f6c6782b287d73373e7ce2319c80eab2> for kcoreaddons, and see also https://community.kde.org/Policies/Library_Code_Policy#Deprecation_of_API

INLINE COMMENTS

> dialog.h:102
>       * The dialog won't be closed if you setBuffer() in slot connected to this signal
> -     *
> +     * @deprecated Since 5.65, use spellCheckDone
>       * Also emitted after stop() signal

@deprecated Should be last in docs text,
Cmp. also https://community.kde.org/Frameworks/Frameworks_Documentation_Policy#Document_Public_and_Protected_Members

REPOSITORY
  R246 Sonnet

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

To: mlaurent, dfaure, kossebau
Cc: 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/20191126/cdd620bd/attachment.html>