D24892: Fix usage of the new deprecation macros for assignIconsToContextMenu

[Volker Krause]

vkrause added a comment.


  In D24892#552838 <https://phabricator.kde.org/D24892#552838>, @kossebau wrote:
  
  > Looks good. Perfect would be if you tested KIconThemes  with EXCLUDE_DEPRECATED_BEFORE_AND_AT set to hexnumber(5.64.0), to see if there is no internal usage still happening, like with autotests which might need to support such a build with KICONTHEMES_ENABLE_DEPRECATED_SINCE (ENABLE variant, as external to lib).
  
  
  Assuming I used this correctly (setting EXCLUDE_DEPRECATED_BEFORE_AND_AT to 054000) this doesn't build independent of assignIconsToContextMenu, due to the Q_ENUM code generated for KIconLoader still referencing the deprecated FileSystem enum element?
  
  > In general, given even you missed this (both the build disabling of the implementation as well as testing the build with EXCLUDE_DEPRECATED_BEFORE_AND_AT, I asume), I wonder if the support for build-without-deprecated should not be removed again from KDE Frameworks (though not the ECM macro, it works and others might find it useful). KF contributors/builders might not really need it or gain from it before actually KF6 gets created, and things are fragile enough with the new deprecation macros even without that feature (think virtual methods & enums being accidentally wrapped by *_ENABLE_DEPRECATED_SINCE...
  
  It has just been added and I assume people still need to get used to it and we are still ironing out the last issues, so maybe give it a bit more time before pulling it out again right away :) It does have BC and maintenance challenges for sure, but IMHO that is ok as I don't really see it as something to use in production rather than as a tool to help with migrations to new major version.

INLINE COMMENTS

> kossebau wrote in kicontheme.h:292
> Is "// TODO KF6 remove" really needed BTW?
> 
> Personally I would be strict and for KF6 just dump any API deprecated in KF5 times.
> Do you think there will be deprecated API we should keep around even in KF6?
> Or should this be considered on case-by-case once KF6 is created?

I am unsure about that, therefore I'm opting for the safe approach :) It is IMHO possible some deprecate API will stay, e.g. if it got deprecated before having strict rules on porting away from such API or the porting impact turning out more complex than anticipated. I'm therefore only adding the KF6 todos in places where they could be executed immediately when disregarding BC.

REPOSITORY
  R302 KIconThemes

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

To: vkrause, 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/20191024/b4fd51df/attachment.html>