I didn’t expect my words to be that deeply analyzed. This clearly counts as processing 
I agree that this far from perfect. Personally, I think I would love to have a Filecopy style window that would tell me where I’m copying data from and ask to which qube I want to paste it. This is probably not difficult to implement, but I never got around this. At least this would make it more difficult to paste things into a wrong qube.
You can get involved here:
Honestly I was just about to straight up say no, since I feel like I’m way to new to Qubes to start making changes. But then I looked at the source code and honestly I’m going over and over this in my head and can’t really imagine any serious obstacles? I’m probably missing something very obvious.
That said I’ll probably still pass on this for couple of reasons: for one I’m a lazy leech and if I were to do some actual work there are subsystems that need much more love than the clipboard (cough cough firewall? cough); and what’s there already is working.
But honestly my main problem is I don’t think I’d be comfortable using any software that accepts PRs from me
It took my brain an embarrassing amount of time to process this joke 
Thank you very much for this!
I created shortcuts in Keyboard → Shortcuts:
/bin/bash -c "sleep 0.2 && xdotool key ctrl+c && sleep 0.2 && xdotool key ctrl+shift+c" for copy and write to interVM-clipboard
/bin/bash -c "sleep 0.2 && xdotool key ctrl+shift+v && sleep 0.2 && xdtool key ctrl+v" for read, wipe and paste
And it’s working sometimes! Not smoothly (to the point of “unusable”, 50% times it’s just does not work and idk why) and some apps are ignoring these methods, but still.
Probably I could achieve same goal more smoothly with xte\xkb\ahk\xbindkeys\etc but I’m afraid of installing anything in dom0.
I’m sure there is a more proper way to do this, but two comments:
One reason this might not work is that your modifier key (Win?) for this is still depressed while the script is being executed. Just for testing if you increase the first sleep to 1 second and make sure that you don’t press any keys when this is executed, does the situation improve?
There is the danger that the focus changes between the two executions of xdotool (by the way, you mistyped it in the second script). I believe there is a way to get the window ID first, and then send both keystrokes to the same window.
by the way, you mistyped it in the second scrip
thx edited (typo cause there’s no way to copypaste from dom0)
One reason this might not work is that your modifier key (Win?) for this is still depressed while the script is being executed.
Actually I tried it with Ctrl+Alt+,. and Ctrl+C\V (but concern on key being pressed is still reasonable).
Just for testing if you increase the first sleep to 1 second and make sure that you don’t press any keys when this is executed, does the situation improve?
0.2: Paste working, copy doesn’t
1: Paste working, copy doesn’t
1 but trying to depress on copy real fast: TOTALLY WORKS. Thanks.
I changed delays from 1s everywhere to 0.2 + 0.2 on paste, still works. Copy does not work on 1 + 0.2 or 0.2 + 1, 1 + 1 only. Tried Win\Meta\Super+C\V, also F7\8+C\V, same result on delays (copying does not happen, but writing to interVM-clipboard maybe does, there’s notify about it).
Maybe only first emulated shortcut is messed by trigger key(s), if second working properly? Aaaaand yes that’s the fix. /bin/bash -c "sleep 0.1 && xdotool key ctrl && sleep 0.1 && xdotool key ctrl+c && sleep 0.1 && xdotool key ctrl+shift+c" perfectly works.
But with Ctrl+C as a trigger this does not work at all, also this keystrokes sequence can stop stuff if you’d try to copy text from terminal. Maybe there’s some console way of copying in VM’s clipboard? Still win though.
I believe there is a way to get the window ID first, and then send both keystrokes to the same window.
It wouldn’t work if focus changes after emulated end copy and before physical start of paste. So only protection from change focus after (start of?) physical keystroke and before emulated keystrokes (which is time-possible because of two waits).
In my opinion Qubes Clipboard should hold its security aspect like now even if it changes in future. I don’t like the idea of sharing my VM clipboard to directly Global clipboard without any manual method ( like now ctrl+shift+c). But showing the content of clipboard by any tooltip can be helpful (But I think that might increase attack surface because of parsing?)
In ANY case I don’t want to mess with Security of my system, I can afford losing some usability.
How about a notification that shows the clipboard transaction by source vm to destination vm. This only shows vm names not the actual text copied.
This could look like file copy between VMs and thus would help to look moreconsistent.
FY(& others)I: If you click the Qubes Clipboard widget, you should see “Copy dom0 clipboard”…
