This repository includes the following:
- Configuration of XMonad that has specialized functionality
- Patches for XMonad
- XTest Scripts allowing for custom keybindings
The xmonad.hs closely emulates the window division behaviors of Wmii / Orion / I3 / Ion, and other non-minimal tiling window managers (eg. not DWM, or other window managers of the strongly "minimalist" flavor). See xmonad.hs for more details...
It focuses heavily on the ability to manipulate multiple independent groups of windows one or more monitors, with a high degree of granularity. The current way that this is abstracted is through the use of LayoutScreens to pretend that the different "panes" of a Rectangle are in fact different screens. The user may work at a higher level of abstraction, not worrying about master-slave window relationships, nor excessively rigid "dynamic" window behavior.
This is particularly useful in a number of circumstances:
- When using a widescreen monitor, and more efficient screen utilization of the screen space is desired
- When using multiple monitors, and Xinerama or TWinView are unavailable
- When using systems with limited or restrictive X servers, that are incapable of using XRender (xrdp sessions with the span option are a case in point for this functionality)
Included are some other useful behaviors that are not commonly implemented:
- Handles process spawning on FreeBSD correctly
- Allows variable-width layouts properly in conjunction with layoutScreens (via a custom layout, as defined in this file) with an arbitrary number of subdivisions (as noted above)
- Easy dynamic switching between variable width subdivisions of the workspace
- Adapted version of XMonad.Layout.Groups.Wmii (XMonad.Layout.Groups.WmiiTwoPane)
- Integrated with transparent versions of xmobar and dmenu (compatible with XMonad transparent window borders as well)
- Both Next/previous tab and next/previous screen are fully working in all possible layouts. In both cases, moving the focus and/or a window are fully supported, and are constrained on the edges/corners of the screen (no cycles / non-wrapping).
- Handles desktop windows correctly: ensures that rdesktop windows are both non-floating (safely sinks the window) and shifted to a target workspace, with no ghosting effect.
Some scripts are included as they are very tightly coupled with the specific functionality of my window manager configuration, although all are written in C, using XTest. These scripts are valuable as they generate key combinations synchronously and nullify and reinitialize any keys needed to generate the new keys.
I recently purchased an Ergodox keyboard, and I was very impressed by the layer mapping, which makes many keys much easier to reach, and acts somewhat like an additional modifier key.
The main issue that I have is that I still must use a lot of other keyboards, so I wanted to at least have a fallback modifier key to generate arrow keys, and other similar keys on the home row. Also, I wanted to make this an application-level keybinding, with variations in terms of generated keys dependent on which exact combination is pressed.
Since I already use the Hyper and Super keys for window managers (main session and nested remote RDP or VNC session, respectively), I wanted another modifier key that was application-level, but always user customizable. I would arbitrarily call this the "Ultra" key, as the "Front" and "Top" keys of the Space Cadet keyboard are more like a Shift key, and are no more official than my "Ultra" key.
Basically, this "Ultra" key is simulated as either "Hyper+Control" or "Super+Control", which provides this user-level layer, which admittedly reduces the combinatorial possibilities for additional keys. I've even considered making it a completely separate key, using either function keys above F12, or the + or - keys on the Numpad, which I never use.
The implementation relies on generating keys by pressing other keys, which as noted above, is tricky to do, although it is not so bad when using XTest directly. In X11, keyboard events cannot be ignored, nor am I aware of a way to filter events or distinguish a fake event from a real one (that might actually be possible, although I haven't investigated it, yet). Further, the namespace is fully global, which poses risk of some issues.
Fortunately, at least a key up event can be used to approximate an exclusion of certain keys, and synchronous behavior is possible when the library and timing operations are performed in the same program.
Unlike my previous (lazy) attempts using xdotool, XTest directly produces fully reliable results (I don't believe this is necessarily a flaw of that program, just that commands like flushing probably need to happen in the same process). Even key repeat worked correctly during testing.
This effectively allows for translation from any combination of keys to any combination of keys, thus allowing better keybindings for non-extensible but otherwise useful programs, such as chromium.
At the moment there are some glitches, particularly with the Shift key, but also it assumes certain commands use modifier keys on the left or right hand, since I am not yet aware how to detect *which* of the Left or Right versions of a given modifier key were pressed (do I need to use the XRecord extension?). At some point, I will remedy this problem, (I need to look through the sources to xev, which does something of this nature, and hence may offer some clues on such a technique) but I have not done so, yet...
Finally, these are not yet general purpose tools, which is unfortunate. It takes a lot of time to write an XTest based tool that is both reliable for complex use cases and is general purpose. Particularly, writing a batch tool of this nature requires a fairly complex notation to specify exactly which keys must be deactivated and how they must be re-activated.
Transparent Window Decorations
The main patches of note make the window decorations transparent in xmonad-contrib:
- Both the patches and a FreeBSD port are included.
- Works for window decorations, and includes the borders and the area around window title text (so it was necessary to modify three different files)
- The transparency applies to many third-party extensions, such as flashText, since most extensions utilize the window decoration code in xmonad-contrib
- The configuration files and patches should run on the latest versions of XMonad, and will be adapted periodically to be fully compatible with the latest stable versions of the software.
See COPYRIGHT for more details (BSD 3 clause).
I'm not terribly experienced in Haskell, but I'm getting better! Comments/critiques are always welcome, especially from experienced Haskell programmers!