Created attachment 70215 [details] A misbehaving widget The down/up arrow should be gray when the value is equal to the minimum/maximum and black otherwise.
I have the complete opposite behaviour. The arrow are always black, even when the value is at the end of the slider.
This must be a bug in the theme, not in krita. It differs depending on which theme you use. It's, funnily enough not a Qt 4.8 bug... Our code does the right thing: //Disable non-logical buttons if (d->value == d->minimum) { opts.stepEnabled = QAbstractSpinBox::StepUpEnabled; } else if (d->value == d->maximum) { opts.stepEnabled = QAbstractSpinBox::StepDownEnabled; } else { opts.stepEnabled = QAbstractSpinBox::StepUpEnabled | QAbstractSpinBox::StepDownEnabled; } And it doesn't matter whether we always enable or disable them -- oxygen in this version of KDE always shows the top one enabled, the bottom one disabled.
So ... the problem is, as far as I know, that Qt doesn't do the indicated behavior by itself (disable while at minimum), for spinboxes. (you can check with any app, such as "oxygen-demo -style plastique". So oxygen adds "manually" this behavior for generic spinboxes, and well, possibly this does not work well with krita's custom widget (possibly because it doesn't look for the right value for the minimum. Will investigate. In any case I confirm its an oxygen "bug".
Git commit fc78347421b96ea8e524927dcf97b081713db92d by Hugo Pereira Da Costa. Committed on 11/04/2012 at 10:11. Pushed by hpereiradacosta into branch 'KDE/4.8'. use QStyleOptionSpinBox::stepEnabled flag to decide arrow color. M +8 -24 kstyles/oxygen/oxygenstyle.cpp http://commits.kde.org/kde-workspace/fc78347421b96ea8e524927dcf97b081713db92d
Git commit 9a33bca2c004b57f68a5afa05b587f57c4d0198d by Hugo Pereira Da Costa. Committed on 11/04/2012 at 10:11. Pushed by hpereiradacosta into branch 'master'. use QStyleOptionSpinBox::stepEnabled flag to decide arrow color. M +8 -24 kstyles/oxygen/oxygenstyle.cpp http://commits.kde.org/kde-workspace/9a33bca2c004b57f68a5afa05b587f57c4d0198d
Commit above should fix it. I was unaware of the ->stepEnabled flags passed to the option, and used the spinbox values/min/max directly. Usign the suggested flags instead should fix the issue above and I did not notice any regression for "normal" spinboxes. So closing. Thanks for posting the report !
Wonderful, thanks!