Filter Logs in ModList intaller view #2677
Conversation
…n excessive number of requests
…Dickerson/wabbajack into installerLogWindowThreshold
…nerate an excessive number of requests" This reverts commit 44b0637.
|
Personally not the biggest fan of this. I know for the average user this log might not say much, but in the new UI the log isn't visible by default anyway. Also, this log view is used on compilation where I think the author would definitely prefer a more verbose log about what's going on while things are happening. Is it that much faster if you log less info to the control? If there is a serious performance issue there I would rather fix that instead of just showing less info. |
|
The UI is significantly more responsive with fewer log statements being written out. There very likely is a way to improve performance but my knowledge of xaml/wpf stuff is not sufficient to know where to begin. Maybe the filter could be exposed as a option somewhere in the UI? |
|
I've been testing around a little in the new UI and I feel like it's plenty fast after your HTTP changes, so closing this PR. I've implemented your change in there, but changed it to only filter debug and trace messages out of the UI log to avoid 7zip extraction spam and such. I think that's a decent compromise, the debug & trace logging usually doesn't tell the user anything they understand anyway. |
|
Looking forward to checking out the new UI : ) |
Currently all logs get displayed in the ModList installer. This causes some significant decreases in responsiveness. It also means that more meaningful messages like download failure are lost behind logs that aren't meaningful to most users.
This filters to warnings and above to reduce the noise and improve UI performance.