Ich hätte gerne die Möglichkeit gewisse Dinge umsortieren zu können. was mir einfällt:
variablen in eine behavior
darunter dann auch struct variablen
listen
start und end node ports
wie man sortieren kann ist noch die frage was am "einfachsten" ist. am liebsten wäre mir drag and drop
Ich hätte gerne die Möglichkeit gewisse Dinge umsortieren zu können. was mir einfällt:
- variablen in eine behavior
- darunter dann auch struct variablen
- listen
- start und end node ports
wie man sortieren kann ist noch die frage was am "einfachsten" ist. am liebsten wäre mir drag and drop
admin
added this to the Development project 2026-10-03 21:08:39 +02:00
admin
moved this to Next in Development on 2026-10-03 21:08:43 +02:00
Alle laufen durch drei Stellen im Code, je einmal für Inspector und Tab:
Was
Code
gilt auch für
Variablen eines Behaviors, darin Struct-Felder (beliebig tief)
buildVariables → variableRows.ts
Variables-Asset, Felder eines Struct-Assets, Variables-Tab
Ports von Start und End
buildPortSection (portSection.ts)
Felder von Pack/Expand, Ein-/Ausgänge einer Shader-Funktion
Einträge einer Liste
InlineList
Liste im Inspector, im Variables-Tab, verschachtelte Listen, platzierte Objekte
Drag-and-drop gibt es schon (ListView, SortableList in Hierarchy, Pixel Art, Vector Art, Tilemap). Beide können aber nur gleich hohe Zeilen. Die Inspector-Zeilen sind frei gestapelt, ein Struct ist z. B. eine Kopfzeile mit eingerückten Feldern darunter. Deshalb taugen die beiden hier nicht.
Bedienung: Drag-and-drop am Zeilenanfang
Angefasst wird am Zeichen vorne in der Zeile: bei Variablen, Feldern und Ports am Kind-Zeichen (#, Aa, Icon), bei Listen an der Nummer. Erst wenn der Zeiger mehr als 4 px wandert, wird daraus ein Ziehen. Ein Klick bleibt ein Klick, das Kind-Menü an einem Listen-Eintrag geht also weiter auf.
Es kommt keine neue Spalte dazu, sonst würde die Wertespalte im ganzen Inspector verrutschen.
Während des Ziehens wird der gezogene Block (eine Struct samt Feldern, ein Eintrag samt verschachtelter Liste) abgeblendet. Eine Linie in Akzentfarbe zeigt, wo er landet.
Verschoben wird nur unter Geschwistern: eine Variable zwischen Variablen, ein Feld innerhalb seiner Struct, ein Eintrag innerhalb seiner Liste. In eine andere Struct oder Liste hinein geht es nicht, denn das würde die Form des Werts ändern.
Jede Verschiebung ist ein Undo-Schritt.
Ohne doppelten Code
Eine reine RegeldropSlot(zeigerY, blöcke, von) → Zielindex, ohne Browser prüfbar. Die vorhandene dropIndex-Regel aus dem Tile-Tab kommt mit in dieselbe Datei.
Ein Helfer im UI-Toolkit, der eine Zeile als Griff markiert und eine Gruppe von Blöcken kennt: Er erkennt das Ziehen, zeichnet Linie und Abblendung und meldet am Ende (von, nach). Die drei Stellen geben ihm nur ihre Blöcke und eine Funktion zum Ausführen.
Je ein Command:
MoveVariableCommand(asset, key, nach, pfad) für Variablen und Struct-Felder (Pfad wie bei Rename/Remove). In einem Struct-Asset läuft er durch WithStructTypes. Der Abgleich schreibt Felder und Ports als Ganzes ab, die neue Reihenfolge kommt also von selbst an jeder Stelle dieses Typs an, auch an Pack/Expand.
MovePortCommand(asset, node, key, nach). Kanten hängen am Port-Namen und bleiben verbunden.
Listen brauchen keinen Command: InlineList ersetzt die Liste heute schon als Ganzes (access.replace), das gilt auch für Overrides an platzierten Objekten.
Was sich dadurch ändert
Variablen und Struct-Felder: nur die Reihenfolge im Inspector, in Menüs und Feldern von Pack/Expand. Werte hängen am Namen, in der Laufzeit ändert sich nichts.
Start/End-Ports: Die Reihenfolge der Ports an Start, End, Run behavior und On behavior ändert sich. Bestehende Verbindungen bleiben.
Listen: Die Reihenfolge der Einträge ist ein Wert. Item at mit Index 0 liefert danach den neuen ersten Eintrag.
Tests
Unit-Tests für dropSlot, beide Commands samt Undo und das Weitergeben über ein Struct-Asset.
Ein e2e-Check, der im Inspector mit der Maus eine Variable verschiebt, dazu eine Gegenprobe.
Deine Fragen und meine Vorschläge
„Listen“ verstehe ich als die Einträge einer Liste (Werte), nicht als die Felder des Item-Typs. Die stehen ohnehin im Struct-Asset und kommen dort über Punkt 1 mit.
Bei Ports gilt es für alle, die buildPortSection zeichnet, also auch für Pack/Expand-Felder und die Shader-Funktion. Das kostet nichts extra. Die gewählten Ports an Variables/Properties-Nodes würde ich weglassen, weil du danach nicht gefragt hast.
Am oberen oder unteren Rand scrollt der Inspector mit, damit man auch in langen Listen ans Ende kommt. Bei einer gekürzten Liste („… N more“) sortiert man im Inspector nur die sichtbaren Einträge, die ganze Liste im Tab.
Keine Pfeile ↑/↓ zusätzlich. Nur Drag-and-drop, wie du es dir gewünscht hast.
Wenn die Vorschläge für dich passen, sag Bescheid oder schreib es ins Issue, dann baue ich.
## Plan
### Wo die vier Dinge heute stehen
Alle laufen durch **drei Stellen im Code**, je einmal für Inspector und Tab:
| Was | Code | gilt auch für |
|---|---|---|
| Variablen eines Behaviors, darin Struct-Felder (beliebig tief) | `buildVariables` → `variableRows.ts` | Variables-Asset, Felder eines Struct-Assets, Variables-Tab |
| Ports von Start und End | `buildPortSection` (`portSection.ts`) | Felder von Pack/Expand, Ein-/Ausgänge einer Shader-Funktion |
| Einträge einer Liste | `InlineList` | Liste im Inspector, im Variables-Tab, verschachtelte Listen, platzierte Objekte |
Drag-and-drop gibt es schon (`ListView`, `SortableList` in Hierarchy, Pixel Art, Vector Art, Tilemap). Beide können aber nur gleich hohe Zeilen. Die Inspector-Zeilen sind frei gestapelt, ein Struct ist z. B. eine Kopfzeile mit eingerückten Feldern darunter. Deshalb taugen die beiden hier nicht.
### Bedienung: Drag-and-drop am Zeilenanfang
- **Angefasst wird am Zeichen vorne in der Zeile:** bei Variablen, Feldern und Ports am Kind-Zeichen (`#`, `Aa`, Icon), bei Listen an der Nummer. Erst wenn der Zeiger mehr als 4 px wandert, wird daraus ein Ziehen. Ein Klick bleibt ein Klick, das Kind-Menü an einem Listen-Eintrag geht also weiter auf.
- Es kommt **keine neue Spalte** dazu, sonst würde die Wertespalte im ganzen Inspector verrutschen.
- Während des Ziehens wird der gezogene Block (eine Struct samt Feldern, ein Eintrag samt verschachtelter Liste) abgeblendet. Eine Linie in Akzentfarbe zeigt, wo er landet.
- **Verschoben wird nur unter Geschwistern:** eine Variable zwischen Variablen, ein Feld innerhalb seiner Struct, ein Eintrag innerhalb seiner Liste. In eine andere Struct oder Liste hinein geht es nicht, denn das würde die Form des Werts ändern.
- Jede Verschiebung ist ein Undo-Schritt.
### Ohne doppelten Code
1. **Eine reine Regel** `dropSlot(zeigerY, blöcke, von)` → Zielindex, ohne Browser prüfbar. Die vorhandene `dropIndex`-Regel aus dem Tile-Tab kommt mit in dieselbe Datei.
2. **Ein Helfer im UI-Toolkit,** der eine Zeile als Griff markiert und eine Gruppe von Blöcken kennt: Er erkennt das Ziehen, zeichnet Linie und Abblendung und meldet am Ende `(von, nach)`. Die drei Stellen geben ihm nur ihre Blöcke und eine Funktion zum Ausführen.
3. **Je ein Command:**
- `MoveVariableCommand(asset, key, nach, pfad)` für Variablen und Struct-Felder (Pfad wie bei Rename/Remove). In einem Struct-Asset läuft er durch `WithStructTypes`. Der Abgleich schreibt Felder und Ports als Ganzes ab, die neue Reihenfolge kommt also von selbst an jeder Stelle dieses Typs an, auch an Pack/Expand.
- `MovePortCommand(asset, node, key, nach)`. Kanten hängen am Port-Namen und bleiben verbunden.
- Listen brauchen keinen Command: `InlineList` ersetzt die Liste heute schon als Ganzes (`access.replace`), das gilt auch für Overrides an platzierten Objekten.
### Was sich dadurch ändert
- **Variablen und Struct-Felder:** nur die Reihenfolge im Inspector, in Menüs und Feldern von Pack/Expand. Werte hängen am Namen, in der Laufzeit ändert sich nichts.
- **Start/End-Ports:** Die Reihenfolge der Ports an Start, End, `Run behavior` und `On behavior` ändert sich. Bestehende Verbindungen bleiben.
- **Listen:** Die Reihenfolge der Einträge ist ein Wert. `Item at` mit Index 0 liefert danach den neuen ersten Eintrag.
### Tests
- Unit-Tests für `dropSlot`, beide Commands samt Undo und das Weitergeben über ein Struct-Asset.
- Ein e2e-Check, der im Inspector mit der Maus eine Variable verschiebt, dazu eine Gegenprobe.
## Deine Fragen und meine Vorschläge
1. **„Listen“ verstehe ich als die Einträge einer Liste** (Werte), nicht als die Felder des Item-Typs. Die stehen ohnehin im Struct-Asset und kommen dort über Punkt 1 mit.
2. **Bei Ports gilt es für alle, die `buildPortSection` zeichnet**, also auch für Pack/Expand-Felder und die Shader-Funktion. Das kostet nichts extra. Die gewählten Ports an `Variables`/`Properties`-Nodes würde ich weglassen, weil du danach nicht gefragt hast.
3. **Am oberen oder unteren Rand scrollt der Inspector mit**, damit man auch in langen Listen ans Ende kommt. Bei einer gekürzten Liste („… N more“) sortiert man im Inspector nur die sichtbaren Einträge, die ganze Liste im Tab.
4. **Keine Pfeile ↑/↓ zusätzlich.** Nur Drag-and-drop, wie du es dir gewünscht hast.
Wenn die Vorschläge für dich passen, sag Bescheid oder schreib es ins Issue, dann baue ich.
Alle vier Dinge lassen sich jetzt per Drag-and-drop umsortieren, so wie im Plan:
Variablen eines Behaviors oder eines Variables-Assets, und Felder eines Struct-Assets
Struct-Felder in jeder Tiefe, jeweils innerhalb ihrer Struct
Einträge einer Liste, im Inspector und im Variables-Tab
Ports von Start und End, dazu die Felder von Pack/Expand und die Ein-/Ausgänge einer Shader-Funktion
Bedienung
Angefasst wird am Zeichen vorne in der Zeile (#, Aa, Icon), bei Listen an der Nummer. Erst ab 4 px Bewegung wird gezogen, ein Klick bleibt ein Klick.
Der gezogene Block (eine Struct samt Feldern, ein Eintrag samt verschachtelter Liste) wird abgeblendet. Eine Linie in Akzentfarbe zeigt, wo er landet.
Am oberen oder unteren Rand scrollt der Inspector mit.
Jede Verschiebung ist ein Undo-Schritt.
Was sich dadurch ändert
Werte und Verbindungen hängen am Namen, es ändert sich also nur die Reihenfolge.
Bei einem Struct-Asset kommt die neue Reihenfolge an jeder Stelle dieses Typs an: an Variablen, an Pack/Expand und an geteilten Ausgängen.
Die Reihenfolge der Ports an Start/End gilt auch an jedem Node, der das Behavior ausführt.
Bei Listen ist die Reihenfolge Teil des Werts: Item at mit Index 0 liefert danach den neuen ersten Eintrag.
Bewusst nicht dabei
Variablen an einem platzierten Objekt: Die Reihenfolge gehört dem Asset.
Felder einer Struct mit Typ: Die werden am Struct-Asset sortiert.
Die gewählten Ports an Variables- und Properties-Nodes (wie besprochen).
Tests
Gate: 235 Dateien, 3572 Tests, alle grün.
Unit-Tests für die Regeln (blockGap, dropSlot, …), die drei Commands samt Undo, das Weitergeben über ein Struct-Asset und die Port-Reihenfolge am aufrufenden Node.
e2e 22f-iii: Im Browser wird eine Variable über eine mehrzeilige Struct gezogen, dann ein Feld innerhalb der Struct, dann zweimal Undo. 39 Checks, alle grün.
Gegenproben greifen: Ohne Drag fallen die drei Reihenfolge-Checks im Browser.
Nicht im Browser angesehen: die Linie und das Abblenden während des Ziehens, das Mitscrollen am Rand, sowie Ports und Listen (die laufen über denselben Helfer).
## Umgesetzt in `2c19c89`
Alle vier Dinge lassen sich jetzt per **Drag-and-drop** umsortieren, so wie im Plan:
- **Variablen** eines Behaviors oder eines Variables-Assets, und **Felder** eines Struct-Assets
- **Struct-Felder** in jeder Tiefe, jeweils innerhalb ihrer Struct
- **Einträge einer Liste**, im Inspector und im Variables-Tab
- **Ports** von Start und End, dazu die Felder von Pack/Expand und die Ein-/Ausgänge einer Shader-Funktion
### Bedienung
- Angefasst wird am **Zeichen vorne in der Zeile** (`#`, `Aa`, Icon), bei Listen an der **Nummer**. Erst ab 4 px Bewegung wird gezogen, ein Klick bleibt ein Klick.
- Der gezogene Block (eine Struct samt Feldern, ein Eintrag samt verschachtelter Liste) wird abgeblendet. Eine Linie in Akzentfarbe zeigt, wo er landet.
- Am oberen oder unteren Rand scrollt der Inspector mit.
- Jede Verschiebung ist ein Undo-Schritt.
### Was sich dadurch ändert
- Werte und Verbindungen hängen am Namen, es ändert sich also nur die Reihenfolge.
- Bei einem **Struct-Asset** kommt die neue Reihenfolge an jeder Stelle dieses Typs an: an Variablen, an Pack/Expand und an geteilten Ausgängen.
- Die Reihenfolge der **Ports** an Start/End gilt auch an jedem Node, der das Behavior ausführt.
- Bei **Listen** ist die Reihenfolge Teil des Werts: `Item at` mit Index 0 liefert danach den neuen ersten Eintrag.
### Bewusst nicht dabei
- Variablen an einem **platzierten Objekt**: Die Reihenfolge gehört dem Asset.
- Felder einer Struct **mit Typ**: Die werden am Struct-Asset sortiert.
- Die gewählten Ports an `Variables`- und `Properties`-Nodes (wie besprochen).
### Tests
- Gate: 235 Dateien, 3572 Tests, alle grün.
- Unit-Tests für die Regeln (`blockGap`, `dropSlot`, …), die drei Commands samt Undo, das Weitergeben über ein Struct-Asset und die Port-Reihenfolge am aufrufenden Node.
- e2e 22f-iii: Im Browser wird eine Variable über eine mehrzeilige Struct gezogen, dann ein Feld innerhalb der Struct, dann zweimal Undo. 39 Checks, alle grün.
- Gegenproben greifen: Ohne Drag fallen die drei Reihenfolge-Checks im Browser.
- Nicht im Browser angesehen: die Linie und das Abblenden während des Ziehens, das Mitscrollen am Rand, sowie Ports und Listen (die laufen über denselben Helfer).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Ich hätte gerne die Möglichkeit gewisse Dinge umsortieren zu können. was mir einfällt:
wie man sortieren kann ist noch die frage was am "einfachsten" ist. am liebsten wäre mir drag and drop
Plan
Wo die vier Dinge heute stehen
Alle laufen durch drei Stellen im Code, je einmal für Inspector und Tab:
buildVariables→variableRows.tsbuildPortSection(portSection.ts)InlineListDrag-and-drop gibt es schon (
ListView,SortableListin Hierarchy, Pixel Art, Vector Art, Tilemap). Beide können aber nur gleich hohe Zeilen. Die Inspector-Zeilen sind frei gestapelt, ein Struct ist z. B. eine Kopfzeile mit eingerückten Feldern darunter. Deshalb taugen die beiden hier nicht.Bedienung: Drag-and-drop am Zeilenanfang
#,Aa, Icon), bei Listen an der Nummer. Erst wenn der Zeiger mehr als 4 px wandert, wird daraus ein Ziehen. Ein Klick bleibt ein Klick, das Kind-Menü an einem Listen-Eintrag geht also weiter auf.Ohne doppelten Code
dropSlot(zeigerY, blöcke, von)→ Zielindex, ohne Browser prüfbar. Die vorhandenedropIndex-Regel aus dem Tile-Tab kommt mit in dieselbe Datei.(von, nach). Die drei Stellen geben ihm nur ihre Blöcke und eine Funktion zum Ausführen.MoveVariableCommand(asset, key, nach, pfad)für Variablen und Struct-Felder (Pfad wie bei Rename/Remove). In einem Struct-Asset läuft er durchWithStructTypes. Der Abgleich schreibt Felder und Ports als Ganzes ab, die neue Reihenfolge kommt also von selbst an jeder Stelle dieses Typs an, auch an Pack/Expand.MovePortCommand(asset, node, key, nach). Kanten hängen am Port-Namen und bleiben verbunden.InlineListersetzt die Liste heute schon als Ganzes (access.replace), das gilt auch für Overrides an platzierten Objekten.Was sich dadurch ändert
Run behaviorundOn behaviorändert sich. Bestehende Verbindungen bleiben.Item atmit Index 0 liefert danach den neuen ersten Eintrag.Tests
dropSlot, beide Commands samt Undo und das Weitergeben über ein Struct-Asset.Deine Fragen und meine Vorschläge
buildPortSectionzeichnet, also auch für Pack/Expand-Felder und die Shader-Funktion. Das kostet nichts extra. Die gewählten Ports anVariables/Properties-Nodes würde ich weglassen, weil du danach nicht gefragt hast.Wenn die Vorschläge für dich passen, sag Bescheid oder schreib es ins Issue, dann baue ich.
Umgesetzt in
2c19c89Alle vier Dinge lassen sich jetzt per Drag-and-drop umsortieren, so wie im Plan:
Bedienung
#,Aa, Icon), bei Listen an der Nummer. Erst ab 4 px Bewegung wird gezogen, ein Klick bleibt ein Klick.Was sich dadurch ändert
Item atmit Index 0 liefert danach den neuen ersten Eintrag.Bewusst nicht dabei
Variables- undProperties-Nodes (wie besprochen).Tests
blockGap,dropSlot, …), die drei Commands samt Undo, das Weitergeben über ein Struct-Asset und die Port-Reihenfolge am aufrufenden Node.