D27989: Add a new set of barcode size functions

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D27989#670659 <https://phabricator.kde.org/D27989#670659>, @vkrause wrote:
  
  > There's two remaining users in everything covered by lxr, the Plasma clipboard (patch in review: https://phabricator.kde.org/D29478) and KDE PIM (which now depends on a sufficiently new KF5 version to actually do the migration). Both ways can be argued of course, I optimized for "helps me" (the warnings for things I can't change yet don't), and "migration is my problem" rather than "migration is somebody else's problem" (which is my understanding of how we are supposed to be doing KF deprecations to ease the 6 transition).
  
  
  For projects who cannot/do not want yet to adapt to deprecated API (e.g. because they do not fancy #if version #else #endif), they can make use of the built-in features with the deprecation system to deactivate warnings for any API which was set as deprecated initially only after a certain version:
  
  - QT_DEPRECATED_WARNINGS_SINCE (as in, show warnings for API deprecated at least since or already in older versions)
  - KF_DEPRECATED_WARNINGS_SINCE (same as above, KF_ being the group default, with KFOO_ allowing to fine-tune per module)
  
  Both are by default set to the number of the current version (so all warnings are shown), but if using QT_DISABLE_DEPRECATED_BEFORE or KF_DISABLE_DEPRECATED_BEFORE_AND_AT (& KFOO_DISABLE_DEPRECATED_BEFORE_AND_AT) those are defaulting instead to the version given in those macro, so automatically disabling any warnings for API deprecated in newer versions. One has to actively overwrite that to see warnings again (like e..g done for KF modules gloibally in https://phabricator.kde.org/source/extra-cmake-modules/browse/master/kde-modules/KDEFrameworkCompilerSettings.cmake$68
  
    	add_definitions(
    	    -DQT_DEPRECATED_WARNINGS_SINCE=0x060000
    	    -DKF_DEPRECATED_WARNINGS_SINCE=0x060000
    	)
  
  So the idea here is to allow to disable warnings for API deprecations one does not want to care about (yet). So unwanted noise should be design not be a reason here to delay adding the compiler warning macro and the compiler visibility wrapper. Note: Qt is lacking a bit here and there, some deprecations are not properly tagged to support that. KF instead shines there :)
  
  For being silent about the warnings while still doing patches all yourself: while of course it is nice/recommended to help all KDE projects to adapt to some new API by the persons who introduced it, it also is good to get some real world feedback by having people with other mindsets who try to make use of the new API, and who thus might discover issues with the new API or its documentation. And some people are just fine to help out for their own projects to jump to latest best API as well, so they would be happy to learn about as early as possible by having the compiler points things out.
  
  See e.g. how KRun is deprecated currently. Are people upset about the approach? I do not think so. Because they see David going around and helping with the ports. And they see how the new async API is better.
  
  So, no harm here in having the compiler from day one inform interested developers about the deprecation. IMHO, but also covered by what is done elsewhere :) Actually, it is part of the design with the control about compiler warnings by version.

REPOSITORY
  R280 Prison

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

To: vkrause, svuorela
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200514/049262ac/attachment.htm>