To test, checkout branch kj-all-recordings-testapp. First, you will need to run Main.kt to import ulb and tn, if you haven't already. Then create a project and add an audio plugin.
Then, run
main in RecordScriptureTestApp.kt to work with takes on the scripture side
main in RecordResourceTestApp.kt to work with takes on the resource side
If you use these entry points, the app will load the first project, first chapter in that project, and first verse in that chapter. (Navigating strictly down through the app rather than using these separate entry points should work, but I created these entry points to make it faster to test the takes pages alone.)
Try performing record, delete and select (by dragging). Editing takes does not work yet due to an unknown issue with ocenaudio being unable to save edited files.
The most important part of this PR is the creation of a base class called RecordableFragment that handles all of the commonalities between the derived classes RecordScriptureFragment and RecordResourceFragment, namely dragging. Other view and viewmodels have also been renamed for clarity.
Also, I elected to keep the FlowPane as a FlowPane in RecordScriptureFragment. In lieu of finding any helpful examples of lists (particularly grids) with different data/node types, (most people were just talking about using different data types in a TableView, which doesn't solve our problem) I did some investigation:
Datagrid is parameterized by a model type- we would have to create a new umbrella type to encompass the three types: "Record New Take" card, the usual take cards, and blank cards. FlowPane is simpler because you can simply add and remove nodes that can be unrelated. This avoids adding unnecessary bloat code to create a new model type for the datagrid.
Datagrids (and similar lists) require an ObservableList of some kind of model. Besides point 1, this observable list would be different than but dependent on the alternateTakes list used in RecordableViewModel, which is already an ObservableList. Responding to a change in an observable list that is responds to changes in another observable list is slow (I tried it.)
I investigated FlowPane.java to see how I could add or remove blank cards to always empty space in the bottom row with blank cards. This seems possible if I eventually create a copy of FlowPane with some modifications to a private method. It seemed much more complicated to do the same thing using other lists.
Recording, deleting, and selecting takes works on both the scripture and resource side.
Requires common #115.
To test, checkout branch kj-all-recordings-testapp. First, you will need to run Main.kt to import ulb and tn, if you haven't already. Then create a project and add an audio plugin.
Then, run
mainin RecordScriptureTestApp.kt to work with takes on the scripture sidemainin RecordResourceTestApp.kt to work with takes on the resource sideIf you use these entry points, the app will load the first project, first chapter in that project, and first verse in that chapter. (Navigating strictly down through the app rather than using these separate entry points should work, but I created these entry points to make it faster to test the takes pages alone.)
Try performing record, delete and select (by dragging). Editing takes does not work yet due to an unknown issue with ocenaudio being unable to save edited files.
The most important part of this PR is the creation of a base class called RecordableFragment that handles all of the commonalities between the derived classes RecordScriptureFragment and RecordResourceFragment, namely dragging. Other view and viewmodels have also been renamed for clarity.
Also, I elected to keep the FlowPane as a FlowPane in RecordScriptureFragment. In lieu of finding any helpful examples of lists (particularly grids) with different data/node types, (most people were just talking about using different data types in a TableView, which doesn't solve our problem) I did some investigation:
ObservableListof some kind of model. Besides point 1, this observable list would be different than but dependent on thealternateTakeslist used in RecordableViewModel, which is already anObservableList. Responding to a change in an observable list that is responds to changes in another observable list is slow (I tried it.)