Fix widget reset bugs

[jsub1]

Fixes a couple of issues I found in the reset method:

1. Only half of the layers were removed when resetting the widget.
2. An exception was thrown when resetting the jupyter widget because we were also resetting the inherited DOMWidget traits.

[astrofrog]

The issues in the tests are real - I think the problem is that foreground and background aren't traits that have the wwt tag (deliberately). Is that change really needed? What traits are being incorrectly reset?

[jsub1]

There are about 10 different traits inherited from the DOM widget or one of its ancestors where trying to restore them to a default value will cause an exception to be thrown (_dom_classes, comm, etc.).

We could iterate over and reset the traits that are specifically defined in the base widget class, instead of all of the traits that a widget has.

[astrofrog]

We could iterate over and reset the traits that are specifically defined in the base widget class, instead of all of the traits that a widget has.

Yes, though we should make sure we are sub-class friendly too in case anyone ever defines traits in a subclass.

[jsub1]

We could iterate over and reset the traits that are specifically defined in the base widget class, instead of all of the traits that a widget has.

Yes, though we should make sure we are sub-class friendly too in case anyone ever defines traits in a subclass.

The most general/transparent solution I can think of is to add a wwt_reset tag to the traits that we want to reset.
Another solution would be to loop over both BaseWWTWidget.class_traits() and self.class_own_traits(), but that wouldn't allow as much control as the above solution (and would break if we ever add a widget that doesn't inherit directly from the BaseWWTWidget).

[astrofrog]

Adding wwt_reset works for me!

[pkgw]

That sounds like a good solution to me too!

AppVeyor CI failure is an issue of antialiasing and color intensity (opacity?) of overdrawn lines in the Python 3.6 build. Presumably unrelated to this PR.

Travis CI failures are due to an error in make -C docs linkcheck with what looks like a transient issue with GitBook, or possibly a too-short timeout because the problematic URL (https://worldwidetelescope.gitbook.io/layer-control-reference/lcapicommands#table-of-properties) does take a really long time to load.

@astrofrog OK to go ahead and merge?

[jsub1]

One of the Travis failure (3.5) is due to the incompatibility of pytest 4.5 and pytest-remotedata 0.3.0 (Relevant issue: astropy/pytest-remotedata#37). Can we make sure it grabs remotedata 0.3.1 or later going forward?

[pkgw]

Since I went to the trouble of generating them, here are the images from the AppVeyor CI failure.

expected

actual

[pkgw]

@jsub1 Hmm, not sure why it's pulling in the older version, but let's try forcing >= 0.3.1 and see what happens ... I just added a commit to your branch doing so.

[pkgw]

Hmm, on Linux/Py35 it says that it's using remotedata 0.3.1 but the errors are still happening.

[pkgw]

Oh, looks like we need pytest-cov >= 2.6.1 as well. Commit pushed.

[codecov]

Codecov Report

Merging #212 into master will increase coverage by 0.02%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #212      +/-   ##
==========================================
+ Coverage   57.74%   57.76%   +0.02%     
==========================================
  Files          24       24              
  Lines        1692     1693       +1     
==========================================
+ Hits          977      978       +1     
  Misses        715      715

Impacted Files	Coverage Δ
pywwt/core.py	69.72% <100%> (+0.16%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9f914b9...d8f8e60. Read the comment docs.

[pkgw]

Aha! The Travis CI doesn't use conda-forge to source packages, while AppVeyor does. I think these various issues have been due to getting older versions of packages from the more conservative Anaconda defaults channel.

Since AppVeyor uses conda-forge and we've just added pywwt to conda-forge, I've tried adding it to the Travis configuration here. Hopefully this will make these issues go away. And in recent runs, the GitBook issue has disappeared, meaning that the only CI problem left should be the AppVeyor/Py36 issue. I hope.

[pkgw]

OK! The only Travis issue was a transient link-checking issue, so we've at least made progress on the CI front.

@astrofrog look OK?