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.
- There must be a string called
name
which should be set to an identifying name for the module. - There must be an
setup
function which will be called shortly after velox starts - 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