Display average in data value ticker when hovering over row/col labels or trees

[Robert Leach]

USE CASE: WHAT DO YOU WANT TO DO?

Provide useful info when data value ticker is not currently in use.

STEPS TO REPRODUCE AN ISSUE (OR TRIGGER A NEW FEATURE)

1. Open any file
2. Hover over row/col labels or trees

CURRENT BEHAVIOR

"NaN" is currently displayed as the "Data value".

EXPECTED BEHAVIOR

If you hover over a row/col label, it should show for example:

Data value: 0.3 [row ave]

or:

Data value: 0.12 [subtree ave]

If the mouse is off the window, I would leave the field empty instead of showing "NaN" or else display something like this:

Data value: -0.02 [matrix ave]

You could even display multiple values (e.g. min/max, etc), but I'll leave this simple for now.

DEVELOPERS ONLY SECTION

SUGGESTED CHANGE (Pseudocode optional)

none

FILES AFFECTED (where the changes will be implemented) - developers only

unknown

LEVEL OF EFFORT - developers only

medium

COMMENTS

[mohammed faizaan]

I have finished working on this issue. I will send for code review once pull request #88 gets merged, as these are changes are on top of changes made in pull request #88.

[Robert Leach]

I'm interested in your thoughts on dealing with dependent PRs. In the past, I've dealt with it by branching new work off of master as long as the work can stand alone. This follows the concepts in the workflow we selected to use: GitHubFlow.

That's referenced in the CONTRIBUTING.md file in our root dir. I should formalize this as a part of our SCMP.

But there are occasions where the implementation of a new issue depends on completion of another issue on a separate branch/PR. In instances of dependent work such as this, the best practice is debatable, but in the past, I have branched off the branch which is waiting in a PR and then submitted the new PR as a merge from the new branch into the branch currently waiting as its own PR (as opposed to merging into master). However, I'm not aware of the restrictions to this process in the instance where a PR is submitted from a forked project.

The other consideration is the work done to resolve issues brought up during the PR review.

So branching off of a branch in a pending PR serves 2 purposes as I see it: each PR can be merged irrespective of one another and (in the alternative instance that we tend to do for PR issue resolution) where new work is added as a new commit to to an existing PR, it makes it cumbersome to the reviewer to wade through previously reviewed changes to inspect new changes. I've gotten around this in the past by inspecting the individual commits, but those comments are difficult to find for the author to address because they do not show up under the activity tab in the PR.

There's currently not an accommodation for separate inter-dependent branches in the SCMP, nor is "where PR issue work should be done addressed, but I would like to add something to address these issues, hence my interest in getting your feedback on this. The only relevant section of the SCMP is:

3.2.1 CHANGE CONTROL OVERVIEW PROCEDURE

where steps 6-8 indicate to branch off of master for new work.

Anyway, I just thought I would try to solicit your thoughts on this. I knew that inviting outside coders would prompt me to improve the SCMP with regard to these issues.

[Robert Leach]

It's not a duplicate, but it appears there's some overlap between this issue and issue #322 - especially in the comments about improving the issue.

[Robert Leach]

Resolved in pull request #90.

[Robert Leach]

Issue #42 was marked as a duplicate of this issue.

[Robert Leach]

Merged to master.

[Robert Leach]

Removing milestone: General interface (automated comment)