diff --git a/lib/widgets/controllable_loads_section.dart b/lib/widgets/controllable_loads_section.dart index 2fd201d..774cb0c 100644 --- a/lib/widgets/controllable_loads_section.dart +++ b/lib/widgets/controllable_loads_section.dart @@ -101,6 +101,28 @@ class _ControllableLoadsSectionState extends State { // domaine porte UNE charge, et l'ordre de service se règle donc entre domaines. // C'est là que la prise doit être. Réordonner deux charges d'un même domaine reste // possible, par les flèches de leur carte. + // + // ⚠️ **MAIS ce montage ne peut pas défiler pendant un glissement**, et c'est un + // défaut ouvert, pas un choix. Établi par construction le 2026-09-08 : + // + // `roles_devices_screen.dart:113` est un `ListView` — le parent défile. Cette + // liste-ci est en `shrinkWrap: true`, donc son viewport vaut exactement la hauteur + // de son contenu et son `maxScrollExtent` est **nul**. Or l'auto-défilement du + // glisser-déposer agit sur le `Scrollable` de la liste RÉORDONNABLE, jamais sur un + // parent : il n'a donc nulle part où aller, et le `ListView` extérieur n'est même + // pas prévenu. + // + // Conséquence : on ne peut réordonner que ce qui tient à l'écran **en même temps**. + // Or un bloc de domaine déplié fait plus d'un écran à lui seul, donc le geste qui + // compte — remonter un domaine par-dessus un autre — est précisément celui qui ne + // peut pas aboutir. Replier les blocs le rend possible : c'est un contournement, + // et c'est aussi le contrôle qui prouve le diagnostic. + // + // Le remède est structurel : UN seul `Scrollable` sur l'écran, en `CustomScrollView` + // + `SliverReorderableList` — le montage déjà utilisé dans `favorites_screen.dart`. + // Pas fait ici tant que le geste n'a pas été éprouvé au doigt : l'entrée synthétique + // ne reproduit pas un appui-glissé (cf. `tools/rpc/README.md`), donc aucun test de + // ce dépôt ne peut ni montrer le défaut ni prouver sa correction. ReorderableListView.builder( shrinkWrap: true, primary: false,