[u-u] Electronic signage...

[Dan Astoorian]

On Wed, 13 Jul 2016 09:37:49 EDT, Colin McGregor writes:
> 
> The first part of displaying the above is easy enough, a browser the
> like of Chromium set up in kiosk mode. The code behind the above
> above, well... Javascript seems to assume a single thread / single
> task, a problem when you could have all of the above bits of
> information needing to (seem to) update simultaneously (yes, the
> events list might only change once a week, sunset time will only
> change once per day and weather forecast will only change a few times
> per day, but worst case they will all need to (appear to) change at
> the same time). AJAX appears to be a possible part of the solution,
> but... Is there an easier way?

We use Raspberry Pis for our signage.  

Some context: we drive the content from the server side.  When the Pis
boot (and once a day in the early morning, as well as on demand), they
fetch their HTML layout from a hard-coded URL on the server and save it
to disk (if the URL is unavailable, it uses the previously-fetched
copy), and points the browser at file:///home/pi/signage.html.  Storing
the file locally has two main advantages: it caches it in case the
server is unavailable when the browser is restarted, and it sidesteps
certain possible browser security restrictions (e.g., mixed active
content restrictions, where the browser won't allow a page fetched via
HTTPS to load a frame via HTTP).

We use frames (via <IFRAME> tags) to break the display into panes.  One
pane links to a slideshow (for which I was not involved in developing),
which uses AJAX to try to refresh its content periodically, but not drop
the slides it's already showing if the server isn't available.  The
other panes are simply set to refresh every few minutes (and I
customized the generic webkit "could not load page" layout with a
friendlier message).  The javascript in each frame is independent, so
this is a fairly simple solution to your threading question.

For your application, I'd probably set up IFRAMEs with file:/// URLs
that reload (via META refresh tags or javascript) at appropriate
intervals, and use cron jobs to fetch the data (or generate it, for the
values that are calculated).

I haven't tried using Chromium for the web browser.  My original
implementation used Midori, but it was compiled against Webkit 1.0, so
it didn't use the GPU's hardware acceleration features, so I switched to
Epiphany, which uses Webkit 3.  That gave me smoother slide transitions,
but it crashed an average of a couple of times a day (I used a watchdog
wrapper script to restart it when it crashed).  I currently use kweb3
1.6.9-1 (see https://www.raspberrypi.org/forums/viewtopic.php?t=40860
for a description of the latest version), which is very lightweight and
has been extremely reliable--I haven't seen any crashes at all (although
I preemptively kill and restart the browser daily to make sure it
doesn't accumulate cruft).

Let me know if you'd like to borrow the javascript I use to shift the
image around slightly to mitigate burn-in.

If you want to try kweb3, this may save you some time: the invocation I
use is
    kweb3 -JKYFr file:///home/pi/signage.html

where -J enables Javascript, -K enables Kiosk Mode, -Y disables video
and audio (which would be played with an external player), -F enables
experimental webkit features (I don't remember why I included that
option), and -r enables reloading via Alt-R (so that the browser can be
reloaded programmatically via 
    xte 'keydown Alt_L' 'key r' 'keyup Alt_L' 
).

Regards,

-- 
Dan Astoorian, Systems Administrator
Engineering Computing Facility
University of Toronto