RichardandClaude Opus 5
669676ac60
Alle acht Fenster laufen jetzt unter Avalonia: Launcher, Dashboard, Settings, Terminal, Server Jobs, Copytrading, ResolutionFarming, Supervisor, Accounting (+ Shutdown- und Allzweck-Dialog). - Copytrading: vier Tabs (Master-Trader mit Account-Zuweisung, Offene Trades, Geschlossene Trades mit Filterleiste, Account-Einstellungen). Zeilenfaerbung nach PnL laeuft ueber DataGrid.LoadingRow - greift damit auch bei virtualisierten Zeilen, anders als das fruehere Faerben in DataBindingComplete. - ResolutionFarming: Kandidaten, Positionen, Historie, Settings - je Konto. - Supervisor: Analyse-Chat gegen den Agenten (Tool-Fortschritt in der Statuszeile), Dossiers mit Markdown-Ansicht, Berichte, Counterfactuals. - Accounting: KPI-Kacheln, Monats-BWA, Ledger, Abruf/Status, PDF- und CSV-Export ueber den plattformneutralen Datei-Dialog. Der SettingsEditor traegt wie erwartet die drei restlichen PropertyGrid-Stellen (Master-Trader, Account-Einstellungen, ResolutionFarming) mit je einem Aufruf. ENTSCHEIDUNG - Modul-Fenster liegen in der App, nicht in den Modulen (begruendet in Views/Modules/README.md): Die App ist der Kompositionswurzel und referenziert ohnehin alle Module. So bleiben die Modulprojekte FREI VON AVALONIA, was fuer den kopflosen Linux-Betrieb den Ausschlag gibt - der Daemon soll keine GUI-Bibliothek mitschleppen. Verifiziert: kein Modul zieht Avalonia. Registrierung in Shell/ModuleViews.cs, und zwar nur fuer tatsaechlich geladene Module - ein per DisabledModules abgeschaltetes Modul bekommt gar kein Fenster. Nebenbei: eigene View-Model-Typen CopyOpenTradeRow/CopyClosedTradeRow statt des Modul-Modells ClosedTradeRow - sie tragen den aufgeloesten Master-Trader-Namen und die Zeilenfarbe, die es dort nicht gibt (und vermeiden die Namensmehrdeutigkeit). Verifiziert: Solution baut, 450 Tests gruen, --smoke-ui gruen (alle 8 Fenster + Launcher + Dialog + Editor-Pruefung), App laeuft real mit allen Trading-Diensten, Linux-Publish laeuft. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
19 lines
1.2 KiB
Markdown
19 lines
1.2 KiB
Markdown
# Modul-Fenster
|
||
|
||
Die Fenster der Module liegen bewusst **hier in der App** und nicht in den Modulprojekten.
|
||
|
||
**Warum:** Die App ist der Kompositionswurzel – sie referenziert ohnehin alle vier Module. Damit
|
||
bleiben die Modulprojekte (Trading-Engine, Scanner, Supervisor, Accounting) **frei von Avalonia**.
|
||
Das ist für den kopflosen Linux-Betrieb (`--headless`) der entscheidende Punkt: der Daemon soll
|
||
keine GUI-Bibliothek mitschleppen. Zusätzlich können die Fenster so die gemeinsamen Bausteine der
|
||
Shell nutzen (`WindowMenuBar`, `SettingsEditor`, `DialogWindow`), ohne dass diese in eine eigene
|
||
Bibliothek ausgelagert werden müssen.
|
||
|
||
**Folge:** `IPolyTraderModule.RegisterUi` bleibt je Modul ein No-Op; registriert werden die Ansichten
|
||
in `Shell/ModuleViews.cs`. Die stabilen View-IDs (`copytrading.main` usw.) bleiben unverändert,
|
||
sodass Symbole, Reihenfolge und Launcher-Verhalten identisch sind.
|
||
|
||
**Alternative, falls Module später doch ihre UI selbst mitbringen sollen:** eine gemeinsame
|
||
Bibliothek `PolyTrader.Ui.Shared` mit den obigen Bausteinen anlegen und die Fenster in
|
||
`PolyTrader.Modules.X.Ui`-Projekte verschieben. Der Aufbau der Fenster bliebe dabei unverändert.
|