HoneyOS/IDEAS.md

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 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 HoneyBar trägt deine Röhre — ✅ erledigt (24.08.2026)

Die HoneyBar 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 HoneyBar 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 war: Bei mehreren Nutzern trägt die HoneyBar die Farbe des Standardnutzers, weil ihr über die Site-Grenze niemand sagen kann, wer da gerade schaut. Für Apps unter derselben Site erledigt seit dem 29.08.2026 — /api/apps sieht jetzt erst nach der Sitzung und erst dann nach dem Schlüssel. Über eine echte Site-Grenze bleibt es, wie es war.

1.2 Systemmenü im Logo — ✅ gebaut (29.08.2026)

Steht, in beiden Leisten mit denselben Punkten (siehe README). Der Abmeldeknopf in der Menüleiste des Schreibtischs ist dafür weggefallen — er stand sonst zweimal da, und die HoneyBar hat ihn nie gehabt.

Eine Annahme von damals hat sich nicht gehalten: „ohne sie zu verlassen" geht nicht, jedenfalls nicht für Einstellungen und Abmelden. Beides schreibt, und die HoneyBar darf in einer fremden App nicht schreiben — die Sitzung kommt über die Site-Grenze nicht mit, und selbst unter einer Domain liegt das CSRF-Prüfwort in einem Cookie, das nur HoneyOS' eigene Seiten lesen. Also reicht die HoneyBar die Frage als ?einstellungen=1 an den Schreibtisch weiter. Ein Klick, ein Seitenwechsel — dort, wo man angemeldet ist.

Abmelden ist ganz aus den Leisten verschwunden und steht unten in den Einstellungen (Marcs Entscheidung, 29.08.2026). Aus fremden Apps war es ohnehin nur ein Link auf den Schreibtisch gewesen; als einzige Schaltfläche, die eine Sitzung beendet, gehört es an eine Stelle statt an drei. Im selben Zug ist das Zahnrad aus der Menüleiste des Schreibtischs gefallen und durch den Pfeil mit der App-Liste ersetzt worden — damit tragen beide Leisten wirklich dieselben vier Dinge: Logo, Apps, Wetter/Uhr, Aufklappmenü.

Was ohne Seitenwechsel ginge, wenn es je stört: die reinen Aussehensschalter (Röhre, Leuchten, Scanlines) direkt im Menü. Sie kämen ohne Prüfwort aus, wenn der Server stattdessen den Origin der Anfrage gegen die eingetragenen Apps hält — dieselbe Liste, die heute schon die CORS-Freigabe steuert. Das ist eine Sicherheitsentscheidung und keine Kleinigkeit; erst bauen, wenn der Umweg über den Schreibtisch wirklich nervt.

1.3 App-Schublade mit Symbolen — ✅ gebaut (29.08.2026)

Gebaut: die geteilte Symbolquelle. Die Raster liegen in web/glyphs.json, der Schreibtisch lädt sie, die HoneyBar bekommt sie mit der App-Liste mit (siehe README). Damit tragen beide Leisten dieselben Symbole neben den App-Namen, und die doppelt abgetippten Wettersymbole sind weg.

Dazu ein Schalter Einstellungen → HoneyBar: Symbole im App-Streifen an oder aus, für beide Leisten zugleich. In den Aufklappmenüs und auf den Kacheln stehen sie immer — dort ist Platz, und dort sucht man eine App, statt sie im Vorbeigehen wiederzuerkennen.

Ebenfalls gebaut: die Schublade. Der Pfeil rechts klappt in beiden Leisten ein Raster auf — Symbol groß, Name, Untertitel als dritte Zeile. Drei Spalten, am Handy dieselben drei.

Entschieden (29.08.2026): Symbol und Name, nie nur Symbol. Der Grund ist nicht Geschmack, sondern der geteilte Satz von acht generischen Glyphen — zwei Apps können dieselbe Wolke tragen, und bei Homelab-Diensten ist das der Normalfall. Ein Symbol identifiziert erst, wenn es einzigartig ist. Dazu: Den Streifen sieht man im Vorbeigehen, die Schublade macht man auf, weil man sucht — Suchen heißt Lesen, und Platz ist dort genug. Namen wegzunehmen ist 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.

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 — ✅ gebaut (29.08.2026)

Heute stehen die Apps so, wie sie eingetragen wurden. Ab vier, fünf Stück ist das eine Frage — in der HoneyBar zuerst, weil dort der Platz am knappsten ist und die Reihenfolge entscheidet, was man am Handy ohne Wischen sieht.

Die halbe Arbeit ist schon getan: Die App-Liste ist ein Array, und dessen Reihenfolge ist die Reihenfolge — Streifen, Schublade, Kacheln, Schreibtischsymbole und Startmenü zeichnen alle daraus. Es fehlt nur eine Möglichkeit, das Array umzustellen. Kein neues Feld, kein neuer Endpunkt.

Pfeile statt Ziehen, im Programm-Editor je Zeile ein ▲▼:

	Aufwand	am Handy	Tastatur/Vorlesen
Pfeile	~40 Zeilen	sofort	ja
HTML5-Ziehen	~30 Zeilen	löst bei Berührung nicht aus	nein
Ziehen über Zeigerereignisse	~120 Zeilen	ja	nur mit Zusatzarbeit

Man sortiert vier bis sechs Apps einmal, in einer Liste aus aufklappbaren Zeilen — <details> und Ziehen vertragen sich ohnehin schlecht. Die Zeigerereignis-Variante lohnt erst, wenn sie mehrfach gebraucht wird, und genau das kommt: „Widgets verschieben" braucht sie zwingend. Wird sie dort gebaut, kann die App-Liste sie später erben.

Kein A–Z-Knopf (Marc, 29.08.2026): erstmal zu viel. Bei einer Handvoll Apps sortiert man einmal von Hand und rührt es nie wieder an — ein zweiter Weg dorthin ist Zierat. Kommt zurück, wenn er fehlt.

Die Zifferntasten sind bei der Gelegenheit ganz weggefallen. Sie waren ein Pflichtfeld je App, das man beim Anlegen ausfüllen musste, und sie hätten beim Sortieren dieselbe Frage aufgeworfen: mitwandern oder stehenbleiben? Beides falsch. Neue Apps hängen sich jetzt einfach hinten an, die Reihenfolge macht man mit den Pfeilen.

Beim Bauen aufgetreten:

• Der Klick auf einen Pfeil sitzt in einem <summary> — ohne preventDefault klappt jeder Sortierklick die Zeile auf.
• Beim Neuzeichnen müssen offene Zeilen offen bleiben.
• Gespeichert wird wie bisher die ganze Liste auf einmal: Man kann probieren, ohne dass sofort alles umspringt.

Und eine eigene Reihenfolge je Nutzer? — später, aber der Weg bleibt offen

Marcs Frage vom 29.08.2026. Das ist kein Entweder-oder: Eine persönliche Reihenfolge braucht die gemeinsame als Rückfall. Sie sähe so aus —

apps:                  [aether, inknote, status, pdf]   ← die Liste, für alle
users[marc].appOrder:  "pdf,aether,inknote"             ← nur IDs, nur seine Sicht

— unbekannte IDs ignorieren, fehlende hinten anhängen. Das passt ohne Datenmodell-Änderung in die bestehenden Einstellungen (map[string]string). Was jetzt gebaut wird, wird davon also nicht falsch.

Zwei Gründe, trotzdem mit der gemeinsamen anzufangen:

1. Es gibt einen Nutzer. „Meine Reihenfolge" und „die Reihenfolge" sind heute dasselbe — der Unterschied wäre nicht erlebbar, der Code müsste ihn für immer tragen.
2. Die HoneyBar in fremden Apps erkennt den Nutzer nicht. Sie weist sich mit dem Schlüssel aus, nicht mit einer Sitzung, und bekäme die Reihenfolge des Standardnutzers, während der Schreibtisch die eigene zeigt — derselbe Bruch wie heute bei den Farben.

→ Zusammen mit „Persönliche Apps je Nutzer" zu bauen. Die Bedingung dafür ist am 29.08.2026 weggefallen: Aether und InkNote liegen längst unter *.honeyos.duckdns.org, also unter derselben Site, und /api/apps sieht seither erst nach der Sitzung. Die HoneyBar weiß dort jetzt, wer schaut. Was bleibt, ist die Frage, ob es sich bei einem Nutzer lohnt.

1.4 Widget-Rahmen — ✅ gebaut (30.08.2026)

Ein Widget ist jetzt eine Beschreibung, kein Stück HTML im Dokument:

widgetAnmelden({
  id, titel,
  wo:       ["terminal", "desktop"],  // wo es erscheinen darf
  sichtbar: () => …,                  // Schalter aus → gar nicht erst da
  laden:    async () => false|void,   // false = es gibt nichts zu zeigen
  leer:     "verbergen" | "Text",     // was dann passiert
  inhalt:   () => "<html>",
  takt:     600000,                   // Nachladen, optional
})

Der Rahmen (web/js/widgets/rahmen.js) macht daraus im Terminal-Modus ein Fenster in der Widgetspalte und im Desktop-Modus ein Schild, kennt die vier Zustände (lädt · fertig · nichts da · Fehler) und hält den Nachladetakt. Ein Widget, das seinen Server nicht erreicht, sagt das in seinem eigenen Rahmen und reißt weder den Schreibtisch noch die anderen Widgets mit.

Umgestellt sind Benutzer, Wetter und der Systemzustand. Aus der index.html sind damit vier fest verdrahtete Kästen verschwunden, und aus dem Raster die Einzelplätze — vorher hätte das dritte Widget beides wieder angefasst.

Was dabei offen gelassen wurde: die dritte Form. Widgets sollen später auch als Aufklappfeld in der HoneyBar leben können, deshalb erzeugt inhalt() nur den Kern; die Verpackung entsteht im Rahmen. Und die Reihenfolge ist eine Liste — genau das, was „Widgets verschieben" braucht.

2 · Erste Widgets

Eines bauen, benutzen, dann entscheiden.

Widgets, die Daten aus den eigenen Apps holen, sind gestrichen (siehe „Bewusst nicht geplant"). Was bleibt, ist alles, was für sich allein steht: Wetter (gebaut), ein Bild, später vielleicht Uhr, Notizzettel, Systemzustand.

Wetter in der HoneyBar, neben der Uhr — ✅ gebaut (25.08.2026)

Steht. Zwei Orte, unabhängig voneinander: auf dem Schreibtisch, in der HoneyBar, beides oder keins. Seit dem 31.08.2026 an zwei Stellen — auf dem Schreibtisch ist das Wetter ein Widget wie jedes andere und steht in der Widget-Liste, für die Leiste gibt es den eigenen Schalter. Die Stadt wird einmal gesucht und mit ihren Koordinaten gespeichert; der Server holt das Wetter und legt es zehn Minuten beiseite, die Oberflächen zeigen nur, was er hergibt.

Offen geblieben ist eines mit Absicht: Die Stadt lässt sich nur auf dem Schreibtisch ändern, nicht aus der HoneyBar heraus. Ein Klick auf das Symbol führt dorthin. Der Grund ist derselbe wie bei allem anderen in der HoneyBar: Sie liest über den Schlüssel und darf nichts schreiben — und über eine Site-Grenze wüsste sie nicht, für wen sie es täte. Liegt alles unter einer Domain, wäre es nachrüstbar.

Die ursprüngliche Notiz, zur Nachvollziehbarkeit:

Wie es geplant war

Ein Pixelsymbol neben der Uhrzeit, dazu die Temperatur. Ein Klick öffnet ein kleines Feld, in dem die Stadt eingestellt wird. Alles im Röhren-Look: Sonne, Wolke, Regen, Schnee als 12×12-Raster wie die App-Symbole, keine bunten Fremdbilder.

Das ist der beste Kandidat für das erste Widget überhaupt, vor „letzte Dateien" — und zwar aus einem Grund, der von aussen nicht sichtbar ist: Wetter braucht keine der Voraussetzungen, an denen die anderen Widgets hängen. Kein CORS in Aether, keine Sitzung von InkNote, keine App-API. Es hängt an nichts, was sich noch ändern kann, und lässt sich an einem Abend fertig bauen. Damit beantwortet es die eigentliche Frage — schaut man überhaupt hin? — ohne dass vorher das halbe Fundament stehen muss.

Und es ist das erste Widget, das in der HoneyBar lebt statt auf dem Schreibtisch. Es ist damit zugleich der Probelauf für den Rahmen weiter unten.

Die Abfrage gehört auf den Server, nicht in den Browser. Open-Meteo braucht keinen Schlüssel und kostet nichts, aber wenn jede App-Seite selbst dort anfragt, geht bei jedem Seitenaufruf aus jeder App eine Anfrage samt IP an einen Fremden hinaus — und die CSP jeder App müsste den Wetterdienst erlauben. Holt HoneyOS es selbst und gibt es über /api/apps mit heraus (oder über einen eigenen kleinen Endpunkt), sieht der Dienst genau einen Server, die Apps bleiben unberührt, und ein Zwischenspeicher von zehn bis fünfzehn Minuten reicht vollkommen: Das Wetter ändert sich langsamer als eine Seite neu geladen wird.

Zu klären, wenn es soweit ist:

• Stadt → Koordinaten. Open-Meteo hat eine Suche dafür; das Ergebnis einmal speichern statt bei jeder Abfrage neu suchen.
• Wo die Stadt liegt. Zu den Einstellungen im Server, wie Röhre und Effekte — dann gilt sie auf jedem Gerät.
• Am Handy wird es eng. Uhr und Wetter nebeneinander in 32 px: Wahrscheinlich nur das Symbol, Temperatur erst ab einer gewissen Breite.
• Kein Netz, kein Wetter. Dann verschwindet das Symbol, statt eine Zahl von gestern als heutige auszugeben.

Zwei Leisten, zwei Stilsätze

Die HoneyBar in fremden Apps (honeybar.js, eigenes CSS im Shadow DOM) und die Menüleiste des Schreibtischs (.menubar in style.css) sehen gleich aus, sind aber getrennter Code — rund 19 Regeln hier, 30 dort, alle von Hand gleichgehalten.

Das ist bereits einmal auseinandergelaufen: Das Wetter stand zuerst nur in honeybar.js, und der Schalter „in der honeybar" schien auf dem Schreibtisch wirkungslos (25.08.2026). Es wird wieder passieren.

Zwei Auswege:

• Die Schreibtisch-Menüleiste durch honeybar.js ersetzen. Ein Stilsatz, eine Anatomie, und was die HoneyBar kann, kann der Schreibtisch automatisch auch. Kostet: Die Menüleiste hat Dinge, die die HoneyBar nicht hat (Einstellungsknopf, Abmelden, Avatar) — die müssten hinein, und die HoneyBar ist bewusst schlank.
• Die Farb- und Maßangaben in eine gemeinsame Datei ziehen, die beide einbinden. Kleiner Eingriff, löst aber nur die Hälfte: Aufbau und Verhalten bleiben doppelt.

→ Ersteres ist das Richtige, sobald die HoneyBar mehr kann als heute (Widgets, Systemmenü). Vorher lohnt der Umbau nicht.

Die HoneyBar ohne unsafe-inline

Fremde Apps bekommen die HoneyBar über den Reverse Proxy (siehe README). Dabei muss deren CSP heute style-src 'unsafe-inline' erlauben, weil die HoneyBar ihre Stile im Shadow DOM mitbringt — ohne das erscheint sie schwarz auf schwarz. Gemessen am 28.08.2026 an einer nachgebauten fremden App.

Auflösbar: Die Stile als eigene Datei neben honeybar.js ausliefern und im Shadow DOM per <link> einbinden. Dann genügt style-src 'self' https://honeyos…, und die CSP der fremden App bleibt streng. Kostet eine zweite Anfrage, die zwischengespeichert wird.

Zu prüfen ist dabei, was sonst noch inline gesetzt wird: die Lage der HoneyBar selbst und der Innenabstand, den sie der Seite verpasst. Über die CSSOM gesetzte Stile (el.style.x = …) fallen nicht unter die CSP — was im Markup steht, schon.

Bild-Widget — ✅ gebaut (30.08.2026)

Ein Widget, das ein Bild zeigt: hochgeladen oder als Adresse eingetragen. Genau eines je Nutzer; ein neues ersetzt das alte, ohne Verwaltung und ohne Liste.

Reizvoll daran ist, dass es das erste Widget wäre, das nichts abfragt, sondern etwas ist — der Schreibtisch bekommt damit einen persönlichen Zug, den keine Datenanzeige liefert.

Zu klären, wenn es soweit ist:

• Ablegen. HoneyOS speichert bisher nur eine JSON-Datei. Ein Bild heisst: Ordner unter /data, Grössengrenze, erlaubte Typen. SVG ist heikel — es kann Skripte enthalten und darf nicht einfach durchgereicht werden.
• Ausliefern mit Versionsanteil in der Adresse, sonst bleibt beim Austausch das alte im Zwischenspeicher hängen.
• Adresse statt Upload ist billiger zu bauen, holt aber eine fremde Anfrage auf jede Seite mit HoneyBar. Für den Schreibtisch unkritisch; sollte das Bild je in die HoneyBar wandern, wäre es eine Anfrage aus jeder App.
• Zuschneiden? Ein Bild in einem festen Rahmen ist entweder verzerrt oder beschnitten. object-fit: cover und gut — Zuschneiden von Hand ist ein eigenes Stück Arbeit.
• Passt zum Aufnehmen eigener App-Logos (1.3): dieselbe Ablage, dasselbe Ausliefern. Zusammen bauen spart die Hälfte.

Notiz-Widget — ✅ gebaut (30.08.2026), Sofort-Ansicht (31.08.2026)

Ein Zettel auf dem Schreibtisch: hineintippen, fertig. Serverseitig je Nutzer, also auf jedem Gerät derselbe Text.

Nachtrag 31.08.2026 — was daraus wurde. Aus dem „Zettel" ist die Notiz geworden, mit kleinem Markdown, einer Werkzeugleiste und Sofort-Ansicht: Der Text ist immer gesetzt zu sehen, roh ist nur die Zeile, in der die Schreibmarke steht. Der Weg über contenteditable wurde verworfen — man müsste aus dem HTML, das der Browser beim Tippen erzeugt, den Quelltext zurückraten, und ein Fehler dabei kostet Text. Die Grenze zu InkNote steht trotz Formatierung: ein Text, keine Liste von Notizen, keine Ordner, keine Suche.

Die Abgrenzung ist hier wichtiger als die Technik: InkNote gibt es schon. Der Zettel darf keine zweite Notiz-App werden — kein Titel, keine Liste, keine Ordner, keine Suche, keine Formatierung. Genau ein Textfeld, das man im Vorbeigehen benutzt: Einkaufszettel, eine Nummer, ein Gedanke. Alles, was länger lebt als ein Tag, gehört nach InkNote — ein Knopf „nach InkNote" (einfach ein Link) wäre die ehrlichere Antwort als ein zweites Feld.

Reizvoll ist es aus demselben Grund wie das Bild-Widget: Es ist etwas, statt etwas anzuzeigen. Und es braucht keine der Voraussetzungen, an denen die anderen Widgets hingen.

Zu klären, wenn es soweit ist:

• Wann wird gespeichert? Nicht bei jedem Tastendruck — verzögert wie die Einstellungen, plus beim Verlassen des Feldes. Sonst schreibt jede Taste die JSON-Datei neu.
• Länge begrenzen. Ein Zettel, kein Dokument; ein paar tausend Zeichen reichen, und der Server muss die Grenze durchsetzen, nicht das Formular.
• Zwei offene Geräte überschreiben einander. Ohne Konfliktbehandlung gewinnt das zuletzt gespeicherte. Für einen Zettel ist das vertretbar — man sollte es nur wissen und nicht später „Datenverlust" nennen.
• In der HoneyBar? Nur lesend, und auch das erst, wenn alles unter einer Domain liegt — schreiben kann sie von einer fremden Site aus nicht.

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 — ✅ gebaut (31.08.2026)

Widgets per Ziehen umsortieren, die Reihenfolge liegt beim Nutzer auf dem Server — also auf jedem Gerät gleich.

Der Haken ist nicht das Ziehen, sondern die zwei Betriebsarten. Im Terminal-Modus stehen die Widgets in einer Spalte (eine Reihenfolge), im Desktop-Modus als Schilder auf der Fläche (dort wären Koordinaten das Natürliche). Eine gemeinsame Liste für beides ist die einfachere Zusage: eine Reihenfolge, in beiden Ansichten dieselbe. Freie Plätze auf dem Schreibtisch wären das schönere Ziel, aber dann liegen zwei Anordnungen im Server, und beim Wechsel muss man sich entscheiden, welche gilt.

→ Vorschlag: eine Liste, beide Ansichten folgen ihr. Freie Plätze später, falls sie je fehlen.

Am Handy: Ziehen ist dort kein Standard — HTML5-Drag löst per Berührung nicht aus. Entweder Zeigerereignisse selbst behandeln (wie beim Fensterziehen schon gebaut) oder am Handy Pfeiltasten statt Ziehen anbieten. Nicht vergessen: Ohne das ist die Funktion am Handy schlicht nicht da.

Voraussetzung ist ein Widget-Verzeichnis — heute stehen Benutzer und Wetter fest im HTML. Sinnvoll zusammen mit dem Widget-Rahmen (1.4) zu bauen, nicht davor.

Gebaut (31.08.2026), wie vorgeschlagen: eine Liste, beide Ansichten folgen ihr. Dazu ein Schalter je Widget — wer den Systemzustand nicht sehen will, soll ihn abschalten können, ohne ihn nach unten zu schieben.

Beides steht in einer Einstellung: widgets = "benutzer,notiz,-system,…", das Minus heißt aus. Ein Feld statt zwei, weil beides zusammengehört: Ein ausgeschaltetes Widget behält seinen Platz. Damit brauchte es weder einen neuen Endpunkt noch eine neue Tabelle — die Einstellungen liegen ohnehin je Nutzer auf dem Server.

Ziehen ist es nicht geworden, sondern Pfeile — aus demselben Grund wie bei den Apps (1.3b): Am Handy löst HTML5-Drag per Berührung nicht aus, und die Liste ist kurz. Freie Plätze auf dem Schreibtisch bleiben offen, falls sie je fehlen.

Widgets in der HoneyBar selbst

Bisher sind Widgets als Fenster auf dem Schreibtisch gedacht. Der Schreibtisch ist aber die Seite, die man am seltensten offen hat — die HoneyBar dagegen ist überall. Naheliegend also: ein Knopf in der HoneyBar klappt dasselbe Widget als kleines Feld auf, ohne die App zu verlassen.

Technisch ist das dieselbe Sache wie 1.4, nur ein zweites Zuhause für denselben Inhalt: Der Rahmen muss dann drei Formen können — Fenster, Kachel, Aufklappfeld. Das ist beim Bauen von 1.4 zu bedenken, hinterher wird es teuer.

Für Widgets, die nur sich selbst brauchen (Wetter, Bild, Uhr), ist das geschenkt — sie fragen HoneyOS, nicht die App.

---

3 · Ausbau

3.x HoneyOS selbst als PWA — zurückgestellt (30.08.2026)

Heute ist HoneyOS eine Website: Es hat theme-color, aber kein Manifest, kein Symbol und keinen Service Worker — installierbar ist es damit nicht. Am Handy landet man also im Browser mit Adressleiste, während Aether und InkNote als eigene Apps danebenliegen. Das ist genau der Bruch, den das Ganze eigentlich verhindern soll: Der Schreibtisch sollte sich am wenigsten nach Website anfühlen.

Was dazugehört, klein bis groß:

1. Manifest — Name, Startadresse, display: standalone, Hintergrund- und Themenfarbe. Die Farben sollten der eingestellten Röhre folgen; sie liegen im Server, das Manifest kann also erzeugt statt fest hinterlegt werden (Aether macht das beim Symbol schon so).
2. Symbol — ein Pixelglyph in 192 und 512 px, im Amber-Look. Passt zum Rest und ist ohne fremde Werkzeuge zu machen.
3. Service Worker — nötig für die Installierbarkeit. Hier ist zu entscheiden, was er überhaupt soll (siehe unten).

Die eigentliche Frage ist der Offline-Fall. HoneyOS zeigt fremde Apps und später deren Daten — ohne Netz gibt es davon nichts. Ein Schreibtisch, der offline mit leeren Kacheln dasteht, ist schlimmer als ein ehrlicher Hinweis. Sinnvoll wäre: Oberfläche und App-Liste im Cache, damit man die Symbole sieht und antippen kann, und ein deutlicher Vermerk „ohne Verbindung". Widgets bleiben leer, statt Altes von gestern als aktuell auszugeben.

Aus dem Aether-Debakel gelernt und hier von Anfang an zu beachten: Ein Eintrag im Cache ist eine ganze Antwort samt Kopfzeilen. Wird die Startseite vorab abgelegt, friert damit auch ihre CSP ein — und eine Änderung an der Konfiguration erreicht den Browser nie wieder. Also Navigationen Netz zuerst, Cache nur als Rückfall.

Zurückgestellt (Marc, 30.08.2026): erst die Hauptfunktionen, dann das Gehäuse. Die PWA ist mehr Gefühl als Funktion — sie macht nichts möglich, was heute nicht ginge, während der Widget-Rahmen darunter alles Weitere trägt.

Reihenfolge: Erst umziehen (siehe unten), dann installierbar machen. Ein Ursprungswechsel macht aus einer installierten PWA eine fremde App — wer vorher installiert, installiert zweimal.

• 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 HoneyBar 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 HoneyBar 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 App lädt die HoneyBar bei jedem Aufruf nach, also ist sie immer 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 HoneyBar	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 HoneyBar mehr
data-push="none" (liegt darüber)	0 im Layout	verdeckt die Kopfzeile der App
ganz aus	0	schon eingebaut („honeybar ausblenden")

→ Vorschlag: am Rechner die volle HoneyBar, 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 Ursprung in der .env; das Verhalten der HoneyBar 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? — ✅ gelöscht (29.08.2026)

Mitsamt dem Feld „Wer-bin-ich". Die Begründung von damals hat sich gehalten: Es brachte allein den Anzeigenamen, wirkte an zwei Stellen unterschiedlich, und ein Token an eine fremde Adresse zu schicken war eine Falle, die niemand braucht.

Den Namen zeigt jetzt das Benutzer-Widget auf dem Schreibtisch, aus der HoneyOS-Anmeldung — dort, wo er hingehört, und ohne dass eine App etwas dafür tun muss.

Persönliche Apps je Nutzer?

Heute gilt die App-Liste für alle — bewusst so, siehe „Bewusst nicht geplant". Denkbar wäre daneben eine kleine eigene Liste je Konto.

Was dagegen spricht, ist nicht der Aufwand, sondern eine harte Grenze: Auf dem Schreibtisch ginge es sofort (dort ist man angemeldet). In der HoneyBar einer fremden App ginge es nicht, solange HoneyOS auf einer anderen Site liegt als die App — der Browser schickt die HoneyOS-Sitzung dann nicht mit, und der Schlüssel für die App-Liste weiß nicht, wer schaut. Die HoneyBar zeigte also die gemeinsamen Apps, der Schreibtisch zusätzlich die eigenen. Zwei verschiedene Listen an zwei Stellen ist schlechter als eine.

Liegt alles unter derselben Domain, fällt die Grenze weg: die Sitzung wird mitgeschickt, die HoneyBar weiß, wer da ist. Das ist seit dem 29.08.2026 der Fall — Aether liegt unter cloud.honeyos.duckdns.org, HoneyOS unter honeyos.duckdns.org, und /api/apps sieht erst nach der Sitzung und dann erst nach dem Schlüssel. Persönliche Apps sind damit machbar geworden.

→ Vorschlag: zurückstellen, bis es mehr als ein Konto gibt. Bei einer Person ist „persönlich" und „für alle" dasselbe. Der Weg ist aber offen und sollte es bleiben: nichts einbauen, was von einer einzigen gemeinsamen Liste ausgeht.

Wie weit soll das Aussehen der HoneyBar einstellbar sein?

Röhre, Leuchten und Scanlines kommen schon aus HoneyOS (1.1). Offen ist, was darüber hinaus in die Einstellungen gehört: Höhe, Schriftgröße, Position (oben oder unten), ob der Name der App danebensteht.

Die Versuchung ist, alles einstellbar zu machen. Jede Einstellung ist aber eine Verzweigung, die für immer funktionieren muss. Sinnvoll wäre der Schnitt: Farbe und Verhalten ja (das ändert man wirklich), Maße nein (die stellt man einmal ein und nie wieder — dann kann es auch gleich richtig fest stehen).

Alle Apps unter eine Domain ziehen?

honeyos.duckdns.org als Dach, die Apps darunter (cloud.honeyos.duckdns.org und so fort). Am 25.08.2026 gemessen: Dann schickt der Browser die HoneyOS-Sitzung an die HoneyBar mit, über eine fremde Site hinweg nicht.

Damit möglich, was heute nicht geht: mehrere Nutzer mit eigenem Aussehen, persönliche Apps, der Name in der HoneyBar. Und HONEYBAR_KEY samt CORS-Ausnahme wird überflüssig — der Umzug räumt Komplexität weg, statt welche zu schaffen.

Kosten sind einmalig, aber real: Redirect-URIs in PocketID, PUBLIC_URL und die Office-Adressen in Aether, InkNotes Token liegt pro Domain im localStorage (alle werden abgemeldet), Pangolin-Ressourcen, Zertifikate, PWAs einmal neu installieren, alte Freigabelinks per Weiterleitung am Leben halten.

→ Lohnt sich, sobald mehr als eine Person zugreift. Vorher ist es Geschmackssache, danach ist es die einzige Möglichkeit.

Aether und InkNote auch über den HoneyBar-Proxy? — ❌ nein (29.08.2026)

Verlockend war: ein Mechanismus statt zwei, und Aether verlöre den kleinen Rest HoneyBar-Code (honeybar.ts, zwei Felder in der öffentlichen Konfiguration, ein CSP-Eintrag, zwei .env-Zeilen).

Nicht der Aufwand spricht dagegen, sondern zwei andere Dinge:

• Ein Ausfallpunkt vor der Cloud. Fällt der Proxy vor BentoPDF aus, dreht man eine Stunde keine PDFs. Fällt er vor Aether aus, kommt man an die Rechnungen nicht heran. Derselbe Ausfall, ein anderer Preis.
• Der Umweg trägt alles mit: Uploads, WebDAV, Collabora, WebSockets. Und Accept-Encoding "" — nötig, weil im gzip-Strom nichts zu ersetzen ist — schaltet die Kompression für die ganze location ab. Ohne gzip on; im Proxy kämen Aethers Bundles unkomprimiert am Handy an.

Und der Teil, der ohnehin bliebe: --honeybar-h steht an acht Stellen in Aether (Sidebar, SharePage, FilePreview, OfficeEditor). Das Einhängen kann weg, die Layout-Rechnung nicht. In HoneyOS ginge sie nur, indem dort Aethers interne Klassennamen stünden — ein Umbau in Aether zerlegte das Layout dann still. In Aether kostet sie nichts: Ohne HoneyBar steht die Variable auf 0px.

→ Eigene Apps bauen die HoneyBar ein, fremde bekommen den Proxy. Der Proxy ist nicht der bessere Weg, sondern der für den Fall, dass der bessere verwehrt ist.

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.
• Nichts über die HoneyBar wird beim Bauen der Apps eingebacken. Die Adresse stand einmal fest in Aethers index.html. Das war aus zwei Gründen falsch: Ein fertiges Abbild lässt sich dann nicht über die .env umziehen, und der Service Worker der PWA hält die alte index.html im Cache, so dass eine Änderung selbst nach dem Neubau noch nicht ankommt. Ursprung und Schlüssel holt sich die App deshalb zur Laufzeit vom eigenen Server und hängt das Skript selbst ein.
• 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.
• Keine Widgets, die Daten aus Aether oder InkNote holen (gestrichen 29.08.2026). Dafür standen einmal zwei Punkte im Fundament: CORS in Aether und eine Cookie-Sitzung für InkNote. Beides ist nicht mehr gewollt — der Weg über den HoneyBar-Proxy zeigt HoneyOS in den Apps, statt die Apps in HoneyOS nachzubauen.
• HoneyOS speichert nichts aus den Apps. Keine Dateien, keine Notizen, keine Kopien — es zeigt, was die Apps hergeben, und hört da auf. Was der Schreibtisch selbst hervorbringt, ist etwas anderes (präzisiert 29.08.2026, als Bild- und Zettel-Widget dazukamen): ein hochgeladenes Bild, ein Zettel, ein App-Logo. Die Grenze verläuft nicht bei „Inhalt", sondern bei Zweitkopie: Nichts, was in einer App lebt, darf hier ein zweites Zuhause bekommen.
• 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.