On Sunday December 13 2015 17:14:17 Thomas Lübking wrote: > I object the overhead concern. The global solution is easily applied by the > style (the icon isn't loaded from disk or rendered until you/the style > requires a pixmap from painting - until then there's just a string that hints > which icon to use)
Maybe, but the style will have to query the hint every time, whereas querying the style before (not) adding the icon is an overhead that happens only when a button is created. Whether that's a measurable overhead is another thing, of course. > > So this is as well orthogonal to the general Pushbutton > icon/ShowIconsOnPushButtons question (but simply a bug that needs to be fixed) Not exactly orthogonal according how I understand the definition of that term. You claimed that ShowIconsOnPushButtons is supposed to apply to all buttons (and that's the interpretation I'd prefer). In that case, it should override Qt's SH_DialogButtonBox_ButtonsHaveIcons when that variable is true. Otherwise you end up in a situation where a style can override ShowIconsOnPushButtons (which is the "interface" users have to toggle icons in buttons). Actually, I think a KDE style can query KDE's own ShowIconsOnPushButtons, and skip drawing icons an all buttons when that setting is off. That's the idea behind the setting, after all -- and given how the setting is exposed (in systemsettings), that is definitely the interpretation users will give it. > It might seem reasonable to query the parent widget of the button in KGuiItem > to catch a variety of occasions at once (though this doesn't guarantee > anything, parent and style would have to be tracked to make this "perfect" or > QPushButton would check its parent widget on painting and conditionally omit > the icon when it's a buttonbox and the style doesn't want icons there) I don't follow this. If respecting the hint (or hints) via KGuiItem is reasonable, let's begin by drawing up a list of all situations where a KGuiItem should NOT omit the icon despite either of the related hints being false. I continue to think that there is nothing inherently wrong with KDE giving a broader application to a Qt parameter for KDE purposes, as long as it's documented somewhere. You'll also have to consider the fact (IMHO) that every now and then someone will create something that is essentially a QDialogButtonBox but that doesn't use that class. Sure, just blindly applying the rules you can reject any bug reports about how those buttons fail to respect user choice in the matter as "works as intended/expected". And that's where ShowIconsOnPushButtons comes in again... In short, is there any reason why KDE would use the SH_DialogButtonBox_ButtonsHaveIcons hint, if that hint reflects ShowIconsOnButtons? R. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
