Edit nxp gui guider ui

Edit NXP GUI Guider UI

Preserve the GUI Guider project as the source of truth. Treat designer editability and generated runtime behavior as separate acceptance criteria.

Execute the workflow

1. Inspect the target .guiguider file, FrontJson, Application.screen, the matching generated/setup_scr_*.c, and generated/gui_guider.h before editing.
2. Read the nearest project guidance. If GUI_GUIDER_PROFILE.md exists, treat it as the project layer and follow it after this general workflow.
3. Identify the target screen, its existing parent hierarchy, and the GUI Guider/LVGL version.
4. Define every changed control once with its ID, names on both sides, type, parent, geometry, and layer position.
5. Update FrontJson and Application.screen together. Read references/three-way-sync.md for the field and ordering rules.
6. Update generated setup C and gui_guider.h so declarations, parent creation, and control creation match the two model trees.
7. Keep user event logic in the project's custom-code files. Do not create designer-visible controls only in custom code.
8. Run scripts/validate_guiguider.py against the project file. Add --generated-dir when generated sources are available.
9. Clean and build with the toolchain declared by the project or discovered from the GUI Guider installation. Do not guess a compiler path or architecture.
10. Open the project in GUI Guider and confirm that changed controls render, can be selected, and can be moved without corrupting the layer tree.
11. Report structural validation, build result, designer result, and any remaining risk separately.

Apply non-negotiable constraints

• Keep FrontJson, Application.screen, generated setup C, and gui_guider.h synchronized.
• Use one GUI Guider-style ID per logical control and preserve that ID across both model trees.
• Preserve the existing parent hierarchy unless the task explicitly changes it.
• Create a parent before any child in generated C.
• Declare a generated control before referencing it from custom code.
• Use left, top, width, and height for non-screen FrontJson nodes.
• Use pos and size as geometry for non-screen Application.screen nodes.
• Never copy pos/size directly into FrontJson, or left/top into Application.screen.
• Preserve widget-specific fields even when they share names such as width or height; for example, some GUI Guider versions emit both size and spinner-specific width/height.
• Preserve the representation's layer-order convention. In commonly observed GUI Guider projects, FrontJson.list is the reverse of Application.screen[].widgets; verify the current project instead of assuming.
• Keep style values, screen/container names, build commands, and toolchain paths in the project layer, not in this general skill.
• Limit changes to the requested screen unless shared generated declarations must change.

Choose controls by role

• Use lv_line for a decorative line when the target GUI Guider version supports it reliably.
• Use a non-interactive empty label or equivalent designer-native primitive for a simple background or border when that matches existing project patterns.
• Use a container only when it must own children, clip content, move a group, or provide group-level styling.
• Prefer controls that GUI Guider can represent and regenerate over custom runtime-only objects.

Read references/widget-and-hierarchy-rules.md before changing containers or introducing new control types.

Validate completion

Require all applicable checks in references/verification.md. Compilation alone is insufficient: a change is incomplete until the designer model, application model, generated declarations, generated setup code, and visual editability agree.

For a new repository, copy assets/GUI_GUIDER_PROFILE.template.md to the project root as GUI_GUIDER_PROFILE.md and fill in only project-specific facts.