Marcs Vorschlag, und er ist der bessere: "+ kategorie" setzt eine
Ueberschriftenzeile, und was darunter steht, gehoert dazu, bis die naechste
kommt. Die Ueberschrift hat dieselben Pfeile wie eine App, laesst sich
umbenennen und mit x aufloesen.
Damit faellt die Sonderregel von gestern weg -- "am Rand der Gruppe
kategorisiert der Pfeil um, statt zu tauschen". Sie war die Beschreibung
eines Modells; jetzt ist es das Modell: Schiebt man eine App ueber eine
Ueberschrift, ist sie in der anderen Gruppe, und schiebt man eine
Ueberschrift, wandert die Grenze. Nichts davon braucht Code.
Vor allem loest es den echten Mangel der ersten Fassung: Eine Kategorie
umbenennen war ein Feld je App, jetzt ist es eine Zeile.
Gespeichert wird weiter als Feld an der App. Waere die Ueberschrift ein
Eintrag in der App-Liste, enthielte diese Zeilen ohne ID und ohne Adresse,
und jeder Leser muesste das wissen -- Kacheln, Schublade, Pruefung auf
Erreichbarkeit und vor allem die HoneyBar in fremden Apps. Der Preis: Eine
Ueberschrift ohne Apps darunter ueberlebt das Speichern nicht. Eine
Kategorie besteht durch ihre Apps.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ein Feld an der App, kein zweites Datenmodell: Eine Kategorie besteht genau
so lange, wie eine App sie traegt. Damit gibt es nichts anzulegen, nichts zu
loeschen und keine zweite Reihenfolge, die mit der bestehenden aus dem Tritt
geraten koennte.
Die Reihenfolge der Ueberschriften ist die ihres ersten Auftretens in der
Liste -- also ordnen dieselben Pfeile wie bisher beides. Am Rand einer Gruppe
haengt der Pfeil die App in die Nachbargruppe um, statt zu tauschen: derselbe
Knopf zum Sortieren und zum Umkategorisieren, und keine App kann zwischen
zwei Gruppen liegen bleiben.
Eingesammelt wird im Server, beim Schreiben wie beim Lesen. Das war nicht der
erste Entwurf: Zuerst sortierte die Oberflaeche und die HoneyBar setzte ihre
Ueberschriften beim Durchlaufen -- prompt stand eine App ohne Kategorie in der
HoneyBar unter der letzten Ueberschrift und auf dem Schreibtisch ganz oben.
Bei zwei Lesern derselben Liste gehoert die Reihenfolge dorthin, wo die Liste
liegt.
Ueberschriften erscheinen, wo man sucht: Kacheln, Schublade beider Leisten,
Programme-Fenster. Nicht im App-Streifen (32 Pixel) und nicht bei den
Schreibtischsymbolen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ihre Stile hingen als <style> im Shadow DOM, und Markup faellt unter die
CSP der Gastgeber-App: Jede fremde App musste deshalb style-src
'unsafe-inline' erlauben, sonst stand die HoneyBar schwarz auf schwarz da.
Jetzt kommen sie als konstruiertes Stylesheet ueber die CSSOM herein, die
keine CSP kennt. Damit braucht die App gar keine style-src-Erlaubnis mehr
-- auch keine fuer die HoneyOS-Domain, was der geplante Weg ueber eine
zweite Datei und <link> gekostet haette, samt zweiter Anfrage.
Der Strich zum Wiederausklappen hat seinen eigenen Shadow-Root und geht
denselben Weg. Der Rueckfall fuer alte Browser laeuft nach innerHTML,
sonst raeumt das Markup ihn gleich wieder weg.
Gemessen an einer nachgebauten App mit style-src 'self': Leiste bernstein,
32 px, Strich mit Verlauf, keine CSP-Meldung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Auf dem Anmeldebildschirm steht jetzt dieselbe Biene wie in der Leiste und im
Tab, nur gross — ein Geraet, ein Zeichen. Die 3/4-Ansicht wird nirgends mehr
ausgeliefert; sie bleibt als schraeg() im Werkzeug liegen.
Dazu sitzt der SVG-Rahmen jetzt auf dem, was wirklich gefuellt ist. Das Raster
ist quadratisch, die Biene nicht — unten blieb ein Viertel Luft, und die kostet
ueberall Groesse, wo das Bild in einen Kasten gelegt wird.
tools/biene.py schreibt die Zeile in honeybar.js jetzt selbst mit: Drei Kopien,
die von Hand gepflegt werden, laufen genau einmal auseinander.
Die 3/4-Ansicht ist unter 64 px unbrauchbar und deshalb genau hier richtig:
Auf dem Anmeldebildschirm ist Platz, und man wartet ohnehin auf den Anbieter.
Sie schwebt sechs Sekunden lang zwei Pixel weit — eher ein Atmen als eine
Bewegung, und bei prefers-reduced-motion steht sie still.
Gerechnet wird sie in tools/biene.py aus demselben Raster wie die anderen
Fassungen.
Aus dem Quadrat links in beiden Leisten wird eine Pixelbiene von der Seite:
braune Streifen, schwarze Beine, Fluegel mit Kerbe. Sie steht in genau einem
Raster (tools/biene.py, 16x16 Zeichen); daraus entstehen SVG, PNG und eine
Fassung aus Schriftzeichen.
SVG statt PNG in den Leisten: Die HoneyBar laeuft in fremden Apps, und ob ein
<img> dort laedt, entscheidet deren CSP. Markup kann niemand blockieren.
Im System-Fenster und ueber dem Startlauf steht die Biene aus Schriftzeichen —
beides sind Textflaechen, ein Bild darin waere ein Fremdkoerper.
Das Wappen liegt an drei Stellen (Datei, Modul, HoneyBar-Zeile), weil die
Leiste nichts nachladen kann. TestWappenIstUeberallDasselbe haelt sie gleich.
Aus dem Zettel wird die Notiz: Der Text steht immer formatiert da, roh ist nur
die Zeile mit der Schreibmarke. Dazu eine kleine Werkzeugleiste (Aufgabe,
Aufzaehlung, Nummer, Ueberschrift, fett, Linie), Enter fuehrt Listen fort,
Backspace am Zeilenanfang nimmt erst den Vorsatz. Fuer groessere Umbauten
bleibt der Quelltext-Knopf.
Kein contenteditable: Der Quelltext bleibt die Wahrheit und wird nie aus dem
HTML zurueckgerechnet, das der Browser beim Tippen erzeugt.
Reihenfolge und An/Aus der Widgets liegen jetzt je Nutzer auf dem Server, in
einer Einstellung ("benutzer,notiz,-system,wetter,bild"). Der Schalter fuer das
Wetter auf dem Schreibtisch faellt damit weg — es ist ein Widget wie jedes
andere.
Die Einstellungen sind in Abschnitte sortiert (Darstellung, HoneyBar, Widgets,
Wetter, Programme, Konto), Beschriftung links, Schalter rechts.
Zettel: ein Textfeld, mehr nicht — InkNote gibt es schon. Gelesen wird
gesetzt (Ueberschriften, Haken, Aufzaehlungen, fett/kursiv/code, Strich),
geschrieben wird roh. Haken lassen sich ohne Bearbeiten setzen und
aendern die Quelle. Gespeichert wird 800 ms nach dem letzten Anschlag,
sofort beim Verlassen und beim Schliessen des Tabs (keepalive statt
sendBeacon: der kann nur POST und traegt keine Kopfzeilen). Grenze 4000
Zeichen, vom Server durchgesetzt.
Bild: genau eines je Nutzer, hochgeladen oder verlinkt. Die erste Datei,
die HoneyOS ablegt — in bilder/ neben honeyos.json, benannt nach einem
Fingerabdruck der Nutzerkennung. Ein neues Bild ersetzt das alte samt
Datei, die Adresse traegt einen Versionsanteil gegen den Zwischen-
speicher. SVG kommt nicht herein (Text, kann Skripte tragen), und der
Typ wird an den Bytes erkannt, nicht an der Angabe des Browsers.
Der Rahmen kann jetzt Widgets mit eigenem DOM: 'stabil' haelt den Inhalt,
'montiert' verdrahtet ihn. Ohne das haette das Anklopfen bei den Apps
alle zwei Minuten den Text unter den Fingern ausgetauscht.
Nebenbei: Der Aufrufhelfer setzte bei jedem Schreibzugriff
Content-Type: application/json — auch fuer Bildbytes.
widgetAnmelden({ id, titel, wo, sichtbar, laden, leer, inhalt, takt }) —
der Rahmen macht daraus ein Fenster in der Spalte (Terminal) oder ein
Schild (Desktop), kennt lädt/fertig/nichts da/Fehler und haelt den
Nachladetakt. Benutzer, Wetter und Systemzustand sind umgestellt; aus
index.html sind vier feste Kaesten verschwunden und aus dem Raster die
Einzelplaetze.
Zwei Dinge, die erst dabei sichtbar wurden:
- Der Server meldete 'kein Ort eingestellt' und 'Dienst nicht
erreichbar' beide als 204. Ein Ausfall sah damit aus wie ein
abgeschaltetes Widget. Ausfall ist jetzt 502, mit Test.
- Die Reihenfolge haengt nicht mehr an der Modulauswertung: Seit
glyphs.js seine Raster mit await auf oberster Ebene laedt, laufen
Module ohne Symbole vorher durch — der Systemzustand stand deshalb
ueber dem Benutzer. widgetsOrdnen() macht die Reihenfolge zur Angabe,
und genau dort haengt spaeter die im Server gespeicherte ein.
Das Menue hiess class='menu apps' — und .apps ist der Streifen in der
Leiste, der seine rechten 18 px per mask-image ausblendet, damit man
sieht, dass es seitwaerts weitergeht. Die Schublade erbte die Maske und
loeste sich rechts auf. In der Geometrie war nichts zu sehen, deshalb
hatte ich es zweimal uebersehen: nichts ragte hinaus, der Rahmen war da.
Heisst jetzt .menu.schublade, mit Test dagegen: class='apps' darf genau
einmal vorkommen.
.menu a ist spezifischer als .d-app — die Kacheln bekamen dadurch
padding 6px 8px und text-align left statt ihrer eigenen Werte. Das faellt
in der HoneyBar auf, nicht auf dem Schreibtisch: dort steht die
Schublade in .startmenu und wird spezifisch genug angesprochen.
Reihenfolge half nicht, nur Spezifitaet.
Dazu ein Waechter: Ein Backtick in einem Kommentar von honeybar.js
beendet die Vorlagenzeichenkette mitten im CSS und zerlegt die Datei —
zweimal passiert, jetzt bricht der Test.
Sortiert wird im Programm-Editor mit Pfeilen in der Kopfzeile jeder Zeile —
das Array ist die Reihenfolge, also gilt sie ueberall zugleich: Streifen,
Schublade, Kacheln, Schreibtischsymbole, Startmenue. Neue Apps haengen sich
hinten an, statt eine Taste zu verlangen.
Die Zifferntasten sind ganz weg (Marcs Entscheidung): ein Pflichtfeld je
App, das beim Sortieren nur die Frage aufgeworfen haette, ob es mitwandert.
Damit faellt das Feld 'key' aus dem Datenmodell, aus der Kachel, aus der
Hilfe und aus der Statuszeile. Alte Eintraege verlieren es beim naechsten
Speichern still.
Kein A-Z-Knopf — erstmal zu viel, kommt zurueck wenn er fehlt.
Der Schluessel kennt keinen Nutzer und landete beim Standardnutzer — auch
dann, wenn die App unter derselben Site liegt und der Browser das
HoneyOS-Cookie laengst mitschickt (cloud.honeyos.… und honeyos.… sind
dieselbe Site, duckdns.org steht auf der Public-Suffix-Liste). Damit trug
die HoneyBar in Aether die Farben eines fremden Nutzers.
Jetzt sieht /api/apps erst nach der Sitzung, und nur bei eigener
Anmeldung: Im offenen Betrieb und hinter einem Anmelde-Proxy gilt jede
Anfrage als angemeldet, dort bleibt der Schluessel das letzte Wort.
Test dazu, mit zwei Nutzern, damit der Rueckfall auf den einzigen Nutzer
das Ergebnis nicht zufaellig richtig aussehen laesst.
Reihenfolge: Pfeile statt Ziehen (HTML5-Drag loest am Handy nicht aus),
dazu ein A-Z-Knopf. Die eigene Reihenfolge je Nutzer waere rein additiv —
sie braucht die gemeinsame als Rueckfall und haengt an derselben
Bedingung wie persoenliche Apps: zweiter Nutzer oder eine Domain.
Dazu Marcs Zettel-Widget, mit der Abgrenzung zu InkNote als Kernpunkt.
Und die Regel 'speichert keine Inhalte' praezisiert: Sie meint keine
Zweitkopie aus den Apps, nicht das, was der Schreibtisch selbst
hervorbringt.
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.
Der Proxy davor waere kein grosser Aufwand, aber ein Ausfallpunkt vor der
Cloud und ein Umweg fuer Uploads, WebDAV und Collabora — und die
Layout-Rechnung (--honeybar-h) bliebe ohnehin in Aether stehen.
Der Pfeil rechts klappt in beiden Leisten ein Raster auf statt einer
Liste. Symbol gross, Name, Untertitel als dritte Zeile — der stand
bisher nur auf den Kacheln.
Entschieden gegen Symbol allein: Acht geteilte Glyphen identifizieren
nicht, zwei Apps koennen dieselbe Wolke tragen. Und die Schublade macht
man auf, weil man sucht — der Streifen ist der Ort fuers Wiedererkennen,
dort sind die Symbole abschaltbar.
Dazu 1.4 (CORS in Aether) und 1.5 (Cookie-Sitzung fuer InkNote) aus den
Ideen gestrichen: Widgets, die Daten aus den eigenen Apps holen, sind
nicht mehr gewollt. Der Rest ist neu durchnummeriert.
Die HoneyBar kommt bei fremden Apps ueber deren eigenen Ursprung — das
loest CSP, CORS und COEP auf einmal, setzt sie aber auch deren Zwischen-
speicher aus. Eine alte HoneyBar dort sieht aus wie ein Fehler in HoneyOS.
Statt no-cache jetzt no-store, must-revalidate; dazu ein Abschnitt in der
README, wie man einen haengengebliebenen Stand erkennt.
Und der nginx davor heisst nicht mehr 'Einsetzer', sondern HoneyBar-Proxy
(Dienst und Behaelter honeybar-proxy bzw. <app>-honeybar). Er ist ein
Reverse Proxy, der die HoneyBar einsetzt — der alte Name sagte das
Gegenteil von dem, was man im docker ps sehen will. LEISTE_PORT heisst
jetzt HONEYBAR_PROXY_PORT.
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.
Der Koerper hat 14 px, honeybar.js 12 px. In der Menueleiste haengt nur
das Logo direkt drin — alles andere sitzt in .mb-right oder trug seine
eigene Groesse. Also stand ausgerechnet das HONEYOS links groesser da als
dasselbe Logo in Aether. Jetzt gibt die Leiste selbst 12 px vor; die
Innenabstaende sind mitgezogen, damit es an derselben Stelle anfaengt.
Marcs Entscheidung: In der HoneyBar fremder Apps steht kein Abmelden mehr
— es war dort ohnehin nur ein Link auf den Schreibtisch. Als einzige
Schaltflaeche, die eine Sitzung beendet, steht es jetzt an genau einer
Stelle: unten in den Einstellungen, sichtbar nur bei eigener Anmeldung.
Damit faellt auch der ?abmelden=1-Pfad wieder weg und /api/apps braucht
das oidc-Feld nicht mehr.
Das Zahnrad rechts in der Menueleiste ist durch den Pfeil mit der
App-Liste ersetzt — derselbe wie in der HoneyBar. Beide Leisten tragen
damit dieselben vier Dinge: Logo, Apps, Wetter/Uhr, Aufklappmenue.
Das ■ HONEYOS ist jetzt ein Menue statt eines Links: Schreibtisch,
Einstellungen, HoneyBar einklappen, Abmelden. In fremden Apps sind es
Links auf den Schreibtisch (?einstellungen=1 / ?abmelden=1), weil die
HoneyBar dort nicht schreiben darf — Sitzung und CSRF-Pruefwort ueber-
leben die Site-Grenze nicht, und ein Abmelden per Aufruf koennte jede
Seite ausloesen.
Der Abmeldeknopf in der Menueleiste faellt weg (stand doppelt), und
Abmelden erscheint nur, wenn HoneyOS ueberhaupt anmeldet — dafuer gibt
/api/apps jetzt oidc mit heraus. Nebenbei: restliche 'Leiste' im Text
zu 'HoneyBar' vereinheitlicht.
Go: store, auth, weather und config sind eigene Pakete unter internal/. Vorher
lagen fuenf Dateien in einem Topf, und jede kannte jede.
Web: os.js hatte 1425 Zeilen und alles darin. Jetzt core.js (Zustand, Server,
Einstellungen), glyphs.js (die Pixelraster), js/widgets/ mit einem Widget je
Datei, os.js nur noch die Ansichten. Stylesheet nach css/.
Die HoneyBar bleibt eine einzelne Datei ohne Importe — sie wird von fremden
Seiten mit einer Zeile eingebunden, da darf nichts nachladen.
Nebenbei: Das gebaute Binary lag mit 9,8 MB im Repo und ist jetzt ignoriert.
Und der Test gegen eine zweite Versionsnummer geht nicht mehr auf os.js, sondern
durch alle .js — sonst haette ihn dieser Umbau still ausgehebelt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drei Sachen, die Marc aufgefallen sind:
Das Quadrat im Logo war in der HoneyBar in voller Groesse, in der Menueleiste
klein und angehoben — nebeneinander sah das wie zwei verschiedene Logos aus.
Jetzt beide 10px.
Bei vielen Apps quetschte das Flex-Raster die Namen zusammen, statt den Streifen
schiebbar zu machen: flex-shrink stand auf 1. Jetzt schiebt man seitwaerts, in
beiden Leisten, mit einem Schatten am rechten Rand als Hinweis. Am Handy war
das der Unterschied zwischen "sechs Apps erreichbar" und "drei Buchstabenreste".
Und die Widgets waren einspaltig auf 320px begrenzt, waehrend das Systemfenster
die volle Breite nahm — drei verschieden breite Kaesten untereinander sehen aus
wie ein Fehler. Dazu wird aus der Kachelwand am Handy eine Liste: sechs Apps
passen jetzt auf einen Bildschirm statt auf drei.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Beides brachte allein einen Anzeigenamen. Seit der Benutzer als Widget auf dem
Schreibtisch steht, kommt der aus der HoneyOS-Anmeldung — keine App muss mehr
etwas dafuer bereitstellen, und beide Leisten tragen ueberall dasselbe.
Der Token-Schluessel hatte zudem eine scharfe Kante: Zeigte das Feld
Wer-bin-ich auf eine fremde Adresse, ging der Ausweis der App dorthin.
Weg sind damit auch checkAuth, askMe und die Anmeldezeile auf den Kacheln. Alte
honeyos.json-Dateien werden weiter gelesen; die Felder verfallen beim naechsten
Speichern still.
1.0, weil die Bedienung sich aendert und der Stand rund ist: zwei Leisten mit
gleichem Inhalt, Widgets fuer Benutzer und Wetter, die HoneyBar auch in fremden
Apps.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Menueleiste war 34 px hoch, die HoneyBar in den Apps 32 — beim Wechsel sah
man den Sprung. Jetzt beide 32.
Und der Name samt Bild stand rechts in der Menueleiste. Das war das einzige
Stueck, das die HoneyBar in den Apps nicht hat — genau der Unterschied, den man
nicht sehen soll. Er sitzt jetzt als eigenes Widget auf dem Schreibtisch, mit
der Begruessung, die vorher im Systemfenster stand. Beide Leisten tragen damit
ueberall dasselbe.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Und einklappen ging nur einmal: mount() haengte seine Zuhoerer selbst an, also
hatte sie doppelt, wer die HoneyBar ueber den Strich zurueckholte. Der Klick
aufs Menue oeffnete und schloss es im selben Zug — der Punkt "honeybar
einklappen" war damit unerreichbar. Das Verdrahten passiert jetzt einmal.
Nachgestellt mit gruener Roehre: Strich gruen, aus- und wieder einklappen
funktioniert beliebig oft.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Dienst im Beispiel heisst jetzt einsetzer — er ist nicht die HoneyBar,
er setzt sie ein. Zusammensetzungen wie Menueleiste, Taskleiste und
Statusleiste bleiben, die meinen etwas anderes.
Dazu in IDEAS notiert, dass HoneyBar und Menueleiste zwei getrennte Stilsaetze
sind und schon einmal auseinandergelaufen ist.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
In der Oberflaeche hiess das Feld Kennung, in der Konfiguration id, in der
README beides. Drei Namen fuer dieselbe Sache, und man muss sie beim Eintragen
zusammenbringen — jetzt ueberall ID.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Weg 1 fuer selbst geschriebene Apps, Weg 2 fuer fertig bezogene — mit dem
Vorher/Nachher an der Compose-Datei der App und dem, was der Einsetzer kostet.
Dabei richtiggestellt, dass Aether und InkNote die Leiste zur Laufzeit laden
statt sie ins HTML zu schreiben; die README beschrieb noch den alten Stand.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
nginx nimmt ohne client_max_body_size bei 1 MB nichts mehr an. Jede App mit
Dateiupload waere hinter dem Einsetzer kaputt gegangen — und der Fehler haette
wie ein Fehler der App ausgesehen. Nachgemessen: 5 MB gaben 413, danach kam die
Ablehnung von der Ziel-App statt vom Einsetzer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Am Host erkennt nginx, welcher Dienst gemeint ist und welche App das fuer
HoneyOS ist; die Leiste hebt sie dann hervor wie in Aether. Dieselbe Bauart wie
im BentoPDF-Beispiel: Leiste und ihre zwei Abfragen laufen ueber die Adresse
der App, damit deren CSP unangetastet bleibt.
Die beiden .conf-Dateien sind weg — sie standen ein zweites Mal in der
Compose-Datei, und zwei Fassungen derselben Sache laufen auseinander. Heute
schon zweimal passiert.
Geprueft mit zwei Diensten: richtige Kennung je Host, richtige Hervorhebung in
der Leiste, gemeinsame App-Liste, Wetter.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Marcs BentoPDF-Image (ghcr.io/alam00000/bentopdf-simple) schickt eine strenge
CSP — mit dem Image von Docker Hub, an dem ich zuerst geprueft hatte, war das
nicht zu sehen. Statt fremde Kopfzeilen umzuschreiben, reicht der Einsetzer
jetzt auch /honeybar/ und die zwei Abfragen der Leiste unter seiner eigenen
Adresse durch. Damit ist fuer den Browser alles derselbe Ursprung: CSP
unangetastet, kein CORS, kein COEP, und der Schluessel bleibt auf dem Server.
Durchgereicht wird nur /api/apps und /api/weather, nur lesend. Ein pauschales
/api/ haette die ganze Schnittstelle unter die Adresse der App gehaengt — beim
Ausprobieren hat meine eigene Schreibprobe prompt die App-Liste geleert.
Das Binden auf 127.0.0.1 ist raus: Es passt nur, wenn der Proxy auf demselben
Wirt im Host-Netz laeuft, und nicht fuer Marcs Aufbau.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fehlt eine der beiden Dateien auf dem Wirt, legt Docker dort wortlos ein
Verzeichnis an und scheitert beim Start mit "not a directory" — beim Einsetzen
ueber eine Oberflaeche eine Falle ohne Nutzen. Als configs mit content traegt
die Compose-Datei alles selbst.
Durchprobiert ohne eine einzige Datei auf dem Wirt: Stapel hoch, HoneyOS
antwortet, richtige data-app, unbekannter Host 404.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Getrennt gepflegt hiesse, bei jeder neuen App an zwei Stellen zu denken. Das
Netz legt der Stapel selbst unter festem Namen an — vorher musste es von Hand
erzeugt werden, und ohne festen Namen hiesse es nach dem Ordner.
Durchprobiert: Stapel hoch, fremde App tritt dem Netz bei, beide Hosts bekommen
die richtige data-app, unbekannter Host 404.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Am Host erkennt nginx den Dienst; eine neue App sind zwei Zeilen. Geprueft mit
zwei Diensten gleichzeitig: richtige data-app je Host, unbekannter Host 404,
WebSocket-Upgrade durchgereicht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Compose und nginx-Konfiguration, genau so durchprobiert. Dazu der Hinweis, dass
der Ursprung in HoneyOS auf den Buchstaben passen muss: localhost und 127.0.0.1
sind fuer den Browser zwei verschiedene.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Apps, die COEP „require-corp" setzen — alles mit WASM oder SharedArrayBuffer,
etwa BentoPDF — lehnen jede fremde Datei ab, die sich nicht ausdruecklich zur
Einbettung bekennt. Genau das ist der Zweck der Leiste, also sagt sie es jetzt.
Die Alternative waere gewesen, im Proxy das COEP der App zu entfernen. Das
haette ihr die Faehigkeiten genommen, fuer die sie es setzt.
Gefunden beim Einsetzen in BentoPDF hinter einem nginx.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Rezept fuer nginx, geprueft gegen eine App mit gzip und eigener CSP. Die vier
Fallen stehen dabei: Kompression, CSP ersetzen statt ergaenzen, nur HTML
anfassen, Ursprung in HoneyOS eintragen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Anklickbar war es ein Versprechen, das es nicht hielt: Der Klick fuehrte nur
dorthin, wo ohnehin alles eingestellt wird. Jetzt eine Anzeige mit Hinweistext,
in beiden Leisten.
Die Anordnung war seit dem Wetterfenster kaputt. Das Raster verteilt seine
Bereiche der Reihe nach — das dritte landete neben „system" und schob die
Kacheln in die schmale linke Spalte. Links stehen jetzt die Anzeigen
untereinander, rechts die Apps ueber die volle Hoehe.
Keine neue Faehigkeit, also bleibt die Version bei 0.9.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Leiste am oberen Rand von HoneyOS ist nicht honeybar.js, sondern die
Menueleiste des Schreibtischs — anderer Code, gleiches Aussehen. Das Wetter
stand deshalb nur in fremden Apps, waehrend der Schalter dort, wo man ihn
umlegt, nichts zu bewirken schien.
Fuer den, der davorsitzt, ist beides dieselbe Leiste. Ein Schalter, der nur
woanders wirkt, ist nicht zu erklaeren.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei Schalter, unabhaengig voneinander: Schreibtisch, Leiste, beides oder
keins. Die Stadt wird einmal gesucht und mit ihren Koordinaten gespeichert,
sonst suchte jede Abfrage den Ort erneut.
Geholt wird serverseitig und zehn Minuten zwischengespeichert. Der Grund ist
nicht Sparsamkeit: Die Leiste steht auf jeder Seite jeder App, und fragte sie
selbst an, ginge bei jedem Seitenaufruf eine Anfrage samt IP an einen Fremden —
und die CSP jeder App muesste ihn erlauben.
Kein Ort eingestellt oder Dienst nicht erreichbar: 204, und das Symbol bleibt
weg. Eine Zahl von gestern waere schlechter als keine.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Aether und InkNote setzen viewport-fit=cover — als installierte App reicht ihr
Inhalt bis unter die Statusleiste. Eine Leiste, die stur bei 0 anfaengt, liegt
dort unter Uhrzeit und Akkustand. Sie waechst jetzt um env(safe-area-inset-top)
und polstert sich selbst; im Browser ist der Wert null und alles bleibt bei
32 px.
Das Polster der Seite wird dabei nicht mehr ausgerechnet, sondern gerechnet:
env() kennt nur der Browser, und erst beim Anzeigen. Nebenbei behebt das einen
Rundungsfehler beim Ausblenden — der urspruengliche Wert wird jetzt gemerkt
statt zurueckgerechnet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
