4 ms·

What you are saying is not correct; the xdg-desktop-portal API is not tied to flatpak, it has support for individual windows, it's generic and can be re-used by

What you are saying is not correct; the xdg-desktop-portal API is not tied to flatpak, it has support for individual windows, it's generic and can be re-used by any sandbox, and it can also be used outside a sandbox. (Snap I believe is using it and it should be not too hard to get it working in other tools like firejail either) Using it has the benefit that your application will also work inside a sandbox and doesn't need to have additional code paths for X11 and wayland and for the sandboxed case. See here for the description of libei, it's not ready yet but is being worked on, and should have a similar design that allows it to work correctly in a sandbox: https://who-t.blogspot.com/2020/08/libei-library-to-support-emulated-input.html https://who-t.blogspot.com/2020/08/libei-library-to-support-... In almost all cases, Wine should viewporter or use fullscreen-shell to set custom resolutions for specific programs, the only reason you would need to allow wine to have access to an xrandr-like API is if you wanted to run your monitor configuration tool from windows, which I strongly doubt people are wanting to do that. If you are using GNOME/KDE, the GNOME/KDE control panel is always going to be the most reliable way to configure that. Yes you would need to track upstream and keep up with their unstable APIs in order to write such a library that but that's no different than if you asked upstream to do it, they would just be doing that in their tree. (In some cases this is what they do anyway with the xdg-desktop-portal) In any case you would need to be more specific about what it is you want because just saying "implement everything from X11 exactly the way X11 does it" is not useful, that's never going to happen, so let's focus on what actually it is that is needed.

thayne 6y ago
> it has support for individual windows uh, where? From the documentation at https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm... the supported options are whether it should be interactive, and whether the dialog should be modal. There is no option to indicate what kind of screenshot you want (window, monitor, full screen, rectangle). You can hope that the compositor's implementation lets the user select what they want, but the compositor is free to take the screenshot however it wants, the wlroots xdg-desktop implementation for example, currently just always takes a screenshot of the whole screen. The API is oriented more toward's Gnomes approach of considering the screenshot dialog to be the responsibility of the compositor, and doesn't work well for sway's approach of considering the screenshot dialog to be the application's responsibility. The Screencast protocol at least allows you to specify if you want to capture a monitor or a window, although not all compositors support both (for example xdg-desktop-wlroots only supports the monitor type). Now hopefully in the not-too distant future most compositors will support it, atm, at least in my compositor of choice, it doesn't work yet. And in both cases the the xdg-desktop-portal API doesn't really work well with apps like Flameshot or Peek, where you determine what to capture by resizing the window of the app.

thayne 6y ago

> it has support for individual windows uh, where? From the documentation at https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm... the supported options are whether it should be interactive, and whether the dialog should be modal. There is no option to indicate what kind of screenshot you want (window, monitor, full screen, rectangle). You can hope that the compositor's implementation lets the user select what they want, but the compositor is free to take the screenshot however it wants, the wlroots xdg-desktop implementation for example, currently just always takes a screenshot of the whole screen. The API is oriented more toward's Gnomes approach of considering the screenshot dialog to be the responsibility of the compositor, and doesn't work well for sway's approach of considering the screenshot dialog to be the application's responsibility. The Screencast protocol at least allows you to specify if you want to capture a monitor or a window, although not all compositors support both (for example xdg-desktop-wlroots only supports the monitor type). Now hopefully in the not-too distant future most compositors will support it, atm, at least in my compositor of choice, it doesn't work yet. And in both cases the the xdg-desktop-portal API doesn't really work well with apps like Flameshot or Peek, where you determine what to capture by resizing the window of the app.