diff --git a/docs/src/details/integration/bindings/api_json.rst b/docs/src/details/integration/bindings/api_json.rst index 45be78d0f9..b0d98b272c 100644 --- a/docs/src/details/integration/bindings/api_json.rst +++ b/docs/src/details/integration/bindings/api_json.rst @@ -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" diff --git a/docs/src/details/integration/boards/viewe.rst b/docs/src/details/integration/boards/viewe.rst index 134fbab171..eba694dff4 100644 --- a/docs/src/details/integration/boards/viewe.rst +++ b/docs/src/details/integration/boards/viewe.rst @@ -14,6 +14,7 @@ Products Portfolio: ******************* - Embedded Smart Displays + - `IOT_AIOT Smart Display `_ - `Uart Smart Display `_ - `HDMI Display_Raspberry Pi Display `_ diff --git a/docs/src/details/integration/driver/sdl.rst b/docs/src/details/integration/driver/sdl.rst index d05879711c..e345fdbc20 100644 --- a/docs/src/details/integration/driver/sdl.rst +++ b/docs/src/details/integration/driver/sdl.rst @@ -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 diff --git a/docs/src/details/integration/os/yocto/lvgl_recipe.rst b/docs/src/details/integration/os/yocto/lvgl_recipe.rst index 5594907e00..9aabb7a2f4 100644 --- a/docs/src/details/integration/os/yocto/lvgl_recipe.rst +++ b/docs/src/details/integration/os/yocto/lvgl_recipe.rst @@ -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 diff --git a/docs/src/details/integration/os/yocto/terms_and_variables.rst b/docs/src/details/integration/os/yocto/terms_and_variables.rst index 5a448cc64c..c6d9bc723d 100644 --- a/docs/src/details/integration/os/yocto/terms_and_variables.rst +++ b/docs/src/details/integration/os/yocto/terms_and_variables.rst @@ -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 diff --git a/docs/src/details/main-modules/image.rst b/docs/src/details/main-modules/image.rst index d2d7219f4a..a8a85cb5d9 100644 --- a/docs/src/details/main-modules/image.rst +++ b/docs/src/details/main-modules/image.rst @@ -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 ` diff --git a/docs/src/details/widgets/chart.rst b/docs/src/details/widgets/chart.rst index 15b6ca0570..e3b1abfdef 100644 --- a/docs/src/details/widgets/chart.rst +++ b/docs/src/details/widgets/chart.rst @@ -37,56 +37,63 @@ Each chart has the following attributes (over and above attributes found in :ref:`all Widgets `): 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 ` + +- :ref:`See below ` Chart layers diff --git a/docs/src/details/widgets/menu.rst b/docs/src/details/widgets/menu.rst index eabb6b7b7d..b0ff05e6e1 100644 --- a/docs/src/details/widgets/menu.rst +++ b/docs/src/details/widgets/menu.rst @@ -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. diff --git a/docs/src/intro/getting_started/learn_the_basics.rst b/docs/src/intro/getting_started/learn_the_basics.rst index c74a0629d0..7c73ff14fe 100644 --- a/docs/src/intro/getting_started/learn_the_basics.rst +++ b/docs/src/intro/getting_started/learn_the_basics.rst @@ -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 ------------------- diff --git a/docs/src/intro/introduction/faq.rst b/docs/src/intro/introduction/faq.rst index f04991f1bd..146852879d 100644 --- a/docs/src/intro/introduction/faq.rst +++ b/docs/src/intro/introduction/faq.rst @@ -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?