kossebau added a comment.
In D23927#537585 <https://phabricator.kde.org/D23927#537585>, @vkrause wrote: > Moving even more towards a QIcon rather than a QPixmap API is a good thing for sure, I agree on that. I don't think going back is justified here though, especially since the QIcon-based API improves high DPI scalability support. If it's decided to revert this nevertheless, please note that this has a ripple effect on the frameworks already depending on this. The commit & its message claims to "Improve naming of KTitleWidget icon methods", which it does not. It is now actually resulting in wrong expectations. Using a QIcon as pixmap provider engine surely makes sense. That is why the old API had those overloads. But the method does not set an icon, it sets the pixmap by immediately having the QIcon generating the pixmap and then discarding the QIcon object. Which means, if the title widget gets scaled e..g by setting another level, the API user had no gain by passing a QIcon object. Please add a respective disclaimer to the API documentation for now, as the current documentation is misleading, as I can tell you by experience :) REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D23927 To: vkrause, dfaure Cc: kossebau, dhaumann, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
