Open faynopi opened 2 years ago
without redirecting stdout/stderr or anything you can't even debug that notification, it's gone.
I don't see this as a huge problem for something like a notification server, where you usually have control over the notification. I understand it is useful to debug recent notifications, but at most you lose one and then turn on print_to_file
or redirect the output. I don't think these are things that regular users want to enable, so that's why they're disabled by default.
Having said that, It would be nice to be able to debug recent notifications using the CLI. I'd love to do a wired --debug
command which pushes a notification with debug draw + prints debug info to output, but not sure how complicated this will be at the moment -- shouldn't be too bad. This goes with your suggestion:
Having a command-line flag to print debug information in wired --show would help a lot with debugging and is generally useful.
Agreed!
According to my testing, --show does not append any information about that notification to the log file after being displayed, which I believe it should.
Correct, --show
does not add another entry to the log. This is intentional because we don't want client-side interaction to interfere with the "source of truth" history. I see print_to_file
as a log of all the notifications that have been received through Wired, and I think it would lose a lot of its utility if it started printing duplicate notifications because of user action.
I'd love to do a wired --debug command which pushes a notification with debug draw + prints debug info to output
Having wired --debug
would be awesome. Implementing it shouldn't be too difficult Imo. I'm not sure how your code works, but I think the solution would be to set config.debug
at runtime and then perform the same action as --show
.
for the print part, I believe all the things we need to print are already in history.
Having a command-line flag to print debug information in
wired --show
would help a lot with debugging and is generally useful.Debug mode is disabled by default. As a result, if you come across a notice with a body that isn't shown, you'll probably need to check the logs. the problem here is that the
print_to_file
option is disabled by default and considering that your suggested way to runwired
is:without redirecting stdout/stderr or anything you can't even debug that notification, it's gone.
According to my testing,
--show
does not append any information about that notification to the log file after being displayed, which I believe it should.