6 ms·

>no forethought given to apps that need global keybinds Please see this pull request for a description of some of the current challenges with getting global sh

>no forethought given to apps that need global keybinds Please see this pull request for a description of some of the current challenges with getting global shortcuts to work: https://github.com/flatpak/xdg-desktop-portal/pull/711 https://github.com/flatpak/xdg-desktop-portal/pull/711 >no forethought to screen capture The plan for a while has been to put screen capture in Pipewire, this is already working for apps that support it. In any case, X11 also does not have any forethought in relation to hotkeys or screen capture. Technically it has no API for either of those, it has APIs that allow all applications to intercept all keys, and to allow all applications to read the contents of any window. Those APIs can be used to do hotkeys and screen capture in a rudimentary and somewhat broken way but they are not ideal. Just copying those (or an API that looks like those) into Wayland would be an unwise idea.

fps_doug 4y ago
pmontra 4y ago
>> no forethought to screen capture > The plan for a while has been to put screen capture in Pipewire, this is already working for apps that support it. > In any case, X11 also does not have any forethought in relation to hotkeys or screen capture IHMO screen capture and screen sharing are more basic functionality in 2022 than frame perfect. The reason is that if every frame is not perfect we can still understand what happens on our screens. If I can't make screenshots and I can't share the screen I can't work so I will use something else. X11, Windows, Mac, etc. X11 eventually solved those problems (actually the solution derives by trusting every client of the server) and Wayland will solve them too. But as Wayland started in a world where screenshots and screen sharing were already work tools, one of the very first questions should have been: how do we design both a secure system and one that allows screenshots and screen sharing? If it was asked it wasn't given the right priority. Having apps to collaborate with Pipewire (which was added later on if I'm not wrong) is bad design. The screen is there, I want to be able to grab it and share it no matter which app is on screen. Those pixels are mine, right?
- Crysstalis 4y ago
  >how do we design both a secure system and one that allows screenshots and screen sharing? That did already happen, Weston had a built in screenshot tool. Pipewire was adopted because it was an improvement on the Weston design.

fps_doug 4y ago

pmontra 4y ago

>> no forethought to screen capture > The plan for a while has been to put screen capture in Pipewire, this is already working for apps that support it. > In any case, X11 also does not have any forethought in relation to hotkeys or screen capture IHMO screen capture and screen sharing are more basic functionality in 2022 than frame perfect. The reason is that if every frame is not perfect we can still understand what happens on our screens. If I can't make screenshots and I can't share the screen I can't work so I will use something else. X11, Windows, Mac, etc. X11 eventually solved those problems (actually the solution derives by trusting every client of the server) and Wayland will solve them too. But as Wayland started in a world where screenshots and screen sharing were already work tools, one of the very first questions should have been: how do we design both a secure system and one that allows screenshots and screen sharing? If it was asked it wasn't given the right priority. Having apps to collaborate with Pipewire (which was added later on if I'm not wrong) is bad design. The screen is there, I want to be able to grab it and share it no matter which app is on screen. Those pixels are mine, right?

Crysstalis 4y ago
>how do we design both a secure system and one that allows screenshots and screen sharing? That did already happen, Weston had a built in screenshot tool. Pipewire was adopted because it was an improvement on the Weston design.