-
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
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.
|
You can tail the log very easily in Windows even without installing additional utilities:
As you can see, there is no need to modify the behavior of darktable to achieve this. P.S. |
I prefer to use the word "improve", or rather unify the behavior on Linux and Windows. |
I would replace the word "improve" here with more appropriate terms: feature creep, bloating.
Above, I explained at length why it is better to understand the differences of users on different platforms, instead of unifying the behavior on Linux and Windows
PowerShell's |
Alright. Then tell me how Windows users report warnings based in Lensfun or GTK, none of which use the DT's logging system. And as for |
Windows users report these warnings because they (warnings, not users) end up in the log file as warnings are output to
I don't understand why we are discussing this at all. Oh well, I could not mention the |
Ah, okay, my bad. I caused this myself by using
instead of
Could at least the log timestamp be altered to a date + time format instead of time from start, which makes it harder to review logs later? |
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
ee64cac
to
6e7cd5d
Compare
You can raise the issue with a proposal as a feature request (providing, of course, an explanation of what it will improve) and the developers will respond. Although I personally do not understand why this might be necessary. We now have the time since launch for each log entry and this makes it quite easy to see the duration of certain processes. Why would anyone need to know what time the clock on the wall shows at these moments? |
Because figuring out duration isn't the only purpose of logging, is it? |
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: