Documentation; add an initial lag before typing, to help with mod-key release;
robotgo upstream accepted PRs: removing replacement
Implements BEEP
Quasiauto performs autotyping and interactive autotyping for kpmenu. It's meant to do three things:
[kpmenu](https://github.com/AlessioDP/kpmenu)
to use xdotool
on Linux.Quasiauto started from a ticket to add autotype to kpmenu. The quasi-auto mode is an attempt to improve on autotype in a way that minimizes user interaction while making login data entry more robust than autotype, which is fragile in the face of unnecessarily involved Javascript login pages.
Ignoring the dependencies for Xorg interaction (robotgo), there is (relatively) little code and should be easy to audit, even for non-programmers. In particular, no network calls are made and this program should run when network jailed.
Binaries can be downloaded here. Quasiauto can be compiled from source with either go install
:
go install ser1.net/quasiauto
or by cloning and building yourself:
hg clone https://hg.sr.ht/~ser/quasiauto/
cd quasiauto
go build ./cmd/quasiauto
There's only one argument: -ms <millisecs>
, which defines the amount of "lag" between simulated key presses. It is set to default at 50. All other data, it parses from STDIN.
The intended use is as a utility for kpmenu. The idea is that you install quasiauto
and then bind a hotkey to call kpmenu --autotype
; kpmenu farms out the actual autotyping part to quasiauto. All in all, it would look like this:
~/.config/kpmenu/config
:[executable]
CustomAutotypeWindowID="quasiauto -title"
bindsym $mod+r exec /home/ser/.local/bin/kpmenu
bindsym $mod+t exec /home/ser/.local/bin/kpmenu --autotype
Now you can trigger autotyping by pressing MOD-t
on a browser (or other) login window. This depends on having the correct window ID and key sequences set up in the KeePass DB, of course.
A way of testing this is using zenity. Say you have a sourcehut account, and a corresponding entry named Sourcehut
in your KeePassDB. Run the following:
zenity --forms --add-entry "Username" --add-password "Password" --add-entry "TOTP" --title "Log in to Sourcehut"
Make sure the Username
field is selected and press your MOD-t
key, and if everything is configured correctly you should get autotyped credentials into the Zenity window.
quasiauto can autotype on behalf of any program that sends it data in the correct format.
On the kpmenu side, there are a few options that can make autotype work better for you:
--autotypealwaysconfirm Always confirm autotype, even when there's only 1 selection
This forces kpmenu to always ask to start autotype, even if a unique match is made. Without this, autotype can start immediately and -- possibly -- before you've released all of the MOD keys you used to launch autotype, which is less than ideal. I hope to find a way to ensure no keys are pressed before starting autotype, but I don't have a way of doing that right now, so this is a good option to use.
--autotypeusersel Prompt for autotype entry instead of trying to detect by active window title
The kpmenu patch runs a program to find the active window. If you want to disable that, and always select the entry yourself, use this option.
--customAutotypeTyper string Custom executable for autotype typer (default "quasiauto")
Set this to quasiauto -ms 100
to change the type delay.
--customAutotypeWindowID string Custom executable for identifying active window for autotype (default "quasiauto -title")
quasiauto can identify the active window, but you could also use, e.g. xdotool getwindowfocus getwindowname
. Set this option to change how window titles are selected.
VKEY is not implemented, as it's windows specific and I don't have access to a Windows computer.
I haven't found a way to ensure that no modifier keys are being held when autotype starts. Consequently, there's a risk that whatever hotkey trigger is set up might mean a meta key is still being held when typing starts. This is Not Good™, and avoiding this means you may have to insert a small delay (500ms) before executing the program. In my case, the various delays introduced by forking, parsing input, and so on is enough that I don't have a problem if I don't linger on the modifier; however, YMMV. I'll add a safety measure, if I can find a way to read the keyboard state and ensure it's clear in a platform-independent way.
Discussion of the feature is in a github ticket. The design is meant to
Quasiauto reads STDIN and expects (quasi-BNF):
sequence ::= cmds "\n"
cmds ::= cmds "{" cmd "}" | ""
cmd ::= key | "TAB" | "ENTER" | "TOTP" | "DELAY" digits
digits ::= [0-9]+
fields ::= fields "\n" field | field
field ::= key "\t" value
key ::= [^\n\t]+
value ::= [^n]+
For example:
{USERNAME}{TAB}{PASSWORD}{TAB}{TOTP}{ENTER}
Username John B.
Password BooTAY, BooTAY
OTP 1328765
Coverage Parse benchmark Exec benchmark
v0.2.0 94% 12734 10801
v0.1.0 78% 8035