Het stopzetten van de ondersteuning voor xneur heeft me de afgelopen zes maanden veel leed bezorgd. (met de komst van OpenSUSE 15.1 op mijn desktops: wanneer xneur ingeschakeld is, verliezen vensters de focus en flitsen leuk in de pas van de toetsaanslagen.).
«Ah, verdorie, ik ben weer in de verkeerde indeling begonnen te typen» — dit komt in mijn werk ongepast vaak voor. En dat voegt geen positieve sfeer toe.

Tegelijkertijd kan ik (als ontwerper) vrij duidelijk formuleren wat ik wil. En wat ik wilde was (eerder van Punto Switcher, en daarna, bedankt aan Windows Vista, definitief overgestapt op Linux, van xneur) precies één ding. Zodra ik me realiseerde dat mijn scherm onzin laat zien in de verkeerde indeling (dit gebeurt meestal aan het einde van het typen van een nieuw woord), de 'Pause/Break' indrukken. En krijgen wat ik getypt had.
Op dit moment heeft het product een optimale (uit mijn perspectief) verhouding tussen functionaliteit en complexiteit. Het is tijd om te delen.
TL.DR
Hierna komen allerlei technische details, dus eerst — voor de ongeduldigen.
Op dit moment is het volgende gedrag hardcoded:
- «Pause/Break»: wist (Backspace) het laatste woord, schakelt de indeling in het actieve venster (tussen 0 en 1) en typt nogmaals.
- «Linker Ctrl zonder iets»: schakelt de indeling in het actieve venster (tussen 0 en 1).
- «Linker Shift zonder iets»: activeert in het actieve venster indeling №0.
- «Rechter Shift zonder iets»: activeert in het actieve venster indeling №1.
Vanaf dit punt ben ik van plan het gedrag te personaliseren. Zonder feedback is het niet interessant (ik ben er al tevreden mee). Ik vermoed dat er op Habr een voldoende percentage van het publiek met soortgelijke problemen te vinden is.
N.B. Aangezien de huidige versie van de keylogger aan "/dev/input/" is gekoppeld, moet xswitcher met rootrechten worden gestart:
chown root:root xswitcher
chmod +xs xswitcherLet op: de eigenaar van het bestand met suid moet root zijn, want wie de eigenaar is, die wordt suid bij het starten.
Paranoïden (waaronder ikzelf) kunnen het klonen vanuit en lokaal bouwen. Ongeveer zo:
go get "github.com/micmonay/keybd_event"
go get "github.com/gvalkov/golang-evdev"
### X11 headers voor OpenSUSE/deb-gebaseerd
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
Auto-start naar smaak toevoegen (afhankelijk van DE).
Werkt, "eisen geen pap" (≈30 seconden CPU per dag, ≈12 MB in RSS).
Details
Nu — details.
Het hele repository was oorspronkelijk gewijd aan mijn pet-project, en het opzetten van een nieuw project voelt nu te lui aan. Dus, alles is samengevoegd (gewoon in mappen) en bedekt met AGPL ('patent omgekeerd').
De code van xswitcher is geschreven in golang, met minimale inbreng van C. De verwachting is dat deze benadering de minste arbeidsinspanningen vereist (tot nu toe klopt dat). Het behoudt de mogelijkheid om ontbrekende elementen via cgo aan te sluiten.
In de tekst zijn opmerkingen geplaatst over waar ik wat heb geleend en waarom. Omdat de code van xneur me 'niet inspireerde', heb ik als uitgangspunt gekozen voor .
Het gebruik van "/dev/input/" heeft zowel voordelen (alles is zichtbaar, inclusief de ingedrukte toets met herhaling) als nadelen. De nadelen zijn als volgt:
- Herhaling (gebeurtenissen met code '2') correleert niet met herhaling van X.
- Er is geen invoer zichtbaar via X11-interfaces (bijvoorbeeld VNC werkt zo).
- Rootrechten zijn nodig.
Aan de andere kant is het mogelijk om je te abonneren op X-gebeurtenissen via 'XSelectExtensionEvent()'. Dit kan bekeken worden in Voor go heb ik niets dergelijks gevonden, en de ruwe implementatie leidde direct tot een honderdtal regels C-code. Ik heb het voorlopig aan de kant geschoven.
De 'terug' uitvoer is voorlopig gedaan door een virtueel toetsenbord te koppelen. Dank aan de auteur van keybd_event, maar daar is de abstractie te hoog en zal het verder moeten worden herschreven. Bijvoorbeeld, mijn rechter Win-toets selecteert de derde rij. En 'terug' wordt alleen de linker Win getransleerd.
Bekende fouten
- We weten niets over 'composite' invoer (voorbeeld: ½). Momenteel is dit niet nodig.
- We reproduceren de rechter Win-onjuist. In mijn geval verstoort dit de plaatsing van accenten.
- Er is geen duidelijke analyse van de invoer. In plaats daarvan zijn er enkele functies: Compare(), CtrlSequence(), RepeatSequence(), SpaceSequence(). Dank voor de aandacht: ik heb het in de code en hier gecorrigeerd. Met een bepaalde kans kunnen er bugs optreden bij vervangingen.
Op deze plek weet ik niet 'hoe het moet' en sta open voor alle voorstellen. - (O verschrikkelijk) concurrent gebruik van kanalen (keyboardEvents, miceEvents).
Conclusie
De code is de eenvoudigste procedurele. En zo dom als ik. Dus, ik troost mezelf met de hoop dat vrijwel elke techneut het gewenste kan aanvullen. Dit product zal dankzij dat niet verdwijnen zonder ondersteuning, zoals de meeste projecten die gewoon voor de fun zijn.
Veel succes!
Bron: habr.com
