ProHoster > Blog > administrasie > Nuwe analoog van Punto Switcher vir Linux: xswitcher

Nuwe analoog van Punto Switcher vir Linux: xswitcher

Die einde van xneur-ondersteuning het my die afgelope ses maande leed besorg. (met die koms van OpenSUSE 15.1 op my rekenaars: met xneur geaktiveer, verloor vensters fokus en flikker snaaks betyds met sleutelbordinvoer).

“O, verdomp, ek het weer die verkeerde uitleg begin tik” - in my werk gebeur dit onbetaamlik gereeld. En dit voeg niks positiefs by nie.

Nuwe analoog van Punto Switcher vir Linux: xswitcher
Terselfdertyd kan ek (as ontwerpingenieur) redelik duidelik formuleer wat ek wil hê. Maar ek wou (eers van Punto Switcher, en dan, danksy Windows Vista, uiteindelik oorskakel na Linux, vanaf xneur) presies een ding. Nadat u besef het dat die gemors op die skerm in die verkeerde uitleg is (dit gebeur gewoonlik aan die einde van die tik van 'n nuwe woord), trap op "Pouse/Break". En kry wat jy gedruk het.

Op die oomblik het die produk die optimale (uit my oogpunt) funksionaliteit/kompleksiteit verhouding. Dit is tyd om te deel.

TL.DR

Daar sal later allerhande tegniese besonderhede wees, so eers - skakel "om aan te raak" vir die ongeduldige.

Tans is die volgende gedrag hardgekodeer:

  • “Pause/Break”: spasieer die laaste woord terug, verander die uitleg in die aktiewe venster (tussen 0 en 1) en skakel weer.
  • "Linker Ctrl sonder iets": verander die uitleg in die aktiewe venster (tussen 0 en 1).
  • "Links skuif sonder iets": skakel uitleg nr. 0 in die aktiewe venster aan.
  • "Regskuif sonder iets": skakel uitleg nr. 1 in die aktiewe venster aan.

Van nou af beplan ek om die gedrag aan te pas. Sonder terugvoer is dit nie interessant nie (ek is in elk geval goed daarmee). Ek glo dat daar op Habré 'n voldoende persentasie van die gehoor met soortgelyke probleme sal wees.

NB Omdat in die huidige weergawe is die keylogger geheg aan "/dev/input/", xswitcher moet geloods word met wortelregte:

chown root:root xswitcher
chmod +xs xswitcher

Aandag: Die eienaar van die lêer met suid moet root wees, want wie ook al die eienaar is, sal in suid verander word by opstart.

Paranoïede (ek is geen uitsondering nie) kan van kloon GIT en monteer op die terrein. Soos dit:

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

Voeg autostart by na smaak (afhangende van DE).

Dit werk, "vra nie vir pap nie" (≈30 sekondes SVE per dag, ≈12 MB in RSS).

besonderhede

Nou - die besonderhede.

Die hele bewaarplek is oorspronklik aan my troeteldierprojek gewy, en ek is te lui om nog een te begin. Dus, alles word opgestapel (net in dopgehou) en gedek deur AGPL (“omgekeerde patent”).

Die xswitcher-kode is in golang geskryf, met minimale insluitings van C. Daar word aanvaar dat hierdie benadering die minste moeite sal meebring (tot dusver het dit gedoen). Terwyl die vermoë behou word om te verbind wat ontbreek met behulp van cgo.

Die teks bevat kommentaar oor waar dit ontleen is en hoekom. Omdat die xneur-kode "het my nie geïnspireer nie", ek het dit as 'n beginpunt geneem loloswitter.

Die gebruik van "/dev/input/" het beide sy voordele (alles is sigbaar, insluitend die gedrukte outo-herhaal sleutel) en nadele. Die nadele is:

  • Outo-herhaling (gebeurtenisse met kode “2”) korreleer nie met herhaling met x nie.
  • Invoer deur X11-koppelvlakke is nie sigbaar nie (dit is byvoorbeeld hoe VNC werk).
  • Benodig wortel.

Aan die ander kant is dit moontlik om in te teken op X-geleenthede via "XSelectExtensionEvent()". Jy kan loer na xinvoer kode. Ek het nie so iets gekry nie, en die rowwe implementering het dadelik honderd reëls C-kode geneem. Sit dit vir eers eenkant.

Die "omgekeerde" uitset word tans gemaak deur die virtuele sleutelbord te skroef. Dankie aan die skrywer van keybd_event, maar die abstraksie daar is te hoë vlak en sal verder oorgedoen moet word. Ek gebruik byvoorbeeld die regte Win-sleutel om die 3de ry te kies. En net die linker Win word teruggestuur.

Bekende goggas

  • Ons weet niks van "saamgestelde" insette nie (voorbeeld: ½). Dit is nie nou nodig nie.
  • Ons speel die regte Wen verkeerd. In my geval breek dit die klem.
  • Daar is geen duidelike insetontleding nie. In plaas daarvan is daar verskeie funksies: Vergelyk(), CtrlSequence(), RepeatSequence(), SpaceSequence(). Dankie nsmcan vir jou sorg: het dit in die kode en hier reggestel. Met 'n sekere waarskynlikheid kan jy foute vang wanneer jy vervang.
    Op hierdie stadium weet ek nie "hoe om" nie en sal enige voorstelle verwelkom.
  • (O God) mededingende gebruik van kanale (keyboardEvents, miceEvents).

Gevolgtrekking

Die kode is die eenvoudigste prosedure. En dom soos ek. So, ek vlei myself met die hoop dat byna enige tegnikus sal kan voltooi wat hy wil. En danksy hierdie, sal hierdie produk nie vergaan sonder ondersteuning, soos die meeste net-vir-pret nie.

Sterkte!

Bron: will.com

Voeg 'n opmerking