Still buggy so not yet activated in the UI, but the hooks are at least
here.

Separate the links from each other so it's obvious where the links
are.

github changed something about relative links.

Derived classes will almost certainly want to make use of the raw
info.

Issue #21 - non-US key handling.

Issue #21 - non-US keyboard layouts.

The code section for tab, backspace and enter was commented out for
testing but got checked in that way. Fix that.

Requested by Alexander Larsson at Red Hat to allow incorporation of
solution into HTML5 gtk 3.0 backend.

Issue #21 - non-US keyboard layouts.

Only identify some keys as special during the keyDown event so that
when using non-US keyboards the values don't overlap with the values
for normal keys.

Some keys have to still be identified in both keyDown and keyPress
since they generate both: backspace and enter for Firefox and Opera,
tab for Opera.

Also clarify usage statement with legend height adjustment.

Remove console.log in arrays.js so that it works in firefox without
firebug.

This is part of addressing issue #21 - non-US keyboard layouts.

There are several challenges when dealing with keyboard events:
  - The meaning and use of keyCode, charCode and which depends on
    both the browser and the event type (keyDown/Up vs keyPress).
  - We cannot automatically determine the keyboard layout
  - The keyDown and keyUp events have a keyCode value that has not
    been translated by modifier keys.
  - The keyPress event has a translated (for layout and modifiers)
    character code but the attribute containing it differs. keyCode
    contains the translated value in WebKit (Chrome/Safari), Opera
    11 and IE9. charCode contains the value in WebKit and Firefox.
    The which attribute contains the value on WebKit, Firefox and
    Opera 11.
  - The keyDown/Up keyCode value indicates (sort of) the physical
    key was pressed but only for standard US layout. On a US
    keyboard, the '-' and '_' characters are on the same key and
    generate a keyCode value of 189. But on an AZERTY keyboard even
    though they are different physical keys they both still
    generate a keyCode of 189!
  - To prevent a key event from propagating to the browser and
    causing unwanted default actions (such as closing a tab,
    opening a menu, shifting focus, etc) we must suppress this
    event in both keyDown and keyPress because not all key strokes
    generate on a keyPress event. Also, in WebKit and IE9
    suppressing the keyDown prevents a keyPress but other browsers
    still generated a keyPress even if keyDown is suppressed.

For safe key events, we wait until the keyPress event before
reporting a key down event. For unsafe key events, we report a key
down event when the keyDown event fires and we suppress any further
actions (including keyPress).

In order to report a key up event that matches what we reported
for the key down event, we keep a list of keys that are currently
down. When the keyDown event happens, we add the key event to the
list. If it is a safe key event, then we update the which attribute
in the most recent item on the list when we received a keyPress
event (keyPress should immediately follow keyDown). When we
received a keyUp event we search for the event on the list with
a matching keyCode and we report the character code using the value
in the 'which' attribute that was stored with that key.

For character codes above 255 we use a character code to keysym lookup
table. This is generated using the util/u2x11 script contributed by
Colin Dean (xvpsource.org).

API change: for intergrators that explicitly include the Javascript
files (that do not use include/vnc.js)js, include/input.js is a new
file that must also be included.

The mouse and keyboard handling could be useful on its own so split it
out into a Keyboard and Mouse class in include/input.js.

This refactoring is preparation to deal with issue #21 - non-US
keyboard layouts.

Fix mouse button mapping in IE9. All browsers have converged on
a standard left=0, middle=1, right=2 ... all except IE that is.

Add html5 doctype to tests.

In vnc_perf test, use do_test instead of start for function name since
start is a keyword in IE.

In error about Flash give a link to Adobe's download page.

Current timeout is 2 seconds for connect timeout. Use 5 seconds if
web-socket-js (Flash WebSockets emulator) is being used. On Windows XP
with Flash 10.2.152.26, connecting seems to take quite a bit longer
than it probably should. This should make it work more consistently.

Syncs with same change to websockify (7534574a2f).

Primary change is removal of FABridge interface.

Seems to improve overall latency by perhaps 10%. Also, the slowdown
over time in Opera is about half as bad (but still there).

This allows tests to work on the github pages site.

Compares normal Javascript arrays with Canvas ImageData arrays and
Typed Arrays (ArrayBuffers from WebGL).

Thanks to Michael Sersen for creating images/Logo.svg.

- Add images directory with original SVG logo, favicon, and some
  derivative PNGs of the logo for different purpose.

- Note that license on images/* is CC BY-SA.

- Add utils/img2js.py to take an image and generate a base64 encoded
  data URI string.

- Add base64 encoded data URI screen logo to display in canvas when
  disconnected.

Using HTML5 doctype means CSS pixels sizes must have "px" suffix which
many of them did not. Fix that.

Call waitpid in loop to catch SIGCHLD signals that happen while
handling the original SIGCHLD signal.

Pulled from websockify.

API change: changed include path variable from VNC_uri_prefix to
URI_INCLUDE since websock.js uses the variable and websock.js is no
longer just for noVNC (i.e. websockify is really the canonical
location for websock.js).

Changes to get web-socket-js to work. Right now it's a hack to get
around: https://github.com/gimite/web-socket-js/issues#issue/41. The
hack is to disable caching of the flash objects by appending
"?" + Math.random() to the end of the flash object path (but only when
using IE).

Opera 11 native WebSockets (if enabled) seems to have bad behavior for
the bufferedAmount so add change from websockify project to allow max
bufferedAmount (before send queue is delay) to be configured.

Also, Opera 11 and 10.60 behave like Mozilla regarding the '-' key so
translate it correctly.

If all send data was flushed from the send queue then return true,
otherwise false. This doesn't mean the data won't be sent, just that
it wasn't sent this time and is queued.

Only delay sending data if bufferedAmount is greater than 1000.

This seems to match the intention of the spec better. bufferedAmount
does not mean that we can't send, it's just an indication that the
network is becoming saturated. But Opera 11 native WebSockets seems to
have a bug that bufferedAmount isn't set back to zero correctly so
we'll be a bit more tolerant.