0

I want to enable my own widget class for stylesheets, whereat I am not talking about setStyleSheet(qss), but selectors in a qss stylesheet. It is understood that I have to replace the "::" with "--" in namespaces.

Here ( Qt Stylesheet for custom widget ) I have found a similar question, but it is > 4 years old. Based on the answer I have some detailed questions:

a) Is the published approach with an overridden paintEvent still valid (Qt5.6/5.7), from https://stackoverflow.com/a/8817908/356726

void CustomWidget::paintEvent(QPaintEvent *)
 {
     QStyleOption opt;
     opt.init(this);
     QPainter p(this);
     style()->drawPrimitive(QStyle::PE_Widget, &opt, &p, this);
 }

b) In the same thread ( https://stackoverflow.com/a/22094319/356726 ) it is said, I do not need to override paintEvent. Ok, leads me to: b1) is it harmful to override paintEvent anyway, even with QFrame? b2) What is with other base classes, e.g. QTableView? What makes QFrame having this particular role?

c) has anybody found an official Qt documentation on that topic. Nice code in a, but where does it come from? (here) Honestly I do not understand what it does.

-- Edit --

Daniel has pointed out the source of that magical paintEvent snippet here (QWidget paragraph). Interesting that the same ("supports only ..") is said for QDialog, which could mean I have to use the snippet there as well. I fail to understand why they do not add that snippet to the paintEvent of QWidgetas per default.

Community
  • 1
  • 1
Horst Walter
  • 13,663
  • 32
  • 126
  • 228
  • 1
    a) http://doc.qt.io/qt-5/stylesheet-reference.html : "Supports only the background, background-clip and background-origin properties. If you subclass from QWidget, you need to provide a paintEvent for your custom QWidget as below:" i think it is still valid in Qt5.6/5.7 – Daniel Jun 22 '16 at 07:20
  • Thanks, you have found the original source of that very code snippet. Updated above. – Horst Walter Jun 22 '16 at 08:31

1 Answers1

3

Is the published approach with an overridden paintEvent still valid (Qt5.6/5.7)

  • Yes

In the same thread ( https://stackoverflow.com/a/22094319/356726 ) it is said, I do not need to override paintEvent. Ok, leads me to: b1) is it harmful to override paintEvent anyway, even with QFrame? b2) What is with other base classes, e.g. QTableView? What makes QFrame having this particular role?

  • If you subclass QFrame, it provides its own paint event. QFrame is not a special case, it applies to all widgets. The default QWidget::paintEvent does nothing. It's empty. That is why you have to override it and provide your own painting to enable stylesheets when subclassing QWidget. It is not harmful to override QFrame's paint event, but you will lose the default behavior unless you call the QFrames implementation.

Has anybody found an official Qt documentation on that topic. Nice code in a, but where does it come from?

  • Here are the official docs. If you scroll down a little it states: QWidget Supports only the background, background-clip and background-origin properties. If you subclass from QWidget, you need to provide a paintEvent for your custom QWidget as below:

-

void CustomWidget::paintEvent(QPaintEvent *)    
{
    QStyleOption opt;
    opt.init(this);
    QPainter p(this);
    style()->drawPrimitive(QStyle::PE_Widget, &opt, &p, this);
}
Community
  • 1
  • 1
thuga
  • 12,601
  • 42
  • 52