Another episode in the revolution against mouse-requisite interfaces. It's
one more step towards impulse-driven computing.
Enough marketing jargon. keynav is a piece of an on-going experiment to
make pointer-driven interfaces easier and faster for users to operate. It
lets you move the pointer quickly to most points on the screen with only a
few key strokes.
Note that I said pointer, not mouse. The mouse simply drives the pointer.
We can drive the pointer with other devices too. keynav turns your keyboard
into an fast pointer mover.
You select a piece of the screen. The screen is initially wholely selected.
One move will cut that region by half. A move is a direction: up, down,
left, and right.
Once you're done moving, you simply indicate (with a key stroke) that you
want to move. Boom, cursor moves.
keynav is geared towards selecting a piece of the screen very quickly.
Recall from above that you are selecting a region by cutting the previous
region by half. This gives us logarithmic scaling. High resolution screens
incur about the same number of moves to select an area as smaller screens
do.
For example, to select
any pixel on a screen with resolution
1920x1200 it would take 21 moves. 21 moves is horrible. There is a bright side!
How often do you really want to click on a single specific pixel on your screen using your mouse? Never, right? Well, maybe almost never. Most of the time you want to:
- Raise a window and give it focus: 80x80 pixel target (worst: 9 moves)
- Click on an "OK" button: 60x25 pixels (worst: 11 moves)
- Click on a text widget to activate it: 80x25 or larger
Bored of reading? How about a screencast demonstration? Click
here or the image below.
Hopefully the demo gives you a good idea of what keynav does.
The keynav users mailing list is: keynav-users@googlegroups.com
I'll be announcing new versions on this mailing list. Additionally, if you
want help or want to contribute patches to keynav, the mailing list is a
good place to go.
keynav is currently written in C and only works in X11 (Unix graphics
environment). I am planning on porting keynav to both Windows and OS X. If
you are interested in helping me with this, please contact me!
Known working:
- FreeBSD + Xorg 6.9.0
- FreeBSD + Xorg 7.2.0
- Ubuntu Dapper + Xorg 7.0.0
- Ubuntu Feisty + Xorg 7.2.0
- Ubuntu Hardy + Xorg 7.2.0
- Cygwin + Xorg 6.8.x
- Fedora 9
I've seen strong interest in this software working on other platforms, so
I'm doing the best I can. Again, if you're a .NET (or just Windows) or OS X
coder, and are willing to help port this, let me know. It's only 200 lines
of C in Xlib, so it can't be more than a one-day-long project.
keynav-20080614.01.tar.gz
Looking for an older version? Try the
keynav releases archive
make keynav
The above should be all you need to do.
Run keynav, and activate it by pressing Control+Semicolon. You should see a
thin frame on the screen with a cross in it.
The following is the default configuration:
- h : select the left half of the region
- j : select the bottom half of the region
- k : select the top half of the region
- l : select the right half of the region
- shift+h : move the region left
- shift+j : move the region down
- shift+k : move the region top
- shift+l : move the region right
- semicolon : Move the mouse to the center of the selected region
- spacebar : Move the mouse and left-click
- escape : Cancel the move
Your config file must live in ~/.keynavrc. Such as /home/jls/.keynavrc
The config file format consists of a keysequence followed by a
comma-separated list of commands. For example:
space warp,click 1,end
This would move the mouse, click left mouse button, and finish (close the
keynav selector) when you hit spacebar while keynav was active. A sample
config file comes with the distribution as 'keynavrc'.
The following is a list of key modifiers: shift, ctrl, alt, or any valid X
Keysym, such as Shift_L, etc.
List of commands:
- start
- Activate keynav
- end
- Deactivate keynav
- cut-left, cut-right, cut-up, and cut-down
- Cut half of the selection in a given direction. For example,
cut-left will select the left half of keynav selector region. If you
attempt to cut the window too small, the operation will abort. Cut can
take a percentage value to cut by. The default is ".5"
- move-left, move-right, move-up, move-down
- Move the selector window a given direction. The movement amount is
equal to the width or height of the selector depending on the direction.
You cannot move the window outside the bounds of the screen. Move can
take percentage value that specifies the distance relative to the size of
the window. The default is "1.0"
- warp
- Move the mouse to the center of the selector
- click <button>
- Click the given mouse button once. 1 == left, 2 == middle, 3 == right.
- doubleclick <button>
- Click the mouse button twice, quickly. This can also be achieved by
doing "click 1,click 1" in your command sequence.
- drag <button> [keyseq]
- Toggle dragging mode for the given button. If
keyseq
is given then that keysequence is held during the initial mouse button
down event. This is useful in invocations such as 'drag 1 alt' to do a
alt+click-drag on a window to move it.
- grid <rows>x<columns>
[Added 20080509]
- Change the grid layout of the selection. For example, specifying
'grid 3x3' will divde the screen selection into 9 cells, 3 rows and 3
columns. Specifying 'grid 2x3' will divide the screen selection into 6
cells, 2 rows and 3 columns.
- cell-select <row>x<column> OR cell-select <cell>
[Added 20080509]
- Select a specific cell in the grid. The NxM syntax selects the
specific row and column. The single number syntax selects the cell
numbered counting from the top left to the bottom left. For example, a 3x3 grid would be numbered this way:
1 2 3
4 5 6
7 8 9
Allow me to make an analogy.
You approach an elevator. To call the elevator, you aimlessly smack the
button with you hand. Your hand hits the button and activates it, calling
the elevator. You also make significant contact with the wall. Nothing else
happens because the wall doesn't do anything when you press it. There's a
benefit of having your whole hand (large) to use in an attempt to press the
elevator button (small).
With computers, the relationship is different. Your hand is extremely tiny
in size and the targets are somewhat larger. This allows us some degree of
imprecision when clicking but we must remain within the confines of the
button to successfully click it. The goal is like hitting the broad side of
a barn with a baseball. Sounds, easy, right?
What if we use a barn to hit a baseball? The game gets much easier. What
happens if you use keynav to zoom "close enough" to a button, and simply
say "click the button inside this box". The effect is that you "slap" the
selected region and activate whatever button or interactive element.
An example follows. It is a partial screenshot of the downloads window in Firefox.
If we throw the a baseball at the button, we have to hit the small red
area. If we throw a barn at the button, we have a much much larger area of
possible effect.
This is delightful, because we can be less accurate with our clicks. It
comes with some trade-offs though.
- Sometimes I want to click on the pixel my mouse is actually on
- The "barn" approach may hit more than one interface element that is clickable.
I believe both of these can be solved. The first is simple. The next
requires more thought. Perhaps a means by which to select specific elements
in the selected area? Who knows. More research will help.
