Expose ability to have time-dependent layers

[astrofrog]

Layers have the ability to define time-dependent markers, so we should expose that functionality in the layer API.

[ojustino]

@astrojonathan showed me that the code to do this lives here: https://github.com/WorldWideTelescope/wwt-web-client/blob/master/HTML5SDK/wwtlib/Layers/SpreadSheetLayer.cs

Specifically, we can edit BeginRange, EndRange, Decay, and the boolean TimeSeries that turns on all of this functionality.

[ojustino]

I'm finding that these settings are trapped by scope inside objects in the wwtlib.SpreadSheetLayer and wwtlib.TimeSeriesLayer classes and am not finding the way to edit them once a layer has been created. Is it only possible to set these attributes when initializing a layer? @astrojonathan

[astrojonathan]

No these are settable at run-time, and in fact the web client binds to the active layer and sets these thru UI, so You can do the same.
What have you tried? They are accessible like any other property.

[ojustino]

So when working through the SDK, I should be able to do something like wwtlib.SpreadSheetLayer.set_beginRange(date)? With that, I get TypeError: undefined is not an object (evaluating 'wwtlib.SpreadSheetLayer.get_beginRange').

[astrojonathan]

No. You set_timeSeries = true; The "begin" and "end" ranges are internally computed from your data.
You litteally just need to set the columns to define what column number defines your begin and optionally end data, your decay an set the time series to true at it just works.
From that point, you can then loop thru the time range using the space time controller and watch the animation happen.

[ojustino]

I'm not sure why it's not working so simply for me. The only editable attributes I get from wwtlib.SpreadSheetLayer (using Object.keys()) are _getDatafromFeed$1, _executeQuery$1, parseDate, execlToDateTime, get__circleTexture$1.

From what I see in the SpreadSheetLayer section of the SDK, set_timeSeries is inside an object called SpreadSheetLayer$ that I can't access from outside; the errors always say it's undefined.

[pkgw]

@ojustino Can you get your sample Python code in #187 to work in a Jupyter notebook? As far as I can tell, the fundamental issue is how WebKit's JavaScript Date objects work. Unlike some other toolkits, it won't parse the time column in your sample dataset as given. The MDN docs say that you shouldn't parse dates from strings in JavaScript due to cross-browser incompatibilities. But anyway, if I try an example in Jupyter in Firefox, it works.

There might also be issues with timezones; depending on how dates are constructed, they may be interpreted as UTC or as the local timezone. When testing with WebKit I had to express the times as being in my local time zone, YYYY-MM-DDTHH:MM:SS-05:00, to get WWT's internal clock to agree with what I was setting; this needs straightening out.

Finally, I also found that if I was running code as a block, I had to set the current time before calling track_object('Earth'), because the track_object() call would set up a Mover that would override the time that I had tried to set manually.

[ojustino]

@pkgw I'm still not having success running the code in to_test.py and time_test.py in a Jupyter notebook. I have tried working with fresh installs in a different conda environment. I can't get the viewer to show up in a notebook after installing my local git directory's version of pywwt with pip install -e .. I'm guessing you don't have the same behavior?

(Using conda install makes the viewer work, but since time_series and time_att are not keyword arguments of add_data_layer in standard pywwt, the sample code won't work since this PR is not part of the conda install.)

My sample code does not work as intended in Qt. The points disappear once times are assigned to them and they don't reappear after turning `pywwt``s clock backward.

We'll have to be careful about supporting both the Qt and Jupyter versions with regard to your findings on Date is indeed the case. I found that Qt's QWebEngine uses a lot of deprecated JS functionality when I wrote the keyboard controls functionality in wwt.html.

[pkgw]

@ojustino I find that if the viewer isn't showing up, it's almost always an issue with one or more of the extensions that need to be registered with the Jupyter system. Whenever this happens I try to flesh out the docs a bit more; here's a proposed update to the installation docs with some changes based on my most recent struggles: link.

[pkgw]

Closed in #187.