News for hackers. Stuff that matters.
Re:The future of Wayland, and Sway's role in it by Sir_Cmpwn on Thursday October 19, 2017 @01:31PM (#15509811)
A simplified view follows:

Previously: displays & input devices -> xorg-server -> compton -> window manager -> X11 protocol -> X11 clients

Now: displays & input devices -> wayland compositor -> wayland protocol -> wayland clients

Re:The future of Wayland, and Sway's role in it by apetresc on Thursday October 19, 2017 @03:50PM (#15511026)
So does that mean that if you wanted to port, say, Xmonad to Wayland, you would have to reimplement compositing logic again? (Since the existing compositing-logic implementation also handles things like window placement that you would want to override)
Re:The future of Wayland, and Sway's role in it by Sir_Cmpwn on Thursday October 19, 2017 @03:58PM (#15511069)
In theory, yes. In practice, you could build something on top of wlroots, which does a lot of the work for you. In fact, check this out:

https://github.com/swaywm/hsroots

Re:The future of Wayland, and Sway's role in it by apetresc on Friday October 20, 2017 @03:11PM (#15518434)
Thank you for the clarifications :)
Re:The future of Wayland, and Sway's role in it by jononor on Thursday October 19, 2017 @07:04PM (#15512294)
An X window manager would likely have to be completely rewritten to work on Wayland, I doubt many of them have much abstraction of the underlying window system.