Feature: a card changes an object's geometry, and it is saved

Problem

A card of an own component type that changes the object's geometry (an agent's prism with sliders for leg and height) solves again with retrace!, but the window keeps drawing the old shape: there is no public way to draw an object again
The changed parameters are not written to system.jl, which saves only the pose: the window then shows something else than the files, other participants and agents see the old size, and after a reload the change is gone
The page "Edit" rebuilds an object with new parameters, but only for objects from the catalog, whose constructor the GUI knows

Proposal

An own component type can tell the GUI how its constructor reads for its current state. When a card changes such a parameter, the window draws the object again and writes the new constructor into its line of system.jl, as the page "Edit" does for the catalog: with undo, claims and conflicts like any other change of the person.

Tasks

Changing the geometry of an own type on its card shows the new shape at once
The change is saved to its line of system.jl, and other windows and agents see it
Undo restores the old parameters and shape
A type that does not tell its constructor keeps today's behavior, and the card says that such changes are not saved

Notes

Needs a public way in BeamletOptics to draw an object again after its shape changed (Feature: an object is drawn again after its shape changed BeamletOptics.jl#222)
Related: Feature: own types of a project get their card #63 (cards of own types of a project)
Open question: how does a type state its constructor, and should the page "Edit" use the same for the catalog?

The BeamletOptics side of the first task is done: the PR for StackEnjoyer/BeamletOptics.jl#222 (branch feature/rerender-object) adds the exported verb rerender!. It reaches the GUI through its [sources] entry as soon as it is merged into BeamletOptics master.

What rerender! does

rerender!(oh) on the handle of an object draws the object again from its current shape, at its current pose. The handle stays the same object, in the same place among children of its system handle, so the tree of handles, the selection and picking keep working.
rerender!(h) on a system handle draws all its objects again. LiveSystemHandle gets this method from its children, so it needs no change.
On a beam handle, rerender! does the same as update_render!.
update_render! stays the call after a move: it only applies the pose and keeps the old mesh.

Use in a card that changes geometry

# The card has changed the shape of obj, e.g. the leg of a prism
rerender!(oh)            # oh: the object handle of obj; the new shape at the current pose
retrace!(...)            # as now, then update_render! of the beams

Undo works the same way: restore the old parameters, then call rerender!(oh) again.

Things to watch

rerender! replaces the plots of the handle. Attributes set on the old plots (selection highlight, visibility, clip planes) are not carried over: apply them again to render_plots(oh) afterwards, e.g. with the code of LiveSelection.jl.
The GUI calls no internal names of BeamletOptics for this, and no _rerender! is needed anymore.

Still open in this issue

Tasks 2–4: writing the changed parameters to system.jl, undo, and the behavior for types that do not state their constructor. The BeamletOptics change only draws the object again.
The open question of how a type states its constructor.

Own types of a project take part in the window (#66, #63, #65): the w…

Navigation Menu

Feature: a card changes an object's geometry, and it is saved #65

Problem

Proposal

Tasks

Notes

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Feature: a card changes an object's geometry, and it is saved #65

Description

Problem

Proposal

Tasks

Notes

Activity

StackEnjoyer commented on Nov 6, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions