Allow identifier change via direct edit in certain views #151

New issue

Open

opened 2026-06-08 20:04:17 +00:00 by glen · 2 comments

glen commented

2026-06-08 20:04:17 +00:00

Owner

We would like to allow direct change of id of an element via those views which are capable of displaying the ids of elements (such as the outline, and perhaps the graphical view when a (single?) element is selected -- although maybe it would make more sense when a single element is selected that the outline view simply scrolls to that element automagically, showing the element's information that way, rather than via anything else in/around the graphical view; then each view can concentrate on what it does well).

When a view is showing the id of an element, there are at least two possible different interfaces we might allow for changing said id:

Right-clicking on the element or perhaps just on its ID produces a context menu, one item of which is "Change ID," and selecting that menu item pops up a little ID dialogue.
(Any kind of?) clicking on the ID makes it look like a text entry box.

In either of the above two scenarios (there might be other possibilities we could contemplate), the actual identifier change comes down to typing into a text box. There are then at least a couple of ways that the identifier change could take place:

Enter to submit: You can type anything, but nothing happens unless/until you hit enter, at which point the identifier changes. This alternative would lead to some subsequent design decision as to whether at that point the text entry box auto-closes/defocuses, and as to the exact behavior if there had been some typing but then the text entry box is closed or unfocused (just silently cancels the operation, or warns and asks for confirmation, or...)
Close/change focus to submit: You can type anything, but nothing happens until you close or unfocus the text box, at which point the identifier changes. In this scenario, the "enter" key might just be a shortcut to close/unfocus the box.
"Live update": As you type, with each keystroke the id is changed to match what's currently in the box. In this scenario, closing or changing focus from the entry box has no further effect (perhaps unless the id shown is in conflict with a different element's ID, see #150)

My inclination is that "Enter to submit" is a less modern/currently comfortable option, leading to some inclination toward one of the other options. I don't know that "live update" is really necessary here, especially as it might happen that you traverse multiple in-use IDs (with the associated concerns about what happens when renaming to them) en route to the ID you desire. So "close/change focus to submit" might be the happy medium, although we can certainly discuss/consider other options not listed.

We would like to allow direct change of id of an element via those views which are capable of _displaying_ the ids of elements (such as the outline, and perhaps the graphical view when a (single?) element is selected -- although maybe it would make more sense when a single element is selected that the outline view simply scrolls to that element automagically, showing the element's information that way, rather than via anything else in/around the graphical view; then each view can concentrate on what it does well). When a view is showing the id of an element, there are at least two possible different interfaces we might allow for changing said id: * Right-clicking on the element or perhaps just on its ID produces a context menu, one item of which is "Change ID," and selecting that menu item pops up a little ID dialogue. * (Any kind of?) clicking on the ID makes it look like a text entry box. In either of the above two scenarios (there might be other possibilities we could contemplate), the actual identifier change comes down to typing into a text box. There are then at least a couple of ways that the identifier change could take place: * Enter to submit: You can type anything, but nothing happens unless/until you hit enter, at which point the identifier changes. This alternative would lead to some subsequent design decision as to whether at that point the text entry box auto-closes/defocuses, and as to the exact behavior if there had been some typing but then the text entry box is closed or unfocused (just silently cancels the operation, or warns and asks for confirmation, or...) * Close/change focus to submit: You can type anything, but nothing happens until you close or unfocus the text box, at which point the identifier changes. In this scenario, the "enter" key might just be a shortcut to close/unfocus the box. * "Live update": As you type, with each keystroke the id is changed to match what's currently in the box. In this scenario, closing or changing focus from the entry box has no further effect (perhaps unless the id shown is in conflict with a different element's ID, see #150) My inclination is that "Enter to submit" is a less modern/currently comfortable option, leading to some inclination toward one of the other options. I don't know that "live update" is really necessary here, especially as it might happen that you traverse multiple in-use IDs (with the associated concerns about what happens when renaming to them) en route to the ID you desire. So "close/change focus to submit" might be the happy medium, although we can certainly discuss/consider other options not listed.

glen added the

enhancement

label

2026-06-08 20:04:17 +00:00

glen added a new dependency

2026-06-08 20:05:32 +00:00

#150 Make it easy to reassign already-used identifiers

glen removed a dependency

2026-06-08 20:05:45 +00:00

#150 Make it easy to reassign already-used identifiers

glen added a new dependency

2026-06-08 20:05:57 +00:00

#150 Make it easy to reassign already-used identifiers

glen referenced this issue

2026-06-08 20:18:51 +00:00

Make it easy to reassign already-used identifiers #150

Vectornaut added the

label

2026-06-08 20:20:05 +00:00

Vectornaut commented

2026-06-08 20:28:29 +00:00

Member

One step toward implementing this could be to build a component that provides an editable view of an identifier with built-in collision handling, similarly to how the RegulatorInput component provides an editable view of a regulator with built-in validation.

One step toward implementing this could be to build a component that provides an editable view of an identifier with built-in collision handling, similarly to how the [`RegulatorInput`](https://code.studioinfinity.org/StudioInfinity/dyna3/src/commit/bbc76c27972df5887747e3c406fadb7e22fc3846/app-proto/src/components/outline.rs#L18-L87) component provides an editable view of a regulator with built-in validation.

glen commented

2026-06-08 20:48:40 +00:00

Author

Owner

@Vectornaut wrote in #151 (comment):

One step toward implementing this could be to build a component that provides an editable view of an identifier with built-in collision handling, similarly to how the RegulatorInput component provides an editable view of a regulator with built-in validation.

Indeed, and that step is presumably agnostic to the choice of where that component might appear (only in an outline view, sometimes "popped up" in the graphics view, etc.)

@Vectornaut wrote in https://code.studioinfinity.org/StudioInfinity/dyna3/issues/151#issuecomment-3937: > One step toward implementing this could be to build a component that provides an editable view of an identifier with built-in collision handling, similarly to how the [`RegulatorInput`](https://code.studioinfinity.org/StudioInfinity/dyna3/src/commit/bbc76c27972df5887747e3c406fadb7e22fc3846/app-proto/src/components/outline.rs#L18-L87) component provides an editable view of a regulator with built-in validation. Indeed, and that step is presumably agnostic to the choice of where that component might appear (only in an outline view, sometimes "popped up" in the graphics view, etc.)