As far as feature requests come, for xdotool, one of the more common ones is to have the ability to send key or mouse events to a specific window, not just the active one. XTEST (what xdotool uses for key/mouse currently) doesn't let you specify a window to send events. XSendEvent(3) lets you send hand-crafted events to a specific window, but most applications ignore these sent events.

The XEvent struct has a member 'send_event' which is true if the event came from an XSendEvent call and false otherwise. Programs like firefox and xterm (by default) ignore many events that have 'send_event' set to true.

Enter LD_PRELOAD.

Writing a custom shared library that overrides the default XNextEvent and XPeekEvent functions allows us to force 'send_event' to always be false, so an application with this library loaded will happily handle keyboard/mouse events generated with XSendEvent. I already have a helpful project that lets me write such a shared library: liboverride.

#include <stdio.h>
#include <X11/Xlib.h>

void hack_send_event(XEvent *ev) {
  switch (ev->type) {
    case KeyPress: case KeyRelease: case ButtonPress: case ButtonRelease:
      ev->xany.send_event = False;
      break;
  }
}

override(`XNextEvent', `
  {
    real_func(display, event_return);
    hack_send_event(event_return);
    return;
  }
')

This small bit of liboverride code will give me a shared library I can preload with LD_PRELOAD. Doing so will ensure that send_event is false for any key or mouse button events.

Works well. Now that we have a reliable way to allow XSendEvent I think it's worth putting this into xdotool.

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.

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've been doing various Xlib projects off and on for a few years, but none of them have been window manager projects because I was using a WM that pleased me: Ion. Many years later, after following ion from ion 1, 2, and now 3, the author decided to apply some user unfriendly licensing terms to newer releases of ion-3. This license change combined with the author's efforts to require distributions to comply with this license has resulted in most platforms dropping the ion-3 package from its distribution because nobody wants to deal with assholes and drama.

I'm not going to get into a discussion about my opinions about the license. Just know that it inconveniences me, and if you know me, you know that I tend to solve problems of inconvenience with new software tools. That means I need a new window manager.

I've tested other window managers, but none fit me as well as ion did.

A few weeks ago I started on a window manager project tentatively called tsawm (tuomov sucks ass, the window manager) which implements features I like in ion but without the douchebaggery. I started working on it initially in C, since that's where I use xlib, but C has some drawbacks. A nontrivial percentage of what I perceive to be window manager behavior is basically managing some heirarchy of data (frames, client windows, titles, some state). I started looking at Perl's X11::Protocol and Python's xlib module. Python's xlib module is pretty neat, in that it's a pure-python implementation of the X11 protocol.

Somewhat arbitrarily, I started prototyping to see if writing a window manager in python was possible. Yes, it is. So that's where I'm at today.

I've mostly been hacking things together while learning more about window managing in X, but what I have so far is promising: screenshot.

It's not pretty, but finishing this will help me get past the drama and problems that ion and its author bring. Sorry tuomov, I still love ion, but any licenses that keep me (directly or indirectly) from getting shit done aren't acceptable.

I've gotten enough positive feedback about xdotool to convince me to put up a real project page for it. You can view it here at /projects/xdotool

Today's efforts are summarized best by:

% ./xdotool search "Mozilla Firefox"
31457484 
% xwininfo -id 31457484 | egrep 'Width|Height' | paste - -
  Width: 1278     Height: 1008
% ./xdotool windowsize `./xdotool search "Mozilla Firefox"` 500 500
% xwininfo -id 31457484 | egrep 'Width|Height' | paste - -
  Width: 500      Height: 500

This new 'search' command will walk the list of windows in X and basically output any windows with a matching title, name, or class. In this case, I have 1 "browser" window open under firefox that has "Mozilla Firefox" in the title. So I then resize it to 500x500, trivially.

Longer summary of today is that I added 4 new functions to xdotool:

• windowsize <windowid> <width> <height>
• windowfocus <windowid>
• windowmove <windowid> <x> <y>
• search <regexp>

Thanks to valgrind, I also fixed the crashes in Linux. Was due to an off-by-one bug. Sweet tool: valgrind.

Turns out XTEST works as I'd expect, and this example will do what you think, and switch to the 2nd console (assuming you're running one).

% ./xdotool key "ctrl+alt+F2"

Goal: Focus the first window found that is a local xterm (ie; not ssh'd anywhere). My xterms have title with 'host(pwd) - activity' in them. So if my local host is 'snack' I can do:

# Look for xterms starting with 'snack(' and focus the first one
./xdotool search '^snack\(' | head -1 | xargs ./xdotool windowfocus

And magically one of the xterms running a shell locally is focused. I can see this being pretty useful.

Today's code: navmacro-20070622.tar.gz.

I've been working furiously on xdo the past few days. Good times :)

The result so far is as follows:

• xdo is now a library, so you can simply call xdo_click(...) and it will handle all the hard stuff for you for the case that you want to use this in your own code.
• xdotool is the commandline interface to the xdo api.
• navmacro (bad name) is a very small gtk launcher. Basically it's an input box that runs the contents when you hit enter

I include a sample script 'ffsp' which is short for 'firefox searchbar paste'. It works on my system, but obviously on other systems you'll need to tweak it. The basics are there.

So right now, I can do this:

1. Select a piece of text in an xterm
2. Activate navmacro and type 'ffsp' and hit enter
3. Enjoy the fact that firefox has been told to search for the contents of my clipboard

'ffsp' is located in my $HOME/bin/ so I execute it like any other shell script or program.

Interested in the code? Download navmacro-20070620.tar.gz.

Note: navmacro works on my ubuntu and freebsd systems just fine. However, xdotool crashes at the end when I do free(xdo->charcodes) only on my Ubuntu system. Uncertain why, I'm way too tired to debug.

Yesterday, I talked about macros. I spent some time coding today and I now have a tool that will let you execute raw keyboard and mouse input into X using the XTEST extension.

The primary example I used was focusing firefox's URL bar without the mouse. The sequence was this: Switch to Desktop 2 (I press Alt+2), focus firefox's URL bar (using control+l) and clear it.

The result is a simple tool I'm tentatively calling 'xdo'. You can download the source here. Compile instructions are at the top of the file.

The top of xdo.c details the implemented commands, so let's cut to an example:

% echo 'key alt+2; sleep 1; key ctrl+l; key BackSpace' | ./xdo

It does exactly what you think. The 'sleep' command has values in milliseconds, and is only necessary to slow down so that events can propgate fast enough (window focus changes, etc).

Another reasonable example would be to say "firefox, open a new tab and load the URL in my clipboard":

# My clipboard contains a valid url, say, "http://www.google.com/"
(echo "key alt+2; sleep 1; key ctrl+l; key BackSpace;"
 echo "move 55 55; sleep 1; click 2; key Return") | ./xdo

Seems complex, but look at what's really happening: Go to desktop 2, focus urlbar, hit backspace (clearing it), move the mouse cursor to 55,55 (a point inside the urlbar for me), hit middle mouse button to paste.

Change "ctrl+l" to ctrl+k (unix firefox) to focus the "Search" box instead, and change the 'move' command to cursor over the search box to paste instead, and suddenly you can bind a simple keystroke to search for whatever is in your X clipboard. Useful.

One of the neater features is that you can 'type' text:

% echo 'type echo hello there; key Return' | ./xdo
echo hello there
% echo hello there
hello there

Today was a learning day. A few months ago, I released keynav, a tool to make large-area mouse navigation very quick. However, I found myself using keynav to do the same things over and over again. Select certain windows, clicking on certain UI widgets, etc; things that are annoying to do repeatedly.

What if we had a way to describe input actions? What if you could say "Focus the firefox URL bar" with a simple keystroke, without having firefox focused? This premise is fairly simple - Focus firefox, then "click" on a certain part of the window. The URL bar's location is pretty reliable (a few pixels from the top).

If you're like me, firefox is on another virtual desktop. What if firefox isn't shown right now because you're on "Desktop 1" and firefox lives on "Desktop 2"? Well we can find out if it's hidden, then send the keystrokes (via XTEST) to switch to "Desktop 2" and then do whatever we would normally do to focus on Firefox's URL bar. The basic pseudocode of the script would look like:

if firefox is not shown:
  go to desktop 2 ("fake send alt+2")

focus firefox (via fake click?)
fake send "Control+L" (Firefox's shortcut for focusing the urlbar)

Seems pretty simple. "Fake" above refers to events sent using the XTest, an extension to X11 (Xorg/XFree86) that lets you send keystrokes and mouse events as if they had been typed.

So, tonight I started work on a project that would let you script actions. Generally, I'm aiming at scripting UI interaction to make common tasks such as "take me to firefox" simpler.

I revisited some man pages for Xlib I hadn't seen in many months, and now I can traverse the list of all open windows in X and show their status. Here's what this tool outputs; notice how I can tell if the window is visible ("shown" by the window manager):

+ 8388621 (1x16@424,324) [Visible]
  teabag(.../home/jls/projects/navmacro)
  "xterm" "XTerm" 
+ 44040205 (1x16@424,324) [Hidden]
  snack(~) % @ snack
  "xterm" "XTerm" 
+ 29360192 (1x15@1278,1008) [Hidden]
  HMUG: man XWindowAttributes (3) - Mozilla Firefox
  "firefox-bin" "Firefox-bin"

The other piece of learning I did tonight was to learn GTK2. Enough fiddling around and I was able to get a input field that pops up over everything and is as wide as the screen to input your macros in. GTK's not that bad. Its API design is fairly intuitive and I didn't have much trouble getting things working. I even figured out how to ask GTK what it's X window ID is. Most of this knowledge comes from the GDK X Windows Interaction documentation.

#include <gtk/gtk.h>
#include <gdk/gdkx.h>

static void activate(GtkWidget *widget, gpointer data) {
  // widget->window is the GdkWindow containing this widget.
  g_print("Display handle: %x\n", GDK_WINDOW_XDISPLAY(widget->window));
  g_print("Window id: %d\n", GDK_WINDOW_XID(widget->window));
}

int main(int argc, char **argv) {
  GtkWidget *window;

  gtk_init (&argc, &argv);
  window = gtk_window_new (GTK_WINDOW_TOPLEVEL);

  g_signal_connect(G_OBJECT(window), "realize",
                   G_CALLBACK(activate), NULL);

  gtk_widget_show_all(window);
  gtk_main();
  return 0;
}

Compiled with: gcc `pkg-config --cflags --libs x11` test.c

The little bit of GTK I wrote tonight can be found here. It's not much, but it does example how to use GTK and Xlib at the same time, on the same windows.

Oops... it's getting light outside. Naptime ;)