If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

And note too that this is Weston, not core Wayland. As such, this isn't directly applicable to getting a real desktop (KDE, Gnome, XFCE, etc) working on Wayland, since they'll probably not be using Weston. I'd look at this an experiment in how colour management should be implemented in the Wayland world - useful, but not real progress.

Comment

the to do list is largely outside of wayland. GTK and Qt support and the window managers. Am I only holding my breath until they ship it at default in a major distro with xwayland. After that its a slow transition, because most apps are not gtk3 or qt5

Comment

...having a massive interoperability test to check that a KDE application/Gnome application works with the Gnome/KDE server?

Why would that be necesasry? Both would still use the libwayland-server and libwayland-client libaries that implement the actual protocol. Also considering that Wayland forces the clients to do pretty much everything client side I wouldn't imagine there being much difference between Wayland compositors from application's point of view.

Also considering that Wayland forces the clients to do pretty much everything client side I wouldn't imagine there being much difference between Wayland compositors from application's point of view.

Uh? Both things are wrong:
1) many things are made server side: for example Weston moves windows server side (the client doesn't even know where its windows are on the screen!)
2) an example of a difference: KWin's main developer plans to use server side decoration whereas with Weston it's client side decoration, not much difference eh?