PyMacroRecord and the case for a macro recorder that is just a tkinter window

Record, then replay, with the interface in between

PyMacroRecord is a macro recorder whose interface is a tkinter window, and the project describes that plainly as the reason it is easy to use.

The workflow is three steps. To start recording you press the red button. From there you move your mouse, click and type, and everything is recorded, with a choice of what gets recorded. To stop, you click the black square. To play a recording you click the green play icon, and to stop the playback you press the f3 key, by default.

That is the whole interaction model, and the coloured buttons are how the documentation describes it rather than how the interface is necessarily laid out, which is the kind of detail that usually gets lost in a manual.

The project describes itself as free and open source, with no ads and no premium purchase, and the feature list repeats the point: free, no limitations, no premium purchase. That is worth noting as a positioning choice rather than a technical one, because macro recorders are a category where a free tier with a recording limit is common, and the author is clearly making a point of not doing that.

The primary language is Python, the licence is GPL-3.0, and the homepage is pymacrorecord.com. The default branch is main, and the last push to the repository was on 2026-10-18 with v1.4.6 published on 2026-10-10.

The feature list is short and every entry is a different kind of control

Reading the feature list is the fastest way to understand what the application is for, and the entries group into three kinds.

The capture side covers what gets recorded: you can choose from recording mouse movement, click and keyboard input, and the project mentions smooth recording of the mouse as a separate capability. The playback side covers repetition and pacing, with infinite repeat, change speed, interval, for, and schedule listed as separate items. The management side covers save, load and sharing, along with universal files that work with json.

The universal json file is the most interesting of these for anyone who has used a macro recorder before. It means a recording is a text file you can read, diff and check into a repository, rather than a binary blob in a format only one program understands. For a macro that runs a production script, or a macro shared between two people, that difference matters more than the feature list suggests.

Two smaller features are worth calling out. There are after-playback options, with standby or shutdown the computer given as examples, which is a small automation of the kind that usually needs a separate scheduler. And there are custom hotkeys for starting a record and stopping it, starting playback and stopping it, which matters once you have more than one macro.

The demonstration section shows the application running on Windows and on Linux under X11.

Running from source is four steps, and the Tkinter catch

The source instructions are laid out as a sequence, and the Linux caveat is the one worth reading before anything else.

You install Python, download the last source code release, extract it wherever you want, and open a terminal and type the cd command to the software folder. Then the dependencies:

pip3 install -r requirements.txt

On Linux you might need to install Tkinter manually, with the command given as sudo apt install python3-tk or the equivalent for your distro. And on Linux the app requires an X11 session, with Wayland not supported. Then you run it:

cd src && python3 main.py

That X11 requirement is the defining constraint of the project, and it is repeated in the build section with the note that the AppImage runs in X11 mode only and Wayland is not supported. It is a consequence of the design rather than an accident: a macro recorder needs to see and inject input events, and on Linux the two display servers expose that differently. A user on a modern GNOME or KDE session running Wayland will find the application will not start properly, and the fix is to log into an X11 session rather than anything in the application.

The requirements list is short and tells you what the application actually uses. Pillow at 12.3.0, pynput at 1.8.2 for the input handling, requests at 2.34.2, pystray at 0.19.5 for the system tray, and on Windows only win10toast at 0.9 and pyinstaller at 6.21.0. cx-Freeze at 8.6.4 is there for the Linux and folder builds.

Three build targets, two build tools, and a portable Windows option

The build section covers three platforms with different tools, and the differences are practical rather than cosmetic.

The project uses cx_Freeze to build the application. On Linux the output is an AppImage, with the requirements listed as cx_Freeze, imagemagick through its convert command, and curl, and the build is a single script:

./build.sh

That produces a PyMacroRecord-x86_64.AppImage, or the current architecture, in the project root. The name is telling: an AppImage is a single file that runs without installing anything, which suits an application that has to inject keyboard and mouse events and therefore has to run on the desktop session directly.

On Windows there are two routes. The folder build needs cx_Freeze and runs:

python setup_cx.py build

with the output in the build/ directory. The portable build needs PyInstaller instead and runs a batch file:

build.bat

with the output in the dist/ directory. So a Windows user who wants one executable to copy around uses PyInstaller, and one who wants a folder to distribute uses cx_Freeze, and the repository carries both build.bat and build.sh plus setup_cx.py and setup.iss for the installer.

The requirements file shows the build toolchain explicitly: cx-Freeze at 8.6.4 is a direct dependency alongside pyinstaller at 6.21.0, but pyinstaller is marked as Windows only in the same way win10toast is. That conditional marking is a small sign of care, since it keeps a Windows-only build tool out of Linux environments.

Translations are contributed, which says something about the audience

The special thanks section is a list of translations, and it is longer than the contributor list for the code itself.

The named credits cover the Italian and Brazilian-Portuguese translation, the Simplified Chinese translation, the Turkish, German, Dutch, Spanish, Bulgarian, Russian, Korean and Esperanto translations, plus one person credited for code enhancement and another for playtesting.

Ten languages is a real audience, and for a macro recorder it is a slightly unusual one. The application records and replays mouse and keyboard input, which means it is a tool for people automating repetitive work on a desktop, and the translation list suggests that community is broad and international.

It also tells you something about the maintenance model. The project is a single-maintainer application with a stream of translation contributions, and the funding section asks for small donations, saying they really help, and explains that a donor's name appears in a Donors section in the application and among the last five donors on the website.

The repository layout is consistent with that: src/ for the application, requirements.txt, build.sh and build.bat for the two platform builds, setup_cx.py and setup.iss for the Windows packaging, a TUTORIAL.md alongside the project description, and a .github/ directory for the workflows.

Where PyMacroRecord is the wrong choice

The first case is a Wayland desktop on Linux. The application requires an X11 session, the documentation repeats it for the source build and again for the AppImage, and the project does not claim otherwise. That is a hard stop for a user whose session manager defaults to Wayland, and it is the kind of thing that will not be fixed by configuration.

The second is anything that needs a dependable macro format. A macro recorder that stores json is a recorder for your own reuse and for sharing with people who have the same application. It is not a workflow format, and there is no versioning, no conditional branching and no failure handling in what is a sequence of input events.

The third is a machine without a desktop session. The application is a tkinter GUI with a system tray, so it needs a graphical session, which rules out a headless server and a container that is only running a cron job. The after-playback options for standby and shutdown are aimed at a desktop that is about to be used again, not at a server.

The fourth is a team that needs recorded macros to be reproducible across machines. A macro records what happened on one machine, with one keyboard layout, one screen resolution and one application configuration, and replaying it somewhere else is a hope rather than a guarantee.

Editorial conclusion

PyMacroRecord suits someone who repeats the same mouse and keyboard sequence often enough to be tired of doing it, and who wants a recorder that stores plain JSON rather than a proprietary format, since the file format is documented as universal and the recording format is inspectable. It does not suit a Wayland user on Linux, because the application requires an X11 session and the documentation says so twice. Before you install it, check whether the appimage and portable builds cover your platform, and note that the last push was on 2026-10-18 with v1.4.6 published on 2026-10-10.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. LOUDO2/PyMacroRecord on GitHub
3. Project website
4. README
5. Releases