3 ms·

In X, any client can keylog all other clients. Also, without compositing you need to re-render the window when it moves into the screen. X is really just a midd

In X, any client can keylog all other clients. Also, without compositing you need to re-render the window when it moves into the screen. X is really just a middle-man that doesn't do much (that's why DRI is used). > a de novo solution will necessarily need similar levels of work to get to a similar point. No, X contains lots of cruft and hacks.

pdkl95 10y ago
> In X, any client can keylog all other clients. Yes, that's a feature that some of us use. Any replacement needs to support that ability, or it isn't a functional replacement. > without compositing you need to re-render the window when it moves into the screen Some of that is prevented by setting the save-unders flag. More can be prevented if toolkits bothered to draw using X instead of re-sending client-rendered pixmaps on every update (a lot of the people complaining about X are not actually using X for most of their work). However, isn't the whole point of Wayland is that it's a compositing-only server? It's simply forcing the choice to enable compositing. Enabling the Composite extension in xorg fixed the redraw problem years ago. This isn't a Wayland-only feature. > X is really just a middle-man that doesn't do much That's only true for a small set of X clients. > No, X contains lots of cruft and hacks. A lot of that "cruft" is backwards compatibility that doesn't interfere with modern applications and is needed to run older software. Choosing to break 20+ years of software by removing these features is not an acceptable solution. More importantly, a lot of the problems with X are actually problems with the specific implementation of X known as "X.org". A lot of confusion happens when people confuse X (a protocol and specification for display servers and client interface) with an implementation of X ("XFree86", "X.org", others).
- witty_username 10y ago
  > Yes, that's a feature that some of us use. Any replacement needs to support that ability, or it isn't a functional replacement. No it doesn't. There is no need for any client without any permissions or privileges to be able to snoop on other processes. Why not let users decide which clients can snoop? > That's only true for a small set of X clients. What does X do? > More can be prevented if toolkits bothered to draw using X instead of re-sending client-rendered pixmaps on every update (a lot of the people complaining about X are not actually using X for most of their work). No, that is how X works. I found out this when experimenting with creating my own toolkit. The Composite extension fixes this. > Choosing to break 20+ years of software by removing these features is not an acceptable solution. It is acceptable. Most people don't use 20 year old software. XWayland can be used to keep backwards compatibility.

pdkl95 10y ago

> In X, any client can keylog all other clients. Yes, that's a feature that some of us use. Any replacement needs to support that ability, or it isn't a functional replacement. > without compositing you need to re-render the window when it moves into the screen Some of that is prevented by setting the save-unders flag. More can be prevented if toolkits bothered to draw using X instead of re-sending client-rendered pixmaps on every update (a lot of the people complaining about X are not actually using X for most of their work). However, isn't the whole point of Wayland is that it's a compositing-only server? It's simply forcing the choice to enable compositing. Enabling the Composite extension in xorg fixed the redraw problem years ago. This isn't a Wayland-only feature. > X is really just a middle-man that doesn't do much That's only true for a small set of X clients. > No, X contains lots of cruft and hacks. A lot of that "cruft" is backwards compatibility that doesn't interfere with modern applications and is needed to run older software. Choosing to break 20+ years of software by removing these features is not an acceptable solution. More importantly, a lot of the problems with X are actually problems with the specific implementation of X known as "X.org". A lot of confusion happens when people confuse X (a protocol and specification for display servers and client interface) with an implementation of X ("XFree86", "X.org", others).

witty_username 10y ago
> Yes, that's a feature that some of us use. Any replacement needs to support that ability, or it isn't a functional replacement. No it doesn't. There is no need for any client without any permissions or privileges to be able to snoop on other processes. Why not let users decide which clients can snoop? > That's only true for a small set of X clients. What does X do? > More can be prevented if toolkits bothered to draw using X instead of re-sending client-rendered pixmaps on every update (a lot of the people complaining about X are not actually using X for most of their work). No, that is how X works. I found out this when experimenting with creating my own toolkit. The Composite extension fixes this. > Choosing to break 20+ years of software by removing these features is not an acceptable solution. It is acceptable. Most people don't use 20 year old software. XWayland can be used to keep backwards compatibility.