There are always bugs in complex software, so sure. I can also consider myself lucky that I'm not forced into using a Wayland compositor as it'd force me to change my workflows in all kinds of ways.
> If you only care about bugs that affect you then it's not even worth having a discussion about this, you can't expect everyone to wait to make changes until it's personally convenient for you
I'm not expecting anything other than to keep using the software which works for me. I'm not the one arguing for people to change setups that works for us. Use what works for you. If that's Wayland that's your choice. For me it's not - it involves putting effort into something that doesn't give me amy benefits. Nobody is arguing for you to do anything or not anything.
> I would urge you to look into how much work it would take to actually fix those bugs and push out incompatible server/libraries/etc to people and then come back and see if you'd like to revise this statement.
No, I wouldn't like to revise that statement, because none of the bugs are relevant for an updated protocol unless you choose to keep the things that are broken, since the "worst case" is to throw away and start over the same way Wayland did.
> Remember what you are asking here is for every toolkit and program to do a "if x12 then dostuff elseif x11 then do otherstuff" and weigh that versus "if wayland then dostuff elseif x11 then do otherstuff".
And it's obvious that the number of if x12 then dostuff would have been far smaller and/or amortized over longer time because you'd only need them in cases where you actually introduced a breaking change that couldn't be fixed by using functionality that would keep working the same on both.
Most modern X11 apps already don't use most of the functionality of X that is worth deprecating, and for many of those who do the solution would be to change to a request that'd be worth keeping, not to add an if x12. E.g. as I mentioned there are a number of different ways of rendering text with X. The most popular terminals are split roughly in two broad groups: Those who use the old server side rendering, and those who use XRender (a couple of outliers use OpenGL). Most of the ones I've looked at use Xlib etc. directly rather than toolkits, though some of the font stuff in Xlib is wrapping the server side functionality in ways that could be retargeted to use Freetype.
If you remove the former, then ~half of the terminals would need to get updated to use the latter method or forced to use a proxy (ditching most of them isn't really an option - many of the most feature-complete ones use X directly, and all of the ones I have looked at have users who swear by them and will keep using them until there is a feature complete replacement; many of them are decades old and their users still don't agree there's one worth switching to) or client-side reimplementation of the font rendering. But assuming you were to retain the XRender glyph rendering you wouldn't need to special case for this hypothetical x12, just upgrade apps to use XRender, and you could yank out all the font support in the server. Moving to Wayland on the other hand requires all of them to change
To date most of the terminals I've looked at haven't been updated with Wayland support, and many probably never will, making XWayland and so most of Xorg still hang around as long as they have users and someone cares. Given how long many of them have survived, I'm guessing you'll have to wait for their user bases to literally die out.
The X12 approach would have allowed starting to actually deploy the improvements stepwise more than a decade ago. Or more. E.g. the XFIXES extension happened in 2003 and was the first real attempt at some somewhat potentially breaking changes hidden behind an extension flag rather than a version change (and didn't allow the server to actually ditch the old code). Nothing other than politics stopped a more drastic approach.
This notion that there were technical barriers stopping an iteration of X is pure fiction.
> If you only care about bugs that affect you then it's not even worth having a discussion about this, you can't expect everyone to wait to make changes until it's personally convenient for you
I'm not expecting anything other than to keep using the software which works for me. I'm not the one arguing for people to change setups that works for us. Use what works for you. If that's Wayland that's your choice. For me it's not - it involves putting effort into something that doesn't give me amy benefits. Nobody is arguing for you to do anything or not anything.
> I would urge you to look into how much work it would take to actually fix those bugs and push out incompatible server/libraries/etc to people and then come back and see if you'd like to revise this statement.
No, I wouldn't like to revise that statement, because none of the bugs are relevant for an updated protocol unless you choose to keep the things that are broken, since the "worst case" is to throw away and start over the same way Wayland did.
> Remember what you are asking here is for every toolkit and program to do a "if x12 then dostuff elseif x11 then do otherstuff" and weigh that versus "if wayland then dostuff elseif x11 then do otherstuff".
And it's obvious that the number of if x12 then dostuff would have been far smaller and/or amortized over longer time because you'd only need them in cases where you actually introduced a breaking change that couldn't be fixed by using functionality that would keep working the same on both.
Most modern X11 apps already don't use most of the functionality of X that is worth deprecating, and for many of those who do the solution would be to change to a request that'd be worth keeping, not to add an if x12. E.g. as I mentioned there are a number of different ways of rendering text with X. The most popular terminals are split roughly in two broad groups: Those who use the old server side rendering, and those who use XRender (a couple of outliers use OpenGL). Most of the ones I've looked at use Xlib etc. directly rather than toolkits, though some of the font stuff in Xlib is wrapping the server side functionality in ways that could be retargeted to use Freetype.
If you remove the former, then ~half of the terminals would need to get updated to use the latter method or forced to use a proxy (ditching most of them isn't really an option - many of the most feature-complete ones use X directly, and all of the ones I have looked at have users who swear by them and will keep using them until there is a feature complete replacement; many of them are decades old and their users still don't agree there's one worth switching to) or client-side reimplementation of the font rendering. But assuming you were to retain the XRender glyph rendering you wouldn't need to special case for this hypothetical x12, just upgrade apps to use XRender, and you could yank out all the font support in the server. Moving to Wayland on the other hand requires all of them to change
To date most of the terminals I've looked at haven't been updated with Wayland support, and many probably never will, making XWayland and so most of Xorg still hang around as long as they have users and someone cares. Given how long many of them have survived, I'm guessing you'll have to wait for their user bases to literally die out.
The X12 approach would have allowed starting to actually deploy the improvements stepwise more than a decade ago. Or more. E.g. the XFIXES extension happened in 2003 and was the first real attempt at some somewhat potentially breaking changes hidden behind an extension flag rather than a version change (and didn't allow the server to actually ditch the old code). Nothing other than politics stopped a more drastic approach.
This notion that there were technical barriers stopping an iteration of X is pure fiction.