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

Ouverte Adaptée aux débutants
#618 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
1/5
Temps estimé
Moins d'une heure
Accessibilité débutants
65/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
lua
Domaine
desktop, tooling

Piste de recherche

Ouvrez contrib/gimp.lua et examinez la construction de la commande GIMP autour de la ligne 99. Reproduisez le workflow avec GIMP déjà en cours d’exécution, puis appliquez la modification de commande proposée et vérifiez que la session d’édition attend, que le fichier source reste disponible et que la réimportation dans darktable réussit après la fermeture de GIMP.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

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.

Langage dominant
Lua
Étoiles
219
Forks
142
Métriques de merge des PR
Aucune PR mergée en 30 j

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de darktable-org/lua-scripts

Toutes les issues de darktable-org/lua-scripts

Issues similaires

Plus d'issues Lua

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.