Yang terbersih tentu saja akan memperbaiki bug, tetapi sebagai solusi, skrip latar belakang di bawah ini akan melakukan pekerjaan:
#!/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'"])
Cara Penggunaan
- Salin skrip di atas ke dalam file kosong, simpan sebagai
NM_on.py
Tes-jalankan di latar belakang dengan perintah:
python3 /path/to/NM_on.py
Jika semua berfungsi dengan baik, tambahkan ke Aplikasi Startup: Dash> Startup Applications> Add, tambahkan perintah:
/bin/bash -c "sleep 10 && python3 /path/to/NM_on.py"
Penjelasan
Kita bisa mendapatkan status saat ini Num Lock
dalam lebih dari satu cara:
menjalankan perintah:
xset q
yang akan memberikan output seperti:
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
.....
atau dengan perintah:
gsettings get org.gnome.settings-daemon.peripherals.keyboard numlock-state
yang hanya mengembalikan 'on'
, 'off'
atau 'unknown'
.
Karena yang terakhir ini sangat ringan, kami bisa menggunakannya dalam skrip latar belakang untuk memeriksa sekali per detik, dan mengatur nilainya ke 'on'
, jika perlu, dengan perintah:
gsettings set org.gnome.settings-daemon.peripherals.keyboard numlock-state 'on'
dan begitulah ...
Edit
Untuk beberapa alasan, saya melewatkan paragraf terakhir Anda, di mana Anda merujuk ke jawaban lain dengan solusi yang serupa.
Secara teoritis murni, saya selalu memiliki masalah dengan skrip yang secara buta (kembali) menerapkan pengaturan, tanpa memeriksa keadaan saat ini. Ada bisa menjadi argumen untuk melakukannya, jika perintah
gsettings get org.gnome.settings-daemon.peripherals.keyboard numlock-state
untuk mendapatkan nilai saat ini, akan lebih menuntut yang cukup dijalankan
numlockx on
untuk (kembali) diatur numlockx on
.
Melihat pada saat kedua perintah harus selesai (yang setidaknya merupakan indikasi) namun sebaliknya; perintah
gsettings get org.gnome.settings-daemon.peripherals.keyboard numlock-state
tampaknya lebih "ringan".
Menjalankan skrip latar belakang ide yang buruk?
Tentu saja, jika Anda tidak memiliki alasan untuk menjalankan skrip latar belakang, maka jangan lakukan. Pada saat yang sama, jika skrip latar belakang ditulis dengan baik, diuji dengan saksama, prosedur dioptimalkan dengan cerdas, dan jika itu tidak menambah efek yang terlihat pada pekerjaan prosesor, akan konyol untuk tidak digunakan sebagai solusi jika itu menambah penting fungsionalitas atau menghemat waktu Anda.
Saya selalu memiliki setidaknya 4-8 skrip latar belakang berjalan. Sebagian besar dari mereka selama berminggu - minggu tanpa restart. Tidak pernah melihat efek apa pun, pada sistem lansia saya. Ingatlah bahwa sistem Anda menjalankan banyak loop.