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:
1 parent
e088a5f83a
commit
04e4287ba8
1 file changed
+37
-24
@@ -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
|
||||
|
||||
Reference in new issue
Block a user