[KDE/Mac] Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing
René J.V. Bertin
rjvbertin at gmail.com
Thu Dec 10 22:51:18 UTC 2015
> On Dec. 10, 2015, 11:11 p.m., Thomas Lübking wrote:
> > 1. What tells you that this is a dialog buttonbox pushbutton?
> > 2. What happens if the button has no text?
> >
> >
> > The bug is in QDialogButtonBox (or rather the K variant, QDialogButtonBoxPrivate::createButton() seems to incorporate the hint correctly)
> >
> >
> > [KDE] has "ShowIconsOnPushButtons=false" in kdeglobals which was interpreted by KPushButton _and_ kstyle for the hint, but the hint only covers Q'DialogButtonBox'es - there's simply no global rule for this like AA_DontShowIconsInMenus
> >
> > => KDialogButtonBox shall respect the hint for its buttons (there're two special creation routines).
> >
> > For the rest, the platform plugin ideally picks the kdeglobals setting and exports it to the application object (dyn property?) where the style can pick it and incorporate it into its calculations (ie. if no icons are wanted and there's text or arrow, omit the icon in size calculation and painting)
> >
> > "Fixing" that in deprecated KPushButton doesn't really fix anything. We'll face the mix we had, just that users of QPushButton were far less prone to pass them an icon in pre-KF5 times.
> >
> > Please also attach Hugo Pereira Da Costa.
1: why should one care? It is said nowhere that the setting defined as "show icons on buttons" in `systemsettings(5)` applies only to dialogs. Rather, the tooltip says "when this is enabled, KDE applications will show icons alongside [sic!] some important buttons".
In other words, when "this" is *not* enabled, there should be no icons, period.
I have found no sign in the code that the ShowIconsOnPushButtons hint is to be used only for dialogs; `SH_DialogButtonBox_ButtonsHaveIcons` indeed carries the suggestion in its name but I would not be surprised if Qt really thinks of it in a more general sense. Probably also because the notion of what a dialog is has become a lot vaguer.
And that also happens to be what Qt does; buttons show their icons on Linux (and other Unix variants?) but on OS X or MS Windows displaying of those icons is deactivated unless you use a style that enables it. In fact, the default setting for `SH_DialogButtonBox_ButtonsHaveIcons` is false except in the generic Unix theme (= it does work globally like `AA_DontShowIconsInMenus` everywhere else).
2: a user who indicates s/he doesn't want to see icons will get an empty button. That's also what can happen with QPushButton, and app developers have to take this into consideration. Cf. toolbars (and Qt's position on the use of "texted separators").
I don't think I've ever come across a standard button showing only an icon, except possibly the arrow button next to the progress indicators in KMail and KDevelop.
As to fixing it here: as it turns out, "here" is the main source for annoying icons rearing their silly heads on buttons on my screen ;) and it was also something of a challenge to understand why they kept appearing despite the fact that all code appeared to return the value of `ShowIconsOnPushButtons`. Deprecated or not, it doesn't look like all applications are going to stop using it anytime soon.
I looked into fixing the issue in KDialogButtonBox but saw that it does nothing to override the `ShowIconsOnPushButtons` setting. The only way to respect the setting through that class (or a modern equivalent) would be to set an empty icon if `ShowIconsOnPushButtons=false`. That introduces another regression: changes in this setting are supposed to be reflected by running applications without requiring a restart (or a recreation of dialogs). If it were just me I'd decree that buttons can have either text or an icon, but right now we have to make do with this mixed situation.
I don't mind making this an OS X (and MS Windows) specific modification, of course, but on those platforms
- René J.V.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126308/#review89321
-----------------------------------------------------------
On Dec. 10, 2015, 11:12 p.m., René J.V. Bertin wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126308/
> -----------------------------------------------------------
>
> (Updated Dec. 10, 2015, 11:12 p.m.)
>
>
> Review request for KDE Software on Mac OS X, KDE Frameworks, Qt KDE, and Hugo Pereira Da Costa.
>
>
> Repository: kdelibs4support
>
>
> Description
> -------
>
> KF5 applications have long had a habit of drawing icons on buttons even when this feature was turned off in the user's setting. This was mostly noticeable in applications built on kdelibs4support.
>
> It seems that the actual culprit is in Qt's QPushButton implementation (https://bugreports.qt.io/browse/QTBUG-49887), but it is possible to work around it in `KPushButton::paintEvent`, by removing the icon (forcing it to the null icon) in the option instance, before handing off control to the painter.
>
>
> Diffs
> -----
>
> src/kdeui/kpushbutton.cpp 98534fa
>
> Diff: https://git.reviewboard.kde.org/r/126308/diff/
>
>
> Testing
> -------
>
> On Kubuntu 14.04 and OS X 10.9.5 with Qt 5.5.1 and KF5 frameworks 5.16.0 .
>
> I have not yet verified if there are other classes where this modification would be relevant too.
>
>
> Thanks,
>
> René J.V. Bertin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20151210/c81d5a77/attachment-0001.html>
More information about the kde-mac
mailing list