TerminalBasic/openspec/changes/archive/2026-09-08-phase-6-07a-fensterlokale-control-menues/evidence/befund-2026-09-08.md

Befund: Fenstermenü falsch positioniert und „File“ hervorgehoben

Datum: 08.09.2026, Validierung Phase 6 (Change 07), Windows Terminal / cmd.exe, target\debug\tb.

Beobachtung (Screenshot Run-Fenster)

• Aktives Fenster: Run-Fenster (Magenta-Titel), Position etwa Spalte 3, Zeile 6.
• Nach Öffnen des Fenstermenüs erscheint der Aufklappbereich (Restore, Move, Size, Minimize, Maximize, Close) in Zeile 1 direkt unter der Menüleiste, beginnend an der linken Fensterkante, und überdeckt den Titel des dahinterliegenden Codefensters.
• Gleichzeitig ist der Hauptmenüeintrag „File“ in der Menüleiste hervorgehoben, obwohl kein Menüleistenmenü geöffnet wurde.

Das Run-Fenster ist nur das Beispiel; der Fehler betrifft alle Fenster gleich, da Zustand und Renderpfad des Control-Menüs fensterartunabhängig sind.

Erwartung

• Aufklappbereich an das Symbol [≡] des aktiven Fensters angehängt: linke Spalte = Symbolspalte, bevorzugt unmittelbar unter der Titelzeile.
• Reicht der Platz unten nicht (z. B. minimiertes Fenster am unteren Rand), klappt das Menü nach oben und grenzt mit seiner Unterkante an die Titelzeile; es bleibt immer vollständig im Terminalbereich und sichtbar mit dem Fenster verbunden.
• Gleiche Regel für alle Fensterarten.
• Kein hervorgehobener Menüleistentitel.

Ursache im Code (Stand 6e742d9)

• crates/tb-ide/src/app.rs, Command::ControlMenu: setzt self.menu = Some((0, 0)) und damit den Menüleistenindex 0 („File“) als ausgewählt.
• crates/tb-ide/src/render.rs, Menüleiste: hebt den Titel i hervor, wenn self.menu == Some((i, _)); bei Control-Menü also „File“.
• crates/tb-ide/src/render.rs, Popup: Rect::new(x, 1, …) mit x = linke Fensterkante; die Zeile ist fest 1 statt Titelzeile des Fensters + 1.

Korrektur (08.09.2026)

• crates/tb-ide/src/app.rs: control_menu trägt jetzt die eigene Auswahl (Option<usize>); Command::ControlMenu setzt menu nicht mehr. Gemeinsame Eintragsnavigation über open_entries/select_open, menu_open() ersetzt alle „ein Menü ist offen“-Abfragen. Neue Platzierungsfunktion control_menu_rect für alle Fensterarten: linke Spalte = Symbolspalte, bevorzugt unter der Titelzeile, sonst nach oben aufgeklappt bis an die Titelzeile, rechts nur so weit nach links wie nötig.
• crates/tb-ide/src/render.rs: Popup zeichnet die offene Liste an der berechneten Position; Menüleiste hebt nur bei echter Menüleistenauswahl hervor.
• crates/tb-ide/tests/app.rs: control_menus_attach_to_the_symbol_of_every_window prüft Code-, Projekt-, Output- und Immediate-Fenster, maximiert, minimiert (klappt nach oben), an den rechten Rand verschoben (rückt nach links) sowie Mausklick auf [≡] und auf einen Eintrag; vor der Korrektur schlug der Test mit menu == Some((0, 0)) fehl.

Nebenbefund: Export-Tests unter Windows

Bei der Testausführung scheiterten auf unverändertem Stand 6e742d9 sechs Export-Tests (tb-export und tb-ide) mit „Zugriff verweigert (os error 5)“. Ursache in crates/tb-export/src/lib.rs, prepare_publication: Die Temporärdatei wurde nur lesend geöffnet und dann sync_all aufgerufen; Windows verlangt für FlushFileBuffers Schreibrechte. Korrektur: schreibend öffnen. Auf Linux war das Verhalten unauffällig, daher blieb es in den Gitea-Läufen unentdeckt. Für Change 07 (Aufgabe 2.2/2.4) bedeutet das: Windows-Zielprüfungen des Exports müssen mit dieser Korrektur wiederholt werden.

Nebenbefunde: Windows-Checkout mit CRLF und Pfadtrennern

Der vollständige Workspace-Lauf auf dem Windows-Prüfsystem (core.autocrlf=true) zeigte weitere plattformabhängige Fehler auf unverändertem Stand:

• crates/tb-cli/src/ide_acceptance.rs, Referenzmatrix: suchte #[test]\nfn …( in Quelldateien, die im Checkout CRLF tragen. Korrektur: Suche zeilenendenneutral.

• crates/tb-cli/tests/compat.rs: release-formular und isamopen verglichen CRLF-Sollausgaben direkt mit LF-Snapshots (die Hauptschleife normalisierte bereits, die beiden Einzeltests nicht). Korrektur: assert_output_matches und der isamopen-Vergleich normalisieren; .gitattributes erklärt tests/compat/*.out zu LF, wie der bestehende Kommentar es bereits behauptete.

• crates/tb-vm/tests/project_io.rs: suchte den Block ```mak\n in docs/dateiformate.md (CRLF im Checkout). Korrektur: zeilenendenneutral.

• crates/tb-vm/src/project_io.rs, relative_path: schrieb relative Projektverweise mit dem Plattformtrenner (..\lib.tbl), die drei save_as-Tests in crates/tb-ide/tests/documents.rs erwarten /. Unter Linux/macOS ist \ kein Trenner, ein unter Windows gespeichertes Projekt wäre dort nicht ladbar. Korrektur: Verweise werden immer mit / geschrieben; beide Plattformen lösen / beim Laden auf.

• crates/tb-ui/src/forms.rs, Zeichenbildtest: erwartete für die DriveListBox fest / ▼; die Implementierung zeigt absichtlich den Wurzeltrenner der Plattform (std::path::MAIN_SEPARATOR, unter Windows \). Korrektur: Test plattformneutral, docs/forms-referenz.md nennt beide Bilder.

Diese Befunde sind für Change 07 (Plattformmatrix, Aufgabe 2.2/2.4) relevant: Die Windows-Zielprüfung muss mit diesem Stand wiederholt werden. Der vollständige Workspace-Lauf unter Windows (cargo test --workspace --no-fail-fast) bestand nach den Korrekturen; die Zahlen stehen unten.

Testlauf Windows (08.09.2026, Arbeitsstand auf 6e742d9)

cargo fmt --all -- --check sauber, cargo clippy -p tb-ide --tests ohne Warnung.

Lauf	Testziele	bestanden	fehlgeschlagen	ignoriert
Vor den Nebenbefund-Korrekturen	42	636	12	4
cargo test --workspace --no-fail-fast, final	42	637	0	4

Manuelle Gegenprobe (08.09.2026)

Der Benutzer hat die Korrektur im realen Windows Terminal geprüft und als erfolgreich gemeldet: Control-Menüs öffnen fensterlokal am [≡]-Symbol des aktiven Fensters, die Menüleiste zeigt keinen ausgewählten Titel mehr.

Status

Behoben. Automatisiert und manuell nachgewiesen; Übergabe an Change 07 Aufgabe 2.3 als erledigter Fachbefund.