The issue isn’t just that the features had to be reimplemented, but that they were not part of Wayland to begin with. Wayland does only do the most basic stuff and leaves everything else to the compositor (aka Gnome or KDE). That means every compositor will implement their own hacky version of the missing functionality and it takes ages until that gets unified again, so that apps can actually use that functionality.
Wayland is a classic case of an underspecified software project, they do a thing and they might even do it well, but what they are doing is only a fraction of what is actually needed for it to work properly in the real world. That’s why we are 15 years later and the new “simpler” Wayland is still not ready.
Wayland does only do the most basic stuff and leaves everything else to the compositor (aka Gnome or KDE). That means every compositor will implement their own hacky version of the missing functionality and it takes ages until that gets unified again, so that apps can actually use that functionality.
Would this functionality be mostly the same? Could they get together to make a shared libcompositor that implements the bulk of the functionality? Or is it so tied to specifics of the desktop environment that there’s little commonality. In which case, Wayland not doing it would be the right call.
I think wlroots is the standardized thing. Many WMs use it but desktops need to switch over to it afaik. I think KDE talked about doing this for plasma.
I am unsure what wlroots really is and maybe its not a libcompositor you were talking about but similar.
It seems very well specified to me, just developers have leaned on X’s insecurity for years to let them just reach across application boundaries freely. That’s addressed by Wayland, but it’s obviously a breaking change that requires new ways of transferring information between apps with oversight from the system, instead of X where all apps could just freely spy on each other. Things breaking and being complex to reimplement is the cost of doing it right.
The issue isn’t just that the features had to be reimplemented, but that they were not part of Wayland to begin with. Wayland does only do the most basic stuff and leaves everything else to the compositor (aka Gnome or KDE). That means every compositor will implement their own hacky version of the missing functionality and it takes ages until that gets unified again, so that apps can actually use that functionality.
Wayland is a classic case of an underspecified software project, they do a thing and they might even do it well, but what they are doing is only a fraction of what is actually needed for it to work properly in the real world. That’s why we are 15 years later and the new “simpler” Wayland is still not ready.
Would this functionality be mostly the same? Could they get together to make a shared libcompositor that implements the bulk of the functionality? Or is it so tied to specifics of the desktop environment that there’s little commonality. In which case, Wayland not doing it would be the right call.
I think wlroots is the standardized thing. Many WMs use it but desktops need to switch over to it afaik. I think KDE talked about doing this for plasma.
I am unsure what wlroots really is and maybe its not a libcompositor you were talking about but similar.
This is exactly what it is.
It seems very well specified to me, just developers have leaned on X’s insecurity for years to let them just reach across application boundaries freely. That’s addressed by Wayland, but it’s obviously a breaking change that requires new ways of transferring information between apps with oversight from the system, instead of X where all apps could just freely spy on each other. Things breaking and being complex to reimplement is the cost of doing it right.