RDietermann/dionotes-client
1
1
Fork 0
Code Issues 7 Pull Requests 2 Actions Packages Projects Releases Wiki Activity

Notiz-Handling: anlegen, speichern, umbenennen, loeschen #16

New Issue
Open
opened 2026-08-28 09:20:12 +00:00 by RDietermann · 1 comment
RDietermann commented 2026-08-28 09:20:12 +00:00
Owner
Copy Link

Destination

Eine Spec, mit der sich das Notiz-Handling am Stück bauen lässt: Notizen anlegen, bearbeiten, speichern, umbenennen und löschen — bis zu dem Punkt, an dem sich DioNotes zwei Wochen lang für echte Notizen benutzen lässt, ohne für irgendetwas davon in ein anderes Programm zu wechseln.

Notes

Domain: DioNotes — lokale Markdown-Notizen-App, Dioxus 0.7, Desktop. Der Workspace-Teil steht: Ordner öffnen, Notiz-Baum, Notiz anzeigen. Der Editor nimmt Eingaben entgegen und wirft sie weg — das ist der Zustand, den diese Map beendet.

Planen, nicht bauen. Jedes Ticket liefert eine Entscheidung. Beim Schreiben auf die Platte hängen die Entscheidungen besonders eng zusammen — Dirty-State, Auslösezeitpunkt und Konfliktverhalten lassen sich nicht sinnvoll einzeln bauen.

Skills pro Session: /grilling und /domain-modeling; /research für AFK-Recherche.

Rahmenentscheidungen aus dem Charting:

  • Umfang: anlegen, bearbeiten, speichern, umbenennen, löschen. Ohne Suche.
  • Gelöscht wird in den Papierkorb des Betriebssystems, nicht in einen eigenen. Das Versprechen der App lautet „deine Notizen sind gewöhnliche Dateien" — dann soll auch das Löschen sich gewöhnlich verhalten.
  • Umbenennen ja, Verschieben nein.
  • Weiterhin kein Filewatcher und ein Workspace gleichzeitig (aus der Workspace-Map).

Vorarbeit: Ein Council zu diesem Vorhaben hat drei Punkte geliefert, die sonst untergegangen wären: das Dirty-Flag als Voraussetzung für alles Weitere, das Schreiben über rename statt direkt, und die Zeitstempel-Frage, die mit darüber entscheidet, ob der ausgeschlossene Filewatcher später Pflicht wird.

Decisions so far

  • Papierkorb unter Rust: Crate, Netzlaufwerke, Kosten — trash 5.2.6, Aufruf trash::delete(&pfad). Kostet +6 Pakete unter Windows und lässt sich nicht per Feature drücken (anders als bei rfd); fünf davon sind eine zweite, semver-inkompatible Kopie der windows-Familie. Auf Netzlaufwerken funktioniert die Crate gar nicht — Pfad-Bug trash-rs#55, offen seit 2022, die Datei bleibt unversehrt liegen. Ohne den Bug würde Windows dort still und endgültig löschen und Ok(()) melden: am Rückgabewert ist der Fall nicht erkennbar, erkennbar wäre er nur über einen IFileOperationProgressSink, den die Crate hart als None übergibt. Daraus folgt zwingend eine Rückfrage vor dem Löschen. Blockierend, aber schnell (512 MiB in 27 ms; nur der erste Aufruf kostet 740 ms COM-Initialisierung). Ungemessen blieben USB-Sticks und der pro Volume abschaltbare Papierkorb auf lokalem NTFS. Langfassung: Branch research/papierkorb.
  • Was kostet es, Historie später möglich zu halten? — Nichts. Der Einwand ist entkräftet. „Temporäre Datei, dann umbenennen" schließt Historie nicht aus, sondern ist das einzige der beiden Verfahren, das sie billig macht: Historie braucht die Vorfassung, und die liegt beim Umbenennen noch unversehrt auf der Platte — ein direktes fs::write hat sie da schon vernichtet. Teuer wird Historie nicht durch das Wie des Schreibens, sondern durch das Wo: Gibt es genau eine Funktion, die eine Notiz schreibt, ist Historie später eine Änderung innerhalb dieser Funktion. Das ist die einzige Anforderung an #19 und kostet heute nichts, weil es noch gar keine Schreibstelle gibt. Die Asymmetrie läuft umgekehrt zur Behauptung: Der Append-Log ist die Einbahnstraße, nicht das schlichte Schreiben — die Automerge-Maintainer schreiben selbst, Historie lasse sich „nicht verwerfen, ohne das Dokument zu ersetzen", und ein ungepruntes Log misst im Yjs-Benchmark das 70-fache des Rohtexts. Langfassung: Branch research/historie.

Not yet specified

  • Notizen verschieben. Ausdrücklich im Hinterkopf zu behalten, aber nicht Teil dieser Map: Drag-and-Drop im Baum ist ein eigenes Zustandsmodell mit Zielmarkierung, Abbruch und der Frage, was beim Ziehen auf eine Datei passiert. Bis dahin führt der Weg über den Explorer und den ⟳-Knopf.
  • Filewatcher. Aus der Workspace-Map übernommen und hier deutlich relevanter: Sobald geschrieben wird, wird „die Datei hat sich unter uns geändert" von einer Unbequemlichkeit zu einer Frage der Datensicherheit. Ob die Antwort ein Watcher ist, hängt davon ab, wie der Zeitstempel-Konflikt gelöst wird.
  • Große Workspaces. Ab welcher Notizzahl Einlesen und Zustandsprüfung spürbar werden, und ob es dann einen Index braucht.
  • Verschlüsselung der Notizinhalte. Der geplante Passwortschutz soll gegen Dateisystemzugriff wirken; ein Hash im Marker leistet das nicht.

Out of scope

  • Suche. Ausdrücklich gewünscht und als nächstes Vorhaben nach dieser Map vorgesehen — aber mit eigenen Fragen (Index oder Volltext-Scan? Live-Ergebnisse? Nur Titel oder auch Inhalt?), die den Abschluss hier nur verzögern würden. Zwei Wochen Arbeit sind ohne sie möglich.
  • Historie und Undo über Sitzungen hinweg. Nicht geplant. In dieser Map steckt davon nur eine Frage: was es kostet, sie später möglich zu halten — damit die Schreib-Entscheidung bewusst statt versehentlich fällt.
  • Notizen verschlüsseln, Notizen exportieren, Synchronisation. Eigene Vorhaben.
## Destination Eine Spec, mit der sich das Notiz-Handling am Stück bauen lässt: Notizen anlegen, bearbeiten, **speichern**, umbenennen und löschen — bis zu dem Punkt, an dem sich DioNotes zwei Wochen lang für echte Notizen benutzen lässt, ohne für irgendetwas davon in ein anderes Programm zu wechseln. ## Notes **Domain:** DioNotes — lokale Markdown-Notizen-App, Dioxus 0.7, Desktop. Der Workspace-Teil steht: Ordner öffnen, Notiz-Baum, Notiz anzeigen. Der Editor nimmt Eingaben entgegen und **wirft sie weg** — das ist der Zustand, den diese Map beendet. **Planen, nicht bauen.** Jedes Ticket liefert eine Entscheidung. Beim Schreiben auf die Platte hängen die Entscheidungen besonders eng zusammen — Dirty-State, Auslösezeitpunkt und Konfliktverhalten lassen sich nicht sinnvoll einzeln bauen. **Skills pro Session:** `/grilling` und `/domain-modeling`; `/research` für AFK-Recherche. **Rahmenentscheidungen aus dem Charting:** - Umfang: anlegen, bearbeiten, speichern, umbenennen, löschen. **Ohne Suche.** - Gelöscht wird in den **Papierkorb des Betriebssystems**, nicht in einen eigenen. Das Versprechen der App lautet „deine Notizen sind gewöhnliche Dateien" — dann soll auch das Löschen sich gewöhnlich verhalten. - **Umbenennen ja, Verschieben nein.** - Weiterhin **kein Filewatcher** und **ein Workspace** gleichzeitig (aus der Workspace-Map). **Vorarbeit:** Ein Council zu diesem Vorhaben hat drei Punkte geliefert, die sonst untergegangen wären: das Dirty-Flag als Voraussetzung für alles Weitere, das Schreiben über `rename` statt direkt, und die Zeitstempel-Frage, die mit darüber entscheidet, ob der ausgeschlossene Filewatcher später Pflicht wird. ## Decisions so far <!-- ein Eintrag pro geschlossenem Ticket --> - [Papierkorb unter Rust: Crate, Netzlaufwerke, Kosten](https://gitlab.hive-brain.de/RDietermann/dionotes-client/issues/21) — `trash 5.2.6`, Aufruf `trash::delete(&pfad)`. **Kostet +6 Pakete unter Windows und lässt sich nicht per Feature drücken** (anders als bei `rfd`); fünf davon sind eine zweite, semver-inkompatible Kopie der `windows`-Familie. Auf **Netzlaufwerken funktioniert die Crate gar nicht** — Pfad-Bug `trash-rs#55`, offen seit 2022, die Datei bleibt unversehrt liegen. Ohne den Bug würde Windows dort **still und endgültig löschen** und `Ok(())` melden: am Rückgabewert ist der Fall nicht erkennbar, erkennbar wäre er nur über einen `IFileOperationProgressSink`, den die Crate hart als `None` übergibt. **Daraus folgt zwingend eine Rückfrage vor dem Löschen.** Blockierend, aber schnell (512 MiB in 27 ms; nur der erste Aufruf kostet 740 ms COM-Initialisierung). Ungemessen blieben USB-Sticks und der pro Volume abschaltbare Papierkorb auf lokalem NTFS. Langfassung: Branch `research/papierkorb`. - [Was kostet es, Historie später möglich zu halten?](https://gitlab.hive-brain.de/RDietermann/dionotes-client/issues/22) — **Nichts. Der Einwand ist entkräftet.** „Temporäre Datei, dann umbenennen" schließt Historie nicht aus, sondern ist das *einzige* der beiden Verfahren, das sie billig macht: Historie braucht die Vorfassung, und die liegt beim Umbenennen noch unversehrt auf der Platte — ein direktes `fs::write` hat sie da schon vernichtet. Teuer wird Historie nicht durch das **Wie** des Schreibens, sondern durch das **Wo**: Gibt es genau *eine* Funktion, die eine Notiz schreibt, ist Historie später eine Änderung innerhalb dieser Funktion. Das ist die einzige Anforderung an #19 und kostet heute nichts, weil es noch gar keine Schreibstelle gibt. Die Asymmetrie läuft umgekehrt zur Behauptung: **Der Append-Log ist die Einbahnstraße**, nicht das schlichte Schreiben — die Automerge-Maintainer schreiben selbst, Historie lasse sich „nicht verwerfen, ohne das Dokument zu ersetzen", und ein ungepruntes Log misst im Yjs-Benchmark das **70-fache** des Rohtexts. Langfassung: Branch `research/historie`. ## Not yet specified - **Notizen verschieben.** Ausdrücklich im Hinterkopf zu behalten, aber nicht Teil dieser Map: Drag-and-Drop im Baum ist ein eigenes Zustandsmodell mit Zielmarkierung, Abbruch und der Frage, was beim Ziehen auf eine Datei passiert. Bis dahin führt der Weg über den Explorer und den ⟳-Knopf. - **Filewatcher.** Aus der Workspace-Map übernommen und hier deutlich relevanter: Sobald geschrieben wird, wird „die Datei hat sich unter uns geändert" von einer Unbequemlichkeit zu einer Frage der Datensicherheit. Ob die Antwort ein Watcher ist, hängt davon ab, wie der Zeitstempel-Konflikt gelöst wird. - **Große Workspaces.** Ab welcher Notizzahl Einlesen und Zustandsprüfung spürbar werden, und ob es dann einen Index braucht. - **Verschlüsselung der Notizinhalte.** Der geplante Passwortschutz soll gegen Dateisystemzugriff wirken; ein Hash im Marker leistet das nicht. ## Out of scope - **Suche.** Ausdrücklich gewünscht und als **nächstes Vorhaben nach dieser Map** vorgesehen — aber mit eigenen Fragen (Index oder Volltext-Scan? Live-Ergebnisse? Nur Titel oder auch Inhalt?), die den Abschluss hier nur verzögern würden. Zwei Wochen Arbeit sind ohne sie möglich. - **Historie und Undo über Sitzungen hinweg.** Nicht geplant. In dieser Map steckt davon nur eine Frage: was es kostet, sie später *möglich* zu halten — damit die Schreib-Entscheidung bewusst statt versehentlich fällt. - **Notizen verschlüsseln, Notizen exportieren, Synchronisation.** Eigene Vorhaben.
RDietermann added the wayfinder:map label 2026-08-28 09:20:12 +00:00
RDietermann commented 2026-08-28 10:51:05 +00:00
Author
Owner
Copy Link

Übergabe — Arbeitsstand für eine neue Sitzung

Diese Map ist noch nicht implementierungsbereit. Sechs Entscheidungen stehen aus; erst danach lässt sich das Notiz-Handling am Stück bauen.

Wo es steht
Gebaut und auf main Workspace anlegen/öffnen, Notiz-Baum, Notiz anzeigen. Der Editor speichert nicht — Änderungen gehen beim Notizwechsel verloren.
Entschieden #21 (Papierkorb) und #22 (Historie), siehe Decisions so far
Offen #17 Dirty-State · #19 Schreibverfahren · #20 Zeitstempel-Konflikt · #23 Anlegen/Umbenennen · #24 Löschen — alle frei; #18 Speicher-Strategie wartet auf #17

Einstieg: #17 (Dirty-State). Daran hängt #18 unmittelbar, und ohne den Zustand lässt sich „vor dem Wechsel fragen" nicht einmal formulieren.

Was eine neue Sitzung zuerst lesen sollte

  1. docs/agents/issue-tracker.md — tea-Kommandos für diesen Tracker, inklusive der beiden Fallstricke (Assignees nur per PATCH, Dependencies brauchen owner/repo im Body) und des Branch-/PR-Workflows.
  2. CONTEXT.md — Glossar: Workspace, Marker, Workspace-Liste, Notiz, Selector, Editor.
  3. Diesen Map-Body, besonders Notes und Decisions so far.
  4. docs/research/ — die Langfassungen mit Quellen (kommen mit PR #25 auf main).

Zwei Dinge, die überraschen würden

Der Git-Fetch gegen diese Instanz ist kaputt. git push funktioniert, git fetch/clone bricht mit bad pack header ab — serverseitig wird ein packfile angekündigt, dann kommen nur leere Keepalives. Betroffen sind alle Repos der Instanz, nicht nur dieses; SSH und HTTPS gleichermaßen. Das Gitea-Log meldet dabei keinen Fehler, sondern Connection reset by peer von der Client-Seite — der Verdacht liegt deshalb auf der Netzstrecke (Firewall/DPI im Firmennetz), nicht auf dem Server. Ungeprüft: derselbe Klon-Versuch aus einem anderen Netz, etwa einem Handy-Hotspot. Wer das Repo auf einem neuen Gerät klonen will, sollte damit anfangen.

dx erzeugt assets/tailwind.css bei jedem vollen Build neu, obwohl Tailwind entfernt wurde und die Datei niemand verlinkt. Sie steht in der .gitignore; nicht wundern, nicht wieder einchecken.

Offene Nebenbaustellen

  • PR #25 wartet auf Merge (bringt die Recherche-Langfassungen nach main). Danach sind die lokalen Branches research/papierkorb und research/historie entbehrlich.
  • prototype/selector-ui ist gepusht und bleibt als Primärquelle zu #8 bestehen.
  • Aus #21 ungemessen geblieben: USB-Sticks und der pro Volume abschaltbare Papierkorb auf lokalem NTFS — vor der Umsetzung von #24 nachzuholen.
## Übergabe — Arbeitsstand für eine neue Sitzung **Diese Map ist noch nicht implementierungsbereit.** Sechs Entscheidungen stehen aus; erst danach lässt sich das Notiz-Handling am Stück bauen. ### Wo es steht | | | |---|---| | Gebaut und auf `main` | Workspace anlegen/öffnen, Notiz-Baum, Notiz anzeigen. Der Editor **speichert nicht** — Änderungen gehen beim Notizwechsel verloren. | | Entschieden | #21 (Papierkorb) und #22 (Historie), siehe *Decisions so far* | | Offen | #17 Dirty-State · #19 Schreibverfahren · #20 Zeitstempel-Konflikt · #23 Anlegen/Umbenennen · #24 Löschen — alle frei; #18 Speicher-Strategie wartet auf #17 | **Einstieg: #17 (Dirty-State).** Daran hängt #18 unmittelbar, und ohne den Zustand lässt sich „vor dem Wechsel fragen" nicht einmal formulieren. ### Was eine neue Sitzung zuerst lesen sollte 1. `docs/agents/issue-tracker.md` — `tea`-Kommandos für diesen Tracker, inklusive der beiden Fallstricke (Assignees nur per PATCH, Dependencies brauchen `owner`/`repo` im Body) und des Branch-/PR-Workflows. 2. `CONTEXT.md` — Glossar: Workspace, Marker, Workspace-Liste, Notiz, Selector, Editor. 3. Diesen Map-Body, besonders *Notes* und *Decisions so far*. 4. `docs/research/` — die Langfassungen mit Quellen (kommen mit PR #25 auf `main`). ### Zwei Dinge, die überraschen würden **Der Git-Fetch gegen diese Instanz ist kaputt.** `git push` funktioniert, `git fetch`/`clone` bricht mit `bad pack header` ab — serverseitig wird ein `packfile` angekündigt, dann kommen nur leere Keepalives. Betroffen sind **alle** Repos der Instanz, nicht nur dieses; SSH und HTTPS gleichermaßen. Das Gitea-Log meldet dabei keinen Fehler, sondern `Connection reset by peer` von der Client-Seite — der Verdacht liegt deshalb auf der Netzstrecke (Firewall/DPI im Firmennetz), nicht auf dem Server. **Ungeprüft:** derselbe Klon-Versuch aus einem anderen Netz, etwa einem Handy-Hotspot. Wer das Repo auf einem neuen Gerät klonen will, sollte damit anfangen. **`dx` erzeugt `assets/tailwind.css` bei jedem vollen Build neu**, obwohl Tailwind entfernt wurde und die Datei niemand verlinkt. Sie steht in der `.gitignore`; nicht wundern, nicht wieder einchecken. ### Offene Nebenbaustellen - **PR #25** wartet auf Merge (bringt die Recherche-Langfassungen nach `main`). Danach sind die lokalen Branches `research/papierkorb` und `research/historie` entbehrlich. - `prototype/selector-ui` ist gepusht und bleibt als Primärquelle zu #8 bestehen. - Aus #21 ungemessen geblieben: USB-Sticks und der pro Volume abschaltbare Papierkorb auf lokalem NTFS — vor der Umsetzung von #24 nachzuholen.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
wayfinder:grilling
Wayfinder-Ticket: Entscheidung im Gespraech (HITL)
 wayfinder:map
Wayfinder-Map: der Index eines Planungs-Efforts
 wayfinder:prototype
Wayfinder-Ticket: billiger Prototyp als Diskussionsgrundlage (HITL)
 wayfinder:research
Wayfinder-Ticket: Fakten beschaffen (AFK)
 wayfinder:task
Wayfinder-Ticket: manuelle Arbeit, die eine Entscheidung blockiert
No Label wayfinder:map
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
RDietermann
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: RDietermann/dionotes-client#16
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?