adasdadad

docs/ANLEITUNG.md

@@ -17,8 +17,8 @@ Der Desktop besteht aus mehreren Hauptbereichen:
 - `Infobereich`
   Rechter Seitenbereich fuer eingeblendete Informationskarten.
 
-- `Widget-Bereich`
-  Bereich bei Uhr und Systemleiste fuer kleine Mini-Funktionen.
+- `Tray-Bereich`
+  Bereich bei Uhr und Systemleiste fuer kleine Tray-Apps und Mini-Funktionen.
 
 ## Startmenue verwenden
 
@@ -58,10 +58,12 @@ Dort koennen derzeit insbesondere verwaltet werden:
 
 - `Desktop Type` beziehungsweise Skin-Auswahl
 - persoenliche Benutzerdaten
-- sichtbare Apps
-- Inhalte des `Infobereichs`
+- aktivierte `Apps` im Menue
+- optionale `Desktop-Icons` fuer geeignete Apps
+- aktivierte `Tray-Apps`
+- aktivierte `Widgets`
 
-Administratoren nutzen zusaetzlich `Admin Apps` fuer den globalen App-Bestand, die Widget-Uebersicht und erste Integrations-Einstellungen wie den Gitea-Deploy-Status.
+Administratoren nutzen zusaetzlich `Admin Apps` fuer den globalen App-Bestand, Installationswege, LDAP-Gruppenberechtigungen und erste Integrations-Einstellungen wie den Gitea-Deploy-Status.
 
 ## Module
 
@@ -74,10 +76,12 @@ Aktuell gilt:
 - Modul-Businesslogik bleibt im Modul und wird nicht in den Desktop-Core verschoben
 - gemeinsame Desktop-Mechaniken wie Fenster, Asset-Einbindung und Zugriffsschutz werden global bereitgestellt
 
-## Widgets und Cronjobs
+## Tray-Apps, Widgets und Cronjobs
 
-- Widgets koennen von Modulen bereitgestellt werden, wenn das Modul diese Funktion im Manifest hinterlegt.
-- Widget-Funktionen stehen nur dann zur Auswahl, wenn die zugehoerige App fuer den Benutzer installiert oder aktiviert ist.
+- `Tray-Apps` liegen im Bereich neben der Uhr und sind fuer Schnellaktionen oder kleine Visualisierungen gedacht.
+- `Widgets` koennen von Modulen bereitgestellt werden, wenn das Modul diese Funktion im Manifest hinterlegt.
+- Widgets sind fachlich kleine Desktop-Elemente ohne Fensterfunktionen; aktuell erscheinen sie technisch noch uebergangsweise im rechten `Infobereich`.
+- Widget- und Tray-Funktionen stehen nur dann zur Auswahl, wenn der Benutzer auf die zugrundeliegende App Zugriff hat.
 - Das `Cron Tool` ist ein globales `Systemtool` fuer Administratoren.
 - Dort erscheinen Modul-Cronjobs automatisch, sobald ein Modul sie in `module.json` hinterlegt.
 - Cron-Aufrufe laufen auf demselben Host und verwenden dieselbe Projektbasis wie der Desktop.
@@ -89,7 +93,7 @@ Der `Waehrungs-Checker` verwaltet gespeicherte Wechselkurse, Kurs-Historie, Umre
 - das Oeffnen der App loest keinen externen Abruf aus
 - ein manueller Abruf ist nur erlaubt, wenn die letzten gespeicherten Kurse aelter als die konfigurierte Sperrzeit sind
 - mit `force` kann ein Abruf bewusst erzwungen werden
-- das zugehoerige Widget im `Widget-Bereich` nutzt dieselbe Regel wie App und API
+- das zugehoerige Widget nutzt dieselbe Regel wie App und API
 
 ## Benutzerdaten
 
@@ -116,14 +120,15 @@ Der `Infobereich` ist der rechte Desktopbereich.
 
 - Inhalte koennen benutzerbezogen ein- oder ausgeblendet werden.
 - Aenderungen sollen gespeichert bleiben.
-- Der `Infobereich` ist nicht identisch mit dem `Widget-Bereich`.
+- Der `Infobereich` ist nicht identisch mit dem `Tray-Bereich`.
+- Widgets werden aktuell noch dort eingeblendet, sollen spaeter aber frei auf dem Desktop positionierbar sein.
 
 ## Begriffsregel
 
 Fuer sprachliche Konsistenz gilt:
 
 - rechte Desktopseite: `Infobereich`
-- Mini-Apps an Uhr/Systemleiste: `Widget-Bereich`
+- Mini-Apps an Uhr/Systemleiste: `Tray-Bereich`
 - linke Startmenuespalte: `User Setting Bereich`
 - mittlere Startmenuespalte: `Funktion-Bereich`
 - rechte Startmenuespalte: `Auswahlbereich`

docs/CONTENT.md

@@ -36,8 +36,8 @@ Diese Benennungen gelten projektweit und sollen in UI, Doku und Weiterentwicklun
 - `Infobereich`
   Der rechte Bereich auf dem Desktop mit eingeblendeten Informationskarten oder kleinen Bereichsmodulen.
 
-- `Widget-Bereich`
-  Der Bereich bei der Uhr bzw. Systemleiste fuer kleine Widgets oder Mini-Apps.
+- `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`.
@@ -56,13 +56,16 @@ Diese Benennungen gelten projektweit und sollen in UI, Doku und Weiterentwicklun
 ### Systemobjekte
 
 - `App`
-  Ein bereitgestelltes System-Tool oder Modul. Eine App kann als Desktop-App, Menue-App, Systembar-Eintrag oder Quelle fuer Widgets/Funktionen auftreten.
+  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.
+
+- `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`
-  Eine kleine Funktion oder Mini-Anzeige. Widgets sind nicht automatisch identisch mit Apps. Eine App kann Widgets bereitstellen, muss es aber nicht.
+  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`.
@@ -81,14 +84,15 @@ Stand dieser Datei:
 - 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
+- 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
+- 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, Infobereich und Profildaten in einer eigenen Datenbanktabelle mit `_user_data`-Suffix
+- 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
@@ -146,7 +150,7 @@ Fuer einen spaeteren Hilfebereich sollen Inhalte aus dieser Datei in Themenblcke
 - `Desktop bedienen`
 - `Menue verstehen`
 - `Fenster verwenden`
-- `Infobereich konfigurieren`
+- `Infobereich und Widgets konfigurieren`
 - `Apps und Desktop Type verwalten`
 - `Module verstehen und starten`
 - `API-Pfade und Versionen verstehen`

docs/README.md

@@ -60,10 +60,11 @@ Aktuell wichtig:
 - der Boersenchecker ist als importierte Desktop-App unter `custom/apps/boersenchecker/` angebunden
 - Modul-Assets koennen ueber einen gemeinsamen Auslieferungsweg aus dem Modul selbst geladen werden
 - die API bleibt vorerst auf demselben Host und wird nicht auf `api.desktop.kusche.berlin` ausgelagert
-- das gemeinsame Admin-Debug-Widget neben der Uhr ist der Standard fuer Live-Debugging in Desktop und Native-Apps
+- die gemeinsame Admin-Debug-Tray-Funktion neben der Uhr ist der Standard fuer Live-Debugging in Desktop und Native-Apps
 - der Waehrungs-Checker stellt zusaetzlich ein Desktop-Widget fuer manuelle Kursaktualisierung bereit
 - der Gitea-Deploy-Status liegt als optionales Addon unter `system/addons/gitea-deploy-status/` und wird serverseitig ueber `config/gitea.php` angebunden
 - `Admin Apps` ist als globales `Systemtool` fuer App-Bestand, Widgets und erste Integrations-Einstellungen vorhanden
+- LDAP-Gruppenberechtigungen fuer Apps werden zentral ueber die Desktop-App-Verwaltung gepflegt
 - das Oeffnen des Waehrungs-Checkers darf keinen externen Kursabruf ausloesen; Refreshes laufen nur nach Altersregel oder mit `force`
 - `Systemtools` und installierbare `Module` werden getrennt behandelt; Systemtools sind nicht Teil der Benutzer-Installationsauswahl
 - das `Cron Tool` ist als globales Systemtool vorhanden und sammelt Modul-Cronjobs automatisch ueber Manifest-Metadaten

docs/WEITERENTWICKLUNG.md

@@ -29,7 +29,7 @@ Verbindlich ist:
 - globale Debug-Infrastruktur zentral halten und ueber alle Apps wiederverwenden
 - Begriffe in UI und Doku konsistent nach `CONTENT.md` verwenden
 - Apps als bereitgestellte Systemfunktionen denken, nicht nur als sichtbare Fenster
-- Unterschiede zwischen `App`, `Infobereich` und `Widget-Bereich` sauber trennen
+- Unterschiede zwischen `App`, `Tray-App`, `Widget`, `Infobereich` und `Tray-Bereich` sauber trennen
 - lokale Persistenz und spaetere Backend-Synchronisierung getrennt vorbereiten
 - Nutzerdaten und Desktop-Preferences bevorzugt datenbankbasiert speichern, nicht dateibasiert
 - `README.md`-Dateien in Teilbereichen aktuell halten
@@ -38,6 +38,7 @@ Verbindlich ist:
 - importierte Module mit eigener API ueber konsistente `public/api/<modul>/index.php`-Shims an die gemeinsame Desktop-Auth anbinden
 - importierte Module mit eigener Fensterseite ueber konsistente `public/apps/<modul>/index.php`-Shims anbinden
 - Widget-Logik einer App muss dieselben fachlichen Regeln wie die App-API verwenden, nicht eigene Sonderwege
+- App-Berechtigungen fuer LDAP-Gruppen muessen zentral und pro App nachvollziehbar pflegbar bleiben
 - Systemtools duerfen nicht als installierbare Module modelliert werden
 - neue Modul-Widgets und Modul-Cronjobs sollen ueber Manifest-Metadaten registriert werden statt ueber versteckte Sonderlisten
 
@@ -66,6 +67,8 @@ Verbindlich ist:
 - die Definition globaler Debug- und Shell-Werkzeuge soll in `system/shell/` liegen und nicht lose in `public/` oder verstreut im JS
 - API und Desktop teilen sich im aktuellen Zielbild denselben Host; offizielle Basis ist `/api/v1/...`
 - App, API und Widget einer Fachfunktion muessen dieselben Sperr- und Force-Regeln fuer externe Abrufe nutzen
+- Nutzersteuerung fuer Menue-App, Tray-App, Desktop-Icon und Widget muss getrennt speicherbar bleiben
+- Widgets sollen fachlich als Desktop-Elemente gedacht werden; die aktuelle Einblendung im rechten Infobereich ist nur ein Uebergang und darf spaeter sauber ersetzt werden
 - die Trennung `core` / `system_tool` / `module` ist in Metadaten, Startmenue und Benutzer-Setup konsistent zu halten
 - Cron-Endpunkte muessen auf demselben Host laufen und duerfen keine separate Standard-API-Domain voraussetzen
 - Skins definieren Darstellung und Interaktionsdetails, nicht die Fachlogik