lv_xml_load_all_from_path is unable to correctly handle the dependencies between the XML files when dynamically loading.

[ShenRen]

My development environment：
mac m3
lvgl v9.5
lvgl pro editor v2.0.2

The implementation of the function "lv_xml_load_all_from_path" seems to be a simple recursive traversal of the files in the directory and an attempt to parse all xml-format files.

The sorting rule of the underlying file system of lv_fs, if folders are listed first, will cause the globals.xml file in the lvgl_pro_editor project to be parsed and loaded last, resulting in the files in the components and screens folders being unable to reference resources such as styles, images, and fonts.

And the extensions, inheritance, and references between components, between components and the screen, and between screens will all become invalid.

[ShenRen]

The expected behavior of lv_xml_load_all_from_path is as follows: The first step is to parse the inter-references between files to establish dependencies (pay special attention to circular dependencies), and the second step is to load the files in sequence according to the dependencies.

[ShenRen]

lv_xml_load_enhance.c

I have attempted to optimize the loading function. If it proves effective, you can adopt it.

Improve XML loading.md

[ShenRen]

LVGL XML Loading Improvements

1. Problem Analysis

Current Issues

The lv_xml_load_all_from_path function loads XML files using a simple recursive directory traversal, loading files one by one in the order returned by the filesystem, without considering dependencies between XML files. This leads to:

• Component A references Component B, but B is not yet registered, causing reference failures
• globals.xml may load after components, leaving shared constants/styles/themes unavailable
• Screen files may reference components that haven't been loaded yet

Dependency Types

Based on the LVGL XML syntax specification, there are several types of file dependencies:

Type	XML Expression	Description
Component Inheritance	<view extends="my_button">	The current component inherits from another custom component
Component Reference	<round_button text="+"/>	Using a custom component as a child element within a view
Screen Reference	<screen_load_event screen="screen_main"/>	Reference to another screen
Screen Reference	<screen_create_event screen="screen_about"/>	Dynamically creating another screen
Global Resources	globals.xml	Shared styles, constants, themes, images, fonts, etc.

Tags That Are NOT Component Dependencies

The following tags are LVGL XML built-in elements and should NOT be recognized as custom component dependencies:

• Built-in Widgets (lv_* prefix): lv_label, lv_button, lv_slider, lv_obj, lv_image, lv_switch, etc.
• Special XML Elements: style, bind_style, remove_style_all, event_cb, screen_load_event, screen_create_event, subject_increment_event, set_subject, bind_text, bind_value, bind_flag, bind_flag_if_eq, animation, timeline, include_timeline
• Container Elements: view, consts, styles, api, previews, preview, animations, images, fonts, subjects

Loading Priority

1. globals.xml — Highest priority, defines global shared resources
2. translations.xml — Translation files
3. Custom Components — Loaded in dependency order (dependencies loaded first)
4. Screen Files — Usually depend on components, loaded in dependency order

---

2. Algorithm Design

Overall Flow

lv_xml_load_all_from_path(path)
  │
  ├── Phase 1: Scan & Dependency Analysis
  │   ├── 1. Recursively traverse directories, collect all .xml file paths
  │   ├── 2. Perform lightweight parsing on each XML file, extracting:
  │   │   ├── File type (component/screen/globals/translations/widget/project)
  │   │   ├── Component name (filename without extension)
  │   │   └── Dependency list
  │   └── 3. Build a dependency graph (adjacency list)
  │
  ├── Phase 2: Cycle Detection
  │   └── DFS + state markers to detect circular dependencies, log warnings when found
  │
  └── Phase 3: Topological Sort & Load
      ├── 1. Sort by priority + topological order
      ├── 2. Load globals.xml first
      ├── 3. Load translations.xml
      ├── 4. Load components in dependency order
      └── 5. Load screens in dependency order

Data Structures

File Info Node

typedef struct {
    char *path;           // Full file path
    char *name;           // Component/screen name (without extension)
    xml_file_type_t type; // File type
    int dep_count;        // Number of dependencies
    int dep_capacity;     // Capacity of the dependency array
    char **deps;          // Dependency name array
    bool visited;         // DFS visited marker
    bool in_stack;        // DFS recursion stack marker (for cycle detection)
} xml_file_node_t;

Dependency Graph

Represented as an adjacency list: each file node maintains a dependency list. File A depends on File B means: A(depends_on) → B.

File Type Enum

typedef enum {
    XML_FILE_TYPE_UNKNOWN,
    XML_FILE_TYPE_GLOBALS,      // globals.xml
    XML_FILE_TYPE_TRANSLATIONS, // translations.xml
    XML_FILE_TYPE_COMPONENT,    // <component>
    XML_FILE_TYPE_SCREEN,       // <screen>
    XML_FILE_TYPE_WIDGET,       // <widget> — requires a custom parser, typically not loadable at runtime
    XML_FILE_TYPE_PROJECT,      // project.xml — editor configuration, skipped at runtime
} xml_file_type_t;

Lightweight XML Parsing

The Phase 1 dependency analysis does not require full XML parsing. It only needs to extract:

1. The root element tag name (to determine the file type)
2. The extends attribute value in <view extends="X"> (if not an lv_* prefix, add as a dependency)
3. All first-level child element tag names within <view> (filter out built-in widgets and special elements; treat the remainder as dependencies)
4. The screen attribute values in <screen_load_event screen="X"> and <screen_create_event screen="X">

Implemented using the expat SAX parser — records the above information as soon as it is encountered, without fully parsing the entire document tree.

Cycle Detection (DFS Three-Color Marking)

function detect_cycle(node):
    if node.in_stack:
        report cycle: node → ... → node
        return true  (found cycle)
    if node.visited:
        return false

    node.visited = true
    node.in_stack = true

    for each dep in node.deps:
        dep_node = find_node_by_name(dep)
        if dep_node and detect_cycle(dep_node):
            remove this dependency  (break the cycle)

    node.in_stack = false
    return false

Topological Sort (DFS Post-order Traversal)

function topological_sort(nodes):
    for each node in nodes:
        if not node.visited:
            dfs_sort(node)

function dfs_sort(node):
    node.visited = true
    for each dep in node.deps:
        dep_node = find_node_by_name(dep)
        if dep_node and not dep_node.visited:
            dfs_sort(dep_node)
    push node to sorted_list

Topological sort result: files that appear earlier in the list do not depend on files that appear later, meaning files at the beginning of the sorted list should be loaded first.

Loading Priority Adjustment

After topological sorting, forcibly adjust the order:

1. Move globals.xml type files to the front
2. Move translations.xml type files after globals
3. Skip project.xml and widget type files (do not load them)
4. Load the rest in topological order

---

3. Implementation Steps

Step 1: Define Data Structures and Helper Functions

• Add the xml_file_node_t struct
• Add the xml_file_type_t enum
• Implement file node creation and destruction functions
• Implement dependency addition functions

Step 2: Implement File Collection Function

• Implement collect_xml_files() — recursively traverse directories, collect all .xml file paths
• Skip project.xml (not needed at runtime)

Step 3: Implement Lightweight Dependency Parsing

• Implement parse_file_dependencies() — parse a single file using expat, extract dependencies
• Implement SAX event handler callbacks

Step 4: Implement Cycle Detection

• Implement detect_circular_dependencies() — DFS three-color marking
• Log warnings when cycles are found, break cycle edges

Step 5: Implement Topological Sort

• Implement topological_sort() — DFS post-order traversal
• Account for loading priority (globals first, translations second)

Step 6: Implement Ordered Loading

• Implement load_files_in_order() — load files one by one in sorted order
• For component/screen types, call lv_xml_register_component_from_data()
• For translations type, call lv_xml_register_translation_from_data()
• For widget type, skip (requires a custom C parser)

Step 7: Refactor the Main Function

• Modify lv_xml_load_all_from_path() to use the new flow
• Keep lv_xml_load_init() and lv_xml_load_deinit() unchanged

---

4. Test Cases

Test Scenario 1: Simple Dependency Chain

a.xml → depends on b.xml → depends on c.xml
Expected: load order c, b, a

Test Scenario 2: Diamond Dependency

screen.xml → component_a.xml
screen.xml → component_b.xml
component_a.xml → component_b.xml
Expected: load order component_b, component_a, screen (or component_b, component_a, screen)

Test Scenario 3: Circular Dependency

a.xml → depends on b.xml → depends on c.xml → depends on a.xml
Expected: detect the cycle, log a warning, break one edge, then continue loading

Test Scenario 4: globals.xml Priority

screen.xml → depends on my_component.xml
my_component.xml → references constants in globals.xml
Expected: globals.xml loads first

Test Scenario 5: tutorials Project

Test with the lvgl_pro_demos/tutorials directory:
- globals.xml loads first
- translations.xml follows
- components/round_button.xml before components/sliderbox.xml
- All components before screen files
- sliderbox.xml's dependency on round_button.xml is correctly resolved

---

5. Compatibility Considerations

1. Keep the function signature and return value of lv_xml_load_all_from_path unchanged
2. Keep lv_xml_load_init and lv_xml_load_deinit unchanged
3. The existing WASM versions lv_xml_load_all_from_data and lv_xml_load_all_from_file are unaffected
4. The XML type detection logic in load_from_path_start_element_handler remains unchanged
5. For files with no dependencies (single-file scenarios), behavior is identical to the original

[laszlobalint]

@kisvegabor, as this seems to be primarily LV XML related, can you have a look and share your thoughts?

[kisvegabor]

You are right, but I wonder from where do you use lv_xml. It was removed from lvgl in v9.5. Are you still on v9.4?

[ShenRen]

You are right, but I wonder from where do you use lv_xml. It was removed from lvgl in v9.5. Are you still on v9.4?

I simply extracted the lv_xml from the lvgl v9.4 version and made it compatible and integrated on lvgl v9.5. Meanwhile, based on the latest LVGL Pro documentation, I have understood and implemented some of the new XML syntax features. Thanks to the clear and easily understandable code of the entire LV_XML engine, I can expand it. Currently, I am using this old version of LV_XML to save an old project that was on the verge of failure due to changes in the engine's openness.

[kisvegabor]

You must be a smart guy 🙂

I see that issue, and I can take care of it in our implementation. Since I can't fix it publicly I'm closing this issue.

Thank you for reporting it.