API changes:
- include/canvas.js renamed to include/display.js
- Display.rescale() method removed from API. Use Display.set_scale() instead.
- Make logo configuration attribute of Display and display it when
clear() is called if it is set.
API deprecations:
- use RFB onUpdateState instead of updateState.
- use RFB onClipboard instead of clipboardReceive.
See https://github.com/kanaka/noVNC/wiki/ModuleAPI for detailed noVNC
modules and API description.
Expand and normalize the event/callback interfaces. Standize on
"onEventName" form for callbacks.
Callback Renames:
- RFB updateState -> onUpdateState
- RFB clipboardReceive -> onClipboard
- Keyboard keyPress -> onKeyPress
- Mouse mouseButton -> onMouseButton
- Mouse mouseMove -> onMouseMove
Callback Additions:
- RFB onPasswordRequired
- RFB onBell
- RFB onFBUReceive
- RFB onFBUComplete
Other:
- Add array type support to Util.conf_default()
- Removed a bunch of routines from the Display API that were just used
internally and not actually by noVNC: flush, setFillColor,
imageDataGet, imageDataCreate, rgbxImageData, rgbxImageFill,
cmapImageData, cmapImageFill.
- More keyboard/mouse logging when debug turned on.
- Some JSLinting
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).
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.
Joel Martin
Joel Martin