-----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. 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. 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. 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. 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 apologize for the length of this email, but I wanted to point out my motivation and make my ideas clear. I'm also asking explicitly for feedback from current developers. If you have an idea on how to implement these ideas without breaking contrib, that would be fine. Or maybe you want to start out with something on this list, that would be even better :) I also thought about creating a clone/fork of xmonad, but that's something I'd like to avoid, since I believe that the world does not need yet another wm. Best wishes, Jochen -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlCugUkACgkQtVwvsA+W4CDoegCfXHsWj4UcQmM0xzVva78a/HuT 9wYAmwQqbJfB6cgsgIVpjlXElb8nSgdL =XKfv -----END PGP SIGNATURE-----