So does this mean that I wouldn't be able to say remotely display a desktop environment which uses QT and within that click a shortcut to a GTK app and expect it to open and be managed by that QT desktop environment.
Remember KDE and Gnome cooperate and there is dbus. What would likely happen is something like this:
a) KDE desktop is running and you click on a Gnome application.
b) KDE passes a message to the local Gnome to handle remoting
c) local Gnome establishes a session with remote Gnome.
d) Those two communicate making the application effectively local
e) The Gnome applications displays on the KDE desktop using the tools they use today to do this sort of thing (dbus...)
So from an end user standpoint nothing changes
Once you have your desktop environment displaying remotely everything you do looks and feels local. How can you have that when each app may have a different remote implementation?
You could get a local feel, its up to the toolkit. You could get something much better. Each application and each toolkit makes intelligent choices about how to handle latency issues. So for example one application might very aggressively cache if latencies are high, while another might be more worried about processing delays and thus might keep intermediate buffers shallow to reduce the effective latency as much as possible even though this means the buffer runs dry. Apple incidentally is currently doing some brilliant work on buffers taking ideas that Linux invented and making them practical. With Wayland Linux applications and thus users will be able to take advantage of these advances.
Yes it is. In my previous statement I chose QT and GTK as examples because they are so common. A user could have any number of applications using any number of GUI toolkits. Assuming they will all bother to implement their own remote access would way over-optimistic.
If an application is written using a toolkit that doesn't support remoting then the application doesn't support remoting by design. The major Linux toolkits are already working with the Wayland team they fully intend to support it. I'd assume that highly specialized toolkits which don't remote, don't remote because they can't tolerate latency. For example good touch toolkits might fail at 1ms latency, 1ms is too fast even for almost all LANs to keep up.
So let's use this example. Human brains aren't designed for touch latency... you are using a touch toolkit that would be unusable remotely. What's the problem if it doesn't remote?
If I can watch a high definition video feed in real time over the internet then I should be able to remotely display a desktop or a user should be able to remotely display a game. The two should not be mutually exclusive. Surely it is possible to fix this in a way that pleases the gamer without screwing it up for the remote desktop user.
It isn't possible to do both. I'll just repeat what I wrote in the post directly above, " There are advantages to splitting application and video buffers for network transparency. There are advantages to unifying application and video buffers for performance." You have to pick. Either the person who wants performance has to lose or the person who wants network transparency has to lose. There are lots of either / or choices in life, there are lots of either / or choices in designing a windowing system. You cannot build a system where everyone gets everything. And even if I were wrong, X11 most certainly is not such a system. In the world of 2015 X11 mostly sucks at everything but via. hacks is painfully being kept alive. The low level choices you keep dismissing fundamentally alter what the system is capable of doing. For you to get feature F Mr G has to not get feature H.
Wayland people are not taking away stuff to be mean or because they are lazy. They are taking away things because they are balancing out the greatest good for the greatest number. Given the 2015 computing environment* the feature set Wayland choose was arguably the best choice. There is no question that X11's feature set is a dreadful choice.
* or more accurately given the 2008 computing environment, Wayland itself is falling behind.
I should be able to see my favorite desktop manager and click shortcuts within it without worrying about which toolkit each uses. It should just work.. just like it does now.
And you will be able to do that. And most likely it will be far better than now.