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>
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.
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.
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 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.
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.
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>
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>
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>
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>
Dazu die Lehre aus der eingebackenen Adresse: nichts über die Leiste gehört in
den Bau der Apps — weder wegen des fertigen Abbilds noch wegen des Caches der
PWA.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Die Leiste soll zuerst die serverseitige Röhre übernehmen — kleinster
Eingriff, größte Wirkung fürs "ein System"-Gefühl. Danach Systemmenü im
Logo, dann die App-Schublade mit Symbolen.
Neu als offene Entscheidung: wie sichtbar die Leiste sein darf. Sie ist bei
jedem Aufruf der App da, auch wenn man mit HoneyOS gerade nichts zu tun hat.
Vorschlag steht dabei, ebenso der Hinweis, dass es keine Einbahnstraße ist.
Ausserdem defer an der Script-Zeile in README und Demo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nur Notizen, keine Änderung am Verhalten. Hält fest, was aufeinander aufbaut
(Fundament → erstes Widget → Ausbau), welche zwei Entscheidungen offen sind
(Symbole, Token-Schlüssel) und was bewusst nicht geplant ist, damit iframes
und PWA-Weg nicht alle paar Monate neu diskutiert werden.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
