fix(ui): het logo was in donkere modus een groot wit vlak (#735) #742

Merged

brenno merged 4 commits from fix/logo-donkere-modus-735 into main 2026-07-23 12:57:18 +00:00

Conversation 0 Commits 4 Files changed 13 +317 -7

brenno commented 2026-07-23 12:57:06 +00:00

Owner

Copy link

Closes #735

In donkere modus stond het logo als een groot wit vlak op het openscherm.

De oorzaak

Niet de weergave, maar de asset. ocideck-logo.png is volledig ondoorzichtig:
alle vier de hoeken #FFFFFF bij alfa 255, bijna negentig procent van het beeld
zuiver wit. Het is een logo met een witte plaat eromheen ingebakken. Op een licht
oppervlak valt die plaat weg; op het donkere openscherm (#1E293B) was hij op
200 px het enige wat je zag.

Een tint kan dat niet repareren, want de plaat en de tekening zijn dezelfde
pixels.

Wat er is gebeurd

Drie donkere varianten. ocideck-logo-dark.png, librekat-logo-dark.png en
vigilis-logo-dark.png: dezelfde tekening, echt transparante achtergrond, inkt
op de donkere waarde van AppTheme.ink (#E8ECF3). Afgeleid uit de bestaande
assets, zodat de lijnvoering identiek blijft. Voor ocideck-logo.png is de alfa
teruggerekend uit de compositie over wit — genormaliseerd op het inktplateau
(luminantie 44, waar de lijnen liggen) en niet op de donkerste pixel, want dat
laatste maakte het hele logo een tint te bleek.

De alfa blijft de dekkingsgraad van de tekening. Dat is wat ze op elk
oppervlak laat landen, niet alleen op het ene ingebouwde donkere profiel — een
zelfgemaakt profiel kiest zijn eigen achtergrond.

BrandLogo (lib/theme/brand_logo.dart) koppelt elk paar en kiest op
AppTheme.isDark. De vier aanroepplekken (openscherm, toestemmingsdialoog,
"Over OciDeck", licentiepagina) vragen nu BrandLogo.<merk>.assetKey.

ocideck-logo-eu.png krijgt geen ingang: die zit alleen op de EU-blauwe zijbalk
en de navy banner — oppervlakken die in beide modi donker zijn — en zijn
EU-gele inkt leest daar al.

De kaarten in "Over OciDeck" stonden hardgecodeerd op Colors.white in
plaats van AppTheme.paper. Dat hield het hele paneel licht in donkere modus, en
verborg tegelijk dat het LibreKAT- en Vigilis-merk erop donkere inkt waren: de
kaart repareren zonder de logo's zou ze hebben laten verdwijnen. Vandaar in één
beweging.

Het LibreKAT-logo in het themaprofiel (models/settings.dart) blijft
uitdrukkelijk de lichte variant. Dat logo staat op een dia, een dia is een vast
wit canvas in beide modi, en het reist mee in de export.

De regressietest

Een widgettest had dit nooit gevangen — elke aanroepplek deed precies wat er
stond. De toets kijkt daarom eerst in de bestanden: transparante hoeken, lichte
inkt, gelijke afmetingen per paar, en alle zes registreerbaar via rootBundle.
Daarnaast een bronregel dat geen aanroepplek in lib/ zelf een merkpad kiest,
want de vijfde die iemand toevoegt krijgt geen compilerfout maar een wit vlak.

Alle vier de controles zijn rood gezien tegen de onherstelde toestand:

Mutatie	Wat rood werd
donkere variant → de ondoorzichtige plaat	transparante hoeken + lichte inkt
aanroepplek kiest zelf het pad	de bronregel
kaart terug op Colors.white	de kaarttest

Met eigen ogen

flutter run -d macos in donkere modus, alle vier de plekken nagelopen:
openscherm, uitgeverskaart, "Mogelijk gemaakt door", licentiepagina. Lichte modus
is aantoonbaar ongewijzigd — AppTheme.paper ís Colors.white als isDark
onwaar is, en assetKey geeft dan hetzelfde bestand als voorheen.

Poorten

• make check groen, make check-full groen.
• make check-secrets: 0 (gitleaks + trufflehog, werkboom én historie).
• make sast: 0 bevindingen (3 regels over 687 bestanden).
• DAST niet gedraaid. ZAP is advisory en aan geen enkel doel gekoppeld; deze
  wijziging raakt geen geserveerd oppervlak.
• Geen nieuwe afhankelijkheid, dus geen SBOM-gevolg. Geen nieuwe l10n.d('…'),
  dus geen 31 vertalingen — de bestaande Semantics-labels blijven staan.

Eén afweging om te noemen

vigilis-logo-dark.png is een hertinting van andermans merk: het zwarte
woordmerk wordt licht, het gele beeldmerk blijft ongemoeid. Dat is de
gebruikelijke knockout-variant voor een donkere ondergrond en verandert niets aan
de vorm of de herkenbaarheid — maar het is wél een sponsormerk, en als Vigilis
huisstijlregels heeft, is dit het moment om dat na te lopen. Ik heb het gedaan
omdat het alternatief was dat hun naam in donkere modus onleesbaar op de kaart
stond; dat leek me slechter dan een nette knockout.

Verder raakt deze wijziging niets uit het bewaker-rijtje: geen bestandsformaat,
geen opslag, geen afhankelijkheid, geen uitgaand verkeer, geen publieke belofte.

Closes #735 In donkere modus stond het logo als een groot wit vlak op het openscherm. ## De oorzaak Niet de weergave, maar de asset. `ocideck-logo.png` is volledig ondoorzichtig: alle vier de hoeken `#FFFFFF` bij alfa 255, bijna negentig procent van het beeld zuiver wit. Het is een logo met een witte plaat eromheen ingebakken. Op een licht oppervlak valt die plaat weg; op het donkere openscherm (`#1E293B`) was hij op 200 px het enige wat je zag. Een tint kan dat niet repareren, want de plaat en de tekening zijn dezelfde pixels. ## Wat er is gebeurd **Drie donkere varianten.** `ocideck-logo-dark.png`, `librekat-logo-dark.png` en `vigilis-logo-dark.png`: dezelfde tekening, echt transparante achtergrond, inkt op de donkere waarde van `AppTheme.ink` (`#E8ECF3`). Afgeleid uit de bestaande assets, zodat de lijnvoering identiek blijft. Voor `ocideck-logo.png` is de alfa teruggerekend uit de compositie over wit — genormaliseerd op het inktplateau (luminantie 44, waar de lijnen liggen) en niet op de donkerste pixel, want dat laatste maakte het hele logo een tint te bleek. De alfa blijft de dekkingsgraad van de tekening. Dat is wat ze op *elk* oppervlak laat landen, niet alleen op het ene ingebouwde donkere profiel — een zelfgemaakt profiel kiest zijn eigen achtergrond. **`BrandLogo` (`lib/theme/brand_logo.dart`)** koppelt elk paar en kiest op `AppTheme.isDark`. De vier aanroepplekken (openscherm, toestemmingsdialoog, "Over OciDeck", licentiepagina) vragen nu `BrandLogo.<merk>.assetKey`. `ocideck-logo-eu.png` krijgt geen ingang: die zit alleen op de EU-blauwe zijbalk en de navy banner — oppervlakken die in *beide* modi donker zijn — en zijn EU-gele inkt leest daar al. **De kaarten in "Over OciDeck"** stonden hardgecodeerd op `Colors.white` in plaats van `AppTheme.paper`. Dat hield het hele paneel licht in donkere modus, en verborg tegelijk dat het LibreKAT- en Vigilis-merk erop donkere inkt waren: de kaart repareren zonder de logo's zou ze hebben laten verdwijnen. Vandaar in één beweging. Het LibreKAT-logo in het *themaprofiel* (`models/settings.dart`) blijft uitdrukkelijk de lichte variant. Dat logo staat op een dia, een dia is een vast wit canvas in beide modi, en het reist mee in de export. ## De regressietest Een widgettest had dit nooit gevangen — elke aanroepplek deed precies wat er stond. De toets kijkt daarom eerst in de *bestanden*: transparante hoeken, lichte inkt, gelijke afmetingen per paar, en alle zes registreerbaar via `rootBundle`. Daarnaast een bronregel dat geen aanroepplek in `lib/` zelf een merkpad kiest, want de vijfde die iemand toevoegt krijgt geen compilerfout maar een wit vlak. Alle vier de controles zijn rood gezien tegen de onherstelde toestand: | Mutatie | Wat rood werd | |---|---| | donkere variant → de ondoorzichtige plaat | transparante hoeken + lichte inkt | | aanroepplek kiest zelf het pad | de bronregel | | kaart terug op `Colors.white` | de kaarttest | ## Met eigen ogen `flutter run -d macos` in donkere modus, alle vier de plekken nagelopen: openscherm, uitgeverskaart, "Mogelijk gemaakt door", licentiepagina. Lichte modus is aantoonbaar ongewijzigd — `AppTheme.paper` ís `Colors.white` als `isDark` onwaar is, en `assetKey` geeft dan hetzelfde bestand als voorheen. ## Poorten - `make check` groen, `make check-full` groen. - `make check-secrets`: 0 (gitleaks + trufflehog, werkboom én historie). - `make sast`: 0 bevindingen (3 regels over 687 bestanden). - **DAST niet gedraaid.** ZAP is advisory en aan geen enkel doel gekoppeld; deze wijziging raakt geen geserveerd oppervlak. - Geen nieuwe afhankelijkheid, dus geen SBOM-gevolg. Geen nieuwe `l10n.d('…')`, dus geen 31 vertalingen — de bestaande `Semantics`-labels blijven staan. ## Eén afweging om te noemen `vigilis-logo-dark.png` is een hertinting van andermans merk: het zwarte woordmerk wordt licht, het gele beeldmerk blijft ongemoeid. Dat is de gebruikelijke knockout-variant voor een donkere ondergrond en verandert niets aan de vorm of de herkenbaarheid — maar het is wél een sponsormerk, en als Vigilis huisstijlregels heeft, is dit het moment om dat na te lopen. Ik heb het gedaan omdat het alternatief was dat hun naam in donkere modus onleesbaar op de kaart stond; dat leek me slechter dan een nette knockout. Verder raakt deze wijziging niets uit het bewaker-rijtje: geen bestandsformaat, geen opslag, geen afhankelijkheid, geen uitgaand verkeer, geen publieke belofte.

brenno added 4 commits 2026-07-23 12:57:07 +00:00

feat(theme): donkere varianten van de drie merklogo's ... 88da869e7b

Dezelfde tekening, echt transparante achtergrond, inkt op de donkere
waarde van AppTheme.ink. Afgeleid uit de bestaande assets, zodat de
lijnvoering identiek blijft; voor ocideck-logo.png is de alfa
teruggerekend uit de compositie over wit, genormaliseerd op het
inktplateau (44) en niet op de donkerste pixel — dat laatste maakte het
hele logo een tint te bleek.

BrandLogo koppelt elk paar en kiest op AppTheme.isDark, zodat een
volgende aanroepplek het niet zelf hoeft te weten.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

fix(ui): het logo was in donkere modus een groot wit vlak (#735) ... 3b8b983560

De oorzaak zat in de asset, niet in de weergave: ocideck-logo.png is
volledig ondoorzichtig — alle hoeken #FFFFFF bij alfa 255, bijna negentig
procent van het beeld wit. Op een licht oppervlak valt die plaat weg, op
het donkere openscherm was het op 200px het enige wat je zag.

De vier aanroepplekken vragen nu BrandLogo.<merk>.assetKey. Daarnaast
stonden de kaarten in 'Over OciDeck' hardgecodeerd op Colors.white in
plaats van AppTheme.paper: dat hield het paneel licht in donkere modus,
en verborg dat het LibreKAT- en Vigilis-merk erop donkere inkt waren.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

test(theme): bewaak de logo-assets in de pixels, niet in de code (#735) ... 1e1a9102e4

Een widgettest had deze fout nooit gevangen — elke aanroepplek deed
precies wat er stond. De toets kijkt daarom in het bestand: transparante
hoeken, lichte inkt, gelijke afmetingen per paar. Plus een bronregel dat
geen aanroepplek in lib/ zelf een merkpad kiest, want de vijfde die
iemand toevoegt krijgt geen compilerfout maar een wit vlak.

Alle vier de controles zijn rood gezien tegen de oude toestand.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs: changelog en bronkaart voor de donkere logovarianten (#735) ... 10b4e2cd6f

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

brenno merged commit 971abe301b into main 2026-07-23 12:57:18 +00:00

brenno referenced this pull request from a commit 2026-07-23 12:57:20 +00:00

Merge pull request 'fix(ui): het logo was in donkere modus een groot wit vlak (#735)' (#742) from fix/logo-donkere-modus-735 into main

brenno referenced this pull request 2026-07-23 12:57:48 +00:00

[Bug] Het logo is in donkere modus een groot wit vlak #735

Sign in to join this conversation.

Reviewers

No reviewers

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

Subscribe

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!742

No description provided.