Hi Jochen,
See comments inline:
On Thu, Nov 22, 2012 at 2:47 PM, Jochen Keil
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear list,
recently I looked around in the world of tiling window managers. In particular I looked at wmii, i3 and awesome. They offer various features which I was very fond off, yet none was so feature complete that I was convinced to make the switch.
Then I started to think about the current state of xmonad and came to the conclusion that compared to the aforementioned window manager it seems that some dust has settled upon xmonad.
Finally I came up with a small list of features I'd like to implement for xmonad, but I fear that this would break many if not all modules in contrib. I'll discuss every item in detail.
1) wmii like tags
The current workspace model seems a bit inflexible to me. After trying wmii's window tagging model I think that this is a far more flexible, dynamic and better approach to managing windows. Want your browser visible with your editor/terminal windows you use in project A? No problem, associate tag A with your browser, same for tag C, etc.
Have you tried this contrib module out: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Actions-TagWindows.html It isn't the most efficient since it stores tags with X instead of in xmonad (say storing with ExtensibleState a Map Window [String]). Some possibilities such as assigning tags using manageHooks aren't specifically documented either. I don't believe you getting exactly the same behavior of wmii using that module. Another contrib module is also allows toggling windows displayed: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Util-NamedScratchpad.htm...
2) Xrandr support
I've extended the current bindings (Graphics.X11.Xrandr) so that they would be usable for what I intend to do with xmonad. There's a pull request on github and I hope dwagner (who reads this list too, afaik, hint, hint ;) will merge it soon.
My idea about Xrandr support for xmonad would be similar to how it's done in i3. I'd create a separate config for every output (in the Xrandr terminology, e.g. DVI1 or LVDS, etc.).
Therefore, every output would be associated with a set of windows, and a layout which would be used to generate the "view" for the windows. If an output becomes inactive the windows could easily be shown on another output (e.g. by using something like a hierarchical ManageHook, like try 1; try 2; fallback 3)
This would especially shine together with wmii like tags. To motivate this idea a bit more: Imagine attaching your external monitor to your laptop and all your windows will be automatically sorted to the right screen, e.g. the browser and the editor to the external monitor, your email client to your laptops monitor.
Having different workspaces per screen is done: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-IndependentScreen... Using the config's handleEventHook you can find out when a new monitor has been attached: I think this module (added after 0.10) has code to do exactly that: http://code.haskell.org/XMonadContrib/XMonad/Hooks/DynamicBars.hs
3) A tree hierarchy for windows
I had some issues with the stackset over the past years, mainly because it makes it hard to write an column layout which simply splits the current window either automatically or manually. Furthermore a tree can be simply transformed to a stack (the other way round is nearly impossible). That way most of the (at least pure) layouts could be kept, layouts with side effects (especially on the X monad) probably not.
Most contrib layouts don't mess around with xmonad's state, so not that much would have to be changed in contrib if you had a WindowSetTree and only had a:
project :: WindowSetTree -> WindowSet
Without an:
unproject :: WindowSet -> WindowSetTree -> WindowSetTree
Which would merge back the changes (deleted windows, reordered windows, changed layout states). Some layouts to look at that already sort of do this (without changing xmonad core): http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-Groups.html http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-SubLayouts.html http://hpaste.org/4770 -- somewhat broken manual tiling layout
4) Reparenting
This would be nice for having window titles, etc. Only for the sake of completeness for the moment, since I haven't thought about this much yet.
Contrib does do decorations. Windows are created to show the titles, but I don't think that makes xmonad reparenting: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-Decoration.html
5) XCB instead of Xlib
This is kind of optional. The XHB (haskell xcb bindings) lack some features which would make it hard to fully convert xmonad to xcb. However, there is Xlib-xcb which facilitates the usage of Xlib functions with xcb. All that's required is a simple hsc2hs wrapper to this.
I think the only function to wrap would be XGetXCBConnection(), which would give you a Display -> IO Connection Then you could experiment call functions in xhb I think. It can probably be done in your xmonad.hs (or in other files in ~/.xmonad/lib/), though I suppose the main benefit would only happen if you started to replace things in core which will break some things in contrib. For example, xhb's Event is done in the same way as xmonad's Message and Control.Exception exceptions, while X11 has a data Event. Hopefully this gives you an idea that much can be accomplished outside of core without much extra effort. There's no reason we couldn't have an XMonad.Config.WMII Adam