4 ms·

X has serious architectural problems. What would it mean to build a completely new windowing API using the extension system, if 'proper use' would mean using e

X has serious architectural problems. What would it mean to build a completely new windowing API using the extension system, if 'proper use' would mean using exclusively the new extended API? Is that meaningfully different from or better than building a new windowing system (cf wayland) and implementing x11 on top of it (cf xwayland)? FWIW, I think wayland also has serious architectural problems, and see arcan as much more promising, but rewriting/replacing legacy can definitely be justified. Extension hell is much worse than compatibility hell. If you don't like gtk4's api, then don't use it; gtk3 will continue to work. It's better that an api should be coherent and cohesive than that it should bend over backwards to keep compatibility with ideas that no longer make sense. Obviously, this should be applied within reason—don't do a complete rearchitecture every month—but compatibility breaks are important and necessary.

quotemstr 6y ago
> if 'proper use' would mean using exclusively the new extended API? Is that meaningfully different from building a new windowing system (cf wayland) and implementing x11 on top of it (cf xwayland)? We're already in a world where "proper use" of X11 means relying on ubiquitous extensions. Nobody uses the core font rendering APIs anymore --- instead, everyone uses fontconfig and XRENDER. The transition was gradual and smooth. Nobody had to rewrite applications. Both old-font-API and new-font-API X11 applications shared the same X server, the same connectivity configuration. The transition to Wayland should have looked like a super-XRENDER, not some bespoke new thing with an embedded X server that will always be a second-class citizen just like embedded X servers on Windows and macOS are. Making some grand new thing and emulating the legacy thing is harder to get right than just teaching the legacy thing to do something new. Why? Because in any rewrite, you not only have to rewrite the parts of the old system that are bad, but also the parts that are good.
- ATsch 6y ago
  Yet the people who were working on Xorg decided to write wayland instead. Why? Because there was little more benefit to he had from the previous approach. Xorg had become a slow and bloated synchronous IPC service and replacing it with a UNIX pipe was the logical solution.
  - quotemstr 6y ago
    > Xorg had become a slow and bloated synchronous IPC service and replacing it with a UNIX pipe was the logical solution. You do realize the the X11 server connection is also almost always a Unix socket, right? (ITYM "Unix socket", not "Unix pipe".) That's like showing out your spork and replacing it with a spork. > Yet the people who were working on Xorg decided to write wayland instead. My whole point is that they were wrong to do so, just like I think the GTK people are wrong to break ABI on GTK4.
    - ATsch 6y ago
      A completely new solution was inevitable because there was nothing more that could be done with Xorg. All of the complexity that mattered had moved into the WM, Compositor or Client. It wasn't actually doing anything anymore.
      - quotemstr 6y ago
        > A completely new solution was inevitable because there was nothing more that could be done with Xorg. I see no evidence behind this assertion. What specifically would have prevented the further evolution of Xorg? > All of the complexity that mattered had moved into the WM, Compositor or Client. Good. So that means that Xorg didn't have to change very much. All Xorg had to do is provide mechanism, not policy, and let WM, compositor, and client cooperate as they've been doing for decades. But instead the Xorg maintainers got bored and decided to make a big ball of mud with no separation of concerns.

quotemstr 6y ago

> if 'proper use' would mean using exclusively the new extended API? Is that meaningfully different from building a new windowing system (cf wayland) and implementing x11 on top of it (cf xwayland)? We're already in a world where "proper use" of X11 means relying on ubiquitous extensions. Nobody uses the core font rendering APIs anymore --- instead, everyone uses fontconfig and XRENDER. The transition was gradual and smooth. Nobody had to rewrite applications. Both old-font-API and new-font-API X11 applications shared the same X server, the same connectivity configuration. The transition to Wayland should have looked like a super-XRENDER, not some bespoke new thing with an embedded X server that will always be a second-class citizen just like embedded X servers on Windows and macOS are. Making some grand new thing and emulating the legacy thing is harder to get right than just teaching the legacy thing to do something new. Why? Because in any rewrite, you not only have to rewrite the parts of the old system that are bad, but also the parts that are good.

ATsch 6y ago
Yet the people who were working on Xorg decided to write wayland instead. Why? Because there was little more benefit to he had from the previous approach. Xorg had become a slow and bloated synchronous IPC service and replacing it with a UNIX pipe was the logical solution.
- quotemstr 6y ago
  > Xorg had become a slow and bloated synchronous IPC service and replacing it with a UNIX pipe was the logical solution. You do realize the the X11 server connection is also almost always a Unix socket, right? (ITYM "Unix socket", not "Unix pipe".) That's like showing out your spork and replacing it with a spork. > Yet the people who were working on Xorg decided to write wayland instead. My whole point is that they were wrong to do so, just like I think the GTK people are wrong to break ABI on GTK4.
  - ATsch 6y ago
    A completely new solution was inevitable because there was nothing more that could be done with Xorg. All of the complexity that mattered had moved into the WM, Compositor or Client. It wasn't actually doing anything anymore.
    - quotemstr 6y ago
      > A completely new solution was inevitable because there was nothing more that could be done with Xorg. I see no evidence behind this assertion. What specifically would have prevented the further evolution of Xorg? > All of the complexity that mattered had moved into the WM, Compositor or Client. Good. So that means that Xorg didn't have to change very much. All Xorg had to do is provide mechanism, not policy, and let WM, compositor, and client cooperate as they've been doing for decades. But instead the Xorg maintainers got bored and decided to make a big ball of mud with no separation of concerns.