# 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 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](README.md)). 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. Die HoneyBar hat die Frage deshalb als `?einstellungen=1` an den Schreibtisch weitergereicht. **Auch das ist seit dem 01.09.2026 weg** (Marcs Einwand): Wenn der Punkt ohnehin nur weiterleitet, ist er neben „Schreibtisch" keine zweite Möglichkeit, sondern dieselbe mit einem Zwischenschritt weniger. Das Bar-Menü trägt jetzt Schreibtisch und Einklappen, sonst nichts. **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](README.md)). 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 — `
` 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 `` — 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: ```js 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: () => "", 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` — ✅ gebaut (11.09.2026) Fremde Apps mussten für die HoneyBar `style-src 'unsafe-inline'` erlauben, weil sie ihre Stile im Shadow DOM als `