-----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-----
2012/11/22 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.
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.
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,
Jochen -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlCugUkACgkQtVwvsA+W4CDoegCfXHsWj4UcQmM0xzVva78a/HuT 9wYAmwQqbJfB6cgsgIVpjlXElb8nSgdL =XKfv -----END PGP SIGNATURE-----
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
+1
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.
On Thu, Nov 22, 2012 at 21:15:40 GMT, Eric Velten de Melo wrote:
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.
Someone mentioned on IRC a while back that they were interested in making a Wayland protocol library (no C bindings) which a Wayland-XMonad (WMonad?) could be implemented. Another interesting exercise would be to factor out the X monad from XMonad so that WMonad could still use XMonadContrib (some things would have to be reimplemented for Wayland (such as X.H.DynamicBars), but for those that just manipulate StackSet, it shouldn't be insane). Some modules would be more useful as well (I used to use CopyWindow until I started using multi-monitor where it falls flat on its face; Wayland will make CopyWindow actually possible with multi-monitor).
This would be also quite a huge amount of work, but maybe something people would be more interesting in doing. I know I would.
I'm interested and I'd be interested in helping to port XMonadContrib modules over (or do adaptations to support XMonad and WMonad at the same time). -- Ben
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
participants (5)
-
adam vogt -
Alfredo Di Napoli -
Ben Boeckel -
Eric Velten de Melo -
Jochen Keil