Edge-to-edge : gestion des marges en orientation paysage - #79
Conversation
…des topics pour éviter le capteur en paysage. En paysage, le contenu des lignes passait sous la découpe du capteur. Chaque ligne applique désormais en padding latéral l'inset (barre de navigation et découpe du capteur), la même valeur des deux côtés pour un décalage symétrique quel que soit le côté du capteur. Le fond de la ligne reste pleine largeur et passe donc sous le capteur, seul le contenu est décalé. L'inset est capturé sur le SwipeRefreshLayout parent (le listener du bas est déjà posé sur la ListView) et renvoyé non consommé, puis transmis à l'adapter. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…n de page pour éviter le capteur en paysage. En paysage, le contenu des barres de pagination pouvait passer sous la découpe du capteur. On applique désormais un padding latéral symétrique (le max des insets gauche/droite de barre de navigation et découpe du capteur) sur les trois conteneurs concernés : la liste des topics d'un forum, la liste des messages d'un topic et la recherche de topics dans un forum. Le fond des barres reste pleine largeur, seul leur contenu est décalé. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…e capteur en paysage. La toolbar appliquait l'inset gauche et droite séparément, ce qui décalait son contenu vers le capteur en paysage. On applique désormais le max des deux insets des deux côtés, pour que le contenu reste centré quel que soit le côté du capteur. Le bouton de navigation garde son indentation Material standard (comme en portrait, simplement décalé par le cutout). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…s pour éviter le capteur en paysage. En paysage, le contenu de la liste des messages pouvait passer sous la découpe du capteur. On applique désormais un décalage latéral symétrique (le max des insets gauche/droite de barre de navigation et découpe du capteur, la même valeur des deux côtés quel que soit le côté du capteur). Deux mécanismes selon le style de liste, car les besoins diffèrent : en mode carte, les cartes flottent, donc on ajoute l'inset en marge autour d'elles via le padding latéral de la ListView (avec clipToPadding=false) pour décaler la carte entière ; sinon les lignes occupent toute la largeur, donc leur fond reste pleine largeur et passe sous le capteur, seul leur contenu est décalé via un padding posé sur chaque ligne par l'adapter. L'inset est capturé sur le SwipeRefreshLayout parent (pour ne pas monopoliser le listener de la ListView) et renvoyé non consommé, puis aiguillé vers l'un ou l'autre mécanisme selon cardDesignIsEnabled. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…r éviter le capteur en paysage. En paysage, le bouton +, la zone de texte et le bouton d'envoi de la barre d'envoi d'un topic pouvaient passer sous la découpe du capteur. On décale désormais le contenu de la barre en padding latéral symétrique (le max des insets gauche/droite de barre de navigation et découpe du capteur), tout en gardant son fond pleine largeur : le fond garde l'apparence de prendre toute la largeur (comme la liste des topics) et seul le contenu est resserré. Le padding du bas (barre de navigation et clavier) est conservé. Le décalage latéral est intégré au listener d'insets déjà posé sur la barre d'envoi, une vue ne pouvant avoir qu'un seul listener. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…herche pour éviter le capteur en paysage. En paysage, les boutons Sujet/Auteur/Message de la recherche de topics (alignés à droite) pouvaient passer sous la découpe du capteur. On applique désormais à leur barre le même padding latéral symétrique que la barre de pagination juste au-dessus : le fond reste pleine largeur, seul le contenu est resserré. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…l'accueil pour éviter le capteur en paysage. En paysage, les cartes de catégories de l'accueil (sélection d'un forum) pouvaient passer sous la découpe du capteur. Comme les cartes flottent, on les décale via une marge autour d'elles (padding latéral symétrique ajouté sur leur conteneur, en plus de spaceAroundSingleCard) plutôt que par du padding interne. Le conteneur reçoit bien les insets car le listener du bas posé sur le ScrollView parent les renvoie non consommés. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… de recherche de forum pour éviter le capteur en paysage. En paysage, le contenu des lignes de résultats de recherche de forum (accueil) pouvait passer sous la découpe du capteur. Ces lignes occupent toute la largeur, donc chaque ligne applique désormais en padding latéral l'inset (barre de navigation et découpe du capteur), la même valeur des deux côtés pour un décalage symétrique. Le fond de la ligne reste pleine largeur et passe sous le capteur, seul le contenu est décalé. L'inset est capturé sur le SwipeRefreshLayout parent (le listener du bas est déjà posé sur la ListView) et renvoyé non consommé, puis transmis à l'adapter. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…latéral symétrique. Le calcul de l'inset latéral symétrique (le max des insets gauche/droite de barre de navigation et découpe du capteur) était dupliqué sur six emplacements, et la pose du listener sur le parent d'une liste (capture puis renvoi non consommé, plus requestApplyInsets) l'était sur trois. On extrait donc deux utilitaires dans Utils : getSymmetricSideInset(WindowInsetsCompat) pour le calcul, et forwardSymmetricSideInset(parent, cible) pour la diffusion vers une liste. La toolbar et la barre d'envoi (qui gèrent aussi le haut ou le bas) utilisent désormais getSymmetricSideInset pour leur latéral, addSymmetricSideInsetPadding s'appuie dessus, et ShowForumFragment, SelectForumInListActivity et AbsShowTopicFragment remplacent leur listener manuel par forwardSymmetricSideInset. Le listener passe d'onCreateView à onViewCreated (après setAdapter), ce qui rend inutiles les gardes de nullité de l'adapter. Comportement inchangé. La cible de diffusion passe par une interface maison (SideInsetTarget) plutôt que java.util.function.IntConsumer, indisponible sous minSdk 23 sans desugaring des bibliothèques. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Dans les commentaires ça parle beaucoup de laisser de l'espace vertical pour la découpe du capteur (logique) et pour la barre de navigation, mais je vois pas dans quel contexte on pourrait avoir la barre de navigation sur les cotés. Bon c'est que des commentaires donc on s'en fout un peu. |
| ViewCompat.requestApplyInsets(swipeRefresh); | ||
| /* Edge-to-edge : on capture l'inset latéral sur le parent de la liste (le listener du bas est déjà | ||
| posé sur la ListView) et on le transmet à l'adapter qui décale le contenu de chaque ligne. */ | ||
| Utils.forwardSymmetricSideInset(swipeRefresh, adapterForForum::setSideInset); |
There was a problem hiding this comment.
J'aime pas trop ça. Avant la lambda s'exécutait sur l'adapterForForum actuel au moment de l'appel, maintenant elle s'exécute sur l'adapterForForum présent au moment de la création de la lambda. Ça me semble plus fragile.
There was a problem hiding this comment.
(sachant que ce membre peut changer quand on appelle la fonction recreateAdapterForForum)
FranckRJ
left a comment
There was a problem hiding this comment.
Je pense que le SideInsetTarget devrait être récupéré dynamiquement pour être certain d'appliquer l'inset à l'objet courant dans forwardSymmetricSideInset, et pas à l'objet qui était courant lors de la création de la lambda.
Laisse de l’espace pour le sensor en mode paysage, au lieu que le contenu passe en dessous, et fait la même chose de l’autre côté de l’écran pour avoir de la symétrie.
Gérés :
Certains ont le fond en pleine taille (telle la liste des topics) avec juste le contenu décalé, certains ont le tout décalé (telle que la liste des messages quand c’est des cards), selon ce qui fait sens pour chaque.
Pas gérés :