3 ms·

The information you present is completely consistent with what smoldesu said.

by nsajko 4y ago

cowtools 4y ago
Maybe I should be more specific: >the onus is now on each individual desktop environment to provide it's own implementation of screensharing wlroots-based DEs can simply use wlroots' screen-sharing implementation for example. The wayland equivalent to the smaller DEs that relied on Xorg to reduce their complexity and maintenance is just smaller DEs using wlroots or similar. The larger DEs like Gnome and KDE will have no problem bearing the onus of implementing wayland themselves. I've had it screen sharing working perfectly on gnome for the better part of a year already.
- smoldesu 4y ago
  wlroots is really not that mature, and it's sort of a too-little-too-late situation. A lot of DEs are just never going to get around to switching to Wayland, but that doesn't mean they're going to stop development either. That's a pretty considerable fragmentation that people shouldn't take lightly. My example of a project doing this well is PipeWire. They looked at the Linux audio scene at the time (arguably worse than xorg on many accounts) and created a replacement that both supported old paradigms while simultaneously promoting lower-latency, higher-quality ways to connect. Wayland should have taken the same approach: it's never going to kill it's past, so it may as well adopt it. If I could use Wayland as a compositor while keeping x11 as my window server, I would. I wouldn't get the "full security" of Wayland, but I'd be onboard with their project if the maintainers weren't so allergic to user choice.
  - kaba0 4y ago
    That’s why Wayland has XWayland for seamless backwards compatibility with X applications? That’s pretty much the equivalent of a PA sink in PipeWire. I don’t see how your supposed compositor/window server hybrid would solve any of the problem of the past - what would even be the task of wayland there? It would be what kde plasma does with its compositor.

The information you present is completely consistent with what smoldesu said.

by nsajko 4y ago

The information you present is completely consistent with what smoldesu said.

Maybe I should be more specific: >the onus is now on each individual desktop environment to provide it's own implementation of screensharing wlroots-based DEs can simply use wlroots' screen-sharing implementation for example. The wayland equivalent to the smaller DEs that relied on Xorg to reduce their complexity and maintenance is just smaller DEs using wlroots or similar. The larger DEs like Gnome and KDE will have no problem bearing the onus of implementing wayland themselves. I've had it screen sharing working perfectly on gnome for the better part of a year already.

smoldesu 4y ago
wlroots is really not that mature, and it's sort of a too-little-too-late situation. A lot of DEs are just never going to get around to switching to Wayland, but that doesn't mean they're going to stop development either. That's a pretty considerable fragmentation that people shouldn't take lightly. My example of a project doing this well is PipeWire. They looked at the Linux audio scene at the time (arguably worse than xorg on many accounts) and created a replacement that both supported old paradigms while simultaneously promoting lower-latency, higher-quality ways to connect. Wayland should have taken the same approach: it's never going to kill it's past, so it may as well adopt it. If I could use Wayland as a compositor while keeping x11 as my window server, I would. I wouldn't get the "full security" of Wayland, but I'd be onboard with their project if the maintainers weren't so allergic to user choice.
- kaba0 4y ago
  That’s why Wayland has XWayland for seamless backwards compatibility with X applications? That’s pretty much the equivalent of a PA sink in PipeWire. I don’t see how your supposed compositor/window server hybrid would solve any of the problem of the past - what would even be the task of wayland there? It would be what kde plasma does with its compositor.