[xmonad] WaylandMonad

[Carsten Mattner]

Sounds like a good project to me and I'd like to see the results.

On Thu, Apr 16, 2015 at 11:30 PM, Auke Booij <auke at tulcod.com> wrote:
> 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
> _______________________________________________
> xmonad mailing list
> xmonad at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad