Files
TerminalBasic/openspec/specs/ide-oberflaeche/spec.md

111 lines
11 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# ide-oberflaeche Specification
## Purpose
Definiert den bedienbaren Terminalrahmen der IDE mit zwei Arbeitsmodi, gemeinsamen Befehlen, Fenstern, Dialogen und beständigen Benutzereinstellungen.
## Requirements
### Requirement: Start und zwei Arbeitsmodi
Die IDE SHALL mit Versions-/Copyright-Begrüßung und anschließend einem leeren Projekt mit Codefenster „[1] Untitled“ und rechts angeordnetem Project Window starten. Programmierumgebung und Designer SHALL im selben Prozess arbeiten. Die Umgebung SHALL File/Edit/View/Search/Run/Debug/Options/Window und rechts Help zeigen; der Designer File/Edit/View/Tools/Options/Window/Help. Der Designer SHALL eine Properties Bar statt einer Statuszeile besitzen.
#### Scenario: Erster Start
- **WHEN** die IDE ohne Projekt gestartet wird
- **THEN** ist das leere Codefenster direkt bedienbar und das Project Window sichtbar; die Begrüßung blockiert keine Eingabe
### Requirement: Einheitliche Menü- und Befehlsbedienung
Alle Befehle aus docs/ide-referenz.md SHALL im jeweils beschriebenen Menü erscheinen. Alt oder F11 SHALL die Menüleiste aktivieren, Mnemonics auswählen und Esc abbrechen; mit „…“ bezeichnete Befehle SHALL einen Dialog öffnen. Menü, Kürzel und anklickbarer Statushinweis SHALL dieselbe Aktion auslösen. Kontextuell unzulässige Befehle SHALL deaktiviert und ihr Grund erkennbar sein.
#### Scenario: Modusabhängige Funktionstaste
- **WHEN** F10 im Designer und danach im pausierten Programmiermodus gedrückt wird
- **THEN** wechselt es im Designer zwischen Menü- und Properties Bar und löst im Programmiermodus den Prozedurschritt aus
#### Scenario: Vollständige Eingabeverteilung
- **WHEN** Ctrl+C im Editor, F11 zur Menüaktivierung und F12 im Formularkontext gedrückt werden
- **THEN** werden Kopieren, Menüaktivierung und Event Procedures ausgelöst, ohne als BASIC-Abbruch oder verlorene Taste behandelt zu werden
### Requirement: MDI-Fenster und Fokus
Fenster SHALL Titelleiste, Control-Menü, Rahmen und bei Bedarf Scrollbalken erhalten. New Window SHALL eine zusätzliche Ansicht erzeugen; Arrange All SHALL geöffnete Fenster kacheln. F6/Ctrl+F6, Shift+F6, Ctrl+F4, Ctrl+F7/F8/F9/F10/F5 und Alt+Minus SHALL Wechseln, Schließen, Verschieben, Skalieren, Minimieren, Maximieren, Wiederherstellen und Control-Menü bedienen. Die Window-Liste SHALL das aktive Codefenster markieren. Projektbuttons Form/Code und Enter SHALL die entsprechende Ansicht öffnen.
#### Scenario: Fenster wiederherstellen
- **WHEN** ein Codefenster verschoben, skaliert, minimiert, maximiert und wiederhergestellt wird
- **THEN** bleiben Dokument, Cursor und vorherige Normalgeometrie erhalten und alle Bedienelemente erreichbar
#### Scenario: Dialogfokus
- **WHEN** ein modaler Dialog geöffnet und anschließend abgebrochen wird
- **THEN** empfängt nur der Dialog die Eingaben und danach erhält das vorher aktive Fenster den Fokus zurück
### Requirement: Farben und Statusanzeige
Die IDE SHALL das anhand belegter VBDOS-Ansichten dokumentierte Farbschema aus docs/ide-referenz.md verwenden, insbesondere dunkelblaue Codefläche mit heller Schrift, weiße aktive Titel auf dunklem Magenta, graue Menüs und schwarze Statusschrift auf Cyan. Alle IDE-Farben SHALL als feste 24-Bit-RGB-Werte ausgegeben werden, unabhängig von TERM, COLORTERM, NO_COLOR und der ANSI-Palette. Ein Rückfall auf Index- oder Profilfarben MUST NOT erfolgen; die IDE MUST NOT die globale Terminalpalette verändern. Fensterflächen SHALL vor dem Zeichnen vorhandene Desktopzeichen und verdeckte Fensterinhalte löschen, sodass unbeschriebene Fläche und Texthintergrund dieselbe Farbe besitzen. Die Statuszeile SHALL kontextuelle klickbare Kürzel und Zeile/Spalte im Format 00001:001 zeigen. Display SHALL Vorder-/Hintergrund aus 16 Farben, Desktop-Füllzeichen und Tabweite ändern können. Bestehende gespeicherte Farbauswahlen SHALL gültig bleiben und MUST NOT stillschweigend überschrieben werden.
#### Scenario: Farben ändern
- **WHEN** der Benutzer Titelhintergrund, Desktopzeichen und Tabweite im Display-Dialog ändert
- **THEN** erscheinen die Änderungen in der IDE, während die Farbvorgaben des ausgeführten BASIC-Programms unverändert bleiben
#### Scenario: Abweichende ANSI-Palette
- **WHEN** die IDE mit Standardoptionen auf einem Terminal mit expliziter Farbausgabe und einer pastellfarbenen ANSI-Palette gestartet wird
- **THEN** bleiben Codefläche dunkelblau, Code lesbar und aktive Titel weiß auf dunklem Magenta; das Terminalprofil und die Farben nach Verlassen der IDE werden nicht verändert
#### Scenario: Bestehende Einstellungen laden
- **WHEN** eine vorhandene Optionsdatei mit angepassten DOS-Farbnummern geladen wird
- **THEN** bleiben die gewählten Nummern sowie alle weiteren Einstellungen erhalten und gelten über dieselbe definierte IDE-Farbabbildung
#### Scenario: Keine Farbfähigkeit gemeldet
- **WHEN** die IDE ohne COLORTERM, mit TERM=vt100 oder NO_COLOR=1 startet
- **THEN** gibt sie unverändert absolute RGB-Werte aus, insbesondere Codehintergrund #0000AA und Titelhintergrund #AA00AA
#### Scenario: Freie Fensterfläche
- **WHEN** der Desktop ein Füllzeichen enthält oder sich Fenster überdecken und im Editor Text eingegeben, markiert und die Auswahl aufgehoben wird
- **THEN** bleiben unbeschriebene Fensterzellen echte Leerzeichen in der jeweiligen Fensterfarbe ohne Desktopmuster oder verdeckte Inhalte
### Requirement: Beständige und validierte Optionen
Options SHALL Display, Set Paths, Right Mouse, Save und Syntax Checking anbieten. Syntax Checking SHALL anfangs aktiv sein. Rechtsklick SHALL konfigurierbar Kontext-Hilfe auslösen. Explizites Save SHALL die Optionen benutzerbezogen speichern; fehlerhafte oder unbekannte Konfiguration SHALL mit verständlicher Diagnose und benutzbaren Vorgaben behandelt werden.
#### Scenario: Neustart mit Optionen
- **WHEN** Optionen gespeichert und die IDE aus einem anderen Arbeitsverzeichnis neu gestartet wird
- **THEN** gelten die gespeicherten Werte weiterhin, ohne Projektdateien als Konfigurationsspeicher zu benutzen
### Requirement: Terminalgröße und Wiederherstellung
Die IDE SHALL die aktuelle Terminalfläche nutzen und auf Größenänderungen reagieren. Unter 80×25 SHALL ausschließlich ein Mindestgrößenhinweis erscheinen, ohne Dokumente oder Sitzung zu verlieren. Normaler Exit und Fehlerabbruch SHALL Terminalmodus und Cursor wiederherstellen.
#### Scenario: Verkleinern und zurück
- **WHEN** ein Terminal mit offenen Dokumenten unter 80×25 schrumpft und anschließend wieder wächst
- **THEN** kehrt die bedienbare Oberfläche mit erhaltenen Dokumenten und erreichbaren Fenstern zurück
### Requirement: Vollständige Exportdialoge mit getrennter Erzeugung
Run→Make EXE File und Run→Make Library SHALL bereits in Phase 5 bedienbare Dialoge für Artefaktart, Zielsystem/-architektur und Ausgabepfad öffnen. Mit Phase 6 SHALL die Ziele als natives eigenständiges Executable mit nativer Runtime in tbrt beziehungsweise portable P-Code-Bibliothek `.tbl` beschrieben sein. System-/Architekturwahl SHALL nur für EXE erforderlich sein; Make Library SHALL ohne native Zielvorlage verfügbar sein, sobald sein Backend vorhanden ist. Die Dialoge SHALL Eingaben prüfen, Überschreibkonflikte behandeln und Zustände für Erzeugung, Erfolg, Fehler und Abbruch darstellen können. Die tatsächliche Erzeugung SHALL erst mit dem Backend aus Phase 6 verfügbar sein; bis dahin SHALL nur die Erzeugungsaktion mit einem verständlichen Verfügbarkeitsgrund gesperrt sein. Die IDE MUST NOT einen Export vortäuschen oder ein bloßes TBC-Kompilat als natives Artefakt ausgeben.
#### Scenario: Dialoge vor dem Erzeugungsbackend
- **WHEN** beide Make-Befehle ohne verfügbares Erzeugungsbackend über Menü oder Tastatur geöffnet werden
- **THEN** lassen sich die zur Artefaktart passenden Angaben (EXE-Zielsystem/-architektur und Ausgabepfad, für TBL der Ausgabepfad) bearbeiten und validieren; die fehlende Erzeugung wird erklärt und keine Zieldatei geschrieben
#### Scenario: Fehlerhafte Ausgabeangaben
- **WHEN** ein leerer oder unzulässiger Ausgabepfad beziehungsweise ein bestehendes Ziel ohne Überschreibentscheidung angegeben wird
- **THEN** zeigt der Dialog den Eingabefehler oder die notwendige Entscheidung und behält die übrigen Angaben
#### Scenario: Ergebnisdarstellung über die vorbereitete Übergabe
- **WHEN** die Exportanbindung im Oberflächentest Erzeugung, Erfolg, Fehler und Abbruch mit demselben gültigen Auftrag zurückmeldet
- **THEN** zeigt die IDE jeweils den passenden Zustand mit Ziel beziehungsweise Diagnose und erhält die Projektdokumente; der Test behauptet keine tatsächliche native Dateierzeugung
#### Scenario: Verfügbares Erzeugungsbackend
- **WHEN** ein gültiger Auftrag bei verfügbarem Backend tatsächlich erfolgreich erzeugt wird
- **THEN** zeigt der Dialog den bestätigten Erfolg mit dem passenden EXE- oder TBL-Zielartefakt und erhält die Projektdokumente
### Requirement: Lesbare UI-Zustände
Im Standardtheme SHALL jedes dargestellte IDE-Text-/Hintergrundpaar mindestens 4,5:1 Kontrast nach sRGB-Relativluminanz besitzen, einschließlich Auswahl, Hilfelinks, Fehlermeldungen und deaktivierter Beschriftungen. Zur Bedienung notwendige nichttextuelle Fokus-/Rahmenmarkierungen SHALL gegenüber angrenzenden Flächen mindestens 3:1 erreichen. Aktive/inaktive, ausgewählte, deaktivierte und Debuggerzustände SHALL zusätzlich durch Rahmen, Zeichen oder Text erkennbar bleiben. Benutzerdefinierte Farbkombinationen und programmgesteuerte BASIC-Farben sind von den Standardtheme-Grenzwerten ausgenommen.
#### Scenario: Auswahl und Fensterwechsel
- **WHEN** Text markiert, zwischen Code und Projekt gewechselt und ein Menü oder Dialog geöffnet wird
- **THEN** bleiben Schrift und Fokus in allen beteiligten Zuständen lesbar; die Standardfarbpaare und erforderlichen Markierungen erfüllen die Kontrastgrenzen
#### Scenario: Hilfe, Debugger und Designer
- **WHEN** ein Hilfelink fokussiert, ein Breakpoint oder die aktuelle Ausführungszeile angezeigt und ein Designer-Control ausgewählt wird
- **THEN** bleiben Inhalt, jeweilige Markierung und Beschriftungen unterscheidbar und erfüllen die Standardtheme-Kontrastgrenzen
### Requirement: Belegter Theme-Abgleich
Der Theme-Abgleich SHALL nachvollziehbare VBDOS-Referenzfundstellen und zugeordnete IDE-Ansichten für Editor, aktive/inaktive Titel, Menüs, Projekt, Dialoge, Status, Hilfe und Designer dokumentieren. Nicht belegte Details SHALL als solche und bewusste Abweichungen für Kontrast als Anpassungen gekennzeichnet sein. Die reale Darstellung SHALL in der Plattformmatrix für Windows Terminal, Terminal.app sowie xterm und VTE auf beiden Linux-Architekturen mit Revision, Terminalversion und Farbprofil geprüft werden. Fehlende visuelle Nachweise MUST offen bleiben.
#### Scenario: Farbnummern stimmen, Darstellung weicht ab
- **WHEN** ein Render-Test die erwarteten Farbnummern liefert, der reale Terminalnachweis aber blasse oder unlesbare Standardfarben zeigt
- **THEN** bleibt der Theme-Befund offen, bis Ursache, Korrektur beziehungsweise belegte Terminalgrenze und erneute betroffene Abnahme dokumentiert sind