Add GUI to whats_new.rst

[chenghuzi]

In whats_new.rst we have categories API and Bug. Should we put the gui part under API or add another category GUI for the current and all future possible gui changes?

[rythorpe]

My vote is to leave GUI related code changes out of whats_new.rst for now, since hnn-core was originally designed to be API-oriented rather than GUI-oriented. Later down the road, we can then migrate the GUI code to its own repo without generating confusion withing the whats_new.rst timeline.

[jasmainak]

The purpose of the whats_new.rst document is twofold: 1) Track new changes introduced since the last release so they can be mentioned in the release email, 2) Give contributors credit for their work in the release email. But I guess for the GUI it is okay to have one entry for the GSoC ...

On the question of migrating GUI to its own repo, I foresee some issues ... particularly with respect to setting up continuous integration. If changes are made to hnn-core they would break the GUI and it would not be caught unless you have a cron job running ... which I believe might turn out to be tricky to set up. I would rather have Huzi focus on the actual code than fight with continuous integration. Also, the code is not substantial to merit a separate repository ... the overhead of maintaining the peripherals around that repository might be higher than maintaining the code.

If it's mainly a branding question, we could also call the "new GUI" hnn-dashboard. IMO, the right approach from the very beginning should have been to have the GUI and computational core in the same repository but logically separate (rather than mixed as it was) ... I had to create hnn-core as a separate repository so as to not spend my time debating the right approach but instead executing what made sense ;-)

[rythorpe]

Won't the GUI come with a few more dependencies, therefore moving the repo away from it's intended lightweight design?

I totally agree that credit should be given wherever possible, however, isn't the whats_new.rst also a changelog that helps users track what features are being added and/or deprecated? I wasn't imaging moving the GUI to it's own repo now, but rather once it and the hnn-core API stabilizes a bit more.

[jasmainak]

Ipywidgets is a very "light" dependency because anyone with a Jupyter installation should have it as well. We can move the GUI outside HNN-core certainly in the future. Specially if we go down the path of an integrated source-localization and HNN GUI down the path as was proposed in the original HNN grant:

At that point, the GUI code might start becoming substantial and 3D brain visualization libraries might be tricky in one repository.

[rythorpe]

Fair enough!