Search this site


Page 1 of 2  [next]

Metadata

Articles

Projects

Presentations

New keynav release available (0.20101014)

The keynav project gets a upgrade today. Some small feature additions and bug fixes.

Download: keynav-0.20101014.3067.tar.gz

Changes from the previous release:

0.20101014.*
  - Added 'restart' command. Makes keynav restart. Useful for binding a key to
    reload the config.
  - Added 'loadconfig' command. This lets you include additional config files
    to load on the command line or in one of the default keynavrc files.
    (requested by Axel Beckert)
  - keynav will now restart if it receives SIGHUP or SIGUSR1
  - Map 'Enter' by default to 'warp,click 1,end' (requested by Axel Beckert)
    by Axel Beckert)
  - Fix a bug causing the point under the mouse cursor to not click through the
    keynav window in certain conditions. Reported via mailing list by Eric Van
    Dewoestine and Krister Svanlund.

New keynav release available (0.20100302)

It's time for a new keynav release. The main push for this release was to fix problems with building against the new libxdo (xdotool) versions.

Additionally, there is one new feature: "record"

Recording lets you record a series of actions in keynav and replay them later much like you would in vim. Only keynav actions are recorded.

0.20100302.*:
  - Started using glib for dynamic arrays (GPtrArray)
  - Uses new versioning scheme major.date.svnrev
  - Added 'version' (or -v or --version) to output the keynav version
  - Now requires libxdo.so.1 (via xdotool)
  - Add ability to record keynav actions with the 'record' command. Optional argument
    is a filename to save the recordings to for persistence across keynav runs.
    Example in keynavrc to bind 'q' to record to ~/.keynav_macros:
      q record ~/.keynav_macros
    Works similar to vim recording.
      1) Hit record once
      2) Type the key you want to record to
      3) Do things in keynav you want recorded.
      4) Any 'end' operation or hitting record again will terminate and save
         this recording.
    Recordings only persist if you specify a file to save to, otherwise they are lost
    across keynav restarts.

20091231.04:
  - Try repeatedly to grab the keyboard with XGrabKeyboard on 'start' commands.
    This loop is a necessary workaround for programs like xbindkeys that could
    launch keynav but at the time of launch still hold a keyboard grab
    themselves. Reported by Colin Shea.

20091231.02:
  - Nonfunctional bug fixes and other code cleanup from patches by Russell Harmon

new keynav version available (20091231)

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

The changelist from the previous announced release is as follows:

20091231.04:
  - Try repeatedly to grab the keyboard with XGrabKeyboard on 'start' commands.
    This loop is a necessary workaround for programs like xbindkeys that could
    launch keynav but at the time of launch still hold a keyboard grab
    themselves. Reported by Colin Shea.

20091231.02:
  - Nonfunctional bug fixes and other code cleanup from patches by Russell Harmon

20091231.01:
  - Some internal code refactor/cleanup
  - Reduce drawing flicker by drawing to a Pixmap and blitting to the window.
  - Allow commands to be given on keynav startup. (Reported by Colin Shea)
    The same commands valid as keybindings are valid as startup commands:
    % keynav "start, grid 3x3"
  - Allow clicking through the keynav grid window area (Reported by Yuri D'Elia)
  - Support daemonizing using the 'daemonize' command in keynavrc. Added an
    example to the distributed keynavrc.
  - Use new library features given by xdotool/libxdo 20091231.01

20091208:
  - Support linking against libxdo.so if it is found, otherwise we build xdo.o
    into keynav. The original intent of including xdotool in the release package
    was to make make it easy to build keynav without a packaging system. Now
    that more distros have keynav and xdotool, this requirement is less
    important.

    This change is in response to Debian rqeuest:
      http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560103
keynav-20091231.02

new keynav version available (20091108)

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

The changelist from the previous announced release is as follows:

20091108:
  - Added xinerama support.
    * Default 'start' will now only be fullscreen on your current xinerama
    display. You can move between screens by using the move-* actions to move
    the current selection outside the border of the current screne.
  - All xdotool commands now return integers so we can forward their return
    status to the user.
  - Actually handle SIGCHLD now so the shell commands get reaped on exit.

keynav with xinerama support

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.

keynav in Xinerama

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.

keynav shell command examples

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

new keynav version available (20080614.01)

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.

new keynav version available (20080522)

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.)

Impulse-driven computing

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!