This is the same post I made to the keynav-users mailing list

I just finished working on the xinerama portion of multi-screen support for keynav.

If someone is interested, I could use some help testing. It's working for me, and there are a few odd behaviors that I'm not sure are the best. Let me know if you test it.

No new official release yet, but if you want to test, svn can be fetched with:
svn checkout http://semicomplete.googlecode.com/svn/keynav

- Include support for multiple screens.
  * When 'start' happens, the region will be the size of the current display
    (wherever the mouse is)
  * Moving the region outside of the current display will move it to the next
    display (right or left). This currently only works with Xinerama.
  * History works as expected (move to the right display, history-back goes to
    the previous display, etc)
  * When multiple Screen (non-xinerama) are found, XGrabKey on all root windows.
  * Screens are sorted, if possible, from left-to-right based on x-coordinate
    origin. This unfortuntely means, for now, only left-to-right monitor
    configurations are known to be supported.

I've got a dual-head setup now that has unequal resolutions. Keynav kind of sucks when this situation occurs, so I'm adding multiple-screen and Xinerama support to keynav. I'll update here when it's done.

Press 'f' when keynav is active and instantly jump to my firefox window.

# in .keynavrc
f sh "activate-firefox.sh", end

Now, in activate-firefox.sh:

#!/bin/sh
# activate-firefox.sh
xdotool windowactivate $(xdotool search -title -- '- Mozilla Firefox')

Extend that and press 'g' to jump to gmail, assuming that tab is open. (Requires my firefox tabsearch plugin)

# in .keynavrc
g sh "activate-gmail.sh"

Now, in activate-gmail.sh:

#!/bin/sh
# activate-gmail.sh

./activate-firefox.sh
xdotool key ctrl+apostrophe
xdotool type gmail
xdotool key Return

Hop on over to the keynav project page and download the new version.

The changelist from the previous announced release is as follows:

20080614.01:
  - Several bug fixes and feature additions suggested by Yuri D'Elia.
  - Sync xdotool library to 20080606
  - Added default key binding Ctrl+[ as 'end' (requested by Luke Macken)
  - New command: 'sh' - Executes shell commands.
    Example keynavrc: ctrl+x sh "xterm -bg black -fg white"
  - New command: 'history-back' - Undo a window change operation
    Example keynavrc: a history-back
    + Such operations include: cut-*, grid, cell-select, move-*
    + The history size is currently hard-coded at 100 entries.
    + If you exceed 100 moves, the oldest entry will be removed.
    + Every time keynav is activated, the history is wiped.
  - Fix: Any command starting with "start" is now bound globally.
  - Fix: All rendering is delayed until after the end of the current command
    sequence. This fixes (in order of annoyance, worst first):
    1) Crash when a 'start' and 'end' exist in the same command sequence.
    2) Visible 2x2 grid first, before a 3x3 grid when the start command is
       'start, grid 3x3'
    3) Rendering blinking a full white window on the screen before clipping to
       the grid.
    4) Visible blink when "cut-left,cut-up" and such are run simultaneously.
  - Fix: If the 'start' command is invoked again while keynav is active, then
    the default arrangement is set (full screen and 2x2 grid). Previously, the
    'start' command was a no-op if keynav was active.

Hop on over to the keynav project page and download the new version.

The changelist from the previous announced release is as follows:

20080522:
  - Sync xdotool library to 20080521.
  - Added 2 grid examples to keynavrc
  - Applied patches from Richard Kolkovich
    + Fix backwards math when calculating Nth cell when using 'cell-select N'
    + Fix dislexia when doing 'cell-select NxM'
    + Abort update() calls when app is inactive.
  - Now warns you if you try to execute an invalid command.

(Yes, 0522 is tomorrow. Turns out uploads to googlecode are write-once, so I'll need to come up with an additional versioning scheme that lets me push multiple releases in a single day in case I find something bad after I upload a release.)

Muscle memory is great. Are there flexible, programmable tools which let you turn a set of potentially-complex actions into something muscle-memory trainable?

I suspect making a generic tool to do this would be difficult. keynav and xdotool aim to solve some of these problems, but what about some of the more complex ones? Is it worth trying to solve these edge cases with automation? Specifically, I mean solutions where programatically you'd be talking to two or more separate systems (or APIs).

One specific set of problems is because X11's default clipboard buffer is not the same thing as GTK's clipboard buffer. So, in firefox, using 'middle click' to paste gives me X11's clipboard while CTRL+V gives me GTK (firefox)'s clipboard contents. It's likely I'm calling this thing "X11's clipboard" when it's really the "X11 Selection". It seems simple to write a tool that would copy X11's current selection to GTK's clipboard.

You could have code that looked like this, but it wouldn't be efficient:

while true:
  if gtk_clipboard_changed:
    set_x11_clipboard(value)
  else if x11_clipboard_changed:
    set_gtk_clipboard(value)

You could make that not chew up cpu by adding a small sleep at the end of each iteration, but that still sucks. From what I can tell, GTK has a way to block for clipboard changes, but X11 may not.

If the X11 application uses cut buffers, then the root X window gets notifications about cut buffer changes. However, copying stuff in firefox doesn't show any cut buffers being used.

Alternately, we could hack our own "ctrl+v" functionaly by grabbing that keystroke, or by grabbing a different, unrelated keystroke, which would do:

1. copy primary selection to clipboard
2. send literal "ctrl+v"
3. restore clipboard

Update: An existing tool will keep your selection and clipboard buffers in sync: autocutsel. Looks like it uses the sleepy-loop approach I mentioned, but it does work. Awesome!

I got enough feature requests for grid support (in various layouts) that I decided it was time to add generic grid support. You can now use grid movement on grids of any configuration, 2x2, 3x3, 2x3, etc.

Hop on over to the keynav project page and download the new version.

The changelist from the previous announced release is as follows:

  Feature request: Grid support.
  * New command: 'grid NxM' N and M are row and columns, respectively.
    You can divide the screen into any number of rows and columns.
    The default is 2x2.
  * New command: 'cell-select N' or 'cell-select NxM'
    With this command you can select a specific cell to zoom to.
    Usage: cell-select N
      Selects the Nth cell, counting from top left to bottom right.
      The order of a 3x3 grid would be:
        1 2 3
        4 5 6
        7 8 9
    Usage: cell-select NxM
      Selects the specific cell at NxM. '2x2' will select row 2 column 2.

  Other important changes:
  - Whitespace before command names works now.
  - Added a pile of new examples in keynavrc.

I've been slightly overwhelmed with email about keynav in the past few days. To help with this, I've created a mailing list for the project.

Email: keynav-users@googlegroups.com Home: http://groups.google.com/group/keynav-users

I'll post announcements there in addition to this site. Questions should be directed to the mailing list. :)

Hop on over to the keynav project page and download the new version.

The changelist from the previous announced release is as follows:

  Bug fix:
    If you tried to override an existing key binding, it would add a 2nd
    binding for that key instead of actually overriding it.
  Reported by Tim Schumacher.

Hop on over to the keynav project page and download the new version.

The changelist from the previous announced release is as follows:

20080501:
  Patches from Mark (20080501)
   * ~/.keynavrc extends defaults rather than replacing them
   * "clear" in ~/.keynavrc resets keybindings
   * comments can appear anywhere on a line

  Patches from Eric (20080501)
   * If the move or size value is greater than 1.0, then assume it is an absolute value.

  Patches from Lukas Mai (20080429)
   * Fixes a few minor bugs
   * Clean up to compile without most warnings when -pendantic and -Wall are enabled.