* Add event-based LogMonitor state changes to better handle batch reads
Pre-reading hackily used read-all to suppress notifications. But that broke some assumptions about what read-all meant. Furthermore, the Core UI told plugins about read-all rather than the log monitor telling them -- which is really what should be telling them.
To address these concerns, LogMonitor now provides an event that both the PluginCore and PluginEventHandler listens to or tracking logging state allowing more granular information about the activities of LogMonitor, including distinguishing between ReadAll and Pre-read batches. Plugins no longer need to track if LogMonitor is in batch-read mode or not -- PluginCore now provides it.
I've also converted all built-in plugins to use the new event-based system. The old system is marked deprecated and will go away once other known contributed plugins have converted to the new system.
* Change LogMonitorState enum to [Flags], drop 'None' state
As requested, and did associated simplifications and cleanup that followed.
* WIP: initial commit for observatory herald
* Plugin error handling refactor
* make error window non-modal
* tidy up plugin error handling
* first pass for basic herald functionality
* corrections for linux env
* Use FNV hash directly instead of managing through dictionary/index file
* resolve audio queuing issue, switch to personal NetCoreAudio fork
* merge cleanup
* add enable setting, populate defaults
* framework xml doc update
* Adjust settings, add style selection, replace locale with demonym in dropdown list.
* Test is position is on screen before saving/loading.
* use a default that's actually in the list
* feat: cosmetic overhaul of native notification popup
* fix: use correct screen default
* feat: move notification test from debug build type to button press
* fix: not debug anymore
* fix: rearrange native notification settings controls
* fix: account for display scaling when positioning notification
* fix: guard against a screen that no longer exists
* fix: safer way to get screens, in case control tree changes
Upon arrival of new records to the backing ObservableCollection, scroll the DataGrid to the last item. However, when the DataGrid is initialized, there's not yet a data context set, so when that happens, then we can listen to the CollectionChanged event to trigger scrolling (only really needed for additions).
In passing, also set the DataGrid to ReadOnly.
In the other two files, minor simplifications/cleanup.
