How can I access the background color from the application stylesheet in my custom widget?
-
In my custom widget, which derives from
QPushButton
I'm trying to reimplementpaintEvent
. The one thing I can't figure out, is how to get the desired background color to use when painting.The application has a global stylesheet, which a lot of detailed color settings for checked and unchecked (flat) buttons. I want to reuse these same settings, and since my class derives from
QPushButton
, the stylesheets should apply to my class as well.I was expecting that
this->palette().base()
would return the correct color, switching between the 'checked' and 'unchecked' color when checking and unchecking my button. However, it doesn't. The same result forthis->palette().window()
. The palette doesn't seem to update when changing the 'checked' value.Where can I get the color I should use according to the stylesheets? Or what do I need to do to ensure changing the 'checked' value triggers an update in the palette?
-
Hi
Have you tried via a QStyle (in paint event)
QStyleOption opt;
opt.init(this);
opt.palette.base() -
@mrjj Thanx for the idea - didn't do the job though.
I already tried heroically to attach a debugger and try to see where Qt itself gets the color when I don't overwrite the function. I didn't find it, but maybe I should try again and try harder......
-
@Jakob
Damn , I had hoped.
Since u inhertied from QPushButton, i wonder if it has to be
http://doc.qt.io/qt-5.5/qstyleoptionbutton.html
But guess it dont matter as palette seems to be in base class.
Sorry, out of ideas. I want to know too .) -
Hi,
The style used to paint widget is a private QStyle derived class and AFAIK, you can't extract the background information from it.
As a workaround you could use custom properties for your button and modify them in the style sheet.
Hope it helps
-
One possible way would be to parse the style sheet itself and get the data you want from it in order to do the painting.
AFAIK, Qt style sheets are currently not supported for custom QStyle subclasses so that's also a no-go
-
As QWidgets are said to be "done" it should be safe to include private headers, right?
-
Done doesn't mean there's no work on them at all ;)
Even so, the QStyleSheetStyle class doesn't export the information needed
-
@SGaist I noticed that if I ask the current style of my button, I actually get an instance of exactly that
QStyleSheetStyle
class. I then hoped that maybe I could simply do:auto st = style(); st->polish(this);
This seems to be what the Qt-code itself also does, except:
- the color is still not updated
- this seems to introduce an (infinite) loop in
paintEvent
somehow (maybe something to do with theseRECURSION_GUARD
macro calls??)
-
IIRC polish will trigger a paint event and there you have your loop.
What do you need to paint on your push button ?
-
Something along the lines of http://ctrlv.in/701304. Doing the painting was quite easy - however, we have an elaborate set of colours defined for buttons, with specialisations for
:flat
buttons, in:checked
and:!checked
state, and also for the:hover
state, and for each of the combinations.In the documentation of
QPalette
it states:
'If you create a new widget we strongly recommend that you use the colors in the palette rather than hard-coding specific colours'But apparently all bets are off once stylesheets come into play.
-
@SGaist No, not at all. We're not reusing any of the system styling anywhere. The application has its complete own styling defined in the stylesheet. By now the stylesheet is appr. 500 lines.
In a way I'm trying to achieve the opposite. Through the stylesheet we're overwriting all the default styling. Because stylesheets are supposed to be 'cascading' over predefined styles, my expectations was also that the
QPalette
instance would always be updated whenever the state of the button asks for it. So the first line in the example you linked, is actually precisely what I was trying to do, expecting to get the currently relevant color. -
@SGaist Btw, the documentation of
QPalette
seems even 'more confusing' now that I have seen some of the internals by some debugging efforts while looking for some 'loopholes'.It seems that even the internal Qt-code can never rely on the correctness of the
QPalette
instance once thepaintEvent()
method is entered. If I follow things correctly, it seems also internal code explicitly always calls some special 'update' function in order to update the internalQPalette
instance. This is for me the exact opposite of what I would expect based on theQPalette
documentation, which to me suggests that the palette is continuously being updated before entering thepaintEvent()
function.Have I encountered some kind of (extensive) bug in the code, in the documentation? Or maybe I'm completely misunderstanding something?
-
@mrjj @SGaist As it turns out, not only colors are not updated in the palette, also any margins set through the stylesheet, are not updated in the widget's
contentsRect
, what I would actually expect.This thread has been around for some while now without a satisfying answer, so I'll post some bugs I guess, and consider this thread as 'closed' by those bug reports.
-
Please share any bug report you are opening so that other may find them more easily.