5 ms·

Wayland makes the wrong abstractions and does not offer vital functionality usually needed on a Desktop system. As a result every Toolkit/Compositor has to impl

by sprash 5y ago

Wayland makes the wrong abstractions and does not offer vital functionality usually needed on a Desktop system. As a result every Toolkit/Compositor has to implement that additional functionality itself and most of the time it is incompatible to the competitor for no apparent reason. As an exercise I recommend to write a native universal applicable Wayland application that takes screenshots.

xxpor 5y ago
Why are objections like this not solved with things like wlroots?
- folmar 5y ago
  wlroots are not used by the two main desktops, so to get basic features like screenshots you need to support 3 different ways already.
  - kaba0 5y ago
    Wlroots is an implementation of wayland protocols — if gnome and plasma implement the same protocol according to specification, you only have to write code to that protocol, once.
    - yjftsjthsd-h 5y ago
      Right, but that protocol isn't in wayland proper and isn't standardized, so GNOME and KDE and wlroots all have different takes.
      - dralley 5y ago
        Right, but the point is that the protocol doesn't need to be in Wayland proper, so long as it's standardized somewhere. And it is. https://flatpak.github.io/xdg-desktop-portal/portal-docs.html https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
  - boudin 5y ago
    You're mistaken, that's not the role of wayland. If you're looking into an universal way to takr screenshots, screesncast, etc..., you're looking for xdg-desktop-portal. There'is implementations for wlroots, gnome, qt, and others.
    - wing-_-nuts 5y ago
      >You're mistaken, that's not the role of wayland. A side note, but I really hate this ideology of 'x does one thing' outside of command line tools. This is a display server we're talking about. It should be able to enable normal desktop usage. Maybe not everything but core features like brightness control, screen sharing, screenshots, etc. Otherwise every wm that comes along is going to have to reinvent the wheel. There are tons of really great window managers out there, where the authors have looked at all the work it will take to get running on wayland, and have simply thrown their hands up in frustration. It seems to me the only people that really benefit from the switch to wayland are the wayland devs themselves.
      - xxpor 5y ago
        All I know is as a user, Wayland lets me have reasonable HiDPI support (where 2 monitors can have different scale levels). And I can't on X.
      - dralley 5y ago
        Wayland is not a display server, it's a display protocol. There is no "display server" in the architecture.
        wing-_-nuts 5y ago
        I, as a user, do not give a rats ass if it's a protocol or server. I don't want to lose functionality just because some group of devs prefers to do a rewrite of something. I've used gnome wayland, and sway. It's pretty damning that so few other window managers support wayland due to the sheer difficulty of the task.
craftinator 5y ago
> As an exercise I recommend to write a native universal applicable Wayland application that takes screenshots. As someone who tried to do this... Ouch. Things like this are why X will still be around in 15 years.
- markstos 5y ago
  Wayland as a `screencopy` protocol and the `wlroots` library packages it for other compositors to use. Is the issue that compositors don't implement the `screencopy` protocol themselves or use the implementation provided by wlroots? Ref: https://wayland.app/protocols/wlr-screencopy-unstable-v1 https://wayland.app/protocols/wlr-screencopy-unstable-v1
  - craftinator 5y ago
    > Is the issue that compositors don't implement the `screencopy` protocol themselves or use the implementation provided by wlroots? In general, when your diagnosis to a problem is "the people using my product are all just too lazy to use it right", the problem is almost always that your product is the problem.
  - folmar 5y ago
    Not really - to quote the page you reference: > "Warning! The protocol described in this file is experimental and backward incompatible changes may be made. and the compositors were there way before 2018, so it's a bit too much to expect them to jump on the protocol.
tosihakkeri 5y ago
Based on what you just wrote, it sounds to me that you might be assuming the wrong abstraction yourself.
kaba0 5y ago
Wayland as a display protocol (correctly) started out with a tiny core, which can display the content of a window, and manage available extensions by version. This has grown out to be a really great abstraction, where later multiple implementations can decide on new protocols/extensions to support. And they have already done plenty of such extensions, and they are compatible with each other. Remember, these are protocols. There is no need to implement them yourself, they can be made into a library, like wlroots, and you can build your compositor on that base, without any repetition. Also, multiple implementations only mean that there won’t be implementation-specific quirks. As for screenshots specifically, while the base use case is trivial enough, recording screens are most definitely not (it needs proper synchronization). Pipewire is the project that can solve the issue perfectly, and it is indeed working correctly for like a year already, with screen share even in proprietary apps like teams.
- enriquto 5y ago
  > As for screenshots specifically, while the base use case is trivial enough, recording screens are most definitely not (it needs proper synchronization). Pipewire is the project that can solve the issue If I understand the OP correctly, this sort of philosophy is deeply troubling to some people. For simplicity-oriented folks, trivial things should be trivial, as a matter of principle. If some trivial thing becomes slightly less convenient so that complex stuff may be possible, this is an unacceptable compromise; or at least a very worrying one. When taking static screenshots requires an entire "project" that is "just ready this year" , the threshold of unacceptability is long surpassed. I get that wayland folks do not share this worldview and they want to do the right thing, even at the expense of sacrifying things that were previously easy. But, to other people, this rubs them in a very wrong way.
  - kaba0 5y ago
    wlroots does implement a very simple screenshot protocol, the reason I didn’t mention it was that it is not cross-wayland-implementation. But there is nothing inherent in wayland that would prevent this functionality — they just try to find a good abstraction they all can stick to (as these APIs will likely be used for a long time), and gnome and plasma people have a different view on that. (Also, if we have a complex program that does all the things we need and a simple program+the complex one, we will have more complexity in the latter case so the previous one may be preferred)
bitwize 5y ago
> As a result every Toolkit/Compositor has to implement that additional functionality itself and most of the time it is incompatible to the competitor for no apparent reason. Or, compositors can use these wonderful things we have called dynamic libraries, and simply link against implementations of that desktop functionality, such as wlroots -- which implementations, by the way, will be far less crufty and ad hoc than the equivalent X11 solution! Much of the reason why X is the way it is is because back in the day, Unix lacked dynamic libraries in general, so in order to share an implementation of, say, graphics primitives, the best way was to write a server that implemented them and have clients communicate with that server. Now that we have dynamic libraries, we can share a single implementation of graphics rendering across multiple programs, and still have all the speed advantages of doing all the rendering client side!
bitwize 5y ago
I'm sure the architects of Xorg have a much better idea of which abstraction to use and why it's superior to Wayland. Oh wait, the architects of Xorg designed Wayland! X11 is a dead end. Its authors have deprecated it and offered an upgrade path: Wayland. Time to make like Elsa and let it go.
- a1369209993 5y ago
  > the architects of Xorg Xorg was designed decades ago. The architects of Xorg are dead, retired, or overwritten with their stupider future selves; you're talking about maintainers.
  - marcodiego 5y ago
    Xorg was not designed. It organically evolved.
    - a1369209993 5y ago
      ... Okay, that's fair, but not really my point.

by sprash 5y ago

xxpor 5y ago

Why are objections like this not solved with things like wlroots?

folmar 5y ago
wlroots are not used by the two main desktops, so to get basic features like screenshots you need to support 3 different ways already.
- kaba0 5y ago
  Wlroots is an implementation of wayland protocols — if gnome and plasma implement the same protocol according to specification, you only have to write code to that protocol, once.
  - yjftsjthsd-h 5y ago
    Right, but that protocol isn't in wayland proper and isn't standardized, so GNOME and KDE and wlroots all have different takes.
    - dralley 5y ago
      Right, but the point is that the protocol doesn't need to be in Wayland proper, so long as it's standardized somewhere. And it is. https://flatpak.github.io/xdg-desktop-portal/portal-docs.html https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
- boudin 5y ago
  You're mistaken, that's not the role of wayland. If you're looking into an universal way to takr screenshots, screesncast, etc..., you're looking for xdg-desktop-portal. There'is implementations for wlroots, gnome, qt, and others.
  - wing-_-nuts 5y ago
    >You're mistaken, that's not the role of wayland. A side note, but I really hate this ideology of 'x does one thing' outside of command line tools. This is a display server we're talking about. It should be able to enable normal desktop usage. Maybe not everything but core features like brightness control, screen sharing, screenshots, etc. Otherwise every wm that comes along is going to have to reinvent the wheel. There are tons of really great window managers out there, where the authors have looked at all the work it will take to get running on wayland, and have simply thrown their hands up in frustration. It seems to me the only people that really benefit from the switch to wayland are the wayland devs themselves.
    - xxpor 5y ago
      All I know is as a user, Wayland lets me have reasonable HiDPI support (where 2 monitors can have different scale levels). And I can't on X.
    - dralley 5y ago
      Wayland is not a display server, it's a display protocol. There is no "display server" in the architecture.
      - wing-_-nuts 5y ago
        I, as a user, do not give a rats ass if it's a protocol or server. I don't want to lose functionality just because some group of devs prefers to do a rewrite of something. I've used gnome wayland, and sway. It's pretty damning that so few other window managers support wayland due to the sheer difficulty of the task.

craftinator 5y ago

> As an exercise I recommend to write a native universal applicable Wayland application that takes screenshots. As someone who tried to do this... Ouch. Things like this are why X will still be around in 15 years.

markstos 5y ago
Wayland as a `screencopy` protocol and the `wlroots` library packages it for other compositors to use. Is the issue that compositors don't implement the `screencopy` protocol themselves or use the implementation provided by wlroots? Ref: https://wayland.app/protocols/wlr-screencopy-unstable-v1 https://wayland.app/protocols/wlr-screencopy-unstable-v1
- craftinator 5y ago
  > Is the issue that compositors don't implement the `screencopy` protocol themselves or use the implementation provided by wlroots? In general, when your diagnosis to a problem is "the people using my product are all just too lazy to use it right", the problem is almost always that your product is the problem.
- folmar 5y ago
  Not really - to quote the page you reference: > "Warning! The protocol described in this file is experimental and backward incompatible changes may be made. and the compositors were there way before 2018, so it's a bit too much to expect them to jump on the protocol.

tosihakkeri 5y ago

Based on what you just wrote, it sounds to me that you might be assuming the wrong abstraction yourself.

kaba0 5y ago

Wayland as a display protocol (correctly) started out with a tiny core, which can display the content of a window, and manage available extensions by version. This has grown out to be a really great abstraction, where later multiple implementations can decide on new protocols/extensions to support. And they have already done plenty of such extensions, and they are compatible with each other. Remember, these are protocols. There is no need to implement them yourself, they can be made into a library, like wlroots, and you can build your compositor on that base, without any repetition. Also, multiple implementations only mean that there won’t be implementation-specific quirks. As for screenshots specifically, while the base use case is trivial enough, recording screens are most definitely not (it needs proper synchronization). Pipewire is the project that can solve the issue perfectly, and it is indeed working correctly for like a year already, with screen share even in proprietary apps like teams.

enriquto 5y ago
> As for screenshots specifically, while the base use case is trivial enough, recording screens are most definitely not (it needs proper synchronization). Pipewire is the project that can solve the issue If I understand the OP correctly, this sort of philosophy is deeply troubling to some people. For simplicity-oriented folks, trivial things should be trivial, as a matter of principle. If some trivial thing becomes slightly less convenient so that complex stuff may be possible, this is an unacceptable compromise; or at least a very worrying one. When taking static screenshots requires an entire "project" that is "just ready this year" , the threshold of unacceptability is long surpassed. I get that wayland folks do not share this worldview and they want to do the right thing, even at the expense of sacrifying things that were previously easy. But, to other people, this rubs them in a very wrong way.
- kaba0 5y ago
  wlroots does implement a very simple screenshot protocol, the reason I didn’t mention it was that it is not cross-wayland-implementation. But there is nothing inherent in wayland that would prevent this functionality — they just try to find a good abstraction they all can stick to (as these APIs will likely be used for a long time), and gnome and plasma people have a different view on that. (Also, if we have a complex program that does all the things we need and a simple program+the complex one, we will have more complexity in the latter case so the previous one may be preferred)

bitwize 5y ago

> As a result every Toolkit/Compositor has to implement that additional functionality itself and most of the time it is incompatible to the competitor for no apparent reason. Or, compositors can use these wonderful things we have called dynamic libraries, and simply link against implementations of that desktop functionality, such as wlroots -- which implementations, by the way, will be far less crufty and ad hoc than the equivalent X11 solution! Much of the reason why X is the way it is is because back in the day, Unix lacked dynamic libraries in general, so in order to share an implementation of, say, graphics primitives, the best way was to write a server that implemented them and have clients communicate with that server. Now that we have dynamic libraries, we can share a single implementation of graphics rendering across multiple programs, and still have all the speed advantages of doing all the rendering client side!

bitwize 5y ago

I'm sure the architects of Xorg have a much better idea of which abstraction to use and why it's superior to Wayland. Oh wait, the architects of Xorg designed Wayland! X11 is a dead end. Its authors have deprecated it and offered an upgrade path: Wayland. Time to make like Elsa and let it go.

a1369209993 5y ago
> the architects of Xorg Xorg was designed decades ago. The architects of Xorg are dead, retired, or overwritten with their stupider future selves; you're talking about maintainers.
- marcodiego 5y ago
  Xorg was not designed. It organically evolved.
  - a1369209993 5y ago
    ... Okay, that's fair, but not really my point.