"Buttons have icons", round N+1
Hi, There has been some discussion around one of my RRs concerning how to respect KDE's ShowIconsOnPushButtons and Qt's SH_DialogButtonBox_ButtonsHaveIcons style hint. The ultimate way would be in the style that does the actual drawing, but that is probably not the one with the smallest overhead. Until now this discussion focussed on kdelibs4support, but I just learned that e.g. KMessageBox can also show buttons that have icons despite ShowIconsOnPushButtons being false. This happens for instance in the dialog Kate puts up when asked to close a file with unsaved changes. The dialog in question is a KMessageBox with a few KStandardGuiItems. In a comparable situation, Qt's own code simply doesn't add the standard icons to the buttons being created, when SH_DialogButtonBox_ButtonsHaveIcons is false. KMessageBox isn't a QDialogButtonBox, but shouldn't it do the same? Would it be acceptable to remove the icon in the appropriate KStandardGuiItem methods, or even in KGuiItem, when SH_DialogButtonBox_ButtonsHaveIcons is false, or (rather) when ShowIconsOnPushButtons is false? Regards, René ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: "Buttons have icons", round N+1
On Sonntag, 13. Dezember 2015 16:20:19 CEST, René J.V. wrote: There has been some discussion around one of my RRs concerning how to respect KDE's ShowIconsOnPushButtons and Qt's SH_DialogButtonBox_ButtonsHaveIcons style hint. The ultimate way would be in the style that does the actual drawing, but that is probably not the one with the smallest overhead. 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) The dialog in question is a KMessageBox with a few KStandardGuiItems. In a comparable situation, Qt's own code simply doesn't add the standard icons to the buttons being created, when SH_DialogButtonBox_ButtonsHaveIcons is false. KMessageBox isn't a QDialogButtonBox No, but it uses one - the problem is the same as in the kdelibs4support code of KDialogButtonBox - the assignment of the KGuiItem which ignores SH_DialogButtonBox_ButtonsHaveIcons in all the *Internal functions of KMessageBox. Needs a similar fix (to respect the hint) So this is as well orthogonal to the general Pushbutton icon/ShowIconsOnPushButtons question (but simply a bug that needs to be fixed) 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) Cheers, Thomas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: "Buttons have icons", round N+1
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
