Najczystszym rozwiązaniem byłoby oczywiście naprawienie błędu, ale w celu obejścia tego problemu poniższy skrypt w tle wykona zadanie:
#!/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'"])
Jak używać
- Skopiuj powyższy skrypt do pustego pliku i zapisz go jako
NM_on.py
Uruchom go w tle za pomocą polecenia:
python3 /path/to/NM_on.py
Jeśli wszystko działa poprawnie, dodaj go do aplikacji startowych: Dash> Aplikacje startowe> Dodaj, dodaj polecenie:
/bin/bash -c "sleep 10 && python3 /path/to/NM_on.py"
Wyjaśnienie
Aktualny Num Lock
stan możemy uzyskać na więcej niż jeden sposób:
uruchomienie polecenia:
xset q
co da wynik taki jak:
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
.....
lub z poleceniem:
gsettings get org.gnome.settings-daemon.peripherals.keyboard numlock-state
który po prostu zwraca 'on'
, 'off'
lub 'unknown'
.
Ponieważ ten ostatni jest wyjątkowo lekki, możemy go bardzo dobrze użyć w skrypcie w tle, aby sprawdzać raz na sekundę i ustawić wartość 'on'
, jeśli to konieczne, za pomocą polecenia:
gsettings set org.gnome.settings-daemon.peripherals.keyboard numlock-state 'on'
i tak się dzieje ...
Edytować
Z jakiegoś powodu brakowało mi twojego ostatniego akapitu, w którym odniosłeś się do innej odpowiedzi z podobnym rozwiązaniem.
Czysto teoretycznie zawsze mam problem ze skryptami, które na ślepo (ponownie) stosują ustawienia, bez sprawdzania aktualnego stanu. Nie mogło być argumentem, aby to zrobić, jeśli komenda
gsettings get org.gnome.settings-daemon.peripherals.keyboard numlock-state
aby uzyskać aktualną wartość, byłoby bardziej wymagające, że wystarczy uruchomić
numlockx on
ustawić (ponownie) numlockx on
.
Patrząc na czas, w którym oba polecenia muszą zakończyć (co jest przynajmniej wskazówką), jest jednak na odwrót; Komenda
gsettings get org.gnome.settings-daemon.peripherals.keyboard numlock-state
wydaje się być bardziej „lekki”.
Uruchamianie skryptu w tle to zły pomysł?
Oczywiście, jeśli nie masz powodu, aby uruchamiać skrypt w tle, nie rób tego. Jednocześnie, jeśli skrypt w tle jest dobrze napisany, dokładnie przetestowany, procedury są inteligentnie zoptymalizowane, a jeśli nie doda żadnego zauważalnego wpływu na zajęcie procesora, głupio byłoby nie używać tego obejścia, jeśli dodaje ważne funkcjonalność lub oszczędza czas.
Ciągle mam uruchomione co najmniej 4-8 skryptów w tle. Większość z nich przez tygodnie bez restartu. Nigdy nie zauważyłem żadnego wpływu na moje starsze systemy. Pamiętaj, że i tak Twój system działa w wielu pętlach.
gsettings get org.gnome.settings-daemon.peripherals.keyboard numlock-state
nadal powraca'on'
.