D24965: KConfigWidgets: port away from KF5 deprecated API

2019-11-20 Thread David Faure
dfaure closed this revision. REPOSITORY R265 KConfigWidgets REVISION DETAIL https://phabricator.kde.org/D24965 To: dfaure, kossebau, elvisangelaccio, vkrause Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24965: KConfigWidgets: port away from KF5 deprecated API

2019-10-29 Thread Friedrich W. H. Kossebau
kossebau accepted this revision. kossebau added a comment. This revision is now accepted and ready to land. Tired given the time, but let's see if I get things straight this time: Given KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x053f00, in the API of KConfig we just see

D24965: KConfigWidgets: port away from KF5 deprecated API

2019-10-26 Thread David Faure
dfaure added a comment. Funnily enough, the 5.39 is irrelevant, since we don't support building with older versions of KConfig. But it becomes relevant because we support enabling one and not the other, as you mention. We could cheat and just s/38/39/ here, it wouldn't harm anyone. If

D24965: KConfigWidgets: port away from KF5 deprecated API

2019-10-26 Thread Friedrich W. H. Kossebau
kossebau added inline comments. INLINE COMMENTS > kossebau wrote in kstandardaction_p.h:103 > Hm, KStandardShortcut::SaveOptions_DEPRECATED_DO_NOT_USE should not be needed > to be used here. > Does the use of KF_DISABLE_DEPRECATED_BEFORE_AND_AT trigger this? If so, IMHO >

D24965: KConfigWidgets: port away from KF5 deprecated API

2019-10-26 Thread David Faure
dfaure added inline comments. INLINE COMMENTS > kossebau wrote in kstandardaction_p.h:103 > Hm, KStandardShortcut::SaveOptions_DEPRECATED_DO_NOT_USE should not be needed > to be used here. > Does the use of KF_DISABLE_DEPRECATED_BEFORE_AND_AT trigger this? If so, IMHO > ECMGenerateExportHeader

D24965: KConfigWidgets: port away from KF5 deprecated API

2019-10-26 Thread Friedrich W. H. Kossebau
kossebau added inline comments. INLINE COMMENTS > kstandardaction_p.h:103 > #if KCONFIGWIDGETS_BUILD_DEPRECATED_SINCE(5, 38) > -{ SaveOptions, KStandardShortcut::SaveOptions, "options_save_options", > I18N_NOOP(" Settings"), nullptr, nullptr }, > +{ SaveOptions,

D24965: KConfigWidgets: port away from KF5 deprecated API

2019-10-26 Thread David Faure
dfaure updated this revision to Diff 68797. dfaure added a comment. Keep code for compat. Requires D24971 . REPOSITORY R265 KConfigWidgets CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D24965?vs=68789=68797 BRANCH master REVISION DETAIL

D24965: KConfigWidgets: port away from KF5 deprecated API

2019-10-26 Thread David Faure
dfaure added a comment. Sorry, you were very clear, I just forgot that the compiler warning comes from a different macro :-) REPOSITORY R265 KConfigWidgets REVISION DETAIL https://phabricator.kde.org/D24965 To: dfaure, kossebau, elvisangelaccio, vkrause Cc: kde-frameworks-devel,

D24965: KConfigWidgets: port away from KF5 deprecated API

2019-10-26 Thread Friedrich W. H. Kossebau
kossebau added a comment. So seems I missed to make clear what I meant, next try :) The goal is: make clients (e.g. apps) which are still using this method to set the app icon aware by a compiler warning that they should port their code to use QApplication::setWindowIcon. For that we

D24965: KConfigWidgets: port away from KF5 deprecated API

2019-10-26 Thread David Faure
dfaure added a comment. Why would I need to push/pop warning, if the method call doesn't trigger any warning anymore? REPOSITORY R265 KConfigWidgets REVISION DETAIL https://phabricator.kde.org/D24965 To: dfaure, kossebau, elvisangelaccio, vkrause Cc: kde-frameworks-devel, LeGast00n,

D24965: KConfigWidgets: port away from KF5 deprecated API

2019-10-26 Thread Friedrich W. H. Kossebau
kossebau added a comment. In D24965#554393 , @dfaure wrote: > So basically we just use //KF6 TODO REMOVE for programIconName, but still use the macro around setProgramIconName? Works for me. Yes, remove the

D24965: KConfigWidgets: port away from KF5 deprecated API

2019-10-26 Thread David Faure
dfaure added a comment. So basically we just use //KF6 TODO REMOVE for programIconName, but still use the macro around setProgramIconName? Works for me. REPOSITORY R265 KConfigWidgets REVISION DETAIL https://phabricator.kde.org/D24965 To: dfaure, kossebau, elvisangelaccio, vkrause Cc:

D24965: KConfigWidgets: port away from KF5 deprecated API

2019-10-26 Thread Friedrich W. H. Kossebau
kossebau added a comment. This falls into a category I also saw elsewhere doing all the patches, where the same API is used from two sides: the client side, like application code, and the serving side, like infrastructure. While we want to tell the client side, stop using this and for

D24965: KConfigWidgets: port away from KF5 deprecated API

2019-10-26 Thread David Faure
dfaure added a comment. The goal is to set KF_DISABLE_DEPRECATED_BEFORE_AND_AT, so this isn't just about a warning, it's about API that no longer exists. But I guess we can't do that then, if we want to preserve compatible behavior until KF6... REPOSITORY R265 KConfigWidgets REVISION

D24965: KConfigWidgets: port away from KF5 deprecated API

2019-10-26 Thread David Faure
dfaure added a reviewer: vkrause. REPOSITORY R265 KConfigWidgets REVISION DETAIL https://phabricator.kde.org/D24965 To: dfaure, kossebau, elvisangelaccio, vkrause Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24965: KConfigWidgets: port away from KF5 deprecated API

2019-10-26 Thread Friedrich W. H. Kossebau
kossebau added a comment. While being deprecated, there might be code still using it, and you are killing support for that now, which is backwards-incompatibel. IMHO the support should be kept. And we want to rather have a generic way to disable the warning here (still TODO to have

D24965: KConfigWidgets: port away from KF5 deprecated API

2019-10-26 Thread David Faure
dfaure created this revision. dfaure added reviewers: kossebau, elvisangelaccio. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. dfaure requested review of this revision. REVISION SUMMARY KAboutData::setProgramIconName is deprecated and says "Use