atbswp records mouse and keyboard actions and plays them back

Record once, replay as many times as you like

atbswp is described as a minimalist macro recorder, and the tagline is the whole product: literally automate the boring stuff with Python, allowing the user to record his mouse and keyboard actions and reproduce them identically as many times as he wants.

That is a narrower scope than a general automation framework, and the description of the interface matches it. The screenshot in the documentation is a compact window with a record control, and the demo is a short animated gif of an action being captured and replayed.

The tool is Python with a wxPython interface, and the input handling is done with pyautogui and pynput, which the install instructions name on every platform. The project is GPL-3.0 licensed, the primary language is Python, and the topics are keystroke, keystrokes and linux, which tells you the centre of gravity is keyboard and mouse event capture rather than application scripting.

The repository layout has a Python package in atbswp/ and, notably, an atbswp-rs/ directory, which is a Rust implementation of the same idea sitting alongside it. Whether the two are alternatives or a port in progress is not stated in the documentation, so treat the Rust directory as something to look at rather than something to rely on.

The last push was on 2026-10-02, and the tagged releases are old: 0.3.0 from 2021-05-15, v0.2 from 2021-02-20 and v0.1 from 2020-05-12. The project is not archived, so work is continuing on the branch, but there has been no release in five years.

The use cases start with game farming and get broader from there

The use case section is written in the first person, and the honesty about the starting point is what makes it useful.

The author has mainly used it to automate gold, point and XP farming in games. And then the list of other things it could do. Automate a demo during a conference, for example. Automate UAT in the devops process, as long as you are making something with a GUI. Download and save individual responses from Google Forms in PDF format with names based on some form field.

The third of those is the most interesting, because it is the case where a recorder beats a script. Downloading form responses as PDFs with generated filenames is a job that involves reading a page, clicking through a list, and saving with a derived name. A macro recorder captures that once, including the fiddly parts, and replays it. Writing it as a script means dealing with the form's HTML and its PDF endpoint, which is more work and more fragile.

The conference demo case points at the same thing. A repeated action in a live demo is exactly what you cannot afford to have fail because a network call was slow, and a local macro that replays recorded input has no network dependency at all.

The common thread across all three is that the target is a GUI, and the automation does not need to understand the application. That is the trade the tool makes: it does not survive layout changes and it does not know what it is doing, but it needs no cooperation from the application and no API.

The author also invites contact, with a GitHub handle given in an obfuscated form, and asks for a PR or a demo video with bonus points for the latter.

Four platforms, four slightly different install paths

There are two ways in. You can download the installer or archive for your operating system, currently Windows and Linux, from the releases page. Or you build from source, and the four instructions differ more than you would expect.

On Fedora:

sudo dnf install python3-wxpython4 python3-xlib python3-tkinter
git clone https://github.com/RMPR/atbswp.git && cd atbswp
make prepare-dev
make run

Fedora is the only platform with a Makefile in the documented flow, with a prepare-dev target and a run target.

On Debian:

sudo apt install git python3-dev python3-tk python3-setuptools python3-wheel python3-pip python3-wxgtk4.0
git clone https://github.com/RMPR/atbswp.git && cd atbswp
python3 -m pip install pyautogui pynput --user
python3 atbswp/atbswp.py

On Manjaro and Arch, which is also available on the AUR:

sudo pacman -S tk python-wxpython
python3 -m pip install pyautogui pynput --user
git clone https://github.com/RMPR/atbswp.git && cd atbswp
python3 atbswp/atbswp.py

And on Windows:

git clone https://github.com/rmpr/atbswp
cd atbswp\
pip install wxPython pyautogui pynput
python atbswp\atbswp.py

The pattern across the three Unix variants is the same: the system package manager provides the wxPython GUI toolkit and the X11 libraries, and pip installs the two input libraries into the user site. The Windows path has no system package step at all, because pip handles wxPython there.

The X11 dependency on the Unix platforms is not an accident of packaging, it is the same issue described in the known issues.

Linux support is Xorg only, and the fix is a GDM config change

The known issues section is short and it is the most important thing in the documentation for a Linux user.

On Linux, this only works with Xorg, with Wayland support coming soon, and for now you have to enable Xorg. The command given is:

sudo sed 's/#WaylandEnable=false/WaylandEnable=false/' /etc/gdm/custom.conf -i # on Gnome

That edits the GDM display manager configuration to switch the session from Wayland to Xorg, and the -i flag makes the edit in place. There is also a link to the Fedora documentation on configuring Xorg as the default GNOME session.

The reason is in the dependency list rather than the prose. The Unix installs pull in `python3-xlib` on Fedora and `python3-wxgtk4.0` on Debian, and Xlib is an X11 protocol library. A macro recorder that hooks global keyboard and mouse events needs access to the input devices, and under Xorg that is what XTEST and Xlib give you, while under Wayland the compositor mediates input and an application cannot silently capture it.

So the practical guidance is that on a modern Linux desktop you will be running a GNOME session on Xorg, which means signing out of a Wayland session, and you lose some of what Wayland offers in the process. On Windows there is no equivalent restriction, since the capture APIs there are available to any desktop application.

The stated intent to support Wayland eventually is worth believing with a grain of salt, because it depends on the input-capture portals rather than on the recorder's own code, and no timeline is given.

Where this sits against a script or a proper automation tool

The comparison that matters is with the alternative of scripting the task, and the difference is a trade you have to make deliberately.

A script, whether it is pyautogui code you wrote or a Playwright or Selenium test, knows what it is doing. It queries the DOM, it waits for a specific element, it fails loudly when the page changes. That is a real advantage in anything you intend to run repeatedly over months, because a script that breaks tells you what broke.

A recorded macro knows nothing. It replays input events at recorded positions and timings, so it breaks silently when the layout changes, and it is affected by anything that moves the window or changes the focus. It is also affected by the machine being slower or faster than the machine that recorded it, if the replay depends on timing.

For a one-off or a demo, that does not matter. For a production UAT step, it is a real problem, and the documentation's own example of automating UAT is the case where the trade is least favourable. The README's other examples, a conference demo and a form-response download, are cases where a macro is a good fit because the task is stable and the alternative is more code than the task deserves.

The second comparison is with a macro recorder built into the desktop, which many Linux desktops ship with. Those are typically more polished and handle the same capture and replay, so the reason to prefer atbswp is that it is a small readable Python program you can extend, and the reason not to is that it has had no release since 2021.

The project is a single-developer tool with a contributing guide, a demo, a Telegram channel for news and polls, and a donation link. For what it is, that is a reasonable amount of scaffolding, and the honest framing is that it is a weekend project that people have found useful for years.

Editorial conclusion

Adopt atbswp if you want to automate a repetitive GUI workflow and would rather record the actions than write a script for them, since that is the whole design. Skip it if you need it to work under Wayland, because the documentation states Linux support is Xorg only and that you have to enable Xorg, and if you need unattended scheduling or a maintained release, since the last tagged version is from 2021. Verify first that your display server is Xorg on Linux, that the Python GUI and input packages install on your distribution, and that the application you want to automate does not need administrator rights, since a recorder that replays a click is running with whatever rights you gave it.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. RMPR/atbswp on GitHub