What is so wrong with X? I understand that it is a mess and the developers have to work hard to add new features to it. But as a user of X I virtually have no problems.
For the future Wayland might be the correct way forward but I do not see any short term gain for the users.
1. Development of X is slow. Like "the kernel supports switching between gpus flawlessly but X needs a restart"-slow. Users notice this (though I don't know the current situation of this issue).
2. X-window-managers have awful performance compared to Windows. Try dragging a window around in IceWM or every other Linux desktop. It looks like hell, flickering borders and such. Though I remember a interview with the developer who did the first push for a new scheduler before cfq as he quit kernel-development who tried to tune the kernel for this, so this hasn't to be X fault.
Just found it, Con Kolivas and http://apcmag.com/interview_with_con_kolivas_part_1_computin...
Point is: The desktop of Linux is slow and maybe Wayland will help.
3. (It is always more) That it is a mess to develop for X (and it is) leads to bugs user will notice.
Some people complain about bloat and bad compositing performance under X, but my real problem with X is that it's very insecure. Any program running on a given X server can see any keyboard input to any other program running on the same server by default. As it stands, there's not a practical solution to this.
The Qubes project is interesting in some ways, but I think they're trying to do too much in one go, and as a result the final product doesn't seem very practical. For example, applications can't use hardware accelerated video according to their FAQ [1].
So pardon me while I braindump...
It would be an interesting project to integrate an Android-style permissions permissions system(possibly using SELinux) complete with per-application virtual filesystems (using FUSE) into the system package manager. So, for example, you install a music player, the package manager sets up a virtual filesystem for it that lets the program see its own configuration directory and your music directory, but nothing else. The package manager asks if you'd like to allow network permissions to the music player (for downloading album art or whatever); if yes, a firewall rule is added specifically allowing that process to access the network, if not, none is.
One problem with that kind of system is that a lot of end-user desktop programs are written with the assumption that the entire home directory is fair game. I'm not convinced that's really necessary, though. In case a program occasionally wants to access a file outside of its normal sandbox (say, you just downloaded a podcast into your downloads directory and want to play it with that music player I mentioned previously) you could always have the supervising program ask the user if it's okay to temporarily add that file to the program's sandbox. If it happens in an expected way (e.g. the user clicks on a media file in the file manager) you could safely grant access to the file without explicitly asking the user.
Something like that, on a distro using Wayland as the windowing system (to avoid the gaping security holes in X), would provide 90% of the security that Qubes does with significantly less inconvenience to the user. It would still require a good deal of work for the package maintainers, but perhaps a distro like that could implement something like the AUR [2] so users could do a lot of the packaging work for peripheral packages.
How do you think client-side window decorations impacts this? It seems to me that it would be difficult or impossible to create a secure GUI if every application gets such complete control over user interaction.
