idlephysicist / cave-logger Goto Github PK

Regarding model.Statistic

$ grep -R Statis .
./internal/gui/gui.go:	//statsLocations []*model.Statistic
./internal/db/db.go:func (db *Database) GetTopPeople() ([]*model.Statistic, error) {
./internal/db/db.go:	cavers := make([]*model.Statistic, 0)
./internal/db/db.go:		var c model.Statistic
./internal/db/db.go:func (db *Database) GetTopLocations() ([]*model.Statistic, error) {
./internal/db/db.go:	stats := make([]*model.Statistic, 0)
./internal/db/db.go:		var s model.Statistic
./internal/model/gui.go:type Statistic struct {

Whether this is removed depends on how #24 progresses in development.
I don’t believe that this needs to be on the v2 milestone as these structs and functions may survive in some manner (based on #24 once again).

As the title states the deleted rows can still be seen in the table until the app is restarted.

Noted on both the people & locations windows.

Add vim style / searching / filtering to the following pages.

• Trips
• People Cavers
• Locations Caves

Reconfigure layout to be a bit more sane.

• Move the menu to across the top - think tab bar
• Move stats to their own page - think dashboard
• Status bar at the bottom

When using the l shortcut to get to the logs/trips window. The Cave column disappears from the refreshed table if you were already in the logs/trips window.

It does not happen if you cycle between the windows normally.

And does not happed with other windows.

Easy enough to do. I dunno why I didn't do it before for this program.

Add sorting functionality to the three main views.

I need to check tview wiki to see if this is even possible at present.

• Trips
• People
• Locations

Unblocked by cview implementing sorting, with f35f86924a! Trevor has also submitted a PR to tview will eventually be merged.

• Locations
  • Region
  • Country
• People
  • Club
• Trips
  • Cave
  • Names

PyYAML is a dependency for the Cave Logger installation (the make-db.py script). It is an unlisted dependency.

There are two options:

1. Have Homebrew / Linuxbrew install PyYAML in some way (is it even available through Brew?)
2. Convert Cave Logger to use something like JSON instead.
   This would also have the knock-on effect of removing the YAML dependency from Cave Logger as YAML is not part of the Go standard library.

The Homebrew formula which installs cave-logger does set a version variable for HEAD builds. But for builds from releases there is no git directory to pull commit info from.

Make a change to the Makefile to have a default value for the commit variable if there is no git directory.

Have a view to select data to be plotted. I also think that this should be available to the user via cli flags. That would mean that the analysis code should be packaged separately to the gui and db code.

Plots would not displayed in app (unless that can be reliably achieved).

As an initial step I think that this should be implemented as a cli flag where all of the analysable metrics are outputted. I think the former should follow the lines of

cave-logger --analysis -o ./analysis-2020-08-14.pdf

This would mean that all the ground work of doing the various analyses would be completed and ready before any work is attempted on the gui.

A panic occurs when the user attempts to inspect a trip, and there are no trips in the display buffer.

The likelihood of this actually affecting a user is very slim but it is still worth fixing.

Upon creating, updating, & deleting trips the user is returned to the locations window and not the trips window.

The same is true for the people window, and correctly true for the locations window.

Currently the trips page is sorted by DB index (I think) it would be better to sort it by Date.

Think about adding a note field to the caver/person table. The same could be done for caves/locations too. In fact that might be of more use.

These notes should only be viewable through an inspection view. Which would mean re-implementing that for the Caver and Cave panes.

Luckily I had just commented out most of the GUI code for displaying inspection windows. The db and model package will require more work along with the Python scripts which generate the databases.

I should point out that this will be a breaking change, meaning that people’s existing databases will not work and will need to be migrated. A migration could potentially be done in Python, meaning the script would read the file and determine if it had the right columns, then insert those columns if they are missing. I will need to brush up on SQLite to see how to do that.