This looks like a good place for Ivory to get started with IGB code.

Woohoo! finally got it working!!!
I made all of my initial changes on a "breakThings" branch and I left a messy wake of commented out code.
Now I'm making a fresh branch "IGBF-201" to make all of the necessary changes in an orderly, well-commented fashion.

I pushed my local IGBF-201 branch to my fork of the repository:
https://bitbucket.org/IvoryBlak/integrated-genome-browser/branch/IGBF-201

Now it needs review.

Devdatta, To refresh the table, I used igbService.refreshDataManagementView() instead of updateGeneralLoadView().
We used updateGeneralLoadView(), but all it does is call refreshTreeViewAndRestore() and refreshDataManagementView().
I'm not sure what refreshTreeViewAndRestore() does, but all I want to do is refresh the table.

In testing, please include tests to see that the buttons in the table (refresh, delete, etc) are working appropriately for non-joined-graph tracks. Buttons that relate to loading data (refresh, delete, and load mode) should be inactive for joined graphs.

AL self-assigning for 1st level review.

Instructions from Ann:

Check that once a joined graph track is made, that it becomes available in the Data Management table and in the corresponding Preferences window and in the right-click "Configure" menu.

While performing the first-level revew I noticed that the you can now rename joined graphs and the new name appears in the Data Management table, but it does not appear in the Tracks tab of IGB preferences (see screenshot). I don't actually think this has anything to do with renaming tracks though, but just joining them, because as soon as I join them there is no track listed in the Tracks tab of Preferences. I could make a new JIRA story for this if desired, but it would be great if we could go ahead and fix it now! As far as I can tell though, this is the only thing preventing this issue from being resolved. Since this needs to be fixed, I am re-assigning to Ivory and moving the story back to the To-Do column.

After talking to Ann, I consolidated the comments that she and I made in the code on bit bucket into a set of 7 items to address:

1.
in core/igb/src/main/java/com/affymetrix/igb/view/load/DataManagementTableModel.java
public DataSet getRowFeature(int row) {

I will have to re-word the comments to make that clearer. What I meant is this:
If there are two tracks of joined graphs, and 4 other tracks, then there will be 4 "features" (DataSets). The table will have 6 rows: 4 for the tracks that have a feature, then 2 for the joined graph tracks. For each row, the system will determine the corresponding "feature". For row 1 its the first DataSet in "features", for row 2 its the second, etc. For rows 5 and 6, there is no feature. Those rows are "after the last feature".

2.
in core/igb/src/main/java/com/affymetrix/igb/view/load/DataManagementTableModel.java
public ITrackStyleExtended getStyleFromRow(int row){
This function is used for all rows (graph tracks, joined graphs, and annotation tracks). The function name should remain. BUT The if block, is for things that have an associated feature (graphs, annotations). The code in the implied else block is for joined graphs. ---> that distinction is what needs to be clearer. I think it just needs comments to make this clear (no name changes).

in core/igb/src/main/java/com/affymetrix/igb/view/load/DataManagementTableModel.java

3.
change name of variable "comboTrackStyles" to "joinedGraphStyles"

4.
generateFeature2StyleReference
—make private, or specify permission
-change name to refreshStyles
—include a comment explaining that this method gets called when a user opens or deletes a data set. Instance variables that keep track of the relationship between style objects and data set objects get updated in this method.

5.
Add general comments:
This is the function that creates the feature2styleReference, which uses the DataSet as a key to link to the corresponding style.
DataSets do not include a pointer to the corresponding style, but styles (well, some styles) include a pointer to the corresponding DataSet.
generateFeature2StyleReference() works essentially like an outer for loop, with createPrimaryVirtualFeatures() as an inner for loop.
pseudo-code:
for every DataSet that is passed in:
– look at all of the current styles,
– for each of these styles:
– -- if it is the style that goes with this DataSet, put this DataSet and this style into feature2styleReference as a key/value pair.
When the DataManagementTable is generated, a row is made for each DataSet and this object is used to retrieve the style info to use for each row (foreground color, background color, hidden/visible, and the name to display) With the new code, rows are generated the same way, BUT THEN additional rows are made for each style in comboTrackStyles using only the style info, with no corresponding DataSet (so in those rows, there is no option to refresh or delete the track or change the load mode).

6.
change name ”catchComboStyles” to match up to “createPrimaryVirtualFeatures”.

7.
check: is it better to use ItrackStyle or ITrackStyleExtended ?

I have laid out a plan for myself to make these changes while running $ git rebase --interactive
so the git history will be easy to follow.

amend to 5bfba49 “Added a container (a list called comboTrackStyles) to the DataManagementTableModel to”
(DataManagementTableModel.java)
variable names: 3,6
comments: 5

amend to 283c325 “Modifiy DataManagementTable and DataManagementTableModel so that the Data Manag”
(DataManagementTableModel.java)
comments: 1,2

new commit
(DataManagementTableModel.java)
comments, variable name, permissions: 4

Note: I will need to force push this to my cloud fork, which may erase the comments that I and I made there.
I saved them as a pdf for my own reference.

I made the changes that Ann and I talked about (see last comment).
I used rebase --interactive so the changes are woven into the existing commits, as if I had done it perfectly the first time.
This was added hassle on my end (more than I expected), but I think its worth it for how it makes the documentation so much easier to follow for the main project.

I rebased from main master (24 May 2017 up through commit 937399... )
I tested it on my machine, still good.
I did a push --force to update my remote branch, erasing all of the code comments that we had made on Bitbucket.

I'm moving it to 'needs 1st level review'.

Done with first level review.

Code changes look good. One can now rename the joined graphs. Also, an entry is made for it in the data management table. As this joined graph entry is made using only style attributes and there is no DataSet corresponding to it, we do not have the "refresh", "change load mode" and "delete" options working for this entry.

Issue is ready for second level review.

This issue has passed the 2nd-Level Review.

Joined graphs can now be renamed and the changes appear in the Data Management Table, as expected, even when changing to a different chromosome.I could not find a way to break this feature and did not notice any other side effects related to this change, so I am moving this issue to the Ready For Pull Request column and re-assigning the story to Ivory.

On a side note, I created IGBF-1168 (Add Joined Graphs to Tracks Tab of IGB Preferences) so we can track this issue as a separate bug.

I submitted the pull request.

After testing, it seems this issue is now resolved. Joined graphs can now be renamed and the changes appear in the Data Management Table, as expected, even when changing to a different chromosome (unless the data has not been loaded for the joined graph on that chromosome, but this is the current behavior on the live branch as well, so it is not related to this change). I could not find a way to break this feature and did not notice any other side effects related to this change. Since this story is resolved, it will now be closed.