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.

Nuovo analogo di Punto Switcher per Linux: xswitcher
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.

In bocca al lupo!

Fonte: habr.com

Aggiungi un commento