Developer Integration
Regeneration and Ownership
Review exactly which exported files are generated, developer-owned or require diff review.
Ownership map
| File or area | Managed by | May be regenerated | Appropriate changes |
|---|---|---|---|
| 90_Studio_Export.c / .h | Studio | Yes | None permanent; review generated output only. |
| 95_UserEvents.c / .h | Developer after standalone export | Live Studio copies can be regenerated | Callbacks and integration logic in the standalone copy. |
| Generated assets | Studio | Yes | Do not hand-edit; replace through Studio. |
| main.c / app_main | Developer/export template | Review the export diff | Startup and application composition. |
| CMakeLists.txt | Exporter | Yes | Review before adding persistent custom registration. |
| Other developer modules | Developer | No by the UI generator | Drivers, services, tasks and product behavior. |
Hardware Example ownership pattern
Example 01 is the concrete regeneration model: 90_Studio_Export.* owns replaceable generated LVGL and public FG_Set_* implementations; matching 95_UserEvents callback bodies carry UI intent into developer code; ordinary developer modules own GPIO setup, polling, debouncing, outputs, startup safety and physical behavior.
Safe Git workflow
- 01Commit the current export.
- 02Regenerate the UI.
- 03Review the complete diff.
- 04Restore or merge intentional developer changes where required.
- 05Build the standalone project.
- 06Test the result on physical hardware.