- 23 Jul, 2013 1 commit
-
-
samhed authored
-
- 11 Jul, 2013 1 commit
-
-
samhed authored
-
- 08 Jul, 2013 1 commit
-
-
samhed authored
* The trigger distance now takes devicePixelRatio into account.
-
- 03 Jul, 2013 1 commit
-
-
samhed authored
-
- 25 Jun, 2013 1 commit
-
-
Samuel Mannehed authored
to make double clicking on touch devices easier a double click is now triggered when two mouse clicks occur within 500 milli seconds and closer than 50 pixels together
-
- 13 Jun, 2013 1 commit
-
-
Phil Driscoll authored
-
- 30 Jan, 2013 2 commits
- 23 Dec, 2012 1 commit
-
-
Hirokazu Takahashi authored
Firefox 17 generates 173 as the keycode for the minus key.
-
- 17 Oct, 2012 1 commit
-
-
Joel Martin authored
This reverts commit 079504a6.
-
- 15 Oct, 2012 1 commit
-
-
Joel Martin authored
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
-
- 06 Oct, 2012 1 commit
-
-
Blindauer Emmanuel authored
-
- 25 Sep, 2012 1 commit
-
-
Hirokazu Takahashi authored
-
- 02 Aug, 2012 1 commit
-
-
BLINDAUER EMMANUEL authored
-
- 26 Apr, 2012 1 commit
-
-
Joel Martin authored
Unfortunately the values for those duplicate keys are not the same and I'm not sure which ones are more correct. However, for now, I've commented out the second occurrence. This data is generated from /usr/include/X11/keysymdef.h using the utils/u2x11 script.
-
- 14 Mar, 2012 1 commit
-
-
Joel Martin authored
May window managers have a keyboard shortcut that switch away from the current desktop (e.g. desktop switcher). Unfortunately, when this happens, the meta/control keys that are used with the shortcut will send a down event to the browser, but the up event will never be sent because the browser no longer has focus at the point when the up event happens. This can cause weird stuck key issues for VNC clients (not just noVNC). To get around this, we try and detect when the browser loses focus and release any keys that are on the keyDownList. As an aside, if you run into this situation (in noVNC or another VNC client), you can unstick the state by pressing and releasing the Ctrl, Shift, Alt, etc. Addresses: https://github.com/kanaka/noVNC/pull/135
-
- 08 Sep, 2011 1 commit
-
-
Chris Gordon authored
-
- 24 Jul, 2011 1 commit
-
-
Joel Martin authored
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.
-
- 11 May, 2011 2 commits
-
-
Joel Martin authored
- Add conf_defaults which accepts an array of configuration attributes. - Split out user configuration defaults from the actual configuration object. - Add mode field and enforce read-only, write-once, read-write modes.
-
Joel Martin authored
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
-
- 29 Apr, 2011 1 commit
-
-
Joel Martin authored
Still buggy so not yet activated in the UI, but the hooks are at least here.
-
- 15 Apr, 2011 2 commits
-
-
Joel Martin authored
Issue #21 - non-US key handling.
-
Joel Martin authored
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.
-
- 14 Apr, 2011 1 commit
-
-
Joel Martin authored
Requested by Alexander Larsson at Red Hat to allow incorporation of solution into HTML5 gtk 3.0 backend.
-
- 12 Apr, 2011 1 commit
-
-
Joel Martin authored
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.
-
- 05 Apr, 2011 1 commit
-
-
Joel Martin authored
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).
-
- 03 Apr, 2011 1 commit
-
-
Joel Martin authored
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.
-