Polishing a few rough edges:
* Enable scrolling on the Plugin List view. It only fit 6 or 7. I have 13.
* I fiddled a bit with column auto-sizing (left it commented out, see comment).
* A whole bunch of tweaks to the settings view:
* first row of controls was cut off at the top (under the window title bar)
* fixing that revealed uneven spacing between columns
* action buttons were teensy tiny and unreadable
* settings view columns were too narrow (200 px).
* added some spacing to help with readability
* settings windows now start in center of current screen rather than some random place.
Refactored out the logic backing the JournalBase TimestampDateTime property so it can be used for any DateTime type property, providing a standardized json String -> DateTime conversion for any date-time property. Implemented as an `internal static` method on JournalBase so journal objects which inherit from JournalBase or don't inherit from it can use it.
Used this to provide a DepatureTimeDateTime on CarrierJumpRequest (this property was added in Update 14) and to implement the existing ExpiryDateTime on CurrentGoal.
From a quick search in the journal documentation, I don't see any other applications for this.
Add a try-catch in ReadAllLines to handle a read failure if a file is locked.
Add a check for a non-existing export folder when exporting and prompt for new path if it doesn't exist.
* Implement click-through windows for X11
* Adjust the "platform specific" comment
* Get rid of accidental whitespace
* Move else declaration into next line
For plugin developers: Adds a new method to the IObservatoryCore interface to add multiple grid items in 1 call -- which only invokes the UI thread once (and potentially only scrolls to bottom once) providing a small performance improvement and providing some modest convenience.
I've had this occur a number of times (twice in a row yesterday) where if you receive new records while doing a long read-all, this exception crashes ObsCore.
So may need some further digging, but in the meantime, it won't crash here.
Tab separated output facilitates much more efficient opening of exported content in a spreadsheet for further data analysis, furthermore, it vastly reduces file size at the cost of human-readability. However, for the spreadsheet junkies among us, this is a welcome option.
To complement this, there is now an "Export Options" expander in the Core settings panel. Here one can select their preferred export style (default remains Fixed width) and now one can pre-select the export folder.
With this change, clicking export *will not* prompt for an export folder if one is already set. It will simply immediately export data.
Enjoy!
The recently updated avalonia seemed to change behavior in a way that caused notifications to steal focus from the game (often at at inopportune times). Not all users experienced this.
Adds new functions to the Lua environment available to custom criteria for handling rings and belts:
- the existing `rings(scan.Rings)` function behavior is unchanged
- NEW: `ringsOnly(scan.Rings)` and `beltsOnly(scan.Rings)` functions return ONLY rings or belts, respectively, and shortcuts the `scan.Rings` check
- NEW: `hasRings(scan.Rings)` and `hasBelts(scan.Rings)` functions return true if there are one or more proper rings or belts, respectively, in scan.Rings and shortcuts the check, too
Furthermore, this adds a debugging aid that identifies what custom criteria caused an error/crash. For simple criteria, ie:
`::Hot Landable::`
... the description "Hot Landable" is used. For complex criteria, you can now annotate the `::Criteria::` line with a description used for debugging like so:
`::Criteria=Hot Landable::`. Criteria errors are logged like this:
```
Error encountered in Elite Observatory from plugin Explorer while processing custom criteria 'Criteria14=I just crash' on scan:
```
Duplicates are avoided by prepending the user-provided description with a generated name (ie. `Criteria14`, in the example above).
Finally, the Detail expression for simple criteria can now safely reference values checked as part of the criteria condition. In particular, the Detail expression is now conditionally evaluated if the result is true. So the following will now work (previously it failed for non-star bodies when StarType was nil):
```
::Ringed Star::
scan.StarType and hasRings(scan.Rings)
::Detail::
'Star type: ' .. scan.StarType
```
Symptoms: App takes a very long time to start up, sluggish response to events because it's reading and processing every ancillary file 10x instead of just once when successful.
