Le module de thème publie deux palettes derrière les mêmes noms : `apply()`
rebranche `BG`, `TEXT`, `TAB_CSS` sur celle qui est choisie au lancement, et
les cent soixante-dix appels répartis dans l'interface continuent de lire
`theme.BG` sans rien savoir du thème actif. Aucun widget n'a eu à changer —
c'est ce que permettait le passage systématique par `theme.X` à l'usage.
Le choix est lu une seule fois, au démarrage. Les feuilles de style sont
posées dans les constructeurs des fenêtres ; les repeindre à chaud
supposerait de reconstruire celle qui porte l'état du tunnel, ses fils
d'exécution et ses minuteries. Le message de confirmation annonce donc la
prise d'effet au prochain lancement plutôt que de laisser croire le contraire.
Le thème sombre reste le défaut, et rend exactement les mêmes feuilles de
style qu'avant.
Un thème clair n'est pas une inversion, et trois familles de valeurs vivaient
en dur là où elles étaient jusqu'ici invisibles. Dans la feuille de style
commune, les variantes d'état des champs et des boutons étaient des voiles
blancs translucides — c'est-à-dire rien du tout sur un fond clair. Le texte
posé sur un aplat saturé — bouton plein, onglet actif, bandeau, sélection —
portait `TEXT`, qui devient presque noir en thème clair et disparaîtrait sur
l'accent : un jeton distinct le dit, blanc dans les deux thèmes. Enfin le
graphe de bande passante peignait son fond en dur, soit un panneau sombre au
milieu d'une page claire ; ses sept teintes sont devenues des jetons, comme
quatre couleurs de survol de la fenêtre principale.
Deux endroits figeaient par ailleurs le thème au chargement de leur module et
auraient gardé les teintes sombres quel que soit le réglage : la feuille de
style de la fenêtre d'historique, bâtie au niveau du module, et la table
état → couleur du diagnostic, évaluée comme attribut de classe. La première
devient une fonction, la seconde ne retient que la puce et demande la couleur
au thème au moment de l'affichage.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La v0.8.0 laissait cohabiter deux vérifications du code à 6 chiffres : la
fenêtre MFA locale, qui contrôlait un code contre un secret détenu par le
poste lui-même — et ne verrouillait donc que sa propre interface — puis la
validation par le serveur, seule à décider de l'accès réseau. L'ancienne
disparaît, avec le secret TOTP qu'elle stockait en clair dans config.json
(effacé au premier lancement) et l'onglet MFA du panneau Administrateur.
La saisie passe par une fenêtre dédiée qui relaie le refus exact du serveur
et laisse réessayer, la requête partant dans un thread pour qu'un serveur
muet ne fige pas l'application. Une ligne « Accès distant » distingue
désormais l'état de l'autorisation de celui du tunnel : monté sans code
validé, celui-ci ne mène nulle part.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La présence d'une clé pré-partagée se devinait au fait que le champ soit
rempli. Un serveur qui n'en utilise pas — le cas par défaut de WireGuard —
déclenchait donc un avertissement à chaque diagnostic, et une clé oubliée dans
le champ finissait écrite dans la configuration alors que le serveur n'en
attendait aucune, ce qui casse le handshake aussi sûrement qu'une clé
manquante. Une case à cocher tranche désormais, et le diagnostic distingue les
quatre états au lieu d'un avertissement unique.
Le drapeau vaut None par défaut et non False : _merge() recopie le défaut dans
toute configuration antérieure, et False aurait désactivé la PSK d'un tunnel
qui fonctionnait.
Refonte des onglets, qui passaient de sept à cinq :
- WireGuard et Clés se chevauchaient — la clé publique du serveur se saisissait
dans l'un pendant que l'assistant qui la produit vivait dans l'autre, et les
quatre façons de sortir une configuration étaient réparties entre les deux.
Fusionnés en sous-onglets Tunnel, Clés, Profils & fichiers.
- Les trois tests s'empilaient sur une page unique où le rapport de diagnostic
se retrouvait comprimé. Chacun a son sous-onglet.
- MFA et Sécurité répondent à la même question et sont regroupés.
- La section des droits parlait de sudo et de setup-sudoers sous Windows, où
rien de tout cela n'existe, et concluait « privilèges root » sur un rapport
simplement vide. Elle vérifie maintenant l'élévation UAC et WireGuard.
Chaque onglet s'ouvre sur un encart expliquant ce qu'on y décide, et les
couleurs — vingt-quatre valeurs en dur, cinq bandeaux sans rapport de teinte,
des blocs de résultat au fond incohérent — passent par app/ui/theme.py.
tuxgyverandClaude Opus 5
tuxgyver