4 ms·

Need some shuteye (9am 'into the night'), but I think we are running into a similar misunderstanding that I spotted you having in the other Xorg thread. https:

Need some shuteye (9am 'into the night'), but I think we are running into a similar misunderstanding that I spotted you having in the other Xorg thread. https://github.com/wayland-project/wayland-protocols/blob/master/GOVERNANCE.md https://github.com/wayland-project/wayland-protocols/blob/ma... Is what I mean with political process. Patching the compositor is the wrong side of the equation, it doesn't work with networked clients and it's the client that needs most of the features. It's the client that needs to have a more expressive surface to work with. You can do these things safely and securely without the overbearing constraints and complexity of the policies that we are practically stuck with. See the trayicon/stream-deck articles. > I'm aware that Arcan got wayland support recently and that actually gives me more hope that we're not headed towards an apocalypse of protocol incompatibilities. I don't know if 4 years is recently in that span (see the dating my X post), but Xwayland support was initially decided as off limits. That was added recently because, as it turns out, those clients are still the ones that behave the most predictably and are the most robust. Even for applications that should handle both and I need to choose explicitly (arcan-wayland -exec-x11 the_thing or arcan-wayland -exec the_thing) I really only use the x11 side. Even for gtk and Qt. That's the real tragedy. I would say the babel-split is practically here because of all the sidebands and ad-hoc protocols that have been introduced specifically as a reaction to the strictness and limitations of the initial designs and the poor underlying primitives (as in the wire format and its de facto implementation).

cycloptic 6y ago
The wire format and the initial implementation are definitely flawed, but if you fix them you end up in the same situation again where you break everything every release and you go through all this politics trying to get everyone to use yet another new protocol and implementation. I see various complaints about that and it always comes back to the same thing. We have alternative implementations of the protocol but nobody uses them because of this. Consequently this is the same reason that it took so long to fix issues in X. I see what you mean with that document, but if you have been watching then none of that stuff is new or unique to Wayland. What you may have missed is that this document is a reaction to the politics that already were around in the X days. (I was alluding to this earlier when I was talking about WM atoms, the popular desktops already have their own sets of policies there that are necessary and incompatible and in some ways do limit the expressive power of clients) Not working with networked clients is a minor detail. It's trivial to have a user upload a compositor script to a different machine. If it becomes annoying to do it manually then a client that needs more features simply needs an automated way to do this. Still no need to touch the Wayland portions there either. I actually do appreciate the efforts to fix these issues with the whole shmif setup and I sympathize, but it's the same uphill political battle if you want to push that out to the rest of the ecosystem.
- crazyloglad 6y ago
  Part of it is that you either go to extreme lengths (like arcan-wayland) or it embeds itself so deep in the code base that it will be hard to get anywhere. If it doesn't get fixed, well, you don't have to be a reliability expert to be worried about this one: https://gitlab.freedesktop.org/wayland/wayland/-/issues/159 https://gitlab.freedesktop.org/wayland/wayland/-/issues/159 I have probably chased ghosts deep inside GTK from this one alone for multiple full time weeks, to no avail. There will eventually appear a rather harsh teardown post of some of the major mistakes in the implementation (and that alone, no xml business), wayland-server might not improve, but future designers should be able to stumble upon it. I think to get further with the discussion we need a sort of list of what mechanisms we consider mechanisms, and how policies project over them. Not to be disrespectful, but my budget for engagement is thin, pandemics, sorry :-/ The politics stuff - so I have some logs that precedes the formation that are quite incendiary and outright vile, but there is enough shit flinging to suffice to stop at there being good reason why I wouldn't consider getting closer than bayonet range, and why the post was obtuse enough to discourage most #metoo and discard me as an idiot who knows nothing. The tech stuff matters though and that's only what I want to see. A protocol and not marriage as if from 'the war of the roses'(1989). There is a fourth option that might materialise, but that's for then.
  - entropy1111 6y ago
    X was really bad for me and Wayland has been very reliable. Good enough for my work. Your posts are very political stuff too. If you want to be strictly technical just skip all the meta/drama and the boogeyman talk. In the post and in the comment section. It doesn't put you in a good light even if your statements turn out to be true. Your projects look very interesting. A suggestion for your next blog post would be talk about what you want to achieve, your real intentions, and how you plan to do that. If it's just a showcase make that clear. It's unfortunate that you don't want to work with what they have now but I hope you can find a compromise. It would be great if your contributions could make Wayland even better.
    - crazyloglad 6y ago

cycloptic 6y ago

The wire format and the initial implementation are definitely flawed, but if you fix them you end up in the same situation again where you break everything every release and you go through all this politics trying to get everyone to use yet another new protocol and implementation. I see various complaints about that and it always comes back to the same thing. We have alternative implementations of the protocol but nobody uses them because of this. Consequently this is the same reason that it took so long to fix issues in X. I see what you mean with that document, but if you have been watching then none of that stuff is new or unique to Wayland. What you may have missed is that this document is a reaction to the politics that already were around in the X days. (I was alluding to this earlier when I was talking about WM atoms, the popular desktops already have their own sets of policies there that are necessary and incompatible and in some ways do limit the expressive power of clients) Not working with networked clients is a minor detail. It's trivial to have a user upload a compositor script to a different machine. If it becomes annoying to do it manually then a client that needs more features simply needs an automated way to do this. Still no need to touch the Wayland portions there either. I actually do appreciate the efforts to fix these issues with the whole shmif setup and I sympathize, but it's the same uphill political battle if you want to push that out to the rest of the ecosystem.

crazyloglad 6y ago
Part of it is that you either go to extreme lengths (like arcan-wayland) or it embeds itself so deep in the code base that it will be hard to get anywhere. If it doesn't get fixed, well, you don't have to be a reliability expert to be worried about this one: https://gitlab.freedesktop.org/wayland/wayland/-/issues/159 https://gitlab.freedesktop.org/wayland/wayland/-/issues/159 I have probably chased ghosts deep inside GTK from this one alone for multiple full time weeks, to no avail. There will eventually appear a rather harsh teardown post of some of the major mistakes in the implementation (and that alone, no xml business), wayland-server might not improve, but future designers should be able to stumble upon it. I think to get further with the discussion we need a sort of list of what mechanisms we consider mechanisms, and how policies project over them. Not to be disrespectful, but my budget for engagement is thin, pandemics, sorry :-/ The politics stuff - so I have some logs that precedes the formation that are quite incendiary and outright vile, but there is enough shit flinging to suffice to stop at there being good reason why I wouldn't consider getting closer than bayonet range, and why the post was obtuse enough to discourage most #metoo and discard me as an idiot who knows nothing. The tech stuff matters though and that's only what I want to see. A protocol and not marriage as if from 'the war of the roses'(1989). There is a fourth option that might materialise, but that's for then.
- entropy1111 6y ago
  X was really bad for me and Wayland has been very reliable. Good enough for my work. Your posts are very political stuff too. If you want to be strictly technical just skip all the meta/drama and the boogeyman talk. In the post and in the comment section. It doesn't put you in a good light even if your statements turn out to be true. Your projects look very interesting. A suggestion for your next blog post would be talk about what you want to achieve, your real intentions, and how you plan to do that. If it's just a showcase make that clear. It's unfortunate that you don't want to work with what they have now but I hope you can find a compromise. It would be great if your contributions could make Wayland even better.
  - crazyloglad 6y ago