Fehlerfälle beim Anlegen und Öffnen #6

New Issue

RDietermann · 2026-08-27T12:32:55Z

RDietermann commented

2026-08-27 12:32:55 +00:00

Part of #1

Question

Was passiert, wenn beim Anlegen oder Öffnen eines Workspace etwas schiefgeht?

Die Fälle, die real vorkommen:

Ein Workspace aus der Liste existiert nicht mehr — Ordner verschoben, umbenannt, gelöscht, oder es ist ein nicht eingehängtes Netzlaufwerk.
Der .dionotes/-Marker fehlt in einem Ordner, der in der Liste steht.
Der Nutzer wählt beim Anlegen einen Ordner, der bereits ein Workspace ist.
Der Nutzer wählt einen Ordner ohne Schreibrechte, oder der Marker lässt sich nicht anlegen.
Der gewählte Ordner ist nicht leer und enthält bereits fremde Dateien.

Zu entscheiden ist pro Fall: Was sieht der Nutzer, und was tut die App mit dem Listeneintrag — stillschweigend entfernen, als defekt markieren, stehen lassen? Und übergreifend: Werden Fehler im Selector inline angezeigt oder als Dialog?

Zielgröße: eine Tabelle Fall → Anzeige → Konsequenz für die Liste.

Nachtrag nach #4 (Dateiformate). Zwei der oben gelisteten Fälle sind dort bereits entschieden und hier nicht neu zu verhandeln:

Der .dionotes/-Marker ist beschädigt oder nicht parsebar: Workspace nicht öffnen, Fehler zeigen, Marker nicht neu anlegen. Begründung steht in #4 — sobald ein Passwort-Hash im Marker liegt, wäre stillschweigendes Neuanlegen ein Weg, den Schutz auszuhebeln.
Die Workspace-Liste ist beschädigt: verwerfen, mit leerer Liste starten.

Offen bleibt hier, was der Nutzer davon sieht: Wie wird der Fehler dargestellt (inline im Selector oder als Dialog), und was passiert mit dem betroffenen Listeneintrag — stillschweigend entfernen, als defekt markieren oder stehen lassen?

Ebenfalls neu durch #4: Der Fall „Ordner ohne Marker steht in der Liste" ist jetzt scharf von „Marker vorhanden, aber unlesbar" zu trennen — das sind zwei verschiedene Zustände mit womöglich verschiedenen Antworten.

Part of #1 ## Question Was passiert, wenn beim Anlegen oder Öffnen eines Workspace etwas schiefgeht? Die Fälle, die real vorkommen: - Ein Workspace aus der Liste existiert nicht mehr — Ordner verschoben, umbenannt, gelöscht, oder es ist ein nicht eingehängtes Netzlaufwerk. - Der `.dionotes/`-Marker fehlt in einem Ordner, der in der Liste steht. - Der Nutzer wählt beim Anlegen einen Ordner, der bereits ein Workspace ist. - Der Nutzer wählt einen Ordner ohne Schreibrechte, oder der Marker lässt sich nicht anlegen. - Der gewählte Ordner ist nicht leer und enthält bereits fremde Dateien. Zu entscheiden ist pro Fall: Was sieht der Nutzer, und was tut die App mit dem Listeneintrag — stillschweigend entfernen, als defekt markieren, stehen lassen? Und übergreifend: Werden Fehler im Selector inline angezeigt oder als Dialog? Zielgröße: eine Tabelle Fall → Anzeige → Konsequenz für die Liste. --- **Nachtrag nach #4 (Dateiformate).** Zwei der oben gelisteten Fälle sind dort bereits entschieden und hier **nicht** neu zu verhandeln: - *Der `.dionotes/`-Marker ist beschädigt oder nicht parsebar*: Workspace **nicht öffnen**, Fehler zeigen, Marker **nicht** neu anlegen. Begründung steht in #4 — sobald ein Passwort-Hash im Marker liegt, wäre stillschweigendes Neuanlegen ein Weg, den Schutz auszuhebeln. - *Die Workspace-Liste ist beschädigt*: verwerfen, mit leerer Liste starten. Offen bleibt hier, **was der Nutzer davon sieht**: Wie wird der Fehler dargestellt (inline im Selector oder als Dialog), und was passiert mit dem betroffenen Listeneintrag — stillschweigend entfernen, als defekt markieren oder stehen lassen? Ebenfalls neu durch #4: Der Fall *„Ordner ohne Marker steht in der Liste"* ist jetzt scharf von *„Marker vorhanden, aber unlesbar"* zu trennen — das sind zwei verschiedene Zustände mit womöglich verschiedenen Antworten.

RDietermann added the wayfinder:grilling label 2026-08-27 12:32:55 +00:00

RDietermann added a new dependency 2026-08-27 12:36:04 +00:00

#4 Dateiformate: App-Konfiguration und .dionotes-Marker

RDietermann added a new dependency 2026-08-27 12:36:05 +00:00

#2 Nativer Ordner-Dialog unter Dioxus 0.7 Desktop

RDietermann self-assigned this 2026-08-28 06:30:28 +00:00

RDietermann commented

2026-08-28 06:35:19 +00:00

Antwort

Die Regel

Statt einer Liste, welcher Fall wo erscheint — die veraltet, sobald ein Fall dazukommt:

Zustand → inline. Unterbrechung einer laufenden Aktion → Dialog.

Zustände stehen an ihrem Ort und bleiben dort (ein Listeneintrag, der nicht erreichbar ist). Unterbrechungen treten mitten in etwas auf, das der Nutzer gerade angestoßen hat, und brauchen eine Antwort oder Kenntnisnahme, bevor es weitergeht.

Beim Öffnen — inline am Listeneintrag

Fall	Markierung	Der Eintrag
Ordner existiert nicht	nicht erreichbar	bleibt
Ordner existiert, kein `.dionotes/`	kein Workspace mehr	bleibt
Marker vorhanden, aber unlesbar	beschädigt	bleibt
Die Workspace-Liste selbst ist unlesbar	Hinweis, dass sie verworfen wurde	Liste startet leer

Kein Eintrag wird jemals automatisch entfernt. Der häufigste Grund für „Ordner existiert nicht" ist nicht Löschung, sondern ein Laufwerk, das gerade nicht da ist — ein abgezogener Stick, ein nicht eingehängtes Netzlaufwerk. Automatisches Aufräumen würde den Eintrag genau dann wegwerfen, wenn nichts kaputt ist, und der Nutzer müsste den Pfad neu heraussuchen, obwohl er nur den Stick einstecken wollte.

Die drei Zustände werden unterschiedlich benannt, weil sie zu verschiedenen Handlungen führen: Stick einstecken — Ordner wiederherstellen — Datei reparieren.

Ein Klick auf einen markierten Eintrag versucht es erneut. Damit ist „Stick wieder eingesteckt" ohne eigenen Knopf abgedeckt; schlägt es wieder fehl, bleibt die Markierung stehen.

Für kein Workspace mehr braucht es keinen eigenen Weg zurück: Der Nutzer kann den Ordner über Anlegen erneut auswählen, und da ein bereits vorhandener Workspace dort geöffnet statt abgelehnt wird (siehe unten), führt derselbe Weg in beiden Fällen zum Ziel.

Das Entfernen von Hand ist damit eine Anforderung, aber kein Teil dieser Map — es liegt als „Workspace entfernen" im Fog.

Beim Anlegen — Dialog

Fall	Verhalten
Nutzer bricht den nativen Ordner-Dialog ab	Nichts passiert. Kein Fehler, keine Meldung — `pick_folder()` liefert `None`, das ist eine Absage, keine Störung
Gewählter Ordner ist bereits ein Workspace	Kein Fehler: öffnen, und falls noch nicht in der Liste, aufnehmen
Gewählter Ordner ist nicht leer	Rückfrage („enthält bereits Dateien — trotzdem anlegen?"), Bestätigen oder Abbrechen
Keine Schreibrechte / Marker nicht anlegbar	Fehlerdialog, Vorgang abgebrochen

Bereits ein Workspace → öffnen statt melden. Der Nutzer hat unmissverständlich auf diesen Ordner gezeigt. Ihm zu sagen „das ist bereits ein Workspace" und ihn dann in den Öffnen-Tab zu schicken, ist eine Belehrung mit Extraarbeit. Streicht einen Fehlerfall ersatzlos.

Nicht leer → immer fragen, auch wenn der Ordner ausschließlich Markdown-Dateien enthält. Klüger wäre, nur bei fehlenden .md zu fragen — aber eine Regel, die mal greift und mal nicht, ist schwerer zu durchschauen als eine, die immer gilt, und wirkt unberechenbar, wenn sie danebenliegt. Die Rückfrage trifft jeden Workspace genau einmal in seinem Leben, weil sie nur beim Anlegen auftritt.

Zwei Punkte, die beim Ausformulieren aufgefallen sind

1. Wann wird der Zustand der Einträge geprüft? Die Markierungen setzen voraus, dass die App den Zustand kennt, bevor der Nutzer klickt — also eine Prüfung pro Eintrag beim Anzeigen der Liste. Bei einem nicht eingehängten Netzlaufwerk kann bereits path.exists() in ein Timeout von mehreren Sekunden laufen, und das würde den Selector beim Start blockieren — ausgerechnet den Bildschirm, den jeder Start zuerst zeigt.

Die Prüfung gehört deshalb nebenläufig, mit den Einträgen zunächst unmarkiert. Wie das in Dioxus 0.7 sauber aussieht (use_resource pro Eintrag oder eine gemeinsame Aufgabe), ist beim Bauen zu klären; als Fog auf der Map vermerkt.

2. Der Ordner ohne Marker ist nicht immer ein Fehler. Er tritt auch auf, wenn der Nutzer beim Anlegen einen frischen Ordner wählt — dann ist „kein Marker" der erwartete Ausgangszustand. Die Markierung gilt ausschließlich für Einträge, die bereits in der Liste stehen.

## Antwort ### Die Regel Statt einer Liste, welcher Fall wo erscheint — die veraltet, sobald ein Fall dazukommt: > **Zustand → inline. Unterbrechung einer laufenden Aktion → Dialog.** Zustände stehen an ihrem Ort und bleiben dort (ein Listeneintrag, der nicht erreichbar ist). Unterbrechungen treten mitten in etwas auf, das der Nutzer gerade angestoßen hat, und brauchen eine Antwort oder Kenntnisnahme, bevor es weitergeht. ### Beim Öffnen — inline am Listeneintrag | Fall | Markierung | Der Eintrag | | --- | --- | --- | | Ordner existiert nicht | **nicht erreichbar** | bleibt | | Ordner existiert, kein `.dionotes/` | **kein Workspace mehr** | bleibt | | Marker vorhanden, aber unlesbar | **beschädigt** | bleibt | | Die Workspace-Liste selbst ist unlesbar | Hinweis, dass sie verworfen wurde | Liste startet leer | **Kein Eintrag wird jemals automatisch entfernt.** Der häufigste Grund für „Ordner existiert nicht" ist nicht Löschung, sondern ein Laufwerk, das gerade nicht da ist — ein abgezogener Stick, ein nicht eingehängtes Netzlaufwerk. Automatisches Aufräumen würde den Eintrag genau dann wegwerfen, wenn nichts kaputt ist, und der Nutzer müsste den Pfad neu heraussuchen, obwohl er nur den Stick einstecken wollte. Die drei Zustände werden **unterschiedlich benannt**, weil sie zu verschiedenen Handlungen führen: Stick einstecken — Ordner wiederherstellen — Datei reparieren. **Ein Klick auf einen markierten Eintrag versucht es erneut.** Damit ist „Stick wieder eingesteckt" ohne eigenen Knopf abgedeckt; schlägt es wieder fehl, bleibt die Markierung stehen. Für **kein Workspace mehr** braucht es keinen eigenen Weg zurück: Der Nutzer kann den Ordner über *Anlegen* erneut auswählen, und da ein bereits vorhandener Workspace dort geöffnet statt abgelehnt wird (siehe unten), führt derselbe Weg in beiden Fällen zum Ziel. Das Entfernen von Hand ist damit eine Anforderung, aber kein Teil dieser Map — es liegt als „Workspace entfernen" im Fog. ### Beim Anlegen — Dialog | Fall | Verhalten | | --- | --- | | Nutzer bricht den nativen Ordner-Dialog ab | **Nichts passiert.** Kein Fehler, keine Meldung — `pick_folder()` liefert `None`, das ist eine Absage, keine Störung | | Gewählter Ordner ist bereits ein Workspace | **Kein Fehler: öffnen**, und falls noch nicht in der Liste, aufnehmen | | Gewählter Ordner ist nicht leer | **Rückfrage** („enthält bereits Dateien — trotzdem anlegen?"), Bestätigen oder Abbrechen | | Keine Schreibrechte / Marker nicht anlegbar | **Fehlerdialog**, Vorgang abgebrochen | **Bereits ein Workspace → öffnen statt melden.** Der Nutzer hat unmissverständlich auf diesen Ordner gezeigt. Ihm zu sagen „das ist bereits ein Workspace" und ihn dann in den Öffnen-Tab zu schicken, ist eine Belehrung mit Extraarbeit. Streicht einen Fehlerfall ersatzlos. **Nicht leer → immer fragen**, auch wenn der Ordner ausschließlich Markdown-Dateien enthält. Klüger wäre, nur bei fehlenden `.md` zu fragen — aber eine Regel, die mal greift und mal nicht, ist schwerer zu durchschauen als eine, die immer gilt, und wirkt unberechenbar, wenn sie danebenliegt. Die Rückfrage trifft jeden Workspace genau einmal in seinem Leben, weil sie nur beim Anlegen auftritt. --- ### Zwei Punkte, die beim Ausformulieren aufgefallen sind **1. Wann wird der Zustand der Einträge geprüft?** Die Markierungen setzen voraus, dass die App den Zustand kennt, bevor der Nutzer klickt — also eine Prüfung pro Eintrag beim Anzeigen der Liste. Bei einem nicht eingehängten Netzlaufwerk kann bereits `path.exists()` in ein Timeout von mehreren Sekunden laufen, und das würde den Selector beim Start blockieren — ausgerechnet den Bildschirm, den jeder Start zuerst zeigt. Die Prüfung gehört deshalb **nebenläufig**, mit den Einträgen zunächst unmarkiert. Wie das in Dioxus 0.7 sauber aussieht (`use_resource` pro Eintrag oder eine gemeinsame Aufgabe), ist beim Bauen zu klären; als Fog auf der Map vermerkt. **2. Der Ordner ohne Marker ist nicht immer ein Fehler.** Er tritt auch auf, wenn der Nutzer beim *Anlegen* einen frischen Ordner wählt — dann ist „kein Marker" der erwartete Ausgangszustand. Die Markierung gilt ausschließlich für Einträge, die *bereits in der Liste stehen*.

RDietermann closed this issue

2026-08-28 06:35:20 +00:00

RDietermann referenced this issue

2026-08-28 06:35:51 +00:00

Workspace: anlegen, wiederfinden, oeffnen #1

RDietermann referenced this issue

2026-08-28 06:45:20 +00:00

Selector-UI: Anlegen und Öffnen #8

RDietermann referenced this issue

2026-08-28 06:46:44 +00:00

Workspace: anlegen, wiederfinden, oeffnen #1

RDietermann referenced this issue from a commit