Use Windows Terminal to display DT stdout/stderr

[jsmucr]

Currently on Windows, DT redirects all output to

%LOCALAPPDATA%\Microsoft\Windows\INetCache\darktable\darktable-log.txt

I suggest to override this behavior for Windows Terminal which is the default terminal app since Windows 11, assuming that the user runs DT in a terminal for debugging reasons.

It is however still perfectly possible to redirect DT output using the standard redirection operator:

darktable\bin\darktable.exe -d lua > darktable.log 2>&1

[jsmucr]

Please take this as a suggestion. I presume there's more to change, but I didn't dig deeper yet.

[TurboGit]

@wpferguson : Maybe you can comment on this Windows specific PR? TIA.

[wpferguson]

I'll look at it...

[wpferguson]

Tested on Win 11. Running in terminal works fine (actually better because it eliminates the "flashing" windows problems). Running in command prompt still works normally.

I'll test on Win 10 and see what happens.

EDIT: Tested on Win 10. Has no effect, even after forcing the terminal application to be the command processor. Had no negative effects either.

I don't have a windows 8 or 8.1 machine so can't test but it shouldn't have any negative effects.

[victoryforce]

Tested on Win 11. Running in terminal works fine (actually better because it eliminates the "flashing" windows problems). Running in command prompt still works normally.

That is, running in the Windows Terminal redirects the output, but running directly in the command processor (without the participation of Windows Terminal) does not?

I'll test on Win 10 and see what happens.

EDIT: Tested on Win 10. Has no effect, even after forcing the terminal application to be the command processor. Had no negative effects either.

I didn't quite understand why that could be. If we start Windows Terminal and run darktable in it, it doesn't matter if it happens in Windows 11 or Windows 10. The code checks for the presence of the WT_SESSION environment variable, the presence of which does not depend on the version of Windows.

I don't have a windows 8 or 8.1 machine so can't test but it shouldn't have any negative effects.

Yes, it is guaranteed for the suggested code because Windows 8.x does not support Windows Terminal.

[wpferguson]

That is, running in the Windows Terminal redirects the output, but running directly in the command processor (without the participation of Windows Terminal) does not?

Running in Windows Terminal lets the output come to the window. Running in a command prompt redirects the output to a file, as currently happens.

I didn't quite understand why that could be.

The terminal app in win 10 wasn't listed as Windows Terminal. Perhaps it needs to be installed separately? Just checked and that is the case, it doesn't come as part of windows 10.

[jsmucr]

Windows Terminal does not come with W10 by default, but can be installed from the store or via package managers. It's actually a nice app. You can run various shells in it (I use it mainly with WSL), and seems to have been made by that one particular MS team who actually know what they're doing. 😀Dne 9. 8. 2024 19:13 napsal uživatel wpferguson ***@***.***>: That is, running in the Windows Terminal redirects the output, but running directly in the command processor (without the participation of Windows Terminal) does not? Running in Windows Terminal lets the output come to the window. Running in a command prompt redirects the output to a file, as currently happens. I didn't quite understand why that could be. The terminal app in win 10 wasn't listed as Windows Terminal. Perhaps it needs to be installed separately? Just checked and that is the case, it doesn't come as part of windows 10. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[victoryforce]

That is, running in the Windows Terminal redirects the output, but running directly in the command processor (without the participation of Windows Terminal) does not?

Running in Windows Terminal lets the output come to the window. Running in a command prompt redirects the output to a file, as currently happens.

OK, as it should be (I asked for clarification because the original wording could be interpreted in different ways).

Oops, just now noticed that my question was the opposite of the correct wording! :)

I didn't quite understand why that could be.

The terminal app in win 10 wasn't listed as Windows Terminal. Perhaps it needs to be installed separately? Just checked and that is the case, it doesn't come as part of windows 10.

So I didn't understand correctly, I thought that the comment meant that "Windows Terminal" was launched in Windows 10. I have it installed in Windows 10. But it's hard for me to remember, maybe I actually installed it manually once for testing after seeing it advertised somewhere...

But that's really irrelevant, since we definitely don't need to be tied to the Windows Terminal specifically, even if we go in the direction suggested in this PR. But here we need a more detailed description of the context and what problem we are solving. This will be quite a lot of text, so the continuation is in the following comments.

[victoryforce]

@jsmucr First of all, thank you for your desire to improve darktable and your contribution!

Indeed, it is reasonable to assume that if a user on Windows runs a program not through an icon, but from the command line in the terminal, then there are chances than this is done for the purpose of debugging. But this is not always the case. This may be an advanced user who needs it to specify darktable command line options. For example, to specify a different configuration directory.

As for the specific proposal implemented by this PR, it has two drawbacks:

• We should not limit ourselves to Windows Terminal, any console is good enough to display debug output
• We should not limit disabling redirection to the log file only if there are enabled debug channels

Now in more detail:

• "Let's assume that Windows Terminal is good enough to display debug output" - any terminal is good enough to display debug output. So instead of checking if we are running from Windows Terminal we need to check if we are running from any console. I believe this can be done by checking for SESSIONNAME environment variable.

• Output redirection is suggested to be turned off only when the arguments include activation of debug channels (-d/--debug). But some debug printing can occur even in the absence of these arguments (this is called DT_DEBUG_ALWAYS in the code). And in this case, the program prints a warning about the most serious problems that the user should pay attention to, even if he did not enable certain debugging channels. Therefore, output redirection should be turned off simply by running it in the console, regardless of the presence of -d/--debug.

The next comment will be even longer about the context and what problem the redirect was trying to solve and how to improve the solution...

[victoryforce]

Now for the big picture. The question is what problem the proposed change solves and whether the proposed solution will be better.

Redirecting output to the log file on Windows platform was not introduced for any technical reasons, not because output to the terminal had any problems. The reason is not the difference of platforms, but the difference of typical users. A characteristic feature of the Linux user base is that interaction with the command line does not frighten the absolute majority of them. Even if the user is not nerdy, the conscious choice to install Linux means that the user is at least ready to understand certain technical details.

Regarding macOS, this can be said to a lesser extent, but in practice the instructions for macOS users were usually quite clear for them.

The reality of the Windows platform is that it is the most common, and therefore among its users there are more those who have a fear of starting the command line and the need to type something there (and they will have to somehow copy that output, which many have never done in their lives). That is why the redirection of output to a file was initially made.

Logging the entire output of each program run to a log file eliminates the need to ask the user to run the program from the command line to get output for at least the most serious problems that are logged even without specifying debug arguments when the program is started. Of course, this will not help if such arguments are still necessary to diagnose problems, but at least it will help in some cases.

It turns out that the current implementation of output logging to a file is also not ideal. Existing problems:

• The log is somewhere deep in the tree of the apps working directories (AppData), where the user never looks, so it is impossible to come across it without knowing the exact location
• The program interface does not contain any link to log file or the ability to open it and copy its contents
• The log file is located under a directory that is hidden, so with the default settings, it cannot be accessed by navigating in File Explorer. It is necessary to either teach the user to change the Windows setting to "show hidden files", or explain that the path they were told must be entered in the address field.

In fact, the correct solution to the problem of a complicated debugging process would be to modify the program interface so that the user can do everything without going to the command line and/or searching for a log file. This should include:

• Ability to set debugging channels (i.e. parameters of the -d/--debug command line argument) in the dedicated tab of global program settings
• Ability to open the log file from the program interface (it would be logical to place link to it in the same settings tab)
• Placing the log in a more visible and easily accessible location, for example under the Documents directory.

There is nothing wrong with implementing both points 2 and 3, although even implementing one of them would be sufficient in principle.

[wpferguson]

I would vote for point 3, putting the log file in the documents directory.

Opening the log file from inside the program is probably not much use. As you said, windows users aren't usually technically inclined so we'd end up having to explain what they are looking at. Better to just have the log file accessible so that they can attach it.

[jsmucr]

Adding a button opening Explorer at the file would be beneficial. That's how many apps in Windows do it.But that's not what I'm trying to solve here. My original concern was tailing the log, and figuring out what went wrong the very moment a failure occurs. The same way I'd do it in Linux.Adding an optional argument like `--debug-out <file>` or `--debug-out -` for stdout would make me happy enough.