How can I access the background color from the application stylesheet in my custom widget?

[mrjj]

@SGaist
Ok. a bit surprising . :)

[A Former User]

As QWidgets are said to be "done" it should be safe to include private headers, right?

[SGaist]

Done doesn't mean there's no work on them at all ;)

Even so, the QStyleSheetStyle class doesn't export the information needed

[Jakob]

@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 these RECURSION_GUARD macro calls??)

[SGaist]

IIRC polish will trigger a paint event and there you have your loop.

What do you need to paint on your push button ?

[Jakob]

@SGaist

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]

Are you using something like described in this post ?

[Jakob]

@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.

[Jakob]

@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 the paintEvent() 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 internal QPalette instance. This is for me the exact opposite of what I would expect based on the QPalette documentation, which to me suggests that the palette is continuously being updated before entering the paintEvent() function.

Have I encountered some kind of (extensive) bug in the code, in the documentation? Or maybe I'm completely misunderstanding something?

[Jakob]

@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.

[SGaist]

Please share any bug report you are opening so that other may find them more easily.