dragon, a drag-and-drop source and sink for X

A window that holds one file, for apps that only accept drags

The problem dragon solves is narrow and real. Many programs, web applications in particular, expect files to be dragged into them, and if you do not habitually use a file manager that turns into an obstacle. dragon is a drag-and-drop source for X, and the usage is one argument:

  dragon file.tar.gz

What appears is a window containing just that file, ready to be dragged wherever you need it. The interesting property is that nothing has to be modified on the receiving side. The application already speaks the drop protocol, so no plugin, no extension, no re-upload of your own file. There is no X, Wayland or browser specific handling exposed to the user, and the program is described as lightweight. For a person who lives in a terminal, this is the bridge to an interface convention that assumes a file manager you may not have. The point is not that dragon is clever about files. The point is that it hands over a file through the mechanism the receiving application already understands.

--target inverts the flow and prints what you drop

Run the program in target mode and the relationship reverses. You get a window you can drag files and text into, and every dropped item is printed to standard output:

  dragon --target

That single behaviour is what makes dragon useful as a filter. Because the output goes to standard output rather than to a text box, you can redirect it, pipe it, or hand it to a shell command, so a dropped file becomes an argument to the next program in a chain. Text is accepted on the same footing as files, which is the part that surprises people coming from file managers. Two flags adjust the lifecycle. The --and-exit option terminates as soon as one drag-and-drop operation is complete, which suits a single file handled once. The --keep option, combined with target mode, changes the behaviour of the target window itself: each file you drop becomes its own draggable button that you can drag elsewhere later, so the window accumulates your working set instead of discarding it.

  dragon --target --keep

Between the two modes, dragon covers both directions of a transfer without adding an application-specific feature to either end.

One C file, four Makefile targets, a man page and bash completion

The repository is small in a way that makes review easy. The top level holds a .gitignore, a LICENCE, a Makefile, a README, a bash-completion script, a dragon.1 man page, the single source file dragon.c, and an example directory containing download.sh. The Makefile builds against GTK+ 3 and fontconfig, resolved through pkg-config:

PREFIX = $(HOME)/.local
MANPREFIX = $(PREFIX)/share/man
BASHCOMPLETIONPREFIX = $(PREFIX)/share/bash-completion/completions/
NAME = dragon

The compile rule is a single command line, and it pins the C standard explicitly:

$(NAME): dragon.c Makefile
	$(CC) --std=c99 -Wall $(DEFINES) dragon.c -o $(NAME) $(DEPS_CFLAGS) $(CFLAGS) $(LDFLAGS) $(DEPS_LDLIBS)

Beyond that, the Makefile offers install, uninstall and clean. The install target is more than a copy: it installs the executable, generates a man page by rewriting the name into dragon.1 with sed, and installs a bash completion file under the same substitution, so renaming the binary renames its documentation and completion script consistently. That is the kind of detail that separates a tool someone actually installed from a proof of concept. The dependency on fontconfig through pkg-config is also worth noting, since it is easy to miss when a build fails on a machine that has GTK+ 3 but not the font configuration library.

Building and installing with make, PREFIX and NAME

Installation is two steps. Run make to compile dragon and get an executable you can run immediately or put wherever you like. To install it system wide for your own account, run make install, which places it in ~/.local/bin by default, along with the man page under the share/man tree and the bash completion file under share/bash-completion/completions. Two variables change that behaviour. The PREFIX variable moves the destination, so make PREFIX=/path/here install installs elsewhere. The NAME variable changes the executable name, so make NAME=dragon-drop install generates an executable and a man page that match the new name. The first use is then the same three-line pattern as the documentation shows: run dragon with a file path to get a drag source, run it with --target to get a drop target, and add --keep when you want dropped files to stay available for dragging again. Expect to see a small window appear immediately on the X display, and expect nothing to happen on a machine with no display, since the program is a graphical client that talks to a display server. The README states the requirement plainly: dragon requires GTK+ 3 and is distributed under the GNU GPL version 3.

Releases stopped in 2022 while commits carried on

The maintenance record here needs two numbers, not one. The last push was on 2026-10-18, so work is still landing in the repository. The most recent tagged release, however, is v1.2.0 from 2022-03-05, and the release before that was v1.1.1 from 2019-11-14. A checkout of master is therefore not the same thing as a packaged release, and a distributor packaging dragon would be building from untagged commits. There is no release note or changelog in the repository listing to explain what changed between the tag and the tip, and the README itself is a few paragraphs long with no section on the Wayland path, on the behaviour of the target window under a compositor, or on failure modes, even though the program describes itself as a source and sink for X or Wayland. The practical effect is that the code is short enough to read end to end, which is the best available answer to the question of what changed. Anyone tracking this project for a dependency should plan to vendor the source rather than wait for a new tag.

Where dragon is the wrong tool

It is worth being explicit about what this program does not do. It does not move files on its own, so it does not fit an automated or unattended pipeline, where a script would rather pass a path to a command than ask a human to drag something. It also does not give the receiving application anything it did not already accept, so an application that takes a file path or a URL is better served by invoking it directly. And it will not help with an application that only accepts uploads through a web form, because the drop protocol is not the same thing as a file input. On the licensing side, the GNU GPL version 3 is the real constraint for anyone who wants to ship the binary, since the source is required to travel with it; the licence text is in the LICENCE file. And the operational one: the target mode prints to standard output, which means the reading program has to consume it, so a workflow needs both halves, a window to drop into and a consumer waiting for the line.

Editorial conclusion

dragon fits a narrow and genuinely useful job: moving a file into a web app that only accepts drags, and piping dropped text into a command, on a machine where you have no file manager workflow you want to use. It does not fit automated or unattended pipelines, and it does not fit distributions that cannot ship GPL-3.0 binaries. Before building, check the Makefile variables PREFIX and NAME, confirm GTK+ 3 and fontconfig are present, and remember that the most recent tagged release is v1.2.0 from 2022-03-05 even though the last push was on 2026-10-18.

Frequently asked questions

Official sources

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