8 ms·

People are responding to this comment by saying "Screenshots work," and yes, they do, somewhat. However, you're limited to using the screenshot tool built in to

People are responding to this comment by saying "Screenshots work," and yes, they do, somewhat. However, you're limited to using the screenshot tool built in to your Wayland compositor, rather than any third-party tool. For example, my favorite screenshot tool supports automatic timed screenshots, of particular windows or the whole screen or of a specified region, of one desktop or several, and various customizations. Those features aren't supported by my compositor, and I don't have a choice. So Wayland limits my options. Another area missing functionality is remote desktop. Yes, most Wayland compositors support VNC or similar remote desktop, but without the functionality of previous solutions. For example, I used x11vnc extensively: with it, I can share just one window or a whole screen, with various security options, and I can do so programmatically from the command line. Because VNC is now a feature built into the compositor, I no longer have a choice which remote desktop tool to use, and adding features is not a priority for maintainers of the compositors. So, while, yes technically, you're right that some analogues of screenshots and remote desktop exist on Wayland, they do so without any of the modularity and flexibility that Linux is (allegedly) proud of.

sho_hn 4y ago
This is a valid and level-headed analysis. The good news is that this is not unfixable; there is a venue and a governance organization to standardize the protocols and compositor interoperability that is needed. And there has been notable progress. Specifically when it comes to screen share / remote desktop, standardization of the API to invoke sharing is happening by way of the XDG portal API efforts. There is active collaboration there e.g. between the browser vendors and the compositor vendors to agree on an interface. Here is a recent progress report: https://jgrulich.cz/2022/11/21/webrtc-chromium-year-end-report/ https://jgrulich.cz/2022/11/21/webrtc-chromium-year-end-repo...
- Aardwolf 4y ago
  > there is a venue and a governance organization to standardize the protocols and compositor interoperability that is needed I'm not sure if that applies specifically to this case, but I'm not a fan of some standardization of protocols that is going on in Linux desktops, because: - desktop managers can't properly keep state of your windows anymore on shutting off/on monitors. Claimed reason why this is not fixable: "the standard requires it" - I dislike MM/DD/YYYY date formats. File managers used to have their own setting to choose your date format. Now they use some common standard so you have to set your Linux locale to something non-US. This then breaks other things. It's much nicer to be able to configure things per-application. - Kolourpaint used to have a good color picker that showed you the numerical and hex values of colors. Now it has a horrible one that is only some palette where you can edit individual entries. You can't easily see the RGB values of a pixel in an image you open in Kolourpaint anymore. All due to "standardization", using a shared color picker component - Focus stealing prevention no longer properly works, all due to adhering to some desktop standards - Desktops like KDE and Cinnamon using horrible non-human editable json/xml/base64-encoded UTF-16 formats for their config - Some Qt or GDK applications not having icons sometimes, due to them expecting some common icons available somewhere. This issue used to not exist, applications came with their own icons that just worked I much preferred how unix and the desktop used to be, where you could manually edit textual config files to do whatever you want, and had the power and flexibility to change almost anything in intuitive ways
  - ChuckNorris89 4y ago
    >I'm not a fan of some standardization of protocols that is going on in Linux desktops Standardization and Linux desktops are sometimes mutual conflicting terms. There's doesn't seem to be much standardization on this front but tribes of people saying "new things should be this way" and other tribes saying "n'ah mate, that sucks, we'll keep using our own better way". Linux desktops don't have the Apple/Microsoft dictatorship powers to actually enforce any kind of GUI standards so we get this constant hassle and even more fragmentation.
    - sho_hn 4y ago
      > Linux desktops don't have the Apple/Microsoft dictatorship powers to actually enforce any kind of GUI standards so we get this constant hassle and even more fragmentation. Do Apple and Microsoft actually have them? The GUI experience on Windows is relatively disjointed, and Apple famously did it to itself with e.g. randomly chosen brushed metal windows and other app-specific background textures. It appears far more common now for popular applications to ship their own look & feel and even theming. Let's say Discord, or even first-party, VS Code. I'd say the accomplishments of standardization and interoperability on the Linux desktop are actually more substantial than on either Windows or MacOS. Consider that e.g. KDE and Gnome applications share a lot of important standards and are generally able to run in either vendor's shells. Windows and MacOS each effectively only have a single GUI frontend, so this kind of collaboration between vendors doesn't need to be accomplished, and it's not happening between the app makers, either.
      - unconed 4y ago
        >brushed metal windows and other app-specific background textures. You're about a decade late with this complaint... and wrong. The brushed metal look was for application windows that resembled "appliances", which would remain open as you loaded/saved different projects. This was to distinguish them from the normal white document windows, which are tied 1-to-1 to a file. I'm not saying they always followed this rule exactly... but there definitely was a rule. And the Apple of the era would publish detailed Human Interface Guidelines detailing all the thinking and intended practices. Third party mac software of that era was famously extremely consistent too, because of this shared base. I only have one request from Linux desktops: mac style shortcuts with meta instead of ctrl. I also know it will never happen because everyone took their cues from messy Microsoft instead of the superior Apple practices.
WhyNotHugo 4y ago
> For example, my favorite screenshot tool supports automatic timed screenshots, of particular windows or the whole screen or of a specified region, of one desktop or several, and various customizations. Those features aren't supported by my compositor, and I don't have a choice. So Wayland limits my options. Xorg doesn't support his either. Your screenshotting tool runs the timer and takes the screenshot when the timer expires. You complaint is like saying "the Linux kernel won't render markdown for me". No, it won't, you're looking at the wrong part of the stack. For example, you can simply run `sleep 3 && shotman --output` to take a screenshot of an output in three seconds. There might be other GUI tools with a pretty timer setting. I've no idea if such a thing exists or not, but it's perfectly possible to write without any changes to the compositor (e.g.: the compositor provides the necessary APIs for thi).
- hackyhacky 4y ago
  You're missing my point. The Wayland architecture does not give me a choice in my screenshot, video recording, and remote desktop tool: you have to use the functionality built in to the compositor. Many compositors (notably GNOME and KDE) don't support the Wayland semi-standard interface for these things. You mentioned shotman, but that isn't even a real screnshotting tool: it's just a screenshot GUI that depends on existing functionality that may or may not be present in your compositor. If all the compositors actually supported a standard for providing this functionality; and if that standard provided enough flexibility to do what I want, then I wouldn't complain. That's the essence of modularity. But the standards are poor and poorly-supported, and I literally can't do what I want. Your trivial example of using the sleep command to simulate delayed capture doesn't address the actual issue, and fails to recognize that no amount of hacky solutions will allow me to use a VNC screen sharing tool that shares only a specific window, because the Wayland compositors have chosen not to support that feature and failed to provide a standard way for external tools to do so.
  - QEIAo7BCrzKtYQ 4y ago
    >The Wayland architecture does not give me a choice in my screenshot, video recording, and remote desktop tool Yes it does. Use the screenshot, screencast and remote desktop XDG portals for that. It's understandable you're confused because the X11 way was to try to jam everything into X extensions whether it made sense or not. The overall trend lately is to move APIs into other components (XDG portals, pipewire, DBus, systemd, etc.)
saurik 4y ago
> ...without any of the modularity and flexibility that Linux is (allegedly) proud of. Linux seems to have been infiltrated by people who simply don't believe in this anymore, and so we keep getting "modern" "batteries included" integrated monoliths that suck at everything but supposedly make things easier because this new crop of people don't want to have to know about or compare multiple options :(. And like, because for specific use cases the monoliths can have better performance, that gets used as a way to undermine what used to be the unique selling proposition of Linux :(.
- deleted 4y ago
  [deleted]
robotnikman 4y ago
One of my favorite remote viewing tools, Anydesk, has no plans to support wayland, which is unfortunate...
Ptchd 4y ago
> However, you're limited to using the screenshot tool built in to your Wayland compositor That not true anymore... I use Flameshot
- hackyhacky 4y ago
  It offers a degraded experience depending on your compositor. https://flameshot.org/docs/guide/wayland-help/ https://flameshot.org/docs/guide/wayland-help/

sho_hn 4y ago

This is a valid and level-headed analysis. The good news is that this is not unfixable; there is a venue and a governance organization to standardize the protocols and compositor interoperability that is needed. And there has been notable progress. Specifically when it comes to screen share / remote desktop, standardization of the API to invoke sharing is happening by way of the XDG portal API efforts. There is active collaboration there e.g. between the browser vendors and the compositor vendors to agree on an interface. Here is a recent progress report: https://jgrulich.cz/2022/11/21/webrtc-chromium-year-end-report/ https://jgrulich.cz/2022/11/21/webrtc-chromium-year-end-repo...

Aardwolf 4y ago
> there is a venue and a governance organization to standardize the protocols and compositor interoperability that is needed I'm not sure if that applies specifically to this case, but I'm not a fan of some standardization of protocols that is going on in Linux desktops, because: - desktop managers can't properly keep state of your windows anymore on shutting off/on monitors. Claimed reason why this is not fixable: "the standard requires it" - I dislike MM/DD/YYYY date formats. File managers used to have their own setting to choose your date format. Now they use some common standard so you have to set your Linux locale to something non-US. This then breaks other things. It's much nicer to be able to configure things per-application. - Kolourpaint used to have a good color picker that showed you the numerical and hex values of colors. Now it has a horrible one that is only some palette where you can edit individual entries. You can't easily see the RGB values of a pixel in an image you open in Kolourpaint anymore. All due to "standardization", using a shared color picker component - Focus stealing prevention no longer properly works, all due to adhering to some desktop standards - Desktops like KDE and Cinnamon using horrible non-human editable json/xml/base64-encoded UTF-16 formats for their config - Some Qt or GDK applications not having icons sometimes, due to them expecting some common icons available somewhere. This issue used to not exist, applications came with their own icons that just worked I much preferred how unix and the desktop used to be, where you could manually edit textual config files to do whatever you want, and had the power and flexibility to change almost anything in intuitive ways
- ChuckNorris89 4y ago
  >I'm not a fan of some standardization of protocols that is going on in Linux desktops Standardization and Linux desktops are sometimes mutual conflicting terms. There's doesn't seem to be much standardization on this front but tribes of people saying "new things should be this way" and other tribes saying "n'ah mate, that sucks, we'll keep using our own better way". Linux desktops don't have the Apple/Microsoft dictatorship powers to actually enforce any kind of GUI standards so we get this constant hassle and even more fragmentation.
  - sho_hn 4y ago
    > Linux desktops don't have the Apple/Microsoft dictatorship powers to actually enforce any kind of GUI standards so we get this constant hassle and even more fragmentation. Do Apple and Microsoft actually have them? The GUI experience on Windows is relatively disjointed, and Apple famously did it to itself with e.g. randomly chosen brushed metal windows and other app-specific background textures. It appears far more common now for popular applications to ship their own look & feel and even theming. Let's say Discord, or even first-party, VS Code. I'd say the accomplishments of standardization and interoperability on the Linux desktop are actually more substantial than on either Windows or MacOS. Consider that e.g. KDE and Gnome applications share a lot of important standards and are generally able to run in either vendor's shells. Windows and MacOS each effectively only have a single GUI frontend, so this kind of collaboration between vendors doesn't need to be accomplished, and it's not happening between the app makers, either.
    - unconed 4y ago
      >brushed metal windows and other app-specific background textures. You're about a decade late with this complaint... and wrong. The brushed metal look was for application windows that resembled "appliances", which would remain open as you loaded/saved different projects. This was to distinguish them from the normal white document windows, which are tied 1-to-1 to a file. I'm not saying they always followed this rule exactly... but there definitely was a rule. And the Apple of the era would publish detailed Human Interface Guidelines detailing all the thinking and intended practices. Third party mac software of that era was famously extremely consistent too, because of this shared base. I only have one request from Linux desktops: mac style shortcuts with meta instead of ctrl. I also know it will never happen because everyone took their cues from messy Microsoft instead of the superior Apple practices.

WhyNotHugo 4y ago

> For example, my favorite screenshot tool supports automatic timed screenshots, of particular windows or the whole screen or of a specified region, of one desktop or several, and various customizations. Those features aren't supported by my compositor, and I don't have a choice. So Wayland limits my options. Xorg doesn't support his either. Your screenshotting tool runs the timer and takes the screenshot when the timer expires. You complaint is like saying "the Linux kernel won't render markdown for me". No, it won't, you're looking at the wrong part of the stack. For example, you can simply run `sleep 3 && shotman --output` to take a screenshot of an output in three seconds. There might be other GUI tools with a pretty timer setting. I've no idea if such a thing exists or not, but it's perfectly possible to write without any changes to the compositor (e.g.: the compositor provides the necessary APIs for thi).

hackyhacky 4y ago
You're missing my point. The Wayland architecture does not give me a choice in my screenshot, video recording, and remote desktop tool: you have to use the functionality built in to the compositor. Many compositors (notably GNOME and KDE) don't support the Wayland semi-standard interface for these things. You mentioned shotman, but that isn't even a real screnshotting tool: it's just a screenshot GUI that depends on existing functionality that may or may not be present in your compositor. If all the compositors actually supported a standard for providing this functionality; and if that standard provided enough flexibility to do what I want, then I wouldn't complain. That's the essence of modularity. But the standards are poor and poorly-supported, and I literally can't do what I want. Your trivial example of using the sleep command to simulate delayed capture doesn't address the actual issue, and fails to recognize that no amount of hacky solutions will allow me to use a VNC screen sharing tool that shares only a specific window, because the Wayland compositors have chosen not to support that feature and failed to provide a standard way for external tools to do so.
- QEIAo7BCrzKtYQ 4y ago
  >The Wayland architecture does not give me a choice in my screenshot, video recording, and remote desktop tool Yes it does. Use the screenshot, screencast and remote desktop XDG portals for that. It's understandable you're confused because the X11 way was to try to jam everything into X extensions whether it made sense or not. The overall trend lately is to move APIs into other components (XDG portals, pipewire, DBus, systemd, etc.)

saurik 4y ago

> ...without any of the modularity and flexibility that Linux is (allegedly) proud of. Linux seems to have been infiltrated by people who simply don't believe in this anymore, and so we keep getting "modern" "batteries included" integrated monoliths that suck at everything but supposedly make things easier because this new crop of people don't want to have to know about or compare multiple options :(. And like, because for specific use cases the monoliths can have better performance, that gets used as a way to undermine what used to be the unique selling proposition of Linux :(.

deleted 4y ago
[deleted]

robotnikman 4y ago

One of my favorite remote viewing tools, Anydesk, has no plans to support wayland, which is unfortunate...

Ptchd 4y ago

> However, you're limited to using the screenshot tool built in to your Wayland compositor That not true anymore... I use Flameshot

hackyhacky 4y ago
It offers a degraded experience depending on your compositor. https://flameshot.org/docs/guide/wayland-help/ https://flameshot.org/docs/guide/wayland-help/