Hi everyone,
I am experiencing a severe and persistent layout lifecycle synchronization issue in LVGL v9 regarding the dynamic positioning of the dropdown list container (list box) when switching the UI base direction to RTL (Right-to-Left).
UI Architecture & Hierarchy:
- We have a root full-screen canvas loaded with a sliding page transition mechanics.
- Inside the main viewport, there is a vertical scroll container layout managed via native flex column rules:
lv_obj_set_flex_flow(scrollList, LV_FLEX_FLOW_COLUMN);. - Inside this flex container, we instantiate custom frame components where we create dropdown objects:
ddType = lv_dropdown_create(frame_battery_settings);andddMode = lv_dropdown_create(frame_battery_settings);. - The elements are explicitly positioned via absolute bounds relative to their respective local frame origins using
lv_obj_align(ddMode, LV_ALIGN_TOP_LEFT, 160, 50);.
The Problem:
When the user switches the active application language to Arabic or Persian (ar / fa), we programmatically enforce a layout mirror pass by intercepting the root canvas via:
lv_obj_set_style_base_dir(new_screen, LV_BASE_DIR_RTL, 0);
- Dropdown Button Behavior (Correct): The flex layout engine and base direction parameters intercept successfully on startup. The dropdown master buttons correctly flip horizontally across the X-axis and mirror themselves dynamically to the opposite side of the frame.
- Dropdown Open List Behavior (Broken): When a user physically interacts with the mirrored dropdown widget, the dynamically generated dropdown list container (
list box) completely ignores the updated runtime positional bounds of its master button. It spawns blindly on the right-hand side of the display—locked firmly onto the old default LTR layout matrix coordinates.
What We Have Tried (and why it fails):
- Static Pre-fetching at Creation: Accessing
lv_dropdown_get_list(dd)inside the factory assembler phase and applying styles or alignment offsets fails completely because the layout engine completely re-creates/destroys the dynamic sheet overlay on physical pointer touch event intervals. - Hooking into Event Callbacks: Attempting to catch
LV_EVENT_CLICKED,LV_EVENT_FOCUSED, or raw hardware drawing hooks likeLV_EVENT_DRAW_POST_BEGIN(31) to manually override coordinates vialv_obj_align_toorlv_obj_set_poseither fails silently or triggers a fatal infinite layout recalculation loop, completely freezing the FreeRTOS task and locking the hardware SPI/DMA display transmission lines. The core positioning engine (lv_dropdown_init_list) executes asynchronously right after these flags, forcefully wiping out our manual layout overrides. - Using v9 Layout Completions: Reading the raw hook state 53 (
LV_EVENT_GET_SELF_SIZE) allows us to adjust positions without a hard device crash, but the layout matrix remains absolutely deaf to horizontal shifts; the list container refuses to jump down to the absolute left bounding corridor of the dropdown button.
It seems the dropdown overlay layer (lv_layer_top) drops outside the logical scope of the parenting flex containment architecture during RTL matrix transformation phases.
code
// Event callback attached via LV_EVENT_ALL
void AppSetupScreen::dd_mode_changed_cb(lv_event_t* e) {
lv_event_code_t code = lv_event_get_code(e);
lv_obj_t* dd = (lv_obj_t*)lv_event_get_target(e);
// We want to force the list box to render flush left with a 25px vertical padding gap
// But layout overrides here are continuously bypassed or trigger system freezes
if (code == LV_EVENT_VALUE_CHANGED) {
lv_obj_t* list = lv_dropdown_get_list(dd);
if (list != nullptr) {
lv_obj_set_style_base_dir(list, LV_BASE_DIR_LTR, LV_PART_MAIN);
lv_obj_set_style_text_align(list, LV_TEXT_ALIGN_LEFT, LV_PART_MAIN);
lv_obj_align_to(list, dd, LV_ALIGN_OUT_BOTTOM_LEFT, 0, 25); // Sağırlık / Does not move
}
}
}
How can we gracefully force the dynamically allocated dropdown list overlay to correctly query and attach its origin directly onto the active runtime mirrored coordinates of its parenting dropdown button inside an RTL flex container in LVGL v9? Is there an official rendering lifecycle pipeline hook designed to override this asynchronous positioning bug without crashing the hardware drawing buffers?
Any architectural guidance would be highly appreciated. Thanks!