ripdrag turns a terminal file list into a drag source

Naming a file on the command line should be enough to drag it

Plenty of desktop applications only accept a file when it is dropped onto them, and that leaves terminal users switching context: you type a path, then reach for a file manager, then find the file, then drag it. ripdrag removes that round trip. The project describes itself as an application that lets you drag and drop files from and to the terminal, and the core invocation is simply the binary followed by a filename. The stated use case is exactly the moment of friction: many applications expect files to be dragged into them, and normally you would have to put your terminal aside and open a file manager to do it. The project also mentions pairing the binary with a fuzzy finder such as fzf, where the selected path is handed straight to the drag window, which turns file picking into a keyboard action followed by a pointer action. The audience is therefore the terminal power user with a graphical session, not the person working over a plain SSH connection.

Two modes: dragging files out, and receiving files dropped in

The option list makes the two directions explicit. By default ripdrag acts as a source, showing the paths you passed so you can drag them somewhere else. The --target flag flips the role: the window becomes a place where files are dropped in, and the --keep flag decides whether those files stay where they are. With --keep the files you dragged out are kept rather than removed, which is the switch that makes the tool usable as a file mover rather than a file destroyer. The reverse direction is what makes ripdrag interesting as a companion to a terminal workflow, since you can drag an attachment from a browser or a file manager into the window and then work with the resulting path in the shell. Other flags refine the window rather than the transfer: --resizable, --icons-only to hide labels, --disable-thumbnails to skip loading thumbnails from images, --icon-size to control icon and thumbnail size, --content-width and --content-height for the main window dimensions, --all for a drag all button and --all-compact to show only a count and drag the items together. --no-click stops the window from opening files on click, and --and-exit exits after the first successful drag or drop.

The Rust and GTK4 rewrite behind a dragon compatible surface

ripdrag is written in modern Rust against GTK4, and its stated design goal is to be feature to feature compatible with dragon while using that stack. The dependency list backs up the shape of the code. Argument parsing comes from clap 4.5.51 with the derive feature, which is why the help output has the shape it does. The GTK binding is the gtk4 crate at version 0.10.1 with the v4_8 feature enabled, and glib-macros sits alongside it for the object system. Two entries are worth calling out. async-channel 2.5.0 provides the asynchronous channel the application uses to move work between threads, which is what keeps a drag operation from blocking the interface while the drag is in flight. The opener crate handles opening files, which matches the documented behaviour of the --no-click flag that stops files from being opened when you click them. The release profile strips symbols and enables link time optimization, so the installed binary is smaller and slower to build. The repository is laid out as a conventional Cargo project, with a Cargo.toml, a Cargo.lock and a src directory, alongside a meson.build file and a it.catboy.ripdrag.json file that suggest packaging work beyond crates.io.

Installing ripdrag means preparing a GTK4 build environment

There is no prebuilt Linux binary in the README beyond the distribution packages, so installing on a workstation means getting the GTK4 development headers and a Rust toolchain in place first. On Ubuntu 22.04 or later the project asks for the GTK4 development package, a build toolchain and curl, then installs Rust through rustup.

sudo apt install libgtk-4-dev build-essential curl
curl --proto '=https' --tlsv1.3 https://sh.rustup.rs -sSf | sh

On Fedora, CentOS and RHEL the equivalent list is longer, covering the pixbuf, pango, graphene, cairo and gtk4 development packages.

sudo dnf install cargo gdk-pixbuf2-devel pango-devel graphene-devel cairo-gobject-devel cairo-devel python2-cairo-devel gtk4-devel

Arch Linux users have an AUR package called ripdrag-git, and the manual route installs the Rust and GTK4 dependencies with pacman.

sudo pacman -Sy --needed rust gtk4 base-devel

macOS needs homebrew, and the README asks for rustup and gtk4 there as well.

brew install rustup gtk4
rustup-init

NetBSD is the easiest path, since a pre-compiled binary is available from the official repositories.

pkgin install ripdrag

The binary itself is then installed from crates.io with cargo.

cargo install ripdrag

The README explicitly notes that sudo is not required if you do not want the tool installed for root, and that cargo is not on the path by default, so the shell needs one adjustment.

PATH=$PATH:~/.cargo/bin

The flags ripdrag could not carry over from dragon

The compatibility goal has a documented exception. The README states that some features, naming --on-top, cannot be ported over because of limitations in GTK4. That single gap has real consequences for the intended workflow, because the always on top window is what lets you keep the drag handle visible while you click into a target application behind it. Without it, the window behaves like any other GTK window, and the interaction depends on the window manager. A second limit is structural rather than a missing flag. ripdrag is a graphical program, so it needs a display and a window manager that speaks the desktop drag and drop protocol; the README documents no headless mode, no Wayland specific notes and no fallback for a session that refuses the drag. The project also lists what remains to be done, and the list is honest about the packaging gap: clean up of the code, build scripts for pacman, deb, rpm, windows and macos, and automated builds. In other words, the cross platform story is real for macOS and NetBSD, and partial for Linux, where you either use a distribution package or assemble the toolchain yourself.

How ripdrag differs from a file manager or a plain copy command

The usual alternative for moving a file is a file manager, which gives you previews, selection and multi file operations but pulls you out of the terminal. The other alternative is the shell itself, with cp, mv or ln, which stays in the terminal but produces a copy or a move rather than a drag gesture. ripdrag sits in a third position: it produces an actual drag source, meaning another application can accept the file the way it accepts one dropped from a file manager, and that is the only route to applications that will not read a path from a clipboard or a command substitution. The alternative to ripdrag proper is dragon, the utility ripdrag is written to mirror, and the difference in approach is the rewrite: dragon is the original and ripdrag tracks its feature set on a Rust and GTK4 base, which buys a maintained toolkit stack and the clap based command surface but costs the --on-top behaviour that GTK4 does not allow. Users who need that behaviour have to stay with the original, and users who want a build that matches the rest of a modern Rust toolchain can move to ripdrag with the same command line.

Release pace and what the GPL-3.0 licence means for your build

ripdrag is not archived and its last push was on 2026-09-16, with the same day bringing release v0.4.13. The two earlier releases on record are v0.4.12 from 2026-04-07 and v0.4.11 from 2025-10-29, so the visible history is a stream of patch level releases with gaps of several months rather than a fixed schedule. The version in the package manifest matches the newest tag, 0.4.13, and the project uses a changelog and release tooling conventions typical of a Cargo project, so an upgrade is normally a cargo install refresh followed by a check of the option list, which is where any behaviour change would show up. The licence is GPL-3.0, and the package manifest points at a license file rather than embedding the text. For teams that ship ripdrag inside a larger product, that licence obliges you to distribute the corresponding source of the combined work and to keep the licence terms intact. For a developer who installs the binary on their own machine, the obligation is effectively invisible. Anyone with an open source compliance process should still read the licence file and the terms of their own product before shipping, and should note that the project is still missing build scripts for deb, rpm, windows and macos, which is where a custom packaging pipeline would land.

Editorial conclusion

ripdrag earns a place for terminal heavy work where a file path has to become a real drag gesture, particularly when it is combined with a fuzzy finder such as fzf, and for anyone who wants the dragon command surface on a modern GTK4 stack. It is the wrong tool for a headless session, for a machine without the GTK4 development libraries, and for anyone who needs the always on top window, since the README states that the --on-top flag could not be ported because of GTK4 limitations. Before you commit, run cargo install ripdrag on one machine with the GTK4 headers present and drag a file into a real application, because the README documents no fallback for a display server that will not accept the drag.

Frequently asked questions

Official sources

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