[electron][logging][output] As an electron application user I would like to see the logging in the output view

[kittaakos]

For the electron version only; It should be possible to open the Output view and see the logs.

[westbury]

We have code to do this and I was wondering which bits to push to Theia core. I have a few questions:

We use log4js. I considered using Bunyan but I had problems getting it to work on Windows with Node 10. See, for example, trentm/node-bunyan#571. So, would you be interested in a PR for a log4js replacement for the Bunyan extension? Note that Bunyan has been inactive for almost two years. Log4js supports custom appenders, and we have a custom appender that sends the logging to the output view. By injecting the log4js configuration, this means what goes to the output view, the console etc can be configured by the IDE provider.

We send log content back to the browser side using new messaging API which then puts it into the output view. An alternative way would be to have new messaging API that exposes OutputChannel on the node side, which may be useful outside logging. I was thinking about how this might develop going forwards. There may be demand for more custom UI for log output, which might mean logs going into a separate view, or might mean making the output view more extendable.

Another issue to consider is that logs are primarily there to debug the IDE itself, not to debug the applications in the IDE. Therefore showing logs in the IDE may be considered inconsistent, though there is a benefit in the Electron case. Perhaps there should be separate API in ILogger for messages intended for the output view.

[kittaakos]

replacement for the Bunyan extension

I do not have objections against it, especially, if it does not work on Windows. Can you please create a follow-up GH issue to discuss it? It should be possible to configure to logging into a file too.

API that exposes OutputChannel on the node side

Exactly this, but the DI should be done in connection scope and only for electron. Maybe the electron-based default logger should send the log messages to this, dedicated, output channel.

though there is a benefit in the Electron case

We are targeting electron only within this issue.

[akosyakov]

We can also add a new repo for this extension. Ideally we will remove all extensions from this repo which does not support plugin system at the end.

Updated:
Or do you want to see logging in the output view for Electron by default?

[kittaakos]

Or do you want to see logging in the output view for Electron by default?

That would make sense. By default, if you start a bundled electron application from the application icon (both Windows and macOS) you cannot see anything from the backend log, so the end-users have a hard time to share any errors or the stack traces.

[westbury]

we will remove all extensions from this repo which does not support plugin system

the end-users have a hard time to share any errors or the stack traces

Surely this would be solved by logging to file. We currently log to files using our log4js extension, and we have UI to help the users attach the logs to e-mail. Are you sure that the right way to make it easy for users to forward diagnostic info such as logs is to go through the output view?

[kittaakos]

Are you sure that the right way to make it easy for users to forward diagnostic info such as logs is to go through the output view?

Well, it would be better than nothing. Right now, users have no chance to see the errors at all without starting the electron application from a shell.

to go through the output view?

Can you recommend a better approach; please share with us. At this point, almost any solution is better than the current one: nothing.

[akosyakov]

VS Code does the same for logging, so let's do it for Electron. For browser though backend logs should not leak to the user, they are for administrators.

[westbury]

Thanks for all your feedback. That is very helpful.

[paul-marechal]

Just saw #5039

Can you recommend a better approach; please share with us. At this point, almost any solution is better than the current one: nothing.

Writing the logs to a file seemed like a fair idea too.