31 ms·

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

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.
    - cycloptic 7y ago
      >I'm actually more concerned about the fact that wlroots has/had to duplicate work done by Gnome and KDE I don't think so, GNOME and KDE have never had the goal of making a reusable and generic compositor library like wlroots. You can try to build something with their internal compositor libraries (libmutter or kwayland) but they probably won't be as nice. >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. This is on purpose and it's not the problem. It's the only way to do it securely. The problem is that you are trying to perform a privileged operation, which is the only way that something like flameshot can even work. Allowing random unprivileged programs to scrape your screen without confirmation is how you get trojans and other spyware. It's not worth adding more APIs to the portal just to support this because it's intended to be a secure API that can be accessed from within sandboxed applications. Sure there are other tools on X but unfortunately none of those options are secure either.

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.
  - cycloptic 7y ago
    >I'm actually more concerned about the fact that wlroots has/had to duplicate work done by Gnome and KDE I don't think so, GNOME and KDE have never had the goal of making a reusable and generic compositor library like wlroots. You can try to build something with their internal compositor libraries (libmutter or kwayland) but they probably won't be as nice. >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. This is on purpose and it's not the problem. It's the only way to do it securely. The problem is that you are trying to perform a privileged operation, which is the only way that something like flameshot can even work. Allowing random unprivileged programs to scrape your screen without confirmation is how you get trojans and other spyware. It's not worth adding more APIs to the portal just to support this because it's intended to be a secure API that can be accessed from within sandboxed applications. Sure there are other tools on X but unfortunately none of those options are secure either.