Keep builder and presentation window slide navigation in sync #2024
Labels
No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
security
triage
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
LibreKAT/Ocideck#2024
Loading…
Reference in a new issue
No description provided.
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?
Problem\n\nWhen presenting with two screens, slide navigation does not stay synchronized between the builder and the presentation window. Advancing in the builder leaves the presentation monitor on the previous slide. Advancing with mouse or keyboard in the presentation window produces no visible change.\n\n## Expected behaviour\n\nBoth windows show the same active slide regardless of which window initiates navigation. Mouse and keyboard navigation in the presentation window must immediately update the projected slide and the builder state.\n\n## Scope\n\nFind and repair the shared navigation/state propagation path and add a regression test covering navigation initiated from both windows. This must not change the Markdown file format.
Opgepakt. Tak: codex/fix-presenter-slide-sync. Verwachte reikwijdte: presentatie-/presenter-state en bijbehorende widget- of provider-tests; geen wijziging aan het Markdown-formaat.
Opgelost en op main geverifieerd in mergecommit
93137929f. De presentatiemonitor meldt nu wanneer het kanaal gereed is, tijdelijke opstartfouten worden opnieuw geprobeerd en de bouwer stuurt daarna altijd de nieuwste volledige slide-status. Invoer vanuit het presentatiescherm wordt tot die gereedmelding bewaard. Toegevoegd: regressietests voor synchronisatie in beide richtingen, opstartvertragingen en permanente kanaalfouten. Geen wijziging aan Markdown-formaat, afhankelijkheden of native bridge. De exacte tweeschermenopstelling kon niet opnieuw fysiek worden uitgevoerd omdat op de testmachine één scherm beschikbaar was; de macOS-app startte wel echt en de tweerichtingssynchronisatie is deterministisch getest.