[alias]
    addremove = !git add . && git ls-files --deleted | xargs --no-run-if-empty git rm

Tada—git addremove puts new files in the staging area and also removes deleted files. Now you don’t have to pay attention to your hipster friends who try to tell you how great mercurial is.

#!/bin/bash
 
EVAL_STRING="notify-send -u normal -t 5000 -i info \"Task completed\" \"$@\""
eval $@; eval $EVAL_STRING

I put it in a folder which is in my path, and now I just do

$ notify ./takes_forever

remove Lock = Caps_Lock
add Lock = Escape
keysym Caps_Lock = Escape
keysym Escape = Caps_Lock

In Windows, it’s a bit trickier. You have to add a registry key, and look up the hex codes for the escape and caps lock keys. I found a lot of premade registry files for switching other keys, but apparently I’m the only person who swaps escape with caps lock. Anyway, you just need to paste the following in a file, name it something with a .reg extension, and then double-click it to import the key into the registry.

Windows Registry Editor Version 5.00
 
[HKEY_CURRENT_USER\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,03,00,00,00,3a,00,01,00,01,00,3a,00,00,00,00,00

This only applies the change to the current user, and you have to log out and log back in for the changes to take effect. You have to change the [HKEY_CURRENT_USER\Keyboard Layout] to [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout] if you want it to apply to all users.

While you’re at it, you can find a small utility to allow for alt + left-click window dragging and alt + right-click resizing here and another for background window scrolling here.

SWIG is a great tool that supports a host of high-level languages; I’ve only ever used it with Python. At the other end, you get your choice of C and C++—crappy languages aren’t really my thing, so this tutorial will be about C. I’m going to use Python 3 because all the cool kids live on the bleeding edge. This requires SWIG 1.3.37 or better; if you’re on Ubuntu like me, you’re going to have to go grab it from the website and compile it yourself (I’m using 1.3.39). Also, remember that you need the header files for python installed (python3-dev on Ubuntu). If you’re too lazy to copy-paste, you can download the files here.

We’ll start out with the obligatory hello world program just to test that SWIG is set up correctly. First make a C function that prints the text and name it hello.c:

#include<stdio.h>
 
void hello() {
    printf("Hello, World!\n"):
}

Now we’ll get SWIG to generate a wrapper for us so that we can call it in Python. Make a file called hello.i and put this in it (my code highlighting isn’t feeling very confident about SWIG files, sorry):

%module hello
%{
    void hello();
%}

This file is the interface file, and it tells SWIG what functions and data structures are going to be shared between C and Python. Now we’ll have SWIG process the interface file to make a wrapper for a python module:

$ swig -python hello.i

This should generate two files: hello.py and hello_wrap.c. Compile the C files:

$ gcc -c -fPIC hello_wrap.c hello.c -I/usr/include/python3.0 -I/usr/lib/python3.0

Make sure that the direcotories are correct. Unfortunately, gcc generates a warning when I compile, which is bothersome as I’m a -Werror kind of guy. The -fPIC flag is necessary, because we’re making a shared library the python module is going to use:

$ ld -shared hello.o hello_wrap.o -o _hello.so

If that works, you are ready to fire up Python and try it. At a Python3 prompt:

>>> from hello import *
>>> hello()
Hello, World!

Easy, right? Now I’ll show you some of the features that I most frequently use. First, we’ll pass some data through by wrapping a C function to multiply integers. Make a file called swig_intro.h, and put in the following declaration:

#include<stdlib.h>
#include<stdio.h>
 
int mult(int a, int b);

Then in swig_intro.c we can write

#include "swig_intro.h"
 
int mult(int a, int b) {
    return a * b;
}

Finally, the interface file, swig_intro.i, will look like this:

%module swig_intro
%{
    #include "swig_intro.h"
%}
 
int mult(int a, int b);

To make things easier, let’s write a makefile for this little project:

TARGET     = swig_intro
CC         = gcc
CFLAGS     = -g -fPIC -Wall -Wextra
HEADERS    = swig_intro.h
SRCS       = swig_intro.c
INCLUDES   =
INTERFACE  = swig_intro.i
SWIG       = swig
 
LDSHARED   = ld
CSHARED    = -shared
 
OBJS       = $(SRCS:.c=.o)
 
IWRAP      = $(INTERFACE:.i=_wrap.i)
ISRCS      = $(IWRAP:.i=.c)
IOBJS      = $(IWRAP:.i=.o)
 
PYTHON_INCLUDE= -I/usr/include/python3.0 -I/usr/lib/python3.0
PYTHON_SO     = .so
 
all: $(SRCS)
	$(SWIG) -python $(INTERFACE)
	$(CC) -c $(CCSHARED) $(CFLAGS) $(ISRCS) $(HEADERS) $(SRCS) $(INCLUDES) $(PYTHON_INCLUDE)
	$(LDSHARED) $(CSHARED) $(OBJS) $(IOBJS) -o _$(TARGET)$(PYTHON_SO)
 
clean:
	rm -f *_wrap* *~ .~* *.pyc
	rm -f *.o *.so *.so

If that works, you can launch a Python3 shell (from now on I’ll assume you do the import first):

>>> from swig_intro import *
>>> mult(-10, 5)
-50

Behind the scenes, SWIG uses something called typemaps to specify how each type is from Python to C and vice versa. In many cases, such as this, we don’t need to worry about that at all, because SWIG has default typemaps for all the fundamental datatypes. For example, you might wonder what SWIG does with a C struct. Go ahead and add this definition to the header file and the interface file:

typedef struct Person {
    char *first_name;
    char *last_name;
    int birth_year;
} Person;
 
void print_person(Person *p);

and put the following function into the .c file:

void print_person(Person *p) {
    if (!p->first_name || !p->last_name) {
        printf("The person is not properly defined.\n");
        return;
    }
    printf("%s %s was born in %d.\n", p->first_name, p->last_name, p->birth_year);
}

Now recompile and try this:

>>> p = Person()
>>> p.first_name = "Paul"
>>> p.last_name = "Black"
>>> p.birth_year = 1977
>>> print_person(p)
Paul Black was born in 1977.

As you can see, the the struct Person was wrapped in a very simple Python class with the three public data fields first_name, last_name, and birth_year.

Next, let’s see how to use typemaps ourselves to pass a more complex structure from Python to C. We’re going to make a (rather contrived) C function that will return the product of a list of integers. We’ll do this by turning a Python list into a C struct that specifies an int array and a size. Add the following code to the header and interface files:

struct IntList {
    int size;
    long *list;
} IntList;
 
int product(IntList *l);

In the .c file, add the function:

int product(IntList *l) {
    int i;
    if (l->size <= 0) {
        return 0;
    }
    int ret_val = 1;
    for (i = 0; i size; i++) {
        ret_val *= l->list[i];
    }
    return ret_val;
}

Now we need to define the typemap in the .i file. This isn’t too difficult; we just make use of several functions from the Python C API:

%typemap(in) IntList * {
    if (!PyList_Check($input)) {
        PyErr_SetString(PyExc_TypeError, "Not a list.");
        return NULL;
    }
    int size = PyList_Size($input);
    $1 = (IntList *)malloc(sizeof(IntList));
    long *list = (long *)malloc(sizeof(long) * size);
    $1->list = list;
    $1->size = size;
    int i;
    for (i = 0; i < size; i++) {
        PyObject *item = PyList_GetItem($input, i);
        if (!PyInt_Check(item)) {
            PyErr_SetString(PyExc_TypeError, "List item is not an integer.");
            free(list);
            free($1);
            return NULL;
        }
        list[i] = PyInt_AsLong(item);
    }
}
 
%typemap(freearg) IntList * {
    free(((IntList *)$1)->list);
    free((IntList *)$1);
}

This also illustrates how to tell SWIG to free your objects and how to handle errors. Now we can see it in action:

>>> from swig_intro import *
>>> product(5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Not a list.
>>> product(["five"])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: List item is not an integer.
>>> product([1,3,5,7,9])
945

As you would expect, transferring data the other way is similar. For an example, let’s make a function that takes a list and returns a dictionary mapping the list elements to their squares. Add these definitions to the header and interface files:

struct IntMap {
    int size;
    long *list1;
    long *list2;
} IntMap;
 
IntMap *square(IntList *l);

The actual C function will take a pointer to an IntList and return a pointer to an IntMap, allocating space for a second list as needed. The conversion to a dict will be specified with an out typemap. In the .c file:

IntMap *square(IntList *l) {
    IntMap *ret_map = (IntMap *)malloc(sizeof(IntMap));
    ret_map->size = l->size;
    ret_map->list1 = l->list;
    ret_map->list2 = (long *)malloc(sizeof(long) * l->size);
    int i;
    for (i = 0; i size; i++) {
        ret_map->list2[i] = l->list[i] * l->list[i];
    }
    return ret_map;
}

Add the typemap to the .i file:

%typemap(out) IntMap * {
    $result = PyDict_New();
    int i;
    for (i = 0; i size; i++) {
        PyObject *key = PyInt_FromLong($1->list1[i]);
        PyObject *val = PyInt_FromLong($1->list2[i]);
        PyDict_SetItem($result, key, val);
    }
}
 
%typemap(freearg) IntMap * {
    free(((IntMap *)$1)->list2);
    free((IntMap *)$1);
}

And we’re done!

>>> square([1,-12,60000])
{60000: 3600000000, 1: 1, -12: 144}

I’ve only shown some of the more useful capabilities of SWIG that I find myself using a lot. For more information, consult the official SWIG docs. Unfortunately, they’re not entirely complete, so it is sometime easier to get answers by just browsing the built-in SWIG interface files to see how the typemaps work.

1. Make sure that you’re using the proprietary nvidia driver and that you have nvidia settings installed:

   sudo apt-get install nvidia-settings

2. Open up nvidia-settings (under System -> Administration in Ubuntu and System in Xubuntu).
3. Under “X Server Display Configuration”, you need to set each monitor to have the correct resolution. Also specify the layout you want, and change the configuration to TwinView. Finally, set the position of both to “Absolute”.
4. Now hit “Save to X Configuration File”. Save this to your home directory (i.e. change the path to ~/xorg.conf).
5. (Optional.) If you want to get rid of the NVidia splash screen every time X restarts, open the xorg.conf file in the editor of your choice and make sure that the line

   Option   "NoLogo" "True"

   appears under each “Device” section.

6. Move the file to the proper directory (you need root access):

   sudo mv ~/xorg.conf /etc/X11/

7. Restart the X server. The easiest way to do this is to log out and log back in.
8. Now the Xinerama info should be getting sent properly. In Ubuntu you can tell that this is the case if you are able to place your panel on just one screen instead of both of them (drag it around a bit). Unfortunately, Gnome doesn’t let you set separate desktop backgrounds, so if you want something different on each screen you’ll need to make an image the width of both screens added together and paste the two pictures in (you can do this easily in the Gimp). In Xubuntu, when you open up the properties for your panel, you’ll be able to choose the monitor on which it should appear. Additionally, Xfce allows you to set separate desktop backgrounds.

A few years ago I started using two monitors with my desktop computer. In nvidia-settings I had two options for configuring the monitors: either with TwinView or Separate X servers. Separate X servers is hugely annoying, so that was out. TwinView made my window manager (Fluxbox, at the time) think that I basically had one screen. This meant that maximizing applications caused them to fill both screens. It also meant that no edge snapping occurred at the border between the monitors. I have seen experienced the same behavior with TwinView in Xfce. This means that for at least two years I’ve associated TwinView with pure suck.

The solution I found was Xinerama. This is an X extension that allows for more logical multi-screen behavior. Unfortunately, it has some downsides. It is slow (although having a fairly fast video card I never noticed this), and it does not work with compositing. So, no shadows, transparency, or other fanciness. I decided that having two monitors (without retarded edge behavior) was more important than super-shiny glowing translucent windows with drop shadows, so I’ve lived without compositing as long as I’ve used two monitors.

About an hour ago, while setting up Ubuntu on my dad’s computer (which also has two monitors), I ran into the same exact issue. TwinView made Gnome think that I only had one big monitor, and turning on Xinerama disabled compositing. This was more noticeable in Gnome, though, because without compositing you don’t have fancy alt-tabbing and dragging a window to the edge of the screen doesn’t move it to the next workspace, among several other annoyances. When I checked the Ubuntu forums, the consistent advice I saw was to disable Xinerama and use TwinView. This made no sense to me, but I kept fiddling with it. After at least an hour of disabling and enabling Xinerama, playing with the xorg.conf, restarting X, and reading the Xorg log, everything suddenly started working. With Xinerama disabled, Gnome suddenly started understanding that there were two separate screens. Windows were maximizing. Compositing was working. Birds were singing.

But what had changed? After poking around on Google for a while, I figured out that TwinView, which I’d written off as basically a pile of shit a long time ago, can send the WM Xinerama info (e.g., where the break between the screens is). When this works properly, there’s really no reason (that I can discern) to use Xinerama at all. Apparently it’s aimed more at people with cards that don’t support a solution like TwinView or MergedFB. Also, there’s a little option you can set in the Device section of xorg.conf:

Option "NoTwinViewXineramaInfo"

• For reasons unknown, nvidia-settings likes to set this option and in all my mangling of xorg.conf I’d managed to get one that didn’t include it.
• That option had not been set but Gnome had temporarily been ignoring the Xinerama info before getting its shit together.

If the first one is the case, then that was also my problem in the past on my own computer and I’ll be fixing it first thing when I get my hands on it (I don’t have access to it at the moment). If the second is the case, then maybe Xfce doesn’t use the Xinerama info properly with TwinView. This would probably be a deal-breaker that would cause me to switch to Gnome. I kind of doubt this is the case though, considering how perfectly Xfce does work with Xinerama enabled. Regardless, it’s great to no longer have to use Xinerama.

Before I got this working, this was going to be a rant about the state of dual screens in Linux and nvidia-settings in particular. I’m going to go ahead and mention two that still annoy me about nvidia-settings:

• It doesn’t require root access. Now, with XRandR or whatever you can make some changes without being root, so that may be the reasoning there. However, I just use the command xrandr to do this, and every time I use nvidia-settings I’m trying to make a new xorg.conf. I usually forget to run it as root, so when I’m done making my changes I have to save the file to my home directory and move it manually. This isn’t a huge deal, but it happens just about every time.
• If you are going to use Xinerama, you have enable separate X screens before it reveals the Xinerama checkbox. Why not make Xinerama a separate option in addition to TwinView and separate X servers?

Additionally, Gnome doesn’t let you set separate wallpapers, so the best option is basically to make one image from two separate wallpapers. I’m hoping that this functionality can be added; Xfce already does it properly.

On the whole, though, the dual monitor situation is pretty good. After the initial annoyance of getting it set up it pretty much works. This is much better than the Nvidia situation on Windows, where it likes to forget half of my settings periodically and makes me reboot after making trivial changes.