Phase 6: VBDOS-Theme umsetzen und Change 05a archivieren
This commit is contained in:
18
PLAN.md
18
PLAN.md
@@ -504,6 +504,17 @@ Unter Linux werden weiterhin mindestens zwei Emulatoren geprüft.
|
||||
Change 03 liefert Backend/CLI, das gemeinsame TBL-Testartefakt und die lokal
|
||||
verifizierte Verbraucherprobe; die vollständige Vierzielabnahme folgt in
|
||||
05/06 und die abschließende Phasenabnahme in 07.
|
||||
Zusätzlicher Politur-Change `phase-6-05a-vbdos-theme-und-kontrast`:
|
||||
VBDOS-Referenzabgleich und verlässliche IDE-Farbabbildung einschließlich
|
||||
Kontrast aller UI-Zustände. Umsetzung nach 04, vor der abschließenden
|
||||
visuellen Plattformabnahme in 05; Releasefreigabe 06 und Phasenabschluss 07
|
||||
setzen dessen bestandene Nachweise voraus. 05 kann seine übrigen Prüfpfade
|
||||
parallel vorbereiten. Die historische Gesamtübersicht bleibt erhalten;
|
||||
diese Ergänzung erweitert die Umsetzung auf acht Changes (01–07 plus 05a).
|
||||
05a ist am 07.09.2026 auf Benutzeranweisung mit lokal verifizierter
|
||||
Implementierung archiviert; seine drei offenen visuellen Nachweise werden
|
||||
in 05 weitergeführt und bleiben Voraussetzung der Phasenabnahme.
|
||||
|
||||
Release-Pakete: Windows als `.7z`, macOS und beide Linux-Architekturen
|
||||
als `.tar.gz`, jeweils mit `tb`, `tbc` und der passenden `tbrt`-Vorlage
|
||||
(Windows jeweils `.exe`) samt benötigten Metadaten.
|
||||
@@ -526,6 +537,13 @@ Gesamtproposal und Abhängigkeiten:
|
||||
inkl. systematischem Maus-/Sondertasten-Test (F1–F12, Alt-Kombis;
|
||||
aus Phase 0 übernommen) und Dokumentation bekannter
|
||||
Terminal-Einschränkungen
|
||||
- [ ] **VBDOS-nahes IDE-Theme und Kontrast:** Referenzansichten belegen,
|
||||
dunkelblaue Codefläche und nachvollziehbare Titelfarben verlässlich
|
||||
darstellen; alle Standardtexte mindestens 4,5:1, notwendige
|
||||
nichttextuelle Fokusmarkierungen mindestens 3:1. Auswahl, inaktive
|
||||
und deaktivierte Elemente, Menüs/Dialoge, Hilfe, Debugger und Designer
|
||||
prüfen; Benutzerfarben erhalten. Reale Theme-Nachweise in der
|
||||
Plattformmatrix, keine Abnahme allein anhand von ANSI-Farbnummern.
|
||||
- [ ] Performance-Pass über die VM (nur falls nötig)
|
||||
- [ ] **Native Standalone-Executables:** `tbc build --exe` und IDE →
|
||||
Make EXE File erzeugen ein direkt vom Zielsystem ausführbares,
|
||||
|
||||
@@ -7,12 +7,7 @@ use crate::{
|
||||
};
|
||||
use anyhow::{anyhow, ensure, Result};
|
||||
use crossterm::event::{KeyCode as K, KeyEvent, KeyModifiers as M};
|
||||
use ratatui::{
|
||||
layout::Rect,
|
||||
style::{Color, Style},
|
||||
widgets::Paragraph,
|
||||
Frame,
|
||||
};
|
||||
use ratatui::{layout::Rect, widgets::Paragraph, Frame};
|
||||
use tb_frontend::{Diagnostic, SourcePos};
|
||||
use tb_vm::interp::{DebugLocation, DebugWatch, Vm};
|
||||
|
||||
@@ -682,8 +677,7 @@ impl App {
|
||||
}
|
||||
}
|
||||
f.render_widget(
|
||||
Paragraph::new(lines.join("\n"))
|
||||
.style(Style::default().fg(Color::White).bg(Color::Blue)),
|
||||
Paragraph::new(lines.join("\n")).style(crate::render::pair(15, 1)),
|
||||
r,
|
||||
);
|
||||
if kind == WindowKind::Immediate && r.height > 4 {
|
||||
|
||||
@@ -1702,7 +1702,7 @@ impl App {
|
||||
let r = Rect::new(area.x + timers * 4, area.bottom().saturating_sub(1), 3, 1);
|
||||
timers += 1;
|
||||
f.render_widget(
|
||||
Paragraph::new("[T]").style(Style::default().fg(crate::render::dos(14))),
|
||||
Paragraph::new("[T]").style(crate::render::pair(0, 14)),
|
||||
r.intersection(area),
|
||||
);
|
||||
r
|
||||
@@ -1749,7 +1749,7 @@ impl App {
|
||||
(r.right() - 1, r.y + r.height / 2),
|
||||
] {
|
||||
f.render_widget(
|
||||
Paragraph::new("■").style(Style::default().fg(crate::render::dos(14))),
|
||||
Paragraph::new("■").style(crate::render::pair(0, 14)),
|
||||
Rect::new(x, y, 1, 1),
|
||||
);
|
||||
}
|
||||
@@ -1789,9 +1789,15 @@ impl App {
|
||||
if !r.is_empty() {
|
||||
f.render_widget(
|
||||
Paragraph::new(format!("{n:X} ")).style(
|
||||
Style::default()
|
||||
.bg(crate::render::dos(n as u8))
|
||||
.fg(crate::render::dos(if n < 8 { 15 } else { 0 })),
|
||||
Style::default().bg(crate::render::dos(n as u8)).fg(
|
||||
crate::render::dos(
|
||||
if matches!(n, 0 | 1 | 4 | 5 | 6 | 8 | 9) {
|
||||
15
|
||||
} else {
|
||||
0
|
||||
},
|
||||
),
|
||||
),
|
||||
),
|
||||
r,
|
||||
);
|
||||
|
||||
@@ -8,7 +8,7 @@ use crossterm::event::{KeyCode as K, KeyEvent, KeyModifiers as M};
|
||||
use pulldown_cmark::{Event, Options, Parser, Tag, TagEnd};
|
||||
use ratatui::{
|
||||
layout::Rect,
|
||||
style::{Color, Modifier, Style},
|
||||
style::{Modifier, Style},
|
||||
text::{Line, Span},
|
||||
widgets::Paragraph,
|
||||
Frame,
|
||||
@@ -165,7 +165,7 @@ impl Page {
|
||||
style = style.add_modifier(Modifier::ITALIC);
|
||||
}
|
||||
if heading.is_some() {
|
||||
style = style.fg(Color::Yellow);
|
||||
style = style.fg(crate::render::dos(1));
|
||||
}
|
||||
match event {
|
||||
Event::Start(Tag::Heading { level, .. }) => {
|
||||
@@ -864,7 +864,7 @@ impl App {
|
||||
let start = self.help.row(&rows);
|
||||
f.render_widget(
|
||||
Paragraph::new(format!("{} · Suche: {}", page.title, self.help.input))
|
||||
.style(Style::default().fg(Color::Yellow)),
|
||||
.style(Style::default().fg(crate::render::dos(1))),
|
||||
Rect::new(area.x, area.y, area.width, 1),
|
||||
);
|
||||
for (y, row) in rows
|
||||
@@ -887,9 +887,11 @@ impl App {
|
||||
if x >= shift && end <= shift + area.width as usize {
|
||||
let mut style = g.style;
|
||||
if let Some(link) = g.link {
|
||||
style = style.fg(Color::Cyan).add_modifier(Modifier::UNDERLINED);
|
||||
style = style
|
||||
.fg(crate::render::dos(1))
|
||||
.add_modifier(Modifier::UNDERLINED);
|
||||
if self.help.position.link == Some(link) {
|
||||
style = style.bg(Color::Blue).fg(Color::White);
|
||||
style = style.bg(crate::render::dos(1)).fg(crate::render::dos(15));
|
||||
}
|
||||
}
|
||||
if let Some(last) = spans.last_mut().filter(|s| s.style == style) {
|
||||
|
||||
@@ -11,7 +11,55 @@ use ratatui::{
|
||||
};
|
||||
use unicode_width::{UnicodeWidthChar, UnicodeWidthStr};
|
||||
|
||||
/// DOS-Farben der IDE. Die ersten 16 ANSI-Einträge gehören dem Terminalprofil.
|
||||
/// BASIC-Ausgabe verwendet weiterhin ihre eigene Farbabbildung in tb-ui.
|
||||
pub fn dos(n: u8) -> Color {
|
||||
static COLORS: std::sync::OnceLock<u16> = std::sync::OnceLock::new();
|
||||
dos_color(
|
||||
n,
|
||||
*COLORS.get_or_init(|| {
|
||||
let detected = crossterm::style::available_color_count();
|
||||
// Ein generisches COLORTERM (z.B. "yes") verdeckt bei crossterm TERM.
|
||||
if detected < 256 && std::env::var("TERM").is_ok_and(|s| s.contains("256")) {
|
||||
256
|
||||
} else {
|
||||
detected
|
||||
}
|
||||
}),
|
||||
)
|
||||
}
|
||||
|
||||
pub fn dos_color(n: u8, colors: u16) -> Color {
|
||||
let n = n.min(15) as usize;
|
||||
const RGB: [(u8, u8, u8); 16] = [
|
||||
(0, 0, 0),
|
||||
(0, 0, 170),
|
||||
(0, 170, 0),
|
||||
(0, 170, 170),
|
||||
(170, 0, 0),
|
||||
(170, 0, 170),
|
||||
(170, 85, 0),
|
||||
(170, 170, 170),
|
||||
(85, 85, 85),
|
||||
(85, 85, 255),
|
||||
(85, 255, 85),
|
||||
(85, 255, 255),
|
||||
(255, 85, 85),
|
||||
(255, 85, 255),
|
||||
(255, 255, 85),
|
||||
(255, 255, 255),
|
||||
];
|
||||
if colors > 256 {
|
||||
let (r, g, b) = RGB[n];
|
||||
Color::Rgb(r, g, b)
|
||||
} else if colors >= 256 {
|
||||
// Fester 6x6x6-Farbwürfel / Graurampe statt profilabhängiger Systemfarben.
|
||||
Color::Indexed(
|
||||
[
|
||||
16, 19, 34, 37, 124, 127, 130, 248, 240, 63, 83, 87, 203, 207, 227, 231,
|
||||
][n],
|
||||
)
|
||||
} else {
|
||||
[
|
||||
Color::Black,
|
||||
Color::Blue,
|
||||
@@ -29,11 +77,16 @@ pub fn dos(n: u8) -> Color {
|
||||
Color::LightMagenta,
|
||||
Color::LightYellow,
|
||||
Color::White,
|
||||
][n.min(15) as usize]
|
||||
][n]
|
||||
}
|
||||
}
|
||||
|
||||
pub(crate) fn pair(fg: u8, bg: u8) -> Style {
|
||||
Style::default().fg(dos(fg)).bg(dos(bg))
|
||||
}
|
||||
fn style(app: &App, element: usize) -> Style {
|
||||
let (fg, bg) = app.options.colors[element];
|
||||
Style::default().fg(dos(fg)).bg(dos(bg))
|
||||
pair(fg, bg)
|
||||
}
|
||||
fn put(f: &mut Frame, area: Rect, text: impl Into<String>, style: Style) {
|
||||
f.render_widget(Paragraph::new(text.into()).style(style), area);
|
||||
@@ -72,7 +125,7 @@ impl App {
|
||||
f,
|
||||
area,
|
||||
"Terminal Basic benötigt mindestens 80×25 Zellen.",
|
||||
Style::default(),
|
||||
pair(7, 0),
|
||||
);
|
||||
return;
|
||||
}
|
||||
@@ -101,6 +154,8 @@ impl App {
|
||||
self,
|
||||
if matches!(w.kind, WindowKind::Code(_)) {
|
||||
2
|
||||
} else if w.kind == WindowKind::Toolbox {
|
||||
6
|
||||
} else {
|
||||
5
|
||||
},
|
||||
@@ -108,6 +163,11 @@ impl App {
|
||||
f.render_widget(
|
||||
Block::default()
|
||||
.borders(Borders::ALL)
|
||||
.border_type(if active {
|
||||
ratatui::widgets::BorderType::Double
|
||||
} else {
|
||||
ratatui::widgets::BorderType::Plain
|
||||
})
|
||||
.style(content_style)
|
||||
.border_style(style(self, 4)),
|
||||
rect,
|
||||
@@ -240,7 +300,7 @@ impl App {
|
||||
1,
|
||||
),
|
||||
if mark.bound { "●" } else { "○" },
|
||||
Style::default().fg(Color::Red),
|
||||
pair(15, 4),
|
||||
);
|
||||
}
|
||||
}
|
||||
@@ -290,7 +350,7 @@ impl App {
|
||||
1,
|
||||
),
|
||||
mark,
|
||||
Style::default().fg(Color::Yellow),
|
||||
pair(0, 14),
|
||||
);
|
||||
}
|
||||
}
|
||||
@@ -358,12 +418,12 @@ impl App {
|
||||
Paragraph::new(text)
|
||||
.block(
|
||||
Block::bordered()
|
||||
.border_type(ratatui::widgets::BorderType::Double)
|
||||
.border_style(if active {
|
||||
Style::default().fg(Color::White)
|
||||
.border_type(if active {
|
||||
ratatui::widgets::BorderType::Double
|
||||
} else {
|
||||
style(self, 4)
|
||||
}),
|
||||
ratatui::widgets::BorderType::Plain
|
||||
})
|
||||
.border_style(style(self, 4)),
|
||||
)
|
||||
.style(content_style),
|
||||
r,
|
||||
@@ -396,7 +456,7 @@ impl App {
|
||||
r,
|
||||
text,
|
||||
if row == self.selected_member {
|
||||
Style::default().fg(Color::White).bg(Color::Black)
|
||||
pair(15, 0)
|
||||
} else {
|
||||
content_style
|
||||
},
|
||||
@@ -474,13 +534,13 @@ impl App {
|
||||
f,
|
||||
Rect::new(0, 0, area.width - width, 1),
|
||||
left,
|
||||
style(self, 0),
|
||||
style(self, 6),
|
||||
);
|
||||
put(
|
||||
f,
|
||||
Rect::new(area.width - width, 0, width, 1),
|
||||
geometry,
|
||||
style(self, 0),
|
||||
style(self, 6),
|
||||
);
|
||||
self.hits.push((
|
||||
Rect::new(0, 0, area.width / 2, 1),
|
||||
@@ -508,14 +568,14 @@ impl App {
|
||||
Span::raw(" "),
|
||||
Span::styled(
|
||||
&m.title[..1],
|
||||
style(self, 0).add_modifier(Modifier::UNDERLINED),
|
||||
Style::default().add_modifier(Modifier::UNDERLINED),
|
||||
),
|
||||
Span::raw(format!("{} ", &m.title[1..])),
|
||||
];
|
||||
f.render_widget(
|
||||
Paragraph::new(Line::from(spans)).style(
|
||||
if self.menu.is_some_and(|(n, _)| n == i) {
|
||||
Style::default().fg(Color::White).bg(Color::Black)
|
||||
pair(15, 0)
|
||||
} else {
|
||||
style(self, 0)
|
||||
},
|
||||
@@ -551,14 +611,16 @@ impl App {
|
||||
for (i, (text, c)) in entries.iter().enumerate().skip(start).take(visible) {
|
||||
let disabled = c.and_then(|c| self.availability(c));
|
||||
let st = if disabled.is_some() {
|
||||
Style::default().fg(Color::DarkGray).bg(Color::Gray)
|
||||
pair(0, 7).add_modifier(Modifier::ITALIC)
|
||||
} else if i == selected {
|
||||
Style::default().fg(Color::White).bg(Color::Black)
|
||||
pair(15, 0)
|
||||
} else {
|
||||
style(self, 0)
|
||||
};
|
||||
let r = Rect::new(x + 1, 2 + (i - start) as u16, width - 2, 1);
|
||||
let label = if *c == Some(Command::SyntaxChecking) && self.options.syntax_checking {
|
||||
let label = if disabled.is_some() {
|
||||
format!("× {text}")
|
||||
} else if *c == Some(Command::SyntaxChecking) && self.options.syntax_checking {
|
||||
format!("• {text}")
|
||||
} else {
|
||||
text.clone()
|
||||
@@ -605,7 +667,13 @@ impl App {
|
||||
);
|
||||
let st = style(self, 5);
|
||||
f.render_widget(Clear, rect);
|
||||
f.render_widget(Block::bordered().title(d.title.clone()).style(st), rect);
|
||||
f.render_widget(Block::bordered().style(st), rect);
|
||||
put(
|
||||
f,
|
||||
Rect::new(rect.x, rect.y, rect.width, 1),
|
||||
d.title.clone(),
|
||||
style(self, 3),
|
||||
);
|
||||
let visible = height.saturating_sub(7) as usize;
|
||||
let start = d
|
||||
.focus
|
||||
@@ -626,11 +694,7 @@ impl App {
|
||||
};
|
||||
let label = format!("{}: {}", field.label, value);
|
||||
let selected = d.focus == i;
|
||||
let field_style = if selected {
|
||||
Style::default().fg(Color::White).bg(Color::Black)
|
||||
} else {
|
||||
st
|
||||
};
|
||||
let field_style = if selected { pair(15, 0) } else { st };
|
||||
let caret = if let FieldValue::Text(text) = &field.value {
|
||||
field.label.width() + 2 + text[..field.cursor].width()
|
||||
} else {
|
||||
@@ -671,7 +735,7 @@ impl App {
|
||||
"[OK / Enter]"
|
||||
},
|
||||
if d.focus == d.fields.len() {
|
||||
Style::default().fg(Color::White).bg(Color::Black)
|
||||
pair(15, 0)
|
||||
} else {
|
||||
st
|
||||
},
|
||||
@@ -684,7 +748,7 @@ impl App {
|
||||
f,
|
||||
Rect::new(rect.x + 36, rect.bottom() - 3, width - 38, 1),
|
||||
"[Erzeugen: Phase 6]",
|
||||
Style::default().fg(Color::DarkGray).bg(Color::Gray),
|
||||
pair(0, 7).add_modifier(Modifier::ITALIC),
|
||||
);
|
||||
}
|
||||
let mut status = d.error.clone();
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
use crossterm::event::{
|
||||
Event, KeyCode as K, KeyEvent, KeyModifiers as M, MouseButton, MouseEvent, MouseEventKind,
|
||||
};
|
||||
use ratatui::{backend::TestBackend, style::Color, Terminal};
|
||||
use ratatui::{backend::TestBackend, Terminal};
|
||||
use std::{
|
||||
fs,
|
||||
path::PathBuf,
|
||||
@@ -105,11 +105,11 @@ fn start_snapshot_and_reference_menus_have_all_commands() {
|
||||
&& text.contains("Copyright")
|
||||
&& text.contains("00001:001")
|
||||
);
|
||||
assert_eq!(b[(4, 1)].bg, Color::Magenta);
|
||||
assert_eq!(b[(4, 1)].fg, Color::White);
|
||||
assert_eq!(b[(4, 2)].bg, Color::Blue);
|
||||
assert_eq!(b[(1, 29)].bg, Color::Cyan);
|
||||
assert_eq!(b[(1, 0)].bg, Color::Gray);
|
||||
assert_eq!(b[(4, 1)].bg, tb_ide::render::dos(5));
|
||||
assert_eq!(b[(4, 1)].fg, tb_ide::render::dos(15));
|
||||
assert_eq!(b[(4, 2)].bg, tb_ide::render::dos(1));
|
||||
assert_eq!(b[(1, 29)].bg, tb_ide::render::dos(3));
|
||||
assert_eq!(b[(1, 0)].bg, tb_ide::render::dos(7));
|
||||
plain(&mut app, K::Char('x'));
|
||||
assert_eq!(
|
||||
app.project
|
||||
@@ -663,7 +663,7 @@ fn options_apply_persist_across_bases_and_preserve_unsaved_values_on_error() {
|
||||
plain(&mut app, K::Enter);
|
||||
assert!(app.dialog.is_none());
|
||||
let (_, b) = draw(&mut app);
|
||||
assert_eq!(b[(4, 1)].bg, Color::Yellow);
|
||||
assert_eq!(b[(4, 1)].bg, tb_ide::render::dos(6));
|
||||
assert_eq!(app.options.tab_width, 4);
|
||||
let include = t.0.join("includes");
|
||||
fs::create_dir(&include).unwrap();
|
||||
@@ -924,3 +924,228 @@ fn finalization_failure_is_reported_and_preserves_existing_output() {
|
||||
.to_string_lossy()
|
||||
.starts_with(".tb-export-")));
|
||||
}
|
||||
|
||||
// Prüft tatsächlich gerenderte Zellen, einschließlich geerbter Hintergründe.
|
||||
fn theme_rgb(color: ratatui::style::Color) -> (u8, u8, u8) {
|
||||
use ratatui::style::Color;
|
||||
match color {
|
||||
Color::Rgb(r, g, b) => (r, g, b),
|
||||
Color::Indexed(n @ 16..=231) => {
|
||||
let n = n - 16;
|
||||
let channel = |v: u8| if v == 0 { 0 } else { 55 + v * 40 };
|
||||
(channel(n / 36), channel(n / 6 % 6), channel(n % 6))
|
||||
}
|
||||
Color::Indexed(n @ 232..=255) => {
|
||||
let v = 8 + (n - 232) * 10;
|
||||
(v, v, v)
|
||||
}
|
||||
_ => {
|
||||
let n = (0..16)
|
||||
.find(|n| tb_ide::render::dos_color(*n, 16) == color)
|
||||
.unwrap_or_else(|| panic!("Unbestimmte IDE-Farbe: {color:?}"));
|
||||
theme_rgb(tb_ide::render::dos_color(n, u16::MAX))
|
||||
}
|
||||
}
|
||||
}
|
||||
fn theme_contrast(fg: ratatui::style::Color, bg: ratatui::style::Color) -> f64 {
|
||||
let luminance = |color| {
|
||||
let (r, g, b) = theme_rgb(color);
|
||||
let linear = |v: u8| {
|
||||
let v = f64::from(v) / 255.0;
|
||||
if v <= 0.04045 {
|
||||
v / 12.92
|
||||
} else {
|
||||
((v + 0.055) / 1.055).powf(2.4)
|
||||
}
|
||||
};
|
||||
0.2126 * linear(r) + 0.7152 * linear(g) + 0.0722 * linear(b)
|
||||
};
|
||||
let (a, b) = (luminance(fg), luminance(bg));
|
||||
(a.max(b) + 0.05) / (a.min(b) + 0.05)
|
||||
}
|
||||
fn assert_theme(app: &mut App, context: &str) {
|
||||
let (_, b) = draw(app);
|
||||
for (i, c) in b.content.iter().enumerate() {
|
||||
if !c.symbol().trim().is_empty() {
|
||||
let ratio = theme_contrast(c.fg, c.bg);
|
||||
assert!(
|
||||
ratio >= 4.5,
|
||||
"{context} ({},{}): {:?} {:?}/{:?}: {ratio:.2}:1",
|
||||
i % app.size.0 as usize,
|
||||
i / app.size.0 as usize,
|
||||
c.symbol(),
|
||||
c.fg,
|
||||
c.bg
|
||||
);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn theme_contrast_covers_rendered_states_and_rejects_bad_pairs() {
|
||||
use tb_ide::render::dos_color;
|
||||
for colors in [256, u16::MAX] {
|
||||
for (fg, bg) in tb_ide::options::Options::default().colors {
|
||||
assert!(theme_contrast(dos_color(fg, colors), dos_color(bg, colors)) >= 4.5);
|
||||
}
|
||||
assert!(theme_contrast(dos_color(15, colors), dos_color(7, colors)) < 4.5);
|
||||
for n in 0..16 {
|
||||
let fg = if matches!(n, 0 | 1 | 4 | 5 | 6 | 8 | 9) {
|
||||
15
|
||||
} else {
|
||||
0
|
||||
};
|
||||
assert!(
|
||||
theme_contrast(dos_color(fg, colors), dos_color(n, colors)) >= 4.5,
|
||||
"Palettenbeschriftung {n}"
|
||||
);
|
||||
}
|
||||
}
|
||||
let t = Temp::new();
|
||||
let mut app = t.app();
|
||||
app.options.syntax_checking = false;
|
||||
type_text(&mut app, "PRINT 42");
|
||||
assert_theme(&mut app, "Editor");
|
||||
key(&mut app, K::Char('a'), M::CONTROL);
|
||||
assert_theme(&mut app, "Textauswahl");
|
||||
for m in 0..app.menus().len() {
|
||||
for i in 0..app.menu_entries(m).len() {
|
||||
app.menu = Some((m, i));
|
||||
assert_theme(&mut app, "Menü einschließlich deaktivierter Einträge");
|
||||
}
|
||||
}
|
||||
app.menu = None;
|
||||
for command in [
|
||||
Command::Display,
|
||||
Command::Paths,
|
||||
Command::MakeExe,
|
||||
Command::MakeLibrary,
|
||||
Command::Find,
|
||||
Command::Replace,
|
||||
Command::About,
|
||||
] {
|
||||
app.execute(command);
|
||||
assert_theme(&mut app, "Dialog");
|
||||
if let Some(d) = &mut app.dialog {
|
||||
d.error = "Prüffehler: ungültiger Wert".into();
|
||||
}
|
||||
assert_theme(&mut app, "Dialogfehler");
|
||||
app.dialog = None;
|
||||
}
|
||||
for command in [
|
||||
Command::Project,
|
||||
Command::Debug,
|
||||
Command::Calls,
|
||||
Command::HelpContents,
|
||||
Command::Keyboard,
|
||||
Command::UsingHelp,
|
||||
] {
|
||||
app.execute(command);
|
||||
assert_theme(&mut app, "Projekt/Debugger/Hilfe");
|
||||
plain(&mut app, K::Tab);
|
||||
assert_theme(&mut app, "Fokus/Link");
|
||||
}
|
||||
let path = t.0.join("debug-colors.bas");
|
||||
fs::write(&path, "x%=1\nx%=2\nPRINT x%\nEND\n").unwrap();
|
||||
let mut debugger = t.app();
|
||||
debugger.load_initial_project(path).unwrap();
|
||||
plain(&mut debugger, K::Down);
|
||||
debugger.execute(Command::Breakpoint);
|
||||
assert_theme(&mut debugger, "Ungebundener Breakpoint");
|
||||
debugger.execute(Command::Start);
|
||||
for _ in 0..30 {
|
||||
debugger.tick_execution(0);
|
||||
if debugger.execution == tb_ide::app::Execution::Paused {
|
||||
break;
|
||||
}
|
||||
}
|
||||
assert_eq!(debugger.execution, tb_ide::app::Execution::Paused);
|
||||
assert_theme(&mut debugger, "Gebundener Breakpoint und Ausführungszeile");
|
||||
let (_, marks) = draw(&mut debugger);
|
||||
assert!(marks
|
||||
.content
|
||||
.iter()
|
||||
.any(|c| c.symbol() == "▶" && c.bg == tb_ide::render::dos(14)));
|
||||
// Ein absichtlich schlechtes Standardpaar muss auch die Zellprüfung brechen.
|
||||
let mut bad = t.app();
|
||||
bad.options.colors[3] = (15, 7);
|
||||
assert!(
|
||||
std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| assert_theme(
|
||||
&mut bad,
|
||||
"Negativprobe"
|
||||
)))
|
||||
.is_err()
|
||||
);
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn theme_color_commands_use_explicit_values_and_never_modify_terminal_palette() {
|
||||
crossterm::style::force_color_output(true);
|
||||
use ratatui::{
|
||||
backend::{Backend, CrosstermBackend},
|
||||
buffer::Cell,
|
||||
style::Color,
|
||||
};
|
||||
use tb_ide::render::dos_color;
|
||||
assert_eq!(dos_color(1, u16::MAX), Color::Rgb(0, 0, 170));
|
||||
assert_eq!(dos_color(5, u16::MAX), Color::Rgb(170, 0, 170));
|
||||
assert_eq!(dos_color(6, u16::MAX), Color::Rgb(170, 85, 0));
|
||||
for colors in [16, 256, u16::MAX] {
|
||||
for n in 0..16 {
|
||||
let color = dos_color(n, colors);
|
||||
if let Color::Indexed(index) = color {
|
||||
assert!(index >= 16);
|
||||
}
|
||||
let mut cell = Cell::default();
|
||||
cell.set_symbol("X")
|
||||
.set_bg(color)
|
||||
.set_fg(dos_color(15, colors));
|
||||
let mut output = Vec::new();
|
||||
CrosstermBackend::new(&mut output)
|
||||
.draw(std::iter::once((0, 0, &cell)))
|
||||
.unwrap();
|
||||
let sequence = String::from_utf8(output).unwrap();
|
||||
assert!(sequence.contains('X'));
|
||||
if colors >= 256 {
|
||||
assert!(sequence.contains("48;"));
|
||||
}
|
||||
if colors > 256 {
|
||||
assert!(sequence.contains("48;2;"));
|
||||
}
|
||||
assert!(!sequence.contains("\x1b]")); // Keine globale Palettenänderung.
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn theme_designer_chrome_and_handles_preserve_program_palette() {
|
||||
let t = Temp::new();
|
||||
let mut app = t.app();
|
||||
app.execute(Command::NewForm);
|
||||
let root = app.design_objects().unwrap()[0].0;
|
||||
app.design_select(root, false).unwrap();
|
||||
let (_, b) = draw(&mut app);
|
||||
let handles: Vec<_> = b.content.iter().filter(|c| c.symbol() == "■").collect();
|
||||
assert!(!handles.is_empty());
|
||||
for c in handles {
|
||||
assert_eq!(
|
||||
(c.fg, c.bg),
|
||||
(tb_ide::render::dos(0), tb_ide::render::dos(14))
|
||||
);
|
||||
assert!(theme_contrast(c.fg, c.bg) >= 4.5);
|
||||
}
|
||||
let form = app.design_form().unwrap().clone();
|
||||
let (_, screen) = tb_ide::designer::preview(&form, (100, 30)).unwrap();
|
||||
let mut buf = ratatui::buffer::Buffer::empty(ratatui::layout::Rect::new(0, 0, 100, 30));
|
||||
ratatui::widgets::Widget::render(tb_ui::screen::ScreenWidget(&screen), buf.area, &mut buf);
|
||||
for (i, c) in buf.content.iter().enumerate() {
|
||||
let original = screen.cell(i / 100 + 1, i % 100 + 1);
|
||||
assert_eq!(c.bg, tb_ui::screen::basic_color(original.bg));
|
||||
}
|
||||
// Vorschau minimieren: ab hier gehören alle sichtbaren Zellen zur IDE.
|
||||
app.execute(Command::Minimize);
|
||||
for command in [Command::Toolbox, Command::Palette, Command::MenuDesign] {
|
||||
app.execute(command);
|
||||
assert_theme(&mut app, "Designer-Werkzeug");
|
||||
}
|
||||
}
|
||||
|
||||
@@ -3,7 +3,8 @@
|
||||
Rekonstruierte UX-Spezifikation der IDE des Vorbilds (VBDOS 1.0, 1992) —
|
||||
Grundlage für `tb-ide` (Phase 5). Quellen: Original-Hilfedatei (dekodiert),
|
||||
README des Originalpakets, Screenshots (Pixelanalyse), Sekundärliteratur.
|
||||
Konfidenz je Abschnitt vermerkt; `TODO` = offen.
|
||||
Konfidenz je Abschnitt vermerkt; `TODO` = offen. Konkrete Farbquellen und
|
||||
Kontrastanpassungen: siehe Abschnitt 4a.
|
||||
|
||||
Die IDE besteht im Vorbild aus zwei Programmen: der **Programmierumgebung**
|
||||
und dem separaten **Form Designer** (eigene Menüleiste, Wechsel über
|
||||
@@ -99,6 +100,106 @@ Alles über **Options→Display** je „User-Interface Element" umkonfigurierbar
|
||||
(Fore-/Background aus 16 Farben, Desktop-Füllzeichen, Tabweite).
|
||||
Laufzeit-Defaults kompilierter Programme weichen ab (Titel Weiß auf Schwarz).
|
||||
|
||||
## 4a. Farbabbildung und Kontrast (Phase 6)
|
||||
|
||||
Die DOS-Farbnummern in Options→Display bleiben erhalten. Die IDE verwendet
|
||||
bei `COLORTERM=truecolor`/`24bit` explizite RGB-Werte der klassischen
|
||||
16-Farben-Palette; bei `TERM=…256color` feste Einträge im Farbwürfel und der
|
||||
Graurampe außerhalb der ersten 16 ANSI-Farben. Ein generisches `COLORTERM`
|
||||
verdeckt diese 256-Farben-Erkennung nicht. Auf Windows verwendet die IDE
|
||||
zusätzlich die ANSI-Fähigkeitserkennung des vorhandenen Terminaladapters.
|
||||
Die Erkennung erfolgt einmal pro Prozess; nach Profiländerungen neu starten.
|
||||
|
||||
Damit hängt das Standardtheme bei expliziter Farbausgabe nicht von einer
|
||||
pastellfarbenen ANSI-Palette ab. Beispielwerte: Codehintergrund `#0000AA`,
|
||||
Codeschrift `#AAAAAA`, aktiver Titel `#FFFFFF` auf `#AA00AA`. DOS-Farbe 6
|
||||
ist Braun (`#AA5500`), nicht das frei konfigurierte ANSI-Gelb. Der
|
||||
256-Farben-Fallback nähert diese Werte an (`#0000AF`, `#A8A8A8`, `#AF00AF`).
|
||||
Die globale Terminalpalette wird nicht verändert. Unbekannte beziehungsweise
|
||||
reine 16-Farb-Terminals verwenden weiterhin die ANSI-Zuordnung; dort ist ein
|
||||
geeignetes Terminalprofil nötig. `NO_COLOR`, Transparenz, Farbfilter und
|
||||
Inaktivitätsdimmung des Emulators können die Darstellung zusätzlich verändern;
|
||||
die IDE überschreibt solche Benutzereinstellungen nicht.
|
||||
|
||||
### Referenzfundstellen
|
||||
|
||||
Die folgenden Originalprogramm-Ansichten wurden am 07.09.2026 visuell
|
||||
abgeglichen; die Beschreibung des Archivs ist keine Quelle für die genaue
|
||||
Palette. Ansichten belegen Flächen und Rollen, keine heutige Terminalausgabe.
|
||||
|
||||
- [Code View: Code, Run-Menü, Projekt und Status](https://winworldpc.com/screenshot/c39439e2-80a2-c692-222e-11c3a4e284a2/207ae280-a231-57c3-b111-c3a4c2a90f70)
|
||||
- [Form View: Designer, Properties, Werkzeuge und Palette](https://winworldpc.com/screenshot/c39439e2-80a2-c692-222e-11c3a4e284a2/1865c3a7-0957-c3b1-11c3-a4c2a90f7054)
|
||||
- [About: Dialog, aktiver Titel und Fokusrahmen](https://winworldpc.com/screenshot/c39439e2-80a2-c692-222e-11c3a4e284a2/0de2809a-6fc3-b757-c3b1-11c3a4c2a90f)
|
||||
|
||||
| Rolle | Beobachtung im Vorbild | Terminal Basic / Anpassung |
|
||||
|---|---|---|
|
||||
| Code | Helle Schrift auf dunklem Blau | DOS 7 auf 1; Auswahl invertiert dasselbe Paar |
|
||||
| Aktiver Titel / Dialogtitel | Weiß auf Magenta | DOS 15 auf 5; dunkles Magenta, kein Pastellrosa |
|
||||
| Inaktives Projekt / Rahmen | Schwarz auf Grau | DOS 0 auf 7; aktive Fenster zusätzlich mit Doppelrahmen |
|
||||
| Menü, Projekt, Dialog | Schwarz auf Grau; Auswahl hell auf Schwarz | DOS 0 auf 7, Auswahl 15 auf 0 |
|
||||
| Status | Schwarz auf Cyan | DOS 0 auf 3 |
|
||||
| Designer-Werkzeuge | Schwarz auf Cyan | DOS 0 auf 3 |
|
||||
| Properties Bar | Helle Schrift auf Cyan | Bewusste Kontrastanpassung: Schwarz auf Cyan |
|
||||
| Fokusrahmen und Sizing Handles | Teilweise Weiß auf Grau | Schwarzer Doppelrahmen; schwarze Handle-Zeichen auf Gelb |
|
||||
| Deaktivierte Beschriftungen | Nicht ausreichend durch diese Ansichten belegt | Lesbares Schwarz auf Grau, Menüs zusätzlich `×` und kursiv |
|
||||
| Hilfe und Debuggermarkierungen | In diesen Ansichten nicht belegt | Dunkelblaue Hilfetitel/Links auf Grau; Fokus Weiß auf Blau; Breakpoints Weiß auf Rot, Ausführungszeile Schwarz auf Gelb |
|
||||
|
||||
Die Standardpaare müssen bei RGB- und 256-Farben-Ausgabe mindestens 4,5:1
|
||||
Textkontrast erreichen; notwendige nichttextuelle Fokusmarkierungen mindestens
|
||||
3:1. Die Zelltests prüfen auch Rahmen und Handles auf mindestens 4,5:1
|
||||
gegen ihren eigenen Hintergrund. Benutzerauswahl in Display bleibt frei;
|
||||
bestehende Optionsdateien werden nicht umgeschrieben. BASIC-Ausgabe und
|
||||
Formularvorschau behalten ihre programmbestimmten Farbattribute, während
|
||||
Designer-Werkzeuge und Handles die IDE-Farben verwenden.
|
||||
|
||||
Die sRGB-Kontrastberechnung ergibt für die wichtigsten Standardpaare:
|
||||
|
||||
| Rolle | RGB | 256 Farben |
|
||||
|---|---|---|
|
||||
| Code / Hilfelink | 5,72:1 | 5,45:1 |
|
||||
| Aktiver Titel | 6,38:1 | 6,10:1 |
|
||||
| Menü / Dialog / deaktivierter Text | 9,04:1 | 8,83:1 |
|
||||
| Status / Werkzeuge | 7,33:1 | 7,75:1 |
|
||||
| Auswahl | 21,00:1 | 21,00:1 |
|
||||
| Linkfokus / Debugger | 13,29:1 | 12,97:1 |
|
||||
| Breakpoint | 7,75:1 | 7,44:1 |
|
||||
| Ausführung / Handle | 19,69:1 | 19,72:1 |
|
||||
|
||||
### Prüffolge für Change 05
|
||||
|
||||
Je Pflichtzelle Windows amd64/Windows Terminal, macOS arm64/Terminal.app,
|
||||
Linux amd64/xterm, Linux amd64/VTE, Linux arm64/xterm und Linux arm64/VTE:
|
||||
|
||||
1. Revision und Executable-Prüfsumme, OS-/Terminalversion, Profil,
|
||||
`TERM`/`COLORTERM`, `NO_COLOR`, Transparenz und Dimmung protokollieren.
|
||||
Mit einem frischen Optionsverzeichnis sowie einer Kopie der vorhandenen
|
||||
Optionen prüfen; echte Benutzeroptionen dabei erhalten.
|
||||
2. `tests/compat/datarohtext.bas` öffnen. Unmarkierten Editor und Ctrl+A-Auswahl
|
||||
erfassen, anschließend mit F6 ins Projekt wechseln. Erwartet: dunkles
|
||||
Blau, lesbare Auswahl, unterscheidbare aktive/inaktive Rahmen und Titel.
|
||||
3. Run-Menü einschließlich deaktiviertem Eintrag, Options→Display und einen
|
||||
Exportdialog mit ungültiger Eingabe öffnen. Erwartet: lesbare Mnemonics,
|
||||
Fokusfelder, deaktivierte Texte und Fehlerhinweise.
|
||||
4. F1-Hilfe öffnen, mit Tab einen Link fokussieren. F9-Breakpoint setzen und
|
||||
mit F5 bis zum Halt laufen. Erwartet: lesbare Überschriften und Links,
|
||||
sichtbare Breakpoint-/Ausführungsmarkierungen.
|
||||
5. Neue Form anlegen, Toolbox und Palette öffnen, Control auswählen und
|
||||
Größe ändern. Erwartet: cyanfarbene Werkzeuge/Properties, lesbare 16
|
||||
Farbbeschriftungen und Handles; ForeColor/BackColor der Vorschau bleiben
|
||||
unabhängig vom IDE-Theme.
|
||||
6. Dieselben Ansichten mit absichtlich abweichender ANSI-Palette prüfen.
|
||||
RGB-/256-Farben der IDE müssen stabil bleiben. Transparenz und
|
||||
Inaktivitätsdimmung getrennt ein-/ausschalten und Abweichungen als
|
||||
Emulatorverhalten dokumentieren. Für 16-Farb-Fallback das tatsächlich
|
||||
geeignete Profil und verbleibende Unterschiede festhalten.
|
||||
7. Options ändern, speichern und neu starten; Auswahl muss erhalten sein.
|
||||
IDE beenden: globale Palette und normale Shell-Anzeige müssen erhalten sein.
|
||||
|
||||
Pro Schritt Soll/Ist, Bild-/Transkriptbezug und gegebenenfalls Befund führen.
|
||||
Headless-Zelltests ersetzen diese visuellen Zielnachweise nicht. Die
|
||||
vollständige Matrix ist noch offen; die Originalansichten oben sind keine
|
||||
bestandenen TerminalBasic-Zielprüfungen.
|
||||
|
||||
## 5. Editor-Verhalten (Konfidenz: sicher; Keyword-Großschreibung: wahrscheinlich)
|
||||
|
||||
- **Syntax Checking** (Toggle, Standard an): beim Verlassen der Zeile wird
|
||||
|
||||
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-09-07
|
||||
@@ -0,0 +1,31 @@
|
||||
## Context
|
||||
|
||||
`Options::default` enthält bereits Code (7,1), aktiven Titel (15,5), Menü/Dialog (0,7) und Status (0,3). `render::dos` übersetzt diese Werte in benannte ANSI-Farben; `help.rs`, `debugger.rs` und Teile von `render.rs` setzen zusätzlich direkte Farben. Die konkrete Darstellung hängt daher vom Terminalprofil ab. Der Screenshot „Bildschirmfoto 2026-09-07 at 17.04.25.png“ zeigt das Problem, beweist aber weder das verwendete Profil noch die Ursache jeder einzelnen blassen Fläche. Auch Auswahl, gespeicherte Optionen, Transparenz und Inaktivitätsdimmung sind zu prüfen.
|
||||
|
||||
`docs/ide-referenz.md`, Abschnitt 4, nennt Weiß auf Magenta ausdrücklich als VBDOS-Merkmal. Diese Sekundärrekonstruktion ist der Ausgangspunkt; ihre Originalfundstellen sind bei der Umsetzung nachvollziehbar zu belegen. Ein Austausch gegen eine beliebige moderne Palette wäre kein Referenzabgleich.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:** Definierte IDE-Farbwerte, VBDOS-nahe Flächen und Kontrast in allen interaktiven Zuständen mit wenigen Änderungen an vorhandenen Renderpfaden.
|
||||
|
||||
**Non-Goals:** Theme-Framework, neue Theme-Auswahl, globale Terminalpalette verändern, automatische Umfärbung von BASIC-Programmen, Emulatorinstallation, Änderungen an Build-/Exportarchitektur.
|
||||
|
||||
## Decisions
|
||||
|
||||
1. Die bestehenden sieben konfigurierbaren Elemente und DOS-Farbnummern erhalten. Die vorhandene zentrale IDE-Abbildung um explizite RGB-Werte der dokumentierten DOS-Palette ergänzen; sämtliche direkten IDE-Farbzuweisungen und geerbten Hintergrundfarben prüfen und auf dieselbe Abbildung führen. Keine zweite Palette pro Fenster. Reine Änderungen der Defaults reichen gegen profilabhängige ANSI-Farben nicht aus.
|
||||
2. Direkte Farbausgabe verwenden, wenn vom Terminal unterstützt; für 256 Farben feste passende Einträge außerhalb der profilabhängigen ersten 16 verwenden, für reine 16-Farb-Terminals bestehende ANSI-Zuordnung als begrenzten Fallback dokumentieren. Vorhandene Terminalfähigkeitsinformationen wiederverwenden; keine neue Erkennungsbibliothek oder Terminalabfrage-Protokollschicht. Fehlende Erkennung und tatsächlich genutzter Fallback müssen im Prüfbericht benannt sein.
|
||||
3. Referenzfarben je Rolle mit Fundstellen festhalten. Zuerst Originalzuordnung prüfen, danach nur unzureichende Kontrastpaare gezielt anpassen. Für diese Anpassungen explizite Begründung statt falscher Behauptung historischer Identität. Insbesondere Auswahl, deaktivierte Menüs, inaktive Titel, rote Breakpoints und Hilfelinks gegen ihren tatsächlichen Hintergrund messen. Alle Standardtexte erhalten 4,5:1, notwendige nichttextuelle Markierungen 3:1; vorhandene Symbole/Rahmen als zusätzliche Zustandsmerkmale nutzen.
|
||||
4. Die IDE-Palette vom `ScreenWidget` für BASIC-Ausgabe getrennt halten. Dessen `basic_color` und die BASIC-/Forms-Farbattribute werden durch diesen Change nicht global ersetzt. Designer-Vorschau von programmbestimmten Farben unterscheiden: IDE-Werkzeuge erhalten das Theme, Vorschau respektiert Form-Farbattribute.
|
||||
5. Bestehende TestBackend- und Optionsprüfungen um tatsächliche Vorder-/Hintergrundwerte, Kontrast und Zustandswechsel erweitern. Keine rein textuellen Snapshots als Farbprüfung ausgeben. In 05 dieselben Ansichten unter Standardprofil und absichtlich abweichender ANSI-Palette erfassen; Terminalprofil, Transparenz/Dimmung und ausgewählte Texte protokollieren. Keine Screenshot-Pixelgleichheit über unterschiedliche Schriften fordern.
|
||||
6. 05a kann unabhängig von noch fehlenden Prüfrechnern implementiert werden, ist aber erst mit den zugeordneten visuellen Matrixnachweisen vollständig verifiziert. 05 bleibt Eigentümer dieser Nachweise. Vor Releasefreigabe 06 und Phasenabschluss 07 müssen 05a und die betroffenen Matrixzellen bestanden sein.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- Terminal erzwingt Transparenz oder Inaktivitätsdimmung → Anwendung kontrolliert dies nicht; reproduzierbares undurchsichtiges Prüfprofil und tatsächliche Einschränkung dokumentieren, keine unlesbare Pflichtzelle als bestanden werten.
|
||||
- 16-Farb-Fallback hängt weiter von der Palette ab → Grenze und geprüftes geeignetes Profil dokumentieren; bei unterstützten expliziten Farben nicht unnötig auf ANSI zurückfallen.
|
||||
- Exakte historische Kombination verfehlt Kontrast → Lesbarkeit hat Vorrang; eng begrenzte Anpassung mit Originalpaar und Messwert belegen.
|
||||
- Benutzerfarben sind absichtlich kontrastarm → erhalten, ohne Standardtheme-Abnahme auf diese Auswahl zu übertragen.
|
||||
|
||||
## Migration Plan
|
||||
|
||||
Keine neue Optionsdatei und keine automatische Überschreibung. Referenzbelege und Farbabbildung ergänzen, betroffene Renderpfade und Regressionen prüfen, anschließend visuelle Nachweise in 05 aktualisieren. Rücknahme betrifft nur die IDE-Farbabbildung und zugehörige Renderkorrekturen; gespeicherte Farbnummern bleiben kompatibel.
|
||||
@@ -0,0 +1,27 @@
|
||||
## Why
|
||||
|
||||
Der gemeldete Screenshot vom 07.09.2026 zeigt blasse Code- und Titelfarben mit unzureichendem Kontrast. Die vorhandenen DOS-Farbnummern werden als terminalprofilabhängige ANSI-Farben ausgegeben; die bisherige Spezifikation garantiert damit noch kein sichtbar VBDOS-nahes, lesbares Theme auf den Phase-6-Zielen.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Das gesamte IDE-Theme mit belegten VBDOS-Referenzansichten abgleichen; Herkunft, sichere Beobachtungen und bewusste Anpassungen für Lesbarkeit dokumentieren.
|
||||
- Dunkelblaue Codefläche, helle Schrift, graue Bedienflächen und die belegte aktive Titelfarbe verlässlich darstellen; die vorhandene Referenz nennt Weiß auf dunklem Magenta, nicht blasses Rosa.
|
||||
- Kontrast für normale und ausgewählte Texte, aktive/inaktive Fenster, Menüs, Dialoge, Hilfe, Debugger und Designer messbar absichern. Fokus und Zustände zusätzlich durch vorhandene Rahmen/Zeichen kennzeichnen.
|
||||
- Terminalprofilunabhängige IDE-Farbwerte und einen dokumentierten Fallback bereitstellen; Options→Display und gespeicherte Benutzerfarben erhalten.
|
||||
- Visuelle Nachweise mit der Plattformmatrix aus 05 verbinden und als Voraussetzung für Release-/Phasenabnahme in 06/07 führen.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
|
||||
Keine.
|
||||
|
||||
### Modified Capabilities
|
||||
|
||||
- `ide-oberflaeche`: VBDOS-Referenztreue, definierte Farbabbildung und überprüfbare Kontrastanforderungen für das IDE-Theme präzisieren.
|
||||
|
||||
## Impact
|
||||
|
||||
Betroffen sind insbesondere `crates/tb-ide/src/render.rs`, `options.rs`, `help.rs`, `debugger.rs`, `designer.rs`, ihre vorhandenen Render-/Optionsprüfungen und `docs/ide-referenz.md`. Die ANSI-Zuordnung in `tb-ui/src/screen.rs` ist bei der Abgrenzung zur BASIC-Ausgabe zu berücksichtigen. Kein neuer Theme-Manager und keine zusätzliche Abhängigkeit sind vorgesehen. Benutzerdefinierte BASIC-/Forms-Farbattribute bleiben erhalten.
|
||||
|
||||
Eigenständiger Politur-Change innerhalb Phase 6 nach 04, vor finalen Nachweisen aus 05 und der Freigabe aus 06/07. 05 bleibt Eigentümer der echten OS-/Emulatormatrix; 05a liefert deren Theme-Prüffälle. Bereits erhobene Farbnachweise müssen bei Änderungen erneut geprüft werden.
|
||||
@@ -0,0 +1,36 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### 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. Die Standardfarben SHALL auf Terminals mit Unterstützung expliziter Farbwerte unabhängig von der benutzerdefinierten ANSI-Palette ausgegeben werden. Für eingeschränkte Farbfähigkeiten SHALL ein dokumentierter, lesbarer Fallback bestehen; die IDE MUST NOT die globale Terminalpalette verändern. 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
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### 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
|
||||
@@ -0,0 +1,20 @@
|
||||
## 1. Referenz und Ursachenabgleich
|
||||
|
||||
- [x] 1.1 Die in `docs/ide-referenz.md` genannten Farben anhand nachvollziehbarer VBDOS-Fundstellen für Code, Titel, Menüs, Projekt, Dialoge, Status, Hilfe und Designer belegen; Tabelle mit Fundstelle, Sollpaar und ausdrücklich unbelegten Details liefert den prüfbaren Abgleich.
|
||||
- [ ] 1.2 Den Screenshot-Befund mit frischen und gespeicherten Optionen sowie normaler/abweichender ANSI-Palette reproduzieren; Auswahl, Transparenz und Inaktivitätsdimmung getrennt prüfen und tatsächliche Ursache samt Vorher-Nachweis dokumentieren.
|
||||
|
||||
## 2. Farbabbildung und Zustände
|
||||
|
||||
- [x] 2.1 Bestehende IDE-Farbabbildung um definierte DOS-RGB-Werte und passenden 256-/16-Farb-Fallback ergänzen; fokussierter Test bestätigt alle 16 Zuordnungen und tatsächlich erzeugte Terminalfarben ohne globale Palettenänderung.
|
||||
- [x] 2.2 Direkte und geerbte Farben in Editor, Fenstern, Menüs, Dialogen, Status, Hilfe und Debugger auf die einheitliche Abbildung führen; Renderprüfung muss reale Vorder-/Hintergrundpaare bei Auswahl, deaktivierten Einträgen, Fensterwechsel, Fehler und Debuggermarkierung erfassen.
|
||||
- [x] 2.3 Designer-Werkzeuge, Properties und Auswahlmarkierungen abgleichen; Renderprüfung belegt lesbare IDE-Zustände bei unveränderten BASIC-/Forms-Farbattributen und Vorschaufarben.
|
||||
- [x] 2.4 Standardpaare auf 4,5:1 Textkontrast und notwendige nichttextuelle Markierungen auf 3:1 prüfen, unzureichende Paare korrigieren und Abweichungen vom Vorbild begründen; ausführbarer Regressionstest muss bei einem absichtlich kontrastarmen Standardpaar fehlschlagen.
|
||||
- [x] 2.5 Options→Display und Laden/Speichern vorhandener Farbnummern prüfen; Regression bestätigt unveränderte Benutzerauswahl, Desktopzeichen, Tabweite und Programmausgabe ohne stilles Zurücksetzen.
|
||||
|
||||
## 3. Visuelle Abnahme und Übergabe
|
||||
|
||||
- [x] 3.1 Referenztabelle, Kontrastwerte und reproduzierbare Ansichten/Bedienfolgen für 05 bereitstellen; jede betroffene UI-Rolle und jeder Zustand muss einen erwarteten sichtbaren Effekt besitzen, einschließlich Standardprofil und abweichender ANSI-Palette.
|
||||
- [ ] 3.2 Tatsächliche Theme-Nachweise aus 05 für Windows Terminal, Terminal.app sowie xterm/VTE auf Linux amd64 und arm64 zuordnen; Revision, Terminalversion, Profil/Farbmodus und Vorher-/Nachher-Ansichten müssen vorliegen, fehlende Systeme bleiben offen.
|
||||
- [ ] 3.3 Alle Theme-Befunde beheben und betroffene Render-/Options-/Emulatorprüfungen wiederholen; Verifizierungsbericht mit null offenen Befunden, aktuelle Referenzdokumentation und konsistente Übergabe an 05/06/07 sind Abschlussbedingung.
|
||||
|
||||
Archivhinweis 07.09.2026: Auf Benutzeranweisung nach offen ausgewiesenem Stand 7/10 archiviert. Aufgaben 1.2, 3.2 und 3.3 bleiben unbestanden; Change 05 führt Profil-Gegenprobe, tatsächliche Matrix und abschließende Theme-Verifizierung weiter.
|
||||
@@ -0,0 +1,51 @@
|
||||
# Verifizierung: phase-6-05a-vbdos-theme-und-kontrast
|
||||
|
||||
Stand: 07.09.2026, Basis `69f200248198a7a0cc5cd23f7f379550eee0277f` plus lokaler Change-05a-Diff. Auf Benutzeranweisung nach dem Bericht 7/10 synchronisiert und am 07.09.2026 archiviert; die drei offenen Nachweise werden ausdrücklich in Change 05 weitergeführt. Implementierung und lokale Tests sind keine vollständige visuelle Plattformabnahme.
|
||||
|
||||
## Ergebnis
|
||||
|
||||
| Dimension | Stand |
|
||||
|---|---|
|
||||
| Vollständigkeit | 7/10 Aufgaben abgeschlossen; 1.2, 3.2 und 3.3 offen |
|
||||
| Korrektheit | Lokale Farb-, Zustands-, Options- und Regressionsprüfungen bestanden; tatsächliche Darstellung auf den Pflichtterminals noch nicht belegt |
|
||||
| Kohärenz | Vorhandene IDE-Farbabbildung erweitert, keine neue Abhängigkeit; BASIC-Ausgabe und Formularvorschau behalten ihre separate Zuordnung |
|
||||
|
||||
## Implementierung und Nachweise
|
||||
|
||||
- `crates/tb-ide/src/render.rs`: zentrale DOS-RGB-Palette, fester 256-Farben-Fallback außerhalb der Systempalette, begrenzter ANSI-Fallback. Bestehende Farbnummern bleiben kompatibel. Gemeinsame Farbpaare für aktive/inaktive Fenster, Projekt, Menüs, Dialoge, Status und Fehlermeldungen; aktive Fenster mit Doppelrahmen, deaktivierte Menüpunkte mit lesbarer Schrift und zusätzlichem ×-Zeichen. Mnemonics erben die Auswahlfarben.
|
||||
- `crates/tb-ide/src/help.rs` und `debugger.rs`: Hilfetitel/Links mit lesbarem Vordergrund, ausgewählter Link mit festem Paar, Debugger mit derselben IDE-Palette. Breakpoint und Ausführungsmarkierung erhalten in `render.rs` eigene kontrastreiche Hintergründe.
|
||||
- `crates/tb-ide/src/designer.rs`: Handles/Timerkennzeichen mit vollständigem Farbpaar und kontrastgerechte Beschriftung aller 16 Farbfelder. Toolbox und Properties Bar orientieren sich an den cyanfarbenen Referenzflächen; Formularfarbattribute bleiben unverändert.
|
||||
- `crates/tb-ide/tests/app.rs`: Zellprüfung von Editor, Textauswahl, allen Menüeinträgen, deaktivierten Zuständen, Dialogen einschließlich Fehlern, Projekt, Hilfe/Linkfokus, Debugger/Breakpoint/Ausführungszeile und Designer-Werkzeugen. Absichtlich zu schwaches Titelpaar wird abgewiesen. RGB-/256-Farben-Kontrast und alle Palettenbeschriftungen geprüft; reale Ratatui/Crossterm-Ausgabe enthält explizite Farbsequenzen und keine OSC-Palettenänderung. Bestehende Options-/Persistenzprüfungen sowie unveränderte BASIC-Palettenzuordnung bestehen.
|
||||
- `docs/ide-referenz.md`, Abschnitt 4a: drei nachvollziehbare Originalprogramm-Ansichten für Code/Run-Menü/Projekt, Designer und About-Dialog. Nicht belegte Hilfe-/Deaktivierungsdetails sind ausdrücklich benannt. Tabelle dokumentiert gezielte Kontrastabweichungen, Messwerte und die vollständige Bedienfolge für sechs Matrixzellen in 05.
|
||||
|
||||
### Ausgeführte Prüfungen
|
||||
|
||||
- `COLORTERM=truecolor cargo test --locked --workspace`: 636 bestandene Testergebnisse, 0 Fehler, 3 bestehende ignorierte Tests. Kein ignorierter Fall wird als Theme-Nachweis gezählt.
|
||||
- Anschließend `COLORTERM=truecolor cargo test --locked -p tb-ide` auf dem letzten Render-/Dokumentationsstand: bestanden (91 Tests plus erfolgreicher separater Hilfe-Kindprozess).
|
||||
- `COLORTERM= TERM=xterm-256color cargo test --locked -p tb-ide --test app theme_`: 3/3 bestanden. Erfasst auch den Fall, dass ein generisches COLORTERM die TERM-Erkennung überdecken würde.
|
||||
- `COLORTERM= TERM=vt100 cargo test --locked -p tb-ide --test app theme_`: 3/3 bestanden. Die Berechnung für ANSI setzt die dokumentierte DOS-Palette voraus und beweist kein frei konfiguriertes Emulatorprofil.
|
||||
- `cargo clippy --locked -p tb-ide --all-targets -- -D warnings`, `cargo fmt --all -- --check` und `git diff --check`: bestanden.
|
||||
- `openspec validate --all --strict --no-interactive`: 31/31 bestanden.
|
||||
- `cargo build --locked --release -p tb-ide`: bestanden; aktuelle IDE unter `target/release/tb` (macOS arm64). SHA-256: `b54dfa6607b454dae42bb57bc856b020a11ce80a2dd49a55f9826e461fbe8e0f`. Ein lokaler Build ist kein visueller Terminalnachweis.
|
||||
|
||||
## Offene Befunde – Übergabe an Change 05
|
||||
|
||||
### CRITICAL: Aufgabe 1.2 – konkrete Screenshot-Reproduktion fehlt
|
||||
|
||||
Der Codebefund ist reproduzierbar: benannte ANSI-Farben werden vom Terminalprofil bestimmt, feste RGB-/256-Farben umgehen diese Systempalettenzuordnung. Aus dem Benutzerbild allein lässt sich jedoch nicht feststellen, welchen Anteil gespeicherte Optionen, Textauswahl, Transparenz oder Inaktivitätsdimmung an dessen Darstellung hatten. Am erwarteten macOS-Standardpfad lag keine Optionsdatei vor; das beweist nicht, dass die abgebildete Sitzung ohne Optionen lief.
|
||||
|
||||
Erforderlich: dieselbe IDE-Ansicht im betroffenen Terminal mit frischen und den tatsächlich verwendeten Optionen sowie protokolliertem Profil nach der Folge in Abschnitt 4a vergleichen. Die Aufgabe bleibt bis zu dieser Gegenprobe offen.
|
||||
|
||||
### CRITICAL: Aufgabe 3.2 – echte visuelle Matrix fehlt
|
||||
|
||||
Windows amd64/Windows Terminal, macOS arm64/Terminal.app sowie Linux amd64 und arm64 jeweils mit xterm und VTE sind noch nicht visuell abgenommen. Es werden weder Cross-Builds noch TestBackend-Ansichten als solche Nachweise ausgegeben. Die Computer-Use-Schnittstelle hat den Zugriff auf Terminal.app im bisherigen Versuch ausdrücklich gesperrt; andere UI-Steuerwege werden nicht zum Umgehen dieser Sperre verwendet. Für die übrigen Pflichtterminals liegt noch kein nutzbarer Zugang vor.
|
||||
|
||||
Erforderlich: die vorbereiteten Ansichten auf den sechs tatsächlichen Kombinationen prüfen und Revision, Executable-Prüfsumme, Terminalversion, Profil/Farbmodus und Bild-/Transkriptbelege in Change 05 zuordnen. Vorher-Nachher-Vergleich und getestete Ersatzwege bei Terminalgrenzen dokumentieren.
|
||||
|
||||
### CRITICAL: Aufgabe 3.3 – Abschluss setzt die beiden Nachweise voraus
|
||||
|
||||
Die lokalen Prüfungen melden auf dem geprüften Stand keinen weiteren Implementierungsbefund. Ein Report ohne offene Befunde kann erst nach 1.2 und 3.2 erstellt werden. Tatsächlich gefundene Zielprobleme müssen vor Abschluss korrigiert und auf dem betroffenen Terminal erneut geprüft werden.
|
||||
|
||||
## Nächster Schritt
|
||||
|
||||
Die korrigierte IDE ist die Implementierungsgrundlage für Change 05. Dessen echte Plattformabnahme liefert die noch offenen visuellen Nachweise für 05a; Change 05 bleibt bis dahin offen; das Archiv von 05a dokumentiert ausdrücklich den Stand 7/10 statt einer vollständigen visuellen Abnahme. Es wurde keine Pflichtprüfung gestrichen oder als bestanden angenommen.
|
||||
@@ -17,6 +17,8 @@ Phase 5 verwendete crossterm-Ereignisse, ratatui-TestBackend und `tests/support/
|
||||
5. Windows-/Unix-spezifische Tests und Hilfsprozesse mit passenden Plattformzweigen führen. Keine Unix-Shell-Kommandos unverändert auf Windows als vermeintliche Produktfehler werten. Produktsemantik und Testhost-Portabilität getrennt prüfen.
|
||||
6. Fehler im gemeinsamen Terminaladapter beheben und einen fokussierten Regressionstest ergänzen. Für vom Emulator reservierte Shortcuts einen bereits vorhandenen Menü-/Mausweg prüfen. Fehlende Pflichtfunktionen werden nicht als Terminalgrenze umetikettiert.
|
||||
|
||||
7. Den ergänzenden Theme-Change 05a vor Abschluss der visuellen Matrix berücksichtigen. Dessen Referenzansichten und Kontrastprüfungen mit tatsächlicher Revision, Farbprofil und Standard-/abweichender ANSI-Palette in jeder Pflichtzelle prüfen; vor einer Theme-Korrektur erhobene betroffene Bilder erneut aufnehmen. Diese Nachweise gehen mit der bestehenden Matrix an 06/07.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- CI ohne interaktiven Desktop → automatisierte Zieltests plus zugeordnete manuelle Emulatornachweise, keine Gleichsetzung beider Kategorien.
|
||||
|
||||
@@ -23,3 +23,5 @@ Keine. Bestehende IDE- und Host-Eingabeverträge bleiben maßgeblich.
|
||||
## Impact
|
||||
|
||||
Terminaladapter in tb-ui/tb-ide, bisheriger PTY-Test, native Artefakttests aus 02–04 und neue Matrixdokumentation. Fachkorrekturen bleiben in bestehenden Adaptern. Abhängigkeiten: 01–04; automatisierte Aufrufe werden in 06 in Gitea Actions übernommen.
|
||||
|
||||
Der zusätzliche Change `phase-6-05a-vbdos-theme-und-kontrast` liefert Referenzfarben, Kontrastregeln und visuelle Prüffälle. Die abschließende Darstellungsmatrix umfasst diese Ergebnisse; ihre Vorbereitung kann unabhängig davon fortgesetzt werden.
|
||||
|
||||
@@ -12,7 +12,7 @@ Die Plattformabnahme SHALL Windows amd64 mit Windows Terminal, macOS arm64 mit e
|
||||
- **THEN** bleibt dessen Ausführungsnachweis offen und die vollständige Plattformabnahme gilt nicht als bestanden
|
||||
|
||||
### Requirement: Reale Eingabe und Darstellung
|
||||
Die Matrix SHALL F1–F12, relevante Shift-/Ctrl-/Alt-Kombinationen, Menünavigation, Mausdruck/-loslassen/-bewegung, Unicode, Farben und Größenänderung für IDE und repräsentative erzeugte Programme prüfen. Eingaben SHALL genau einmal dem zuständigen IDE- oder BASIC-Kontext zugeordnet werden. Unterhalb der Mindestgröße SHALL die Anwendung bedienbar wiederherstellbar bleiben.
|
||||
Die Matrix SHALL F1–F12, relevante Shift-/Ctrl-/Alt-Kombinationen, Menünavigation, Mausdruck/-loslassen/-bewegung, Unicode, Farben und Größenänderung für IDE und repräsentative erzeugte Programme prüfen. Die IDE-Farbprüfung SHALL das geltende VBDOS-Theme einschließlich Kontrast und Zuständen aus `ide-oberflaeche` mit dokumentiertem Farbprofil und tatsächlichen Ansichten abdecken. Eingaben SHALL genau einmal dem zuständigen IDE- oder BASIC-Kontext zugeordnet werden. Unterhalb der Mindestgröße SHALL die Anwendung bedienbar wiederherstellbar bleiben.
|
||||
|
||||
#### Scenario: Tastenkonflikt im Terminal
|
||||
- **WHEN** der Emulator eine IDE-Tastenkombination selbst abfängt
|
||||
|
||||
@@ -15,4 +15,4 @@
|
||||
## 3. Übergabe
|
||||
|
||||
- [ ] 3.1 Terminalgrenzen und verifizierte Ersatzwege dokumentieren; kein Produktfehler oder fehlender Prüfrechner darf als bestandene Matrixzelle erscheinen.
|
||||
- [ ] 3.2 Automatisierbare Zielprüfungen an 06 übergeben und Matrixbericht fertigstellen; alle Pflichtzellen, Revisionen, vier Ergebnisse derselben TBL-Verbraucherprobe und tatsächlichen Ergebnisse müssen vor Abschluss vorliegen. Native Prüfsysteme dürfen separat vom zentralen Buildrunner betrieben und Nachweise dokumentiert manuell erhoben werden.
|
||||
- [ ] 3.2 Automatisierbare Zielprüfungen an 06 übergeben und Matrixbericht fertigstellen; alle Pflichtzellen, Revisionen, vier Ergebnisse derselben TBL-Verbraucherprobe und tatsächlichen Ergebnisse müssen vor Abschluss vorliegen. Die weiterhin offenen Archivaufgaben 05a/1.2 (konkretes Benutzerprofil, frische/gespeicherte Optionen, Transparenz/Dimmung), 05a/3.2 (visuelle Matrix) und 05a/3.3 (befundfreie Schlussverifizierung) müssen hier tatsächlich abgeschlossen werden. Die visuellen Nachweise müssen das umgesetzte Theme aus 05a einschließlich Profil-/Farbmodus und relevanter UI-Zustände abdecken. Native Prüfsysteme dürfen separat vom zentralen Buildrunner betrieben und Nachweise dokumentiert manuell erhoben werden.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
## Context
|
||||
|
||||
README nennt derzeit noch „Projektrahmen“, die Korpus-README enthält frühere Phasenaussagen, Exportseiten nennen das noch fehlende Backend. PLAN verweist bei der Endabnahme historisch auf 285 Spracheinträge; das heutige Inventar führt zusätzlich das vollständige Forms-Objektmodell. Help bettet docs und PLAN zur Buildzeit ein. 01–06 liefern neue Fähigkeiten und konkrete Artefaktnachweise.
|
||||
README nennt derzeit noch „Projektrahmen“, die Korpus-README enthält frühere Phasenaussagen, Exportseiten nennen das noch fehlende Backend. PLAN verweist bei der Endabnahme historisch auf 285 Spracheinträge; das heutige Inventar führt zusätzlich das vollständige Forms-Objektmodell. Help bettet docs und PLAN zur Buildzeit ein. 01–06 einschließlich 05a liefern neue Fähigkeiten und konkrete Artefaktnachweise.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
@@ -13,7 +13,7 @@ README nennt derzeit noch „Projektrahmen“, die Korpus-README enthält frühe
|
||||
1. Bestehende docs als einzige Hilfe-/Referenzquelle erhalten. Native Runtime in tbrt, portables TBL und vollständiges TBC ausdrücklich unterscheiden; native `.lib`/`.a` oder eine C-Verbraucherschnittstelle sind kein Phase-6-Exportziel. README, Tutorial, Migration, TBC-/TBL-/tbrt-Vertrag, `tbc link`, IDE-Library-Einbindung, Paketinhalt und OS-Mindeststände anhand der tatsächlichen CLI-/IDE-Implementierung prüfen. Neue Seiten ausdrücklich im Help-Katalog registrieren und interne Links testen. Historische Reports werden nicht rückwirkend als neue Messungen umgeschrieben.
|
||||
2. Den Phase-5-Hauptablauf und Abnahmesatz aus 01 verwenden; zusätzliche Schritte arbeiten mit aus 06 entpackten Tools, echten nativen Ausgaben und einem separaten BASIC-Verbraucher aus 03 ohne Library-Quellen. Keine zweite allgemeine Testframeworkschicht. Pro Ziel konkrete Prozess-/Terminal-/Dateiresultate aufzeichnen.
|
||||
3. `inventar.rs`, feste Sollquellen und VM-Ereignisauslöser erneut vollständig ausführen; Summen aus allen aktuellen Einträgen ermitteln. Historische 285 Sprachelemente sind eine Herkunftszahl, keine Sollobergrenze. Gefundene Lücken in ihrem Fachpfad beheben und deren Proben wiederholen; Quellen und Non-Feature-Fundstellen erhalten.
|
||||
4. Die acht Planpunkte erhalten explizite Nachweise aus 01–06 plus finalem Gesamtweg. Referenzmessung nach sämtlichen Fachkorrekturen, kein Wiederholen unveränderter teurer Prüfungen ohne Anlass. Gitea-Run-/Release-IDs, Commit, Paketprüfsummen und Matrixzellen bilden die Releaseevidenz.
|
||||
4. Die neun Planpunkte erhalten explizite Nachweise aus 01–06 einschließlich 05a plus finalem Gesamtweg. Referenzmessung nach sämtlichen Fachkorrekturen, kein Wiederholen unveränderter teurer Prüfungen ohne Anlass. Gitea-Run-/Release-IDs, Commit, Paketprüfsummen und Matrixzellen bilden die Releaseevidenz.
|
||||
5. Veraltete Hinweise in PLAN (einschließlich der doppelten Einordnung von `tbc build --exe` unter Stufe 2) und Dokumenten konsistent bereinigen. Tatsächliche Stufe-2-Ideen bleiben unbeschlossen. Ein fehlender Prüfrechner oder Releasezugang bleibt ein Blocker für die Abnahme, keine unterstellte erfolgreiche Prüfung.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
@@ -7,7 +7,7 @@ Nach den Einzelchanges muss Phase 6 anhand tatsächlich ausgelieferter Programme
|
||||
- README, Sprach-/Migrations-/Dateiformat-/IDE-/Exportdokumentation und ausführbare Beispiele auf den endgültigen Stand bringen; eingebettete Hilfe mitprüfen.
|
||||
- Installation aus allen vier Release-Paketen, IDE-Projektaufbau, TBL-Bau, `tbc link`, IDE-Library-Einbindung und eigenständige EXE-Nutzung zusammenhängend abnehmen.
|
||||
- Das vollständige aktuelle Sprach- und Forms-Inventar mit null offenen Einträgen und begründeten Non-Features prüfen; die historische Zahl 285 nicht als Grenze des erweiterten Inventars verwenden.
|
||||
- Alle acht Phase-6-Planpunkte mit aktuellen Nachweisen, Revisionen und Artefakten verbinden und erst dann abschließen.
|
||||
- Alle neun Phase-6-Planpunkte mit aktuellen Nachweisen, Revisionen und Artefakten verbinden und erst dann abschließen.
|
||||
|
||||
## Capabilities
|
||||
|
||||
@@ -21,4 +21,4 @@ Keine. Bestehende Sprach-/Inventarverträge werden erneut geprüft, nicht abgesc
|
||||
|
||||
## Impact
|
||||
|
||||
PLAN.md, README.md, docs, examples und Help-Katalog sowie Abschlussnachweise. Keine vorgezogenen Stufe-2-Spracherweiterungen. Abhängigkeiten: alle Changes 01–06 mit synchronisierten Specs und tatsächlichen Prüfergebnissen; abgeschlossene Aufgabenlisten allein genügen nicht.
|
||||
PLAN.md, README.md, docs, examples und Help-Katalog sowie Abschlussnachweise. Keine vorgezogenen Stufe-2-Spracherweiterungen. Abhängigkeiten: alle Changes 01–06 einschließlich 05a mit synchronisierten Specs und tatsächlichen Prüfergebnissen; abgeschlossene Aufgabenlisten allein genügen nicht.
|
||||
|
||||
@@ -26,7 +26,7 @@ Die Endabnahme SHALL mit den fertigen Releasepaketen auf Windows amd64, macOS ar
|
||||
- **THEN** funktionieren Projekt-/Export-/Nutzungsschritte ausschließlich mit den beschriebenen Artefakten und Systemvoraussetzungen
|
||||
|
||||
### Requirement: Evidenzgebundener Phasenabschluss
|
||||
Jeder Phase-6-Planpunkt SHALL vor dem Abhaken auf bestandene Nachweise mit Revision, Plattform und Artefakt verweisen. Workspace-Regressionen, Native-/Verbrauchertests, Plattformmatrix, Inventar und bestehende Compile-Budgets SHALL auf dem finalen Stand bestehen. Fehlende externe Systeme oder noch nicht ausgeführte Workflows MUST als fehlende Nachweise sichtbar bleiben.
|
||||
Jeder Phase-6-Planpunkt SHALL vor dem Abhaken auf bestandene Nachweise mit Revision, Plattform und Artefakt verweisen. Workspace-Regressionen, Native-/Verbrauchertests, Plattformmatrix einschließlich VBDOS-Theme-/Kontrastnachweisen aus 05a, Inventar und bestehende Compile-Budgets SHALL auf dem finalen Stand bestehen. Fehlende externe Systeme oder noch nicht ausgeführte Workflows MUST als fehlende Nachweise sichtbar bleiben.
|
||||
|
||||
#### Scenario: Vollständige Artefakte aber fehlender Test
|
||||
- **WHEN** alle Change-Dokumente vorhanden sind, aber eine erforderliche Plattform- oder Releaseprüfung fehlt
|
||||
|
||||
@@ -9,10 +9,10 @@
|
||||
|
||||
- [ ] 2.1 Vollständiges aktuelles Sprach-/Forms-Inventar mit Sollquellen, Absenkung und Ereignisauslösern prüfen; null offene Einträge und jede Non-Feature-Fundstelle im Bericht belegen.
|
||||
- [ ] 2.2 Gesamtweg Installation → IDE-Projekt → Debuggen → TBL-Export → separates BASIC-Projekt/`tbc link` → eigenständige EXE-Nutzung auf allen vier Zielen ausführen; jeweilige Paketprüfsumme, Revision und beobachtete Resultate protokollieren.
|
||||
- [ ] 2.3 Alle sieben Changes und ihre Abhängigkeiten gegen synchronisierte Specs prüfen; gefundene Fachbefunde im zuständigen Bereich beheben und betroffene Nachweise bis zu null offenen Befunden wiederholen.
|
||||
- [ ] 2.3 Alle acht Changes (01–07 plus 05a) und ihre Abhängigkeiten gegen synchronisierte Specs prüfen; gefundene Fachbefunde im zuständigen Bereich beheben und betroffene Nachweise bis zu null offenen Befunden wiederholen.
|
||||
- [ ] 2.4 Workspace-, TBL-Link-/native EXE-, Plattform-/Release- und Compile-/VM-Leistungsnachweise auf dem finalen Stand abschließen; fehlende externe Nachweise ausdrücklich offen lassen, keine historischen Messungen als neue ausgeben.
|
||||
|
||||
## 3. Phasenabschluss
|
||||
|
||||
- [ ] 3.1 Alle acht PLAN-Punkte einer bestandenen Evidenz zuordnen und erst dann abhaken; Bericht muss Gitea-Run-/Releasebezug, zentralen Cross-Paketbau und davon getrennte echte Zielausführung, vier Targets und verbleibende Stufe-2-Abgrenzung zeigen.
|
||||
- [ ] 3.1 Alle neun PLAN-Punkte einer bestandenen Evidenz zuordnen und erst dann abhaken; Bericht muss Gitea-Run-/Releasebezug, zentralen Cross-Paketbau und davon getrennte echte Zielausführung, vier Targets und verbleibende Stufe-2-Abgrenzung zeigen.
|
||||
- [ ] 3.2 Abschließende Doku-/Help-/OpenSpec-Konsistenz prüfen; keine unaufgelösten Links, widersprüchlichen Exporthinweise oder offenen Phase-6-Befunde dürfen verbleiben.
|
||||
|
||||
@@ -36,12 +36,20 @@ Fenster SHALL Titelleiste, Control-Menü, Rahmen und bei Bedarf Scrollbalken erh
|
||||
- **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 Farbschema aus docs/ide-referenz.md verwenden, insbesondere blaue Codefläche, weiße aktive Titel auf Magenta, graue Menüs und schwarze Statusschrift auf Cyan. 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.
|
||||
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. Die Standardfarben SHALL auf Terminals mit Unterstützung expliziter Farbwerte unabhängig von der benutzerdefinierten ANSI-Palette ausgegeben werden. Für eingeschränkte Farbfähigkeiten SHALL ein dokumentierter, lesbarer Fallback bestehen; die IDE MUST NOT die globale Terminalpalette verändern. 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
|
||||
|
||||
### 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.
|
||||
|
||||
@@ -74,3 +82,21 @@ Run→Make EXE File und Run→Make Library SHALL bereits in Phase 5 bedienbare D
|
||||
#### 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
|
||||
|
||||
Reference in New Issue
Block a user