Prevent terminal windows from popping up during start on Windows

[gerritsangel]

Is your feature request related to a problem? Please describe.

It's really "ugly" that Darktable opens multiple terminal windows on startup, which close immediately. After all, Darktable is a GUI application, and no other GUI (which are not geared towards developers or really really special purpose) application opens a terminal screen on startup.

This is even worse, because you think that the Ui is opened, and then a terminal window quickly pops up directly in focus, thus preventing being able to click around in the UI.

Describe the solution you'd like

Just start Darktable without any terminal screens :)

Alternatives

I think there is no alternative. This behaviour is just completely unnecessary on Windows and it does not make any sense.

Additional context

I have this issue on Windows 11 Home. I think it might have something to do with the lua interpreter being loaded, and for each lua script loaded there is yet another terminal screen opening? Probably the lua interpreters should be started as GUI process?

Anyway, I cannot imagine how this was not yet discussed, but this is really one of the weirdest UI things I find with Darktable :)

I would also try to give it a go on fixing it myself, although not sure where to start. Any pointers would be appreciated :)

[wpferguson]

This is a "feature" of windows any time you call a system command from inside a program. If you search you'll find lots of threads about the problem with no solution. The command prompt is a gui application, so any time you run a command, the command prompt has to appear.

You could run WSL and run the linux version of darktable, which can launch a system command without flashing a window at you.

[ralfbrown]

I took a look at what the darktable code uses to run external programs. The Lua code uses system(), while printing and email use Glib functions in the g_spawn_* family. I wonder if g_spawn_command_line_sync (the equivalent of system) might be able to avoid the terminal window.... if not, g_spawn_sync should, but it's more work to setup.

[gerritsangel]

This is a "feature" of windows any time you call a system command from inside a program. If you search you'll find lots of threads about the problem with no solution. The command prompt is a gui application, so any time you run a command, the command prompt has to appear.

You could run WSL and run the linux version of darktable, which can launch a system command without flashing a window at you.

Hmm okay, but:

I have seen this behaviour in no other programs, even in the ones which use for example Lua. Let's say Davinci Resolve, it has a Lua and a Python scripting engine built in. It does not open any shell window. So there must be some solution, or probably the approach which Darktable uses is not appropriate.

And normal users do not know what WSL is, and even then I would have a Linux application running inside Windows , which then probably breaks most of the Windows integration (let's say file piker etc).

Maybe the issue is that there is a system command called? I mean, why does the Lua interpreter have to be called as a command, instead of just load the interpreter in C code? Is this some security feature?

[parafin]

It’s not the lua interpreter that runs separately. It’s programs run by it and maintenance things like updating lua scripts using git (if I’m not mistaken).

[gerritsangel]

Okay, thanks for the hint, i'll try and do some investigation.

[wpferguson]

The Lua interpreter is part of darktable, thus it has access to the darktable internals and can be used to extend the functionality. When a script executes an os.system() or io.popen() instruction the operating system command interpreter (bash on linux/macos, cmd on windows) is invoked to run the argument. Since CMD is a GUI application, the window has to open in order to run the argument (command).

See https://stackoverflow.com/questions/6362841/use-lua-os-execute-in-windows-to-launch-a-program-with-out-a-flash-of-cmd

[gerritsangel]

Okay, so I did some tests with a rust program:

#![windows_subsystem = "windows"]
use mlua::prelude::*;

fn main() -> LuaResult<()> {
    let lua = Lua::new();

    lua.load(r#"os.execute("notepad")"#).exec()?;
    Ok(())
}

So, indeed it behaves the same as Darktable. It will compile as a windows subsystem binary, it will open a terminal window and then notepad appears.

But if I start a command with only rust APIs, it only starts notepad:

#![windows_subsystem = "windows"]
use std::process::Command;
use std::io::Result;


fn main() -> Result<()> {
    Command::new("notepad").output()?;
    Ok(())
}

So, basically this tells me:

• It's not a general problem on Windows
• The problem is only Lua's os.execute() and io.popen().

But when lua's function is deliberately kept simple (which in general is probably fine)... Why not then replace it with a custom function which is OS dependent, or probably better, only on Windows replace it with a Windows specific API call which behaves the same as io.popen and os.execute?

I mean if Rust's standard library can execute a process under Windows with a windows subsystem application without opening a terminal, a C program should be able to do that as well.

[wpferguson]

@gerritsangel run your tests with MSYS2 and gcc and see if that works.

[gerritsangel]

@wpferguson Yes, still same behaviour. The standard Rust Command api does not open a terminal window, only the Lua one.

I used mingw-w64-ucrt-x86_64-gcc as written on the msys2 homepage, and for Rust i used toolchain stable-x86_64-pc-windows-gnu.

[wpferguson]

So what solution are you proposing/desiring?

darktable uses lua as supplied by lua.org. If there are issues with the way os.execute and io.popen work on windows, then the issue should be raised with the lua developers.

[parafin]

I think what is being proposed is to create a darktable-specific functions implementing os.execute and io.popen, that could be called from lua scripts, and then migrating all scripts to make use of them. Not sure if it’s a good idea. Maybe indeed it would be better to enhance lua’s original functions instead upstream…

[Dannny1]

This may be related also to the issue of incorrect colors on windows. #3619
If i remember correctly it appeared at the same time and also it appears always on primary monitor (similarly primary monitor profile is always used).

[wpferguson]

@Dannny1 this is a lua issue and has nothing to do with colors or multiple monitors.