[xmonad] Prospective development of Xmonad

[adam vogt]

Hi Jochen,

See comments inline:

On Thu, Nov 22, 2012 at 2:47 PM, Jochen Keil <jochen.keil at gmail.com> wrote:
> -----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.html


> 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-IndependentScreens.html

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