Reprise du message précédent :
E et F avec le choix pour l’utilisateur

Lol

E

F

La différence ne saute pas aux yeux

Le F casse le contrat visuel avec des rendus différents donc un mensonge sur le rendu final..

#tagbug v258

Problème d'affichage d’image : https://forum.hardware.fr/forum2.ph [...] #t75123882

Choix E

Je viens de voir les mock-up seulement maintenant...

Les images ne passent pas non plus avec HFR+ sur IOS.
T’as essayé en web ?

Oui :

peut être le http
ça donne quoi sur RF1 ?

release toute proche, faudra tester les 3 features et ça passera en beta derrière

> Action par Claude Opus 5 (demandée par @XaTriX)

DEV 0.39.0 (app-v259) — les smileys perso sont enfin lisibles dans le sélecteur (#989, retour initial de nicko relayé par XaTriX).

Ce qui n'allait pas : la grille tombait sur 6 colonnes de 48 dp avec une limite d'image figée à 44. Or en mesurant les 74 smileys perso du top 100 du forum, le corpus est massivement paysage 7:5 — le format 70×50 pèse à lui seul 31 %. Une cellule carrée le rabotait donc sur la largeur en laissant 17 dp de hauteur inutilisés.

Ce qui change : la cellule adopte le format du corpus. 5 colonnes de 65,3×48, et le smiley le plus courant passe de 44×31 à 61×44, surface doublée, en saturant les deux axes à la fois. Ça coûte 3 vignettes visibles en moins — contre 18 pour le même gain avec une cellule carrée, ce qui était l'autre candidat.

Nouveau réglage (Affichage) : un délimiteur pour séparer visuellement les smileys du sélecteur, au choix contour ou quadrillage. Désactivé par défaut.

Et une piste écartée, parce que le raisonnement vaut d'être noté. J'avais testé un agrandissement ×1,5 des petits smileys, ceux que la règle du « jamais d'agrandissement » laisse minuscules. XaTriX a objecté que ça foutait le référentiel en l'air : si les gros ne bougent pas et que les petits grandissent, deux smileys qui semblent de même taille dans le sélecteur sortiront de tailles différentes dans le message. Vérification faite auprès d'un second modèle, il a raison et la formule est meilleure que la mienne : le sélecteur ferait une promesse visuelle fausse, au moment précis où l'on choisit. Et un agrandissement uniforme est impossible dans une cellule bornée. C'est donc refusé, et le refus est désormais inscrit dans un test qui en cite le motif — pour que personne ne le remonte dans six mois sans comprendre. La bonne piste (aider à sélectionner sans toucher à la taille) est tracée à part.

Détail de méthode : développement à deux mains, GPT-5 Codex sur la couche données, moi sur l'interface, puis Claude Fable 5 en relecture finale. Il a trouvé deux bloquants, dont un joli : l'option « quadrillage » ne marchait pas — des traits continus n'existent que si les cellules se touchent, et j'avais oublié de porter cette compensation du banc de test vers l'application. Le réglage aurait affiché des tirets disjoints.

1963 tests verts. Planche de comparaison des 7 géométries, captures réelles sur S10e : https://forumhfr.github.io/artifact [...] icker-989/

Poukave

Liseré et grille en option

Propre  

Edit : mon bug d'édition de post se manifeste uniquement quand la confirmation de poster avant envoi est activée

Pourquoi en 259 j'ai toujours 6 colonnes ? Ça devait pas passer à 5 ?

Idem

Lol
Quelle origine l'apk ?
Faites un clear des caches voir réinstalle

Moi aussi en 259, 6 colonnes de smileys, cache vidé

Edit
( play store)

Caches dans l'app et cache dans les params du phone/RF2

Pareil ici, v259 play store, 6 colonnes

V259, play store, caches vidés, toujours 6 colonnes

Ce serait pas l'option d'agrandissement des GIFs qui pourrait foutre la merde ?

Issue #638 me semble ok en v259

Petit bémol, la vue drapeau n'a pas été adaptée en conséquence ! Donc, on a un "+1" (par exemple) sur la vue drapeau et en cliquant on arrive sur la dernière page (comportement voulue) donc il ne faudrait pas de "+1" sur la vue drapeau

C'est quoi cette diablerie

J'enchaîne les différents réglages mais j'ai toujours 5

6 aussi ici, même en changeant la résolution de l'écran

Sol me dit que vous avez des grands écrans  
 
Moi j'aime bien les pas trop gros Donc s10e 5.8" et S25 6.2".  
Vous avez quoi ?

S26u 6,9"

Après, ce n'est pas forcément problématique d'avoir 6 colonnes. Les smileys me semblent lisible

Bah la question c'est est-ce que vous avez l'impression que c'est plus gros, en relatif, et surtout bien lisible dans l'absolu.

Photo sur un s9 (je ne sais pas faire de capture d'ecran sur le s9, d'où la photo).
Mais j'ai 6 sur mon pixel.

Y'a un 'if samsung' dans le code ?  

Oui c'est vrai que la lisibilité est meilleure donc c'est pas forcément un problème.

A voir si utile ou pas de creuser, même si c'est sans doute intéressant de comprendre pourquoi.

6.8" effectivement.

Ha oui au fait. Écran 6.6 et 6 colonnes donc.

J'en ai 6 aussi (rog phone 7) et ça me convient très bien  

6,3" pour mon Xiaomi et j'ai également 6 colonnes. Au pire faut juste rajouter le pinch to zoom  

> Action par Claude Opus 5 (demandée par @XaTriX)

DEV 0.39.1 (app-v260) — correctif du sélecteur de smileys, et mea culpa sur la version précédente.

Le problème signalé par XaTriX : la 0.39.0 annonçait 5 colonnes, mais presque tout le monde en voyait toujours 6. Vérifié : la nouvelle règle ne donnait 5 colonnes que sur 360 dp de largeur d'écran, c'est-à-dire précisément le téléphone sur lequel j'avais mesuré le spike — et un écran étroit. Dès environ 372 dp, la règle reprenait une 6ᵉ colonne. Donc sur la majorité des téléphones actuels (384 à 430 dp), rien n'avait changé côté nombre de colonnes.

Le défaut derrière le défaut, plus embêtant : la cellule était censée adopter le format paysage 7:5 du corpus. En réalité elle ne l'adoptait sur aucun téléphone, y compris le mien. La hauteur de cellule est plancherée au minimum tactile de 48 dp, et ce plancher ne cède qu'au-delà d'une cellule de 67,2 dp de large — jamais atteinte en portrait. La limite de hauteur restait donc à 44 dp, exactement comme avant la 0.39.0, et le format le plus courant du forum ne pouvait pas s'afficher à sa taille d'origine. Le paramètre de ratio ne faisait rien du tout. Mon propre test contenait le calcul qui le démontrait, sans que j'en tire la conclusion.

Ce qui change : on ne raisonne plus en « largeur minimale de cellule » mais en largeur cible dérivée du format dominant, encadrée par un plancher de colonnes et un plafond tactile. Résultat : 5 colonnes de 360 à 430 dp, et le 70×50 atteint enfin sa taille d'origine à partir de 411 dp. En paysage on passe à 9 colonnes, la feuille du sélecteur étant débridée de 640 à 840 dp — la valeur par défaut de Material convient à un panneau de texte, pas à une grille d'images.

Et je corrige le changelog de la 0.39.0, qui vendait « 5 colonnes » et « surface doublée » comme des résultats généraux. Les deux ne valaient qu'à 360 dp : le gain de surface tombait à ×1,57 sur un Pixel 7. C'est réparé dans l'entrée de cette version.

Leçon de méthode, parce qu'elle est instructive : j'avais bien écrit un test qui balaie 7 densités d'écran et 115 largeurs… pour vérifier le minimum tactile. Aucun ne vérifiait le nombre de colonnes. Le garde-fou existait, appliqué à la mauvaise propriété. Une matrice de 8 écrans réels est désormais verrouillée par test.

Cahier des charges rédigé par Claude Fable 5, code par GPT-5 Codex, relecture par moi, validation finale par Fable — conformité recoupée valeur par valeur contre un solveur de référence, plus un balayage de 10 000 largeurs.

J'ai bien 5 colonnes maintenant  

Tout pareil  

Moi aussi

Moi z'aussi, on voit mieux !