4 ms·
> The ability for one window to float over another was a later innovation and is of course more difficult to implement. I find it funny, because I would say I
by pqb 6y ago
> The ability for one window to float over another was a later innovation and is of course more difficult to implement.
I find it funny, because I would say I have seen more floating window manager, when I was browsing GitHub, so I assume it is also quite easy to create a new one from scratch. Such floating VMs usually have 200-1000 LOC and die after 1 month after initial commit. Recently, xwm has been on HN [0] and it is small in terms of SLOC. There is smaller one called tinywm[1]. When we would compare them to i3[2] and sway, we can see they have thousand times larger codebase but they also bring a lot more features.
I keep my fingers crossed for more sophisticated WMs like PaperWM[3], which is "tiled scrollable window manager" to take off. They might synthesize ideas from floating and tiling managers and provide a better tool to manage windows on a screen.
[0]: https://github.com/mcpcpc/xwm https://github.com/mcpcpc/xwm
[1]: https://github.com/mackstann/tinywm https://github.com/mackstann/tinywm
[2]: https://github.com/i3/i3 https://github.com/i3/i3
[3]: https://github.com/paperwm/PaperWM https://github.com/paperwm/PaperWM
- Blikkentrekker 6y ago> I find it funny, because I would say I have seen more floating window manager, when I was browsing GitHub, so I assume it is also quite easy to create a new one from scratch. Such floating VMs usually have 200-1000 LOC and die after 1 month after initial commit. Recently, xwm has been on HN [0] and it is small in terms of SLOC. There is smaller one called tinywm[1]. When we would compare them to i3[2] and sway, we can see they have thousand times larger codebase but they also bring a lot more features. That is because the X11 server handles the drawing of windows over each other. Older display protocols simply had no support for it.