Widget-Rahmen: Widgets sind Beschreibungen, keine Kaesten in der Seite
widgetAnmelden({ id, titel, wo, sichtbar, laden, leer, inhalt, takt }) —
der Rahmen macht daraus ein Fenster in der Spalte (Terminal) oder ein
Schild (Desktop), kennt lädt/fertig/nichts da/Fehler und haelt den
Nachladetakt. Benutzer, Wetter und Systemzustand sind umgestellt; aus
index.html sind vier feste Kaesten verschwunden und aus dem Raster die
Einzelplaetze.
Zwei Dinge, die erst dabei sichtbar wurden:
- Der Server meldete 'kein Ort eingestellt' und 'Dienst nicht
erreichbar' beide als 204. Ein Ausfall sah damit aus wie ein
abgeschaltetes Widget. Ausfall ist jetzt 502, mit Test.
- Die Reihenfolge haengt nicht mehr an der Modulauswertung: Seit
glyphs.js seine Raster mit await auf oberster Ebene laedt, laufen
Module ohne Symbole vorher durch — der Systemzustand stand deshalb
ueber dem Benutzer. widgetsOrdnen() macht die Reihenfolge zur Angabe,
und genau dort haengt spaeter die im Server gespeicherte ein.
This commit is contained in:
marc committed
1 parent
981a2331df
commit
b7cc06b7c1
12 files changed
+461
-180
No files matched your search
@@ -165,51 +165,36 @@ ist am 29.08.2026 weggefallen: Aether und InkNote liegen längst unter
|
||||
erst nach der Sitzung. **Die HoneyBar weiß dort jetzt, wer schaut.** Was bleibt,
|
||||
ist die Frage, ob es sich bei einem Nutzer lohnt.
|
||||
|
||||
### 1.4 HoneyOS selbst als PWA
|
||||
### 1.4 Widget-Rahmen — ✅ gebaut (30.08.2026)
|
||||
|
||||
Heute ist HoneyOS eine Website: Es hat `theme-color`, aber kein Manifest, kein
|
||||
Symbol und keinen Service Worker — installierbar ist es damit nicht. Am Handy
|
||||
landet man also im Browser mit Adressleiste, während Aether und InkNote als
|
||||
eigene Apps danebenliegen. Das ist genau der Bruch, den das Ganze eigentlich
|
||||
verhindern soll: Der Schreibtisch sollte sich am wenigsten nach Website
|
||||
anfühlen.
|
||||
Ein Widget ist jetzt eine **Beschreibung**, kein Stück HTML im Dokument:
|
||||
|
||||
Was dazugehört, klein bis groß:
|
||||
```js
|
||||
widgetAnmelden({
|
||||
id, titel,
|
||||
wo: ["terminal", "desktop"], // wo es erscheinen darf
|
||||
sichtbar: () => …, // Schalter aus → gar nicht erst da
|
||||
laden: async () => false|void, // false = es gibt nichts zu zeigen
|
||||
leer: "verbergen" | "Text", // was dann passiert
|
||||
inhalt: () => "<html>",
|
||||
takt: 600000, // Nachladen, optional
|
||||
})
|
||||
```
|
||||
|
||||
1. **Manifest** — Name, Startadresse, `display: standalone`, Hintergrund- und
|
||||
Themenfarbe. Die Farben sollten der eingestellten Röhre folgen; sie liegen
|
||||
im Server, das Manifest kann also erzeugt statt fest hinterlegt werden
|
||||
(Aether macht das beim Symbol schon so).
|
||||
2. **Symbol** — ein Pixelglyph in 192 und 512 px, im Amber-Look. Passt zum
|
||||
Rest und ist ohne fremde Werkzeuge zu machen.
|
||||
3. **Service Worker** — nötig für die Installierbarkeit. Hier ist zu
|
||||
entscheiden, was er überhaupt soll (siehe unten).
|
||||
Der Rahmen (`web/js/widgets/rahmen.js`) macht daraus im Terminal-Modus ein
|
||||
Fenster in der Widgetspalte und im Desktop-Modus ein Schild, kennt die vier
|
||||
Zustände (lädt · fertig · nichts da · Fehler) und hält den Nachladetakt. Ein
|
||||
Widget, das seinen Server nicht erreicht, sagt das **in seinem eigenen Rahmen**
|
||||
und reißt weder den Schreibtisch noch die anderen Widgets mit.
|
||||
|
||||
**Die eigentliche Frage ist der Offline-Fall.** HoneyOS zeigt fremde Apps und
|
||||
später deren Daten — ohne Netz gibt es davon nichts. Ein Schreibtisch, der
|
||||
offline mit leeren Kacheln dasteht, ist schlimmer als ein ehrlicher Hinweis.
|
||||
Sinnvoll wäre: Oberfläche und App-Liste im Cache, damit man die Symbole sieht
|
||||
und antippen kann, und ein deutlicher Vermerk „ohne Verbindung". Widgets
|
||||
bleiben leer, statt Altes von gestern als aktuell auszugeben.
|
||||
Umgestellt sind Benutzer, Wetter und der Systemzustand. Aus der `index.html`
|
||||
sind damit vier fest verdrahtete Kästen verschwunden, und aus dem Raster die
|
||||
Einzelplätze — vorher hätte das dritte Widget beides wieder angefasst.
|
||||
|
||||
**Aus dem Aether-Debakel gelernt und hier von Anfang an zu beachten:** Ein
|
||||
Eintrag im Cache ist eine ganze Antwort **samt Kopfzeilen**. Wird die Startseite
|
||||
vorab abgelegt, friert damit auch ihre CSP ein — und eine Änderung an der
|
||||
Konfiguration erreicht den Browser nie wieder. Also Navigationen Netz zuerst,
|
||||
Cache nur als Rückfall.
|
||||
|
||||
**Reihenfolge:** Erst umziehen (siehe unten), dann installierbar machen. Ein
|
||||
Ursprungswechsel macht aus einer installierten PWA eine fremde App — wer
|
||||
vorher installiert, installiert zweimal.
|
||||
|
||||
### 1.5 Widget-Rahmen
|
||||
|
||||
Ein Fenstertyp, der einen Inhalt holt, ihn anzeigt und sich benimmt, wenn es
|
||||
schiefgeht: lädt gerade, nichts da, nicht angemeldet, Fehler. Einmal richtig
|
||||
gebaut, kostet jedes weitere Widget danach fast nichts.
|
||||
|
||||
Muss in **beiden Betriebsarten** funktionieren — im Desktop als Fenster, im
|
||||
Terminal als Kachel.
|
||||
**Was dabei offen gelassen wurde:** die dritte Form. Widgets sollen später auch
|
||||
als Aufklappfeld in der HoneyBar leben können, deshalb erzeugt `inhalt()` nur
|
||||
den Kern; die Verpackung entsteht im Rahmen. Und die Reihenfolge ist eine
|
||||
Liste — genau das, was „Widgets verschieben" braucht.
|
||||
|
||||
## 2 · Erste Widgets
|
||||
|
||||
@@ -424,7 +409,7 @@ schon gebaut) oder am Handy Pfeiltasten statt Ziehen anbieten. Nicht vergessen:
|
||||
Ohne das ist die Funktion am Handy schlicht nicht da.
|
||||
|
||||
Voraussetzung ist ein Widget-Verzeichnis — heute stehen Benutzer und Wetter
|
||||
fest im HTML. Sinnvoll zusammen mit dem Widget-Rahmen (1.5) zu bauen, nicht
|
||||
fest im HTML. Sinnvoll zusammen mit dem Widget-Rahmen (1.4) zu bauen, nicht
|
||||
davor.
|
||||
|
||||
### Widgets in der HoneyBar selbst
|
||||
@@ -434,9 +419,9 @@ ist aber die Seite, die man am seltensten offen hat — die HoneyBar dagegen ist
|
||||
überall. Naheliegend also: ein Knopf in der HoneyBar klappt dasselbe Widget als
|
||||
kleines Feld auf, ohne die App zu verlassen.
|
||||
|
||||
Technisch ist das dieselbe Sache wie 1.5, nur ein zweites Zuhause für denselben
|
||||
Technisch ist das dieselbe Sache wie 1.4, nur ein zweites Zuhause für denselben
|
||||
Inhalt: Der Rahmen muss dann drei Formen können — Fenster, Kachel, Aufklappfeld.
|
||||
Das ist beim **Bauen** von 1.5 zu bedenken, hinterher wird es teuer.
|
||||
Das ist beim **Bauen** von 1.4 zu bedenken, hinterher wird es teuer.
|
||||
|
||||
Für Widgets, die nur sich selbst brauchen (Wetter, Bild, Uhr), ist das
|
||||
geschenkt — sie fragen HoneyOS, nicht die App.
|
||||
@@ -445,6 +430,48 @@ geschenkt — sie fragen HoneyOS, nicht die App.
|
||||
|
||||
## 3 · Ausbau
|
||||
|
||||
### 3.x HoneyOS selbst als PWA — zurückgestellt (30.08.2026)
|
||||
|
||||
Heute ist HoneyOS eine Website: Es hat `theme-color`, aber kein Manifest, kein
|
||||
Symbol und keinen Service Worker — installierbar ist es damit nicht. Am Handy
|
||||
landet man also im Browser mit Adressleiste, während Aether und InkNote als
|
||||
eigene Apps danebenliegen. Das ist genau der Bruch, den das Ganze eigentlich
|
||||
verhindern soll: Der Schreibtisch sollte sich am wenigsten nach Website
|
||||
anfühlen.
|
||||
|
||||
Was dazugehört, klein bis groß:
|
||||
|
||||
1. **Manifest** — Name, Startadresse, `display: standalone`, Hintergrund- und
|
||||
Themenfarbe. Die Farben sollten der eingestellten Röhre folgen; sie liegen
|
||||
im Server, das Manifest kann also erzeugt statt fest hinterlegt werden
|
||||
(Aether macht das beim Symbol schon so).
|
||||
2. **Symbol** — ein Pixelglyph in 192 und 512 px, im Amber-Look. Passt zum
|
||||
Rest und ist ohne fremde Werkzeuge zu machen.
|
||||
3. **Service Worker** — nötig für die Installierbarkeit. Hier ist zu
|
||||
entscheiden, was er überhaupt soll (siehe unten).
|
||||
|
||||
**Die eigentliche Frage ist der Offline-Fall.** HoneyOS zeigt fremde Apps und
|
||||
später deren Daten — ohne Netz gibt es davon nichts. Ein Schreibtisch, der
|
||||
offline mit leeren Kacheln dasteht, ist schlimmer als ein ehrlicher Hinweis.
|
||||
Sinnvoll wäre: Oberfläche und App-Liste im Cache, damit man die Symbole sieht
|
||||
und antippen kann, und ein deutlicher Vermerk „ohne Verbindung". Widgets
|
||||
bleiben leer, statt Altes von gestern als aktuell auszugeben.
|
||||
|
||||
**Aus dem Aether-Debakel gelernt und hier von Anfang an zu beachten:** Ein
|
||||
Eintrag im Cache ist eine ganze Antwort **samt Kopfzeilen**. Wird die Startseite
|
||||
vorab abgelegt, friert damit auch ihre CSP ein — und eine Änderung an der
|
||||
Konfiguration erreicht den Browser nie wieder. Also Navigationen Netz zuerst,
|
||||
Cache nur als Rückfall.
|
||||
|
||||
**Zurückgestellt (Marc, 30.08.2026): erst die Hauptfunktionen, dann das
|
||||
Gehäuse.** Die PWA ist mehr Gefühl als Funktion — sie macht nichts möglich, was
|
||||
heute nicht ginge, während der Widget-Rahmen darunter alles Weitere trägt.
|
||||
|
||||
**Reihenfolge:** Erst umziehen (siehe unten), dann installierbar machen. Ein
|
||||
Ursprungswechsel macht aus einer installierten PWA eine fremde App — wer
|
||||
vorher installiert, installiert zweimal.
|
||||
|
||||
|
||||
- Welche Widgets wo liegen, **pro Nutzer im Server** merken — die Einstellungen
|
||||
liegen ohnehin schon dort, das ist eine Erweiterung, kein Neubau
|
||||
- Widgets im Terminal-Modus
|
||||
|
||||
Reference in new issue
Block a user