Related to issue/pulls:
https://github.com/kanaka/noVNC/issues/194
https://github.com/kanaka/noVNC/pull/201
https://github.com/kanaka/noVNC/pull/202

In IE9, the window.onload event can fire before dynamically loaded
scripts have finished loading. This can result in either WebSocket (in
the case of vnc_auto.html) or RFB (in the case of vnc.html) not being
defined at the point when window.onload is called.

- Move the load_scripts routine from vnc.js to util.js (so that
  websockify can use it too). Also, refactor to work when load_scripts
  is called by a script that itself uses load_scripts. When the whole
  chain of dynamically loaded scripts is finished then call
  window.onscriptsload. Use this mechanism in all the places that
  depend on dynamic loading of scripts: vnc.html, vnc_auto.html,
  websock.js, tests/vnc_playback.html, and tests/vnc_perf.html.

- Use the new window.onscriptsload handler instead of window.onload.

- Remove include/start.js and do the script loading and startup event
  handling in include/ui.js instead.

The MPL 2.0 license is a "file-level" copyleft license vs the
"project-level" nature of the L/GPL. The intention of noVNC has
always been that it should be easy to incorporate into existing
projects and sites whether free/open or proprietary/commercial. The MPL
2.0 is designed for this sort of combination project but still
requires that any distributed modifications to noVNC source files must
also be published under the same license.

In addition, the MPL 2.0 allows the code to be used in L/GPL projects
(the secondary license clause). This means that any projects that are
already incorporating noVNC should not be impacted by this change and
in fact it should clarify the licensing situation (the exact
application of the L/GPL to web applications and interpreted code is
somewhat ambiguous).

The HTML, CSS, image and font files continue to be under more
permissive licenses (see LICENSE.txt). The included websockify python
code remains under a LGPLv3 license although the include/websock.js
file from the websockify component is now under MPL 2.0 as well.

Permission was received from other noVNC authors to make this change to their
code license on the following dates:

    - Chris Gordon (UI): Jun 24, 2012
    - Antoine Mercadal (DOM,*util.js): Oct 10, 2012
    - William Lightning (UltraVNC repeater): Oct 10, 2012
    - Mike Tinglof (tight encoding): Oct 15, 2012

API changes (forward compatible):

- Display: add 'viewport' conf option to turn on and off viewport
  mode.
- RFB: add 'viewportDrag' option to enable/disable viewport dragging
  mode.

Other:

- Add clip mode setting to default UI. For touch devices, clipping is
  forced on.
- Use CSS media queries to adjust visual elements based on screen
  size. Especially disconnected logo size/position and button text size.
- Catch page unload while connected and give a confirm dialog.
- Change mouse button selector to a single button that changes between
  ' ', 'L', 'M', 'R' when clicked (empty means mouse is just being
  moved and doesn't send clicks).
- include/ui.js:setViewClip() routine sets the clipping of the
  viewport to the current size of the viewport area (if clipping is
  enabled).
- include/ui.js:setViewDrag() toggles/enables/disables viewport
  dragging mode.
- Add several images for the UI and for Apple devices:
    - images/clipboard.png: clipboard menu icon
    - images/connect.png: connect menu icon
    - images/disconnect.png: disconnect button icon
    - images/keyboard.png: show keyboard button
    - images/move.png: viewport drag/move toggle button
    - images/settings.png: settings menu icon
    - images/screen_320x460.png: iOS app/desktop link start image
    - images/screen_57x57.png: iOS app icon
    - images/screen_700x700.png: full size noVNC image

Part of mobile device support:
https://github.com/kanaka/noVNC/issues/48

The Display object is redefined as a larger display region with
an equal or smaller visible viewport. The size of the full display
region is set/changed using resize(). The viewport is set/changed
using viewportChange().

All exposed routines that draw on the display now take coordinates
that are absolute (relative to the full display region). For example,
the result of fillRect(100, 100, 10, 10, [255,0,0]) will appear in the
canvas at (0,0) if the viewport is set to (100,100).

Details:

- Move the generic part of the viewport code from tests/viewport.html
  into include/display.

- Add two new routines to the Display interface:

    - viewportChange(deltaX, deltaY, width, height)
        - This adjusts the position of the visible viewport and/or the
          size of the viewport.

        - deltaX and deltaY specify how the position of the viewport
          should be shifted. The position of the viewport is clamped
          to the full region size (i.e. cannot outside the display
          region).

        - The clean and dirty regions of the display are updated based
          on calls to this routine. For example, if the viewport width
          is increased, then there is now a dirty box on the right
          side of the viewport. Another example, if the viewport is
          shifted down and to the left over the display region, there
          are now two dirty boxes: one on the left side and one
          on the bottom of the viewport.

    - getCleanDirtyReset()
        - This returns an object with the clean box and a list of
          dirty boxes (that need to be redrawn).

            {'cleanBox':
                {'x': x, 'y': y, 'w': w, 'h': h},
             'dirtyBoxes':
                [{'x': x, 'y': y, 'w': w, 'h': h}, ...]
             }

        - The coordinates in the clean and dirty boxes are absolute
          coordinates (relative to the full display region) but they
          are clipped to the visible viewport.

        - Calling this function also resets the clean rectangle to be
          the whole viewport (i.e. nothing visible needs to be redrawn
          dirty) so the caller of this routine is responsible for
          redrawing any

Tested on iOS (iPhone and iPad).

The viewport is correctly clipped to the screen/browser size and
resizing works correctly.

This uses the CSS3 Flexible Box Layout model.

Tested with an iPad 2.

This example shows a 400x200 viewport of an 800x400 display.

It tries to be intelligent about how much it redraws. It copies what
it can, and then when the user releases the mouse, it redraws the
"dirty" areas that were newly revealed.

First crack at supporting touch screen for devices like Android and
iOS tablets. Part of https://github.com/kanaka/noVNC/issues/48.

This change detects touch screen support and uses the touchstart,
touchmove, touchend events in place of the normal mouse events.

In order to support middle and right mouse clicks, if the device is
a touch device, then three toggle buttons are added to the UI
representing the left, middle and right mouse buttons. These select
which mouse button will be sent when the screen is touched. All the
buttons can be toggled off, in which case then the touch events only
move the mouse cursor rather than sending a mouse down and mouse up
for touchstart and touchend events respectively. This allows fairly
full control with the mouse on touch screens.

Instead of R,G,B (red-shift of 0, green-shift of 8, and blue-shift
of 16), use the default ordering of B,G,R (red-shift of 16, green-shift of 8, and blue-shift
of 0) that tightvncserver uses (and that VMWare's VNC server seems to
require). Also, warn in the console if the server does not default to
the new format.

Fix the tests/canvas.html test. This is a general fix with regards to
the rename/refactor of canvas.js into display.js and not specific to
the color re-ordering.

- Update test mode calls to work with separate websock module.

- Pull in include/websock.js update 7f487fdbd from websockify.

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.

This allows tests to work on the github pages site.

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

To go along with addition of performance notes to the website.

https://github.com/kanaka/websockify is now the canonical location of
websockify (formerly wsproxy). A copy of the python version is kept
here for backwards compatibility and ease-of-use. The other versions
and related test scripts are in websockify.

- add dup2 functionality. This requires adding a ref cnt to the
  _WS_connections structure so that we only free the structure once
  all dup'd referenced are closed. Also, refactor malloc and free of
  connection structure into _WS_alloc and _WS_free.
- allow select to accept a NULL timeout value which means sleep
  forever instead of segfaulting.
- fix some compile warnings related to ppoll definition.
- move some WebSockets related html test pages into utils and symlink
  them from tests.

Moved websocket.py code into a class WebSocketServer. WebSockets
server implementations will sub-class and define a handler() method
which is passed the client socket after. Global variable settings have been
changed to be parameters for WebSocketServer when created.

Subclass implementations still have to handle queueing and sending but
the parent class handles everything else (daemonizing, websocket
handshake, encode/decode, etc). It would be better if the parent class
could handle queueing and sending. This adds some buffering and
polling complexity to the parent class but it would be better to do so
at some point. However, the result is still much cleaner as can be
seen in wsecho.py.

Refactored wsproxy.py and wstest.py (formerly ws.py) to use the new
class. Added wsecho.py as a simple echo server.

- rename tests/ws.py to utils/wstest.py and add a symlink from
  tests/wstest.py

- rename tests/ws.html to tests/wstest.html to match utils/wstest.py.

- add utils/wsecho.py

- add tests/wsecho.html which communicates with wsecho.py and simply
  sends periodic messages and shows what is received.

Related to issue Non-US keyboard layout option issue:
https://github.com/kanaka/noVNC/issues#issue/21

Rename the $() selector to $D() so that it doesn't collide with
the jQuery name.

The API change is that the 'target' option for Canvas and RFB objects
must now be a DOM Canvas element. A string is no longer accepted
because this requires that a DOM lookup is done and the Canvas and RFB
should have no UI code in them. Modularity.

- Also, discovered node.js bug in base64 decoding. Added test case and
  filed https://github.com/ry/node/issues/issue/402

 - util.js that contains essential functions
 - webutils.js that contains the GUI utility function.js

this helps to include noVNC in other project, especially Cappuccino Application
i

- include/rfb.js: Keep track of the number of rects of each encoding
  type and print them out when we close a connection (if 'info'
  logging level).

- tests/vnc_perf.html: first pass at a noVNC based performance
  benchmark.

- utils/wsproxy.py: Fix the output of the record filename.

- include/canvas.js: When 'debug' logging, show browser detection
  values.
- test/canvas.html: Only restore the canvas to it's starting state if
  the logging level is not 'debug'.
- wsproxy.py: Append the session number to the record filename so that
  multiple sessions don't stomp on each other.

Easier to reference from web site (gh-pages branch).

Preparation for online demo.

Split general playback code into tests/playback.js.

Use timestamps from recording with proxy to playback in realtime.

It's less efficient on average that base64 (150% vs 133%). It's
non-standard (0 shifted to 256 before encoding). And I rarely use it.

Generally, most servers send hextile updates as single updates
containing many rects. Some servers send hextile updates as many small
framebuffer updates with a few rects each (such as QEMU). This latter
cases revealed that shifting off the beginning of the receive queue
(which happens after each hextile FBU) performs poorly.

This change switches to using an indexed receive queue (instead of
actually shifting off the array). When the receive queue has grown to
a certain size, then it is compacted all at once.

The code is not as clean, but this change results in more than 2X
speedup under Chrome for the pessimal case and 10-20% in firefox.

- This allows the recorded data to be immediately usable by
  tests/vnc_playback.html

Turns out when Windows is running in QEMU and a window scroll happens,
there are lots of little hextile rects sent. This is slow in noVNC.

- Some recording/playback improvement.
- Add test harness to drive playback of recordings.
- By pulling off the rect header in one chunk we get a 3X speedup in
  Chrome and a 20% speedup in firefox (specifically for the scroll
  test).
- Also, get rid of some noise from creating timers for handle_message.
  Check to make sure there isn't already a pending timer first.