Nuovo analogo di Punto Switcher per Linux: xswitcher
La fine del supporto di xneur mi ha causato qualche sofferenza negli ultimi sei mesi. (con l'avvento di OpenSUSE 15.1 sui miei desktop: con xneur abilitato, le finestre perdono la messa a fuoco e sfarfallano in modo strano a tempo con l'input da tastiera).
"Oh, dannazione, ho ricominciato a digitare nel layout sbagliato" - nel mio lavoro ciò accade spesso indecentemente. E non aggiunge nulla di positivo.
Allo stesso tempo, io (come ingegnere progettista) posso formulare abbastanza chiaramente ciò che voglio. Ma volevo (prima da Punto Switcher, poi, grazie a Windows Vista, passando infine a Linux, da xneur) esattamente una cosa. Dopo aver realizzato che i rifiuti sullo schermo sono nel layout sbagliato (questo di solito accade alla fine della digitazione di una nuova parola), premere "Pausa/Interruzione". E prendi quello che hai stampato.
Al momento il prodotto ha il rapporto funzionalità/complessità ottimale (dal mio punto di vista). È tempo di condividere.
TL.DR
Ci saranno tutti i tipi di dettagli tecnici più tardi, quindi prima... link "toccare" per gli impazienti.
Attualmente il seguente comportamento è hardcoded:
“Pausa/Interruzione”: torna indietro all'ultima parola, cambia il layout nella finestra attiva (tra 0 e 1) e compone nuovamente.
“Ctrl sinistro senza nulla”: cambia il layout nella finestra attiva (tra 0 e 1).
“Maiusc sinistro senza nulla”: attiva il layout n. 0 nella finestra attiva.
“Shift destro senza nulla”: attiva il layout n. 1 nella finestra attiva.
D'ora in poi ho intenzione di personalizzare il comportamento. Senza feedback, non è interessante (a me va bene comunque). Credo che su Habré ci sarà una percentuale sufficiente di pubblico con problemi simili.
NB Perché nella versione attuale, il keylogger è collegato a "/dev/input/", xswitcher deve essere avviato con diritti di root:
chown root:root xswitcher
chmod +xs xswitcher
Si prega di notare: Il proprietario del file con suid deve essere root, perché chiunque sia il proprietario verrà trasformato in suid all'avvio.
I paranoici (non faccio eccezione) possono clonare GIT e assemblare sul posto. Come quello:
go get "github.com/micmonay/keybd_event"
go get "github.com/gvalkov/golang-evdev"
### X11 headers for OpenSUSE/deb-based
zypper install libX11-devel libXmu-devel
apt-get install libx11-dev libxmu-dev
cd "x switcher/src/"
go build -o xswitcher -ldflags "-s -w" --tags static_all src/*.go
Aggiungi l'avvio automatico a piacere (a seconda del DE).
Funziona, “non richiede porridge” (≈30 secondi CPU al giorno, ≈12 MB in RSS).
dettagli
Ora - i dettagli.
L'intero repository era originariamente dedicato al mio progetto preferito e sono troppo pigro per iniziarne un altro. Quindi tutto ammucchiato (solo in cartelle) e coperto da AGPL (“brevetto inverso”).
Il codice xswitcher è scritto in golang, con inclusioni minime di C. Si presume che questo approccio comporterà il minimo sforzo (finora lo è stato). Pur mantenendo la possibilità di connettere ciò che manca utilizzando cgo.
Il testo contiene commenti su da dove è stato preso in prestito e perché. Perché il codice xneur “non mi ha ispirato”, l’ho preso come punto di partenza loloswitcher.
L'uso di "/dev/input/" presenta sia vantaggi (tutto è visibile, compreso il tasto di ripetizione automatica premuto) che svantaggi. Gli svantaggi sono:
La ripetizione automatica (eventi con codice “2”) non è correlata alla ripetizione con x.
L'input tramite le interfacce X11 non è visibile (questo è il modo in cui funziona VNC, ad esempio).
Hai bisogno di radice.
D'altro canto è possibile iscriversi agli X-Event tramite "XSelectExtensionEvent()". Puoi sbirciare codice xinput. Non ho trovato nulla di simile per Go e l'implementazione approssimativa ha richiesto immediatamente un centinaio di righe di codice C. Mettilo da parte per ora.
L'uscita “inversa” attualmente avviene avvitando la tastiera virtuale. Grazie all'autore di keybd_event, ma l'astrazione è di livello troppo alto e dovrà essere rifatta ulteriormente. Ad esempio, utilizzo il tasto Win destro per selezionare la terza riga. E solo il Win sinistro viene ritrasmesso.
Bug conosciuti
Non sappiamo nulla dell’input “composito” (esempio: ½). Non è necessario in questo momento.
Stiamo giocando la vittoria giusta in modo errato. Nel mio caso, spezza l'enfasi.
Non esiste un'analisi chiara dell'input. Esistono invece diverse funzioni: Compare(), CtrlSequence(), RepeatSequence(), SpaceSequence(). Grazie nsmcan per la vostra attenzione: corretto nel codice e qui. Con una certa probabilità, puoi rilevare bug durante la sostituzione. A questo punto non so “come fare” e accetterei volentieri qualsiasi suggerimento.
(Oh Dio) uso competitivo dei canali (keyboardEvents, miceEvents).
conclusione
Il codice è la procedura più semplice. E stupido come me. Quindi mi lusingo con la speranza che quasi ogni tecnico sarà in grado di portare a termine ciò che vuole. E grazie a ciò, questo prodotto non morirà senza supporto, come la maggior parte solo per divertimento.