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
