Add Stage UI extension

[juanluber]

Stage UI adds simple DOM-based UI controls over the stage (input, textarea, button, checkbox, select, radio). Controls are positioned using stage coordinates and can be shown/hidden, focused, removed, and queried for current value.

Tested:

Loaded in TurboWarp editor; blocks appear under “Stage UI”.

Created each control type and verified positioning, show/hide, remove, focus.

Verified event hats trigger correctly.

Verified UI is cleared when the project stops (Stop button).

[Brackets-Coder]

see #2157, this is a duplicate

[juanluber]

@Brackets-Coder Thanks for the note! I checked #2157 and it’s closed (never merged). This PR is a fresh implementation, up-to-date, and all required checks are passing. If you still see any overlap concerns, I’m happy to adjust scope or follow preferred guidelines.

[juanluber]

Added documentation at docs/juanluber/stage-ui.md.

[Brackets-Coder]

@Brackets-Coder Thanks for the note! I checked #2157 and it’s closed (never merged). This PR is a fresh implementation, up-to-date, and all required checks are passing. If you still see any overlap concerns, I’m happy to adjust scope or follow preferred guidelines.

Sorry, wrong PR. This is a duplicate of #2158

[juanluber]

@Brackets-Coder Thanks for the note! I checked #2157 and it’s closed (never merged). This PR is a fresh implementation, up-to-date, and all required checks are passing. If you still see any overlap concerns, I’m happy to adjust scope or follow preferred guidelines.

Sorry, wrong PR. This is a duplicate of #2158

@Brackets-Coder ¡Gracias por la aclaración! No conocía el #2158.
Le eché un vistazo y parece que aborda una idea similar, pero lleva abierto desde junio de 2025. Este PR es una implementación nueva, actualizada, supera todas las comprobaciones necesarias e incluye documentación y limpieza automática al detener el proyecto.

Si los responsables del mantenimiento prefieren un único PR para esta función, con gusto seguiré sus preferencias:

Si prefieren continuar con este PR, puedo seguir iterando aquí.

Si prefieren mantener el #2158 como el PR canónico, puedo cerrarlo y volver a enviar las mejoras pertinentes en la forma que prefieran.

[juanluber]

@Brackets-Coder Thanks for the note! I checked #2157 and it’s closed (never merged). This PR is a fresh implementation, up-to-date, and all required checks are passing. If you still see any overlap concerns, I’m happy to adjust scope or follow preferred guidelines.

Sorry, wrong PR. This is a duplicate of #2158

@Brackets-Coder Thanks for clarifying! I wasn’t aware of #2158.
I took a look and it appears to cover a similar idea, but it has been open since June 2025. This PR is a fresh implementation, up-to-date, passes all required checks, and includes documentation and automatic cleanup on project stop.

If maintainers prefer a single PR for this feature, I’m happy to follow their preference:

If they’d rather continue with this PR, I can keep iterating here.

If they’d rather keep #2158 as the canonical PR, I can close this PR and re-submit the relevant improvements in whatever form they prefer.

[juanluber]

@Brackets-Coder Thanks for the note! I checked #2157 and it’s closed (never merged). This PR is a fresh implementation, up-to-date, and all required checks are passing. If you still see any overlap concerns, I’m happy to adjust scope or follow preferred guidelines.

Sorry, wrong PR. This is a duplicate of #2158

@Brackets-Coder Thanks for the clarification! I wasn’t aware of #2158. I took a look and it seems to cover a similar idea, but it has been open since June 2025. This PR is a fresh, up-to-date implementation, passes all required checks, and includes documentation and automatic cleanup when the project stops.

If the maintainers prefer having a single PR for this feature, I’m happy to follow their preference:

If they’d rather continue with this PR, I can keep iterating here.

If they’d rather keep #2158 as the canonical PR, I can close this one and resubmit the relevant improvements in whatever form they prefer.

[juanluber]

@Brackets-Coder Thanks for the note! I checked #2157 and it’s closed (never merged). This PR is a fresh implementation, up-to-date, and all required checks are passing. If you still see any overlap concerns, I’m happy to adjust scope or follow preferred guidelines.

Sorry, wrong PR. This is a duplicate of #2158

@Brackets-Coder Thanks for the clarification! I wasn’t aware of #2158. I took a look and it seems to cover a similar idea, but it has been open since June 2025. This PR is a fresh, up-to-date implementation, passes all required checks, and includes documentation and automatic cleanup when the project stops.

If the maintainers prefer having a single PR for this feature, I’m happy to follow their preference:

If they’d rather continue with this PR, I can keep iterating here.

If they’d rather keep #2158 as the canonical PR, I can close this one and resubmit the relevant improvements in whatever form they prefer.

I understand the overlap with #2158 (DOM overlays). This PR is focused on stage-aligned UI controls and differs in a few key ways:

Stage + size as first-class primitives: controls are created with Scratch stage coordinates and width/height (x, y, w, h) directly.
Auto repositioning: elements stay aligned to the canvas under zoom/resize/fullscreen via a continuous reposition loop.
Generic interaction hats: when any UI changes and when UI [ID] changes, plus last ID / last value.
Additional controls: textarea, checkbox, and radio group.
State export helpers: all IDs (CSV) and all values (JSON).
If you’d still prefer consolidating into #2158, I’m happy to close this PR and submit these specific features on top of #2158 instead.

[Brackets-Coder]

See #2271. While there aren't specific guidelines, the unspoken rule is to let all duplicates have an equal chance of merging. We "prioritize" older pull requests, but all developer's opinions are equally valued. I'll mark this as a duplicate there, and I'd encourage you to collaborate on #2158 if you can and are willing.

[juanluber]

See #2271. While there aren't specific guidelines, the unspoken rule is to let all duplicates have an equal chance of merging. We "prioritize" older pull requests, but all developer's opinions are equally valued. I'll mark this as a duplicate there, and I'd encourage you to collaborate on #2158 if you can and are willing.

See #2271. While there aren't specific guidelines, the unspoken rule is to let all duplicates have an equal chance of merging. We "prioritize" older pull requests, but all developer's opinions are equally valued. I'll mark this as a duplicate there, and I'd encourage you to collaborate on #2158 if you can and are willing.

[juanluber]

@Brackets-Coder Thanks for the explanation! That makes sense.
I’m happy to close this PR as a duplicate and focus on contributing the relevant improvements to #2158 (stage-aligned x/y/w/h primitives, auto repositioning, generic change hats, extra controls, and state export helpers).
If there’s a preferred way to structure those contributions, please let me know.

[Brackets-Coder]

Don't feel obligated to close, but if @samllea1 wants to collaborate then go ahead