darktable-org / darktable-org/lua-scripts

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

Offen Anfängerfreundlich
#618 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

bug
Vorherrschende Sprache
Lua
Sterne
219
Forks
142
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

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.

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Öffne contrib/gimp.lua und untersuche die Erstellung des GIMP-Befehls um Zeile 99. Reproduziere den Workflow, während GIMP bereits läuft, wende dann die vorgeschlagene Befehlsänderung an und überprüfe, dass die Bearbeitungssitzung wartet, die Quelldatei verfügbar bleibt und der erneute Import in darktable nach dem Schließen von GIMP erfolgreich ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
lua
Bereich
desktop, tooling
Issue-Typ
Bug
Schwierigkeit
1/5
Geschätzter Aufwand
Unter einer Stunde
Aktivitätsstatus
Veraltet
Klarheit
Klar beschrieben
Anfängerfreundlichkeit
65/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.