Transmission Remote GUI: a native desktop client for a Transmission daemon

What Transgui actually is, and who it is for

Transgui is not a BitTorrent client in the sense of something that downloads torrents itself. It is a front-end. The README describes it as a cross-platform front-end that remotely controls a Transmission daemon via its RPC protocol, and the repository ships an rpc.pas and an rpc-spec.txt alongside the UI forms, which matches that description. The daemon does the downloading; Transgui draws the window, sends RPC calls and renders the answers.

That distinction decides who the tool is for. If you run transmission-daemon on a home server, a NAS or a seedbox, and you want to manage it from a desktop machine, Transgui is aimed at you. The README compares it directly to the built-in Transmission web interface, claiming it is faster and has more functionality. The feature list is where that claim lives: selecting which files to download, choosing file priority, viewing details about connected peers, full per-torrent information and per-torrent options. Those are the operations a web UI often makes tedious.

The interface is deliberately familiar. The README calls it uTorrent-like, and the fixed hotkeys reinforce that: Alt+1 through Alt+8 switch between All Torrents, Downloading, Completed, Active, Inactive, Stopped, Error and Waiting, while Alt+G, Alt+K, Alt+P and Alt+F jump to the General, Trackers, Peers and Files tabs of the info pane. If you have used a desktop torrent client before, the layout will not need explaining.

How the RPC front-end is put together

The architecture visible in the repository is a single native application built with Lazarus RAD and the Free Pascal compiler, with platform-specific units where needed (maclocale.pas for macOS locale handling, for example) and a synapse/ directory for the networking layer. The RPC layer is not generated from a schema; rpc-spec.txt sits next to rpc.pas as reference material for the protocol the code speaks.

The data flow is one-directional in the sense that matters: Transgui holds connection settings, opens a session against the daemon, and then polls and issues commands. Everything the user sees about a torrent, whether that is peer lists, tracker status or file progress, arrives through the daemon's RPC endpoint. Nothing is stored locally except configuration, which is why the program is small and why it can be pointed at a different daemon by changing a host and port.

Two details in the README show how seriously the configuration side is treated. First, portable mode: if the program finds a transgui.ini file in the same folder as the binary, it stores all configuration and data files in the program's folder instead of the user profile. Second, the --home=<home_dir> command line parameter, which sets a home directory for the program and, per the README, takes precedence over portable mode and the default user-profile location. The README notes you can run multiple instances by giving each a different home directory. That is a real capability, not a cosmetic one: it lets one machine hold separate profiles for separate daemons.

The README also admits that not everything is reachable from the interface. It points to advanced parameters in transgui.ini that cannot be modified via the GUI and links two issues, #924 for file manager and shortcuts, #1020 for the rest. Treat the GUI as the common path, not the complete surface.

Installing Transgui on Linux, Windows and macOS

The README lists precompiled binaries on the GitHub Releases page for supported Linux architectures, and states they require glibc 2.34 or newer. Download and extract the archive for your architecture, then run the transgui binary, making the file executable if needed. The README suggests creating a desktop or menu shortcut afterwards.

chmod +x transgui
./transgui

On Windows the README recommends the portable zip over the installer, because the archive is much smaller. Extract it anywhere and run transgui.exe. One caveat is spelled out: a portable release does not carry SSL/TLS support by default. You either install the OpenSSL 3.x Light package matching your build architecture, or copy the project's OpenSSL DLLs from setup/win/openssl for 32-bit or setup/win_amd64/openssl for 64-bit into the same folder as transgui.exe. Missing MSVCR120.dll means you need the Microsoft Visual C++ 2013 Redistributable; missing VCRUNTIME140.dll means the latest v14 Redistributable. The README warns against mixing files from different releases or architectures.

Chocolatey users have a shorter path:

choco install transgui

On macOS the README gives two routes. Without a package manager, download the disk image, mount it, and either run the application directly or drag it to your disk or Applications folder. With Homebrew installed:

brew install --cask transmission-remote-gui

Building from source is the harder path and assumes a working Lazarus and Free Pascal setup. After cloning or extracting the source, the README gives two commands, one to build the resource file and one to build the application, both taking a Lazarus directory path:

lazbuild -B transgui.lpi --lazarusdir=<lazarus_dir>
make LAZARUS_DIR=<lazarus_dir>

A third command, make LAZARUS_DIR=<lazarus_dir> zipdist, produces a release archive in the Release sub-folder. Once the program is running, the first real use is to point it at your daemon: fill in host, port and credentials in the connection dialog, and the torrent list loads from the RPC endpoint. You can also hand it a torrent directly, since the README states a path to a .torrent file or a magnet link can be passed as a command line parameter and the program will add it. The -hidden flag starts the program with only its tray icon visible.

Where Transgui is the wrong tool

The first limitation is structural: Transgui cannot do anything the daemon cannot. If your Transmission daemon is not running, not reachable, or not configured to accept RPC connections, the interface shows you nothing useful. There is no local torrent engine to fall back on. Anyone who wants a single program that both downloads and manages torrents should look elsewhere; the README's own framing, a front-end to remotely control a daemon, rules that out.

The second is packaging. The most recent release listed for this repository is v5.18.0 from 2019-10-12, with v5.17.0 before it in June 2019 and v5.16.0 in December 2018. The repository itself is not archived and was pushed to on 2026-09-13, so source activity continues, but a reader who wants a ready binary is depending on builds that are years old. The README does not document a rollback path if a new build misbehaves, nor does it describe a stable versus development release channel. That silence matters more than usual here, because the Linux binaries carry a hard glibc 2.34 floor; on an older distribution the precompiled route simply will not run, and the only documented fallback is building with Lazarus and Free Pascal.

Third, the dependency story on Windows is easy to get wrong. Portable mode means no installer manages your OpenSSL DLLs, and the README explicitly warns against mixing files from different releases or architectures. A user who unzips a new build over an old folder can end up with a mismatch that the program will not diagnose for them.

Finally, the interface is not fully self-describing. Some transgui.ini parameters have no GUI equivalent, and the README defers to two GitHub issues for the details rather than documenting them inline. If your workflow depends on one of those settings, you are reading issue threads, not documentation.

Alternatives and how they differ in approach

The most direct alternative is the Transmission web interface itself, which the README names as the thing Transgui improves on. The difference is architectural rather than cosmetic. The web UI runs inside the daemon and is reached through a browser; Transgui is a compiled native application that speaks the same RPC protocol from outside. That is why Transgui can offer a uTorrent-like layout, fixed hotkeys and a dedicated info pane with separate Peers and Files tabs, and why it works the same way regardless of which browser you happen to have open.

A second alternative is the transmission-remote command line tool, which talks to the same daemon and exposes the same class of operations without any GUI at all. If your management tasks are scriptable and repetitive, a command line client is a better fit than a window you have to click through, and it has no glibc or OpenSSL packaging concerns of its own.

A third option is a different desktop front-end for the same daemon. Tremotesf and Transmission Web Control both appear in what people search for alongside Transgui, and both occupy the same niche: a client-side interface over Transmission's RPC. The practical difference to weigh is maintenance and packaging rather than protocol, since all of them depend on the daemon's RPC surface. Transgui's distinguishing traits are its Pascal and Lazarus codebase, its portable mode and --home parameter, and the fact that its published binaries stop in 2019 while the source tree does not.

Licence, maintenance and what an upgrade costs

Transgui is licensed under GPL-2.0, with the repository carrying COPYING.txt and a separate COPYING.FPC for the Free Pascal runtime components. The GPL-2.0 implication that matters in practice is distribution: if you ship a modified transgui binary to others, the licence's source-availability terms attach to that distribution. Running it against your own daemon is not distribution. This is a summary of what the repository states, not legal advice; read COPYING.txt before you redistribute anything.

On maintenance, the honest reading is mixed. The repository is not archived and its last push was on 2026-09-13, so the source tree is being touched. But the newest release listed is v5.18.0 from 2019-10-12, and the README's installation section leans on those release artifacts. That gap is the upgrade cost a prospective user should price in: if you rely on precompiled binaries, you are relying on a 2019 build, and if you want something newer you are on the Lazarus and Free Pascal build path described in the README, with the lazbuild and make commands taking a Lazarus directory. The README does not describe a release cadence, a support window for older builds, or a migration guide between versions. VERSION.txt exists in the repository root, but the README does not explain how it relates to the published releases.

Editorial conclusion

Adopt Transgui if you already run transmission-daemon and want per-torrent controls, file priorities and peer details in a native window rather than a browser tab. Do not adopt it if you need a client that itself downloads torrents, or if you are on a platform whose packaged build you cannot verify, since the release binaries date from 2019 and the README's own build path assumes a working Lazarus and Free Pascal toolchain. Before committing, check the Releases page for a build matching your architecture, confirm the glibc 2.34 requirement on Linux, and decide whether you need SSL/TLS, which on Windows means supplying OpenSSL separately for the portable zip.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. transmission-remote-gui/transgui on GitHub