1. 21 Apr, 2011 1 commit
  2. 19 Apr, 2011 1 commit
  3. 15 Apr, 2011 2 commits
  4. 14 Apr, 2011 1 commit
  5. 12 Apr, 2011 1 commit
    • Joel Martin's avatar
      input.js: adjust special key handling for non-US keys. · fac149dd
      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.
      fac149dd
  6. 06 Apr, 2011 2 commits
  7. 05 Apr, 2011 3 commits
    • Joel Martin's avatar
      0a920147
    • Joel Martin's avatar
      Fix copyright year to 2011. · d0c29bb6
      Joel Martin authored
      d0c29bb6
    • Joel Martin's avatar
      Refactor keyboard event handling. · c96f9003
      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).
      c96f9003
  8. 03 Apr, 2011 2 commits
  9. 29 Mar, 2011 2 commits
  10. 26 Mar, 2011 1 commit
  11. 25 Mar, 2011 1 commit
  12. 24 Mar, 2011 1 commit
  13. 22 Mar, 2011 1 commit
    • Joel Martin's avatar
      Higher connectTimeout default with web-socket-js. · 81bcf70f
      Joel Martin authored
      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.
      81bcf70f
  14. 16 Mar, 2011 1 commit
    • Joel Martin's avatar
      Update web-socket-js to bb5797cad. · bbd21ca7
      Joel Martin authored
      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).
      bbd21ca7
  15. 15 Mar, 2011 1 commit
  16. 14 Mar, 2011 1 commit
  17. 23 Feb, 2011 2 commits
  18. 19 Feb, 2011 1 commit
  19. 05 Feb, 2011 1 commit
  20. 03 Feb, 2011 1 commit
    • Joel Martin's avatar
      Add logo, favicon. · 159ad55d
      Joel Martin authored
      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.
      159ad55d
  21. 02 Feb, 2011 1 commit
  22. 01 Feb, 2011 1 commit
  23. 31 Jan, 2011 3 commits
  24. 24 Jan, 2011 3 commits
    • Joel Martin's avatar
      Opera 11 WebSockets and Opera '-' key mapping fix. · 7cc5fbc5
      Joel Martin authored
      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.
      7cc5fbc5
    • Joel Martin's avatar
      websock.send returns true/false. · 1756a30a
      Joel Martin authored
      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.
      1756a30a
    • Joel Martin's avatar
      Tolerate some bufferedAmount. · 8b502df2
      Joel Martin authored
      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.
      8b502df2
  25. 19 Jan, 2011 3 commits
  26. 18 Jan, 2011 2 commits