Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.



>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.


> 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.

That's not true. One way is to have secure protocols that can only be used by whitelisted programs in a secure context. sway has something like this (although by default I think it is pretty open), but there isn't any kind of standard mechanism for privileged protocols in wayland.

Also, I don't see why the screenshot API couldn't take a value for the type of screenshot to take. Like an enum with values for Region, Window, Screen, Full, and Any. To hint at what kind of screenshot to prefer.


Yes, one way to have a whitelist is to pop up a dialog asking to approve elevated permissions for a certain application. This is what mobile operating systems already do. The security implementation in sway is incomplete and has stalled, and is not going to work for all other types of desktop anyway. Pluggable security configuration should probably be added to wlroots at some point. This would allow any compositor to implement their preferred security policy and support whatever MACs or auditing they need.

The desktop portal does sort of support choosing a source, but only for screencast. See the enum here: https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: