> [href]
Seen it, and seen the talk[1].
> we don't really "use" X these days
GTK+ and QT do not use a lot of X, as they render all their widgets with (e.g.) libcairo.so and libpango-1.0.so that only treat X as a framebuffer. Unfortunately, projecting your own usage habits onto others is an easy trap to fall into.
For example, one minor data point, from my desktop system - I use the built-in font server:
$ rdb -q | grep 'URxvt.*font'
URxvt*font: -xos4-terminus-medium-r-normal--14-140-72-72-c-80-iso10646-1
Why? Because it's (MUCH) faster to draw, doesn't slow down even remotely, and after is much clearer to read on the screen than the blurry mess[2] that pango/etc gives you.
/// that said ///
As I mention briefly, I was warming up to the idea of wayland. GTK+ and QT are certainly popular, and some things DO need to be fixed. The linked phoronix article (or talk) does bring up some good points. The massive amount of (serialized) round-trips to the x-server (even locally) that are mandated by the protocol is paticularly outrageous.
If backwards compatibility and remoting can be maintained through some sort of extension (or whatever), then it could even be a nearly-seamless drop in.
The clipboard and selection, on the other hand, have nothing to do with any of that. They aren't a performance problem, and there is no reason to remove it. In fact, given this is a big change in general, and an opportunity to fix some of the core protocols, why not /expand/ the idea to include a full kill-ring or similar? Call it a fix for CUT_BUFFER[0-7] that were never really used?
Changing protocols and the display pipeline ("things programmers have to worry about") is one thing. Cutting UI features that have been in place for a long time ("things users care about strongly") is a different world entirely.
> but a single clipboard is probably sufficient
When you've used both for decades, a single buffer is NOT sufficient. They end up serving completely different purposes, and are often needed simultaneously.
[1]: http://www.youtube.com/watch?v=RIctzAQOe44
[2]: http://www.antigrain.com/research/font_rasterization/index.h...