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>
- Instance unique : un second lancement réveille l'instance active.
- Autostart et reconnexion auto activés par défaut (nouvelle installation).
- Page « À propos » refaite en 5 onglets (contenu séparé dans app_info.py).
- Corrige le handshake/RX-TX qui ne s'affichaient plus (wg show sans élévation).
- Corrige le diagnostic sudo trompeur (sondes qui ne matchaient jamais les règles).
- Corrige make setup-sudoers bloqué hors session graphique (pkexec -> sudo), idempotent.
- Corrige le README : Kill Switch inexistant retiré, ordre d'élévation réel documenté.
fix: la clé pré-partagée n'était écrite dans aucune config client
L'assistant de génération produisait une PresharedKey affichée à l'écran mais
stockée nulle part, et l'import d'un .conf ignorait la ligne. Face à un serveur
qui en attend une, le tunnel montait et l'interface existait — sans qu'aucun
handshake n'aboutisse jamais. La PSK devient un champ à part entière.
fix: options de ligne de commande wireguard.exe incorrectes sous Windows
/installtunnel et /uninstalltunnel n'existent pas ; les vrais verbes sont
/installtunnelservice et /uninstalltunnelservice. S'y ajoutaient l'absence de
résolution du chemin d'installation (WireGuard n'est pas dans le PATH),
l'absence totale d'élévation UAC alors que ces commandes l'exigent, et une
détection d'installation qui sondait une application graphique avec --help.
feat: diagnostic de bout en bout de la chaîne de connexion
Le bouton de test s'arrêtait à la joignabilité UDP et concluait « serveur
joignable » sur un tunnel qui n'échangeait rien. Il déroule désormais quatorze
étapes, de la configuration locale jusqu'au DNS dans le tunnel, et désigne
l'étape qui bloque.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- wg-quick down échoue silencieusement si l'interface a déjà disparu
(crash, kill, veille) et ne retire donc jamais l'entrée DNS posée par
wg-quick up : la résolution reste pointée sur un résolveur mort.
Ajout d'un nettoyage DNS inconditionnel (app/core/dns.py) déclenché à
la connexion, la déconnexion, la fermeture et au démarrage suivant.
- is_connected() se basait sur `wg show`, qui rend un code 0 même en cas
d'échec de permission pour un utilisateur non-root : l'app se croyait
déconnectée en permanence et ne démontait donc jamais le tunnel à la
fermeture. Détection réécrite via sysfs (sans privilèges).
- Connexion/déconnexion et ping tournaient sur le thread Qt : gel de
l'UI pendant les élévations de privilèges. Déportés dans des
QThread (app/ui/worker.py).
- Restauration réseau garantie sur toutes les sorties (croix, tray,
SIGINT/SIGTERM, atexit, exception) via app/core/shutdown.py.
- run_privileged() : la détection "sudo veut un mot de passe" ratait en
session non-anglophone et sur les comptes ALL=(ALL) ALL ; réécrite
pour se fier au message d'erreur réel plutôt qu'à `sudo -l`.
- Écriture de la config WireGuard dans /etc/wireguard (root:root 0700)
passe maintenant par install -D via la chaîne de privilèges complète
au lieu d'un tee non autorisé par les sudoers.
- Ajout d'un diagnostic des droits (make check-privileges, bouton
Admin) et mise à jour de setup-sudoers pour couvrir toutes les
commandes désormais utilisées.
tuxgyverandClaude Opus 5
tuxgyver
Johnny