Chili Palmer
5a1a284505
Control-Menüs öffnen für alle Fensterarten am [≡]-Symbol des aktiven Fensters: eigener Auswahlzustand statt Kopplung an die Menüleiste, bevorzugt unter der Titelzeile, bei Platzmangel nach oben aufgeklappt, am rechten Rand nur so weit nach links wie nötig. Regressionstest über TestBackend für Code-, Projekt-, Output-, Immediate-, Debug- und Hilfefenster, maximiert, minimiert, Rand und Maus. Nebenbefunde der Windows-Testausführung: Temporärdatei vor sync_all schreibend öffnen (Zugriff verweigert), relative Projektverweise immer mit / schreiben, zeilenendenneutrale Vergleiche in Referenzmatrix-, Kompatibilitäts- und MAK-Beispieltests, DriveListBox-Zeichenbild plattformneutral. Korpus-Sollausgaben per .gitattributes auf LF. Specs ide-oberflaeche und ide-projekte synchronisiert, Change archiviert. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
65 lines
6.0 KiB
Markdown
65 lines
6.0 KiB
Markdown
# 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.
|