Название - отсылка к devilspie, похожей утилитой. Она примечательна тем, что конфиг пишется на диалекте лисп, несмотря на это у неё весьма ограниченные возможности. Тем более у утилит типа wmctl и т.п.

С помощью библиотеки wnck можно делать куда больше, а ещё больше если задействовать gdk.

Для глобальный горячих клавиш я использовал libkeybinder, раньше я делал такое на "голой" xlib, но так удобней(и переносимей). Впрочем xlib/xtest тоже используется - чтобы эмулировать нажатие кнопок. Но эти функции опциональны.

В качестве формата конфига я выбрал yaml. Более старые версии использовали конфиг на питоне, но я решил что yaml удобней конечным пользователям. Тем более в него можно встраивать код на python и sh.

В детали реализации я вдаваться не буду. Там много магии и метапрограммирования, часть кода сгенерирована.

Лучше покажу пример конфига, который использует часть возможностей. Кстати, новые правила можно генерировать из командной строки, оно возьмет name и class_group активного окна.

При работе над django-проектом, есть ряд must-have сторонних библиотек, если не хочется бесконечно изобретать велосипед. Средстав отладки sql запросов(debug-toolbar, silk, --print-sql из django-extensions), что-нибудь для хранения древовидных структур, переодических/отложенных задач(кстати, cron-like интерфейс есть у uswgi. EAV всё ещё бывает нужен, хотя часто его можно заменить jsonfield. И одна из таких крайне полезных вещей, но почему-то реже обсуждаемая в сети - FSM. Не так часто почему-то сталкиваюсь с ними в чужом коде.

<cut>

Практически у каждой записи в БД есть некоторое состояние. Например, для комментария это может быть - опубликован/удален/удален модератором. Для заказа в магазине - оформлен/оплачен/доставлен/возврат и т.п. Причем переход из одного состояния в другое часто бывает размазан по коду и в нем присутствует бизнес-логика, которую надо обильно покрывать тестами(всё равно придется, но можно избежать тестирования элементарных вещей, например, что заказ может перейти в состояние "возврат денег" только после того, как он побывал в состоянии "оплачен".

Вполне логично было бы описывать такие переходы более декларативно и в одном месте. Вместе с необходимой логикой и проверкой доступа.

Вот пример кода из тестов библиотеки django-fsm