Sunday, January 29, 2012

JavaScript Pointer Lock (Mouse Lock) in Chrome Developer Preview

Mouse Lock is the canonical term for when a game (or other application) removes the mouse cursor from view and interprets mouse motion for something else, e.g. looking around in a 3D world. To date this has not been possible for web applications without a plugin, which makes many game genres and other applications just terrible to use. (e.g. forcing users to drag the mouse button to pan the view, while a native application would use the mouse button for something else, e.g. interacting with the world.).

Good news: I've been working on a w3c specification to address this. The feature is available for developers to experiment with now in Chrome (details below). And, a FireFox implementation is on it's way too, thanks primarily to David Humphrey using it as a class project.

Today the first Chrome Canary build is available to try the feature out:

  • Get a build.
    • Chrome Canary builds auto-update daily and install without interfering with your normal installation of Chrome, they're the way to go since they're so easy. Unless your on Linux, where you need to just get a recent Linux Build.
  • Enable pointer lock.
    • Navigate to about:flags, find Enable Pointer Lock, and restart (there's a button below).
  • Try a demo.
    • http://media.tojicode.com/q3bsp/ is a nice one from Brandon Jones and what you see in the screenshot above. It's a quake 3 BSP viewer.
    • Others are sure to show up soon, minutes after landing the keystone WebKit patch I received a few IMs and emails from excited developers. 
  • Go Fullscreen. (more on that later)
    • In Brandon's demo find the fullscreen button in the bottom right corner. (It has to be JavaScript initiated fullscreen, not chrome's "presentation mode".)
  • Allow the site to disable your mouse cursor.
    • This setting is remembered for each site, and can be forgotten in Chrome's preferences / content settings.
  • Read some doc https://developer.mozilla.org/en/API/Mouse_Lock_API.
There's a lot that will be changing with this. First, I have several issues still to deal with in the WebKit implementation, a security review will certainly find more, and oh yeah we're going to overhaul the spec to be as identical as possible to the Fullscreen spec.

Some have asked if pointer lock will be forever restricted to fullscreen mode. No, in fact by the time the JavaScript bindings ship without developer flags I'm hoping to have removed the restriction, and if not then soon after. The only real requirement is that the user not suffer from a poorly behaving website. At the moment that means if a site spams lock requests that we require a user-gesture (e.g. clicking on the web page content, or pressing a key). Fullscreen currently requires the same, so we hide in it's shadow, but I'll implement the check even in windowed mode.

Chrome 19 is the earliest JavaScript pointer lock could ship without a developer flag, but it's predicated on many things coming into place. However, Native Client apps have been able to use it since Chrome 16.

Developers interested in the nitty gritty implementation details can see the chromium bug http://code.google.com/p/chromium/issues/detail?id=72754. To follow along, please only star the issue (top left). If  you've made awesome demos and add this feature, drop a comment here. ;)

Happy locking.

Tuesday, January 17, 2012

Automatic Screen Window Titles in Bash and Vim


I finally configured screen to display the list of windows open with useful titles. Here are the few bits I needed

First, if you don't know what I'm talking about:
I occasionally SSH into work, and when I do I use a program called screen that can host multiple terminal shells. It can persist those shells and allow me to reconnect if I get disconnected or want to change computers I'm working on.

BTW, I always start screen with screen -RaAd -S x

  • -a   include all capabilities ...
  • -A   Adapt  the sizes of all windows ...
  • -d -R   Reattach a session and if necessary detach or even create it first.
  • -S Name of the session


The default configuration makes it hard to keep track of how many terminals you have running, and what they are doing. I made three changes that help my personal workflow:

Add a persistent display at the bottom of screen
In .screenrc I appended this line:
hardstatus alwayslastline "%{=b}%{G} Screen(s): %{b}%w %=%{kG}%C%A  %D, %M/%d/%Y "


Source: Julien Chaffraix, a coworker.

Set the current directory name as the window title from bash
In .bashrc I appended these lines:

if [ "$TERM" = "screen" ]; then
  screen_set_window_title () {
    local HPWD="$PWD"
    case $HPWD in
      $HOME) HPWD="~";;


      ## long name option:
      # $HOME/*) HPWD="~${HPWD#$HOME}";;


      ## short name option:
      *) HPWD=`basename "$HPWD"`;;


    esac
    printf '\ek%s\e\\' "$HPWD"
  }
  PROMPT_COMMAND="screen_set_window_title; $PROMPT_COMMAND"
fi


You can see that I'm using a short name for each directory, e.g. "chromium" instead of the full path or suffix path after my home directory, e.g. "~/projects/chromium". You can toggle the commented lines to try alternates.

Source: http://unix.stackexchange.com/questions/6065/gnu-screen-new-window-name-change.

Set the name of the buffer I'm editing in vim
In .vimrc I appended these lines ("To create ^[, which is escape, you need to enter CTRL+V < Esc"):

if &term == "screen"
  let &titlestring=expand("%:t")
  set t_ts=^[k
  set t_fs=^[\
  set title
endif


Source: http://vim.wikia.com/wiki/Automatically_set_screen_title.