| ApplicationWindow.qml |
|
1289 |
- |
| BusyIndicator.qml |
|
2707 |
- |
| Button.qml |
|
2214 |
- |
| CheckBox.qml |
|
3551 |
- |
| CheckDelegate.qml |
|
3637 |
- |
| CMakeLists.txt |
|
3991 |
- |
| ComboBox.qml |
|
5441 |
- |
| DelayButton.qml |
|
2453 |
- |
| Dial.qml |
|
2321 |
- |
| Dialog.qml |
|
2409 |
- |
| DialogButtonBox.qml |
|
1928 |
- |
| doc |
|
|
- |
| Drawer.qml |
|
1919 |
- |
| Frame.qml |
|
1434 |
- |
| GroupBox.qml |
|
2504 |
- |
| HorizontalHeaderView.qml |
|
894 |
- |
| HorizontalHeaderViewDelegate.qml |
|
5317 |
- |
| impl |
|
|
- |
| ItemDelegate.qml |
|
2291 |
- |
| Label.qml |
|
1158 |
- |
| Menu.qml |
|
1883 |
- |
| MenuBar.qml |
|
1767 |
- |
| MenuBarItem.qml |
|
2289 |
- |
| MenuItem.qml |
|
4760 |
- |
| MenuSeparator.qml |
|
1607 |
- |
| Page.qml |
|
1693 |
- |
| PageIndicator.qml |
|
2606 |
- |
| Pane.qml |
|
1433 |
- |
| Popup.qml |
|
1675 |
- |
| ProgressBar.qml |
|
5104 |
- |
| qqstylekit.cpp |
!
\qmltype StyleKit
\inqmlmodule Qt.labs.StyleKit
\brief A singleton for setting and accessing the current style.
\c StyleKit is a singleton for setting the application \l Style.
\snippet PlainStyleMain.qml 1
It also provides properties for global StyleKit configuration and debugging.
\labs
\sa Style, StyleVariation
|
5651 |
- |
| qqstylekit_p.h |
|
2134 |
- |
| qqstylekitanimation.cpp |
!
\qmltype StyleAnimation
\inqmlmodule Qt.labs.StyleKit
\inherits ParallelAnimation
\brief A convenience type for animating style properties.
StyleAnimation is an \l [QtQuick]{Animation} that animates style properties
when a control changes \l {ControlStateStyle}{state}. For example, setting
\l animateBackgroundColors to \c true will animate all color properties of
the \l {ControlStyle::}{background}, such as \l {DelegateStyle::color}{background.color},
\l {BorderStyle::color}{background.border.color}, \l {ImageStyle::color}{background.image.color},
and \l {ShadowStyle::color}{background.shadow.color}. It is used inside a
\l {ControlStyle::}{transition}:
\snippet StyleAnimationSnippets.qml transition
StyleAnimation is just a convenience \l [QtQuick]{Animation} that handles listing the
affected style properties automatically. The snippet above could also be written as:
\snippet StyleAnimationSnippets.qml custom transition
A StyleAnimation can also be used together with other animations:
\snippet StyleAnimationSnippets.qml mixed transition
\labs
\sa {ControlStyleProperties::transition}{ControlStyle.transition}, ControlStyle
|
8156 |
- |
| qqstylekitcontrol.cpp |
!
\qmltype ControlStyle
\inqmlmodule Qt.labs.StyleKit
\inherits ControlStateStyle
\brief Defines the style for a control in the \c normal state.
A ControlStyle describes how a \l Control should be styled. Its API
largely mirrors that of a Qt Quick Control: it provides grouped
properties for delegates such as
\l {ControlStateStyle::background}{background},
\l {ControlStateStyle::indicator}{indicator},
\l {ControlStateStyle::handle}{handle}, and
\l {ControlStateStyle::text}{text}, along with layout
properties such as
\l {ControlStateStyle::padding}{padding} and
\l {ControlStateStyle::spacing}{spacing}.
If you are familiar with the API of a \l Control in Qt Quick Controls,
you should find the ControlStyle API easy to follow.
ControlStyle inherits \l ControlStateStyle because it represents the
\e normal state: properties set directly on a ControlStyle describe
how the control looks when no other state is active. State-specific
overrides are set through nested states, such as \l {ControlStateStyle::}{hovered}
\l {ControlStateStyle::}{pressed}, and \l {ControlStateStyle::}{checked}.
\l {StylableControls}{Each stylable control} in a \l Style, \l Theme, or \l StyleVariation is a ControlStyle.
For example, in the snippet below, \l {StylableControls::}{control},
\l {StylableControls::}{button} and \l {StylableControls::}{radioButton}
are all ControlStyles:
\snippet ControlStyleSnippets.qml ControlStyle
\sa {StylableControls}{All stylable controls}, Style, Theme,
StyleVariation, ControlStateStyle, DelegateStyle
|
5642 |
- |
| qqstylekitcontrol_p.h |
|
1624 |
- |
| qqstylekitcontrolproperties.cpp |
!
\qmltype ControlStyleProperties
\inqmlmodule Qt.labs.StyleKit
\brief Defines the stylable properties for a control.
ControlStyleProperties defines the stylable properties for a
control: the visual building blocks \l background, \l indicator, \l handle,
and \l text, as well as layout properties like \l padding, \l spacing,
and \l transition.
The style properties are accessed through inherited types such as
\l ControlStyle and \l StyleReader.
\labs
\sa ControlStyle, StyleReader, ControlStateStyle, DelegateStyle
|
78987 |
- |
| qqstylekitcontrolproperties_p.h |
Only QQStyleKitControlProperties (as opposed to the nested delegates) have properties
with an ID at the bottom of the available space. The exception is the global flag, which
inherits the groupSpace from the control. |
25654 |
- |
| qqstylekitcontrols.cpp |
!
\qmltype StylableControls
\inqmlmodule Qt.labs.StyleKit
\brief Abstract base type containing the control types that can be styled.
StylableControls is an abstract base type. It contains a \l ControlStyle for
each control type that can be styled by a \l Style, \l Theme, or \l StyleVariation.
The control types form a hierarchy where properties set on a base type
propagate down to the more specific ones. For example, assigning a radius
of four to \c abstractButton.background.radius will cause all button
types, such as \l button, \l checkBox, and \l radioButton, to get a radius
of four.
The snippets on this page illustrate a few of the key properties that can be
used to style each control type, but they are by no means exhaustive. Many other properties
are available, as documented in the \l ControlStyle and \l DelegateStyle documentation.
In practice, some of them can also be omitted because the
\l {Style::fallbackStyle}{fallback style} already supplies sensible defaults.
This means that if you simply remove a property from one of the snippets, it
might not actually affect its appearance, since it will just be read from the
fallback style instead.
\sa {StyleKit Property Resolution}
\labs
|
27443 |
- |
| qqstylekitcontrols_p.h |
|
11361 |
- |
| qqstylekitcontrolstate.cpp |
!
\qmltype ControlStateStyle
\inqmlmodule Qt.labs.StyleKit
\inherits ControlStyleProperties
\brief Describes the style of a control in a given state.
ControlStateStyle describes the style of a control in a particular state.
A \l ControlStyle inherits ControlStateStyle, since it represents the
\e normal state — properties set directly on a \l ControlStyle describe
how the control looks when no other state is active. State-specific
overrides are then set through nested states such as \l pressed,
\l hovered, and \l checked.
Nested states are not mutually exclusive. Multiple states can be active at
the same time — for example, a button can be both hovered and
pressed simultaneously. When several states are active, all matching
state overrides are applied. If the same property is set in multiple
active states, conflicts are resolved using the following priority
order: \l pressed, \l hovered, \l highlighted, \l focused,
\l checked, \l vertical. So for example \c {pressed.background.color}
wins over \c {checked.background.color} if the control is both
\l pressed and \l checked.
The \l disabled state is an exception: a disabled control cannot
be interacted with, so the \l pressed, \l hovered, \l highlighted,
and \l focused states will not apply. However, \l disabled can
still be combined with states like \l checked and \l vertical.
The more deeply nested a state is, the more qualified it is.
For example, \c {hovered.pressed.background.color} takes precedence over
\c {hovered.background.color} when both \l hovered and \l pressed are
active. The nesting order does not matter:
\c {hovered.pressed} and \c {pressed.hovered} are equivalent.
However, if both forms are used at the same time, which one wins is
undefined.
Deeper nesting of states can also be used to resolve conflicts. If the same property
is set in both \l hovered and \l checked, the priority order means
the \l hovered value wins. If you would rather have the checked value win, or
use an altogether different value in that situation, you can override
the property in \c {hovered.checked}, which then takes precedence over both.
The following snippet shows how to style a button differently
depending on its state:
\snippet ControlStateStyle_states.qml States
\labs
\sa ControlStyle, DelegateStyle, {StyleKit Property Resolution},
{Reference Fallback Style}
|
7016 |
- |
| qqstylekitcontrolstate_p.h |
|
2415 |
- |
| qqstylekitcustomcontrol.cpp |
!
\qmltype CustomControl
\inqmlmodule Qt.labs.StyleKit
\inherits ControlStyle
\brief Defines styling for a custom (non-built-in) control.
CustomControl allows you to define and style controls that are not part of
\l {Qt Quick Controls}. This is convenient if you have additional controls
or components that should be styled according to the active \l Style and \l Theme.
Like the built-in control types (such as
\l {StylableControls::}{abstractButton},
\l {StylableControls::}{pane}, and
\l {StylableControls::}{slider}), CustomControl inherits
\l ControlStyle. Unlike built-in types, which are implicitly connected to
their control type, a CustomControl requires \l controlType to be set
explicitly. Apart from that, they work exactly the same way.
A \l Style or \l Theme can define as many custom controls as needed, and a
CustomControl in a Theme can have the same \l controlType as one in the \l Style.
That is no different from, for example, a \l {StylableControls::}{slider}
being styled by both the \l Style and the \l Theme. The fallback logic is the same.
Any style properties not set on a CustomControl fall back to those set
on a \l {StylableControls::}{control}.
The following snippet shows how to define styling for a custom control:
\snippet CustomControlSnippets.qml custom control style
And the following snippet shows an example on how to implement a custom
control that uses it:
\snippet CustomControlSnippets.qml custom control
\labs
\sa StyleReader, ControlStyle, Style, StylableControls::getControlStyle()
|
2773 |
- |
| qqstylekitcustomcontrol_p.h |
|
1119 |
- |
| qqstylekitcustomtheme.cpp |
!
\qmltype CustomTheme
\inqmlmodule Qt.labs.StyleKit
\brief Defines a named custom theme.
CustomTheme lets you add additional themes beyond
\l {Style::light}{light} and \l {Style::dark}{dark}.
While the light and dark themes are applied \l {Style::themeName}{automatically} based on the
operating system's color scheme, a CustomTheme must be activated
explicitly by the application. Apart from this difference, all themes work the same way.
You can define any number of custom themes inside a \l Style.
\snippet CustomThemeSnippets.qml custom themes
To activate a CustomTheme, set \l Style::themeName to its name
from the application:
\snippet CustomThemeSnippets.qml change theme
You can also set a CustomTheme as the default theme at start-up:
\snippet CustomThemeSnippets.qml custom theme at start-up
The custom themes defined in a Style can be queried at runtime
from \l {Style::customThemeNames} or \l {Style::availableThemeNames}.
\labs
\sa Theme, Style::themeName, Style::customThemeNames
|
2334 |
- |
| qqstylekitcustomtheme_p.h |
|
1279 |
- |
| qqstylekitdebug.cpp |
!
\qmltype StyleKitDebug
\inqmlmodule Qt.labs.StyleKit
\brief Traces how style properties are resolved for a control.
StyleKitDebug is a diagnostic in-app tool that logs style property reads to the
debug output. It is useful for understanding why a control ends up with a
particular appearance, especially in complex styles that involve multiple
\l {Theme}{themes} or \l {StyleVariation}{style variations}.
It is accessed through \l {StyleKit.debug}.
\note This tool is experimental. Enabling it will severely degrade performance and should only
be used for debugging. The output format may change in future versions.
To start tracing, assign the control you want to introspect to the \l control property:
\snippet StyleKitDebug.qml trace
Each resolved property is printed as a single line showing where the value
came from and what it resolved to:
\code
[read] StyleReader[Hovered].button.background.color -> Style.Theme(Dark).button[Hovered] = #add8e6
\endcode
The \c StyleReader in the output refers to the \l StyleReader that the \l Button
uses internally to read its style property values.
Tracing the property reads of a StyleReader can produce a large amount of output. Use \l filter to
limit the output to properties of interest.
\labs
\sa StyleKit::debug, {StyleKit Property Resolution}
|
13379 |
- |
| qqstylekitdebug_p.h |
|
2771 |
- |
| qqstylekitdelegate.cpp |
!
\qmltype StyledItem
\inqmlmodule Qt.labs.StyleKit
\inherits Item
\brief Renders a DelegateStyle.
StyledItem renders a \l DelegateStyle. It reads properties such as
\l {DelegateStyle::color}{color},
\l {DelegateStyle::border}{border},
\l {DelegateStyle::gradient}{gradient}, and
\l {DelegateStyle::image}{image}, and creates the corresponding
visual elements internally.
If the \l {DelegateStyle::delegate}{delegate} set on a DelegateStyle
is \c null (the default), StyledItem will automatically be used for rendering.
A custom \l {DelegateStyle::delegate}{delegate} can be set to
any Item. But combined with a StyledItem, you can retain
the default rendering while adding overlay, underlay, or shader effects.
The following snippet shows how to draw an extra Item on top of the
default delegate:
\snippet StyledItemOverlay.qml overlay
\labs
For more examples of overlays, underlays and shader effects, see the
\l{StyleKit Quick Controls Example}.
\sa DelegateStyle, {DelegateStyle::delegate}{delegate}, {DelegateStyle::data}{data}
|
11535 |
- |
| qqstylekitdelegate_p.h |
|
1533 |
- |
| qqstylekitfont.cpp |
|
2839 |
- |
| qqstylekitfont_p.h |
|
4190 |
- |
| qqstylekitglobal.cpp |
|
254 |
- |
| qqstylekitglobal_p.h |
Sub types, like states, are a part of a propertys storage ID, not its Path ID.
They appear in the group path, but are handled differently. |
4582 |
- |
| qqstylekitpalette.cpp |
|
2470 |
- |
| qqstylekitpalette_p.h |
The following properties are lazy-created, since it's unlikely that a style
sets them all. And since a QQuickPalette is not a QObject, we use std::unique_ptr
for memory management. Since each palette is logically independent of this class,
we make them mutable so that the getter functions can be const.
|
4546 |
- |
| qqstylekitpropertypath.cpp |
|
3697 |
- |
| qqstylekitpropertypath_p.h |
Each style property in StyleKit needs a unique PropertyStorageId that can be used as
a key in the map that stores its value. To compute such an ID, we must consider the
property's full nested path, since properties like 'background.color' and
'background.border.color' refer to different values.
Because a property may have multiple values depending on the control's state and
subtype, we distinguish between a property's path ID and its storage ID. The path
ID represents the portion of the property path that does not vary during lookups.
For example, in the full path:
"button.pressed.indicator.up.background.color"
the portion that is invariant is:
"indicator.background.color"
The other parts of the path—such as the control type ('button'), the state ('pressed'),
and the subtype ('up')—are resolved dynamically by the propagation engine. During lookup,
the engine substitutes these components in decreasing order of specificity. For instance:
- If the property is not found on 'button', it falls back to 'abstractButton'.
- If it is not found in the 'pressed' state, it falls back to 'normal'.
- If it is not found in the 'up' subtype, it falls back to 'indicator'.
These varying components are prepended in sequence by the propagation engine to form
the final PropertyStorageId, which uniquely identifies the stored value in the map.
Note that a property path may also include groups known as Options. These are not part
of the Path ID or the Storage ID; they are simply flags used by QQStyleKitPropertyResolver
to control how a property should be read.
In general, the structure of a property path is:
control.options.states.subtype.nested_group_path.property
However, for API convenience, subtypes are written inside the delegate they belong to.
For example, although the storage path is "spinBox.up.indicator.background.color", the
style syntax is "spinBox.indicator.up.background.color". |
7819 |
- |
| qqstylekitpropertyresolver.cpp |
By default, the base types should mirror the class hierarchy in Qt Quick Controls.
However, to make it possible to style a base type without having to "undo" it again
in a sub type, we choose to diverge in som cases:
ItemDelegate — Normally used as a menu item in a ComboBox or as an item in a ListView.
Although it behaves similarly to a button, it is typically styled very differently
(e.g., without borders, drop shadows, gradients, etc.). For that reason, it falls
back to Control rather than AbstractButton.
MenuBarItem — Although it is technically a button, it is typically styled very differently
from other buttons (e.g., without borders, drop shadows, gradients, etc.). For that
reason, it falls back to Control rather than AbstractButton.
MenuItem — In Qt Quick Controls, MenuItem inherits from AbstractButton. Although it
behaves similarly to a button, it is typically styled very differently
(e.g., without borders, drop shadows, gradients, etc.). For that reason, it falls
back to Control rather than AbstractButton.
TabBar — In Qt Quick Controls, ToolBar inherits Pane, while TabBar inherits Container.
Since it is desirable for a TabBar to share styling characteristics (such as
background color) with ToolBar and Pane, we let it fall back to Pane instead of
Control.
|
35815 |
- |
| qqstylekitpropertyresolver_p.h |
|
4413 |
- |
| qqstylekitreader.cpp |
!
\qmltype StyleReader
\inqmlmodule Qt.labs.StyleKit
\inherits ControlStyleProperties
\brief Reads properties from the active Style for a specific control.
StyleReader is the bridge between a control in \l {Qt Quick Controls}
and the \l {StyleKit::style}{active style}. It exposes all the style
properties — \l {ControlStyleProperties::background}{backgrounds},
\l {ControlStyleProperties::indicator}{indicators},
\l {ControlStyleProperties::handle}{handles},
\l {ControlStyleProperties::text}{text},
\l {ControlStyleProperties::padding}{padding},
and more — that a control, and its delegates, should bind to.
All built-in \c StyleKit controls use a StyleReader
internally for this purpose.
The state properties — \l hovered, \l pressed, \l focused, \l checked,
\l highlighted, etc. — tell StyleReader which state the control is in.
It uses these to resolve and read the correct property values from
the \l Style, taking \l {Theme}{Themes}, \l {StyleVariation}{StyleVariations},
\l {StylableControls}{fallback types}, and property propagation
into account.
When implementing a \l CustomControl, you can follow the same approach as
the built-in controls:
\snippet StyleReaderSnippets.qml custom control
\note The style properties inherited from \l ControlStyleProperties do not map
directly to the \l Style. Instead, they reflect a cache of potentially interpolated
values during an active \l {ControlStyle::}{transition}. Writing to them will \e not
update the corresponding properties in the \l Style and may interfere with ongoing
transitions. Write directly to the \l Style when you need to change a style property.
\labs
\sa CustomControl, Style, {StyleVariation::controlType}{StyleVariation.controlType},
{StyleKit Property Resolution}
|
34753 |
- |
| qqstylekitreader_p.h |
|
7749 |
- |
| qqstylekitstyle.cpp |
!
\qmltype Style
\inqmlmodule Qt.labs.StyleKit
\inherits AbstractStyle
\brief The root type for a style definition.
\l Style is the root type in StyleKit for defining a complete visual style for
\l [QtQuickControls] {Qt Quick Controls}. A style lets you customize
the appearance of \l {StylableControls}{every control type}
— \l {ControlStateStyle::background}{backgrounds}, \l {ControlStateStyle::indicator}{indicators},
\l {ControlStateStyle::handle}{handles}, \l {ControlStateStyle::}{text},
\l {ControlStateStyle::}{padding}, and more
— as well as how controls respond to states
such as \l {ControlStyle::}{hovered},
\l {ControlStyle::}{pressed}, and
\l {ControlStyle::}{disabled}, including animated
\l {ControlStyle::transition}{transitions} between them.
Styles support \l light and \l dark color schemes through \l {Theme}
{themes}, and you can add any number of \l {CustomTheme}{custom themes}
as well. \l {StyleVariation}{Style variations} allow you to define
alternative styling that can be applied to specific control instances
or entire control types. You can also define \l {CustomControl}
{custom controls} to extend the style beyond the built-in control set.
The following example shows a minimal style that defines some structural
properties shared by all themes, with separate light and dark themes for colors:
\snippet PlainStyle.qml 1
For a more complete example, see the \l{StyleKit Quick Controls Example}.
\labs
\sa Theme, CustomTheme, StyleVariation, ControlStyle, DelegateStyle,
CustomControl, {StyleKit Property Resolution}
|
15848 |
- |
| qqstylekitstyle_p.h |
|
4106 |
- |
| qqstylekitstyleandthemebase.cpp |
!
\qmltype AbstractStyle
\inqmlmodule Qt.labs.StyleKit
\inherits StylableControls
\brief Abstract base type with properties common to both \l Style and \l Theme.
AbstractStyle contains properties, such and fonts and palettes, that are
common to both a \l Style and a \l Theme.
\labs
|
1770 |
- |
| qqstylekitstyleandthemebase_p.h |
|
1576 |
- |
| qqstylekittheme.cpp |
!
\qmltype Theme
\inqmlmodule Qt.labs.StyleKit
\inherits AbstractStyle
\brief Defines color and style overrides for a color scheme.
A Theme overrides properties defined in a \l Style to provide a
distinct visual appearance for a particular color scheme. A style
typically configures structural properties such as implicit size,
padding, and radii, while a theme specifies colors, shadows, and
other visual attributes. However, this is not a restriction — a
theme can override any property that a style can set.
A style can provide a \l {Style::light}{light} and a
\l {Style::dark}{dark} theme. When \l {Style::themeName}{themeName}
is set to \c "System" (the default), the active theme follows the
\l {QStyleHints::colorScheme}{operating system's color scheme}.
You can also create additional themes using \l CustomTheme and
\l {Style::themeName}{switch between them} at runtime.
Properties that are not set in the theme fall back to those defined
in the \l Style.
The following example defines light, dark, and high-contrast
themes, each providing different colors for the controls:
\snippet ThemeSnippets.qml themes
For a complete example showing themes in action, see the
\l {StyleKit Quick Controls Example}.
\labs
\sa Style, CustomTheme, {StyleKit Property Resolution}
|
9171 |
- |
| qqstylekittheme_p.h |
|
1486 |
- |
| qqstylekitvariation.cpp |
!
\qmltype StyleVariation
\inqmlmodule Qt.labs.StyleKit
\inherits StylableControls
\brief Defines alternative styling for specific controls.
A StyleVariation lets you define alternative styling that can be applied
to specific controls in the application (\e{instance variations}),
or to all descendants of a particular parent control type
(\e{type variations}). For example, you can give controls in a sidebar a
compact appearance, or make buttons inside all \l {ToolBar}{toolbars} look
different from buttons elsewhere.
\section2 Instance Variations
Instance variations are activated by setting the \l {StyleVariation::}{variations}
attached property on any item in the application — all StyleKit controls that are
children or descendants of that item will receive the alternative styling. Variations
can also be set at multiple levels of the hierarchy simultaneously; when they conflict,
the variation closest to the control takes precedence.
Instance variations are defined in the \l Style or \l Theme that they affect:
\snippet InstanceVariationSnippets.qml instance variations in style
And they are applied from the application using the
\l {StyleVariation::}{variations} attached property:
\snippet InstanceVariationSnippets.qml apply instance variation
Variation names referred to from the application that are not defined in the active
style (or theme) are silently ignored — they act as hints that the style author can
choose to implement or leave unhandled.
\section2 Type Variations
Type variations are assigned to the \l {ControlStyle::}{variations} property of a
specific \l ControlStyle, without requiring a \l name. Unlike instance variations —
which require the application to explicitly opt in — type variations are applied
automatically to all controls of a given type whenever they are descendants of the
specified parent control type.
The following snippet shows how to make all \l {Button}{Buttons} inside a \l Frame look
distinct from buttons elsewhere:
\snippet TypeVariationSnippets.qml frame with variation
Because \l {StylableControls::}{groupBox} falls back to
\l {StylableControls::}{frame} in the style hierarchy, type variations
set on \c frame are automatically inherited by \c groupBox as well. To opt out,
reset the variations for the subtype.
\section2 Propagation order
A StyleVariation is local to the \l Style or \l Theme where it is defined. A Theme
cannot shadow an entire StyleVariation defined in the Style — only individual
properties within it can be overridden, just like any other style property.
For example, if both the \l Style and the active \l Theme define \c {frame.variations},
both type variation arrays take effect for a \l Frame. The resolution order for
individual properties is: the Theme's variation properties take precedence over the
Theme's direct properties, which take precedence over the Style's variation properties,
which take precedence over the Style's direct properties.
The same applies to instance variations. A StyleVariation defined in a \l Theme takes
precedence over the Theme's direct properties. If a StyleVariation with the same
\l name is also defined in the \l Style, both take effect, following the same
resolution order as described above.
In the following snippet, a button with \c {StyleVariation.variations: ["alert"]}
will be red in the light theme and cyan in the dark theme, with a 4-pixel border in
both. Because the dark theme overrides \c {button.background.radius} to be \c 6,
that property takes precedence over the \c {background.radius} set in the Style's
variation. As a result, the button's radius ends up being \c 6 in the dark theme, but \c 0
in the light theme:
\snippet VariationPropagation.qml propagation
\labs
\sa Style, Theme, {ControlStyle::variations}{ControlStyle.variations},
{StyleVariation::variations}{StyleVariation.variations, {StyleKit Property Resolution}}
|
9760 |
- |
| qqstylekitvariation_p.h |
|
2397 |
- |
| RadioButton.qml |
|
3572 |
- |
| RadioDelegate.qml |
|
3677 |
- |
| RangeSlider.qml |
|
5933 |
- |
| RoundButton.qml |
|
2225 |
- |
| ScrollBar.qml |
|
1789 |
- |
| ScrollIndicator.qml |
|
2450 |
- |
| ScrollView.qml |
|
2297 |
- |
| SearchField.qml |
|
7950 |
- |
| Slider.qml |
|
3612 |
- |
| SpinBox.qml |
|
5528 |
- |
| Style.qml |
|
908 |
- |
| StyleAnimation.qml |
|
5539 |
- |
| SwipeDelegate.qml |
|
2440 |
- |
| Switch.qml |
|
4062 |
- |
| SwitchDelegate.qml |
|
4203 |
- |
| TabBar.qml |
|
1994 |
- |
| TabButton.qml |
|
2181 |
- |
| TableViewDelegate.qml |
|
3319 |
- |
| TextArea.qml |
|
2591 |
- |
| TextField.qml |
|
2548 |
- |
| ToolBar.qml |
|
1604 |
- |
| ToolButton.qml |
|
1979 |
- |
| ToolSeparator.qml |
|
1642 |
- |
| ToolTip.qml |
|
2178 |
- |
| TreeViewDelegate.qml |
|
7148 |
- |
| Tumbler.qml |
|
2419 |
- |
| VerticalHeaderView.qml |
|
505 |
- |
| VerticalHeaderViewDelegate.qml |
|
2257 |
- |
| widgets |
|
|
- |