Widgets d’intégration externe : choisir la disposition des cases et leur donner une couleur d’accent

Demande de fonctionnalités
1

Titre : Widgets d’intégration externe : choisir la disposition des cases et leur donner une couleur d’accent

Bonjour,

Je développe l’intégration externe Prix Carburants. Un utilisateur m’a fait deux remarques sur la carte « Ma station » que je ne peux pas régler côté intégration, car elles dépendent de l’affichage des widgets dans Gladys.

1. Disposition des cases

Aujourd’hui, les cases (value / gauge) passent à la ligne quand la place manque (flex-wrap, largeur mini 96 px). Avec 3 cases sur une carte étroite, on obtient 2 cases à mi-largeur et 1 case en pleine largeur en dessous. L’utilisateur trouverait plus clair d’avoir 3 cases de même largeur, l’une sous l’autre.

Gladys n’envoie pas la largeur de l’écran à l’intégration, donc l’intégration ne peut pas choisir.

Proposition : un champ optionnel dans le contenu du widget, par exemple tiles_layout :

  • auto : comme aujourd’hui (par défaut) ;
  • row : toutes les cases sur une seule ligne, même largeur ;
  • stack : une case par ligne, en pleine largeur.

Une valeur inconnue revient à auto, donc rien ne change pour les intégrations existantes.

2. Couleur d’accent par case

Les couleurs autorisées sont des couleurs « de sens » : neutral, primary, success, warning, danger, info. C’est très bien pour dire « ok / attention / erreur », mais on ne peut pas s’en servir pour repérer une case d’un coup d’œil. Par exemple, l’utilisateur aimerait retrouver les couleurs des pistolets de carburant. Et l’orange (warning) sert déjà, dans ma carte, à signaler une rupture : utiliser les mêmes couleurs pour les deux mélangerait les deux sens.

Proposition : un champ optionnel accent sur les cases, affiché comme une petite barre ou un point de couleur, séparé de color (qui garde son rôle actuel sur la valeur). Deux options possibles :

  • une couleur libre #RRGGBB, vérifiée par Gladys ;
  • ou, pour rester cohérent avec les thèmes clair et sombre, une petite liste de couleurs nommées : green, yellow, blue, orange, red, purple, gray.

Pour finir

Les deux ajouts sont optionnels et ne changent rien aux widgets existants. Je peux proposer une PR si l’idée vous convient.

Merci !

2

Ce sujet tombe a point, j’ai eu cette problématique aujourd’hui :+1:

3

Salut @prohand,

Merci pour ce retour très bien documenté (et merci @Lokkye pour la confirmation) !

Les deux problèmes sont réels. Mais dans les deux cas, je pense que la solution doit venir de Gladys plutôt que d’un nouveau champ côté intégration. C’est le principe de base des widgets d’intégration : l’intégration décrit quoi afficher, Gladys décide comment. C’est ce qui nous permet de garantir que tous les widgets restent cohérents en thème clair, en thème sombre, avec Horizon, et à toutes les largeurs d’écran.

1. La disposition des cases

Tu mets le doigt sur un vrai bug, et ton propre argument donne la clé : l’intégration ne connaît pas la largeur de l’écran, elle est donc la plus mal placée pour choisir la disposition. Le même widget s’affiche sur un téléphone et sur une tablette murale. row avec 6 cases sur un téléphone donnerait des valeurs tronquées, et stack sur une carte large donnerait une carte très haute pour rien. Un choix figé sera forcément faux quelque part.

Le problème vient de notre rendu : quand la place manque, une case passe à la ligne et s’étire sur toute la largeur. Avec 3 cases dans une carte étroite, ça donne exactement le « 2 + 1 » que tu décris, et ça touche toutes les intégrations, pas seulement la tienne.

On va donc corriger ça directement dans Gladys, sans nouveau champ : une grille équilibrée, qui choisit le nombre de colonnes selon le nombre de cases et la largeur réelle de la carte, et qui n’étire plus jamais une case isolée. Ton widget en profitera sans rien changer, comme tous les autres.

2. La couleur d’accent

Couleur hexadécimale libre : non. C’est un choix assumé depuis le départ : on ne pourrait plus garantir le contraste en mode sombre ou avec Horizon, et ce serait la porte ouverte aux couleurs de marque.

Une palette nommée, en revanche, c’est une vraie question. Tu as raison de ne pas détourner warning : color exprime un état (ok / attention / problème), alors que toi tu veux exprimer une identité (quel carburant). Et le besoin dépasse les carburants : les bacs de collecte des déchets (jaune, vert, bleu…) sont typiquement dans le même cas.

J’ai quand même deux réserves :

  • Pour l’utilisateur, une couleur reste une couleur : une barre rouge ou orange sera lue comme une alerte, quel que soit le nom du champ. La confusion que tu veux éviter (orange = rupture) reviendrait visuellement.
  • Le risque « arc-en-ciel » : six cases de six couleurs, c’est exactement l’encombrement qu’on cherche à éviter.

Si on y va, ce serait à ces conditions :

  • une liste fermée de couleurs, que Gladys adapte elle-même au thème clair, au thème sombre et à Horizon (contraste compris : un jaune sur fond blanc n’est pas lisible tel quel) ;
  • affichée uniquement comme une petite pastille d’identité, jamais comme couleur de la valeur ou du fond (ça reste le rôle de color) ;
  • disponible partout où une pastille identifie quelque chose : les cases, mais aussi les lignes de status (un widget de collecte des déchets utiliserait plutôt une liste) ;
  • simplement ignorée par une ancienne version de Gladys.

Comme ce serait un second système de couleurs qui concerne tous les widgets, je préfère traiter ce point à part et le spécifier avant de coder, plutôt que de l’ajouter en même temps que le correctif de disposition. Si d’autres ont des cas d’usage, n’hésitez pas à les partager ici, ça aidera à trancher :slightly_smiling_face:

En attendant, pour Prix Carburants, le libellé et l’icône de chaque case suffisent à identifier le carburant, et tu as bien raison de garder warning pour les ruptures.

Merci encore pour la proposition et pour l’offre de PR ! Pour l’accent, attendons d’avoir tranché ici avant de partir sur du code.

4

Ticket :