LVGL Pro Best Practices

These guidelines help keep projects organized, maintainable, and easier to scale when working with the LVGL Pro Editor.

These guidelines help keep projects organized, maintainable, and easier to scale when working with the LVGL Pro Editor.

1. Project Naming

Avoid project names that may conflict with libraries or frameworks.

Do NOT use:

• lvgl

Recommended:

• Use a unique project name specific to your project.

This prevents naming conflicts and keeps the build system clean.

2. Asset Organization

Use clear and consistent prefixes for generated assets.

Images

• icon_
• image_

Fonts

Use structured naming to handle different sizes and styles:

• font_<name>_<size>
• font_<name>_<size>_<format>

Examples:

• font_roboto_14_regular
• font_roboto_16_bold

This is especially important when managing multiple font sizes and formats such as bold, italic, or medium.

3. Raw Resource Separation

Keep raw resources separate from generated resources.

Recommended structure:

images/
images/raw/

images/raw/icon_home.png
images/icon_home.c

• icon_home_20dp.png
• icon_home_40dp.png

Benefits:

• Generated files remain easy to locate
• Raw assets are not mixed with generated files
• Project structure remains clean and predictable

4. Subject Naming

Use a consistent prefix for subjects.

• subject_settings
• subject_home

This improves readability and ensures naming consistency across the project.

5. Style Naming

Always prefix styles.

Base styles:

• style_button
• style_container
• style_text

Theme variants:

If multiple themes are used (e.g., dark and light), include a theme prefix:

• style_dark_button
• style_light_button

This approach simplifies theme management and scaling.

6. Screens, Components, and Widgets

Create screens, components, and widgets using their respective folders.

Recommended approach:

Use:

• Add New → Component
• Add New → Widget
• Add New → Screen

This automatically organizes them into subfolders, improving navigation and maintainability.

7. Widget Naming

Use a prefix for widgets:

• wd_menu
• wd_statusbar
• wd_clock

This makes widgets easy to identify and avoids naming conflicts.

8. Do Not Edit Generated Files

Files generated by the editor are overwritten during regeneration.

Do not modify them directly.

Instead:

• Modify the source XML
• Use styles
• Use components or widgets

Direct edits to generated files will be lost.

9. Avoid Inline Styles in XML

Minimize the use of inline style attributes.

Avoid:

<lv_obj style_bg_color="0x000000" style_bg_opa="255" />

Recommended:

<styles>
   <style name="style_obj" bg_color="0x000000" bg_opa="255" />
</styles>

<lv_obj>
   <style name="style_obj" />
</lv_obj>

Benefits:

• Styles are reusable
• XML remains clean and readable
• Easier maintenance and updates

10. Avoid API Properties in Components/Widgets

Avoid defining API properties that may conflict with editor-specific behavior.

Avoid:

<prop name="name" type="text" />

Also avoid unnecessary API overrides:

<api>
   <prop name="width" type="int" />
</api>

<view width="$width" />

Recommended:

Use the help property to document API usage:

<api name="text" type="string" help="Sets the label text of the component" />

11. Avoid Overriding Default Flags or State

Avoid overriding default states or flags on the root object unless necessary.

Avoid:

<component>
   <view checked="true" />
</component>

Recommended:

Set such properties when the component is used within a screen.

This ensures components remain flexible and reusable.

12. Component Sizing Best Practices

Avoid combining fixed component sizes with fixed child sizes.

Not recommended:

<view width="content">
   <lv_dropdown width="420" />
</view>

This prevents proper resizing when the component is reused.

Recommended:

<view width="420">
   <lv_dropdown width="100%" />
</view>

Benefits:

• Child elements resize automatically
• Components can be reused at different sizes
• Layout behavior remains predictable