
Une variable CSS, cinq tours de revue et une chaîne d'outils Swift qui a menti
La v2.0.7 de GeekBye a rendu tout l'overlay translucide de façon ajustable — ce qui ressemble à une modification CSS d'une ligne et n'en était absolument pas une. La vraie histoire, c'est ce qu'a rattrapé la revue de code : deux surfaces qui refusaient de s'estomper, une barre d'enregistrement qui paraissait fausse à la même opacité, et un binaire compilé qui a oscillé de 672 octets parce que notre propre documentation a indiqué à un relecteur la mauvaise version de Swift.
« Rends l''overlay translucide » est le genre de tâche qui ressemble à un curseur et à une propriété CSS opacity. La v2.0.7 de GeekBye a livré exactement ce résultat côté utilisateur — un unique « mode clair » ajustable qui vous laisse voir à travers les panneaux de l''assistant ce qu''il y a derrière. Mais la partie intéressante de cette sortie, ce n''est pas la fonctionnalité. Ce sont les cinq tours de revue qu''il a fallu pour la réussir, et une histoire de guerre autour d''un binaire compilé qui a changé de taille parce que notre propre documentation a menti à un relecteur.
La bonne façon de rendre toute une interface translucide
La version naïve consiste à saupoudrer une valeur d''opacité sur chaque composant de panneau et à considérer que c''est réglé. C''est un piège de maintenance : une douzaine de valeurs codées en dur qui divergent dès que quelqu''un en touche une.
À la place, la v2.0.7 utilise un unique utilitaire CSS partagé et un token par surface. Il y a une seule classe overlay-surface qui calcule le fond d''un panneau à partir de deux propriétés personnalisées : une opacité de base que chaque surface déclare pour elle-même (la barre de contrôle, le chat, les bulles de transcription, les blocs de code, etc. choisissent chacune la leur), et un multiplicateur d''alpha global qui voyage sur la racine de l''overlay et représente le réglage du curseur de l''utilisateur. Chaque surface lit le même multiplicateur ; chacune garde son propre caractère. Point crucial : seul le fond du panneau est mis à l''échelle — le texte, les icônes et le backdrop-blur restent pleinement rendus, donc « translucide » ne veut jamais dire « illisible ».
Deux décisions de ce design méritent d''être soulignées, car elles font la différence entre une fonctionnalité qui aide et une qui génère des tickets de support :
- La valeur par défaut est totalement opaque. Le réglage d''opacité est livré à 100 % — une opération neutre. L''overlay de personne n''est soudain devenu transparent à la mise à jour ; la translucidité est là quand on la cherche et invisible jusque-là.
- Le réglage est validé de manière défensive. Il y a une source unique de vérité pour le minimum, le maximum, la valeur par défaut et le pas, et un normaliseur qui protège le cas vide/absent. Cela compte à cause d''un piège JavaScript :
Number(null)vaut0, donc un réglage absent coercé naïvement basculerait l''overlay dans son état le plus transparent au lieu de sa valeur par défaut. Le normaliseur intercepte cela avant que ça puisse arriver.
Faites glisser le curseur et tout l''overlay se re-teinte en direct, en pleine session d''enregistrement, parce que chaque surface est abonnée au même réglage. Pas de redémarrage, pas de rechargement.
Ce que la revue a rattrapé (et qu''un test sur un seul écran n''aurait jamais rattrapé)
C''est là que « une variable CSS » a cessé d''être simple. Trois bugs ont fait surface en revue, et deux d''entre eux sont la même leçon sous un déguisement différent.
Un panneau qui refusait de s''estomper. L''overlay des raccourcis clavier restait obstinément opaque pendant que tout le reste devenait translucide. La cause : il se rend en dehors du sous-arbre du DOM qui porte la variable d''opacité, il n''a donc jamais hérité de la valeur qui descendait en cascade depuis la racine de l''overlay. Les propriétés personnalisées CSS s''héritent à travers l''arbre du DOM — et si un nœud n''est pas réellement descendant de l''endroit où vous définissez la variable, il ne reçoit silencieusement rien. Le correctif a été de définir la variable localement sur ce panneau aussi.
Une teinte au survol qui disparaissait. Les boutons Fn/Assist perdaient leur lueur cyan au survol. L''utilitaire de translucidité posait le fond avec !important (il doit l''emporter sur les valeurs par défaut des surfaces), et cela écrasait la teinte de fond hover: sur le même élément. Collision de spécificité. Le correctif a été de rendre la teinte au survol tout aussi appuyée pour qu''elle puisse reprendre le dessus au survol.
Les deux relèvent de la même vérité de fond : une cascade de variables CSS est une véritable frontière de correction, pas un détail de style. L''héritage et la spécificité décident si votre valeur atteint seulement l''élément, et ni l''un ni l''autre n''apparaît sur une capture d''écran tant que ce n''est pas cassé.
La même opacité, un rendu différent. Le plus subtil : la barre d''enregistrement et la barre au repos étaient réglées à l''identique opacité de base, et paraissaient pourtant nettement différentes. Pourquoi ? La pastille d''enregistrement utilisait un backdrop-blur plus lourd, et un flou fort sur un fond sombre tend en moyenne vers un résultat plus sombre — donc un alpha égal produisait une apparence inégale. Elle avait aussi une bordure discrète là où la barre au repos avait un bord en anneau dégradé lumineux. Le correctif a fait correspondre le niveau de flou et l''anneau. La leçon est restée : un alpha égal n''est pas une apparence égale une fois que le flou entre en jeu. La translucidité est un système d''effets qui interagissent, pas un nombre unique.
Le binaire qui a changé de taille parce que la documentation a menti
Maintenant l''histoire de guerre, et c''est mon genre préféré — celle où l''outillage et la documentation se contredisent et où un relecteur consciencieux se retrouve pris entre deux feux.
GeekBye distribue quelques binaires Swift précompilés (des assistants natifs pour des choses comme la détection de réunion). Comme un binaire compilé est commité dans le dépôt, chaque développeur doit le compiler avec exactement la même version de Swift — des chaînes d''outils différentes produisent des octets différents à partir d''un code identique, ce qui signifierait un conflit git fantôme à chaque recompilation. Il y a donc un script qui impose une version précise : Swift 6.3.x, contrôlée au moment du build.
Pendant la revue de cette sortie, un relecteur a signalé qu''un binaire devait être recompilé pour concorder avec « la chaîne d''outils imposée par le dépôt ». Le développeur a fait exactement cela — et la taille du binaire est passée de 89,184 octets à 88,512. Le message du commit disait même qu''il « restaurait une sortie stable en octets » en recompilant avec Swift 6.2.1, « la chaîne d''outils imposée par le dépôt ».
Sauf que 6.2.1 était la mauvaise version. Le script de contrôle du build exigeait 6.3.x. Le problème, c''est que la documentation en prose — le README et le guide du contributeur — disait encore 6.2.1 à deux endroits. Ainsi un relecteur consciencieux et un développeur consciencieux, tous deux essayant de bien faire, ont suivi la documentation droit vers le commit de précisément l''artefact que le script de contrôle existe pour rejeter. Un binaire 6.2.1 dans un dépôt 6.3.x, c''est exactement la dérive qui casserait la recompilation propre de tous les autres développeurs.
Le commit suivant a corrigé cela — et le correctif est l''essentiel. Il n''a pas seulement recompilé le binaire vers sa forme 6.3.x (taille restaurée à 89,184, exactement là où elle avait commencé). Il a aussi corrigé les références obsolètes à « 6.2.1 » dans la documentation pour que le piège ne puisse plus se refermer. Le binaire a oscillé de 672 octets puis est revenu sur deux commits, et le vrai bug n''a jamais été le binaire. C''était que deux sources de vérité — le script de contrôle et la documentation écrite — se contredisaient, et qu''un humain a fait confiance à la mauvaise.
Trois choses que cette sortie a enseignées
- Une cascade de variables CSS est une frontière de correction. Deux des trois bugs de revue se résumaient à une variable qui n''héritait pas et à un
!importantqui écrasait un état au survol. Si une valeur doit atteindre un élément par héritage ou l''emporter par spécificité, ce chemin est de la logique — vérifiez-le comme de la logique, pas comme du style. - Des paramètres égaux peuvent produire des résultats inégaux. La barre d''enregistrement et la barre au repos partageaient une opacité et paraissaient pourtant différentes parce qu''un flou différent changeait le résultat. Quand vous unifiez un système visuel autour d''un seul nombre, vérifiez que les autres variables autour de chaque surface ne changent pas discrètement ce que ce nombre signifie.
- Quand la documentation et le contrôle se contredisent, corrigez la contradiction — pas seulement le symptôme. Le bug n''était pas un mauvais binaire ; c''était une documentation qui nommait la mauvaise chaîne d''outils et un script de contrôle qui disait le contraire. Recompiler le binaire traite le symptôme. Faire concorder toutes les sources de vérité est le vrai correctif, parce que le prochain relecteur fera lui aussi confiance à la documentation.
La v2.0.7 de GeekBye a livré la translucidité uniforme, tous les cas limites revus et la documentation de la chaîne d''outils remise d''aplomb. C''est la dernière des sorties de « métier discret » avant le sprint de fiabilité qui a suivi. Pour les fondations qui la soutiennent, voir ce que coûte vraiment une version 2 (v2.0.0) ; pour la sortie sœur de peaufinage, logiciel calme : le correctif du scintillement et la puce de mode réponse (v2.0.3 + v2.0.5) ; et pour la façon dont l''overlay reste caché pendant un appel, comment rester invisible pendant le partage d''écran.