-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Windows Terminal to display DT stdout/stderr #17141
base: master
Are you sure you want to change the base?
Conversation
Currently on Windows, DT redirects all output to %LOCALAPPDATA%\Microsoft\Windows\INetCache\darktable\darktable-log.txt This commit overrides 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
Please take this as a suggestion. I presume there's more to change, but I didn't dig deeper yet. |
@wpferguson : Maybe you can comment on this Windows specific PR? TIA. |
I'll look at it... |
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. |
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 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.
Yes, it is guaranteed for the suggested code because Windows 8.x does not support Windows Terminal. |
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.
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. |
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: ***@***.***>
|
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! :)
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. |
@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:
Now in more detail:
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... |
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:
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:
There is nothing wrong with implementing both points 2 and 3, although even implementing one of them would be sufficient in principle. |
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. |
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.
|
Currently on Windows, DT redirects all output to
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: