112 lines
2.9 KiB
Markdown
112 lines
2.9 KiB
Markdown
# Migration bestehende Module
|
|
|
|
## Ziel
|
|
|
|
Die bestehenden Module aus dem alten Nexus sollen als Basis in `desktop.kusche.berlin` verfügbar sein, damit sie dort später in die neue Oberfläche überführt werden können.
|
|
|
|
## Wichtige Regel
|
|
|
|
Die Übernahme erfolgt zweistufig:
|
|
|
|
1. Rohkopie als Referenzbasis
|
|
2. anschließende separate Anpassung im neuen Projekt
|
|
|
|
## Empfohlener Zielordner im neuen Projekt
|
|
|
|
- `temp/nexus-module-import/`
|
|
|
|
## Was kopiert werden soll
|
|
|
|
Mindestens:
|
|
|
|
- `/modules/`
|
|
- relevante globale Dokumentationsdateien
|
|
- gegebenenfalls Referenzdateien aus `/src/`, wenn Modul-Helfer benötigt werden
|
|
|
|
Zusätzlich möglich:
|
|
|
|
- kompletter Altstand unter `Old-Nexus/`
|
|
|
|
## Was zunächst nicht aktiv umgebaut werden soll
|
|
|
|
- keine direkten Eingriffe in das alte Nexus-Projekt
|
|
- keine halb fertige Mischform aus alter UI und neuer Desktop-UI
|
|
- keine automatische Massenmigration ohne Sichtprüfung pro Modul
|
|
- keine technische Nutzung von `Old-Nexus/` im neuen Produktivcode
|
|
|
|
## Ziel nach dem Kopieren
|
|
|
|
Im neuen Projekt gibt es:
|
|
|
|
- die neue Desktop-Shell
|
|
- die importierten Module als Rohbasis
|
|
- optional `Old-Nexus/` als reine Sicht- und Erinnerungsbasis
|
|
- eine schrittweise Anbindung pro Modul an das neue Fenstersystem
|
|
|
|
## Empfohlener Migrationsablauf je Modul
|
|
|
|
1. Modul aus Import-Basis prüfen
|
|
2. benötigte Assets und Seiten identifizieren
|
|
3. Modul in neue App-Registry eintragen
|
|
4. Modul als Desktop-App definieren
|
|
5. Modulansichten in Fensterlogik integrieren
|
|
6. Skin-Verhalten testen
|
|
|
|
## Wichtig für spätere Umsetzung
|
|
|
|
Module werden nicht einfach als alte Seite verlinkt, sondern:
|
|
|
|
- als App registriert
|
|
- im Desktop geöffnet
|
|
- mit Fenstertitel, Icon, Startverhalten und optionalen Widget-Anknüpfungen beschrieben
|
|
|
|
Wenn `Old-Nexus/` vorhanden ist:
|
|
|
|
- nur zum Nachschlagen alter Lösungswege verwenden
|
|
- keine Pfadabhängigkeit darauf erzeugen
|
|
- nichts daraus zur Laufzeit laden
|
|
- nichts daraus direkt includen oder importieren
|
|
|
|
## Mögliche App-Metadaten je Modul
|
|
|
|
- `app_id`
|
|
- `title`
|
|
- `icon`
|
|
- `entry_route`
|
|
- `window_mode`
|
|
- `default_width`
|
|
- `default_height`
|
|
- `supports_widget`
|
|
- `supports_tray`
|
|
- `module_name`
|
|
|
|
## Erweiterte Modul-Metadaten fuer die neue Desktop-Shell
|
|
|
|
Importierte Module sollen bei der Migration nicht nur eine Fenster-App bekommen, sondern moeglichst direkt folgende Angaben im Manifest vorbereiten:
|
|
|
|
- `app_scope: module`
|
|
- `installable: true`
|
|
- `desktop.available`
|
|
- `desktop.show_on_desktop`
|
|
- `desktop.show_in_start_menu`
|
|
- `widgets[]`
|
|
- `cron_jobs[]`
|
|
|
|
Damit koennen folgende Dinge ohne weitere Sonderverdrahtung automatisch entstehen:
|
|
|
|
- Desktop- und Startmenue-Sichtbarkeit
|
|
- Widget-Auswahl im User Self Management
|
|
- Aufnahme in die zentrale Cron-Verwaltung
|
|
|
|
## Systemtools sind keine Module
|
|
|
|
Globale Verwaltungsfunktionen werden in diesem Projekt nicht als installierbare Module behandelt.
|
|
|
|
Beispiele:
|
|
|
|
- `User Management`
|
|
- `User Self Management`
|
|
- `Cron Tool`
|
|
|
|
Diese Apps laufen als `system_tool` und nicht als `module`.
|