[xmonad] WaylandMonad

[Auke Booij]

Would this currently be considered an unrealistic project, or a
project not worth investing time in?

I should probably add that the wayland API is considered stable. It is
certainly stable enough for GNOME, KDE, enlightenment, and numerous
other window managers to be in active development (and very far, at
that). The key "xdg-shell" protocol is still under development, but
for the (technically rather limited) use case of WaylandMonad, no
substantial changes are being introduced.

On 14 April 2015 at 14:41, Auke Booij <auke at tulcod.com> wrote:
> A few weeks ago, I sent in a Google Summer of Code application for the
> haskell.org organization to work on porting Xmonad to wayland. The
> haskell organization has asked me to find a mentor for my application,
> which is the main reason for this email.
>
> If you are
> 1. an adult (sorry kids, Google's rules)
> 2. experienced with the Xmonad source
> 3. interested in wayland
> 4. willing to spend some time this summer on mentoring me
> then please contact me or someone in the haskell community to discuss
> mentoring options. The deadline for proposal matching is the 24th of
> April, so please contact me within this week (or better yet, as soon
> as possible).
>
> Without a mentor, I cannot get accepted for GSoC. I am already up to
> speed on wayland, so I think any Xmonad developer with some free time
> would make a great mentor.
>
> I attached my GSoC application below.
>
> Any comment on making Xmonad work on wayland is welcome as well. My
> current plan is to fork Xmonad and replace all the X bits by wayland
> bits - see also my proposal below.
>
> Greetings,
> Auke.
>
>
> Abstract
> ===
> XMonad has, for a long time, been a flagship product of the Haskell
> community. With the arrival of wayland, XMonad is bound to look stuck
> in the past, and it's time for a port. Thanks to my previous work on
> wayland-related haskell libraries, this is now a viable project.
>
> Proposal
> ===
>
> Background
> ---
> X11 has long been the de facto standard way for applications to
> display graphical user interfaces on the screen. For various reasons,
> a new project called wayland has been started, that can be seen as a
> successor of the X ecosystem, or at least can be seen as something
> that will play a very important role. Among others, GNOME is already
> working on wayland support, and plans to make it fully supported by
> version 3.18. This shows the relevance of wayland.
>
> XMonad is a flagship product of the Haskell community that is often
> cited as an example of the applicability of Haskell: its real world
> value. XMonad is a compositor (aka window manager) for the X11
> ecosystem.
>
> In the new wayland ecosystem, one cannot reuse X11 compositors: they
> need to be partially rewritten.
>
> Goal
> ---
> I intend to fork XMonad and make it into a wayland compositor. Since
> the general ideas behind the X11 and the wayland protocol are not too
> different, this should be doable: we are still working with pointers
> and windows and input and output and renderings and messages. However,
> the wayland setup is technically very different from X11, since the
> central X11 server has been replaced by the compositor itself, and
> this means some very foundational code will need to be rewritten.
>
> I am the author of hayland [1], the haskell bindings to the wayland C
> library, as well as haskell-xkbcommon [2], the haskell bindings to the
> xkbcommon C library. With these two projects in place, the time is
> ripe for a wayland compositor written in haskell: the preliminaries
> are mostly there.
>
> As part of this project, I will have to invest some time in these two
> bindings projects as well (since they are quite new and have had
> little testing). For this reason, I intend to keep the scope of this
> project limited, and focus on getting some version of XMonad running
> on Wayland.
>
> I do not intend to change the architecture of XMonad, except wherever
> this would not require much more investment of time, and only as
> wished by the community. In other words: if you have anything that I
> should change about XMonad, and it is easy to switch to this new
> thing, then I'll use it. Any serious architectural changes will need
> to take place in a later stage.
>
> Deliverables
> ---
> - A working wayland compositor written in wayland, based on XMonad
> - Documentation of the source code (i.e. a technical document), user
> documentation (where this differs from XMonad)
> - Roadmap for further work: how should this project be continued into
> a next iteration of the XMonad project?
>
> Roadmap
> ---
> April/May: properly work my way through the XMonad source, and
> document things that will need changing
>
> June: Hack until it's working
>
> June+July: More hacking, also documentation
>
> August: Prepare a proper release, clean up code
>
> Bio
> ---
> I am currently studying for a Master of Logic in Amsterdam, and have a
> Master of Advanced Studies in Mathematics from Cambridge, UK, a BSc in
> Applied Mathematics and a BSc in Electrical Engineering (both from TU
> Delft).
>
> I have previously successfully finished GSoC (2010, with Gentoo) and
> SOCIS (in 2013, with PyBRML) (SOCIS is a GSoC-like program managed by
> the European Space Agency).
>
> I am the author of hayland [1], the haskell bindings to the wayland C
> library, as well as haskell-xkbcommon [2], the haskell bindings to the
> xkbcommon C library.
>
>
>
> The name of this fork is up for discussion.
>
> [1] https://github.com/tulcod/haskell-wayland
>
> [2] https://github.com/tulcod/haskell-xkbcommon