Mirrors_UI_SDK/lvgl
1
0
Fork 0
mirror of https://github.com/lvgl/lvgl.git synced 2026-05-20 04:11:36 +08:00
Code Issues Actions 36 Packages Projects Releases Wiki Activity

docs(list formatting): fix erroneous list formatting (#8602)

Browse Source
This commit is contained in:
Victor Wheeler
2025-07-28 04:27:28 -06:00
committed by GitHub
parent 8f79aa941e
commit 8d74df6ae8
10 changed files with 230 additions and 178 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/src/details/integration/bindings/api_json.rst
+95 -75
View File
@@ -82,10 +82,11 @@ this field. The possible "json_type" values are:
- ``"array"``: The array type is used to identify arrays.
Fields:
- ``"dim"``: number of items in array
- ``"quals"``: array of qualifiers, IE "const"
- ``"type"``: This may or may not be available.
- ``"name"``: name of data type
- ``"dim"``: number of items in array
- ``"quals"``: array of qualifiers, IE "const"
- ``"type"``: This may or may not be available.
- ``"name"``: name of data type
- ``"field"``: This type is used to describe fields in structures and unions.
@@ -93,60 +94,66 @@ this field. The possible "json_type" values are:
covered below.
Fields:
- ``"name"``: field name
- ``"type"``: data type
``"json_type"`` carries object type (e.g. "enum", "function", etc.) identifying the top-level group it comes from
- ``"bitsize"``: The number of bits for bit-fields, or ``null`` for normal field types.
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"name"``: field name
- ``"type"``: data type
- ``"json_type"`` carries object type (e.g. "enum", "function", etc.) identifying the top-level group it comes from
- ``"bitsize"``: The number of bits for bit-fields, or ``null`` for normal field types.
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"arg"``: Describes a function argument
Fields:
- ``"name"``: argument name
- ``"type"``: data type
``"json_type"`` carries object type (e.g. "enum", "function", etc.) identifying the top-level group it comes from.
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"name"``: argument name
- ``"type"``: data type
- ``"json_type"`` carries object type (e.g. "enum", "function", etc.) identifying the top-level group it comes from.
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"forward_decl"``: Describes a forward declaration. There are structures in
LVGL that are considered to be private and that is what these describe.
Fields:
- ``"name"``: name of forward declaration
- ``"type"``: data type
``"json_type"`` carries object type (e.g. "enum", "function", etc.) identifying the top-level group it comes from.
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"name"``: name of forward declaration
- ``"type"``: data type
- ``"json_type"`` carries object type (e.g. "enum", "function", etc.) identifying the top-level group it comes from.
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"function_pointer"``: Describes a function pointer. These are used when
registering callback functions in LVGL.
Fields:
- ``"name"``: name of function pointer
- ``"type"``: function return type
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"args"``: array of ``"arg"`` objects described above
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"name"``: name of function pointer
- ``"type"``: function return type
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"args"``: array of ``"arg"`` objects described above
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"variable"``: Describes a global variable.
Fields:
- ``"name"``: variable name
- ``"type"``: data type
``"json_type"`` carries object type (e.g. "enum", "function", etc.) identifying the top-level group it comes from.
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"storage"``: array of any storage-class specifiers present (e.g. "auto", "static", "extern", etc.)
- ``"name"``: variable name
- ``"type"``: data type
- ``"json_type"`` carries object type (e.g. "enum", "function", etc.) identifying the top-level group it comes from.
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"storage"``: array of any storage-class specifiers present (e.g. "auto", "static", "extern", etc.)
- ``"special_type"``: Currently only used to describe an ellipsis argument of a function.
Fields:
- ``"name"``: always "ellipsis"
- ``"name"``: always "ellipsis"
- ``"primitive_type"``: Data type that does not begin with ``"lv_"`` and end with
@@ -154,55 +161,61 @@ this field. The possible "json_type" values are:
(e.g. int, unsigned int), etc..
Fields:
- ``"name"``: name of primitive type
- ``"name"``: name of primitive type
- ``"enum"``: C enumerations
Fields:
- ``"name"``: If enumeration is the result of a ``typedef``, this field carries
the type name defined. Example: ``lv_align_t``. (Not always available.)
- ``"type"``: type of enumerators (always "int")
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"members"``: array of ``"enum_member"`` objects
- ``"name"``: If enumeration is the result of a ``typedef``, this field carries
the type name defined. Example: ``lv_align_t``. (Not always available.)
- ``"type"``: type of enumerators (always "int")
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"members"``: array of ``"enum_member"`` objects
- ``"enum_member"``: enumerator (enumeration value). This "json_type" is only found
in the ``"members"`` array of an ``"enum"`` object
Fields:
- ``"name"``: enumerator name
- ``"type"``: If enumeration is the result of a ``typedef``, this field carries
the type name defined. Example: ``lv_align_t``.
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"value"``: enumerator value
- ``"name"``: enumerator name
- ``"type"``: If enumeration is the result of a ``typedef``, this field carries
the type name defined. Example: ``lv_align_t``.
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"value"``: enumerator value
- ``"lvgl_type"``: Data type defined in LVGL (begins with ``"lv_"`` and ends with ``"_t"``.
Fields:
- ``"name"``: type name
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"name"``: type name
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"struct"``: C struct
Fields:
- ``"name"``: struct name (data type if defined by ``typedef``)
- ``"type"``: a "primitive_type" object {"name": "struct", "json_type": "primitive_type"}. (See definition above.)
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"fields"``: array of ``"field"`` objects (See definition above.)
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"name"``: struct name (data type if defined by ``typedef``)
- ``"type"``: a "primitive_type" object {"name": "struct", "json_type": "primitive_type"}. (See definition above.)
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"fields"``: array of ``"field"`` objects (See definition above.)
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"union"``: C union
Fields:
- ``"name"``: union name (data type if defined by ``typedef``)
- ``"type"``: a "primitive_type" object {"name": "union", "json_type": "primitive_type"}. (See definition above.)
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"fields"``: array of ``"field"`` elements.
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"name"``: union name (data type if defined by ``typedef``)
- ``"type"``: a "primitive_type" object {"name": "union", "json_type": "primitive_type"}. (See definition above.)
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"fields"``: array of ``"field"`` elements.
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"macro"``: C macro. There is limited information that can be
@@ -211,59 +224,66 @@ this field. The possible "json_type" values are:
anything else.
Fields:
- ``"name"``: macro name
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"name"``: macro name
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"ret_type"``: return type from a function. This is only going to be seen in the ``"type"``
element of a ``"function"`` type.
Fields:
- ``"type"``: data type
``"json_type"`` carries object type (e.g. "enum", "function", etc.) identifying the top-level group it comes from.
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"type"``: data type
- ``"json_type"`` carries object type (e.g. "enum", "function", etc.) identifying the top-level group it comes from.
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"function"``: C function
Fields:
- ``"name"``: function name
- ``"type"``: A "ret_type" object. (See definition above.)
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"args"``: array of ``"arg"`` json types. (See definition above.)
- ``"name"``: function name
- ``"type"``: A "ret_type" object. (See definition above.)
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"args"``: array of ``"arg"`` json types. (See definition above.)
- ``"stdlib_type"``: C integral type (int, unsigned int, float, etc.)
Fields:
- ``"name"``: type name
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"name"``: type name
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"unknown_type"``: This should not be seen. If it is then there needs to be
an adjustment made to the script. Please open an issue and let us know if you see this type.
Fields:
- ``"name"``: type name
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"name"``: type name
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"pointer"``: C pointer
Fields:
- ``"type"``: pointer type
``"json_type"`` carries object type (e.g. "enum", "function", etc.) identifying the top-level group it comes from.
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"type"``: pointer type
- ``"json_type"`` carries object type (e.g. "enum", "function", etc.) identifying the top-level group it comes from.
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"typedef"``: C type definition
Fields:
- ``"name"``: type name (e.g. ``lv_part_t``)
- ``"type"``: a "primitive_type" object {"name": "uint32_t", "json_type": "stdlib_type"}. (See definition above.)
``"json_type"`` carries object type (e.g. "enum", "function", etc.) identifying the top-level group it comes from.
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"quals"``: array of any qualifiers present, e.g. "const"
- ``"name"``: type name (e.g. ``lv_part_t``)
- ``"type"``: a "primitive_type" object {"name": "uint32_t", "json_type": "stdlib_type"}. (See definition above.)
- ``"json_type"`` carries object type (e.g. "enum", "function", etc.) identifying the top-level group it comes from.
- ``"docstring"``: string containing Doxygen-extracted documentation
- ``"quals"``: array of any qualifiers present, e.g. "const"
docs/src/details/integration/boards/viewe.rst
+1
View File
@@ -14,6 +14,7 @@ Products Portfolio:
*******************
- Embedded Smart Displays
- `IOT_AIOT Smart Display <https://viewedisplay.com/iot_aiot-smart-display/>`_
- `Uart Smart Display <https://viewedisplay.com/uart-smart-display/>`_
- `HDMI Display_Raspberry Pi Display <https://viewedisplay.com/hdmi-display-raspberry-pi-display/>`_
docs/src/details/integration/driver/sdl.rst
+5 -3
View File
@@ -14,9 +14,10 @@ Prerequisites
-------------
Install SDL according to your platform.
Linux ``sudo apt install libsdl2-dev``
MacOS ``brew install sdl2``
Windows https://github.com/libsdl-org/SDL/releases
- Linux ``sudo apt install libsdl2-dev``
- MacOS ``brew install sdl2``
- Windows https://github.com/libsdl-org/SDL/releases
Configure SDL Driver
@@ -24,6 +25,7 @@ Configure SDL Driver
1. Required linked libraries: -lSDL2
2. Enable SDL driver support in lv_conf.h, CMake compiler definitions or KConfig.
.. code-block:: c
#define LV_USE_SDL 1
docs/src/details/integration/os/yocto/lvgl_recipe.rst
+44 -34
View File
@@ -132,14 +132,16 @@ all the layers::
bitbake-layers show-layers
The following layers should be listed:
- core
- yocto
- yoctobsp
- raspberrypi
- openembedded-layer
- multimedia-layer
- networking-layer
- meta-python
- core
- yocto
- yoctobsp
- raspberrypi
- openembedded-layer
- multimedia-layer
- networking-layer
- meta-python
Build for RaspberryPi3 64
=========================
@@ -197,20 +199,21 @@ bootloader files, and other components that are generated during the Yocto
build process.
There are some key folders:
- **images**: it contains the images that can be flashed or deployed to
the target device. Files like the Linux kernel, root filesystem (e.g., .
ext4, .tar.gz, .squashfs), bootloaders (e.g., U-Boot), and other
bootable images for the device are found here. t's organized by the
machine (or target board) for which the image was built.
- **rmp/deb/ipk**: These folders contain the individual software packages
generated during the build, in the specified package format (RPM, DEB,
or IPK). These packages are typically created when you're building your
Yocto project with package management support enabled. These can later
be installed on the target device using package management tools
- **sdk**: This subdirectory contains Software Development Kits (SDKs)
that you can use to cross-compile applications for your target system.
The SDKs are generated when you use the ``bitbake -c populate_sdk``
command.
- **images**: it contains the images that can be flashed or deployed to
the target device. Files like the Linux kernel, root filesystem (e.g., .
ext4, .tar.gz, .squashfs), bootloaders (e.g., U-Boot), and other
bootable images for the device are found here. t's organized by the
machine (or target board) for which the image was built.
- **rmp/deb/ipk**: These folders contain the individual software packages
generated during the build, in the specified package format (RPM, DEB,
or IPK). These packages are typically created when you're building your
Yocto project with package management support enabled. These can later
be installed on the target device using package management tools
- **sdk**: This subdirectory contains Software Development Kits (SDKs)
that you can use to cross-compile applications for your target system.
The SDKs are generated when you use the ``bitbake -c populate_sdk``
command.
tmp/sysroots-components
@@ -229,14 +232,15 @@ one package changes, Yocto only needs to update the corresponding component
rather than rebuilding or copying the entire sysroot.
If you followed the previous steps, here are the folders you will find:
- ``all``: Architecture-independent files.
- ``cortexa53``: Files for the Cortex-A53 (ARMv8-A) architecture.
- ``manifests``: Track files installed in the sysroot by package.
- ``raspberrypi3_64``: Files specific to the Raspberry Pi 3 (64-bit).
- ``x86_64``: Files for the x86_64 (PC) architecture, typically for
cross-compilation tools.
- ``x86_64-nativesdk``: Files related to the SDK for cross-compilation on
an x86_64 host.
- ``all``: Architecture-independent files.
- ``cortexa53``: Files for the Cortex-A53 (ARMv8-A) architecture.
- ``manifests``: Track files installed in the sysroot by package.
- ``raspberrypi3_64``: Files specific to the Raspberry Pi 3 (64-bit).
- ``x86_64``: Files for the x86_64 (PC) architecture, typically for
cross-compilation tools.
- ``x86_64-nativesdk``: Files related to the SDK for cross-compilation on
an x86_64 host.
Each folder corresponds to components relevant to the specific architecture,
and they collectively form the complete environment needed to compile and run
@@ -386,9 +390,10 @@ there is a LICENSE.txt. To get the value of the hash of the file, you can do
this command: ``md5sum LICENSE.txt``
SRC_URI: Specifies the locations of the source code and patches for the recipe:
- The main source repository for LVGL specifying the master branch.
- The following arguments are the local patch files that will be applied to
the source code during the build process.
- The main source repository for LVGL specifying the master branch.
- The following arguments are the local patch files that will be applied to
the source code during the build process.
**SRCREV**: Defines the specific commit (in this case, a Git SHA hash) from
which the source code will be fetched. This ensures that the build uses a
@@ -421,6 +426,7 @@ manually to understand what is generated each step, or you can run ``bitbake
lvgl`` to run all the tasks.
Fetch (do_fetch)
.. code-block:: bash
bitbake lvgl -c fetch
@@ -444,6 +450,7 @@ Fetch (do_fetch)
Unpack (do_unpack)
.. code-block:: bash
bitbake lvgl -c unpack
@@ -459,6 +466,7 @@ Unpack (do_unpack)
Patch (do_patch)
.. code-block:: bash
bitbake lvgl -c patch
@@ -471,6 +479,7 @@ Patch (do_patch)
current source directory **${S}**.
Configure (do_configure)
.. code-block:: bash
bitbake lvgl -c configure
@@ -491,8 +500,8 @@ Configure (do_configure)
generated running the CMake command, but nothing is built yet. Also, the
sysroots have everything required to build lvgl library.
Compile (do_compile)
.. code-block:: bash
bitbake lvgl -c compile
@@ -513,6 +522,7 @@ Compile (do_compile)
After this task has been completed, everything is ready to be installed.
Install (do_install)
.. code-block:: bash
bitbake lvgl -c install
docs/src/details/integration/os/yocto/terms_and_variables.rst
+6 -6
View File
@@ -28,12 +28,12 @@ S
-
The location in the Build Directory where unpacked recipe source code resides.
By default, this directory is ${WORKDIR}/${BPN}-${PV}, where ${BPN} is the
base recipe name and ${PV} is the recipe version. If the source tarball
extracts the code to a directory named anything other than ${BPN}-${PV}, or if
the source code is fetched from an SCM such as Git or Subversion, then you
must set S in the recipe so that the OpenEmbedded build system knows where to
find the unpacked source.
By default, this directory is ${WORKDIR}/${BPN}-${PV}, where ${BPN} is the
base recipe name and ${PV} is the recipe version. If the source tarball
extracts the code to a directory named anything other than ${BPN}-${PV}, or if
the source code is fetched from an SCM such as Git or Subversion, then you
must set S in the recipe so that the OpenEmbedded build system knows where to
find the unpacked source.
As an example, assume a Source Directory top-level folder named poky and a
default Build Directory at poky/build. In this case, the work directory the
docs/src/details/main-modules/image.rst
+14 -9
View File
@@ -74,17 +74,22 @@ Various built-in color formats are supported:
The bytes of :cpp:enumerator:`LV_COLOR_FORMAT_NATIVE` images are stored in the following order.
- 32-bit color depth:
- **Byte 0**: Blue
- **Byte 1**: Green
- **Byte 2**: Red
- **Byte 3**: Alpha (only with :cpp:enumerator:`LV_COLOR_FORMAT_NATIVE_WITH_ALPHA`)
- **Byte 0**: Blue
- **Byte 1**: Green
- **Byte 2**: Red
- **Byte 3**: Alpha (only with :cpp:enumerator:`LV_COLOR_FORMAT_NATIVE_WITH_ALPHA`)
- 16-bit color depth:
- **Byte 0**: Green 3 lower bit, Blue 5 bit
- **Byte 1**: Red 5 bit, Green 3 higher bit
- **Byte 2**: Alpha byte (only with :cpp:enumerator:`LV_COLOR_FORMAT_NATIVE_WITH_ALPHA`)
- **Byte 0**: Green 3 lower bit, Blue 5 bit
- **Byte 1**: Red 5 bit, Green 3 higher bit
- **Byte 2**: Alpha byte (only with :cpp:enumerator:`LV_COLOR_FORMAT_NATIVE_WITH_ALPHA`)
- 8-bit color depth:
- **Byte 0**: Red 3 bit, Green 3 bit, Blue 2 bit
- **Byte 2**: Alpha byte (only with :cpp:enumerator:`LV_COLOR_FORMAT_NATIVE_WITH_ALPHA`)
- **Byte 0**: Red 3 bit, Green 3 bit, Blue 2 bit
- **Byte 2**: Alpha byte (only with :cpp:enumerator:`LV_COLOR_FORMAT_NATIVE_WITH_ALPHA`)
You can store images in a *Raw* format to indicate that it's not encoded
with one of the built-in color formats and an external :ref:`Image decoder <overview_image_decoder>`
docs/src/details/widgets/chart.rst
+44 -37
View File
@@ -37,56 +37,63 @@ Each chart has the following attributes (over and above attributes found in
:ref:`all Widgets <base_widget>`):
Type (governs how a chart's data series are drawn)
- Can be LINE (default), BAR, SCATTER, or none.
- You can change the chart's type at any point during its life.
- Can be LINE (default), BAR, SCATTER, or none.
- You can change the chart's type at any point during its life.
Horizontal and Vertical division lines
- default 3 and 5 respectively
- can be any non-negative value including 0
- default 3 and 5 respectively
- can be any non-negative value including 0
2 Y axes and 2 X axes (the latter are used with SCATTER charts)
- All 4 axes come with each chart automatically (they do not have to be created).
- Their default ranges are [0..100]. If you need a different range, set it before
chart is drawn.
- You "use" an axis by associating it with a data series, which happens when the
data series is created (more on this below). More than one data series can be
associated with each axis.
- All 4 axes come with each chart automatically (they do not have to be created).
- Their default ranges are [0..100]. If you need a different range, set it before
chart is drawn.
- You "use" an axis by associating it with a data series, which happens when the
data series is created (more on this below). More than one data series can be
associated with each axis.
Point count (number of data points in all data series added to the chart)
- default 10
- If you provide your own data-value arrays, each array so provided must contain
at least this number of values.
- For LINE- and BAR-charts, this is the number of points on the X axis.
- LINE- and BAR-charts require only one data-value array to supply Y-values for each data point.
- For SCATTER charts, this is the number of scatter-points in the data series.
- SCATTER charts have separate data-value arrays for both X-values and Y-values.
- default 10
- If you provide your own data-value arrays, each array so provided must contain
at least this number of values.
- For LINE- and BAR-charts, this is the number of points on the X axis.
- LINE- and BAR-charts require only one data-value array to supply Y-values for each data point.
- For SCATTER charts, this is the number of scatter-points in the data series.
- SCATTER charts have separate data-value arrays for both X-values and Y-values.
Any number of data series
- After a chart is created, it initially contains no data series. You have to add them.
- You can add and remove data series at any time during a chart's life.
- When a data series is created, it comes with pre-allocated values array(s)
based on its chart type and ``point_count``. (All chart types use an array of
Y-values. SCATTER-type charts also use an array of X-values.). All Y-values so
allocated are set to :c:macro:`LV_CHART_POINT_NONE`, which causes that point to be hidden.
- To get points to be drawn on the chart, you must set their Y-values to something
other than :c:macro:`LV_CHART_POINT_NONE`.
- You can hide a point by setting its Y-value to :c:macro:`LV_CHART_POINT_NONE`.
- If desired, you can tell a data series to instead use a value array you
provide. If you do:
- Pre-allocated value arrays are automatically freed.
- That data series will continue to use *your* array from that time onward.
- The values in your array must remain available through the life of that data series.
- You must ensure each array provided contains at least ``point_count`` ``int32_t`` elements.
- Management of the life any value arrays you provide is up to you.
- After a chart is created, it initially contains no data series. You have to add them.
- You can add and remove data series at any time during a chart's life.
- When a data series is created, it comes with pre-allocated values array(s)
based on its chart type and ``point_count``. (All chart types use an array of
Y-values. SCATTER-type charts also use an array of X-values.). All Y-values so
allocated are set to :c:macro:`LV_CHART_POINT_NONE`, which causes that point to be hidden.
- To get points to be drawn on the chart, you must set their Y-values to something
other than :c:macro:`LV_CHART_POINT_NONE`.
- You can hide a point by setting its Y-value to :c:macro:`LV_CHART_POINT_NONE`.
- If desired, you can tell a data series to instead use a value array you
provide. If you do:
- Pre-allocated value arrays are automatically freed.
- That data series will continue to use *your* array from that time onward.
- The values in your array must remain available through the life of that data series.
- You must ensure each array provided contains at least ``point_count`` ``int32_t`` elements.
- Management of the life any value arrays you provide is up to you.
Any number of cursors
- After a chart is created, it initially contains no cursors. You have to add them
if you want to use them.
- You can add, show, hide or remove cursors at any time during a chart's life.
- After a chart is created, it initially contains no cursors. You have to add them
if you want to use them.
- You can add, show, hide or remove cursors at any time during a chart's life.
Update mode
- :ref:`See below <chart_update_modes>`
- :ref:`See below <chart_update_modes>`
Chart layers
docs/src/details/widgets/menu.rst
+12 -7
View File
@@ -45,13 +45,18 @@ Create a Menu
This creates a Menu Widget with this object hierarchy:
- Menu: :cpp:type:`lv_menu_t`
- Hidden Sub-Page Storage: :cpp:type:`lv_obj_t`
- Main container: :cpp:var:`lv_menu_main_cont_class`
- Main header: :cpp:var:`lv_menu_main_header_cont_class`
- Back button: :ref:`lv_button`
- Back button icon: :ref:`lv_image`
- Main header title: :ref:`lv_label` (default hidden)
- Menu: :cpp:type:`lv_menu_t`
- Hidden Sub-Page Storage: :cpp:type:`lv_obj_t`
- Main container: :cpp:var:`lv_menu_main_cont_class`
- Main header: :cpp:var:`lv_menu_main_header_cont_class`
- Back button: :ref:`lv_button`
- Back button icon: :ref:`lv_image`
- Main header title: :ref:`lv_label` (default hidden)
Note that no sidebar is created. You can create one later if you wish.
docs/src/intro/getting_started/learn_the_basics.rst
+6 -5
View File
@@ -37,11 +37,12 @@ Basic Data Flow
3. **Create display and input devices**: Create display(s) (:cpp:type:`lv_display_t`) and input device(s) (:cpp:type:`lv_indev_t`) and set up their callbacks
4. **Create the UI**: Call LVGL functions to create screens, widgets, styles, animations, events, etc.
5. **Call lv_timer_handler() in a loop**: It handles all the LVGL-related tasks:
- refresh display(s),
- read input devices,
- fire events based on user input (and other things),
- run any animations, and
- run user-created timers.
- refresh display(s),
- read input devices,
- fire events based on user input (and other things),
- run any animations, and
- run user-created timers.
Integration example
-------------------
docs/src/intro/introduction/faq.rst
+3 -2
View File
@@ -55,8 +55,9 @@ LVGL doesn't start, randomly crashes or nothing is drawn on the display. What ca
* Enable :ref:`logging`.
* Enable assertions in ``lv_conf.h`` (``LV_USE_ASSERT_...``).
* If you use an RTOS:
* Increase the stack size of the task that calls :cpp:func:`lv_timer_handler`.
* Be sure you are using one of the methods for thread management as described in :ref:`threading`.
* Increase the stack size of the task that calls :cpp:func:`lv_timer_handler`.
* Be sure you are using one of the methods for thread management as described in :ref:`threading`.
My display driver is not called. What have I missed?