why override paint just to drawPrimitive(PE_Widget)?

[nroberts]

Why would someone override paintEvent to just do this:

QStyleOption opt;
    opt.init(this);
    QPainter p(this);
    style()->drawPrimitive(QStyle::PE_Widget, &opt, &p, this);

QStyleOption opt;
    opt.init(this);
    QPainter p(this);
    style()->drawPrimitive(QStyle::PE_Widget, &opt, &p, this);

To copy to clipboard, switch view to plain text mode 

[SixDegrees]

Because paintEvent gets called whenever painting - or re-painting - is required. Stick an output statement in paintEvent and start dragging windows partially offscreen, obscuring them with other windows, hiding and showing them and other activities; watch your console fill up with output.

[nroberts]

Because paintEvent gets called whenever painting - or re-painting - is required. Stick an output statement in paintEvent and start dragging windows partially offscreen, obscuring them with other windows, hiding and showing them and other activities; watch your console fill up with output.

Yes, I know all that. The question is, why would someone override the paintEvent inherited from QWidget just to tell the system to draw this widget. QWidget already has a paintEvent that I assume draws the widget and its children (seems to work fine), so why would it be necessary to write this override? In other words, what problem is this override written to solve?

---

Added after 19 minutes:

I stepped through both the OP method and simply calling QWidget:aintEvent(). Now I'm even more confused because neither one does anything. QWidget's paintEvent is an empty block and when you pass PE_Widget to drawPrimitive and the last parameter is directly derived from QWidget, all executable code is skipped.

[SixDegrees]

A QWidget object isn't visible; it has nothing to paint. Unlike the many widgets which derive from it.

[nroberts]

A QWidget object isn't visible; it has nothing to paint. Unlike the many widgets which derive from it.

I'm afraid I don't understand your point; could you please explain?

---

Added after 1 40 minutes:

Yes, I know all that. The question is, why would someone override the paintEvent inherited from QWidget just to tell the system to draw this widget. QWidget already has a paintEvent that I assume draws the widget and its children (seems to work fine), so why would it be necessary to write this override? In other words, what problem is this override written to solve?

---

Added after 19 minutes:

I stepped through both the OP method and simply calling QWidget:aintEvent(). Now I'm even more confused because neither one does anything. QWidget's paintEvent is an empty block and when you pass PE_Widget to drawPrimitive and the last parameter is directly derived from QWidget, all executable code is skipped.

I suppose it might help if I explain WHY I am so interested in this piece of apparently useless code that someone went out of their way to make.

The code in question is a part of a qt-solutions library. Perhaps I am mistaken in assuming that the authors of such libraries would have any special expertise in Qt (especially given that the library in question is so poorly made that I decided to make my own version of it), but I would hope that it's reasonable to assume there's at least a little peer review of such officially recognized extensions (they used to charge for them as I understand).

So what I'm trying to figure out is why someone that has intimate knowledge of Qt would do something like this. I'm trying to learn Qt specific methods from this library's source code and this particular piece is just throwing me off. Did they really just write a bunch of redundant code that does nothing for no reason, or was there something guiding their purpose? Legacy? Future?

[theprimat]

Hi,
we using the same code in our solution for correctly painting our own implementations of QWidgets if they have a stylesheet. If you do not the stylesheet commands are not applied in your own widgets. Really nasty!

primat

[wysota]

If you do not the stylesheet commands are not applied in your own widgets.

Same goes for any custom style. The fact that default styles draw empty widgets as 'nothing' doesn't mean custom styles (like stylesheets) have to follow that pattern as well.