docs: Reihenfolge umgestellt, Sichtbarkeit der Leiste als offene Frage

Die Leiste soll zuerst die serverseitige Röhre übernehmen — kleinster
Eingriff, größte Wirkung fürs "ein System"-Gefühl. Danach Systemmenü im
Logo, dann die App-Schublade mit Symbolen.

Neu als offene Entscheidung: wie sichtbar die Leiste sein darf. Sie ist bei
jedem Aufruf der App da, auch wenn man mit HoneyOS gerade nichts zu tun hat.
Vorschlag steht dabei, ebenso der Hinweis, dass es keine Einbahnstraße ist.

Ausserdem defer an der Script-Zeile in README und Demo.

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

IDEAS.md

@@ -11,21 +11,45 @@ wirklich hinschaut.
 
 ## 1 · Fundament
 
-Ohne diese Stücke ist alles danach nicht möglich.
+Ohne diese Stücke ist alles danach nicht möglich. Reihenfolge nach dem
+Verhältnis von Aufwand zu spürbarer Wirkung.
 
-### 1.1 App-Schublade in den Apps
+### 1.1 Die Leiste trägt deine Röhre
 
-**Die Idee:** In Aether und InkNote ein Knopf, der eine Übersicht aller Apps
+**Das größte Gefühl für den kleinsten Eingriff.** Heute ist `honeybar.js` fest
-aufklappt — mit Symbol. Die Liste kommt aus HoneyOS, nicht aus der App. Eine
+bernsteinfarben — auch wenn dein Schreibtisch auf grün steht. Genau dieser Bruch
-neue App trägt man einmal ein und sie taucht überall auf, ohne dass eine App
+lässt die Leiste wie etwas Angeklebtes wirken statt wie Teil eines Systems.
-angefasst wird.
 
-**Stand:** Die Hälfte steht schon. `honeybar.js` holt die Liste aus `/api/apps`,
+Die Einstellungen liegen seit 24.08. serverseitig. Liest die Leiste sie mit, gilt:
-bringt seine eigene Sitzung mit und hat bereits ein Aufklappmenü. Was fehlt, ist
+Röhre in InkNote auf grün stellen → Schreibtisch, Aether und jede weitere App
-die Darstellung als Raster mit Symbolen statt einer Textliste.
+ziehen mit, weil es dieselbe Einstellung an derselben Stelle ist.
 
-**Der eigentliche Punkt: die Symbole.** Heute lebt das Pixelraster in `os.js`
+Zu tun: die fest eingetragenen Farbwerte im Shadow DOM durch dieselben
-(`GLYPHS`), die Leiste kennt es nicht und zeigt nur Namen. Zwei Wege:
+`--p*`-Variablen ersetzen, die `style.css` schon benutzt, und beim Start
+`/api/me` mitnehmen (holt die Leiste ohnehin schon für den Namen).
+
+### 1.2 Systemmenü im Logo
+
+Das `■ HONEYOS` links ist heute nur ein Link zum Schreibtisch. Wie ein
+Apfel-Menü gehören darunter: Schreibtisch · Einstellungen · Abmelden. Dann sind
+die HoneyOS-Sachen aus jeder App heraus erreichbar, ohne sie zu verlassen.
+
+Die Einstellungen sind derselbe Inhalt wie auf dem Schreibtisch — sie liegen im
+Server, also stimmt beides automatisch überein.
+
+### 1.3 App-Schublade mit Symbolen
+
+**Die Idee:** ein Knopf, der eine Übersicht aller Apps aufklappt — mit Symbol.
+Die Liste kommt aus HoneyOS. Eine neue App trägt man einmal ein und sie taucht
+überall auf, ohne dass eine App angefasst wird.
+
+**Stand:** Die Hälfte steht. `honeybar.js` holt die Liste aus `/api/apps`, bringt
+seine Sitzung mit und hat ein Aufklappmenü. Es fehlt die Darstellung als Raster
+mit Symbolen — heute sind es Textknöpfe. Bei zwei Apps geht das noch, ab vier
+wird es eng, am Handy sofort.
+
+**Der eigentliche Punkt: die Symbole.** Das Pixelraster lebt in `os.js`
+(`GLYPHS`), die Leiste kennt es nicht. Zwei Wege:
 
 - **Pixelglyphen teilen** — `GLYPHS` + `glyphSvg()` in eine eigene Datei, die
   Desktop und Leiste beide laden. Kein Upload, kein Speicher, passt zum Look.
@@ -34,10 +58,10 @@ die Darstellung als Raster mit Symbolen statt einer Textliste.
   Flexibler, aber: Speicher, Größenbegrenzungen, Auslieferung, und der
   Retro-Look bekommt bunte Fremdkörper.
 
-→ **Empfehlung: Pixelglyphen teilen.** Eine gemeinsame Datei löst es. Bilder
+→ **Empfehlung: Pixelglyphen teilen.** Bilder später nachrüsten, falls je eine
-später nachrüsten, falls je eine App dabei ist, für die kein Symbol passt.
+App dabei ist, für die kein Symbol passt.
 
-### 1.2 CORS in Aether
+### 1.4 CORS in Aether
 
 Damit der Desktop Aether überhaupt etwas fragen darf. Aethers Sitzung ist ein
 Cookie, und weil alles unter derselben Domain liegt, schickt der Browser es
@@ -47,7 +71,7 @@ schon heute mit — es fehlt allein die Freigabe im Go-Backend
 Kleiner Eingriff, aber **die Voraussetzung für jedes Aether-Widget** und
 nebenbei auch für die Anmeldeanzeige auf der Kachel.
 
-### 1.3 InkNote: Sitzung zusätzlich als Cookie
+### 1.5 InkNote: Sitzung zusätzlich als Cookie
 
 InkNote weist sich mit einem Bearer-Token aus, der im localStorage liegt. Der
 ist **pro Domain** — von `os.…` aus grundsätzlich unerreichbar, und daran ändert
@@ -55,13 +79,11 @@ keine Konfiguration etwas.
 
 Solange das so bleibt, kann HoneyOS **keine InkNote-Daten anzeigen**. Der Weg
 wäre, dass InkNote seine Sitzung zusätzlich als `HttpOnly`-Cookie setzt; der
-Token-Weg kann daneben bleiben, damit die PWA und der Offline-Betrieb
+Token-Weg kann daneben bleiben, damit PWA und Offline-Betrieb unangetastet sind.
-unangetastet bleiben.
 
-Erledigt das zugleich: der Token-Schlüssel in der App-Verwaltung wird überflüssig
+Erledigt zugleich den Token-Schlüssel (siehe „Offene Entscheidungen").
-(siehe „Offene Entscheidungen").
 
-### 1.4 Widget-Rahmen im Desktop
+### 1.6 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
@@ -70,8 +92,6 @@ gebaut, kostet jedes weitere Widget danach fast nichts.
 Muss in **beiden Betriebsarten** funktionieren — im Desktop als Fenster, im
 Terminal als Kachel.
 
----
-
 ## 2 · Erste Widgets
 
 Eines bauen, benutzen, dann entscheiden.
@@ -98,6 +118,36 @@ wirklich draufschaust, lohnt der Rest. Wenn nicht, war es ein Abend.
 
 ## Offene Entscheidungen
 
+### Wie sichtbar darf die Leiste sein?
+
+**Der Zwiespalt:** Die Zeile steht im HTML der App, also ist die Leiste bei
+*jedem* Aufruf da — auch wenn man die Cloud einfach direkt öffnet und mit
+HoneyOS gerade nichts zu tun hat. 32 px, dauerhaft, in einer App, die man auch
+für sich allein benutzt. Am Handy in einer installierten PWA wiegt das schwerer
+als am großen Schirm.
+
+Möglichkeiten, von viel nach wenig Platz:
+
+| | Platz | Gefühl |
+|---|---|---|
+| volle Leiste | 32 px immer | am ehesten „OS" |
+| schmaler Streifen, klappt bei Berührung auf | 4 px | immer erreichbar, nie im Weg |
+| nur ein Eckknopf | ~0 | praktisch, aber keine Leiste mehr |
+| `data-push="none"` (liegt darüber) | 0 im Layout | verdeckt die Kopfzeile der App |
+| ganz aus | 0 | schon eingebaut („leiste ausblenden") |
+
+→ **Vorschlag: am Rechner die volle Leiste, am Handy der schmale Streifen.**
+Als Einstellung, nicht fest verdrahtet — dann lässt sich die Meinung ändern,
+ohne etwas neu zu bauen.
+
+**Wichtig für die Entscheidung:** Das ist keine Einbahnstraße. In den Apps steht
+nur ein Verweis; das Verhalten der Leiste liegt zentral in HoneyOS. Aussehen,
+Höhe, Auto-Verstecken, Abschaffen — alles eine Änderung an einer Stelle, ohne
+Aether oder InkNote neu zu bauen.
+
+→ **Erst in einer App einbauen, eine Woche benutzen, dann entscheiden.** Nicht
+in beide gleichzeitig.
+
 ### Token-Schlüssel behalten oder löschen?
 
 **Empfehlung: löschen.** Gründe:
@@ -131,6 +181,9 @@ 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.
+- **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.
 - **Der Weg aufs Handy bleibt ein normaler Link.** Android öffnet die
   installierte PWA, wenn die Adresse in ihren Bereich fällt — das funktioniert
   heute und darf nicht durch JavaScript-Navigation oder Rahmen kaputtgemacht

README.md

@@ -95,10 +95,13 @@ in beiden: Menüleiste, Palette, Einstellungen, App-Liste.
 Eine Zeile ins `frontend/index.html` der App:
 
 ```html
-<script src="https://os.honeyy.duckdns.org/honeybar/honeybar.js"
+<script defer src="https://os.honeyy.duckdns.org/honeybar/honeybar.js"
         data-app="aether"></script>
 ```
 
+`defer` ist nicht optional: ohne wartet der Seitenaufbau der App auf das Skript.
+Ist HoneyOS langsam oder aus, soll die Leiste den Start von Aether nicht bremsen.
+
 `data-app` ist die Kennung aus der App-Liste. Die Liste holt sich die Leiste selbst von
 `/api/apps` — mit deiner HoneyOS-Sitzung, weil alle Adressen unter derselben Domain liegen.
 **Freigegeben sind nur die Ursprünge, die selbst als App eingetragen sind**: die App-Liste

web/honeybar/demo.html

@@ -36,6 +36,6 @@
       <p>Eine App, die mit <code>100vh</code> rechnet, nimmt <code>--honeybar-h</code> ab.</p>
     </main>
 
-    <script src="./honeybar.js" data-app="inknote" data-home="/"></script>
+    <script defer src="./honeybar.js" data-app="inknote" data-home="/"></script>
   </body>
 </html>