<table><tr><td style="">kossebau added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D24965">View Revision</a></tr></table><br /><div><div><p>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.</p>

<p>While we want to tell the client side, stop using this and for that also allow them to disable it, the serving side still needs to access it to support the legacy system.</p>

<p>I had some ideas how to support this, though this would complicated all this fragile macro logic even more, so not sure this will work out.</p>

<p>The other option is to remove the diabling wrappers around the programIconName API, so one can still use KF_DISABLE_DEPRECATED_BEFORE_AND_AT for the rests of the API. Actually I had done that in the other places where I came across that category. I would be in favour to do the same for programIconName. What do you think?</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R265 KConfigWidgets</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D24965">https://phabricator.kde.org/D24965</a></div></div><br /><div><strong>To: </strong>dfaure, kossebau, elvisangelaccio, vkrause<br /><strong>Cc: </strong>kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns<br /></div>