New signal for replacing done(const QString &)
Details
- Reviewers
dfaure kossebau - Commits
- R246:f6f6aa244b55: Rename signal for avoiding overload signal
build
Diff Detail
- Repository
- R246 Sonnet
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
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 for kcoreaddons, and see also https://community.kde.org/Policies/Library_Code_Policy#Deprecation_of_API
src/ui/dialog.h | ||
---|---|---|
101–102 | @deprecated Should be last in docs text, |
docs/Doxyfile.local | ||
---|---|---|
5 | The predefined macros we want to tell doxygen about in the case of kapidox (being run in a non-build checkout, so without the generated headers/sources) are both the variants of the 3 macros for SONNETCORE and SONNETUI, not KCOREADDONS :) In case you wonder about the differences for instructions to ecm_add_qch, kapidox processes the whole sources with both libs into one documentation module, while the ecm macro is used to create two separate QCH files, one per library. | |
src/core/CMakeLists.txt | ||
36 | Given there is nothing yet deprecated in the core lib, you want for now to not pass any DEPRECATION_VERSIONS args (to avoid the respective generated preprocessor code). # DEPRECATION_VERSIONS 5.x | |
src/ui/dialog.h | ||
110 | The @since would ideally also be move to the end of the docs. |