4 ms·

I actually went looking at the source code to see if this would work on Wayland and it doesn't. The clipboard snooping is implemented by listening for events us

I actually went looking at the source code to see if this would work on Wayland and it doesn't. The clipboard snooping is implemented by listening for events using gdk.Clipboard, which is not an ext_data_control_v1 implementation. So on Wayland it'll only notice clipboard events if it's in focus (or if the compositor sends clipboard events to unfocused windows, which I'm not sure any do). https://github.com/murat-cileli/clyp/blob/2c0ce6c33813c3f35f60e1bc35e093873f208f1e/clipboard.go#L66 https://github.com/murat-cileli/clyp/blob/2c0ce6c33813c3f35f... Edit: Yes, tested it now and it doesn't detect clipboard events from Wayland windows when it doesn't have focus. It only detects events from Xwayland windows when unfocused, or if I copy something from a Wayland window and then focus the clyp window then it detects the thing I copied.

nine_k 1y ago
It's almost as if a Wayland compositor should keep a list of trusted apps to broadcast clipboard events to, somehow similar to how screenshots are handled. (Not that Wayland is well-rounded in this regard.)
- Arnavion 1y ago
  The ext_data_control_v1 protocol I mentioned is a protocol specifically for clipboard managers. So a client that wants to be a clipboard manager would implement that protocol. There are already implementations of it like wl-clipboard. There is no need for the compositor to broadcast regular clipboard events (wl_data_offer). Now the compositor could certainly keep an additional list of trusted applications that are allowed to be clients of the ext_data_control_v1 protocol. Though identifying the client to enforce such a thing is a bigger problem than just maintaining a list of applications, because the protocol has no client identification. AFAIK every compositor that supports that protocol has no restrictions on clients requesting it, though something involving the security-context protocol might change this in the future.
  - Cloudef 1y ago
    Hyprland has sort of permission handling https://wiki.hypr.land/Configuring/Permissions/ https://wiki.hypr.land/Configuring/Permissions/ But yeah there isn't really a "standard wayland ecosystem way"
    - Arnavion 1y ago
      I see the prompt-less permission config is based on the executable path. How does it get the executable path for the client? And is it robust against me spinning up a mount namespace with an arbitrary /usr/bin/grim that I control?
      - Cloudef 1y ago
        Probably not
ghostly_s 1y ago
Odd, why does the readme tout "Full Wayland support" then?
- RonanSoleste 1y ago
  Because its easy to write it and most wont even verify?

nine_k 1y ago

It's almost as if a Wayland compositor should keep a list of trusted apps to broadcast clipboard events to, somehow similar to how screenshots are handled. (Not that Wayland is well-rounded in this regard.)

Arnavion 1y ago
The ext_data_control_v1 protocol I mentioned is a protocol specifically for clipboard managers. So a client that wants to be a clipboard manager would implement that protocol. There are already implementations of it like wl-clipboard. There is no need for the compositor to broadcast regular clipboard events (wl_data_offer). Now the compositor could certainly keep an additional list of trusted applications that are allowed to be clients of the ext_data_control_v1 protocol. Though identifying the client to enforce such a thing is a bigger problem than just maintaining a list of applications, because the protocol has no client identification. AFAIK every compositor that supports that protocol has no restrictions on clients requesting it, though something involving the security-context protocol might change this in the future.
- Cloudef 1y ago
  Hyprland has sort of permission handling https://wiki.hypr.land/Configuring/Permissions/ https://wiki.hypr.land/Configuring/Permissions/ But yeah there isn't really a "standard wayland ecosystem way"
  - Arnavion 1y ago
    I see the prompt-less permission config is based on the executable path. How does it get the executable path for the client? And is it robust against me spinning up a mount namespace with an arbitrary /usr/bin/grim that I control?
    - Cloudef 1y ago
      Probably not

ghostly_s 1y ago

Odd, why does the readme tout "Full Wayland support" then?

RonanSoleste 1y ago
Because its easy to write it and most wont even verify?