marcandClaude Opus 5
944b2c63e2
Ein Office-Dokument öffnete am Telefon als gewandeltes PDF, weil OnlyOffices Oberfläche auf 400 Pixeln nichts vom Dokument übrig lässt. Die Begründung war falsch: Die Ermittlungsliste bietet zu jeder Endung mehrere Aktionen an, und OnlyOffice/Euro-Office führen neben `edit` auch `mobileEdit` – dieselbe Adresse mit `?mobile=1`, dahinter eine für kleine Schirme gebaute Oberfläche. `EditURL` kannte nur `edit` und `view`; die Handy-Fassung lag die ganze Zeit in der Tabelle und wurde nie abgerufen. Entschieden wird am Zeigegerät, nicht an der Fensterbreite – ein schmales Fenster auf dem Schreibtisch ist immer noch eine Maus. Mit dem Anlass fällt die Notlösung: preview.go (229 Zeilen), convert.go (271) samt Test, files.preview_version (Migration 000026), die Sonderabfrage im GC, die Route und dreizehn Fundstellen im Frontend. convert.go hatte keinen anderen Aufrufer – die gesamte Umwandlung nach PDF existierte allein für diese Ansicht. Wer ein PDF braucht, exportiert es im Editor. Die Dateien unter previews/ sammelt der GC ein. Zwei Fehler, die dabei sichtbar wurden: fix(history): „Edit" schloss die Datei, statt den Editor zu öffnen. Beim Wechsel räumt React erst die alte Ansicht ab; der Aufräumer von useBackClose ruft history.back(), das verzögert wirkt und deshalb den Eintrag verbrauchte, den der Editor gerade angelegt hatte. Ein Zähler für selbst ausgelöste Schritte verschluckt genau diese popstate. fix(filetypes): `.txt` ging gar nicht auf. Es stand in officeExtensions und lief damit in den Office-Zweig statt in den eingebauten Text-Editor – am Telefon in die PDF-Umwandlung, die daran scheiterte. `md`, `log` und `rst` standen nie drin; das war die Asymmetrie. Dazu Euro-Office als Compose-Profil (Abbild 6,99 GB, nachgemessen – die Ankündigung nennt 5) und die Android-App als Idee. Geprüft: go build/vet sauber, tsc sauber, 37 Vitest-Tests, alle 234 Prüfungen der sieben Selbsttest-Suiten grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
131 lines
6.4 KiB
Markdown
131 lines
6.4 KiB
Markdown
# Ideen
|
||
|
||
Was noch kommen könnte. **Nichts davon ist beschlossen** — beschlossen ist,
|
||
was im [README](README.md) und in den Plänen steht
|
||
([cloud-projekt-plan.md](cloud-projekt-plan.md), [kalender-plan.md](kalender-plan.md)).
|
||
|
||
Hier landet, was einen guten Grund hat, aber gerade keinen Anlass. Der
|
||
Unterschied ist wichtig: Eine Funktion ohne Anlass zu bauen ist der Weg, auf
|
||
dem eine Anwendung unübersichtlich wird.
|
||
|
||
---
|
||
|
||
## Kalender
|
||
|
||
### Öffentlicher Abo-Link — vertagt (12.09.2026)
|
||
|
||
Ein Nur-Lese-Link auf einen Kalender, den jemand **ohne Konto** abonnieren
|
||
kann. Nicht dasselbe wie die Freigabe an ein Konto (die steht seit dem
|
||
12.09.2026): Dort ist der Empfänger bekannt, hier ist er es nicht.
|
||
|
||
**Warum vertagt:** kein Anlass. Marc ist der einzige Nutzer seiner Cloud, und
|
||
für den eigenen Gebrauch gibt es bereits zwei Wege an dieselben Termine — die
|
||
Weboberfläche und CalDAV mit App-Passwort.
|
||
|
||
**Wofür es gut wäre, wenn der Anlass kommt:**
|
||
|
||
* Den eigenen Kalender in einer *fremden* Anwendung einblenden, die kein
|
||
CalDAV mit Anmeldung kann, sondern nur eine `.ics`-Adresse frisst — etwa
|
||
ein Kalender auf der Arbeit.
|
||
* Einen Terminplan an Familie oder Verein geben, ohne für jeden ein Konto
|
||
anzulegen.
|
||
|
||
**Wie es gebaut würde** (damit die Überlegung nicht verloren geht):
|
||
|
||
Aether hat die Freigabelinks für Dateien schon, samt Token, optionalem
|
||
Passwort, Ablaufdatum und dem Zähler. Ein Kalender-Abo ist dieselbe Sache mit
|
||
einer anderen Ausgabe: `GET /share/kalender/{token}.ics` liefert den Export,
|
||
den es schon gibt (`api.go`, `Export`).
|
||
|
||
Drei Dinge wären dabei zu entscheiden, und sie sind der eigentliche Inhalt:
|
||
|
||
1. **Nur lesend, ohne Ausnahme.** Ein schreibbarer Link wäre ein Konto ohne
|
||
Passwort.
|
||
2. **Was steht drin?** Ein Abo zeigt Titel, Ort und Beschreibung jedes
|
||
Termins. Wer „Arzttermin, Dr. Müller" im Kalender stehen hat und den Link
|
||
weitergibt, gibt das mit weiter. Ein Schalter „nur Belegt/Frei" (Titel
|
||
durch „Belegt" ersetzen) wäre deshalb kein Zierrat, sondern der Grund,
|
||
warum man den Link überhaupt zu teilen wagt.
|
||
3. **Ein Abo wird regelmäßig abgerufen**, nicht einmal. Ein Kalenderprogramm
|
||
fragt alle paar Minuten nach. Der Zähler der Freigabelinks zählte dann
|
||
Maschinen statt Menschen, und die Sperre nach zehn Fehlversuchen träfe
|
||
einen Client, der bloß ein falsch gespeichertes Passwort wiederholt.
|
||
Beides müsste für diesen Linktyp anders sein.
|
||
|
||
### Aufgabenansicht (VTODO) — vertagt (12.09.2026)
|
||
|
||
Aether nimmt Aufgaben bereits an, speichert sie und gleicht sie ab; die Spalte
|
||
`component` in `cal_objects` unterscheidet sie von Terminen. Es fehlt **nur**
|
||
die Ansicht in der Weboberfläche.
|
||
|
||
**Warum vertagt:** Auf Marcs Telefon gibt es nichts, was sie zeigen würde.
|
||
|
||
Android hat von Haus aus **keinen Speicher für Aufgaben**. Für Termine gibt es
|
||
einen Systemanbieter — den füllt DAVx5, und Samsung Kalender liest daraus. Für
|
||
Aufgaben gibt es das nicht. DAVx5 kann Aufgabenlisten deshalb nur abgleichen,
|
||
wenn eine App installiert ist, die selbst den Speicher mitbringt:
|
||
**`tasks.org`**, OpenTasks oder jtx Board.
|
||
|
||
**Samsungs „Erinnerungen" gehört nicht dazu.** Der Bereich „Erinnerungen" im
|
||
Samsung Kalender ist kein Teil des Kalenders, sondern ein Fenster in die
|
||
Samsung-Erinnerungen-App; die hängt am Samsung-Konto (bzw. an Microsoft To Do),
|
||
nicht an CalDAV. Der Unterschied ist am Gerät ablesbar: Beim Anlegen eines
|
||
**Termins** fragt Samsung Kalender, in welchen Kalender — dort steht Aether zur
|
||
Auswahl. Beim Anlegen einer **Erinnerung** fragt es das nicht, weil es nur
|
||
einen Ort gibt, an den sie gehen kann.
|
||
|
||
Eine Ansicht in Aether wäre heute also eine reine Weboberflächen-Aufgabenliste –
|
||
ohne Weg, vom Telefon aus etwas hineinzuschreiben. Das ist ein eigenes
|
||
Vorhaben, kein Nebenprodukt des Kalenders.
|
||
|
||
**Der Anlass wäre: `tasks.org`.** Kostenlos, quelloffen, arbeitet mit DAVx5
|
||
zusammen und bringt den Aufgabenspeicher mit, der Android fehlt. Ist die App
|
||
installiert und das Aether-Konto in DAVx5 für Aufgabenlisten eingeschaltet,
|
||
landen Aufgaben vom Telefon in Aether — und dann hat die Ansicht in der
|
||
Weboberfläche einen Anlass. Der Unterbau steht bereits: Aether meldet seinen
|
||
Kalendern `VTODO` als unterstützt, nimmt sie an, speichert sie und gleicht sie
|
||
über `sync-collection` ab. Zu bauen bliebe die Ansicht selbst — eine Liste mit
|
||
Häkchen, Fälligkeit und Priorität, sinnvollerweise als vierte Ansicht neben
|
||
Monat, Woche und Liste.
|
||
|
||
**Was beim Bauen zu bedenken wäre:** Eine Aufgabe hat *kein* Pflichtdatum. Alle
|
||
drei heutigen Ansichten ordnen nach Zeit — eine Aufgabe ohne Fälligkeit hätte
|
||
darin keinen Platz. Das ist der Grund, warum es eine eigene Ansicht braucht und
|
||
kein Einstreuen in den Monat.
|
||
|
||
**Gegentest, falls die Einschätzung falsch ist:** DAVx5 öffnen, Aether-Konto
|
||
antippen. Gibt es dort einen Reiter „Aufgabenlisten" mit Einträgen, ohne dass
|
||
eine der genannten Apps installiert ist, stimmt das oben nicht.
|
||
|
||
---
|
||
|
||
## Eine Android-App — notiert (15.09.2026)
|
||
|
||
Eine einfache eigene App fürs Telefon, statt der installierten Weboberfläche.
|
||
|
||
**Warum das nicht offensichtlich ist:** Die Weboberfläche *ist* am Telefon
|
||
schon installierbar, hat ein eigenes Symbol, läuft ohne Adressleiste und kennt
|
||
die sicheren Bereiche neben Uhr und Wischbalken. Eine App, die nur dasselbe in
|
||
einem Rahmen zeigt, wäre Arbeit ohne Gewinn.
|
||
|
||
**Was eine echte App kann, was die Weboberfläche nicht kann** — und nur dafür
|
||
lohnt sie sich:
|
||
|
||
* **Fotos automatisch hochladen.** Der eigentliche Grund, warum Leute die
|
||
Nextcloud-App installieren. Der Browser darf im Hintergrund nicht auf die
|
||
Galerie, eine App schon.
|
||
* **„Teilen mit → Aether"** aus jeder anderen App heraus. Ein Anhang aus dem
|
||
Mailprogramm landet in einem Tippen in der Cloud.
|
||
* **Hochladen, das weiterläuft**, wenn der Schirm aus ist. Ein Browser-Tab
|
||
wird nach Sekunden angehalten; ein großer Upload bricht deshalb ab.
|
||
* **Dateien im Android-Dateimanager** über einen Storage Access Provider.
|
||
|
||
**Was es kosten würde:** Ein zweiter Stapel (Kotlin oder Flutter), eine zweite
|
||
Veröffentlichungskette, und jede Serveränderung ist ab dann an zwei Stellen
|
||
nachzuziehen. Die bestehende REST-Schnittstelle plus App-Passwörter genügen
|
||
als Unterbau, ein neues Backend wäre es nicht.
|
||
|
||
**Der Anlass wäre: automatischer Fotoupload.** Solange das nicht gebraucht
|
||
wird, ist die installierte Weboberfläche der bessere Weg — sie ist da, sie ist
|
||
gepflegt, und sie ist genau eine Codebasis.
|