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

mrjj

Hi
Have you tried via a QStyle (in paint event)
QStyleOption opt;
opt.init(this);
opt.palette.base()

Jakob

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

mrjj

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

SGaist

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

mrjj

@SGaist
So you cannot make your own widget style aware?

SGaist

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

mrjj

@SGaist
Ok. a bit surprising . :)

? Offline

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.