Lua Script GIMP doesn't waits for GIMP locks when it's previously opened

Open Beginner friendly
#618 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
65/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
lua
Domain
desktop, tooling

Research direction

Open contrib/gimp.lua and inspect the GIMP command construction around line 99. Reproduce the workflow with GIMP already running, then apply the proposed command change and verify that the editing session waits, the source file remains available, and re-import into darktable succeeds after closing GIMP.

Written by the indexing model from the issue text.

Description

bug
Description of the Issue

The contrib/gimp.lua script fails to open images in GIMP when an instance of GIMP is already running. The image is exported by Darktable, but GIMP displays a "No such file or directory" error, and the image is never re-imported into Darktable.

The Root Cause

Race Condition The script's logic relies on the GIMP process being blocking (waiting until the application closes) to proceed to the file cleanup/re-import phase.

Scenario A (GIMP Closed): The script works. The process blocks, user edits, closes GIMP, and the script continues.

Scenario B (GIMP Open): Modern GIMP behavior (especially GIMP 3.0 AppImages or modern 2.10 distros using DBus) defaults to "Single Instance" mode. The command sends a signal to the running instance and returns control immediately (non-blocking) to the shell.

Because of this non-blocking return, the Lua script immediately proceeds to df.file_move, moving/renaming the source file before the GIMP instance (which queues the open request as an idle job) has a chance to read it.

Verification
GIMP 3.0 (AppImage): Confirmed failure due to immediate process return.

GIMP 2.10 (Ubuntu Studio Repo): Confirmed failure on a standard, fresh install, ruling out custom environment issues.

CLI Reproduction: gimp image.jpg && mv image.jpg destination.jpg reproduces the failure in the terminal (GIMP fails to read because mv happens instantly).

The Solution According to GIMP Developer Jehan (discussed in GNOME/gimp #14827), the correct way to maintain the script's intended sequential workflow (Edit -> Wait -> Re-import) is to force a new instance.

Adding the --new-instance flag forces GIMP to spawn a new process that blocks the terminal until that specific window is closed, preventing the race condition.

Proposed Change In contrib/gimp.lua, modify the command construction:
Lua

-- Current implementation (around line 99) gimpStartCommand = gimp_executable .. " " .. img_list

-- Proposed fix
gimpStartCommand = gimp_executable .. " --new-instance " .. img_list

Result of the Fix I verified this locally. With --new-instance, the script correctly waits for the editing session to close, the file remains available for GIMP to read, and the re-import to Darktable succeeds upon closing the window.

Dominant language
Lua
Stars
219
Forks
142
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from darktable-org/lua-scripts

All issues in darktable-org/lua-scripts

Similar issues

More Lua issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.