Le plus propre serait bien sûr de corriger le bogue, mais comme solution de contournement, le script d'arrière-plan fera le travail:
#!/usr/bin/env python3
import subprocess
import time
key = "org.gnome.settings-daemon.peripherals.keyboard numlock-state"
while True:
time.sleep(1)
state = subprocess.check_output([
"/bin/bash", "-c", "gsettings get "+key]).decode("utf-8").strip()
if state != "'on'":
subprocess.Popen([
"/bin/bash", "-c", "gsettings set "+key+" 'on'"])
Comment utiliser
- Copiez le script ci-dessus dans un fichier vide, enregistrez-le sous
NM_on.py
Testez-le en arrière-plan avec la commande:
python3 /path/to/NM_on.py
Si tout fonctionne bien, ajoutez-le aux applications de démarrage: Dash> Applications de démarrage> Ajouter, ajoutez la commande:
/bin/bash -c "sleep 10 && python3 /path/to/NM_on.py"
Explication
Nous pouvons obtenir l' Num Lock
état actuel de plusieurs manières:
exécution de la commande:
xset q
ce qui donnera une sortie comme:
Keyboard Control:
auto repeat: on key click percent: 0 LED mask: 00000000
XKB indicators:
00: Caps Lock: off 01: Num Lock: off 02: Scroll Lock: off
03: Compose: off 04: Kana: off 05: Sleep: off
06: Suspend: off 07: Mute: off 08: Misc: off
09: Mail: off 10: Charging: off 11: Shift Lock: off
12: Group 2: off 13: Mouse Keys: off
auto repeat delay: 500 repeat rate: 33
.....
ou avec la commande:
gsettings get org.gnome.settings-daemon.peripherals.keyboard numlock-state
qui revient simplement 'on'
, 'off'
ou 'unknown'
.
Étant donné que ce dernier est extrêmement léger, nous pouvons très bien l'utiliser dans un script d'arrière-plan pour vérifier une fois par seconde, et définir la valeur sur 'on'
, si nécessaire, avec la commande:
gsettings set org.gnome.settings-daemon.peripherals.keyboard numlock-state 'on'
et il en est ainsi ...
Éditer
Pour une raison quelconque, j'ai raté votre dernier paragraphe, dans lequel vous avez fait référence à une autre réponse avec une solution similaire.
En théorie, j'ai toujours un problème avec les scripts qui appliquent (ré) aveuglément les paramètres, sans vérifier l'état actuel. Il pourrait y avoir un argument pour le faire, si la commande
gsettings get org.gnome.settings-daemon.peripherals.keyboard numlock-state
pour obtenir la valeur actuelle, serait plus exigeant que d'exécuter simplement
numlockx on
pour (re) régler numlockx on
.
En regardant l'heure à laquelle les deux commandes doivent se terminer (ce qui est au moins une indication), c'est l'inverse; la commande
gsettings get org.gnome.settings-daemon.peripherals.keyboard numlock-state
semble être plus "léger".
Exécuter un script d'arrière-plan est une mauvaise idée?
Bien sûr, si vous n'avez aucune raison d'exécuter un script d'arrière-plan, ne le faites pas. Dans le même temps, si un script d'arrière-plan est bien écrit, soigneusement testé, les procédures sont intelligemment optimisées et si cela n'ajoute aucun effet notable sur l'occupation du processeur, il serait stupide de ne pas l'utiliser comme solution de contournement s'il ajoute des éléments importants. fonctionnalité ou vous fait gagner du temps.
J'ai constamment au moins 4 à 8 scripts d'arrière-plan en cours d'exécution. La plupart d'entre eux pendant des semaines sans redémarrage. Je n'ai jamais remarqué d'effet sur mes systèmes âgés. Gardez à l'esprit que votre système exécute de nombreuses boucles de toute façon.
gsettings get org.gnome.settings-daemon.peripherals.keyboard numlock-state
revient toujours'on'
.