Wie der Titel schon beschreibt, werden es ziemlich sicher noch mehr Tabs. Wir müssten eine vernünftige Lösung ausarbeiten. Ich selbst verwende den Game Maker mit einer Auflösung von 1920x1080. Was das die e2e tests betrifft, könnte man den Testbrowser einfach auch größer machen. Dann haben wir längere Zeit eine Ruhe. andere billiger weg wäre: der Tab Buttons Bereich horizontal scrollbar.
Vielleicht gibt es noch eine elegantere Möglichkeit. lass uns das ausarbeiten.
Wie der Titel schon beschreibt, werden es ziemlich sicher noch mehr Tabs. Wir müssten eine vernünftige Lösung ausarbeiten. Ich selbst verwende den Game Maker mit einer Auflösung von 1920x1080. Was das die e2e tests betrifft, könnte man den Testbrowser einfach auch größer machen. Dann haben wir längere Zeit eine Ruhe. andere billiger weg wäre: der Tab Buttons Bereich horizontal scrollbar.
Vielleicht gibt es noch eine elegantere Möglichkeit. lass uns das ausarbeiten.
admin
added this to the Development project 2026-09-13 20:24:02 +02:00
admin
moved this to Next in Development on 2026-09-13 20:24:09 +02:00
Zuerst die Zahlen, die den Zuschnitt bestimmt haben
Gemessen, nicht geschaetzt:
Fenster
Mitte
Tab-Reihe
frei
1280 x 800 (e2e/CI)
670 px
631 px
35 px
1920 x 1080 (deine Aufloesung)
1310 px
631 px
675 px
Die Breiten je Tab: State machine 114, Animation 83, Container 81, Graph 74, Texture 64, Shader 61, Scene 53, Game 50, List 35.
Bei 1280 passt kein zehnter Tab mehr -- 35 px frei, und das ist exakt die Breite des
kuerzesten Namens im Bestand. Bei 1920 waeren es etwa neun weitere, dann dasselbe Problem.
Zu den beiden Wegen aus dem Issue
Testbrowser groesser machen kostet mehr, als es aussieht: die Wache 14b misst dann bei
1920 und meldet den Ueberlauf bei 1280 nicht mehr -- die App waere auf einem kleineren
Fenster kaputt, ohne dass es jemand merkt. Dazu haengen etliche e2e-Checks an Layoutmassen
(Graph-Fit, emptySpot, locate-Bounds); an der blossen Aenderung der Konsolenhoehe sind
seinerzeit sechs gekippt. Und es ist Aufschub, keine Loesung.
Horizontal scrollbar loest den Ueberlauf, aber ein Tab, der gerade ausgeschoben ist,
ist unauffindbar -- man muss wissen, dass es ihn gibt, und blind scrollen.
Gewaehlt wurde das Overflow-Menue.
Was gebaut ist
TabStrip (src/editor/TabStrip.ts) ersetzt die nackte HStack. Was nicht in die Spalte
passt, steht hinter einem >>-Knopf am Ende der Reihe und kommt als Menue, nach Namen; ein
Klick oeffnet den Tab und holt ihn in die Reihe. Der Tab, den man gerade bearbeitet, ist
immer sichtbar -- notfalls als einziger.
Die Regel selbst ist eine reine Funktion (tabRowLayout in tabRow.ts), also ohne
Browser pruefbar: laengster Praefix, der ins Budget passt, aktiver Tab hinten angehaengt
(die Reihenfolge bleibt, weil der Praefix vor ihm endet).
Damit braucht ein neuer Tab keine Platzrechnung mehr. Er braucht eine Zeile in TAB_ORDER, TAB_LABELS und panes -- alle drei Record<CentreTab, ...>, das Vergessen
ist ein Typfehler. Genau das war die Bitte im Titel.
Zwei Festlegungen, die ich selbst getroffen habe
Der >>-Knopf hat feste Breite (28 px), sonst gaebe es einen Kreis: die Zahl der
verdeckten Tabs bestimmt die Knopfbreite, die Knopfbreite den Platz, der Platz die Zahl.
Deshalb steht dort auch keine Zahl.
setActive() ruft selbst relayout() -- Widget.resize laeuft nur bei geaenderter
Groesse durch layout(), und beim Tabwechsel aendert sich nichts an der Groesse. Ohne das
bliebe ein aus dem Menue gewaehlter Tab verdeckt.
Geprueft, nicht behauptet
./check.sh
=== CHECK EXIT 0 ===, 892 Tests (+5), Log juenger als jede Quelle
e2e GM_STEPS=1-14
ALL PASSED -- 395 Checks (+5), gegen index-CQtVIlJQ.js
Angesehen
Screenshot der gequetschten Mitte (~172 px): Leiste zeigt Scene, Game, >> -- nichts ragt in den Inspector
Menue
die sieben Verdeckten werden namentlich angeboten; List gewaehlt -> tab: "list", Reihe ["scene","list"]
Gueltigkeit
Neubau nach der Gegenprobe ergibt wieder index-CQtVIlJQ.js, denselben Inhalts-Hash
Zwei Gegenproben, jede beisst an ihrer Stelle:
Regel ohne "aktiver Tab bleibt" -> genau die 2 Unit-Tests dazu fallen, 3 bleiben gruen.
Ueberlauf stumpf, neu gebaut -> der neue Check faellt mit 7 Tabs bis x=1140 bei
Spaltenrand ~680, also 460 px unter dem Inspector, und >> ist nicht auffindbar. Das ist
woertlich der alte Fehler aus CI-Run 5. Die uebrigen 377 bleiben gruen.
Zaehler 790 (785 + 5) in README und Wiki Development; die 785 misst CI-Lauf 29
(e0c459c), gegengelesen: ALL PASSED - 785 checks, Job succeeded.
Grenzen, die ich benenne
Bei 1280 aendert sich heute nichts -- es passt alles, der >> erscheint nie. Der Bau ist
eine Wache fuer den zehnten Tab und fuer schmale Fenster, kein sichtbares Feature.
Der Tab-Wechsel ueber Tastatur erreicht verdeckte Tabs nicht (sie sind visible: false,
fallen also aus dem Tab-Zyklus) -- der Weg dorthin ist der Knopf.
Die elegantere Moeglichkeit, nach der du gefragt hast
Es gibt sie, und sie ist nicht gebaut: die neun Tabs sind gar keine Gleichen. Scene und Game sind immer da, die anderen sieben editieren das, was gerade offen ist -- eine Textur,
eine Animation, ein Shader, ein Container, eine Liste. Ein Tab, der nichts zu zeigen hat, muss
nicht in der Leiste stehen. Das waere der Wechsel von "Tab = Werkzeug" zu "Tab = offenes
Dokument" (mit x, wie in einer IDE), und er skaliert mit beliebig vielen Tabs, weil die Zahl
dann von deiner Arbeit abhaengt, nicht vom Funktionsumfang. Preis: groesster Umbau, und er
aendert das gewohnte Verhalten (heute klickt man Texture und sieht die zuletzt gewaehlte).
Wenn du das willst, gehoert es in ein eigenes Issue -- das Overflow-Menue steht dem nicht im Weg.
Umgesetzt mit **Commit f83c568**, Wiki `aa47bdd`.
## Zuerst die Zahlen, die den Zuschnitt bestimmt haben
Gemessen, nicht geschaetzt:
| Fenster | Mitte | Tab-Reihe | frei |
|---|---|---|---|
| 1280 x 800 (e2e/CI) | 670 px | 631 px | **35 px** |
| 1920 x 1080 (deine Aufloesung) | 1310 px | 631 px | 675 px |
Die Breiten je Tab: `State machine` 114, `Animation` 83, `Container` 81, `Graph` 74,
`Texture` 64, `Shader` 61, `Scene` 53, `Game` 50, `List` 35.
**Bei 1280 passt kein zehnter Tab mehr** -- 35 px frei, und das ist exakt die Breite des
kuerzesten Namens im Bestand. Bei 1920 waeren es etwa neun weitere, dann dasselbe Problem.
## Zu den beiden Wegen aus dem Issue
**Testbrowser groesser machen** kostet mehr, als es aussieht: die Wache 14b misst dann bei
1920 und meldet den Ueberlauf bei 1280 nicht mehr -- die App waere auf einem kleineren
Fenster kaputt, ohne dass es jemand merkt. Dazu haengen etliche e2e-Checks an Layoutmassen
(Graph-Fit, `emptySpot`, `locate`-Bounds); an der blossen Aenderung der Konsolenhoehe sind
seinerzeit sechs gekippt. Und es ist Aufschub, keine Loesung.
**Horizontal scrollbar** loest den Ueberlauf, aber ein Tab, der gerade ausgeschoben ist,
ist unauffindbar -- man muss wissen, dass es ihn gibt, und blind scrollen.
Gewaehlt wurde das **Overflow-Menue**.
## Was gebaut ist
`TabStrip` (`src/editor/TabStrip.ts`) ersetzt die nackte `HStack`. Was nicht in die Spalte
passt, steht hinter einem `>>`-Knopf am Ende der Reihe und kommt als Menue, nach Namen; ein
Klick oeffnet den Tab **und holt ihn in die Reihe**. Der Tab, den man gerade bearbeitet, ist
immer sichtbar -- notfalls als einziger.
Die Regel selbst ist eine **reine Funktion** (`tabRowLayout` in `tabRow.ts`), also ohne
Browser pruefbar: laengster Praefix, der ins Budget passt, aktiver Tab hinten angehaengt
(die Reihenfolge bleibt, weil der Praefix vor ihm endet).
**Damit braucht ein neuer Tab keine Platzrechnung mehr.** Er braucht eine Zeile in
`TAB_ORDER`, `TAB_LABELS` und `panes` -- alle drei `Record<CentreTab, ...>`, das Vergessen
ist ein Typfehler. Genau das war die Bitte im Titel.
## Zwei Festlegungen, die ich selbst getroffen habe
- **Der `>>`-Knopf hat feste Breite (28 px)**, sonst gaebe es einen Kreis: die Zahl der
verdeckten Tabs bestimmt die Knopfbreite, die Knopfbreite den Platz, der Platz die Zahl.
Deshalb steht dort auch keine Zahl.
- **`setActive()` ruft selbst `relayout()`** -- `Widget.resize` laeuft nur bei geaenderter
Groesse durch `layout()`, und beim Tabwechsel aendert sich nichts an der Groesse. Ohne das
bliebe ein aus dem Menue gewaehlter Tab verdeckt.
## Geprueft, nicht behauptet
| | |
|---|---|
| `./check.sh` | `=== CHECK EXIT 0 ===`, **892 Tests** (+5), Log juenger als jede Quelle |
| e2e `GM_STEPS=1-14` | **ALL PASSED -- 395 Checks** (+5), gegen `index-CQtVIlJQ.js` |
| Angesehen | Screenshot der gequetschten Mitte (~172 px): Leiste zeigt `Scene`, `Game`, `>>` -- nichts ragt in den Inspector |
| Menue | die sieben Verdeckten werden namentlich angeboten; `List` gewaehlt -> `tab: "list"`, Reihe `["scene","list"]` |
| Gueltigkeit | Neubau nach der Gegenprobe ergibt wieder `index-CQtVIlJQ.js`, denselben Inhalts-Hash |
**Zwei Gegenproben, jede beisst an ihrer Stelle:**
- Regel ohne "aktiver Tab bleibt" -> genau die **2** Unit-Tests dazu fallen, 3 bleiben gruen.
- Ueberlauf stumpf, **neu gebaut** -> der neue Check faellt mit **7 Tabs bis x=1140 bei
Spaltenrand ~680**, also 460 px unter dem Inspector, und `>>` ist nicht auffindbar. Das ist
woertlich der alte Fehler aus CI-Run 5. Die uebrigen 377 bleiben gruen.
Zaehler **790** (785 + 5) in README und Wiki *Development*; die 785 misst CI-Lauf 29
(`e0c459c`), gegengelesen: `ALL PASSED - 785 checks`, `Job succeeded`.
## Grenzen, die ich benenne
- **Bei 1280 aendert sich heute nichts** -- es passt alles, der `>>` erscheint nie. Der Bau ist
eine Wache fuer den zehnten Tab und fuer schmale Fenster, kein sichtbares Feature.
- Der Tab-**Wechsel** ueber Tastatur erreicht verdeckte Tabs nicht (sie sind `visible: false`,
fallen also aus dem `Tab`-Zyklus) -- der Weg dorthin ist der Knopf.
## Die elegantere Moeglichkeit, nach der du gefragt hast
Es gibt sie, und sie ist **nicht** gebaut: die neun Tabs sind gar keine Gleichen. `Scene` und
`Game` sind immer da, die anderen sieben editieren *das, was gerade offen ist* -- eine Textur,
eine Animation, ein Shader, ein Container, eine Liste. Ein Tab, der nichts zu zeigen hat, muss
nicht in der Leiste stehen. Das waere der Wechsel von "Tab = Werkzeug" zu "Tab = offenes
Dokument" (mit x, wie in einer IDE), und er skaliert mit *beliebig* vielen Tabs, weil die Zahl
dann von deiner Arbeit abhaengt, nicht vom Funktionsumfang. Preis: groesster Umbau, und er
aendert das gewohnte Verhalten (heute klickt man `Texture` und sieht die zuletzt gewaehlte).
Wenn du das willst, gehoert es in ein eigenes Issue -- das Overflow-Menue steht dem nicht im Weg.
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.
Wie der Titel schon beschreibt, werden es ziemlich sicher noch mehr Tabs. Wir müssten eine vernünftige Lösung ausarbeiten. Ich selbst verwende den Game Maker mit einer Auflösung von 1920x1080. Was das die e2e tests betrifft, könnte man den Testbrowser einfach auch größer machen. Dann haben wir längere Zeit eine Ruhe. andere billiger weg wäre: der Tab Buttons Bereich horizontal scrollbar.
Vielleicht gibt es noch eine elegantere Möglichkeit. lass uns das ausarbeiten.
Umgesetzt mit Commit
f83c568, Wikiaa47bdd.Zuerst die Zahlen, die den Zuschnitt bestimmt haben
Gemessen, nicht geschaetzt:
Die Breiten je Tab:
State machine114,Animation83,Container81,Graph74,Texture64,Shader61,Scene53,Game50,List35.Bei 1280 passt kein zehnter Tab mehr -- 35 px frei, und das ist exakt die Breite des
kuerzesten Namens im Bestand. Bei 1920 waeren es etwa neun weitere, dann dasselbe Problem.
Zu den beiden Wegen aus dem Issue
Testbrowser groesser machen kostet mehr, als es aussieht: die Wache 14b misst dann bei
1920 und meldet den Ueberlauf bei 1280 nicht mehr -- die App waere auf einem kleineren
Fenster kaputt, ohne dass es jemand merkt. Dazu haengen etliche e2e-Checks an Layoutmassen
(Graph-Fit,
emptySpot,locate-Bounds); an der blossen Aenderung der Konsolenhoehe sindseinerzeit sechs gekippt. Und es ist Aufschub, keine Loesung.
Horizontal scrollbar loest den Ueberlauf, aber ein Tab, der gerade ausgeschoben ist,
ist unauffindbar -- man muss wissen, dass es ihn gibt, und blind scrollen.
Gewaehlt wurde das Overflow-Menue.
Was gebaut ist
TabStrip(src/editor/TabStrip.ts) ersetzt die nackteHStack. Was nicht in die Spaltepasst, steht hinter einem
>>-Knopf am Ende der Reihe und kommt als Menue, nach Namen; einKlick oeffnet den Tab und holt ihn in die Reihe. Der Tab, den man gerade bearbeitet, ist
immer sichtbar -- notfalls als einziger.
Die Regel selbst ist eine reine Funktion (
tabRowLayoutintabRow.ts), also ohneBrowser pruefbar: laengster Praefix, der ins Budget passt, aktiver Tab hinten angehaengt
(die Reihenfolge bleibt, weil der Praefix vor ihm endet).
Damit braucht ein neuer Tab keine Platzrechnung mehr. Er braucht eine Zeile in
TAB_ORDER,TAB_LABELSundpanes-- alle dreiRecord<CentreTab, ...>, das Vergessenist ein Typfehler. Genau das war die Bitte im Titel.
Zwei Festlegungen, die ich selbst getroffen habe
>>-Knopf hat feste Breite (28 px), sonst gaebe es einen Kreis: die Zahl derverdeckten Tabs bestimmt die Knopfbreite, die Knopfbreite den Platz, der Platz die Zahl.
Deshalb steht dort auch keine Zahl.
setActive()ruft selbstrelayout()--Widget.resizelaeuft nur bei geaenderterGroesse durch
layout(), und beim Tabwechsel aendert sich nichts an der Groesse. Ohne dasbliebe ein aus dem Menue gewaehlter Tab verdeckt.
Geprueft, nicht behauptet
./check.sh=== CHECK EXIT 0 ===, 892 Tests (+5), Log juenger als jede QuelleGM_STEPS=1-14index-CQtVIlJQ.jsScene,Game,>>-- nichts ragt in den InspectorListgewaehlt ->tab: "list", Reihe["scene","list"]index-CQtVIlJQ.js, denselben Inhalts-HashZwei Gegenproben, jede beisst an ihrer Stelle:
Spaltenrand ~680, also 460 px unter dem Inspector, und
>>ist nicht auffindbar. Das istwoertlich der alte Fehler aus CI-Run 5. Die uebrigen 377 bleiben gruen.
Zaehler 790 (785 + 5) in README und Wiki Development; die 785 misst CI-Lauf 29
(
e0c459c), gegengelesen:ALL PASSED - 785 checks,Job succeeded.Grenzen, die ich benenne
>>erscheint nie. Der Bau isteine Wache fuer den zehnten Tab und fuer schmale Fenster, kein sichtbares Feature.
visible: false,fallen also aus dem
Tab-Zyklus) -- der Weg dorthin ist der Knopf.Die elegantere Moeglichkeit, nach der du gefragt hast
Es gibt sie, und sie ist nicht gebaut: die neun Tabs sind gar keine Gleichen.
SceneundGamesind immer da, die anderen sieben editieren das, was gerade offen ist -- eine Textur,eine Animation, ein Shader, ein Container, eine Liste. Ein Tab, der nichts zu zeigen hat, muss
nicht in der Leiste stehen. Das waere der Wechsel von "Tab = Werkzeug" zu "Tab = offenes
Dokument" (mit x, wie in einer IDE), und er skaliert mit beliebig vielen Tabs, weil die Zahl
dann von deiner Arbeit abhaengt, nicht vom Funktionsumfang. Preis: groesster Umbau, und er
aendert das gewohnte Verhalten (heute klickt man
Textureund sieht die zuletzt gewaehlte).Wenn du das willst, gehoert es in ein eigenes Issue -- das Overflow-Menue steht dem nicht im Weg.