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 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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

This also interests me, but I'm more of a drive-by contributor than an actual XMonad developer, so I don't know that I'd be a good fit to help get the project approved. On Fri, Apr 17, 2015 at 7:56 PM, joe skinner wrote:

This something that interests me but sadly not something I could help with

On Saturday, April 18, 2015, Carsten Mattner wrote:

...

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 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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

---

xmonad mailing list xmonad@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

_______________________________________________ xmonad mailing list xmonad@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad