velox is a simple wm inspired by dwm, xmonad and awesome.

velox currently uses YAML for its configuration files. As of right now, all of the configuration is done through two files, velox.yaml, and keys.yaml. velox searches for these files first locally (in ~/.velox/), and then system wide (in /etc/velox/).

velox.yaml is where global settings for velox will reside. Currently, the only configuration variable used from velox.yaml is modules. The value of modules should be a list of modules to load on startup.

keys.yaml is where you can configure key bindings for velox. Modules can make use of these bindings using add_configured_key_binding.

The format for keys.yaml is as follows:

group: # The group the contained key bindings belong in
    binding_name: # The name of the binding
        - # A list containing a list of bindings performing the same action
          #
          # Each binding consists of a map containing the keys "mod" and "key"
          #
          # The value associated with the "mod" key should be a list of
          # the modifiers for the key binding, which will be OR'd together
          #
          # The possible values are:
          #     * mod_shift
          #     * mod_lock
          #     * mod_control
          #     * mod_1
          #     * mod_2
          #     * mod_3
          #     * mod_4
          #     * mod_5
          #     * mod_any
          #
          mod: [mod_X, mod_Y]
          # The value associated with the "key" key should be the keysym
          # for the key binding.
          #
          # Keysyms can be obtained from the "keysymdef.h' header from
          # X.Org. NOTE: The "XK_" should be excluded
          key: keysym

Support for modules is still in its infancy, but soon shall allow users to customize their environment through the addition of layouts, hooks, and key bindings.

Currently there are only three required definitions to constitute a module.

1. There must be a string called name which should be set to an identifying name for the module.
2. There must be an setup function which will be called shortly after velox starts
3. There must be a cleanup function which can perform any necessary actions prior to the modules unloading.

Currently, velox includes two layouts by default; tile and grid. These layouts are similar to ones you might have seen in other projects. More layouts can be added through the use of modules, and add_layout. The most important part of a layout is its arrange function, which takes as arguments, a cyclical linked list of windows and layout state.

Things that still need to get done, in no particular order:

• Status bar: Add a statusbar to indicate current workspace and other cool stuff
• Support having multiple tags enabled at the same time
• Support for having windows visible on multiple tags
• Support for multiple screens
• Better EWMH support
• Easily configurable and usable colors
• Easier and more automatic allocation of atoms
• Configurable tags
• Cleanup some of the more messy code to reduce code redundancy