Junction: a chooser for which application opens a file or link

A chooser that sits in the default handler slot

Junction lets you choose the application to open files and links. That is the whole product, and it is worth being precise about how it works, because the design is unusual.

The idea is that you set Junction as the default application for a resource, and then it pops up and offers multiple options to handle it. Instead of a fixed association, you get a prompt.

The implementation goes through the standard freedesktop mechanisms, which is what makes it fit into a Linux desktop rather than sitting beside it. The README shows the commands for each role:

  xdg-settings set default-web-browser re.sonny.Junction.desktop

for the browser role, and:

   xdg-mime default re.sonny.Junction.desktop x-scheme-handler/file

for all files. The png case is the same shape with a specific mime type:

  xdg-mime default re.sonny.Junction.desktop image/png

The mailto role goes through xdg-settings rather than xdg-mime:

  xdg-settings set default-url-scheme-handler mailto re.sonny.Junction.desktop

And folders are handled as a mime type too:

  xdg-mime default re.sonny.Junction.desktop inode/directory

Note the caveat that comes with the all-files command: it may not be respected by all applications, but the command xdg-open will respect it. That is an honest statement of how the desktop environment works, since different toolkits consult the shared MIME database with different degrees of diligence.

The application id re.sonny.Junction appears in every one of those commands, and it is the same identifier used in the Flatpak listing at flathub.org/apps/re.sonny.Junction.

The x-junction URI, which is the part that needs no configuration

The most useful feature does not require Junction to be your default handler for anything.

The URI format is x-junction://$RESOURCE, and the documentation is clear that it requires no programming to use. The examples given are:

- `x-junction://https://github.com`
- `x-junction://~`
- `x-junction://file:///etc/os-release`
- `x-junction:///etc/os-release`

You can use this in web pages, the terminal, native applications and anything able to open URIs.

To test it, the README suggests running xdg-open with the URI in the terminal, or using an anchor tag with the same URI in a browser.

That design decision changes what the application is. A chooser that only works as a default handler is a preference you set once and forget. A chooser that also answers to a URI is a tool you call on purpose, and it is the difference between always showing a prompt and showing one when you ask for it. For anyone who wants to open a URL in a specific browser profile, or a file in a specific editor, without permanently changing the desktop defaults, the URI is the mechanism.

The two path forms are also both present. A file can be given with the file:// scheme, as in x-junction://file:///etc/os-release, or without it, as in x-junction:///etc/os-release, and the home directory shortcut is just x-junction://~. Nothing in the documentation explains the difference between the two path forms, so the safe assumption is that both are accepted and neither is the preferred one.

Desktop files, mime types, and why your application does not show up

The troubleshooting section is where the real dependency on the desktop environment becomes visible, and it is the section most users will need.

If an application does not show up in the chooser, the likely cause is that its desktop file has no MimeType key matching the type of resource you want it to handle. The documentation's example is a custom browser that should handle web content, and the MimeType value to add is text/html, text/xml, application/xhtml+xml, text/mml and the http and https scheme handlers.

There are three more conditions. The [Desktop Entry] section of the .desktop file must be the first section, as the specification mandates. The desktop filename should be unique, because Junction cannot display both /usr/share/applicatins/firefox.desktop and ~/.local/share/applications/firefox.desktop, and the second overrides the first. And you must run update-desktop-database ~/.local/share/applications after installing a desktop file.

That last step is the one that catches people. Without it the file is on disk but the desktop database does not know about it, so the application never appears as a choice.

The documentation also lists where desktop files live, which is the answer to a question every new Linux user eventually asks:

- System `/usr/share/applications/` - User `~/.local/share/applications/` - Flatpak system `/var/lib/flatpak/exports/share/applications/` - Flatpak user `~/.local/share/flatpak/exports/share/applications/` - Snap `/var/lib/snapd/desktop/applications/`

If the application was installed through Flatpak, a package manager or another conventional route, the documentation says to open an issue, which is a reasonable place for a bug that only shows up on a particular system.

Working with the chooser: multiple opens, tooltips and indistinct icons

Several smaller behaviours make the chooser usable rather than merely functional.

Opening a resource with more than one application is supported through middle-click, Ctrl+Click, Ctrl+Enter or Ctrl+Space, which keeps Junction open and allows the resource to be opened in multiple applications. That is the feature that distinguishes a chooser from a menu, and it turns the prompt into a parallel launcher.

Keyboard navigation works with the arrow keys, and the application menu or Ctrl+? shows the keyboard usage.

The complaint about not being able to distinguish options with the same icon has a documented answer. Within Junction you can toggle Show names in the menu, or hover the application with the mouse to display a tooltip. Otherwise you can edit the desktop files to use distinctive icons, and the documentation points at three options: MenuLibre as a GUI, AppEditor as a GUI, and the ArchWiki desktop entries page as the advanced route.

Two GNOME-specific touches are in the tips section. Making new windows open in the centre of the screen is a mutter setting rather than a Junction setting:

gsettings set org.gnome.mutter center-new-windows true

And the terminal alias idea is the simplest way to route everything through Junction from a shell, with the alias `open=flatpak run re.sonny.Junction`, after which you can use `open my-file`. A link on how to create permanent aliases in Linux is included.

Browser integration is handled with a bookmarklet, so you can add a button to a browser toolbar that opens the current page in Junction:

javascript:window.location='x-junction://'+window.location

The Firefox profile trick, and the build and test tooling

The multiple Firefox profiles section is the most concrete example in the documentation, and it shows what Junction is actually for in practice.

If you want to choose which Firefox profile opens a resource, the documentation says to make desktop files for your Firefox profiles in ~/.local/share/applications. Here is the example file:

[Desktop Entry]
Version=1.0
Name=Firefox work
Exec=firefox -P work --class=firefox-work %u
Icon=firefox
Terminal=false
Type=Application
StartupWMClass=firefox-work
MimeType=text/html;text/xml;application/xhtml+xml;application/vnd.mozilla.xul+xml;text/mml;x-scheme-handler/http;x-scheme-handler/https;
StartupNotify=true

The Exec line is the interesting part, since it passes the -P work profile argument and adds a --class flag so the window can be identified. The StartupWMClass entry matches it, and the MimeType line is the long list from the troubleshooting section. You save the file, run update-desktop-database, and the profile shows up as a separate choice in Junction.

There is also a short section on environment variables in desktop files, with a before and after:

# Before
Exec=firefox %u
# After
Exec=env MOZ_USE_XINPUT2=1 firefox %u

The build system is Meson, and the Makefile wraps it. The dev target compiles the GSettings schemas and runs the app from source, the build target runs meson with a prefix and installs into a local directory, and run-host does a clean, a build and then launches the installed binary with GSETTINGS_SCHEMA_DIR pointing at the data directory. There are flatpak and flatpak-local-remote targets, a bundle target that produces a Junction.flatpak, and a test target that runs eslint and the JavaScript tests through a local test runner, plus a desktop file validation step.

The repository root shows the shape of the project: a src directory, a data directory holding the icon and schema, a build-aux directory, a re.sonny.Junction.json Flatpak manifest, a Makefile, a meson.build file, a Junction.doap file and a troll directory that appears to be the test harness.

The application is GPL-3.0 licensed and is published on Flathub. The last push was on 2026-09-25, and the newest tagged release is v1.5.0 from 2022-01-19, after v1.4.0 in December 2021 and v1.3.0, named Tobias, earlier that month. A gap of several years between the newest tag and the current work is a fair signal about the release cadence, so anyone tracking versions should follow the repository rather than the tags.

Editorial conclusion

Adopt Junction if you want to choose the application per file instead of setting one global default, and if you are comfortable with the XDG mime type machinery, since that is where the real configuration lives. Do not adopt it expecting a file manager replacement or a universal default handler, because applications that ignore the desktop database will still open things their own way, and the documentation is explicit that xdg-mime changes may not be respected by all applications. Before you set it as the default for everything, register the specific types you care about, and remember to run update-desktop-database after adding any .desktop file, or the application will not appear in the chooser at all.

Frequently asked questions

Official sources

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