DayDetailViewModel needs testing. I've worked out an improved API, and a set of tests to go along with it, and those can be made more easily with a mockable RecordProvider. So, in addition to stubbing out a bunch of tests, I've also created RecordProvider, mocked it, and implemented it for App.
This is preparatory work. Having the view model directly retrieve data both adds a degree of symmetry (it both gets data from and sends data to the app) and makes it possible for the view model to refresh itself when needing to revert data or after saving data.
I've created the view model and added a getter function for the weight.
I'm passing the view model now to the DayDetailView, DayDetail, and
DayEdit.
I'm starting to set up the Save function for the view model, draining
all of the updated records and saving them.
None of the components yet save any updates to the view model, so
updated_records is always going to be empty until I figure that out.
DayDetail, the component, I used to use as a view. Now I'm swapping
things out so that DayDetailView handles the view itself. The DayDetail
component will still show the details of the day, but I'll create a
DayEditComponent which is dedicated to showing the edit interface for
everything in a day.
The swapping will now happen in DayDetailView, not in DayDetail or an
even deeper component.
Swapping is now done in dedicated functions instead of a big pattern
match.
After selecting a database, the app window will apply the configuration
by opening the database, saving the path to configuration, and switching
to the historical view.
This allows me to directly reference functions that occur on those
widgets without losing them behind a gtk::Widget upcast or needing to
later downcast them.
I've created the DaySummary structure and set up a list view to go into
the historical view. One hard-coded date is visible as a placeholder to
start filling things into the day summary.
Savanni D'Gerinel