Add a web browser dose viewer gui to EGSnrc

[ellieb]

Add the web browser-based .egsphant, .3ddose, and DICOM file viewer. This project is a WIP, but the idea is to have an online resource for users to upload and view their own .egsphant and .3ddose files. There are many TODOs throughout the code that need to be addressed, but some of the major tasks include:

• [ ] Organize and restructure the code to be cleaner and more inline with web standards
• [ ] Add tests
• [ ] Do a visual cleanup of the site, making it more user friendly
• [X] Allow for multiple volume viewers to be functional at once
• [ ] Turn the window and slider bars into a double range slider on the density legend
• [ ] Fix the bug where the panel marker moves if changing a slice after zoom

[ftessier]

Rebased @ellieb's branch on the EGSnrc repo develop branch. Moved the code to HEN_HOUSE/gui/dose-viewer

[rtownson]

@ftessier should we instead be adding this code to the gh-pages branch? If I want to link from gh-pages to the dose viewer I will have to move a copy of the code there anyways, so there would be duplication.

[ftessier]

Nope, we want the code to be in the repository for source control; We don't want to duplicate source management, pull requests, etc., on an orphan branch; even though as you said this implies that we duplicate code to the gh-pages. We can however create a new branch off of gh-pages, were we can cherry-pick the dose-viewer commits as they are added, so as to not have to manually copy files over everytime. If you put the code on gh-pages, for the moment I would leave it in a "hidden" folder (not linked on the web page), but accessible by url, until we test it a little...

[ftessier]

@rtownson I take that back, I see now that we could maintain the web dose viewer code on the orphan gh-pages branch, and create the pull requests against that branch witout issue. However, I still prefer to leave it attached to the main trunk, I feel like it belongs there as part of the code proper, and if the dose viewer development ever requires changes to other parts of the code (say, the DOSXYZnrc output format), then it becomes tricky to synchronize the two disjointed branches. I would also like for users to be able to clone the repo and fire up the viewer on their local machine, right away. There are probably services to host a webpage from a github repo directory... I will look into it!

[ftessier]

Ok, well it seems that hosting with github pages remains the best option here. We can also now host a separate repo for egsnrc.github.io (instead of a separate branch), which may prove useful in terms of filtering out old pdfs (or maybe not filtering them out!), and building a more complex site hosting the viewer etc. We could then create pull requests against that repo from the EGSnrc one; anyways, let's continue to think about this.

[ftessier]

@ellieb I am considering using JS standard (https://standardjs.com/) to lint and format the .js files in your pull request to format the code consistently, beyond personnal coding style. This avoids style divergence and meaningless diffs in the long run, especially as other people with different preferences start changing the code. We do this on C and C++ files with astyle for example. JS Standard seems to be the simplest option out there right now: once installed via npm, just issue standard to check all .js files in the directory.

I ran it in the dose-viewer directory, and although there are 2340 suggestions, the vast majority are simply Strings must use singlequote. and Extra semicolon. "errors", which can be fixed automatically by standard. I just want to check that you are fine with this?

[ftessier]

@ellieb There are only 41 remaining linting instances that seem to require some attention... At any rate, I will look into those after cleaning and squashing the branch, an consult with you at that point on the remaining issues noted by standard.

[ftessier]

And I suggest we use prettier to lint html code (https://prettier.io/). Other suggestions welcome!

[ftessier]

@ellieb I have reduced this pull request to 78 commits, squashing together some smaller, related commits. I think the resulting chain of commits makes logical sense. Please take a look when you have some time, and let me know if this is ok with you. I also adjusted the commit titles accordingly, but left most of the original titles in the commit messages body. The last commit Format... is meant to be amended to format the .js files with standard and .html files with Prettier.

[ftessier]

@ellieb can you review the following log from the JS standard linter, and let me know if any one of these suggested fixes should not be implemented? standard.log

[ftessier]

I am pushing that to Release 2022, and I suggest that we include it as a submodule.