Actiona 3: a desktop automation tool you script in JavaScript

Simulated input, screen watching, and a scripting escape hatch

Actiona is described as an automation tool that lets you execute many actions on your computer, such as emulating mouse clicks, key presses, showing message boxes and editing text files. The actions are grouped into five families in the README. Device emulation covers writing text, pressing a key, moving the mouse cursor as a point or a path, clicking somewhere on the screen, rotating the mouse wheel and waiting for a key to be pressed. System interaction runs a command, kills a process, displays a notification, waits for a pixel color on the screen, restarts or stops or locks the computer, opens a URL, plays a sound, finds an image on the screen and uses text to speech. Windowing actions show a message box, enter data, wait for a window, and close, move or resize a window. Data manipulation reads and writes text files, binary files, INI files, the registry, the clipboard and environment variables, and can copy files, download files and send an e-mail. Flow actions pause, run JavaScript, jump to a line or label, loop, stop, set and read variables, wait for a time or a variable, write to the console and begin, end or call a procedure.

JavaScript in every parameter field is the design decision

The README states that each action has parameters, and that JavaScript can be written in every field and will be run when the action is executed. That single sentence explains the tool's character better than the feature list does. Most GUI automation tools give you a fixed set of fields with a dropdown of choices, and the moment you need a condition or a computed value you are stuck. Here every parameter is a program, so a wait duration can be the result of a calculation, a path can be built from a variable, and a command line can be assembled at run time. The alternative authoring route the README mentions is the EcmaScript programming language, which is JavaScript, for more customization when the visual editor stops being enough. There is also a plain do nothing action, which the README notes is more useful than you would think, a pause action, and an explicit stop action, so a script can be written to bail out cleanly.

Waiting for pixels and images rather than fixed sleeps

Among the system interaction actions, two stand out as the ones that separate a usable automation script from a flaky one. One waits for a pixel color on the screen and another finds an image on the screen. Both are condition checks against the live desktop, which means a script can wait for the application to reach a known state instead of sleeping for a fixed number of seconds. Combined with the wait for a window action in the windowing family and the wait for a key to be pressed in the device family, the tool offers four distinct kinds of wait: a time or date, a variable, a window, and a key. The pixel and image waits are the ones that need real caution, because they depend on theme, scaling and rendering. A pixel color that matches on your machine may never match on a machine with a different theme or a different display scale, and an image search depends on the fonts and antialiasing of the interface it was captured from.

The source layout shows a Qt desktop app with a separate runner

The repository is written in C++ and built with CMake, and the top-level entries show a project with a clear separation between the editor and the execution side. There is an actiona directory that holds the GUI application, an actions directory for the action implementations, actiontools for the shared tooling, an execution directory for the runtime, an actexec directory for the standalone executor, a runner directory, an installer directory, a doc directory for documentation, and scripts and tools directories. Having both an actiona directory and an actexec directory is the interesting part: it implies the application can hand a script to a separate execution component rather than only running it inside its own window. The build is set up for more than one compiler, with GitHub workflow badges for a Linux gcc build and a Windows MSVC build. There is also a .gitmodules file, so some dependencies arrive as submodules, and a CHANGELOG.md at the root.

Getting it: the project site, the Discord and the tag releases

The README does not give an installation command, and that is consistent with the shape of the project. It is a Qt desktop application distributed as a native build per platform rather than as a library from a package registry, so the guidance is to visit actiona.tools, which is the homepage, and the Discord server linked from the README for more information. The release history is visible in the tags: v3.11.4 on 2026-05-13, v3.11.3 on 2026-05-02 and v3.11.2 on 2026-04-19, a steady patch cadence on a stable 3.11 line. The repository is not archived, and the last push was on 2026-05-13. The README also spells out where the money goes, which is unusual and useful information: the project says contributions will pay for the rental of the dedicated server hosting its updater and installers, around 37 euro per month, and for the code signing certificates required on Windows, at least a few hundred pounds.

GPL-3.0 with a stack of differently licensed components

Actiona is licensed under the GNU GPL, and the README is careful to add that it includes code and other resources licensed under other terms. The list is specific. QDarkStyleSheet, the dark theme, is MIT for source code and Creative Commons Attribution International 4.0 for its images. QHotkey is BSD-3-Clause, breakpad is under the BSD licence, mINI is MIT, the Qxt library is Common Public License version 1 and GNU/LGPL version 2.1, the Crystal Clear icons are GNU/LGPL, and qtjsapi is MIT. For anyone packaging or redistributing Actiona, that list is the checklist, and the mixed licensing means the combined work is governed by the GPL while individual bundled pieces keep their own terms. Read the LICENSE file in the repository root for the actual text, since a summary is not what you would want to rely on when shipping a build. Note also that a GPL-3.0 application is a poor fit for embedding in a proprietary product, whatever the individual libraries allow.

Editorial conclusion

Actiona fits someone automating a desktop application that offers no API, or stitching together a small workflow across windows, the clipboard, files and the registry. It does not fit a team that needs unattended headless runs on a server, since the whole model is a visible desktop session with simulated input, and it does not fit anyone who cannot ship GPL-3.0 licensed software. Verify first that the target application tolerates synthetic input, since mouse emulation is a different thing from an API call, and read the README's third-party licence list before you redistribute a build.

Frequently asked questions

Official sources

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