How to subclass QStyleOptionButton?
-
I am working on implementing a custom control derived from
QPushButton. There are some options that can not be configured using the defaultQStyleOptionButton, so I am looking to subclassQStyleOptionButton. Please let me know if you are aware of any docs that explain how to do this. I found a document about creating custom styles but it doesn't cover this aspect. -
@Axel-Spoerl The goal is to have a button widget (derived from QPushButton) that supports multiple variants (6), fill colors (3) that are not otherwise available with Qt's default button and style options. I can achieve this without subclassing QStyleOption/QStyleOptionButton by querying the widget directly inside my style class but was curious if I can use style option to pass the required info.
@schrute: Style options are used for data exchange between widgets and styles. The widget populates it with data that each style may interpret differently when doing its drawing work. So in the case at hand, a custom style is supposed to react specifically to a custom widget. It’s a question of style (haha) whether to query the widget directly or derive from QStyleOption. Deriving from QStyleOption has the advantage that information can be detached at a specific state without being modified when the widget’s state transitions in the meanwhile. For instance if it should be drawn differently while being hovered, the widget may no longer know at the point of direct query, that it once was under the mouse cursor. That’s where I’d draw the line: If conserving fluctuating states is crucial, derive from QStyleOption. If that’s not the case, call the widget directly.
-
Since it's a c++ class you can derive from it like for any other class.
But it won't help you since QPushButton instantiates a QStyleOptionButton internally, not your class.
I also don't see why deriving from QStyleOptionButton should be needed. -
If the goal is to style a
QPushButtondifferntly or in a more complex manner than native Qt styles do, you might want to look into this. It demonstrates how to implement a custom style, offering a variety of options how to specifically style a widget. -
Since it's a c++ class you can derive from it like for any other class.
But it won't help you since QPushButton instantiates a QStyleOptionButton internally, not your class.
I also don't see why deriving from QStyleOptionButton should be needed.@Christian-Ehrlicher I was planning to use the derived style option in my derived QPushButton's paintEvent.
-
If the goal is to style a
QPushButtondifferntly or in a more complex manner than native Qt styles do, you might want to look into this. It demonstrates how to implement a custom style, offering a variety of options how to specifically style a widget.@Axel-Spoerl The goal is to have a button widget (derived from QPushButton) that supports multiple variants (6), fill colors (3) that are not otherwise available with Qt's default button and style options. I can achieve this without subclassing QStyleOption/QStyleOptionButton by querying the widget directly inside my style class but was curious if I can use style option to pass the required info.
-
@Axel-Spoerl The goal is to have a button widget (derived from QPushButton) that supports multiple variants (6), fill colors (3) that are not otherwise available with Qt's default button and style options. I can achieve this without subclassing QStyleOption/QStyleOptionButton by querying the widget directly inside my style class but was curious if I can use style option to pass the required info.
@schrute: Style options are used for data exchange between widgets and styles. The widget populates it with data that each style may interpret differently when doing its drawing work. So in the case at hand, a custom style is supposed to react specifically to a custom widget. It’s a question of style (haha) whether to query the widget directly or derive from QStyleOption. Deriving from QStyleOption has the advantage that information can be detached at a specific state without being modified when the widget’s state transitions in the meanwhile. For instance if it should be drawn differently while being hovered, the widget may no longer know at the point of direct query, that it once was under the mouse cursor. That’s where I’d draw the line: If conserving fluctuating states is crucial, derive from QStyleOption. If that’s not the case, call the widget directly.
-
S schrute has marked this topic as solved on
-
I ian28 referenced this topic on
