4 ms·
There should be no “reading the clipboard” at all. A “paste” should result in the OS providing the contents to the app, not signalling the app to read the clipb
by stanmancan 6y ago
There should be no “reading the clipboard” at all. A “paste” should result in the OS providing the contents to the app, not signalling the app to read the clipboard.
- gruez 6y agoYour solution of "only let the OS initiate pasting" only really works when dealing with os provided text editing widgets. What if an app wants to implement a paste button/gesture? eg. paste and go to url that chrome/safari has, or terminal emulators that paste on control-shift-v rather than control-v, or photo editors that don't really have a text box to "paste" to begin with.
- pavel_lishin 6y agoYes, these are hard problems, but I would prefer that they either be solved - or go without some features - rather than let every app be able to read the contents of my clipboard.
- kshacker 6y agoHard problems sometimes (but not always) have simple solutions. Putting apps copying clipboard up in your face is one such solution and it seems to be highlighting the abusers, no? Even if an app has a genuine need to copy clipboard, having it in front of user every time will be useful.
- stanmancan 6y agoI know those are probably just a few examples of many but: Paste and go isn’t a feature worth sacrificing the privacy of your clipboard contents Terminal emulators, not sure to be honest. Why not stick to traditional cut and paste shortcuts? Photo editors: nobody said you need a text box to paste to. Set your UI element as “pasteable” or whatever’s needed and let the app handle whatever clipboard contents comes it’s way. If it’s not supported it gets ignored.