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
|
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.
|
Kacheln und beantwortet genau die Frage, die ein generisches Symbol offenlässt.
|
||||||
|
|
||||||
**Ebenfalls offen: eigene Logos hochladen** (beschlossen als Planung,
|
**Was aus 1.3 offen bleibt, steht jetzt weiter unten:** eigene Logos zum
|
||||||
25.08.2026). Je App ein Bild in HoneyOS, die Pixelglyphe als Rückfall, wenn
|
Hochladen (siehe „Eigene App-Logos" in Teil 2). Sie hängen an derselben Ablage
|
||||||
keins da ist. Das Logo gehört ausdrücklich auch in die HoneyBar — dort ist die
|
wie das Bild-Widget und gehören deshalb dorthin, nicht mehr ins Fundament.
|
||||||
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.
|
|
||||||
|
|
||||||
### 1.3b Reihenfolge der Apps
|
### 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
|
- Passt zum Aufnehmen eigener App-Logos (1.3): dieselbe Ablage, dasselbe
|
||||||
Ausliefern. Zusammen bauen spart die Hälfte.
|
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 verschieben, Reihenfolge im Server — Marcs Idee (29.08.2026)
|
||||||
|
|
||||||
Widgets per Ziehen umsortieren, die Reihenfolge liegt beim Nutzer auf dem
|
Widgets per Ziehen umsortieren, die Reihenfolge liegt beim Nutzer auf dem
|
||||||
|
|||||||
Reference in new issue
Block a user