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

I have a machine that runs X but doesn't listen to inet connections (via -nolisten-tcp). What if I want to use x2x to this machine? Simple.

 ssh -tY thatmachine 'x2x -from $DISPLAY -to :0 -west' 

This will ssh to 'thatmachine' and forward X. This set's $DISPLAY on the remote machine, which you can then invoke x2x with specifying 'from' as $DISPLAY. This has the same effect as invoking:

 x2x -to thatmachine:0 -west 

Except you don't need to allow tcp X connections. :)