4 ms·

> 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 t

• cycloptic 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
        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).