Thanks to some early testing and feedback from the previous xdotool release, I've put together a new release that fixes a few minor problems.

Download: xdotool-1.20100302.2708.tar.gz

As usual, if you find problems or have feature requests, please file bugs or send an email to the list.

Changelist since previous announcement:

1.20100302.*:
  - Some test fixes suggested by Daniel Kahn Gillmor
  - Don't use isatty(0) anymore as it isn't totally reliable in determining if
    we should try to read from stdin.

1.20100301.*:
  - Minor libxdo patch to avoid exporting unnecessary symbols (Daniel Kahn Gillmor)
  - Minor Makefile fix to only link libxdo (and not xdotool) against libX11 and
    libXtst (also Daniel Kahn Gillmor)
  - Some test cleanup patches by Daniel Kahn Gillmor
  - Fixed the 'type hello' test that would fail sometimes when run in Xephyr.
  - Fix a minor bug in xdo_window_setclass that incorrectly aborts when
    XGetClassHint fails.

A new release of xdotool is available. This release has only minor changes based on changes needed to help Debian and other folks package this. Speaking of which: thanks to Daniel Kahn Gillmor and Wen-Yen Chuang for helping maintain the Debian packages for xdotool and keynav and for working with me on these changes.

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

The changelist follows:

20091231.02:
  No functional changes.
  - fix linking problems and just use $(CC) for build and linking
  - Make the tests headless (requires Xvfb and GNOME)
  - Make the t/run.sh test runner exit-code friendly

20091231.01:
  No xdotool changes.
  libxdo changes:
    * Rename keysymcharmap -> keysym_charmap
    * Expose keysym_charmap and symbol_map as xdo_keysym_charmap()
      and xdo_symbol_map()

xdotool-20091231.02

A new release of xdotool is available. It fixes two bugs that were moderately annoying.

20090126:
  * Change the default behavior of 'getwindowfocus' to get the first
    ancestor-or-self window that has WM_CLASS set. WM_CLASS will be set on
    (all?) top-level windows and it's possible that the currently focused window
    according to X is not a top-level window. To use the previous behavior, use
    'getwindowfocus -f'
  * Make 'xdotool key at' work correctly. 'at' is usually Shift+2, for example.
    Now all shifted characters should work, but I've only tested on a US
    keyboard.
  * Minor Makefile fixes for package maintainers.

I've tested it in GNOME and Ion-3 with success.

Download: xdotool-20090126.tar.gz

Resig has a bunch of unit tests he does to make sure jQuery works properly on whatever browser. Manually running and checking unit test results is annoying and time consuming. Let's automate this.

Combine something simple like Firefox and Xvfb (X Virtual Frame Buffer), and you've got a simple way to run Firefox without a visible display.

Let's start Xvfb:

startx -- `which Xvfb` :1 -screen 0 1024x768x24

# Or with Xephyr
startx -- `which Xephyr` :1 -screen 1024x768x24

This starts Xvfb running on :1 with a screen size of 1024x768 and 24bits/pixel color depth. Now, let's run firefox:

DISPLAY=:1 firefox

# Or, if you run csh or tcsh
env DISPLAY=:1 firefox

Seems simple enough. What now? We want to tell firefox to go to google.com, perhaps.

DISPLAY=:1 firefox-remote http://www.google.com/

Now, let's take a screenshot (requires ImageMagick's import command):

DISPLAY=:1 import -window root googledotcom.png

Lets see what that looks like: googledotcom.png

While this isn't complicated, we could very easily automate lots of magic using something like the Selenium extension, all without requiring the use of a visual display (Monitor). Hopefully I'll find time to work on something cool using this soon.

Problems with screen scraping and other website interaction automation is that it almost always needs to be done without a browser. For instance, all of my screen scraping adventures have been using Perl. Browsers already know how to speak to the web, so why reinvent the wheel?

Firefox has lots of javascript-magic extensions such as greasemonkey and Selenium to let you execute browser-side javascript and activity automatically. Combine these together with Xvfb, and you can automate lots of things behind the scenes.

Tie this back to unit tests. Instead of simply displaying results of unit tests, have the page also report the results to a cgi script on the webserver. This will let you automatically test websites using a web browser and have it automatically report the results back to a server.