Using/Migrating HTML Pages from 1.5 to 2.0

You should pretty easily be able to migrate the pages into per-profile html gui pages we have since Uniview 1.6.

Dan Tell posted a similar question here a while ago, http://uniview.userecho.com/topic/500831-migrating-html-buttons-to-work-in-16/. The same uniview.sendEvent() function should replace your message function I think.

Thanks for the link. It wasn't clear to me until a careful reading of that thread that putting an html/ folder inside the 2.0 profile will allow Uniview to load the page as a Custom webpage.

Unfortunately this doesn't appear to work with my 2.0.6 install for some reason. I've added the uniview.js link in index.html, and have edited uvTray.js as suggested by Mikael's post. However none of my buttons work. Also the the browser is stuck on the default tab ("1. Flood Layers"), and I cannot switch to the other three tabs ("2.Precipitation," etc.).

Here are my browser files de_coflood.zip.

I made some changes to the zip you send:
1) removed the js/uniview.js (this is already served by Uniview Theater)
2) removed the websocket code from uvTray
3) removed the sendMessage "overload" with retry from uvTray
4) Included "/js/uniview.js" instead of "js/uniview.js" (i.e. relative to the hosted root instead of the current directory)

Here is the html, html.zip

Thanks, Urban! That seemed to have fixed things.

However now I've noticed other code that is unresponsive. Any ideas why this function:

function toggle_layer(layer_number) {
    "use strict";
    var ele = document.getElementById("toggleToggleLayer");
    var text = document.getElementById("displayToggleLayer");
    if(ele.style.display == "block") {
        uniview.sendEvent("Earth_layerdata.prop.Layer" + layer_number + "_Enabled 0");
        ele.style.display = "none";
    }
    else {
        uniview.sendEvent("Earth_layerdata.prop.Layer" + layer_number + "_Enabled 1");
        ele.style.display = "block";
       }
}

or this:

function toggle_landsat7() {
    "use strict";
    var ele = document.getElementById("toggleLandsat7");
    var text = document.getElementById("displayLandsat7");
    if(ele.style.display == "block") {
        uniview.sendEvent("Earth_layerdata.prop.Layer1_Enabled 0");
        ele.style.display = "none";
        text.innerHTML = "<img width=48 src='pix/off.jpg'>";
    }
    else {
        uniview.sendEvent("Earth_layerdata.prop.Layer1_Enabled 1");
        ele.style.display = "block";
        text.innerHTML = "<img width=48 src='pix/on.jpg'>";
    }
}

would no longer work?

I think I've found at least the bugs and typos causing the second function above not to work. So that problem was caused by my own sloppiness. I'll report back more on the first function ...

Hey Ka Chun,

If it's of any help, I an attach html an example of a now-fully functional HTML page from one of our shows in Uniview 2.0.

They're still not idea, fancy page layouts, but it might be helpful. Instead of scripting each individual layer button, I have a generic "toggle" type button that alternates between two clasess (uv-toggle-off and uv-toggle-on) which enables to send it two different command strings, which has made it easier (and less programming intensive and consistent) to toggle resources in Uniview in our custom layouts. All the javascript is still stored in the uniview.js.

Thanks, Dan!

Let me see if your files can help with our toggling needs. I thought I had a generic function written that would work for any Geoscope layer, but that has recently stopped working in 2.0 as well. I'll report back later today (Monday May 18) ...

Yep, it's probably obvious how my buttons work, but a uv-toggle-off/on can have any string attached to it, so my buttons for slides, layers and objects all look very similar and are just the custom command string, with one consistent javascript control, but it doesn't automatically scale, as it looks like yours might be intended to? I still have to hand-make each button (lots of copying and pasting).

Actually, this brings up a side note that should maybe be its own ticket: the geoscope layersets file is binary, but it would be really, really awesome if it were ASCII and could be edited outside of Uniview would allow for bulk-editing of large layersets, as well as better being able to see which layer is which number.

Got your uv-toggle functions working. Thanks, Dan!

I second Dan's suggestion of having an ASCII -- at the very least a human-readable XML -- version of the layerset file. It would drastically reduce our work if we can make a copy of an existing layerset, and swap out the parameters of a few key terms in gvim or with a perl script.

With the way things are, I usually have to rebuild layersets from scratch since the layer numbering is opaque, unless you open it up gui.statemanager, and even then that only tells you what layer you need to edit. Editing in the Geoscope window is also not very efficient. Since many of our layersets run into dozens of datasets, this is a real pain.

I agree with this, I hope we can find the time to get this in 3.0. It shouldn't be a big thing to change.

But isn't the real issue that you need dozens of layers? How much of this would be simplified by having video layers? An mp4/mkv mapped on a rectangle projected onto the planet.

Video, gif or time/series layers would be huge, or the ability to add "simple layers"--an ability to quick slap on a rectilinear image or video that doesn't need multiple resolutions would be awesome.

Yes, I agree the ability to just import in a video be huge. So I would be a big fan of that.

However it would still be useful to be able to edit layers when we are not loading animated time series. Or we have time series that do not have large frame counts, so it doesn't make sense to go to the trouble of making a video (e.g., 12 frames for each month of the year). Often we have multiple sets of short time series.

But what often kills us is needing to keep on deck many different KML files and individual WMS base layers (e.g., Landsat, NAIP, Bing, Black Marble, NLCD). These can add up quickly, especially since we want to have them handy in case the presentation or conversation turns to one direction or another.

We've added a ticket for changing the layerset format into a human-readable format, but since this breaks compatibility, we will include this in the next major release rather than in a 2.0.x patch.

We've noted the support for video layers (it's on our list of things we want to do too).

I'm closing this thread now, since the original question (getting html pages to work in 2.0) has been answered below.

One last question: I've replaced the "sendMessage" with "uniview.sendEvent" in Staffan's original cycler code, but that doesn't make the animation cycler work in 2.0. Any recommendations on a fix?
uvCycler.js

Can you confirm that the call actually gets to Uniview?
I.e, has the uniview.js been loaded and does the browser get a 200 OK back from Uniview if you check the browser console?

I just need to know if the problem is on the web side or the Uniview side.

Hi Mikael,

I've confirmed that the uniview.js script is running and sending back "200 OK"s from the sendEvent function. The resume, pause, stop, stepforward, and stepbackward functions in uvCycler.js:range_cycler() all seem to work at least based on the status messages that show up.

For an example of this code to test, check out the profile files referenced in my other support forum thread at https://copy.com/j4oganWtqYDLv3hJ. They contain an example of the range_cycler() code in the first tab of the Custom browser control, with the stepbackward/play/pause/stop/stepforward buttons under "Continuous Cycle":

Hi Kachun,

The kmz layers actually are not effected by Alpha property changes unfortunately. If you try to change your code to use the Enabled property instead in the uvCycler.js you will get it to work.

P.S. Lets continue this discussion either in a new issue or email, just to get clarity on this Issue. :)

Best regards,
Jawad