I spent a while tonight reading up on extended window manager hints. It's not a very well thought-through standard, but many window managers implement it nonetheless.

Tonight I added 7 new commands to xdotool (not yet in a release):

• get and set the number of desktops
• get and set the currently active desktop
• get and set the desktop for a specific window (set == move it to a new desktop)
• activate a window

The first 3 should be pretty straight forward. For fun, I told Gnome2 to create 50 workspaces, and it didn't barf. The taskbar pager looked a little funny as it was sprawling with little desktop views, but it works :)

The last is window activation. It will jump you to the window and give it focus. If the window is on a different desktop, it jumps to that desktop and then activates the window. I've tested exactly that behavior (firefox lives on a separate desktop or workspace) in Gnome2 and ion-3, and it works.

Example: Jump to firefox:

./xdotool windowactivate $(./xdotool search -title "Mozilla Firefox")

Example: Trying to do bad things in Gnome2

% ./xdotool set_num_desktops 5000
% ./xdotool get_num_desktops
36

Example: Move firefox to another desktop

# Find firefox's X Window ID
% MOZWIN=$(./xdotool search --title "Mozilla Firefox")

# Find the desktop containing firefox.
% ./xdotool get_desktop_for_window $MOZWIN
0

# How many desktops do we have?
% ./xdotool get_num_desktops
5

# Move firefox to desktop 3 (index starts at 0)
% ./xdotool set_desktop_for_window $MOZWIN 3

# Show me that firefox has moved to desktop 3
% ./xdotool get_desktop_for_window $MOZWIN
3

# Show me the current desktop
% ./xdotool get_desktop
0

# Activate firefox's window (taking us to Firefox's desktop)
% ./xdotool windowactivate $MOZWIN

# Show that we're now on the same desktop as firefox
% ./xdotool get_desktop
3

I'll put out a new release after I have a chance to tidy up the code a bit.

I was trying to install something from ports tonight, and package fetching kept hanging for a long time. Turns out, for whatever reason, it was trying to connect to some of the servers on ipv6, which would fail and it would then try ipv4. This is probably due to some change I made recently but forgot about.

At any rate, I needed a quick way to kill ipv6 activity on the machine. Trying '/etc/rc.d/network_ipv6 onestop' didn't seem to have the desired effect, so I added this rule to my pf.conf:

block return out inet6 all

Everything is happy now. Probably not the most optimal solution, but I'm not looking for the optimal solution right now.

On a friend's recommendation, I signed up for Rhapsody's music service.

I wasn't able to get it working in Linux. The web interface uses flash, but in Windows it requires the installation of some kind of small piece of software, probably to allow playing of whatever audio format (real? windows media?).

I gave up for a week trying to get it to work. Then, it hit me:

1. Every box I've got came with a windows license.
2. rdesktop supports passing sound remotely (-r sound:remote)

This means I can listen to rhapsody on any platform. Using the license on my laptop, I installed Windows XP in a qemu instance on Linux and enabled remote desktop access. Then, simply doing 'rdesktop -r sound:remote' to login to the virtual machine allowed me to play music. Excellent!

Rhapsody's got a good selection and just about everything I've searched for has been available.

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

Hop on over to the xdotool project page and download the new version. This is the first version being served totally from googlecode, let me know if you have problems.

The changelist from the previous announced release is as follows:

20080521:
  * Import patches from keynav's xdotool branch (From Lukas Mai) which make
    xdotool compile happily when building with -Wall and -pedantic (and others)
  * Finally convert to using Window type for (hopefully) everything instead of
    incorrectly typecasting Window to int sometimes.
  * Confirmed that the one (but mostly useless) test passes.

I've been maintaining my own repository(s) for years, and I've finally grown out of doing it.

My first major repository move was to merge all my CVS and Subversion repositories into a single Subversion repository. This move made me happy for a while, but from time to time the machine hosting the repository would go down, and I'd be out of Subversion access for a while. Additionally, the machine hosting this repository grants me only a small quota (500mb) and my subversion repository was occupying 10% of the space. Lastly, I couldn't be bothered to setup webdav+svn, so I couldn't grant arbitrary users (like you) proper read (and perhaps write) access.

To solve all of these problems, in part or in full, I created a new project on googlecode called 'semicomplete' for my repository. All of my projects will now live there.

I used svnsync to upload my local repository so as to keep all the change history, which took 5 hours, but was otherwise painless.

New repository: http://semicomplete.googlecode.com/

As a side bonus, Google Code Hosting allows you to publish "downloads", which means all of my releases can be put here, saving me 24 megs of used quota on the old machine. Further bonuses include an issue tracking system (so you and I can file bugs that won't get lost) and a project wiki. I don't know if I'll use the wiki yet.

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.