docs(ideen): Widgets in der Leiste, persönliche Apps, Grenzen des Aussehens

Dazu die Lehre aus der eingebackenen Adresse: nichts über die Leiste gehört in
den Bau der Apps — weder wegen des fertigen Abbilds noch wegen des Caches der
PWA.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

IDEAS.md

@@ -102,6 +102,22 @@ Eines bauen, benutzen, dann entscheiden.
 - **Speicherplatz** (Aether) — eine Zahl, ein Balken, billig zu bauen
 - **Letzte Notizen** (InkNote) — braucht 1.3, kommt also später
 
+### Widgets in der Leiste selbst
+
+Bisher sind Widgets als Fenster auf dem Schreibtisch gedacht. Der Schreibtisch
+ist aber die Seite, die man am seltensten offen hat — die Leiste dagegen ist
+überall. Naheliegend also: ein Knopf in der Leiste klappt dasselbe Widget als
+kleines Feld auf, ohne die App zu verlassen.
+
+Technisch ist das dieselbe Sache wie 1.6, 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.6 zu bedenken, hinterher wird es teuer.
+
+**Eine Einschränkung vorweg:** Die Leiste läuft in einer fremden App. Ein
+Aether-Widget in der Leiste **von InkNote aus** braucht deshalb dasselbe, was
+1.4 für den Schreibtisch regelt, nur für einen weiteren Ursprung. In der App
+selbst (Aether-Widget in Aethers eigener Leiste) ist es geschenkt.
+
 → Anfangen mit **letzte Dateien**. Wenn du danach merkst, dass du morgens
 wirklich draufschaust, lohnt der Rest. Wenn nicht, war es ein Abend.
 
@@ -178,6 +194,41 @@ Wird er doch behalten, gehört mindestens eingebaut: **mit Token-Schlüssel nur
 relative Pfade zulassen**, damit ein Ausweis nie an einen fremden Ursprung geht.
 Drei Zeilen.
 
+### Persönliche Apps je Nutzer?
+
+Heute gilt die App-Liste für alle — bewusst so, siehe „Bewusst nicht geplant".
+Denkbar wäre daneben eine kleine eigene Liste je Konto.
+
+**Was dagegen spricht, ist nicht der Aufwand, sondern eine harte Grenze:** Auf
+dem Schreibtisch ginge es sofort (dort ist man angemeldet). In der Leiste einer
+fremden App ginge es **nicht**, solange HoneyOS auf einer anderen Site liegt als
+die App — der Browser schickt die HoneyOS-Sitzung dann nicht mit, und der
+Schlüssel für die App-Liste weiß nicht, wer schaut. Die Leiste zeigte also die
+gemeinsamen Apps, der Schreibtisch zusätzlich die eigenen. Zwei verschiedene
+Listen an zwei Stellen ist schlechter als eine.
+
+**Liegt alles unter derselben Domain** (`os.beispiel.duckdns.org` +
+`cloud.beispiel.duckdns.org`), fällt die Grenze weg: die Sitzung wird
+mitgeschickt, die Leiste weiß, wer da ist. Seit dem Umzug auf
+`os.asianxpolish.duckdns.org` ist genau das der Fall — persönliche Apps sind
+damit machbar geworden.
+
+→ **Vorschlag: zurückstellen, bis es mehr als ein Konto gibt.** Bei einer
+Person ist „persönlich" und „für alle" dasselbe. Der Weg ist aber offen und
+sollte es bleiben: nichts einbauen, was von einer einzigen gemeinsamen Liste
+ausgeht.
+
+### Wie weit soll das Aussehen der Leiste einstellbar sein?
+
+Röhre, Leuchten und Scanlines kommen schon aus HoneyOS (1.1). Offen ist, was
+darüber hinaus in die Einstellungen gehört: Höhe, Schriftgröße, Position (oben
+oder unten), ob der Name der App danebensteht.
+
+**Die Versuchung ist, alles einstellbar zu machen.** Jede Einstellung ist aber
+eine Verzweigung, die für immer funktionieren muss. Sinnvoll wäre der Schnitt:
+Farbe und Verhalten ja (das ändert man wirklich), Maße nein (die stellt man
+einmal ein und nie wieder — dann kann es auch gleich richtig fest stehen).
+
 ### Ideen hier oder als Gitea-Issues?
 
 Vorerst hier. Issues erst, wenn etwas konkret als Nächstes drankommt und der
@@ -193,6 +244,13 @@ Damit es nicht alle paar Monate neu diskutiert wird:
   (`helmet()`) verbieten es beide von sich aus, und das aus gutem Grund. Es
   würde Clickjacking-Schutz, PWA-Installierbarkeit und InkNotes Offline-Betrieb
   kosten. Widgets zeigen **Daten**, die Apps bleiben in ihrem eigenen Tab.
+- **Nichts über die Leiste wird beim Bauen der Apps eingebacken.** Die Adresse
+  stand einmal fest in Aethers `index.html`. Das war aus zwei Gründen falsch:
+  Ein fertiges Abbild lässt sich dann nicht über die `.env` umziehen, und der
+  Service Worker der PWA hält die alte `index.html` im Cache, so dass eine
+  Änderung selbst nach dem Neubau noch nicht ankommt. Ursprung und Schlüssel
+  holt sich die App deshalb zur Laufzeit vom eigenen Server und hängt das
+  Skript selbst ein.
 - **Das Skript wird mit `defer` eingebunden.** Ohne wartet der Seitenaufbau der
   App darauf. Ist HoneyOS langsam oder aus, dürfte eine Zierleiste den Start von
   Aether nicht verzögern.