5 ms·

>Does Wayland do anything better than Xorg? Nitpick: This is not a meaningful comparison. Wayland is a wire protocol. Xorg is a display server, and the wire pr

>Does Wayland do anything better than Xorg? Nitpick: This is not a meaningful comparison. Wayland is a wire protocol. Xorg is a display server, and the wire protocol it implements is called X11. There are several other display servers that implement the Wayland protocol. Some of these display servers do support those core features, and some of them don't (yet). It depends on which one you're using. The display server used by GNOME should support those features. >What is Wayland's reason for existing? From the website [0]: >Wayland is intended as a simpler replacement for X, easier to develop and maintain. [0] https://wayland.freedesktop.org/ https://wayland.freedesktop.org/

thayne 7y ago
> easier to develop and maintain wayland may be easier to maintain than X. But from what I've seen writing a compositor for wayland is more difficult than writing an X window manager, because things you got for free with X have to be implemented by the compositor in wayland. And many applications are more difficult to target wayland, because there aren't (at least yet) standard protocols for things like screenshots, screencapture, etc. So they have to either choose one desktop environment to target, or have implementations for all of them.
- cycloptic 7y ago
  Take a look at wlroots [0] for a library that massively simplifies the task of writing a wayland compositor. It also gives many of those lower level things "for free". For an even higher-level API built on top of wlroots, you can look at wltrunk [1]. There are standard APIs for screenshots and screencapture, implemented through the desktop portal and pipewire. Check the top-level post for more info about this -- it's part of why Wayland support for OBS has progressed. [0] https://github.com/swaywm/wlroots https://github.com/swaywm/wlroots [1] https://git.sr.ht/~bl4ckb0ne/wltrunk https://git.sr.ht/~bl4ckb0ne/wltrunk
  - eikenberry 7y ago
    > There are standard APIs for screenshots and screencapture What standard? Does anyone track how compliant the existing compositors are with the standard?
    - cycloptic 7y ago
      The standard is the desktop portal. The top-level post has a list of backend implementations. The readme in the main daemon has the same list: https://github.com/flatpak/xdg-desktop-portal#using-portals https://github.com/flatpak/xdg-desktop-portal#using-portals
  - thayne 7y ago
    I'm aware of wlroots. But KDE, GNOME, Enlightenment, etc. don't use it, so each of those have to implement things separately. Concerning the desktop portal API. It's basically just a wrapper around the native custom API's of the underlying compositor. And it is pretty limited in functionality. For example, the screenshot API just has a way to request a screenshot, it doesn't have a way to specify that you would like to select a window, region, or display/screen/monitor. In the case of wlr-portal, from what I could tell it just always gives you a screenshot of the full desktop.
    - cycloptic 7y ago
      >But KDE, GNOME, Enlightenment, etc. don't use it, so each of those have to implement things separately. I am not sure how this is relevant if you're trying to write your own compositor. If those projects want to create extra work for themselves, that's on them. >the screenshot API just has a way to request a screenshot, it doesn't have a way to specify that you would like to select a window, region, or display/screen/monitor. Yes, that's on purpose. What's supposed to happen is that the portal daemon (NOT the application) pops up a dialog asking the user to choose which one they want. Unfortunately the wlr portal is still not done yet and doesn't implement this.
      - thayne 7y ago
        > I am not sure how this is relevant if you're trying to write your own compositor. If those projects want to create extra work for themselves, that's on them. I'm actually more concerned about the fact that wlroots has/had to duplicate work done by Gnome and KDE (wlroots is more recent than much of gnome and kde's wayland support). > Yes, that's on purpose. What's supposed to happen is that the portal daemon (NOT the application) pops up a dialog asking the user to choose which one they want. Unfortunately the wlr portal is still not done yet and doesn't implement this. Yeah, the problem is that each compositor has to implement it's own screenshot dialog, and you _have_ to go through that dialog for that compositor. So on wlroots, currently, an app can only get a full screen screenshot. And a tool like flameshot becomes awkward if the compositor opens it's own dialog. In X, if you don't like Gnome's screenshto tool, you have a handful of other options. With wayland, tough luck, the most you can get is a better editor/annotation tool.

thayne 7y ago

> easier to develop and maintain wayland may be easier to maintain than X. But from what I've seen writing a compositor for wayland is more difficult than writing an X window manager, because things you got for free with X have to be implemented by the compositor in wayland. And many applications are more difficult to target wayland, because there aren't (at least yet) standard protocols for things like screenshots, screencapture, etc. So they have to either choose one desktop environment to target, or have implementations for all of them.

cycloptic 7y ago
Take a look at wlroots [0] for a library that massively simplifies the task of writing a wayland compositor. It also gives many of those lower level things "for free". For an even higher-level API built on top of wlroots, you can look at wltrunk [1]. There are standard APIs for screenshots and screencapture, implemented through the desktop portal and pipewire. Check the top-level post for more info about this -- it's part of why Wayland support for OBS has progressed. [0] https://github.com/swaywm/wlroots https://github.com/swaywm/wlroots [1] https://git.sr.ht/~bl4ckb0ne/wltrunk https://git.sr.ht/~bl4ckb0ne/wltrunk
- eikenberry 7y ago
  > There are standard APIs for screenshots and screencapture What standard? Does anyone track how compliant the existing compositors are with the standard?
  - cycloptic 7y ago
    The standard is the desktop portal. The top-level post has a list of backend implementations. The readme in the main daemon has the same list: https://github.com/flatpak/xdg-desktop-portal#using-portals https://github.com/flatpak/xdg-desktop-portal#using-portals
- thayne 7y ago
  I'm aware of wlroots. But KDE, GNOME, Enlightenment, etc. don't use it, so each of those have to implement things separately. Concerning the desktop portal API. It's basically just a wrapper around the native custom API's of the underlying compositor. And it is pretty limited in functionality. For example, the screenshot API just has a way to request a screenshot, it doesn't have a way to specify that you would like to select a window, region, or display/screen/monitor. In the case of wlr-portal, from what I could tell it just always gives you a screenshot of the full desktop.
  - cycloptic 7y ago
    >But KDE, GNOME, Enlightenment, etc. don't use it, so each of those have to implement things separately. I am not sure how this is relevant if you're trying to write your own compositor. If those projects want to create extra work for themselves, that's on them. >the screenshot API just has a way to request a screenshot, it doesn't have a way to specify that you would like to select a window, region, or display/screen/monitor. Yes, that's on purpose. What's supposed to happen is that the portal daemon (NOT the application) pops up a dialog asking the user to choose which one they want. Unfortunately the wlr portal is still not done yet and doesn't implement this.
    - thayne 7y ago
      > I am not sure how this is relevant if you're trying to write your own compositor. If those projects want to create extra work for themselves, that's on them. I'm actually more concerned about the fact that wlroots has/had to duplicate work done by Gnome and KDE (wlroots is more recent than much of gnome and kde's wayland support). > Yes, that's on purpose. What's supposed to happen is that the portal daemon (NOT the application) pops up a dialog asking the user to choose which one they want. Unfortunately the wlr portal is still not done yet and doesn't implement this. Yeah, the problem is that each compositor has to implement it's own screenshot dialog, and you _have_ to go through that dialog for that compositor. So on wlroots, currently, an app can only get a full screen screenshot. And a tool like flameshot becomes awkward if the compositor opens it's own dialog. In X, if you don't like Gnome's screenshto tool, you have a handful of other options. With wayland, tough luck, the most you can get is a better editor/annotation tool.