|
|
@@ -2625,6 +2625,54 @@ de export (het paneel blijft 'm wel tonen — 0 `height:` in het bestand is het
|
|
|
bewijs). **Symptoom als je dit mist:** de grid rendert een leeg grijs vlak, zonder
|
|
|
fout in `dart analyze` of `logcat`.
|
|
|
|
|
|
+**⚠️ Een GEPAGINEERDE lijst kan principieel niet in een scrollende pagina — de
|
|
|
+hele pagina laten meescrollen met de lijst is een dood spoor.** Onderzocht
|
|
|
+2026-09-22 voor `PUitgaanPage` (vraag: op een kleine telefoon de slider +
|
|
|
+advertentie + filterbalk laten meescrollen i.p.v. alleen de tabel). **Besluit
|
|
|
+Bob: bewust niets gedaan** — niet opnieuw voorstellen. Drie blokkades:
|
|
|
+1. De enige builder-route (Column op *Scrollable* + `Shrink Wrap` aan) geeft bij
|
|
|
+ een `PagedMasonryGridView` **een leeg vlak** — al bewezen op Home, zie het
|
|
|
+ StaggeredView-recept elders in dit bestand.
|
|
|
+2. `infinite_scroll_pagination` 4.0.0 vraagt de volgende pagina op bij het
|
|
|
+ **bouwen van item `count - 3`** (`paged_layout_builder.dart:265`), dus op
|
|
|
+ item-index en niet op scrollpositie. Met een onbegrensde hoogte worden alle
|
|
|
+ items meteen gebouwd → alle pagina's achter elkaar opgehaald. Voor Amsterdam
|
|
|
+ is dat 435 events / 9 calls op `services_3` (en ≥600 op `services_1`), dus
|
|
|
+ de paginering weggooien is evenmin een optie.
|
|
|
+3. Pull-to-refresh sneuvelt: de `RefreshIndicator` zit om de grid en heeft een
|
|
|
+ eigen scrollable nodig.
|
|
|
+Echte "alles scrollt" vereist slivers (`SliverMasonryGrid` +
|
|
|
+`AppendedSliverChildBuilderDelegate`); FlutterFlow genereert die niet, en een
|
|
|
+custom widget kan geen FlutterFlow-componenten renderen — je zou slider,
|
|
|
+filterbalk én kaart in Dart moeten herbouwen.
|
|
|
+- **Een vast blok VERPLAATSEN binnen een `Column` met één `Expanded` wint geen
|
|
|
+ ruimte** (denkfout die deze sessie kostte): de lijst krijgt schermhoogte minus
|
|
|
+ álle vaste blokken, dus of de advertentie boven of onder de `Expanded` staat
|
|
|
+ maakt voor die som niets uit. Onder de lijst blijft hij overigens gewoon
|
|
|
+ staan als vaste balk — hij scrollt niet mee weg.
|
|
|
+- **Rekensom telefoon 411×731 dp:** statusbalk 24 + AppBar 80 + slider 234 +
|
|
|
+ advertentie 65 + filterbalk ~90 + lijstpadding 20 + navigatiebalk ~48 = 561,
|
|
|
+ dus ~170 dp over voor een kaart van 160 → één kaart in beeld. Alleen de slider
|
|
|
+ is groot genoeg om een tweede kaart vrij te spelen; al het andere samen haalt
|
|
|
+ die 160 dp niet.
|
|
|
+
|
|
|
+**⚠️ De carousel in de sliders staat op een VASTE 240 dp op alle vier de
|
|
|
+breekpunten, terwijl zijn container op een percentage van de schermhoogte
|
|
|
+staat — dat knijpt op telefoon en verspilt op tablet.** Gemeten 2026-09-22 op
|
|
|
+`PUitgaanSliderComponent` (`height * 0.32` container om een carousel van
|
|
|
+`240/240/240/240`): telefoon 411×731 → container 234 vs. inhoud 240, dus de
|
|
|
+gevraagde hoogte wordt **stil teruggeknepen**; tablet-portret 800×1280 →
|
|
|
+container 410 vs. inhoud 240, dus **170 dp loze ruimte**. Zelfde patroon als de
|
|
|
+Home-slider die "de gevraagde 300 stil terugkneep tot 212". **Gevolg voor wie
|
|
|
+zo'n slider wil verkleinen: dat is geen losse instelling maar een herontwerp
|
|
|
+van de sliderkaart** — de carousel zit op telefoon al op de rem, dus lager gaan
|
|
|
+levert een overflow op (de bekende categorielabel-overflow). Let bij een
|
|
|
+Responsive Value verder op dat FlutterFlow's breekpunten op **breedte** gaan
|
|
|
+terwijl dit een hoogteprobleem is: een telefoon in landschap is 731-820 dp
|
|
|
+breed en krijgt dan de tabletwaarde op zijn laagste scherm. De app zet de
|
|
|
+oriëntatie nergens vast (geen `screenOrientation`, geen
|
|
|
+`setPreferredOrientations`), dus dat geval bestaat echt.
|
|
|
+
|
|
|
**De toggles van `Gradient` en `Box Shadow` in het Container-paneel reageren NIET
|
|
|
op browser-automation — gebruik een omweg.** Bevestigd 2026-09-15: ~6 kliks op
|
|
|
de toggle zelf (track links, track rechts, exacte knoppositie via `zoom`) en op
|
