[Windows][P1] Geen enkel-exemplaarbewaking: een tweede start deelt herstelmap en instellingen met de eerste #2627

New issue

Closed

opened 2026-10-28 16:31:40 +00:00 by brenno · 0 comments

brenno commented

2026-10-28 16:31:40 +00:00

Owner

Symptoom

Op Windows (en Linux) start elke dubbelklik op een .ocideck/.md, en elke tweede klik op de snelkoppeling, een nieuw OciDeck-proces — ook als OciDeck al draait, of nog bezig is met opstarten of afsluiten. Gebruikers die denken dat de app "niet opstart" en nog eens klikken, krijgen meerdere processen die dezelfde bestanden delen.

Oorzaak

windows/runner/main.cpp maakt altijd een nieuw venster; er is geen mutex en geen doorgifte aan een draaiend exemplaar. De bestandsassociatie geeft het pad als argument (lib/main.dart:42-48, pendingLaunchFiles). macOS heeft dit probleem niet (LaunchServices activeert het bestaande proces en levert het bestand via het ocideck/open_file-kanaal).

Gevolgen van twee exemplaren:

Herstel: het tweede exemplaar toont bij de start de herstelvraag voor de levende autosave-bestanden van het eerste (_maybeRestore, lib/widgets/app_shell.dart:341 → RecoveryService.loadAll, lib/services/recovery_service.dart:301). Kiest de gebruiker daar "Herstelkopie weggooien", dan verdwijnt de crashbescherming van het werk in het éérste venster; kiest hij "Openen", dan staat hetzelfde werk dubbel open.
Instellingen: beide schrijven hetzelfde shared_preferences.json (#2628).
Staging: beide ruimen de stagingmap op met dezelfde regels.

Voorgestelde oplossing

Windows: in wWinMain een benoemde mutex (Local\OciDeck-…). Bestaat die al: zoek het hoofdvenster (eigen vensterklasse), stuur de argumenten via WM_COPYDATA, roep AllowSetForegroundWindow/SetForegroundWindow aan en sluit af. Het draaiende exemplaar zet ze door naar het bestaande open-bestandkanaal (OpenFileChannel), dat macOS al gebruikt.
Linux: hetzelfde via een Unix-socket in $XDG_RUNTIME_DIR (of D-Bus); mag een vervolgissue zijn.
Herstel per exemplaar: een lockbestand per sessie met PID; loadAll slaat momentopnames over waarvan de eigenaar nog leeft. Dat beschermt ook tegen een tweede exemplaar dat er tóch komt (bv. een andere gebruiker of een portable kopie).

Wat overeind moet blijven

Bewust meerdere vensters binnen één proces (presentator + beamer via desktop_multi_window) blijven werken; het beamervenster start met multi_window als eerste argument en moet door de mutex heen.

Toets

Op de Windows-spiegel: start ocideck.exe a.md terwijl een exemplaar draait → er blijft één proces, en a.md staat als tabblad open in het eerste.

Onderdeel van de prestatie- en stabiliteitsinspectie van 28-10-2026 (EPIC #2637).

## Symptoom Op Windows (en Linux) start elke dubbelklik op een `.ocideck`/`.md`, en elke tweede klik op de snelkoppeling, een **nieuw OciDeck-proces** — ook als OciDeck al draait, of nog bezig is met opstarten of afsluiten. Gebruikers die denken dat de app "niet opstart" en nog eens klikken, krijgen meerdere processen die dezelfde bestanden delen. ## Oorzaak `windows/runner/main.cpp` maakt altijd een nieuw venster; er is geen mutex en geen doorgifte aan een draaiend exemplaar. De bestandsassociatie geeft het pad als argument (`lib/main.dart:42-48`, `pendingLaunchFiles`). macOS heeft dit probleem niet (LaunchServices activeert het bestaande proces en levert het bestand via het `ocideck/open_file`-kanaal). Gevolgen van twee exemplaren: - **Herstel**: het tweede exemplaar toont bij de start de herstelvraag voor de levende autosave-bestanden van het eerste (`_maybeRestore`, `lib/widgets/app_shell.dart:341` → `RecoveryService.loadAll`, `lib/services/recovery_service.dart:301`). Kiest de gebruiker daar "Herstelkopie weggooien", dan verdwijnt de crashbescherming van het werk in het éérste venster; kiest hij "Openen", dan staat hetzelfde werk dubbel open. - **Instellingen**: beide schrijven hetzelfde `shared_preferences.json` (#2628). - **Staging**: beide ruimen de stagingmap op met dezelfde regels. ## Voorgestelde oplossing 1. **Windows**: in `wWinMain` een benoemde mutex (`Local\OciDeck-…`). Bestaat die al: zoek het hoofdvenster (eigen vensterklasse), stuur de argumenten via `WM_COPYDATA`, roep `AllowSetForegroundWindow`/`SetForegroundWindow` aan en sluit af. Het draaiende exemplaar zet ze door naar het bestaande open-bestandkanaal (`OpenFileChannel`), dat macOS al gebruikt. 2. **Linux**: hetzelfde via een Unix-socket in `$XDG_RUNTIME_DIR` (of D-Bus); mag een vervolgissue zijn. 3. **Herstel per exemplaar**: een lockbestand per sessie met PID; `loadAll` slaat momentopnames over waarvan de eigenaar nog leeft. Dat beschermt ook tegen een tweede exemplaar dat er tóch komt (bv. een andere gebruiker of een portable kopie). ## Wat overeind moet blijven Bewust meerdere vensters binnen één proces (presentator + beamer via `desktop_multi_window`) blijven werken; het beamervenster start met `multi_window` als eerste argument en moet door de mutex heen. ## Toets Op de Windows-spiegel: start `ocideck.exe a.md` terwijl een exemplaar draait → er blijft één proces, en `a.md` staat als tabblad open in het eerste. Onderdeel van de prestatie- en stabiliteitsinspectie van 28-10-2026 (EPIC #2637).

brenno added the

bug

label

2026-10-28 16:31:40 +00:00

brenno referenced this issue

2026-10-28 16:32:34 +00:00

[EPIC] Prestatie- en stabiliteitsinspectie 28-10-2026: traag bij groot, start niet, loopt vast #2637

brenno referenced this issue

2026-10-28 16:33:01 +00:00

[Opstart][P1] Vóór het eerste frame — en dus vóór het venster op Windows — draait onbegrensd synchroon werk #2626

brenno referenced this issue

2026-10-28 16:33:02 +00:00