Symbole in beiden Leisten, aus einer Quelle

Die Pixelraster stehen jetzt in web/glyphs.json — einmal. Der Schreibtisch
laedt die Datei selbst, die HoneyBar bekommt sie mit der App-Liste mit;
sie bleibt damit eine einzelne Datei ohne zweite Anfrage. Die abgetippten
Wettersymbole in honeybar.js sind weg, und die Symbolauswahl im
Programm-Editor kommt jetzt aus derselben Datei statt aus einer Liste im
Quelltext.

Neu: Symbole neben den App-Namen im Streifen beider Leisten, mit einem
Schalter (Einstellungen -> HoneyBar) fuer beide zugleich. In den
Aufklappmenues und auf den Kacheln stehen sie immer.

IDEAS.md

@@ -59,39 +59,29 @@ hält — dieselbe Liste, die heute schon die CORS-Freigabe steuert. Das ist ein
 Sicherheitsentscheidung und keine Kleinigkeit; erst bauen, wenn der Umweg über
 den Schreibtisch wirklich nervt.
 
-### 1.3 App-Schublade mit Symbolen
+### 1.3 App-Schublade mit Symbolen — ✅ halb gebaut (29.08.2026)
 
-**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.
+**Gebaut: die geteilte Symbolquelle.** Die Raster liegen in `web/glyphs.json`,
+der Schreibtisch lädt sie, die HoneyBar bekommt sie mit der App-Liste mit
+(siehe [README](README.md)). Damit tragen beide Leisten dieselben Symbole neben
+den App-Namen, und die doppelt abgetippten Wettersymbole sind weg.
 
-**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.
+Dazu ein Schalter *Einstellungen → HoneyBar*: Symbole im App-Streifen an oder
+aus, für beide Leisten zugleich. In den Aufklappmenüs und auf den Kacheln
+stehen sie immer — dort ist Platz, und dort sucht man eine App, statt sie im
+Vorbeigehen wiederzuerkennen.
 
-**Der eigentliche Punkt: die Symbole.** Das Pixelraster lebt in `os.js`
-(`GLYPHS`), die HoneyBar kennt es nicht. Zwei Wege:
+**Offen bleibt die Schublade selbst:** ein Raster aus Symbolen statt einer
+Liste, wenn es viele Apps werden. Heute reicht der Streifen samt Menü; das ist
+erst ab sechs, sieben Apps eine echte Frage.
 
-- **Pixelglyphen teilen** — `GLYPHS` + `glyphSvg()` in eine eigene Datei, die
-  Desktop und HoneyBar beide laden. Kein Upload, kein Speicher, passt zum Look.
-  Nachteil: nur die eingebauten Symbole.
-- **Echte Bilder** — pro App eine Bildadresse oder ein Upload in HoneyOS.
-  Flexibler, aber: Speicher, Größenbegrenzungen, Auslieferung, und der
-  Retro-Look bekommt bunte Fremdkörper.
-
-→ **Empfehlung: Pixelglyphen teilen** — als Erstes, weil es sofort trägt.
-
-**Beschlossen als Planung (25.08.2026): eigene Logos hochladen.** Je App ein
-Bild in HoneyOS hinterlegen, statt nur aus den eingebauten Glyphen zu wählen.
-Nicht als Ersatz für die Pixelglyphen, sondern daneben: Glyphe als Rückfall,
-wenn kein Bild da ist.
-
-**Das Logo gehört ausdrücklich auch in die HoneyBar**, nicht nur auf den
-Schreibtisch — dort ist die Unterscheidung am nötigsten, weil die Knöpfe klein
-sind und nebeneinanderstehen. Damit ist die geteilte Symbolquelle aus 1.3
-Voraussetzung: Beide Seiten müssen dasselbe Bild bekommen, sonst pflegt man es
-zweimal.
+**Ebenfalls offen: eigene Logos hochladen** (beschlossen als Planung,
+25.08.2026). Je App ein Bild in HoneyOS, die Pixelglyphe als Rückfall, wenn
+keins da ist. Das Logo gehört ausdrücklich auch in die HoneyBar — dort ist die
+Unterscheidung am nötigsten, weil die Knöpfe klein sind und nebeneinanderstehen.
+Der Weg dorthin ist durch die geteilte Quelle jetzt kurz: Beide Seiten holen
+ihre Symbole schon aus derselben Antwort, es müsste nur ein Bild an die Stelle
+des Rasters treten können.
 
 Was daran zu bauen ist, in dieser Reihenfolge: