Originally posted by sinepgib
View Post
Announcement
Collapse
No announcement yet.
X Window System Turns 38 Years Old
Collapse
X
-
- Likes 1
-
Originally posted by billyswong View PostI was replying to a client side decoration supporter that claimed server side decoration is BS.
Yeah, CSD is quite short sighted. I can't deny it's pretty and may have its use, but assuming no mistakes were made has always been the greatest mistake of modern computing.
Leave a comment:
-
Originally posted by sinepgib View Post
As long as the compositor itself is not hanged and you use server side decorations, shouldn't all that still work?
Leave a comment:
-
Originally posted by billyswong View PostThere are valid reasons for "two processes be responsible for drawing one window". I like hanged / busy windows still being draggable and the minimize / close button still works.
Leave a comment:
-
And the supposed "modern" protocol made the wrong assumption that fractional scaling is unneeded because it wouldn't be popular for all the alignment issue. The Wayland team is proven wrong. The manufacturers don't care. The consumers don't care enough. The market, 10 years after Apple's "Retina" is out, is full of monitors that expect people to use fractional scaling, especially laptop monitors and 4k monitors. Near 10 years are wasted because they insisted on downscaling window surfaces in compositor layer from integer scale to fractional scale, taking blurriness and inefficiency for everybody instead of some potential gaps and out of alignment for less well written software.
Now various mitigation proposals for Wayland are being written and tried by compositors outside the GNOME ecosystem. We will see which of them succeed. It is also possible for someone to come up with implementation for Windows-like mixed-DPI fractional scaling support in X.Org, now that X.Org is not maintained by the personnel in Wayland team and they can no longer block innovations there. The only true limitation of X in mixed DPI support is that it can't give a totally smooth drag of windows from screen A to screen B across DPI boundary, while keeping the window size "correct" in both sides. In the crossing phase, either one side would be too big or another side would be too small, just like what's happening in Windows.
- Likes 1
Leave a comment:
-
Originally posted by Alexmitter View Post
Why should Gnome shoot itself in the foot by adopting old mistakes into a modern protocol.
Why should two processes be responsible for drawing one window, it was madness in the past and never properly worked, why in gods name should we do that BS again.
KDE adopted that because why should they care if something sucks, producing a desktop that sucks is in their DNA.
Again there already is a proper solution, which is either already adopted by the usual "toolkits" like SDL2. https://www.phoronix.com/scan.php?pa...L2-Wayland-CSD
- Likes 1
Leave a comment:
-
Originally posted by Old Grouch View PostMy natural state is cynical pessimism (which I defend as realism), so people like you are needed for balance.
- Likes 1
Leave a comment:
-
Originally posted by sinepgib View PostMaybe I'm too much of an optimist with this, I don't know.
- Likes 1
Leave a comment:
-
Originally posted by MorrisS. View Post
Normally, I don't communicate with non sense people, even if I make an exception replying to you in this case. As for your message, it is possible that I've missed your reply for not personal reasons. any way from your argument I get the following suggestion: try to cure yourself you have mental issues.
By the way: no notification was sent about your reply.
Leave a comment:
Leave a comment: