[crazyloglad]

> I don't know if you've noticed, but "policy over mechanism" has thoroughly won in the desktop space. The dominant desktop is Windows; even macOS has several times the mind/market share that Linux has.

Windows exposes lots of WM mechanisms to a developer, hence why something like vrdesktop.net could be built in the first place, or previous WMs like LiteStep for that matter.

It is also why WINE does not, and cannot, have a working Wayland backend while sticking to the protocol. The same is true for X, but there XWayland requires the compositor developer to implement a sideband window manager to hack around the entire Wayland protocol to get X clients to work.

[cycloptic]

I haven't used a Microsoft OS in a long time but somebody told me a few years ago that alternative shells like Litestep became severely limited after the UI changes in Windows 8/10. Not sure if it's true or not or why that is.

I think you missed the mark on this though. I never saw Wayland as being any less about mechanism over policy. In theory X does have more mechanisms to work with but in practice the well-behaved programs that get used a lot tend use toolkits that follow ICCCM/EWMH strictly, and won't do strange things that are out of the ordinary with the policies of the popular desktops.

Compared to Wayland where the idea seems to be that WM implementers actually got more freedom to add any policies they want because they also implement the display server. From a client perspective it's still the same as X. Clients get what they need to function in isolation and don't really have to care about a WM's policies, and when they want to care they check for a specific policy. (In X they would check for an atom) I guess that probably doesn't work so well for Arcan because it also doesn't set anything in the way of policy. Maybe it would be possible for Arcan users to write policies as wayland extensions in lua?

[crazyloglad]

The mechanisms in Windows changed for doing some parts of it - as far as I recall it was due to the access controls (UAC) and DRM around the Window Manager (DWM) but it was a while ago, some vendors have figured out parts of working around DWM again - see the VR desktop mentioned and Stardock WindowFX.

I am not saying that the ones that X have are great or even that good to begin with. A better set could have likely avoided the ICCCM etc. but you can do a lot with just reparent+position - WMs are mostly normal clients after all.

Compare that to say the practically obligatory 'xdg_wm_base' specification, you are much more locked down, and the objects to work with are strongly interconnected. If you want to work around that as a 3rd party developer it's a political process + waiting for n*m compositors and toolkits to adapt.

People tend to miss that Arcan is a Wayland compositor as well, but those clients gets a special path where the WM has to follow extra sets of rules because of it.

I see it as a gradient. Neither is entirely Green (Mechanism) or Red (Policy) but if you look at the sets of both sides and position, I doubt you'll assign the same colors.

[cycloptic]

There's no political process. In GNOME if you want to do strange things with moving and reparenting windows from other processes then you write a GNOME extension. Same with KDE and kwin scripts. No touching of Wayland necessary. Fundamentally it doesn't seem that different from writing Arcan WMs. If all that's not enough then you write a new Wayland compositor with the policy you want, maybe using wlroots to save time. Overall that really hasn't changed much from writing X WMs, I don't get what the concern here is. At worst, it is a change that can be adapted to just like those changes you describe in DWM.

>you are much more locked down

Is this not what a policy is? The window manager locking down clients and enforcing that they can only do certain things? 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.

[crazyloglad]

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/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]

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]

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

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.