8 ms·

Oh the downplaying > In certain cases, 3rd-party applications doing specialized tasks like taking screenshots In what way is this copy&paste-like staple of ge

by eviks 11mo ago

Oh the downplaying > In certain cases, 3rd-party applications doing specialized tasks like taking screenshots In what way is this copy&paste-like staple of general computing some "specialized" task? Will the new opportunities include reaching "specialized" feature parity? > In the longer term, this change opens up new opportunities for features, optimizations, and speed of development.

eddyb 11mo ago
If you're not familiar, the way X11 works is comparable to "multiplayer notepad" for your pixels ("multiplayer MSPaint"?). All your monitors are combined into a large canvas where every pixel can be written and read by any X11 client. Screenshots (and screen sharing) could be silently performed with zero user feedback (or any good way to even detect when apps might be doing this maliciously, AFAIK). This is one of the big "security implications" that motivated Wayland (and somewhat similarly, the Flatpak sandbox and the XDG Portal infrastructure that has by now outgrown it). The infrastructure is already there, for 3rd party apps to request these abilities (with the user getting the choice of following through, or denying the request), e.g.: - https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Screenshot.html https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr... - https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr... Keep in mind that any action which doesn't require interactivity every time (e.g. restarting the screensharing of a previously-chosen window/display) could have "user gave permission" be remembered, but that seamless case still only applies to that combination (so that client can't peek at anything else than what it was offered). Anyway, what the blog post is talking about is really just 3rd party apps that haven't been updated (and e.g. might already not function properly inside Flatpak). > feature parity If we are being honest, screenshots/screensharing was never a "feature" of X11, it was a big security hole abused as a feature.
- eviks 11mo ago
  > The infrastructure is already there, for 3rd party apps to request these abilities (with the user getting the choice of following through, or denying the request), e.g.: Why can't the infrastructure include the user simply allowing the app to continue to have access without a specialized infrastructure of app request (that requires updating the app)? > really just 3rd party apps that haven't been updated What's with the downplaying "just" again? Have all the best or most popular apps been updated to ensure no disruption? > screenshots/screensharing was never a "feature" of X11, it was a big security hole abused as a feature. So what was the screenshot feature of X11? Also classifying use as abuse isn't that honest, only the lack of security is
  - eddyb 11mo ago
    > So what was the screenshot feature of X11? In case I wasn't clear enough, there was never a screenshot feature. Any X11 client could read any pixel written by any other X11 client. > Have all the best or most popular apps been updated to ensure no disruption? I am not familiar with DE-agnostic "screenshot apps" for Linux, they always seemed more common on other OSes, and I've always used the DE-specific apps (which were the first to support such mechanisms, some of them even using more direct DE-specific private protocols instead of XDG Portals). But I spent a few seconds googling for general screenshot apps, found Flameshot (which makes sense as a cross-platform app), and it turns out that support for the XDG Portal approach was added to it almost 5 years ago: https://github.com/flameshot-org/flameshot/pull/1272 https://github.com/flameshot-org/flameshot/pull/1272 And if you peek around the diff, you can tell that KDE/GNOME-specific support, on Wayland - using DBus but not the XDG Portals protocol - already existed, in early 2021, in fact... https://github.com/flameshot-org/flameshot/commit/a5df852268ed935b3ca6f265308d3c3d082218bd https://github.com/flameshot-org/flameshot/commit/a5df852268... That's the commit that added KDE/GNOME-specific Wayland screenshot support. 8 years ago, in a 3rd-party app! > Why can't the infrastructure include the user simply allowing the app to continue to have access without a specialized infrastructure of app request (that requires updating the app)? I'd forgotten that this happened, but for screensharing from a X11 client, someone already went through the trouble of emulating it (on top of the XDG Portals + PipeWire infrastructure): https://blog.davidedmundson.co.uk/blog/xwaylandvideobridge/ https://blog.davidedmundson.co.uk/blog/xwaylandvideobridge/ It's only a temporary hack, and it only matters for X11 clients running under XWayland - if an app can run as a native Wayland client, it should have XDG Portals-based implementations of relevant features. > What's with the downplaying "just" again? Have all the best or most popular apps been updated to ensure no disruption? Am I downplaying, or are you describing a vague category of "the best or more popular apps" without giving examples? I feel like it's too easy for some of this stuff to end up in FUD-like arguments without considering the objective reality (of how far we've come in the past few years etc.). Anyway, my subjective take is that X11 took a decade or two too long to die, and most (if not all) gripes users might have with Wayland can be traced back to X11 outliving its UNIX Workstation origins and having never been designed as a Personal Computing graphical environment.
- Kuraj 11mo ago
  > All your monitors are combined into a large canvas where every pixel can be written and read by any X11 client. Heh. I learned this hard way when trying to set up multiple monitors with different refresh rates
diath 11mo ago
It's actually wild that they're trying to sell lack of basic desktop features as "security features". Try explaining to an average person that when they are playing a game and want to capture a cool moment to share on Discord with their friends that by design the window server they are using will not let them do that and it's "for their own good". Like God forbid I want my computer to be actually usable. We had the same situation in the past when Wayland lacked a way to lock in the cursor within a window and it took them like 8 years to develop a "protocol" or whatever they call it. Imagine that for each basic desktop usability/UX feature, we will have to wait another decade. At that rate Linux will never have widespread adoption on desktop. Wayland sometimes feels like an active effort to sabotage Linux on desktop.
- w4rh4wk5 11mo ago
  I'd say it's completely irresponsible to not have such features, claiming it's about security, rather than implementing it behind a permission system that puts the end-user in charge.
  - StopDisinfo910 11mo ago
    It is implemented behind a permission system. KScreenshot works perfectly fine and so will most of the applications using PipeWire I guess, same that screen captures. KDE is merely saying that some applications will have to be updated to use it so all of the current screenshot applications won't work out of the box. No idea of why some commenters here are implying screenshots don't work in Wayland. It seems their knowledge is somehow stuck at the first proof of concept ten years ago.
    - w4rh4wk5 11mo ago
      I was talking in general. It's less about screenshots and screen recording, but more about drag-and-drop and global hotkeys like push-to-talk in Discord.
      - StopDisinfo910 11mo ago
veeti 11mo ago
[flagged]
kokada 11mo ago
I don't think they're downplaying. Most users will be perfectly happy with the included KDE application for screenshots/screen capture (it is really fully featured, much better than the default options for Windows or macOS). And they're not saying that no third party applications will work either, it is just that old screenshot applications that were created for X11 will need to be ported. In the end that is not really much different from macOS dropping Rosetta in the next release of macOS (yes, I know there is a difference of effort). Old applications will stop working, applications that still get support will eventually support it (if they don't support Wayland already).

by eviks 11mo ago

eddyb 11mo ago

If you're not familiar, the way X11 works is comparable to "multiplayer notepad" for your pixels ("multiplayer MSPaint"?). All your monitors are combined into a large canvas where every pixel can be written and read by any X11 client. Screenshots (and screen sharing) could be silently performed with zero user feedback (or any good way to even detect when apps might be doing this maliciously, AFAIK). This is one of the big "security implications" that motivated Wayland (and somewhat similarly, the Flatpak sandbox and the XDG Portal infrastructure that has by now outgrown it). The infrastructure is already there, for 3rd party apps to request these abilities (with the user getting the choice of following through, or denying the request), e.g.: - https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Screenshot.html https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr... - https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr... Keep in mind that any action which doesn't require interactivity every time (e.g. restarting the screensharing of a previously-chosen window/display) could have "user gave permission" be remembered, but that seamless case still only applies to that combination (so that client can't peek at anything else than what it was offered). Anyway, what the blog post is talking about is really just 3rd party apps that haven't been updated (and e.g. might already not function properly inside Flatpak). > feature parity If we are being honest, screenshots/screensharing was never a "feature" of X11, it was a big security hole abused as a feature.

eviks 11mo ago
> The infrastructure is already there, for 3rd party apps to request these abilities (with the user getting the choice of following through, or denying the request), e.g.: Why can't the infrastructure include the user simply allowing the app to continue to have access without a specialized infrastructure of app request (that requires updating the app)? > really just 3rd party apps that haven't been updated What's with the downplaying "just" again? Have all the best or most popular apps been updated to ensure no disruption? > screenshots/screensharing was never a "feature" of X11, it was a big security hole abused as a feature. So what was the screenshot feature of X11? Also classifying use as abuse isn't that honest, only the lack of security is
- eddyb 11mo ago
  > So what was the screenshot feature of X11? In case I wasn't clear enough, there was never a screenshot feature. Any X11 client could read any pixel written by any other X11 client. > Have all the best or most popular apps been updated to ensure no disruption? I am not familiar with DE-agnostic "screenshot apps" for Linux, they always seemed more common on other OSes, and I've always used the DE-specific apps (which were the first to support such mechanisms, some of them even using more direct DE-specific private protocols instead of XDG Portals). But I spent a few seconds googling for general screenshot apps, found Flameshot (which makes sense as a cross-platform app), and it turns out that support for the XDG Portal approach was added to it almost 5 years ago: https://github.com/flameshot-org/flameshot/pull/1272 https://github.com/flameshot-org/flameshot/pull/1272 And if you peek around the diff, you can tell that KDE/GNOME-specific support, on Wayland - using DBus but not the XDG Portals protocol - already existed, in early 2021, in fact... https://github.com/flameshot-org/flameshot/commit/a5df852268ed935b3ca6f265308d3c3d082218bd https://github.com/flameshot-org/flameshot/commit/a5df852268... That's the commit that added KDE/GNOME-specific Wayland screenshot support. 8 years ago, in a 3rd-party app! > Why can't the infrastructure include the user simply allowing the app to continue to have access without a specialized infrastructure of app request (that requires updating the app)? I'd forgotten that this happened, but for screensharing from a X11 client, someone already went through the trouble of emulating it (on top of the XDG Portals + PipeWire infrastructure): https://blog.davidedmundson.co.uk/blog/xwaylandvideobridge/ https://blog.davidedmundson.co.uk/blog/xwaylandvideobridge/ It's only a temporary hack, and it only matters for X11 clients running under XWayland - if an app can run as a native Wayland client, it should have XDG Portals-based implementations of relevant features. > What's with the downplaying "just" again? Have all the best or most popular apps been updated to ensure no disruption? Am I downplaying, or are you describing a vague category of "the best or more popular apps" without giving examples? I feel like it's too easy for some of this stuff to end up in FUD-like arguments without considering the objective reality (of how far we've come in the past few years etc.). Anyway, my subjective take is that X11 took a decade or two too long to die, and most (if not all) gripes users might have with Wayland can be traced back to X11 outliving its UNIX Workstation origins and having never been designed as a Personal Computing graphical environment.
Kuraj 11mo ago
> All your monitors are combined into a large canvas where every pixel can be written and read by any X11 client. Heh. I learned this hard way when trying to set up multiple monitors with different refresh rates

diath 11mo ago

It's actually wild that they're trying to sell lack of basic desktop features as "security features". Try explaining to an average person that when they are playing a game and want to capture a cool moment to share on Discord with their friends that by design the window server they are using will not let them do that and it's "for their own good". Like God forbid I want my computer to be actually usable. We had the same situation in the past when Wayland lacked a way to lock in the cursor within a window and it took them like 8 years to develop a "protocol" or whatever they call it. Imagine that for each basic desktop usability/UX feature, we will have to wait another decade. At that rate Linux will never have widespread adoption on desktop. Wayland sometimes feels like an active effort to sabotage Linux on desktop.

w4rh4wk5 11mo ago
I'd say it's completely irresponsible to not have such features, claiming it's about security, rather than implementing it behind a permission system that puts the end-user in charge.
- StopDisinfo910 11mo ago
  It is implemented behind a permission system. KScreenshot works perfectly fine and so will most of the applications using PipeWire I guess, same that screen captures. KDE is merely saying that some applications will have to be updated to use it so all of the current screenshot applications won't work out of the box. No idea of why some commenters here are implying screenshots don't work in Wayland. It seems their knowledge is somehow stuck at the first proof of concept ten years ago.
  - w4rh4wk5 11mo ago
    I was talking in general. It's less about screenshots and screen recording, but more about drag-and-drop and global hotkeys like push-to-talk in Discord.
    - StopDisinfo910 11mo ago

veeti 11mo ago

[flagged]

kokada 11mo ago

I don't think they're downplaying. Most users will be perfectly happy with the included KDE application for screenshots/screen capture (it is really fully featured, much better than the default options for Windows or macOS). And they're not saying that no third party applications will work either, it is just that old screenshot applications that were created for X11 will need to be ported. In the end that is not really much different from macOS dropping Rosetta in the next release of macOS (yes, I know there is a difference of effort). Old applications will stop working, applications that still get support will eventually support it (if they don't support Wayland already).