aacid added a comment.
In D16137#341984 <https://phabricator.kde.org/D16137#341984>, @kadabash wrote: > I have to admit, I don't know how to implement a version with flags correctly. Look at kcmodule.h for example you'll see some flags defined there, then there's a setButtons function, this would be the same but to the addPage function > Did I understand you correctly in that an overload with signature > > addPage(QWidget *page, const QString &itemName, const QString &pixmapName = QString(), const QString &header = QString(), bool manage = true, bool fitContentHorizontally = false) > > would be ok as well? This would then be called by the overload without the last option (i.e. the `addPage` that existed before this diff). I'm not really the kconfigwidgets maintainer so i can't say if that would be acceptable API wise, but it would be ok binary compatibility wise, yes. It would though not compile because would mean you have two functions addPage(QWidget *page, const QString &itemName, const QString &pixmapName = QString(), const QString &header = QString(), bool manage = true) addPage(QWidget *page, const QString &itemName, const QString &pixmapName = QString(), const QString &header = QString(), bool manage = true, bool fitContentHorizontally = false) which one would be called when i call addPage(someWidget, "myItemName") the first or the second? To solve that you need to make your new function not have default values, but as said i'm not sure if that's ok API wise, personally i think using flags is nicer REPOSITORY R265 KConfigWidgets REVISION DETAIL https://phabricator.kde.org/D16137 To: kadabash Cc: aacid, kde-frameworks-devel, michaelh, ngraham, bruns
