3 ms·

> For example, my favorite screenshot tool supports automatic timed screenshots, of particular windows or the whole screen or of a specified region, of one desk

> 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.)
  - hackyhacky 4y ago
    The portal only allows an external application to request the service from the compositor. He portal does not allow an external application to provide additional functionality beyond what is already provided by the compositor. In my use case, I want to screen share a specific window, not the whole screen; this is functionality previously provided by a third-party X11-based tool, which cannot be provided from an XDG portal (even on those compositors that support portal at all).
  - WhyNotHugo 4y ago
    Portals are a really weird thing. They're mostly pushed via the Flatpak/GNOME crowd, and are intended to be cross platform by using an external messaging bus: d-bus (e.g.: they don't use the X protocol and Wayland). The same interface can be used in both Xorg and Wayland, and that's the only upside of portals. However, their implementation is not meant for native applications and are pretty inefficient. For example, the screenshot portal will save the image into disk and return its path -- so if you wanted to render the image on screen, you now need to read and decode a file. The screenshot is encoded, serialised to disk, serialised FROM disk and then decoded again just to get pixels from the compositor back into the compositor. Portal really don't make sense if you're writing native wayland clients, since portals just really end up using the wayland protocol under the hood, with two or three services in the middle handing messages over just to expose a "standard" API.
- WhyNotHugo 4y ago
  There's discussions in progress about adding the ability to capture a single toplevel window to the screencopy protocol. Nobody's decided that it's a bad idea, it merely hasn't been implemented yet. Regarding the fact that GNOME doesn't implement a lot of functionality: I don't think it's fair to criticise the protocol and architecture because one implementation decides not to implement a given feature. This is like saying "C sucks because some specific compiler doesn't support the feature I need". It's the compiler you've chosen that sucks in that case, not the language. I'm sure there's some X server implementation out there that's also lacking features you want -- but you wouldn't blame the protocol itself for that implementation's shortcomings.
Sakos 4y ago
> 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. Xorg also doesn't prevent you from using an application that does have these functions. Wayland does prevent you. > but it's perfectly possible to write without any changes to the compositor (e.g.: the compositor provides the necessary APIs for thi). The necessary APIs don't exist, so it isn't possible to write the extra functionality without changing the compositor. Honestly, I don't understand why anybody defends Wayland at this point. It's been, what, ~~six years? Six years~~ FOURTEEN FUCKING YEARS we've been telling you that we want to be able to use our screenshot and recording applications and that removing functionality that we use day-to-day wasn't acceptable. Are the Firefox devs the same people making Wayland? Is that why they're so unresponsive to user needs?
- jpetso 4y ago
  > Is that why they're so unresponsive to user needs? It's because Wayland is a set of protocols, rather than a single dominant implementation. In order to do it right, cross-compositor and flexible, you have to get different actors with different interests and bandwidth agree on a standard. This takes time. In order to get it working fast, developers need to make a compositor-specific implementation first and then put in the extra work of getting it through the standards discussion as well as switching their compositor ecosystem to the new standard. Until this happens with all parts that you care about, you're going to be annoyed either about interoperability or functionality. Pick your poison, and cue Moxie's "The Ecosystem is Moving" blog post. Also, keep using X11 until Wayland has the features you want. Most DEs/WMs haven't ripped out X11 support yet, and hopefully won't until their support of Wayland protocols is solid enough.
  - Sakos 4y ago
    Sounds like a terribly managed project that will never reach an acceptable state. Again, I don't know why people are so tolerant of it. If the Linux kernel had worked the same way, we'd never have gotten Linux.

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.)
- hackyhacky 4y ago
  The portal only allows an external application to request the service from the compositor. He portal does not allow an external application to provide additional functionality beyond what is already provided by the compositor. In my use case, I want to screen share a specific window, not the whole screen; this is functionality previously provided by a third-party X11-based tool, which cannot be provided from an XDG portal (even on those compositors that support portal at all).
- WhyNotHugo 4y ago
  Portals are a really weird thing. They're mostly pushed via the Flatpak/GNOME crowd, and are intended to be cross platform by using an external messaging bus: d-bus (e.g.: they don't use the X protocol and Wayland). The same interface can be used in both Xorg and Wayland, and that's the only upside of portals. However, their implementation is not meant for native applications and are pretty inefficient. For example, the screenshot portal will save the image into disk and return its path -- so if you wanted to render the image on screen, you now need to read and decode a file. The screenshot is encoded, serialised to disk, serialised FROM disk and then decoded again just to get pixels from the compositor back into the compositor. Portal really don't make sense if you're writing native wayland clients, since portals just really end up using the wayland protocol under the hood, with two or three services in the middle handing messages over just to expose a "standard" API.
WhyNotHugo 4y ago
There's discussions in progress about adding the ability to capture a single toplevel window to the screencopy protocol. Nobody's decided that it's a bad idea, it merely hasn't been implemented yet. Regarding the fact that GNOME doesn't implement a lot of functionality: I don't think it's fair to criticise the protocol and architecture because one implementation decides not to implement a given feature. This is like saying "C sucks because some specific compiler doesn't support the feature I need". It's the compiler you've chosen that sucks in that case, not the language. I'm sure there's some X server implementation out there that's also lacking features you want -- but you wouldn't blame the protocol itself for that implementation's shortcomings.

Sakos 4y ago

> 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. Xorg also doesn't prevent you from using an application that does have these functions. Wayland does prevent you. > but it's perfectly possible to write without any changes to the compositor (e.g.: the compositor provides the necessary APIs for thi). The necessary APIs don't exist, so it isn't possible to write the extra functionality without changing the compositor. Honestly, I don't understand why anybody defends Wayland at this point. It's been, what, ~~six years? Six years~~ FOURTEEN FUCKING YEARS we've been telling you that we want to be able to use our screenshot and recording applications and that removing functionality that we use day-to-day wasn't acceptable. Are the Firefox devs the same people making Wayland? Is that why they're so unresponsive to user needs?

jpetso 4y ago
> Is that why they're so unresponsive to user needs? It's because Wayland is a set of protocols, rather than a single dominant implementation. In order to do it right, cross-compositor and flexible, you have to get different actors with different interests and bandwidth agree on a standard. This takes time. In order to get it working fast, developers need to make a compositor-specific implementation first and then put in the extra work of getting it through the standards discussion as well as switching their compositor ecosystem to the new standard. Until this happens with all parts that you care about, you're going to be annoyed either about interoperability or functionality. Pick your poison, and cue Moxie's "The Ecosystem is Moving" blog post. Also, keep using X11 until Wayland has the features you want. Most DEs/WMs haven't ripped out X11 support yet, and hopefully won't until their support of Wayland protocols is solid enough.
- Sakos 4y ago
  Sounds like a terribly managed project that will never reach an acceptable state. Again, I don't know why people are so tolerant of it. If the Linux kernel had worked the same way, we'd never have gotten Linux.