-
-
Notifications
You must be signed in to change notification settings - Fork 898
Qt: honor logToStdout for script logging #3486
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
base: master
Are you sure you want to change the base?
Conversation
| out << message << "\n"; | ||
| out.flush(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LogController.cpp uses a QT_VERSION check to make sure that endl is defined, but this equivalent implementation works in all Qt versions. Maybe we could apply the same change there to remove a conditional compilation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the very least, IMO the #define endl Qt::endl should be replaced with using Qt::endl;.
|
Oops, this PR depends on #3485. |
|
This opens up a lot of architectural issues like "should logging from scripts go through the normal log controller flow", which this PR is kind of just sweeping under the rug. I don't think this is the right place to implement this and it needs more discussion. |
Discussion is the reason I opened the PR. I didn't actually expect it to be merged as-is. |
|
So then let's ask the question: Should logging from the script go through the regular logging flow? If so, we'd need to re-plumb the console a bit, but it's probably a better approach, especially if we want to add options about the destination |
|
It does sound like it might be a good idea, especially with autorun scripts in the picture now. I like the idea of being able to see script errors in with emulation errors in the general logs, and it means that the logs would get captured even if the scripting console isn't open. I think we might need to have some kind of log forwarding in place, so that messages always go to the scripting console but honor the logging configuration for what goes into the general logs. Some side questions:
Also, pulling a comment from #3483 (comment) over into this discussion:
|
Max wanted to see the scripting console output on stdout, but shimming the console object didn't work for capturing runtime errors. This will work for his use case, but maybe it's worth considering if we want to support this use case directly.
PR presented for discussion.