Wayback 0.3 released
-
(4, contd) We need *some way* to give people the freedom to replace the compositor out from under the DE if they need a better feature set, so that extension innovation becomes possible. I may about to be say something incorrect, but I believe the problem here is GNOME. I *think* other DEs/WMs are ultimately based on wlroots, so wlroots-based compositors could be drop in replacements. But GNOME's Mutter is way more specialized. IDK how to work around that. We all switch to Cosmic? :(
> We need *some way* to give people the freedom to replace the compositor out from under the DE if they need a better feature set, so that extension innovation becomes possible.
more than this, we need software that actually works by default. it's easy to get distracted by how technical people can tinker themselves out of this mess, but at the end of the day most users aren't hypernerds and couldn't give a toss about any of that. they just want their computer to let them work
-
@mcc @glennseto i thought about this a few days ago—it might be fun to do a gnome-shell-ish compositor based on wlroots which can run gnome shell's javascript stuff as a regular wayland client, using wlr-layer-shell, instead of being baked into the compositor. then the top bar, dock and neat control panel and extensions could be shared with other desktops, while not being at the whim of mutter's rendering. i think there's no really well engineered bar+control panel thing outside gnome+kde.
@mntmn @mcc @glennseto yeah i mean the architecture of gnome-shell is kinda terrifying broadly. like why is there javascript running in the compositor. why is dynamically switching to triple buffering to work around performance issues in javascript and rendering. in any of my head-canon work in the space i'd want to yeet gnome-shell out of the compositor, and have the compositor just do compositing robustly and fast. (broadly this is a core issue i have with wayland architecture anyway)
-
@mntmn @mcc @glennseto yeah i mean the architecture of gnome-shell is kinda terrifying broadly. like why is there javascript running in the compositor. why is dynamically switching to triple buffering to work around performance issues in javascript and rendering. in any of my head-canon work in the space i'd want to yeet gnome-shell out of the compositor, and have the compositor just do compositing robustly and fast. (broadly this is a core issue i have with wayland architecture anyway)
@dotstdy @mcc @glennseto yes, that is pretty terrifying. i don't think this architecture was intended by the people dreaming up wayland protocols. wayland seems pretty performance oriented to me
-
> We need *some way* to give people the freedom to replace the compositor out from under the DE if they need a better feature set, so that extension innovation becomes possible.
more than this, we need software that actually works by default. it's easy to get distracted by how technical people can tinker themselves out of this mess, but at the end of the day most users aren't hypernerds and couldn't give a toss about any of that. they just want their computer to let them work
@mcc @glennseto step 1 is the hypernerds tinkering themselves out of that mess. step 2 is a bunch of other hypernerds packaging that up as a ready-to-go solution. step 3 is now we have some half-baked solution that patched over a deficiency in what was available, but since it's the only frictionless way to do it right now that's what everyone does. repeat forever. oh whoops we're back with the X11 problem of immense techdebt.
-
@dotstdy @mcc @glennseto yes, that is pretty terrifying. i don't think this architecture was intended by the people dreaming up wayland protocols. wayland seems pretty performance oriented to me
@mntmn @mcc @glennseto it's part of wayland's core design to unify the compositor and the window manager. one could imagine they were thinking of a window manager / shell that wasn't written in javascript at the time, but i think i disagree with it either way. and you can see kde doing the work to undo the damage.
-
@mcc @glennseto step 1 is the hypernerds tinkering themselves out of that mess. step 2 is a bunch of other hypernerds packaging that up as a ready-to-go solution. step 3 is now we have some half-baked solution that patched over a deficiency in what was available, but since it's the only frictionless way to do it right now that's what everyone does. repeat forever. oh whoops we're back with the X11 problem of immense techdebt.
@gsuberland @glennseto it's so frustrating that *canonically*, like *according to the Linux hater's handbook*, the big mistake X11 made early was not standardizing enough in the base protocol and deferring everything to extensions. And then Wayland did the exact!! Same!! Thing!! how does an entire community make the same mistake TWICE
-
@gsuberland @glennseto it's so frustrating that *canonically*, like *according to the Linux hater's handbook*, the big mistake X11 made early was not standardizing enough in the base protocol and deferring everything to extensions. And then Wayland did the exact!! Same!! Thing!! how does an entire community make the same mistake TWICE
@gsuberland @glennseto I realize that having a core profile which lacks knowledge of things like windows and pixels and just configures u a Vulkan surface is useful for like VR headsets and car infotainment boxes, and that's something that should exist. But I would have expected then like. I don't know. A "desktop usage profile" set of standard extensions that a WM needs. Does that exist? Is that slated to exist? I am in the dark.
-
@gsuberland @glennseto I realize that having a core profile which lacks knowledge of things like windows and pixels and just configures u a Vulkan surface is useful for like VR headsets and car infotainment boxes, and that's something that should exist. But I would have expected then like. I don't know. A "desktop usage profile" set of standard extensions that a WM needs. Does that exist? Is that slated to exist? I am in the dark.
@mcc @gsuberland @glennseto no, it is not a thing, nor is it likely to become a thing. basically the position of the wayland committee such as it is, is that implementations should be free to do whatever they like, and that there's no binding power in wayland anyway. (which is why things like server-side-decorations aren't universally supported, as an example)
-
@mntmn @mcc @glennseto it's part of wayland's core design to unify the compositor and the window manager. one could imagine they were thinking of a window manager / shell that wasn't written in javascript at the time, but i think i disagree with it either way. and you can see kde doing the work to undo the damage.
@dotstdy @mntmn @glennseto unifying compositor with window manager is definitely unacceptable if the compositor also determines which features are available to apps.
i guess one question is whether the things KDE, GNOME, etc need to do their window-manager-y things could be pushed into an extension and then downstreamed from the compositor. I don't know how you get KDE, GNOME on board with that. But "no fundamental improvements unless KDE and GNOME agree" is hell. That is the W3C all over again
-
@mcc @gsuberland @glennseto no, it is not a thing, nor is it likely to become a thing. basically the position of the wayland committee such as it is, is that implementations should be free to do whatever they like, and that there's no binding power in wayland anyway. (which is why things like server-side-decorations aren't universally supported, as an example)
@dotstdy @gsuberland @glennseto maybe it shouldn't be the wayland committee's job tho, maybe it's freedesktop's.
-
undefined oblomov@sociale.network shared this topic on