# `xmonad-custom`: Custom modules for my xmonad configuration

## Usage

Install via stack similar as xmonad and xmonad-contrib,
see e.g. [this guide][brianbuccola].
Write `xmonad.hs` as glue code to import modules.

## Goals of this setup
### Design
- Keybindings optimized for neo keyboard layout:
    - positional keybindings taken from default XMonad config,
      e.g. now `n` and `d` are used to rotate through workspaces,
      as they match the positions of `j` and `ö` in the standard qwertz layout.
    - mnemonic keybindings (partially) remapped to avoid conflicts,
      e.g. `r` for running programs, `x` for killing windows
- `Super` and `Alt_L` as main and secondary modifier.
- 20 numbered workspaces, reachable by `<Super>-1`, ..., `<Super>-0` and `<Alt_L>-1`, ..., `<Alt_L>-0`.
  Moving to these workspaces with additional `<Shift>`.
- Workspaces associated to programs, reachably my `<Alt>` and mnemonic keys for the programs:
    - launching programs automatically when opening workspace
      Prevent launching with `<Control>`
    - binding programs to these workspaces (to be implemented)
- Many keybindings for custom menus lanuching (custom) scripts,
  e.g. `u` for stuff associated to my [University Setup][uni-setup]
  or `<Esc>` for reboot, hibernate, suspend etc.
  (still many missing)
- Use [PolyBar][polybar] as status bar

### Implementational
- Use [EZConfig][ezconfig] for all bindings to simplify code.
- Use [Submap][submap] for menus.
- separation into multiple modules to clean up the main `xmonad.hs` config file
  and increase modularization/reusability.
  E.g., it is now trivial to remove university setup keys or bind the submenu to another key.
- Deduplication as strong as reasonably possible.
  This means a single place where all modifier keys are defined etc.
  Also ensures that changing modifier layout is as easy as possible
- Reasonably separate code from real configuration
- Reduce `xmonad.hs` to gluing code / selection of loaded modules.
  In particular, no configuration (read: key definitions) should be present there
- Pack modules into `.cabal` package.
  This ensures that `xmonad-custom` can be installed just as `xmonad` or `xmonad-contrib`
  (e.g. via Stack) and `xmonad.hs` can conveniently import all my stuff.
  In particular, no [custom build script][build-script] is needed to build `xmonad`.
- Use [xmonad-dbus][xmonad-dbus] for communication with PolyBar.

## Non-goals
- Write a library that is directly usable for others.
  This is for personal use, although you are of course invited to reuse/adapt/fork this
- Complete separation of code and configuration.
  This means that the modules do directly contain my keybindings.
  This also means that the source code of this package itself must me modified for
  customization (in contrast to `xmonad` itself, e.g.)
  I went with this option since complete separation is just too ugly to implement
  and somewhat defies the purpose of `xmonad` *not* using configuration files but
  Haskell code.
  Also I believe that users of `xmonad` will want to customize more than just my
  keybindings, so more code has to be written anyways.


[uni-setup]: https://git.abstractnonsen.se/max/university-setup
[ezconfig]: https://xmonad.github.io/xmonad-docs/xmonad-contrib/XMonad-Util-EZConfig.html
[submap]: https://xmonad.github.io/xmonad-docs/xmonad-contrib/XMonad-Actions-Submap.html
[xmonad-dbus]: https://github.com/troydm/xmonad-dbus 
[polybar]: https://github.com/polybar/polybar 
[brianbuccola]: https://brianbuccola.com/how-to-install-xmonad-and-xmobar-via-stack/