desktop/custom/apps

Module

Installierbare und fachliche Apps liegen in diesem Projekt unter custom/apps/<app>/.

Die neue Desktop-Shell ist nur die UI-Schicht. Modul-Businesslogik wird nicht in den Desktop-Core verschoben.

Aktuelle Modulstruktur

Ein Desktop-Modul kann zusaetzlich diese Projektdateien besitzen:

• desktop.php fuer die Desktop-App-Metadaten und Asset-Definitionen
• pages/ fuer Standalone-Seiten oder iframe/native Einstiegspunkte
• api/ fuer modulinterne HTTP-Endpunkte
• assets/ fuer modulnahe CSS- und JS-Dateien
• docs/README.md fuer modulspezifische Hinweise, API und Sonderregeln
• module.json fuer Setup, Desktop-Freigabe, Widget-Funktionen und Cron-Endpunkte

Custom-App-Assets werden nicht direkt aus public/ geladen, sondern ueber den generischen Endpoint /module-assets/index.php aus dem jeweiligen App-Ordner ausgeliefert.

Trennung zwischen Systemtools und Modulen

• Systemtools sind globale Verwaltungs- und Setup-Apps und nicht installierbar
• aktuelle Beispiele: User Management, User Self Management, Cron Tool
• Custom Apps sind installierbare Fachanwendungen
• aktuelle Beispiele: Mining-Checker, Waehrungs-Checker, Boersenchecker, Pi-hole

Diese Trennung wird ueber App-Metadaten gesteuert:

• app_scope
  • core
  • system_tool
  • module
• installable
  • false fuer Core- und Systemtools
  • true fuer installierbare Module

Modul-Metadaten in module.json

Module sollen ihre Desktop-Faehigkeiten zentral in module.json beschreiben.

Wichtige Bausteine:

• desktop
  • available
  • show_on_desktop
  • show_in_start_menu
• widgets
  • beschreibt Widget-Funktionen, die nur fuer installierte Module verfuegbar sind
• cron_jobs
  • beschreibt Cron-Endpunkte fuer die zentrale Cron-Verwaltung

Die Desktop-Shell liest diese Angaben automatisch ein. Neue Modul-Crons und Widgets muessen deshalb nicht zusaetzlich in einer separaten globalen Liste nachgetragen werden, solange sie sauber im Manifest beschrieben sind.

Globale Desktop-Standards fuer Module

• gemeinsame Desktop-Mechaniken wie Fenster, Tray, globale Persistenz und Debug-Infrastruktur liegen im Desktop-Core
• Module und andere Apps sollen keine eigene Grund-Debug-Oberflaeche im Stil eines separaten globalen Debuggers bauen
• fuer Debugging im Desktop gilt das zentrale Admin-Debug-Widget neben der Uhr mit eigenem Debug-Fenster als Standard
• Debug-Events aus Modulen sollen in den gemeinsamen Desktop-Debug-Bus geschrieben werden, damit sie im globalen Debug-Fenster sichtbar sind
• wenn das globale Debug-Fenster geschlossen ist, sollen Module kein dauerhaft aktives Live-Debugging erzwingen
• app-spezifische Debug-Darstellungen sind nur zulaessig, wenn sie fachliche Zusatzinformationen zeigen, die ueber den globalen Stream hinausgehen

Pflegehinweis

Diese Datei muss gepflegt bleiben, wenn sich Modulstruktur oder Modulregeln aendern.

Wichtige Inhalte aus dieser Datei muessen ebenfalls zentral gepflegt werden in:

• CONTENT.md
• WEITERENTWICKLUNG.md