Op 7-6-2012 8:45, Till Oliver Knoll schreef:
Am 06.06.2012 um 13:20 schrieb André Somersan...@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é
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
