PhotoGIMP: An Open-Source Photoshop Alternative Patch for GIMP 3

I spent twenty minutes last month hunting for GIMP’s crop tool, because muscle memory kept sending my cursor to where Photoshop puts it, three rows up and one over from where GIMP actually keeps it. I gave up and used a shortcut I half-remembered from a Photoshop job years ago. It worked. Nothing else about that session did.

That’s the tax nobody mentions when they tell you to switch to GIMP because it’s free. You’re not relearning image editing, you already know that part. You’re relearning where your hands go, which is slower and more annoying than learning something new, because you don’t get better at it, you just get less bothered by it.

PhotoGIMP is a free, community-maintained patch that remaps GIMP 3’s shortcuts, tool positions and default window layout to match Adobe Photoshop, along with a custom splash screen and desktop icon. It ships as a folder of GIMP configuration files, not as a plugin or a fork, so there’s no code to compile and nothing to keep in sync with GIMP’s own releases beyond copying files. You drop them into GIMP’s config directory in place of the ones GIMP generated on first launch, and GIMP behaves as if it always looked this way.

The honest objection is that remapping a few dozen keyboard shortcuts is something GIMP’s own preferences panel already lets you do, so a whole patch project feels like solving a problem you could fix in an afternoon. That’s true for the shortcuts alone. It’s less true once you count everything else PhotoGIMP touches: canvas defaults, dock positions, single-window mode, the colour of the interface chrome, the template sizes that show up when you create a new image. Doing all of that by hand means reading through GIMP’s preferences section by section and guessing at the Photoshop equivalent for each one. PhotoGIMP has already made those guesses, and you can see exactly which ones by reading the config files it ships.

The part that’s more interesting than a config patch has any right to be

Most of what PhotoGIMP ships is inert until you copy it somewhere, so the closest thing to a design decision here is how it decides where “somewhere” is. On Linux there’s an install.sh at the repository root that the README never mentions or links to, and it does something the manual instructions never attempt: it asks GIMP itself where its config directory lives, rather than assuming.

gimp_params=(
    --no-interface
    --console-messages
    --batch-interpreter=plug-in-script-fu-eval
    --batch
    '(begin
        (display "GIMP_CONFIG_DIR=")
        (display gimp-directory)
        (newline))'
    --quit
)

That’s a Script-Fu one-liner run through GIMP’s own batch interpreter, and gimp-directory returns whatever config path GIMP is actually using on the machine it’s running on. The script copies PhotoGIMP’s packaged config, which lives in a folder literally named 3.0 inside the repo, into that live path, wherever it turns out to be. It backs the existing config up to a timestamped folder first, and refuses to run while GIMP is still open.

That matters more than it sounds like it should, because the README’s manual instructions for Linux, Windows and macOS all skip this entirely. They tell you to copy the 3.0 folder straight into %APPDATA%\GIMP or ~/.config/GIMP, on the assumption that GIMP’s config folder is still called 3.0. GIMP 3.2 shipped in March 2026 with its own config folder, and an issue opened in July confirms the obvious result: dropping PhotoGIMP’s files by hand into a 3.2 folder changes nothing but the splash screen. The install script would have handled that correctly, since it never hardcodes the destination. It’s Linux-only, and nothing in the docs points to it.

What you’re actually copying

The patch replaces nine files in GIMP’s config directory: shortcutsrc for keybindings, toolrc for tool ordering, sessionrc and dockrc for window and panel layout, gimprc for general preferences, contextrc for active tool state, templaterc for canvas presets, a theme.css for minor chrome tweaks, and a folder of splash images. On Linux it also drops a .desktop launcher and an icon set, so PhotoGIMP shows up under its own name in your app menu instead of as a second “GIMP” entry.

Restoring stock GIMP is a one-line rm -rf ~/.config/GIMP/3.0 (or the Windows and macOS equivalent of deleting the 3.0 folder by hand), and GIMP regenerates its defaults the next time it starts.

Caveats, honestly

The documented manual install breaks on GIMP 3.2 and newer. Issue #216 reports exactly this on Windows: the files land in a 3.2 folder GIMP never reads from, and only the splash screen changes. The workaround is renaming the destination to match your installed version, or, on Linux, using the undocumented install.sh.

The uninstall instructions are more destructive than the install ones. The README is explicit that installing PhotoGIMP only touches configuration and never your brushes, fonts or plugins. Deleting the whole 3.0 config folder to uninstall doesn’t carry the same guarantee, since GIMP can store user-added brushes and presets inside that same directory tree. One open issue is exactly this: a user reporting they’d wiped their .local folder by following the uninstall steps.

Skip this if you’ve already built your own GIMP workflow. PhotoGIMP overwrites shortcutsrc, toolrc and sessionrc wholesale; there’s no partial-merge option. Any custom shortcuts or panel arrangement you’ve put together yourself gets replaced, not extended.

PhotoGIMP vs remapping it yourself

Where I’d leave it

The interesting idea in this repository isn’t the shortcut mapping, it’s the three lines of Script-Fu that ask GIMP where its own config lives instead of hardcoding a version number into a file path. That’s the actual fix for the bug people are filing issues about, and it’s sitting unlinked in the project root. If I were maintaining this, the first change wouldn’t be a new feature, it’d be one line in the README pointing Linux users at the script that already solves their problem.