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

Aberta Para iniciantes
#618 3 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
1/5
Tempo estimado
Menos de uma hora
Facilidade para iniciantes
65/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Estagnada
Stack de tecnologia
lua
Domínio
desktop, tooling

Direção de pesquisa

Abra contrib/gimp.lua e inspecione a construção do comando do GIMP por volta da linha 99. Reproduza o workflow com o GIMP já em execução, depois aplique a alteração de comando proposta e verifique se a sessão de edição aguarda, se o arquivo de origem continua disponível e se a reimportação no darktable é bem-sucedida após fechar o GIMP.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Lua
Estrelas
219
Forks
142
Métricas de merge de PRs
Nenhum PR com merge em 30d

Guia de contribuição

Nenhum guia de contribuição indexado para este repositório

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de darktable-org/lua-scripts

Todas as issues de darktable-org/lua-scripts

Issues semelhantes

Mais issues de Lua

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.