Files
desktop/docs/CONTENT.md
Lars Gebhardt-Kusche dad3e0a629
All checks were successful
Deploy / deploy-staging (push) Successful in 25s
Deploy / deploy-production (push) Has been skipped
adssd
2026-06-26 01:45:44 +02:00

7.6 KiB

Content

Zentrale Inhaltsbasis fuer desktop.kusche.berlin.

Diese Datei dient als gemeinsame Quelle fuer:

  • Begriffe und offizielle Benennungen im System
  • Funktionsbeschreibung des aktuellen Systems
  • spaetere Inhalte fuer einen Hilfe-Bereich
  • zentrale Zusammenfassung der dezentralen README.md-Dateien

Zweck

CONTENT.md beschreibt das System fachlich und sprachlich.

Nicht hier hinein gehoeren:

  • technische Detailanweisungen fuer Entwickler
  • Go- und NoGo-Regeln fuer Umsetzung
  • nur ordnerspezifische Detailerklaerungen ohne Relevanz fuer das Gesamtsystem

Diese Inhalte liegen in:

Offizielle Begriffe

Diese Benennungen gelten projektweit und sollen in UI, Doku und Weiterentwicklung konsistent verwendet werden.

Oberflaechenbereiche

  • Desktop Die eigentliche Arbeitsflaeche mit Icons, Fenstern, Taskbar und Infobereich.

  • Infobereich Der rechte Bereich auf dem Desktop mit eingeblendeten Informationskarten oder kleinen Bereichsmodulen.

  • Tray-Bereich Der Bereich bei der Uhr bzw. Systemleiste fuer kleine Tray-Apps oder Mini-Funktionen.

  • Setup-Bereich Der zentrale Einstellungsbereich fuer Benutzer, Desktop-Typ, Apps und Bereichsauswahl. Aktuell umgesetzt ueber User Self Management.

  • Logoff-Desktop Die offene Desktop-Oberflaeche vor dem Login. Dort erscheinen nur die Desktop-Apps, die ein Admin explizit fuer die Nutzung ohne Login freigibt.

Menue-Bereiche

  • User Setting Bereich Linke Menuespalte mit User-Icon, Benutzername, Einstieg in Einstellungen und Session-Aktion.

  • Funktion-Bereich Mittlere Menuespalte mit Funktionsgruppen wie Programme.

  • Auswahlbereich Rechte Menuespalte mit den Inhalten der aktuell gewaehlten Funktionsgruppe.

Systemobjekte

  • App Eine allgemeine Anwendung. Eine App erscheint standardmaessig als Menue-Eintrag, kann zusaetzlich ein Desktop-Icon bekommen und weitere Darstellungen wie Tray-App oder Widget bereitstellen. Admins koennen die LDAP-Gruppenberechtigung pro App verwalten und festlegen, ob sie bereits ohne Login auf dem Logoff-Desktop verfuegbar ist.

  • Tray-App Eine App oder Teilfunktion im Bereich neben der Uhr. Tray-Apps sind fuer Schnellaktionen oder Visualisierungen gedacht und koennen eigenstaendig oder zusammen mit der Haupt-App genutzt werden.

  • API Die serverseitige Programmschnittstelle der Desktop-Anwendung. Sie wird im aktuellen Projekt auf demselben Host wie die Desktop-Shell unter /api/v1/... bereitgestellt.

  • Widget Ein kleines Desktop-Element ohne klassische Fensterfunktionen wie Maximieren, Minimieren, Schliessen oder Groessenaenderung. Widgets koennen eigenstaendig oder Teil einer App sein. Zielbild ist eine frei positionierbare Flaeche auf dem Desktop; aktuell werden Widgets uebergangsweise noch im rechten Infobereich gerendert.

  • Desktop Type Benutzerseitige Auswahl des Desktop-/Skin-Typs. Aktuell vorgesehen: Apple, Windows, Linux.

  • Skin Technische und visuelle Auspraegung eines Desktop-Typs, inklusive Layout, Interaktionsdetails und Asset-Zuordnung.

Aktueller Systemumfang

Stand dieser Datei:

  • gemeinsame Desktop-Shell mit den Skins Apple, Windows und Linux
  • offene Desktop-Oberflaeche vor dem Login mit eigener Login-Lasche
  • frei verschiebbare Desktop-Icons
  • Icon-Positionen lokal gespeichert, pro Benutzer und pro Skin
  • automatische Schriftfarbanpassung fuer Desktop-Icons anhand des Hintergrunds
  • Fensterverwaltung mit Oeffnen, Fokussieren, Minimieren, Maximieren und Verschieben
  • konsistentes Standard-Design fuer Fensterinhalte, sofern eine App kein eigenes UI mitbringt
  • Startmenue mit User Setting Bereich, Funktion-Bereich und Auswahlbereich
  • rechter Infobereich mit benutzerbezogener Sichtbarkeit als aktueller Uebergangsplatz fuer Widgets
  • User Self Management als Setup-App
  • Admin Apps als zentrale Admin-App fuer App-Bestand, Widgets und erste Integrations-Einstellungen
  • ZIP-basierte Modulinstallation ueber Admin Apps mit Basispruefung und Entpacken nach custom/apps/
  • getrennte Nutzersteuerung fuer Apps, Tray-Apps, Widgets und optionale Desktop-Icons
  • erster echter App-Pfad fuer installierbare Fach-Apps mit Discovery aus custom/apps/<app>/
  • Mining-Checker als erstes angebundenes klassisches Modul
  • Waehrungs-Checker als zweites angebundenes klassisches Modul mit Desktop-Widget fuer Kursaktualisierung
  • versionierte API auf demselben Host unter (staging.)desktop.kusche.berlin/api/v1/...
  • Benutzereinstellungen fuer Desktop-Skin, App-Auswahl, Tray-Apps, Widgets und Profildaten in einer eigenen Datenbanktabelle mit _user_data-Suffix
  • vorhandene JSON-Dateien dienen nur noch als Fallback oder Uebergang fuer lokale Entwicklung und Altbestaende
  • LDAP-Synchronisierung fuer Standardfelder wie Name, E-Mail, Telefon, Titel und Ort
  • Geburtsdatum aktuell bewusst nur lokal gespeichert
  • Keycloak bleibt das Auth-System

Zentrale Inhaltszusammenfassung aus bestehenden README-Dateien

Globales Projekt

Aus README.md:

  • public/ ist der Web-Root fuer die Desktop-Shell
  • src/Desktop/ enthaelt zentrale Desktop-Mechaniken
  • die API bleibt auf demselben Host wie die Desktop-Shell und wird unter /api/v1/... versioniert
  • partials/desktop/ enthaelt Shell-Templates
  • custom/apps/ bleibt Zielort fuer installierbare Fach-Apps
  • system/apps/ bleibt Zielort fuer System-Tools
  • system/shell/ bleibt Zielort fuer globale Shell-Werkzeuge und shell-nahe Desktop-Helfer
  • system/addons/ bleibt Zielort fuer optionale System-Erweiterungen und Integrationen
  • temp/nexus-module-import/ ist Rohbasis fuer importierte Nexus-Module
  • Keycloak bleibt das Auth-System
  • das globale Desktop-Debug ist als Shell-Werkzeug unter system/shell/desktop-debug/ definiert
  • der Gitea-Deploy-Status liegt als optionales Addon unter system/addons/gitea-deploy-status/

Module

Aus custom/apps/README.md:

  • installierbare Fach-Apps liegen unter custom/apps/<app>/
  • Businesslogik wird nicht in den Desktop-Core verschoben
  • ein Desktop-Modul kann eigene desktop.php, pages/, api/ und assets/ Strukturen mitbringen
  • Modul-Assets muessen nicht in den globalen Desktop-Asset-Baum kopiert werden

Aktueller Modulstand

  • Mining-Checker ist eine Desktop-App aus custom/apps/mining-checker/
  • Waehrungs-Checker ist eine Desktop-App aus custom/apps/fx-rates/
  • die Desktop-Shell kann Moduldefinitionen zentral erkennen und als App bereitstellen
  • wiederverwendbare Modul-Helfer liegen im globalen Kern, die Fachlogik bleibt im Modul

Skins

Aus skins/README.md:

  • skins/<skin>/profile.php enthaelt Skin-Metadaten
  • skins/<skin>/vendor/ enthaelt Rohquellen und Quellpacks
  • public/assets/desktop/skins/<skin>/ enthaelt auslieferbare CSS/JS-Dateien
  • public/assets/desktop/skin-icons/<skin>/ enthaelt verwendete Web-Icons

Hilfe-Bereich Vorbereitung

Fuer einen spaeteren Hilfebereich sollen Inhalte aus dieser Datei in Themenblcke uebernommen werden:

  • Begriffe
  • Desktop bedienen
  • Menue verstehen
  • Fenster verwenden
  • Infobereich und Widgets konfigurieren
  • Apps und Desktop Type verwalten
  • Module verstehen und starten
  • API-Pfade und Versionen verstehen
  • Benutzerdaten und Synchronisierung

Die Inhalte sollen spaeter moeglichst nicht neu erfunden, sondern aus den zentral gepflegten Dateien abgeleitet werden.