Feature request: Copy to clipboard
Expected Behavior
Currently we can click on the copy button in the application to copy a screenshot to the clipboard. However, when used with the -m option, the window never appears and clicking the button requires to first restore the window. Then you must close the window after clickling the copy button. This is very tedious, and should be done automatically (with an option). For example, calling screengrab -rmc can copy a region of the screen to the clipboard, without interacting with the application. -c here automates the process.
Current Behavior
As explained above, the current flow is, you open the application, click on the copy button and then close the application. With a new parameter, this can be automated.
Possible Solution
A new parameter -c will automatically copy the screenshot to the clipboard. It behaves as if the user clicked the copy button.
Steps to Reproduce (for bugs)
Context
I am frequently taking partial screenshots of my screen through operating system shortcuts and pasting them into whatsapp, gimp, etc. Without this feature, I have to interact with the screengrab window everytime. This is a big problem for me as I use i3wm with autotiling and everytime a new window is opened the existing windows are affected from this. They get resized and moved. Sometimes I can even lose the content I would take a screenshot of.
System Information
- Distribution & Version: Endeavour OS, i3wm
- Kernel: 6.5.9-arch2-1
- Qt Version: qt5-base 5.15.11+kde+r138-1
- libqtxdg Version: libqtxdg 3.12.0-1
- lxqt-build-tools Version: none
- Package version: screengrab 2.7.0-1
Something I miss now too, used to Niri's shortcut behviour. Adding an option similar to "autosave" but for the clipboard.
I think the best approach is adding a command-line option:
-c, --copy Copy to clipboard
I'll implement it soon. However, this question arises: Do we want the recently implemented option -n to save the screenshot when used alongside -c ? If not, the option should be like this:
-c, --copy Copy to clipboard, and do not save with -n option
Not sure if that's the best solution, I'd prefer a parallel setting to "autosave" in the GUI. Maybe both is possible?
Both are possible, but I have a feeling that it would an overkill.
Let's decide this before I start to work on it, because it'll be too late afterward. Isn't it like an overkill to you?
Not really - it would cover all cases and desires, like using regardless of the options in the GUI -nfc for example.
- having an option in the GUI for autosave to clipboard
- in addition also if unchecked -c would copy from cli to clipboard
OK.
Bad news: Wayland (or Qt/QtWayland) has an issue that I don't think can be circumvented. I encountered it on labwc (didn't check another compositor). It confused me for half an hour. Then I saw that it had confused people on Internet much more than me (I don't add a link, to prevent GitHub from creating links between pages), because at least I know when it happens ;)
You can see it in the current master by doing this:
- Select "Copy file name only" in Options → Main → Copy filename to the clipboard when saving.
- Also, check both "Auto save screenshot" and "Save first screenshot" in Options → Advanced.
- Save options and exit ScreenGrab — it's important that you do this.
Now, run screengrab -f. Check the clipboard. The file name is not copied to it on auto-saving. But if you save the screenshot by clicking the Save button, the file name will be copied to the clipboard on saving.
Exactly the same thing happens for auto-copying (I made a patch and tested it on labwc): the image isn't copied to the clipboard automatically — although the notification says it is — but it's copied by clicking the Copy button (or using its shortcut).
Now, the problem is that Qt copies text or image to the Wayland clipboard only when that's done through a visible action (button) inside a window. I don't have the slightest idea why.
I don't think X11 has this issue, but I didn't test either.
I see that also from the GUI, only if the save button is hit file path is copied, but with screengrab -f (if running in tray or also not) the file path is copied here.
I think the only possible workaround is working with wlr data control protocol directly. That's not an option, because QtWayland already uses it but has this bug.
I logged into X11 and saw that Qt's handling of clipboard also had an issue there. Although auto-copying worked under normal circumstances, it didn't work with the -n option.
All in all these are the problems:
- On X11, the window should be shown for copying to clipboard to work. So, auto-copying doesn't work with
-n, although it works under other circumstances. - On Wayland, it's much more weird: not only the window should be shown, but also some user interaction should be done with it, even if it's just moving the cursor over it. That's why auto-copying doesn't work with the first screenshot: it's done before any user interaction with the window, or with no window (in the case of
-noption).
The second issue is serious.
The attached code sample shows my point (compile it with qmake6 && make). It shows a simple window with an editor and puts "Test text" into QClipboard.
If it's launched under X11, "Test text" will be pasted not only inside the app's editor but also anywhere a text can be pasted.
If it's launched under Wayland, "Test text" will be pasted only inside the app's editor, nowhere else. That shows QClipboard doesn't put "Test text" into the Wayland clipboard.
However, if I added a button to the app for copying "Test text", its triggering would paste it anywhere on Wayland too.