* do not want just the big Windows-like inefficient and bloated Gnome and KDE desktop environments. And also for those that like or need having various "desktop environments" to switch between.
* like to programmatically grab and inject input events. I.e., AFAIK you will not be able to implement atbswp for Wayland environments using pure Wayland, if at all. Even if you do succeed (by depending on a Wayland extension, working with specific compositors or talking directly to the kernel), it will be more difficult than for X Windows.
Quoting my comment from this thread, near yours:
> Wayland compositors, unlike X Windows window managers, are complicated to implement and on top of that the Wayland protocol standardizes little. This hurts the Wayland compositor ecosystem (again, as compared to X Window managers), and the lack of standardization hurts users directly, too (because then we have to rely on compositor-specific features, thus being tied to that compositor implementation). Last time I looked there still was not any prevalent solution to injecting or logging input events, and even capturing the screen (screen shot) was dependent on the specific compositor implementation. Remember the excuse for ditching X Windows? It was X having too many extensions to the standard. But even that is better than not standardizing on expected features at all.
> Note that I am not saying X Windows is "good", but the fact is Wayland's design is hostile to a lot of things that work with X Windows, instead of Wayland improving on X Windows. So how could I be content with Wayland possibly replacing Xorg?
* do not want just the big Windows-like inefficient and bloated Gnome and KDE desktop environments. And also for those that like or need having various "desktop environments" to switch between.
* like to programmatically grab and inject input events. I.e., AFAIK you will not be able to implement atbswp for Wayland environments using pure Wayland, if at all. Even if you do succeed (by depending on a Wayland extension, working with specific compositors or talking directly to the kernel), it will be more difficult than for X Windows.
Quoting my comment from this thread, near yours:
> Wayland compositors, unlike X Windows window managers, are complicated to implement and on top of that the Wayland protocol standardizes little. This hurts the Wayland compositor ecosystem (again, as compared to X Window managers), and the lack of standardization hurts users directly, too (because then we have to rely on compositor-specific features, thus being tied to that compositor implementation). Last time I looked there still was not any prevalent solution to injecting or logging input events, and even capturing the screen (screen shot) was dependent on the specific compositor implementation. Remember the excuse for ditching X Windows? It was X having too many extensions to the standard. But even that is better than not standardizing on expected features at all.
> Note that I am not saying X Windows is "good", but the fact is Wayland's design is hostile to a lot of things that work with X Windows, instead of Wayland improving on X Windows. So how could I be content with Wayland possibly replacing Xorg?
Also see these (sub)threads:
https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_...
https://news.ycombinator.com/item?id=20376316
https://news.ycombinator.com/item?id=20379423