[Interest] Changing QSpinEdit color

[André Somers]

Op 7-6-2012 8:45, Till Oliver Knoll schreef:
> Am 06.06.2012 um 13:20 schrieb André Somers<andre at familiesomers.nl>:
>
>> ... setPalette cannot be relied on, and is thus effectively useless. Pitty is: style sheet support is incomplete (no API for custom widgets), so in some cases (mainly if you use your own widgets), you're basically screwed. You cannot rely on the palette to work properly, but you cannot use style sheets either.
> What exactly do you mean by "own widgets"? "Custom widgets" as in "You are responsible for painting everything yourself"? So why would one ignore the palette colours - in her own drawing code, that is - when there was a need for that in the first place? Or did you mean "3rd party custom widgets"?
Both, actually. *I* would not ignore them. The issue is, that if you use 
any of the QStyle API to do the actual rendering (you do want your 
widget to blend in with the platform, don't you?), there is no telling 
if those colors will be used or not. One place where you might run into 
this, for instance, is if you do something as simple as implementing 
your own delegate. And, as you say:
> Anyway, I agree that it is a mess having to deal with two different APIs to reliably set the background colour of some line edit widget (style sheet), which at the same time should have the same background colour as some other custom widget (setPalette()), for instance.
If I style my entire application using a style sheet (mind you: usually 
*one* style sheet, set at the highest possible level), then it is very 
annoying if I have to style my *own* widget low-level using a 
setPallette call on the actual widget.
> I wasn't aware that the "style sheet API" wasn't available to custom painting code. I guess one could always provide a custom setStyleSheet method, try to parse (a subset of) the CSS yourself and then merge the result with the (subset) CSS result from the parent widget.
The issue with CSS is, is that this cascading thing makes this hard. 
There is no way to get the "(subset) CSS result from the parent widget". 
If only there were!
> However IIRC widgets "where it is reasonable to set the background colour" - QLineEdit where you want to indicate that some input is missing or wrong, for instance - work cross-platform with setPalette.
Can you guarantee that that will work in all (reasonable) styles? Where 
is it documented what widgets do obey the palette, and what widgets 
don't? For what roles? Will it still work in Windows 8, or in the next 
OSX? And isn't a spinbox just as reasonable as a line edit?
> But more often than never people want to also set the colour of some push button or tab switching "button". At least on a Mac that is absolutely wacko to do so: people go absolutely banana if they don't see their blue bubbly buttons or most recently their "dull gray with decent lighter gray tab highlighting" tab buttons! Didn't you know? Colours have basically become outlawed (icons in Finder, anyone?) in the "greatest OS X we've ever had" - yikes! ;)
>
> Bottom line: if the native painting code doesn't respect your setPalette calls, then there might be a good reason ;)
>
I am very much aware of that, and personally I am not a great fan of 
non-native GUI's. But in terms of API, you have to agree that it is a 
bit of a mess that there is no one API that you can rely on for this 
purpose?

Of course, this lack is going to be solved in the Future (TM) by 
introducing the One API To Rule Them All: Quick (Components) ;-)

André