Make logs accessible

lucas commented

2023-02-19 22:15:20 +01:00

Owner

Since the GUI app will rarely be started from a command line, logs on stdout/stderr won't be useful.

Ideally, there should be an event log within the UI itself, e.g. a read-only textbox at the bottom.
For a "good enough" first implementation, the production version should simply log to a file.

Log view widget
Dialog boxes for errors on critical operations

Since the GUI app will rarely be started from a command line, logs on stdout/stderr won't be useful. Ideally, there should be an event log within the UI itself, e.g. a read-only textbox at the bottom. For a "good enough" first implementation, the production version should simply log to a file. - [x] Log view widget - [ ] Dialog boxes for errors on critical operations

lucas added this to the Basic SDK and mod manager milestone 2023-02-19 22:15:20 +01:00

lucas added the

kind

feature

crate/dtmm

labels 2023-02-19 22:15:20 +01:00

lucas added this to the Mod Manager project 2023-02-19 22:15:38 +01:00

lucas commented

2023-02-19 22:36:38 +01:00

Author

Owner

Certain actions, like mod deployment and profile save, should probably even show a dialog message on error.

lucas added the

stage

actionable

label 2023-02-21 22:51:19 +01:00

lucas commented

2023-02-23 10:46:27 +01:00

Author

Owner

Fancy handling for the dialog:

The first error in the chain is displayed as the error text. The rest of the chain is put into a "Reason" text box.
If there are suggestions, they should be displayed prominently.

Fancy handling for the dialog: The first error in the chain is displayed as the error text. The rest of the chain is put into a "Reason" text box. If there are suggestions, they should be displayed prominently.

lucas commented

2023-02-23 10:49:12 +01:00

Author

Owner

Both for the "log" UI view and the dialog boxes, the worker thread could probably be used.

tracing events are sent through the channel as a AsyncAction::Log or AsyncAction::Error, and this sends back immediately a command to add a log line to a Vector in state or to open the dialog box (or both).

Both for the "log" UI view and the dialog boxes, the worker thread could probably be used. `tracing` events are sent through the channel as a `AsyncAction::Log` or `AsyncAction::Error`, and this sends back immediately a command to add a log line to a `Vector` in state or to open the dialog box (or both).

lucas commented

2023-02-23 11:09:36 +01:00

Author

Owner

Log lines in the UI view should not contain any tracing information, except perhaps the fields.
Potential format:

[{time}] [{level}] {{message}}

[10:50:23] [INFO] I did something

Log lines in the UI view should not contain any `tracing` information, except perhaps the fields. Potential format: ```log [{time}] [{level}] {{message}} [10:50:23] [INFO] I did something ```

lucas referenced this issue from a commit

2023-02-23 21:39:55 +01:00

feat: Reduce clutter in release mode logging

lucas referenced this issue from a commit

2023-02-27 16:49:35 +01:00

feat(dtmm): Implement log view

lucas commented

2023-02-27 16:49:44 +01:00

Author

Owner

The now-implemented log view widget should be good enough for the MVP release

lucas referenced this issue