4 ms·

> You asked if other X servers are used, Allow me to qualify: ON LINUX! Sorry if that wasn't blindingly obvious when I said I was totally on-board with a DRI

by jude- 6y ago

> You asked if other X servers are used, Allow me to qualify: ON LINUX! Sorry if that wasn't blindingly obvious when I said I was totally on-board with a DRI3-only X server. > The point with that is that you're bringing your own compositing and multiplexing anyway. I did not have to do this in the X server world. I did not have to worry about inter-compositor compatibility, because there was only one compositor implementation. Wayland has made me have to do extra work for absolutely no gain. This has got to be the fifth time I've explained this on this comment thread. I don't know how much clearer I can be. > From there it's optional if implementations want to put in additional features for IPC, window management, hotkeys, screenshots, etc, and they can choose if they want to put that in the server or put it in a separate program. So you can still mix and match on some level anyway, it's not quite the same though. I'm glad you've understood that N different window managers will now have N different ways of doing this, whereas before, N different window managers only had 1 way of doing this. It's nowhere near close to the same -- now in order to do one thing reliably, I have to implement it N different ways. It's infuriating that none of the Wayland fans seem to see this as a problem. It's almost as if they're the ones who won't be suffering the consequences of their bad architectural decisions!

cycloptic 6y ago
If you're talking about making something that is Linux only, that also would be a no-go for X clients that expect to run on other operating systems. They would still want to maintain the old code path, so it wouldn't help much. You do have to bring your own multiplexing in the X world if you were implementing an X compositor. Maybe that's unfortunate to you that the focus changed to X compositors, but Wayland didn't change the fact that this work has to be done by some willing party to get that to work. I wouldn't call myself a "Wayland fan" but what you are saying isn't really a problem, the different window managers can choose to implement it just one way. They don't have to do it N different ways, of course they will do it differently if they have a valid reason to. From an application developer perspective you shouldn't have to deal with this problem, I'm sorry if you are a toolkit developer and this has caused you pain, but in my experience nearly all of the bits that you would need to have to do a native port to Wayland aren't specific to any window manager.
- jude- 6y ago
  > the different window managers can choose to implement it just one way. They don't have to do it N different ways, Not holding my breath. Just because you have a standard doesn't mean all implementations behave the same. In fact, they usually don't, which is the problem. > but what you are saying isn't really a problem Thank you for proving my point about being in a position where you don't have to suffer the consequences of your bad architectural decisions.

by jude- 6y ago

cycloptic 6y ago

If you're talking about making something that is Linux only, that also would be a no-go for X clients that expect to run on other operating systems. They would still want to maintain the old code path, so it wouldn't help much. You do have to bring your own multiplexing in the X world if you were implementing an X compositor. Maybe that's unfortunate to you that the focus changed to X compositors, but Wayland didn't change the fact that this work has to be done by some willing party to get that to work. I wouldn't call myself a "Wayland fan" but what you are saying isn't really a problem, the different window managers can choose to implement it just one way. They don't have to do it N different ways, of course they will do it differently if they have a valid reason to. From an application developer perspective you shouldn't have to deal with this problem, I'm sorry if you are a toolkit developer and this has caused you pain, but in my experience nearly all of the bits that you would need to have to do a native port to Wayland aren't specific to any window manager.

jude- 6y ago
> the different window managers can choose to implement it just one way. They don't have to do it N different ways, Not holding my breath. Just because you have a standard doesn't mean all implementations behave the same. In fact, they usually don't, which is the problem. > but what you are saying isn't really a problem Thank you for proving my point about being in a position where you don't have to suffer the consequences of your bad architectural decisions.