Eigene App-Logos aus dem Fundament nach hinten verschoben

Sie haengen an derselben Ablage wie das Bild-Widget (Ordner unter /data,
Groessengrenze, SVG-Falle, Versionsanteil in der Adresse) — zusammen
gebaut kosten sie die Haelfte. Im Fundament stand nur noch das, was
laengst gebaut ist.
This commit is contained in:
marc committed 2026-08-29 23:08:46 +02:00
1 parent e088a5f83a
commit 04e4287ba8
1 file changed
+37 -24
+37 -24
View File
@@ -86,30 +86,9 @@ später eine CSS-Zeile; ohne sie anzufangen kostet die Zeit, in der man rät.
Der Untertitel bekommt damit endlich einen Ort: Er stand bisher nur auf den
Kacheln und beantwortet genau die Frage, die ein generisches Symbol offenlässt.
**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:
1. **Hochladen und ablegen** — HoneyOS speichert heute nur eine JSON-Datei.
Bilder heißt: ein Ordner unter `/data`, eine Größenbegrenzung, erlaubte
Typen (PNG, SVG, WebP), und SVG ist heikel — es kann Skripte enthalten und
darf deshalb nicht einfach durchgereicht werden.
2. **Ausliefern** — unter einer Adresse je App, mit einem Versionsanteil, damit
ein Austausch nicht im Cache hängen bleibt (Aether macht das beim Logo
schon so).
3. **In der HoneyBar anzeigen** — über die Site-Grenze hinweg ein `<img>` von
HoneyOS. Das geht ohne Sitzung, Bilder unterliegen der CORS-Regel nicht.
**Vorher zu klären:** Sollen Bilder in den Retro-Look eingepasst werden
(auf wenige Farben reduziert, hart gerastert) oder bunt bleiben? Ein
Original-Logo mit Farbverlauf neben Pixelglyphen sieht schnell nach Fremdkörper
aus. Ein Filter in der HoneyBar wäre billig zu haben und ließe sich abschalten.
**Was aus 1.3 offen bleibt, steht jetzt weiter unten:** eigene Logos zum
Hochladen (siehe „Eigene App-Logos" in Teil 2). Sie hängen an derselben Ablage
wie das Bild-Widget und gehören deshalb dorthin, nicht mehr ins Fundament.
### 1.3b Reihenfolge der Apps
@@ -306,6 +285,40 @@ Zu klären, wenn es soweit ist:
- Passt zum Aufnehmen eigener App-Logos (1.3): dieselbe Ablage, dasselbe
Ausliefern. Zusammen bauen spart die Hälfte.
### Eigene App-Logos — verschoben aus 1.3 (29.08.2026)
**Beschlossen als Planung (25.08.2026), aber nicht als Nächstes.** Je App ein
Bild in HoneyOS hinterlegen, statt nur aus den eingebauten Glyphen zu wählen —
die Pixelglyphe bleibt der Rückfall, wenn keins 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. Die Voraussetzung dafür — eine geteilte
Symbolquelle für beide Leisten — steht seit dem 29.08.2026 (1.3), es müsste nur
ein Bild an die Stelle des Rasters treten können.
**Warum es warten kann:** Mit acht Glyphen und vier Apps ist noch keine
Verwechslung in Sicht. Die Frage stellt sich, wenn zwei Dienste dieselbe Wolke
tragen; bis dahin erledigt der Untertitel in der Schublade die Unterscheidung.
**Warum es zusammen mit dem Bild-Widget zu bauen ist:** dieselbe Ablage,
dasselbe Ausliefern, dieselben Fallen — zusammen kostet es die Hälfte.
1. **Hochladen und ablegen** — HoneyOS speichert heute nur eine JSON-Datei.
Bilder heißt: ein Ordner unter `/data`, eine Größenbegrenzung, erlaubte
Typen (PNG, SVG, WebP), und SVG ist heikel — es kann Skripte enthalten und
darf deshalb nicht einfach durchgereicht werden.
2. **Ausliefern** — unter einer Adresse je App, mit einem Versionsanteil, damit
ein Austausch nicht im Cache hängen bleibt (Aether macht das beim Logo
schon so).
3. **In der HoneyBar anzeigen** — über die Site-Grenze hinweg ein `<img>` von
HoneyOS. Das geht ohne Sitzung, Bilder unterliegen der CORS-Regel nicht.
**Vorher zu klären:** Sollen Bilder in den Retro-Look eingepasst werden (auf
wenige Farben reduziert, hart gerastert) oder bunt bleiben? Ein Original-Logo
mit Farbverlauf neben Pixelglyphen sieht schnell nach Fremdkörper aus. Ein
Filter in der HoneyBar wäre billig zu haben und ließe sich abschalten.
### Widgets verschieben, Reihenfolge im Server — Marcs Idee (29.08.2026)
Widgets per Ziehen umsortieren, die Reihenfolge liegt beim Nutzer auf dem