[xmonad] Prospective development of Xmonad
Eric Velten de Melo
ericvmelo at gmail.com
Thu Nov 22 22:15:40 CET 2012
2012/11/22 Jochen Keil <jochen.keil at gmail.com>:
> -----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
> 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.
Well, I am not a XMonad developer, but this seems like a huge amount
of work, specially considering the possibility of breaking up
libraries. My other concern it that X is quite old and becoming
obsolete. Instead of adding all these features to XMonad, maybe we
should consider building a new display manager (a port would be
impossible) around something like Wayland. This would be also quite a
huge amount of work, but maybe something people would be more
interesting in doing. I know I would.
> Best wishes,
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> -----END PGP SIGNATURE-----
> xmonad mailing list
> xmonad at haskell.org
More information about the xmonad