* chore: move all observatory repos to core
* only save journal folder on change, don't constantly re-check during monitoring
* chore: monorepo project changes
* chore: monorepo migration
* 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
A few changes in preparation for the upcoming Announcer plugin.
1) De-dupe entries in the plugin table in the core settings UI when a plugin implements both Worker and Notifier interfaces.
2) Also add a "Types" column to the plugin table indicating the set of implemented interfaces found.
3) Wrap the pre-reading logic in "Read-all" scope to properly suppress a stampede of notifications (particularly audio ones) when starting the log monitor.
4) Fix the int setting UI. It rendered incorrectly, it didn't get the value from the settings class, nor wrote it back. Also implemented optional value bounding using the new setting attribute (see the related Framework PR).
5) Applied similar fixes to string setting (addressed rendering, write-back although untested).
6) Minor visual fixes (height/vertical alignment) for non-boolean settings to address cut-off/overlapping inputs.
Sorry for the larger PR, but these *should* be all the loose ends before we could consider including Basic Announcer...
Addresses 2 issues:
1) If a single plugin class implemented both the Worker and Notifier interfaces, multiple instances of the class were created, meaning no shared state within the plugin. Now only 1 instance is created.
2) Plugins implementing only Notifier weren't properly loaded.
The first time you click "Start monitor" (assuming you haven't read-all), we read the last 2 log files to find the journal entries for the last system jumped into (if we can find the FSDJump entry) in order to re-populate the information in all interested plugins. Its much faster than reading all to restore current system context.
- For Botanist plugin, this will display what plants/planets you've already sampled and avoids placeholder planet entries with incorrect bio counts.
- For Explorer, it re-lists interesting items, in case you weren't done exploring the system.
See https://github.com/Xjph/ObservatoryCore/issues/5
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.
