Closed brandon-lockaby closed 2 years ago
I use another script that saves clipboard contents to a file using pimg g "$path"
From terminal, it works, but from a KDE custom shortcut, it doesn't write any file. Any idea?
First, I am not very familiar with KDE. Are the "shortcut" you say desktop entries like Windows?
I have only confirmed that this tool works on the command line in Ubuntu (GNOME), macOS and Windows. That is all I need. So whether or not it can be run from the shortcut you mention is outside the scope of support, but I may be able to give you some advice if you provide me with more information.
Thank you, I'm dyin' here! The shortcuts are just saved in what looks like a sort of ini file, with an entry reading e.g. CommandURL=~/screenshot.sh Based on what little I know about X clipboard, the application that "owns" the clipboard buffer needs to be running for it to be available to paste. Is there a mechanism by which your script keeps a process running or something? I'm just clamoring for clues
Have you tried to specify below command to Command/URL
:
sh -c 'maim -s /tmp/clip.png && pimg c /tmp/clip.png'
OR
bash -c 'maim -s /tmp/clip.png && pimg c /tmp/clip.png'
Using sh -c 'maim -s /tmp/clip.png && pimg c /tmp/clip.png'
, my clipboard is still populated with text copied earlier
However, the same command works in terminal
After running maim -s /tmp/clip.png
from the shortcut, does /tmp/clip.png
exist?
If not, PATH
may be incorrect in environment run from shortcut
Yes, it does
After running:
sh -c 'maim -s /tmp/clip_1.png && pimg c /tmp/clip_1.png &> /tmp/pimg.log'
/tmp/clip_1.png
exist?/tmp/pimg.log
exist?/tmp/pimg.log
say?Using it as the shortcut command/url:
in terminal, another story... $ maim -s /tmp/clip_1.png && pimg c /tmp/clip_1.png &> /tmp/pimg.log7 X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 15 (X_QueryTree) Resource id in failed request: 0x1216647 Serial number of failed request: 320 Current serial number in output stream: 320
idk, I think I broke my session or something, as maim produces this output every time, now. brb 😆
If I have time over the weekend, I'll create a KDE environment and test this issue.
Ok ♥ I hope you don't pull your hair out like me though
I think I am understanding the issue a little, and that it must be a kde/plasma/systemclipboard/klipper issue: The system clipboard manager (I think it used to be klipper but was integrated into plasma itself) by default has the behavior of "prevent empty clipboard." I don't think your solution is keeping a process open to "own" the clipboard, so it becomes necessary to rely on this behavior of the clipboard manager to put it back. Disable this option and pimg leaves you with an empty clipboard, although you can see the image in the clipboard history. However, something is different when running from a keyboard shortcut, and the clipboard manager doesn't see it, and it doesn't show up in the history. I've tried source ~/.bashrc, comparing env's, with no joy so far, I think it might be something else somehow. If I'm right though, it's like a process would need to wait around until it's not the clipboard owner anymore, which sounds like a project.
I've solved it for me by running e.g. python3 ~/.local/bin/pimg
instead of just pimg
, in combination with "prevent empty clipboard" in the clipboard manager
idk where ~/.local/bin/ is supposed to be added to PATH, but I guess it's not in .bashrc...
Running from a terminal
And then paste on imgur.com for testing.
The content is from the file as expected.
Running from a shortcut (KDE)
The content is not from the file as expected, but earlier clipboard content.
Sorry, I am losing my mind over this.