marcandClaude Opus 5
5ed4e30179
Zwei Sachen, die beim Benutzen aufgefallen sind.
- "leiste ausblenden" war eine Einbahnstraße: die Leiste verschwand ganz und
liess sich nur über die Entwicklerkonsole zurückholen. Jetzt bleibt ein
3px-Strich stehen, ein Klick darauf holt sie wieder. ?honeybar=1 an der
Adresse ist der Notausgang, falls der Strich übersehen wird.
- Die Leiste hatte ihre Farben fest eingetragen und blieb bernsteinfarben,
auch wenn der Schreibtisch auf grün stand. Genau dieser Bruch liess sie wie
etwas Angeklebtes wirken. /api/apps liefert deshalb jetzt {apps, settings};
die Leiste setzt Röhre, Glühen und Scanlines danach.
Dass das auch über Site-Grenzen geht, war so nicht erwartet: der Schlüssel
für die App-Liste trägt das Aussehen einfach mit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
207 lines
8.9 KiB
Markdown
207 lines
8.9 KiB
Markdown
# Ideen und Reihenfolge
|
|
|
|
Was noch kommen könnte, in der Reihenfolge, in der es aufeinander aufbaut.
|
|
Nichts davon ist beschlossen — beschlossen ist, was im [README](README.md) steht.
|
|
|
|
Grundsatz für alles hier: **Fundament zuerst, dann ein Widget, dann ausbauen.**
|
|
Nicht zehn Fenster auf einmal planen, sondern eines bauen und sehen, ob man
|
|
wirklich hinschaut.
|
|
|
|
---
|
|
|
|
## 1 · Fundament
|
|
|
|
Ohne diese Stücke ist alles danach nicht möglich. Reihenfolge nach dem
|
|
Verhältnis von Aufwand zu spürbarer Wirkung.
|
|
|
|
### 1.1 Die Leiste trägt deine Röhre — ✅ erledigt (24.08.2026)
|
|
|
|
Die Leiste liest ihre Farben nicht mehr fest, sondern aus derselben Antwort, mit
|
|
der sie die App-Liste holt. Röhre in HoneyOS auf grün → die Leiste in Aether ist
|
|
grün, ohne dass Aether angefasst wird. `glow` und `scanlines` gelten dort ebenso.
|
|
|
|
**Ging entgegen der ersten Einschätzung auch über Site-Grenzen hinweg.** Ich
|
|
hatte notiert, das scheitere daran, dass der Browser die Sitzung nicht mitschickt
|
|
— stimmt, aber der Schlüssel für die App-Liste löst es: dieselbe Anfrage bringt
|
|
das Aussehen gleich mit. Deshalb liefert `/api/apps` jetzt `{apps, settings}`
|
|
statt nur einer Liste.
|
|
|
|
Offen bleibt: Bei mehreren Nutzern trägt die Leiste die Farbe des
|
|
Standardnutzers, weil ihr über die Site-Grenze niemand sagen kann, wer da
|
|
gerade schaut.
|
|
|
|
### 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.
|
|
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.** Bilder später nachrüsten, falls je eine
|
|
App dabei ist, für die kein Symbol passt.
|
|
|
|
### 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
|
|
schon heute mit — es fehlt allein die Freigabe im Go-Backend
|
|
(`Access-Control-Allow-Origin` für `os.…` plus `Allow-Credentials`).
|
|
|
|
Kleiner Eingriff, aber **die Voraussetzung für jedes Aether-Widget** und
|
|
nebenbei auch für die Anmeldeanzeige auf der Kachel.
|
|
|
|
### 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
|
|
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 PWA und Offline-Betrieb unangetastet sind.
|
|
|
|
Erledigt zugleich den Token-Schlüssel (siehe „Offene Entscheidungen").
|
|
|
|
### 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
|
|
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.
|
|
|
|
- **Letzte Dateien** (Aether) — die naheliegendste; braucht nur 1.2
|
|
- **Speicherplatz** (Aether) — eine Zahl, ein Balken, billig zu bauen
|
|
- **Letzte Notizen** (InkNote) — braucht 1.3, kommt also später
|
|
|
|
→ Anfangen mit **letzte Dateien**. Wenn du danach merkst, dass du morgens
|
|
wirklich draufschaust, lohnt der Rest. Wenn nicht, war es ein Abend.
|
|
|
|
---
|
|
|
|
## 3 · Ausbau
|
|
|
|
- Welche Widgets wo liegen, **pro Nutzer im Server** merken — die Einstellungen
|
|
liegen ohnehin schon dort, das ist eine Erweiterung, kein Neubau
|
|
- Widgets im Terminal-Modus
|
|
- Suche über alle Apps hinweg (erst sinnvoll, wenn mehrere APIs angebunden sind)
|
|
- Symbole frei auf dem Schreibtisch ablegen statt in einer Spalte
|
|
- Fensterpositionen überleben den Moduswechsel
|
|
|
|
---
|
|
|
|
## Offene Entscheidungen
|
|
|
|
### Wie sichtbar darf die Leiste sein?
|
|
|
|
**Teilweise beantwortet:** „ausblenden" heißt seit dem 24.08. „einklappen" — es
|
|
bleibt ein 3 px hoher Strich am oberen Rand stehen, ein Klick holt die Leiste
|
|
zurück. Vorher war das eine Einbahnstraße: wer einmal ausgeblendet hatte, kam
|
|
nur über die Entwicklerkonsole wieder heran. `?honeybar=1` an der Adresse
|
|
funktioniert als Notausgang.
|
|
|
|
Damit ist der schmale Streifen technisch schon da. Offen bleibt, ob er am Handy
|
|
der **Standard** sein soll.
|
|
|
|
|
|
**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:
|
|
|
|
1. Er wirkt nur an einer von zwei Stellen — in der Leiste ja, auf dem Desktop
|
|
nie. Das ist schwer zu erklären und noch schwerer zu merken.
|
|
2. Er bringt allein die Namensanzeige. Kein Funktionsunterschied.
|
|
3. Sobald 1.3 gebaut ist, ist er ohnehin überflüssig.
|
|
4. **Scharfe Kante:** Das Feld „Wer-bin-ich" darf auch eine vollständige fremde
|
|
Adresse sein. Steht dort etwas Fremdes *und* ein Token-Schlüssel, schickt die
|
|
Leiste den InkNote-Token dorthin. Das setzt voraus, dass jemand Angemeldetes
|
|
das selbst einträgt — bei einer Ein-Personen-Instanz also kein akuter
|
|
Notstand, aber eine Falle, die niemand braucht.
|
|
|
|
Wird er doch behalten, gehört mindestens eingebaut: **mit Token-Schlüssel nur
|
|
relative Pfade zulassen**, damit ein Ausweis nie an einen fremden Ursprung geht.
|
|
Drei Zeilen.
|
|
|
|
### Ideen hier oder als Gitea-Issues?
|
|
|
|
Vorerst hier. Issues erst, wenn etwas konkret als Nächstes drankommt und der
|
|
Fortschritt verfolgt werden soll — dann eines pro Punkt, mit Verweis hierher.
|
|
|
|
---
|
|
|
|
## Bewusst nicht geplant
|
|
|
|
Damit es nicht alle paar Monate neu diskutiert wird:
|
|
|
|
- **Apps in iframes einbetten.** Aether (`X-Frame-Options: DENY`) und InkNote
|
|
(`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
|
|
werden.
|
|
- **HoneyOS speichert keine Inhalte.** Keine Dateien, keine Notizen, keine
|
|
Kopien. Es zeigt, was die Apps hergeben, und hört da auf.
|
|
- **Keine Rechteverwaltung.** Die App-Liste gilt für alle Angemeldeten. Für eine
|
|
Handvoll eigene Konten gewollt; wäre es je mehr, müsste das neu gedacht werden.
|