pub struct Style<'a> { /* private fields */ }Expand description
Notice these docs are heavy WIP and not very relevent yet
Qt contains a set of QStyle subclasses that emulate the styles of the different platforms supported by Qt (QWindowsStyle, QMacStyle etc.). By default, these styles are built into the Qt GUI module. Styles can also be made available as plugins.
Qt’s built-in widgets use QStyle to perform nearly all of their drawing, ensuring that they look exactly like the equivalent native widgets. The diagram below shows a QComboBox in nine different styles.
Topics:
Setting a Style
The style of the entire application can be set using the
QApplication::setStyle() function. It can also be specified by the
user of the application, using the -style command-line option:
If no style is specified, Qt will choose the most appropriate style for the user’s platform or desktop environment.
A style can also be set on an individual widget using the QWidget::setStyle() function.
Developing Style-Aware Custom Widgets
If you are developing custom widgets and want them to look good on all platforms, you can use QStyle functions to perform parts of the widget drawing, such as drawItemText(), drawItemPixmap(), drawPrimitive(), drawControl(), and drawComplexControl().
Most QStyle draw functions take four arguments:
- an enum value specifying which graphical element to draw
- a QStyleOption specifying how and where to render that element
- a QPainter that should be used to draw the element
- a QWidget on which the drawing is performed (optional)
For example, if you want to draw a focus rectangle on your widget, you can write:
QStyle gets all the information it needs to render the graphical element from QStyleOption. The widget is passed as the last argument in case the style needs it to perform special effects (such as animated default buttons on MacOS ), but it isn’t mandatory. In fact, you can use QStyle to draw on any paint device, not just widgets, by setting the QPainter properly.
QStyleOption has various subclasses for the various types of graphical elements that can be drawn. For example, PE_FrameFocusRect expects a QStyleOptionFocusRect argument.
To ensure that drawing operations are as fast as possible, QStyleOption and its subclasses have public data members. See the QStyleOption class documentation for details on how to use it.
For convenience, Qt provides the QStylePainter class, which combines a QStyle, a QPainter, and a QWidget. This makes it possible to write
…
instead of
…
Creating a Custom Style
You can create a custom look and feel for your application by creating a custom style. There are two approaches to creating a custom style. In the static approach, you either choose an existing QStyle class, subclass it, and reimplement virtual functions to provide the custom behavior, or you create an entire QStyle class from scratch. In the dynamic approach, you modify the behavior of your system style at runtime. The static approach is described below. The dynamic approach is described in QProxyStyle.
The first step in the static approach is to pick one of the styles provided by Qt from which you will build your custom style. Your choice of QStyle class will depend on which style resembles your desired style the most. The most general class that you can use as a base is QCommonStyle (not QStyle). This is because Qt requires its styles to be QCommonStyle s.
Depending on which parts of the base style you want to change, you must reimplement the functions that are used to draw those parts of the interface. To illustrate this, we will modify the look of the spin box arrows drawn by QWindowsStyle. The arrows are primitive elements that are drawn by the drawPrimitive() function, so we need to reimplement that function. We need the following class declaration:
To draw its up and down arrows, QSpinBox uses the PE_IndicatorSpinUp and PE_IndicatorSpinDown primitive elements. Here’s how to reimplement the drawPrimitive() function to draw them differently:
Notice that we don’t use the widget argument, except to pass it
on to the QWindowStyle::drawPrimitive() function. As mentioned
earlier, the information about what is to be drawn and how it
should be drawn is specified by a QStyleOption object, so there is
no need to ask the widget.
If you need to use the widget argument to obtain additional
information, be careful to ensure that it isn’t 0 and that it is
of the correct type before using it. For example:
…
When implementing a custom style, you cannot assume that the widget is a QSpinBox just because the enum value is called PE_IndicatorSpinUp or PE_IndicatorSpinDown.
The documentation for the Styles example covers this topic in more detail.
Warning: Qt style sheets are currently not supported for custom QStyle subclasses. We plan to address this in some future release.
Using a Custom Style
There are several ways of using a custom style in a Qt application. The simplest way is to pass the custom style to the QApplication::setStyle() static function before creating the QApplication object:
You can call QApplication::setStyle() at any time, but by calling
it before the constructor, you ensure that the user’s preference,
set using the -style command-line option, is respected.
You may want to make your custom style available for use in other applications, which may not be yours and hence not available for you to recompile. The Qt Plugin system makes it possible to create styles as plugins. Styles created as plugins are loaded as shared objects at runtime by Qt itself. Please refer to the Qt Plugin
documentation for more information on how to go about creating a style plugin.
Compile your plugin and put it into Qt’s plugins/styles
directory. We now have a pluggable style that Qt can load
automatically. To use your new style with existing applications,
simply start the application with the following argument:
The application will use the look and feel from the custom style you implemented.
Right-to-Left Desktops
Languages written from right to left (such as Arabic and Hebrew) usually also mirror the whole layout of widgets, and require the light to come from the screen’s top-right corner instead of top-left.
If you create a custom style, you should take special care when
drawing asymmetric elements to make sure that they also look
correct in a mirrored layout. An easy way to test your styles is
to run applications with the -reverse command-line option or
to call QApplication::setLayoutDirection() in your main()
function.
Here are some things to keep in mind when making a style work well in a right-to-left environment:
- subControlRect() and subElementRect() return rectangles in screen coordinates
- QStyleOption::direction indicates in which direction the item should be drawn in
- If a style is not right-to-left aware it will display items as if it were left-to-right
- visualRect(), visualPos(), and visualAlignment() are helpful functions that will translate from logical to screen representations.
- alignedRect() will return a logical rect aligned for the current direction
Styles in Item Views
The painting of items in views is performed by a delegate. Qt’s default delegate, QStyledItemDelegate, is also used for calculating bounding rectangles of items, and their sub-elements for the various kind of item data roles
QStyledItemDelegate supports. See the QStyledItemDelegate class description to find out which datatypes and roles are supported. You can read more about item data roles in Model/View Programming
When QStyledItemDelegate paints its items, it draws CE_ItemViewItem, and calculates their size with CT_ItemViewItem. Note also that it uses SE_ItemViewItemText to set the size of editors. When implementing a style to customize drawing of item views, you need to check the implementation of QCommonStyle (and any other subclasses from which your style inherits). This way, you find out which and how other style elements are painted, and you can then reimplement the painting of elements that should be drawn differently.
We include a small example where we customize the drawing of item backgrounds.
The primitive element PE_PanelItemViewItem is responsible for painting the background of items, and is called from QCommonStyle ’s implementation of CE_ItemViewItem.
To add support for drawing of new datatypes and item data roles, it is necessary to create a custom delegate. But if you only need to support the datatypes implemented by the default delegate, a custom style does not need an accompanying delegate. The QStyledItemDelegate class description gives more information on custom delegates.
The drawing of item view headers is also done by the style, giving control over size of header items and row and column sizes.
See also: [StyleOption]
[StylePainter]
{Styles Example}
{Styles and Style Aware Widgets}
[StyledItemDelegate]
{Styling}
Licence
The documentation is an adoption of the original Qt Documentation and provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation.
Implementations
sourceimpl<'a> Style<'a>
impl<'a> Style<'a>
sourcepub fn polish<W: WidgetTrait<'a>>(&self, widget: &W) -> &Self
pub fn polish<W: WidgetTrait<'a>>(&self, widget: &W) -> &Self
Initializes the appearance of the given widget.
This function is called for every widget at some point after it has been fully created but just before it is shown for the very first time.
Note that the default implementation does nothing. Reasonable actions in this function might be to call the QWidget::setBackgroundMode() function for the widget. Do not use the function to set, for example, the geometry. Reimplementing this function provides a back-door through which the appearance of a widget can be changed, but with Qt’s style engine it is rarely necessary to implement this function; reimplement drawItemPixmap(), drawItemText(), drawPrimitive(), etc. instead.
The QWidget::inherits() function may provide enough information to allow class-specific customizations. But because new QStyle subclasses are expected to work reasonably with all current and future widgets, limited use of hard-coded customization is recommended.
See also: [unpolish()]
Overloads Late initialization of the given application object.
Overloads Changes the palette according to style specific requirements for color palettes (if any).
See also: Palette
[Application::set_palette]
sourcepub fn unpolish<W: WidgetTrait<'a>>(&self, widget: &W) -> &Self
pub fn unpolish<W: WidgetTrait<'a>>(&self, widget: &W) -> &Self
Uninitialize the given widget ’s appearance.
This function is the counterpart to polish(). It is called for every polished widget whenever the style is dynamically changed; the former style has to unpolish its settings before the new style can polish them again.
Note that unpolish() will only be called if the widget is destroyed. This can cause problems in some cases, e.g, if you remove a widget from the UI, cache it, and then reinsert it after the style has changed; some of Qt’s classes cache their widgets.
See also: [polish()]
Overloads Uninitialize the given application.
sourcepub fn polish_2<A: ApplicationTrait<'a>>(&self, application: &A) -> &Self
pub fn polish_2<A: ApplicationTrait<'a>>(&self, application: &A) -> &Self
Initializes the appearance of the given widget.
This function is called for every widget at some point after it has been fully created but just before it is shown for the very first time.
Note that the default implementation does nothing. Reasonable actions in this function might be to call the QWidget::setBackgroundMode() function for the widget. Do not use the function to set, for example, the geometry. Reimplementing this function provides a back-door through which the appearance of a widget can be changed, but with Qt’s style engine it is rarely necessary to implement this function; reimplement drawItemPixmap(), drawItemText(), drawPrimitive(), etc. instead.
The QWidget::inherits() function may provide enough information to allow class-specific customizations. But because new QStyle subclasses are expected to work reasonably with all current and future widgets, limited use of hard-coded customization is recommended.
See also: [unpolish()]
Overloads Late initialization of the given application object.
Overloads Changes the palette according to style specific requirements for color palettes (if any).
See also: Palette
[Application::set_palette]
sourcepub fn unpolish_2<A: ApplicationTrait<'a>>(&self, application: &A) -> &Self
pub fn unpolish_2<A: ApplicationTrait<'a>>(&self, application: &A) -> &Self
Uninitialize the given widget ’s appearance.
This function is the counterpart to polish(). It is called for every polished widget whenever the style is dynamically changed; the former style has to unpolish its settings before the new style can polish them again.
Note that unpolish() will only be called if the widget is destroyed. This can cause problems in some cases, e.g, if you remove a widget from the UI, cache it, and then reinsert it after the style has changed; some of Qt’s classes cache their widgets.
See also: [polish()]
Overloads Uninitialize the given application.
sourcepub fn polish_3<P: PaletteTrait<'a>>(&self, palette: &P) -> &Self
pub fn polish_3<P: PaletteTrait<'a>>(&self, palette: &P) -> &Self
Initializes the appearance of the given widget.
This function is called for every widget at some point after it has been fully created but just before it is shown for the very first time.
Note that the default implementation does nothing. Reasonable actions in this function might be to call the QWidget::setBackgroundMode() function for the widget. Do not use the function to set, for example, the geometry. Reimplementing this function provides a back-door through which the appearance of a widget can be changed, but with Qt’s style engine it is rarely necessary to implement this function; reimplement drawItemPixmap(), drawItemText(), drawPrimitive(), etc. instead.
The QWidget::inherits() function may provide enough information to allow class-specific customizations. But because new QStyle subclasses are expected to work reasonably with all current and future widgets, limited use of hard-coded customization is recommended.
See also: [unpolish()]
Overloads Late initialization of the given application object.
Overloads Changes the palette according to style specific requirements for color palettes (if any).
See also: Palette
[Application::set_palette]
sourcepub fn item_pixmap_rect<P: PixmapTrait<'a>, R: RectTrait<'a>>(
&self,
r: &R,
flags: i32,
pixmap: &P
) -> Rect<'_>
pub fn item_pixmap_rect<P: PixmapTrait<'a>, R: RectTrait<'a>>(
&self,
r: &R,
flags: i32,
pixmap: &P
) -> Rect<'_>
Returns the area within the given rectangle in which to draw the provided text according to the specified font metrics and alignment. The enabled parameter indicates whether or not the associated item is enabled.
If the given rectangle is larger than the area needed to render the text, the rectangle that is returned will be offset within rectangle according to the specified alignment. For example, if alignment is Qt::AlignCenter, the returned rectangle will be centered within rectangle. If the given rectangle is smaller than the area needed, the returned rectangle will be the smallest rectangle large enough to render the text.
See also: [t::alignment()]
Returns the area within the given rectangle in which to draw the specified pixmap according to the defined alignment.
sourcepub fn draw_item_text<P: PainterTrait<'a>, Q: PaletteTrait<'a>, R: RectTrait<'a>>(
&self,
painter: &P,
rect: &R,
flags: i32,
pal: &Q,
enabled: bool,
text: &str,
text_role: ColorRole
) -> &Self
pub fn draw_item_text<P: PainterTrait<'a>, Q: PaletteTrait<'a>, R: RectTrait<'a>>(
&self,
painter: &P,
rect: &R,
flags: i32,
pal: &Q,
enabled: bool,
text: &str,
text_role: ColorRole
) -> &Self
Draws the given text in the specified rectangle using the provided painter and palette.
The text is drawn using the painter’s pen, and aligned and wrapped according to the specified alignment. If an explicit textRole is specified, the text is drawn using the palette’s color for the given role. The enabled parameter indicates whether or not the item is enabled; when reimplementing this function, the enabled parameter should influence how the item is drawn.
See also: [t::alignment()]
[draw_item_pixmap()]
sourcepub fn draw_item_pixmap<P: PainterTrait<'a>, Q: PixmapTrait<'a>, R: RectTrait<'a>>(
&self,
painter: &P,
rect: &R,
alignment: i32,
pixmap: &Q
) -> &Self
pub fn draw_item_pixmap<P: PainterTrait<'a>, Q: PixmapTrait<'a>, R: RectTrait<'a>>(
&self,
painter: &P,
rect: &R,
alignment: i32,
pixmap: &Q
) -> &Self
const QPixmap &pixmap) const
Draws the given pixmap in the specified rectangle, according to the specified alignment, using the provided painter.
See also: [draw_item_text()]
sourcepub fn standard_palette(&self) -> Palette<'_>
pub fn standard_palette(&self) -> Palette<'_>
Returns the style’s standard palette.
Note that on systems that support system colors, the style’s standard palette is not used. In particular, the Windows Vista and Mac styles do not use the standard palette, but make use of native theme engines. With these styles, you should not set the palette with QApplication::setPalette().
See also: [Application::set_palette]
sourcepub fn proxy(&self) -> Option<Style<'_>>
pub fn proxy(&self) -> Option<Style<'_>>
Draws the given primitive element with the provided painter using the style options specified by option.
The widget argument is optional and may contain a widget that may aid in drawing the primitive element.
The table below is listing the primitive elements and their associated style option subclasses. The style options contain all the parameters required to draw the elements, including QStyleOption::state which holds the style flags that are used when drawing. The table also describes which flags that are set when casting the given option to the appropriate subclass.
Note that if a primitive element is not listed here, it is because it uses a plain QStyleOption object.
-
Primitive Element
-
QStyleOption Subclass
-
Style Flag
-
Remark
-
Whether the focus is is at the border or inside the widget.
-
{1,2} PE_IndicatorCheckBox
-
{1,2} QStyleOptionButton
-
Indicates a “tri-state” checkbox.
-
Indicates the indicator is checked.
-
Indicates that a radio button is selected.
-
Indicates a “tri-state” controller.
-
Indicates the controller is enabled.
-
{1,4} PE_IndicatorBranch
-
{1,4} QStyleOption
-
Indicates that the control for expanding the tree to show child items, should be drawn.
-
Indicates that a horizontal branch (to show a child item), should be drawn.
-
Indicates that the tree branch is expanded.
-
Indicates that a vertical line (to show a sibling item), should be drawn.
-
Indicates that the arrow should be drawn up; otherwise it should be down.
-
PE_FrameGroupBox, PE_Frame, PE_FrameLineEdit, PE_FrameMenu, PE_FrameDockWidget, PE_FrameWindow
-
Indicates that the Frame should be sunken.
-
Indicates that the window handle is horizontal instead of vertical.
-
PE_IndicatorSpinPlus, PE_IndicatorSpinMinus, PE_IndicatorSpinUp, PE_IndicatorSpinDown,
-
Indicates that the button is pressed.
-
{1,5} PE_PanelButtonCommand
-
{1,5} QStyleOptionButton
-
Set if the button is enabled.
-
Set if the button has input focus.
-
Set if the button is not down, not on and not flat.
-
Set if the button is a toggle button and is toggled on.
-
Set if the button is down (i.e., the mouse button or the space bar is pressed on the button).
See also: [draw_complex_control()]
[draw_control()]
Returns the sub-area for the given element as described in the provided style option. The returned rectangle is defined in screen coordinates.
The widget argument is optional and can be used to aid determining the area. The QStyleOption object can be cast to the appropriate type using the qstyleoption_cast() function. See the table below for the appropriate option casts:
-
Sub Element
-
QStyleOption Subclass
Returns the size of the element described by the specified option and type, based on the provided contentsSize.
The option argument is a pointer to a QStyleOption or one of its subclasses. The option can be cast to the appropriate type using the qstyleoption_cast() function. The widget is an optional argument and can contain extra information used for calculating the size.
See the table below for the appropriate option casts:
-
Contents Type
-
QStyleOption Subclass
See also: ContentsType
[StyleOption]
Returns an integer representing the specified style hint for the given widget described by the provided style option.
returnData is used when the querying widget needs more detailed data than the integer that styleHint() returns. See the QStyleHintReturn class description for details.
Returns a pixmap for the given standardPixmap.
A standard pixmap is a pixmap that can follow some existing GUI style or guideline. The option argument can be used to pass extra information required when defining the appropriate pixmap. The widget argument is optional and can also be used to aid the determination of the pixmap.
Developers calling standardPixmap() should instead call standardIcon() Developers who re-implemented standardPixmap() should instead re-implement standardIcon().
See also: [standard_icon()]
const QWidget *widget = 0) const = 0;
Returns an icon for the given standardIcon.
The standardIcon is a standard pixmap which can follow some existing GUI style or guideline. The option argument can be used to pass extra information required when defining the appropriate icon. The widget argument is optional and can also be used to aid the determination of the icon.
const QPixmap &pixmap, const QStyleOption *option) const
Returns a copy of the given pixmap, styled to conform to the specified iconMode and taking into account the palette specified by option.
The option parameter can pass extra information, but it must contain a palette.
Note that not all pixmaps will conform, in which case the returned pixmap is a plain copy.
See also: Icon
Returns the given logicalRectangle converted to screen coordinates based on the specified direction. The boundingRectangle is used when performing the translation.
This function is provided to support right-to-left desktops, and is typically used in implementations of the subControlRect() function.
See also: Widget::layout_direction()
Returns the given logicalPosition converted to screen coordinates based on the specified direction. The boundingRectangle is used when performing the translation.
See also: Widget::layout_direction()
Converts the given logicalValue to a pixel position. The min parameter maps to 0, max maps to span and other values are distributed evenly in-between.
This function can handle the entire integer range without overflow, providing that span is less than 4096.
By default, this function assumes that the maximum value is on the right for horizontal items and on the bottom for vertical items. Set the upsideDown parameter to true to reverse this behavior.
See also: [slider_value_from_position()]
Converts the given pixel position to a logical value. 0 maps to the min parameter, span maps to max and other values are distributed evenly in-between.
This function can handle the entire integer range without overflow.
By default, this function assumes that the maximum value is on the right for horizontal items and on the bottom for vertical items. Set the upsideDown parameter to true to reverse this behavior.
See also: [slider_position_from_value()]
Transforms an alignment of Qt::AlignLeft or Qt::AlignRight without Qt::AlignAbsolute into Qt::AlignLeft or Qt::AlignRight with Qt::AlignAbsolute according to the layout direction. The other alignment flags are left untouched.
If no horizontal alignment was specified, the function returns the default alignment for the given layout direction.
QWidget::layoutDirection
Returns a new rectangle of the specified size that is aligned to the given rectangle according to the specified alignment and direction.
QSizePolicy::ControlType control2, Qt::Orientation orientation, const QStyleOption *option = 0, const QWidget *widget = 0) const
Returns the spacing that should be used between control1 and control2 in a layout. orientation specifies whether the controls are laid out side by side or stacked vertically. The option parameter can be used to pass extra information about the parent widget. The widget parameter is optional and can also be used if option is 0.
This function is called by the layout system. It is used only if PM_LayoutHorizontalSpacing or PM_LayoutVerticalSpacing returns a negative value.
See also: [combined_layout_spacing()]
Returns the spacing that should be used between controls1 and controls2 in a layout. orientation specifies whether the controls are laid out side by side or stacked vertically. The option parameter can be used to pass extra information about the parent widget. The widget parameter is optional and can also be used if option is 0.
controls1 and controls2 are OR-combination of zero or more control types
This function is called by the layout system. It is used only if PM_LayoutHorizontalSpacing or PM_LayoutVerticalSpacing returns a negative value.
See also: [layout_spacing()]
This function returns the current proxy for this style. By default most styles will return themselves. However when a proxy style is in use, it will allow the style to call back into its proxy.