LibreKAT/Ocideck
LibreKAT/Ocideck
Watch
4
0
Fork
You've already forked Ocideck
 1
Code Issues Pull requests Projects Releases 21 Packages Activity Actions

Keuze-menu-dia met blokken + per-dia sprong naar een andere dia #1162

New issue
Closed
opened 2026-08-03 12:31:27 +00:00 by brenno · 5 comments
brenno commented 2026-08-03 12:31:27 +00:00
Owner
Copy link

Wat willen we bereiken

Een presentatie moet niet-lineair kunnen zijn. Twee samenhangende wensen:

1. Een keuze-menu-dia (nieuw slidetype).
Een dia waarop je blokken neerzet — ingevoerd als bullets in de editor —
waarbij elk blok verwijst naar een andere dia in het deck. In de weergave
worden die blokken als een net raster van keuzeblokken getoond, zodat de dia
werkt als een menu: klik/tik een blok en de presentatie springt naar de
bijbehorende dia. Elk blok kan optioneel een afbeelding dragen (geen plicht;
een blok zonder afbeelding is een gewoon tekstblok).

2. Sprong-uit op elke dia.
Iedere dia moet kunnen aangeven dat de volgende dia een andere is dan de
eerstvolgende in de bronvolgorde — een per-dia "spring hierna naar dia X".
Zonder zo'n sprong geldt gewoon de bestaande lineaire volgorde. Hiermee kun je
vanaf een menu-tak weer terugkeren naar het menu, of een zijpad afsluiten.

Samen leveren deze twee een eenvoudige presentatie-branching op: een menu-dia
biedt keuzes, elke keuze leidt naar een tak, en de tak springt aan het eind
terug.

Wat mist er nu

  • Er is geen in-deck navigatie tussen dia's. hyperlinks op een dia zijn
    uitsluitend externe URL's (slide_factory.dart, importkant); er bestaat geen
    concept "verwijs naar dia N van dit deck".
  • Er is geen slidetype dat blokken/keuzes rendert.
  • De presentator/weergave loopt strikt lineair; er is geen sprong-mechaniek.

Look and feel (cruciaal)

De blokken en het menu moeten kloppen met het actieve deck-thema en écht mooi
ogen: kleuren uit het actieve ColorScheme (surface/onSurface — nooit een eigen
palet hardcoderen), consistent met de bestaande dia-esthetiek, nette
raster-layout, en degelijk gedrag bij 200% tekst en krappe viewports
(overflow-stresspoort). Dit valt of staat met de beeldkeuring — een test
bevestigt de waarden, niet of het mooi is.

Formaat-gevolgen — eerst ontwerpen

Dit raakt het bestandsformaat en verdient een afgetoetst ontwerp vóór de bouw
(zie de werkwijze "formaat eerst ontwerpen"). Open ontwerpvragen die op elkaar
ingrijpen:

  • Hoe verwijs je stabiel naar een andere dia in Markdown? Dia's hebben geen
    vast id in het huidige formaat; posities verschuiven bij invoegen/verwijderen.
    Een index is fragiel. Kandidaat: een stabiel dia-anker/id, óf verwijzen op
    kop/slug. Dit is de kernbeslissing en bepaalt de rest.
  • Waar leeft de sprong-uit? Als dia-eigenschap (frontmatter/HTML-comment),
    round-trippend en leesbaar, zonder base64.
  • Hoe codeert een menublok zijn doel + optionele afbeelding? Sluit aan bij
    de bestaande bullet-/afbeeldingsconventies; een blok is bullet-tekst +
    doelverwijzing + optioneel een mem:/asset-afbeelding.
  • Gedrag bij een kapotte verwijzing (doeldia verwijderd): fail-safe, geen
    crash; zichtbaar in de editor.
  • Round-trip verliesvrij, ook in export (HTML/print) en import.

Wat kost dit (grofweg)

  • Nieuw slidetype = de volledige keten (~18 plekken, skill
    nieuw-slidetype; vergeet _tableBackedTypes/registraties niet).
  • Nieuw dia-navigatiemodel (stabiel dia-id + sprongveld) dat door parser,
    serialiser, editor, preview, presentator en export moet.
  • Presentatiemodus krijgt sprong-mechaniek (menuklik + per-dia sprong-uit),
    inclusief toetsenbord/afstandsbediening en "terug".
  • Zichtbare tekst → l10n.d('…') (31 vertalingen).
  • Docs-keten (USER_GUIDE, SOURCE_MAP, FILE_FORMAT) + overflow-stresspoort-entry
    • goldens/beeldkeuring.
  • Raakt mogelijk de dia-nummering (presentator nummert op bróndia) en de
    slidestrook-navigatie.

Aanpak

Voorstel: eerst een klein formaat-ontwerp (de vier ontwerpvragen hierboven,
gebundeld), aftoetsen, en dan pas bouwen. De sprong-uit (2) en het menu-type (1)
delen hetzelfde navigatie-fundament, dus samen ontwerpen, gefaseerd bouwen —
navigatiemodel eerst, dan het menu-slidetype erop.

## Wat willen we bereiken Een presentatie moet niet-lineair kunnen zijn. Twee samenhangende wensen: **1. Een keuze-menu-dia (nieuw slidetype).** Een dia waarop je *blokken* neerzet — ingevoerd als bullets in de editor — waarbij elk blok verwijst naar een andere dia in het deck. In de weergave worden die blokken als een net raster van keuzeblokken getoond, zodat de dia werkt als een menu: klik/tik een blok en de presentatie springt naar de bijbehorende dia. Elk blok kan *optioneel* een afbeelding dragen (geen plicht; een blok zonder afbeelding is een gewoon tekstblok). **2. Sprong-uit op elke dia.** Iedere dia moet kunnen aangeven dat de volgende dia een *andere* is dan de eerstvolgende in de bronvolgorde — een per-dia "spring hierna naar dia X". Zonder zo'n sprong geldt gewoon de bestaande lineaire volgorde. Hiermee kun je vanaf een menu-tak weer terugkeren naar het menu, of een zijpad afsluiten. Samen leveren deze twee een eenvoudige presentatie-branching op: een menu-dia biedt keuzes, elke keuze leidt naar een tak, en de tak springt aan het eind terug. ## Wat mist er nu - Er is **geen** in-deck navigatie tussen dia's. `hyperlinks` op een dia zijn uitsluitend externe URL's (`slide_factory.dart`, importkant); er bestaat geen concept "verwijs naar dia N van dit deck". - Er is geen slidetype dat blokken/keuzes rendert. - De presentator/weergave loopt strikt lineair; er is geen sprong-mechaniek. ## Look and feel (cruciaal) De blokken en het menu moeten kloppen met het actieve deck-thema en écht mooi ogen: kleuren uit het actieve ColorScheme (surface/onSurface — nooit een eigen palet hardcoderen), consistent met de bestaande dia-esthetiek, nette raster-layout, en degelijk gedrag bij 200% tekst en krappe viewports (overflow-stresspoort). Dit valt of staat met de beeldkeuring — een test bevestigt de waarden, niet of het mooi is. ## Formaat-gevolgen — eerst ontwerpen Dit raakt het bestandsformaat en verdient een afgetoetst ontwerp vóór de bouw (zie de werkwijze "formaat eerst ontwerpen"). Open ontwerpvragen die op elkaar ingrijpen: - **Hoe verwijs je stabiel naar een andere dia in Markdown?** Dia's hebben geen vast id in het huidige formaat; posities verschuiven bij invoegen/verwijderen. Een index is fragiel. Kandidaat: een stabiel dia-anker/id, óf verwijzen op kop/slug. Dit is de kernbeslissing en bepaalt de rest. - **Waar leeft de sprong-uit?** Als dia-eigenschap (frontmatter/HTML-comment), round-trippend en leesbaar, zonder base64. - **Hoe codeert een menublok zijn doel + optionele afbeelding?** Sluit aan bij de bestaande bullet-/afbeeldingsconventies; een blok is bullet-tekst + doelverwijzing + optioneel een `mem:`/asset-afbeelding. - Gedrag bij een **kapotte verwijzing** (doeldia verwijderd): fail-safe, geen crash; zichtbaar in de editor. - Round-trip verliesvrij, ook in export (HTML/print) en import. ## Wat kost dit (grofweg) - **Nieuw slidetype** = de volledige keten (~18 plekken, skill `nieuw-slidetype`; vergeet `_tableBackedTypes`/registraties niet). - **Nieuw dia-navigatiemodel** (stabiel dia-id + sprongveld) dat door parser, serialiser, editor, preview, presentator en export moet. - **Presentatiemodus** krijgt sprong-mechaniek (menuklik + per-dia sprong-uit), inclusief toetsenbord/afstandsbediening en "terug". - Zichtbare tekst → `l10n.d('…')` (31 vertalingen). - Docs-keten (USER_GUIDE, SOURCE_MAP, FILE_FORMAT) + overflow-stresspoort-entry + goldens/beeldkeuring. - Raakt mogelijk de dia-nummering (presentator nummert op bróndia) en de slidestrook-navigatie. ## Aanpak Voorstel: eerst een klein formaat-ontwerp (de vier ontwerpvragen hierboven, gebundeld), aftoetsen, en dan pas bouwen. De sprong-uit (2) en het menu-type (1) delen hetzelfde navigatie-fundament, dus samen ontwerpen, gefaseerd bouwen — navigatiemodel eerst, dan het menu-slidetype erop.
brenno commented 2026-08-03 22:52:06 +00:00
Author
Owner
Copy link

Formaatontwerp — niet-lineaire navigatie

Aftoetsbaar formaatontwerp voor de vier ontwerpvragen. Uitgangspunt: één ankersysteem draagt beide features. Een dia die een doel is (van een menublok óf van een sprong-uit) krijgt een stabiel anker; verwijzen gebeurt naar dat anker. Alles is leesbare Markdown; een gewone Markdown-lezer ziet een bulletlijst met links en negeert de <!-- ocideck_* -->-comments. Geen base64, degradeert netjes.

Vraag 1 — Hoe verwijs je stabiel naar een andere dia? (de kernbeslissing)

Voorstel: een expliciet opgeslagen, mens-leesbaar anker per dia — géén uuid, géén index.

<!-- ocideck_slide_anchor: prijzen -->
# Prijzen
  • Geseed uit de kop-slug bij eerste toekenning (# Prijzen → prijzen), maar daarna bevroren en expliciet opgeslagen. Hernoem je de kop naar "Tarieven", dan blijft het anker prijzen — de link breekt niet.
  • Lui toegekend: alleen een dia die daadwerkelijk doel is, krijgt een anker. Een deck dat nooit vertakt blijft schoon.
  • Uniek binnen het deck. Botsing bij seeden → prijzen-2. Botsing door handmatig bewerken → parser houdt de eerste aan, markeert de rest als kapot doel (zichtbaar in de editor, geen crash).
  • Verwijzen met een #-fragment, zoals een HTML-ankerlink: [Prijzen](#prijzen). Werkt letterlijk als echt anker in de HTML-export.

Afgewezen: index (schuift, fragiel — precies wat het issue vreest); kale uuid (robuust maar onleesbaar in de ruwe .md, botst met de mens-leesbare lijn — finding_id is bewust óók genummerd, niet uuid); kop/slug live afleiden (breekt bij hernoemen of dubbele koppen — het bevriezen lost precies dat op).

De gebruiker ziet dit anker nooit rechtstreeks: in de editor kiest die een doeldia uit een lijst-op-titel/miniatuur, de app schrijft het anker.

Vraag 2 — Waar leeft de sprong-uit?

Voorstel: een dia-eigenschap als HTML-comment op de brondia.

<!-- ocideck_slide_anchor: prijzen -->
<!-- ocideck_next: hoofdmenu -->
# Prijzen
  • ocideck_next verwijst naar het anker van de doeldia. Afwezig = de bestaande lineaire volgorde — geen gedragswijziging voor bestaande decks, nul migratie.
  • Nieuw modelveld Slide.nextAnchor (leeg = lineair), round-trippend, leesbaar. Volgt exact het patroon van ocideck_checklist_scope / ocideck_finding_id, staat bij de andere per-dia directives.
  • Bewust géén frontmatter: frontmatter is deck-breed; dit is per-dia, en per-dia-staat leeft consequent in <!-- ocideck_* -->.

Vraag 3 — Hoe codeert een menublok zijn doel + optionele afbeelding?

Voorstel: de bullets ván de menu-dia zíjn de blokken; elk blok is een Markdown-link, met de afbeelding via de bestaande mem:-conventie.

<!-- _class: menu -->
<!-- ocideck_slide_anchor: hoofdmenu -->

# Kies een onderwerp

- [Prijzen](#prijzen)
- [Demo](#demo) ![](mem:9f2a1c)
- [Contact](#contact)
  • Doel = de #anker-fragmentlink. De parser onderscheidt #… (in-deck sprong) van http(s)://… (bestaande externe hyperlink) — één check, geen nieuw mechanisme.
  • Tekst = de linktekst, los van de kop van de doeldia (een menu-label mag afwijken van de dia-titel).
  • Afbeelding = optioneel via ![](mem:…) of asset-pad, exact de conventie die bulletsImage/twoImages al gebruiken. Geen afbeelding = gewoon tekstblok.
  • Nieuw _class: menu-token voor het slidetype.
  • Degradeert netjes: een externe Markdown-lezer toont een bullet-lijst met links; in de HTML-export worden het echte anker-sprongen.

Afgewezen: doelen in een parallelle comment (<!-- ocideck_menu_targets: … -->) naast kale bullets — dat splitst tekst en doel over twee plekken die uit de pas kunnen lopen (dezelfde stille val als het ooit vergeten _tableBackedTypes). De inline-link houdt tekst + doel + beeld op één regel bij elkaar.

Vraag 4 — Kapotte verwijzing + verliesvrije round-trip

  • Kapot doel (anker verwijderd): fail-safe. In de presentatie rendert het menublok normaal maar doet niets bij klik; een sprong-uit naar een verdwenen anker valt terug op lineair. In de editor is het blok zichtbaar gemarkeerd als "doel bestaat niet meer". Nooit een crash — dit krijgt een expliciete regressietest.
  • Anker overleeft round-trip ook als een dia tijdelijk geen doel meer is; een tijdelijk verbroken link heelt zodra de dia terugkomt. Wees-ankers alleen opschonen bij expliciete gebruikersactie, niet stil.
  • Import (PPTX/ODP/KEY): die formaten kennen interne dia-links; die mappen we naar ocideck_next/menu-ankers wanneer aanwezig, anders lineair. Geen verlies t.o.v. nu.
  • Export (HTML): ankers worden echte id=-attributen op de dia-secties, links worden fragment-links — branching werkt in de geëxporteerde HTML. Print/PDF: links zijn inert (statisch medium), inhoud blijft volledig.

Modeluitbreiding (minimaal)

Veld Betekenis Round-trip
Slide.anchor stabiel anker (leeg = geen doel) <!-- ocideck_slide_anchor: … -->
Slide.nextAnchor sprong-uit (leeg = lineair) <!-- ocideck_next: … -->
menublokken hergebruikt bullets + hyperlinks (nu ook #-fragment) + afbeelding-per-bullet inline - [tekst](#anker) ![](mem:…)

De enige echte modeluitbreiding buiten de twee ankervelden is een afbeelding per bullet (die bullets nu niet dragen). De rest leunt op bestaande velden.

Bewust weggelaten

  • Geen zichtbare dia-id's of handmatig ankerbeheer — de gebruiker kiest doelen visueel, ankers zijn machinerie.
  • Geen voorwaardelijke sprongen / variabelen ("als X dan dia Y"). Eén doel per blok, één sprong-uit per dia — het blijft een menu, geen scripttaal.
  • Geen automatisch opgeschoonde wees-ankers en geen graaf-validatie in het formaat zelf. Onbereikbare-dia-detectie is een editor-hulp (UX), geen formaatregel; het formaat blijft een lijst dia's die toevallig naar elkaar kunnen wijzen.

Openstaand om te bevestigen

De grootste keuze is Vraag 1 (bevroren mens-leesbaar anker vs. kale uuid) — daar hangt de rest aan. Zodra dat vaststaat kan gefaseerd gebouwd worden: navigatiefundament (anker + nextAnchor) → sprong-uit → menu-slidetype.

## Formaatontwerp — niet-lineaire navigatie Aftoetsbaar formaatontwerp voor de vier ontwerpvragen. Uitgangspunt: **één ankersysteem draagt beide features.** Een dia die een doel is (van een menublok óf van een sprong-uit) krijgt een stabiel anker; verwijzen gebeurt naar dat anker. Alles is leesbare Markdown; een gewone Markdown-lezer ziet een bulletlijst met links en negeert de `<!-- ocideck_* -->`-comments. Geen base64, degradeert netjes. ### Vraag 1 — Hoe verwijs je stabiel naar een andere dia? (de kernbeslissing) **Voorstel: een expliciet opgeslagen, mens-leesbaar anker per dia — géén uuid, géén index.** ```markdown <!-- ocideck_slide_anchor: prijzen --> # Prijzen ``` - **Geseed uit de kop-slug** bij eerste toekenning (`# Prijzen` → `prijzen`), maar daarna **bevroren en expliciet opgeslagen**. Hernoem je de kop naar "Tarieven", dan blijft het anker `prijzen` — de link breekt niet. - **Lui toegekend:** alleen een dia die daadwerkelijk doel is, krijgt een anker. Een deck dat nooit vertakt blijft schoon. - **Uniek binnen het deck.** Botsing bij seeden → `prijzen-2`. Botsing door handmatig bewerken → parser houdt de eerste aan, markeert de rest als kapot doel (zichtbaar in de editor, geen crash). - **Verwijzen met een `#`-fragment**, zoals een HTML-ankerlink: `[Prijzen](#prijzen)`. Werkt letterlijk als echt anker in de HTML-export. **Afgewezen:** *index* (schuift, fragiel — precies wat het issue vreest); *kale uuid* (robuust maar onleesbaar in de ruwe `.md`, botst met de mens-leesbare lijn — `finding_id` is bewust óók genummerd, niet uuid); *kop/slug live afleiden* (breekt bij hernoemen of dubbele koppen — het bevriezen lost precies dat op). De gebruiker ziet dit anker nooit rechtstreeks: in de editor kiest die een doeldia uit een lijst-op-titel/miniatuur, de app schrijft het anker. ### Vraag 2 — Waar leeft de sprong-uit? **Voorstel: een dia-eigenschap als HTML-comment op de brondia.** ```markdown <!-- ocideck_slide_anchor: prijzen --> <!-- ocideck_next: hoofdmenu --> # Prijzen ``` - `ocideck_next` verwijst naar het anker van de doeldia. **Afwezig = de bestaande lineaire volgorde** — geen gedragswijziging voor bestaande decks, nul migratie. - Nieuw modelveld `Slide.nextAnchor` (leeg = lineair), round-trippend, leesbaar. Volgt exact het patroon van `ocideck_checklist_scope` / `ocideck_finding_id`, staat bij de andere per-dia directives. - Bewust géén frontmatter: frontmatter is deck-breed; dit is per-dia, en per-dia-staat leeft consequent in `<!-- ocideck_* -->`. ### Vraag 3 — Hoe codeert een menublok zijn doel + optionele afbeelding? **Voorstel: de bullets ván de menu-dia zíjn de blokken; elk blok is een Markdown-link, met de afbeelding via de bestaande `mem:`-conventie.** ```markdown <!-- _class: menu --> <!-- ocideck_slide_anchor: hoofdmenu --> # Kies een onderwerp - [Prijzen](#prijzen) - [Demo](#demo) ![](mem:9f2a1c) - [Contact](#contact) ``` - **Doel = de `#anker`-fragmentlink.** De parser onderscheidt `#…` (in-deck sprong) van `http(s)://…` (bestaande externe hyperlink) — één check, geen nieuw mechanisme. - **Tekst = de linktekst**, los van de kop van de doeldia (een menu-label mag afwijken van de dia-titel). - **Afbeelding = optioneel** via `![](mem:…)` of asset-pad, exact de conventie die `bulletsImage`/`twoImages` al gebruiken. Geen afbeelding = gewoon tekstblok. - **Nieuw `_class: menu`-token** voor het slidetype. - Degradeert netjes: een externe Markdown-lezer toont een bullet-lijst met links; in de HTML-export worden het echte anker-sprongen. **Afgewezen:** doelen in een parallelle comment (`<!-- ocideck_menu_targets: … -->`) naast kale bullets — dat splitst tekst en doel over twee plekken die uit de pas kunnen lopen (dezelfde stille val als het ooit vergeten `_tableBackedTypes`). De inline-link houdt tekst + doel + beeld op één regel bij elkaar. ### Vraag 4 — Kapotte verwijzing + verliesvrije round-trip - **Kapot doel (anker verwijderd):** fail-safe. In de presentatie rendert het menublok normaal maar doet niets bij klik; een sprong-uit naar een verdwenen anker valt terug op lineair. In de editor is het blok zichtbaar gemarkeerd als "doel bestaat niet meer". Nooit een crash — dit krijgt een expliciete regressietest. - **Anker overleeft round-trip** ook als een dia tijdelijk geen doel meer is; een tijdelijk verbroken link heelt zodra de dia terugkomt. Wees-ankers alleen opschonen bij expliciete gebruikersactie, niet stil. - **Import (PPTX/ODP/KEY):** die formaten kennen interne dia-links; die mappen we naar `ocideck_next`/menu-ankers wanneer aanwezig, anders lineair. Geen verlies t.o.v. nu. - **Export (HTML):** ankers worden echte `id=`-attributen op de dia-secties, links worden fragment-links — branching werkt in de geëxporteerde HTML. **Print/PDF:** links zijn inert (statisch medium), inhoud blijft volledig. ### Modeluitbreiding (minimaal) | Veld | Betekenis | Round-trip | |------|-----------|-----------| | `Slide.anchor` | stabiel anker (leeg = geen doel) | `<!-- ocideck_slide_anchor: … -->` | | `Slide.nextAnchor` | sprong-uit (leeg = lineair) | `<!-- ocideck_next: … -->` | | menublokken | hergebruikt `bullets` + `hyperlinks` (nu ook `#`-fragment) + afbeelding-per-bullet | inline `- [tekst](#anker) ![](mem:…)` | De enige echte modeluitbreiding buiten de twee ankervelden is **een afbeelding per bullet** (die bullets nu niet dragen). De rest leunt op bestaande velden. ### Bewust weggelaten - **Geen zichtbare dia-id's of handmatig ankerbeheer** — de gebruiker kiest doelen visueel, ankers zijn machinerie. - **Geen voorwaardelijke sprongen / variabelen** ("als X dan dia Y"). Eén doel per blok, één sprong-uit per dia — het blijft een menu, geen scripttaal. - **Geen automatisch opgeschoonde wees-ankers en geen graaf-validatie in het formaat zelf.** Onbereikbare-dia-detectie is een editor-hulp (UX), geen formaatregel; het formaat blijft een lijst dia's die toevallig naar elkaar kunnen wijzen. ### Openstaand om te bevestigen De grootste keuze is **Vraag 1** (bevroren mens-leesbaar anker vs. kale uuid) — daar hangt de rest aan. Zodra dat vaststaat kan gefaseerd gebouwd worden: navigatiefundament (anker + `nextAnchor`) → sprong-uit → menu-slidetype.
brenno commented 2026-08-03 22:54:58 +00:00
Author
Owner
Copy link

Ik pak dit op — het formaatontwerp hierboven staat vast (bevroren mens-leesbaar anker). Gefaseerd bouwen op branch feat/1162-nietlineaire-navigatie: Fase 1 = navigatiefundament (Slide.anchor + Slide.nextAnchor, verliesvrije round-trip + migratie), daarna sprong-uit in de presentator, daarna het menu-slidetype.

Ik pak dit op — het formaatontwerp hierboven staat vast (bevroren mens-leesbaar anker). Gefaseerd bouwen op branch `feat/1162-nietlineaire-navigatie`: Fase 1 = navigatiefundament (`Slide.anchor` + `Slide.nextAnchor`, verliesvrije round-trip + migratie), daarna sprong-uit in de presentator, daarna het menu-slidetype.
brenno commented 2026-08-03 23:42:50 +00:00
Author
Owner
Copy link

PR voor fase 1+2 (de sprong-uit) staat klaar: #1189

Bevat het navigatiefundament (stabiel bevroren dia-anker + nextAnchor, verliesvrije round-trip), de sprong-uit werkend in de presentator met een navigatiestack als "terug", en de editor-UI ("Hierna"-keuzelijst per dia). make check volledig groen, secrets/SAST schoon, docs + l10n (31 talen) bij.

Issue blijft open: feature 1, het keuze-menu-diatype, volgt als aparte PR op dit fundament (nieuw SlideType + blokkenraster + klik-om-te-springen + beeldkeuring — dat laatste is het visuele "valt of staat"-oppervlak uit dit issue).

PR voor **fase 1+2 (de sprong-uit)** staat klaar: https://pawprint.vigilis.online/LibreKAT/Ocideck/pulls/1189 Bevat het navigatiefundament (stabiel bevroren dia-anker + `nextAnchor`, verliesvrije round-trip), de sprong-uit werkend in de presentator met een navigatiestack als "terug", en de editor-UI ("Hierna"-keuzelijst per dia). `make check` volledig groen, secrets/SAST schoon, docs + l10n (31 talen) bij. Issue blijft **open**: **feature 1, het keuze-menu-diatype**, volgt als aparte PR op dit fundament (nieuw SlideType + blokkenraster + klik-om-te-springen + beeldkeuring — dat laatste is het visuele "valt of staat"-oppervlak uit dit issue).
brenno commented 2026-08-04 01:35:10 +00:00
Author
Owner
Copy link

Fase 3 — het keuze-menu-diatype staat nu ook klaar: #1192 (gestapeld op #1189, landt daarna).

Daarmee is de volledige issue-scope geïmplementeerd:

  • #1189 — het navigatiefundament + de sprong-uit ("Hierna").
  • #1192 — het keuze-menudiatype: blokken die naar een dia springen, als raster in de themakleuren; klik/tik springt, "terug" keert terug naar het menu.

Beide: make check volledig groen, secrets/SAST schoon, docs + l10n (31 talen) bij, en de beeldkeuring gedaan (één overflow-bevinding op een afbeeldingsblok opgelost mét regressietest). Formaat blijft leesbare Markdown — een menu is in het .md gewoon een lijst van links.

Eén niet-blokkerende opvolging apart geflagd: het menu-raster in de HTML-export stylen (nu vermoedelijk een linklijst i.p.v. kaarten; de PDF is wél WYSIWYG). Zodra beide PR's gemerged zijn kan dit issue dicht.

**Fase 3 — het keuze-menu-diatype** staat nu ook klaar: https://pawprint.vigilis.online/LibreKAT/Ocideck/pulls/1192 (gestapeld op #1189, landt daarna). Daarmee is de volledige issue-scope geïmplementeerd: - **#1189** — het navigatiefundament + de sprong-uit ("Hierna"). - **#1192** — het keuze-menudiatype: blokken die naar een dia springen, als raster in de themakleuren; klik/tik springt, "terug" keert terug naar het menu. Beide: `make check` volledig groen, secrets/SAST schoon, docs + l10n (31 talen) bij, en de beeldkeuring gedaan (één overflow-bevinding op een afbeeldingsblok opgelost mét regressietest). Formaat blijft leesbare Markdown — een menu is in het `.md` gewoon een lijst van links. Eén niet-blokkerende opvolging apart geflagd: het menu-raster in de **HTML-export** stylen (nu vermoedelijk een linklijst i.p.v. kaarten; de PDF is wél WYSIWYG). Zodra beide PR's gemerged zijn kan dit issue dicht.
brenno commented 2026-08-04 07:00:46 +00:00
Author
Owner
Copy link

Beide PR's gemerged in main: #1189 (sprong-uit, merge bb7b7d03) en #1192 (keuze-menudiatype, merge 9148b2d9). CI-poort (static-gate + scans) groen op beide, branches opgeruimd. De volledige issue-scope — sprong-uit én keuze-menu met branching — staat op main.

Sluit dit issue. De enige resterende, niet-blokkerende verfraaiing (menu-raster in de HTML-export i.p.v. een linklijst) loopt apart als losse taak.

Beide PR's gemerged in main: **#1189** (sprong-uit, merge `bb7b7d03`) en **#1192** (keuze-menudiatype, merge `9148b2d9`). CI-poort (static-gate + scans) groen op beide, branches opgeruimd. De volledige issue-scope — sprong-uit én keuze-menu met branching — staat op main. Sluit dit issue. De enige resterende, niet-blokkerende verfraaiing (menu-raster in de HTML-export i.p.v. een linklijst) loopt apart als losse taak.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
v0.5.0
v0.4.10
v0.4.9
v0.4.8
v0.4.7
v0.4.6
v0.4.5
v0.4.4
v0.4.3
v0.4.2
v0.4.1
v0.4.0
v0.3.6
v0.3.5
v0.3.4
v0.3.3
v0.3.2
v0.3.1
v0.3.0
v0.2.0
v0.1.3
v0.1.2
v0.1.1
v0.1.0
archive/git-mirror
Labels
Clear labels   
accepted
Assessed and will be built

  
bug
Something is broken

  
declined
Assessed and will not be built

  
docs
Documentation only

  
duplicate
Already tracked elsewhere

  
enhancement
New feature or improvement request

  
good first issue
Small, self-contained, and a good place to start

  
in-progress
Someone is working on this right now. Do not start it in parallel.

  
needs-info
Waiting for the reporter

  
privacy
Personal data can leak. Handled before anything else.

  
security
A weakness someone could use. Handled before anything else.

  
triage
Awaiting assessment

No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
security
triage
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
LibreKAT/Ocideck#1162
No description provided.