Lines Matching full:the
7 Styles are used to set the appearance of Widgets. Styles in LVGL are
8 heavily inspired by CSS. The concept in a nutshell is that a
13 assignment, the target part (pseudo-element_ in CSS) and target state
15 ``style_blue`` to the knob of a slider when it's in pressed state.
16 - The same style can be used by any number of Widgets.
20 style defines it or use a default value if it's not specified by any of the
23 overwrite the background color.
24 - The most recently added style has higher precedence. This means if a property
25 is specified in two styles the newest style in the Widget will be used.
30 - Transitions can be applied when the Widget changes state.
39 The Widgets can be in the combination of the following states:
56 pressed at the same time. This is represented as :cpp:expr:`LV_STATE_FOCUSED | LV_STATE_PRESSED`.
59 setting a different background color for the default and pressed states.
60 If a property is not defined in a state the best matching state's
61 property will be used. Typically this means the property with
62 :cpp:enumerator:`LV_STATE_DEFAULT` is used.˛ If the property is not set even for the
63 default state the default value will be used. (See later)
65 What does the "best matching state's property" mean?
67 States have a precedence which is shown by their value (see in the above list).
69 property to use let's take an example. Imagine the background color is
76 1. Initially the Widget is in the default state, so it's a simple case:
77 the property is perfectly defined in the Widget's current state as
79 2. When the Widget is pressed there are 2 related properties: default
81 The pressed state has 0x0020 precedence which is higher than the
83 3. When the Widget has focus the same thing happens as in pressed state
86 4. When the Widget has focus and pressed both gray and red would work,
87 but the pressed state has higher precedence than focused so gray
91 the pressed state's precedence so rose color would be used.
92 6. When the Widget is in the checked state there is no property to set
93 the background color for this state. So for lack of a better option,
94 the Widget remains white from the default state's property.
98 - The precedence (value) of states is quite intuitive, and it's something the
99 user would expect naturally. Example: if a Widget has focus the user will still
100 want to see if it's pressed, therefore the pressed state has a higher
101 precedence. If the focused state had a higher precedence it would overwrite
102 the pressed color.
104 just set it for the default state. If the Widget can't find a property
105 for its current state it will fall back to the default state's property.
106 - Use ORed states to describe the properties for complex cases (e.g.
112 Instead, for example, use the background color for pressed and checked
113 states and indicate the focused state with a different border color.
122 It's not required to set all the properties in one style. It's possible
123 to add more styles to a Widget and have the latter added style modify
125 and create a new one for red buttons where only the new background color
131 Styles added later have precedence over ones set earlier. So in the
132 gray/red button example above, the normal button style should be added
133 first and the red style second. However, the precedence of the states
134 are still taken into account. So let's examine the following case:
136 - the basic button style defines dark-gray color for the default state and
137 light-gray color for the pressed state
138 - the red button style defines the background color as red only in the default state
140 In this case, when the button is released (it's in default state) it
141 will be red because a perfect match is found in the most recently added
142 style (red). When the button is pressed the light-gray color is a better
143 match because it describes the current state perfectly, so the button
154 the parent Widget's styles. Inheritance is applied only if the given
155 property is not set in the Widget's styles (even in default state). In
156 this case, if the property is inheritable, the property's value will be
157 searched up the parent hierarchy until a Widget specifies a value for the
158 property. The parents will use their own state to determine the value.
159 So if a button is pressed, and the text color comes from a parent, the
171 The following predefined parts exist in LVGL:
174 - :cpp:enumerator:`LV_PART_SCROLLBAR`: The scrollbar(s)
175 …rator:`LV_PART_INDICATOR`: Indicator, e.g. for slider, bar, switch, or the tick box of the checkbox
177 - :cpp:enumerator:`LV_PART_SELECTED`: Indicate the currently selected option or section
178 - :cpp:enumerator:`LV_PART_ITEMS`: Used if the widget has multiple similar elements (e.g. table cel…
188 This means all three parts of the slider can have their own styles. See
200 be local variables in functions which are destroyed when the function
239 on the type of property it is applied to:
281 OR-ed value of parts and state to which the style should be added. Some
285 - :cpp:enumerator:`LV_STATE_PRESSED`: The main part in pressed state. :cpp:enumerator:`LV_PART_MAIN…
286 - :cpp:enumerator:`LV_PART_SCROLLBAR`: The scrollbar part in the default state. :cpp:enumerator:`LV…
287 - :cpp:expr:`LV_PART_SCROLLBAR | LV_STATE_SCROLLED`: The scrollbar part when the Widget is being sc…
288 …ATOR | LV_STATE_PRESSED | LV_STATE_CHECKED` The indicator part when the Widget is pressed and chec…
302 function will only replace ``old_style`` with ``new_style`` if the
303 ``selector`` matches the ``selector`` used in ``lv_obj_add_style``. Both
305 adding and removing styles. If the combination of
307 styles, all occurrences will be replaced. The return value of the
316 …lv_obj_replace_style(btn, &style_btn, &new_style_btn, 0); /* Replace the button style with a diff…
325 ``style`` only if the ``selector`` matches with the ``selector`` used in
326 :cpp:func:`lv_obj_add_style`. ``style`` can be ``NULL`` to check only the
327 ``selector`` and remove all matching styles. The ``selector`` can use
328 the :cpp:enumerator:`LV_STATE_ANY` and :cpp:enumerator:`LV_PART_ANY` values to remove the style from
335 property is added or changed), the Widgets using that style should be
338 1. If you know that the changed properties can be applied by a simple redraw
351 To get the final value of a style's property considering
358 These functions use the Widget's current state and if no better candidate exists they return the de…
378 freed when the Widget is deleted. They are useful to add local
398 For the full list of style properties click :ref:`here <style_properties>`.
406 In documentation of widgets you will see sentences like "The
407 _____ Widget uses the typical background style properties". These "typical
408 background properties" are the properties being referred to:
418 See :ref:`boxing_model` for the meanings of these terms.
427 By default, when a Widget changes state (e.g. it's pressed) the new
428 properties from the new state are set immediately. However, with
431 the pressed color over 300 ms.
433 The parameters of the transitions are stored in the styles. It's
436 - the time of the transition
437 - the delay before starting the transition
438 - the animation path (also known as the timing or easing function)
439 - the properties to animate
441 The transition properties can be defined for each state. For example,
442 setting a 500 ms transition time in the default state means that when
443 the Widget goes to the default state a 500 ms transition time is
444 applied. Setting a 100 ms transition time in the pressed state causes a
445 100 ms transition when going to the pressed state. This example
446 configuration results in going to the pressed state quickly and then
472 If the ``opa``, ``blend_mode``, ``transform_angle``, or
474 creates a snapshot of the widget and its children in order to
475 blend the whole widget with the set opacity, blend mode and
478 These properties have this effect only on the ``MAIN`` part of the
481 The created snapshot is called "intermediate layer" or simply "layer".
483 can build the layer from smaller chunks. The size of these chunks can be
484 configured by the following properties in ``lv_conf.h``:
486 - :cpp:enumerator:`LV_LAYER_SIMPLE_BUF_SIZE`: [bytes] the optimal target buffer size. LVGL will try…
489 If transformation properties were also used the layer cannot be
490 rendered in chunks, but one larger memory block needs to be allocated. The
491 required memory depends on the angle, zoom and pivot parameters, and the
492 size of the area to redraw, but it's never larger than the size of the
493 widget (including the extra draw size used for shadow, outline, etc).
495 If the widget can fully cover the area to redraw, LVGL creates an RGB
496 layer (which is faster to render and uses less memory). If the opposite
500 The click area of the widget is also transformed accordingly.
520 to the UI which can then be modified by adding further styles.
529 2. Assign the initialized theme to a display.
532 example shows how to set the "default" theme:
546 The included themes are enabled in ``lv_conf.h``. If the default theme
554 theme can be selected. The parent theme's styles will be added before
555 the custom theme's styles. Any number of themes can be chained this way.
558 :cpp:expr:`lv_theme_set_parent(new_theme, base_theme)` extends the
559 ``base_theme`` with the ``new_theme``.