Wol <[email protected]> writes:
Wayland has problems remembering where windows used to be.
Do you mean, there are limitations of the protocol that cause this? If so, i'd certainly be interested in the details.
But more generally, further to my last email, just because one compositor has issues with something, doesn't mean _all_ Wayland compositors have that issue. For example, a number of people who have issues with Mutter assume that 'Wayland' is the issue, when in fact the issue is that the Mutter devs consciously choose to not implement certain things. Likewise, it's incorrect to assume that Weston implements all possible functionality; as i said in my last email, it's not intended to be such a showcase, only a minimal example implementation. This is why i put together the "Functionality by compositor" section on the "List of software for Wayland" page on the wiki, which shows which compositors have implemented which interfaces. (Someone added the Niri column recently; i'm not sure how current the rest of the information now is, and unfortunately chronic health issues mean i'm not in a position to go through and update it.)
i've also noticed people assuming that if there isn't currently an implementation of some functionality that X implements, that it's not possible at all under Wayland. This is incorrect. For example, it used to be the case that there was no Wayland-session-over-the-network functionality. But in more recent times, people using compositors based on wlroots (e.g. Sway) might be able to use waypipe(1); i'm not sure what's the case for other compositors. And waypipe(1) might not actually be sufficient for some people's use cases right now, but that might be more due to a lack of volunteers to implement the relevant functionality, not because it's not possible under Wayland.
Alexis.
