Emote icon indicating copy to clipboard operation
Emote copied to clipboard

Do not use (main) clipboard

Open reitzig opened this issue 3 years ago • 10 comments

emote uses the "main" clipboard to paste emojis; that tends to break some workflows ("copy image; write tweet; paste im ... fuck").

As per askubuntu#591686, xdotool can send Unicode characters directly which should provide a neat solution that does not "pollute" the clipboard.

As an alternative, you could use xsel -s to use the seconday selection instead, in the hope of causing fewer conflicts.

reitzig avatar May 28 '21 10:05 reitzig

Does this fix work with terminals? #66

rbreaves avatar Apr 13 '22 13:04 rbreaves

I uninstalled this app and will not use it until this has been fixed. I lost my clipboard contents too many times and this is definitely unacceptable.

They may be some technical limitations that requires to use the clipboard, but technical limitations should not interfere with user experience since the user should not be aware of how the software is working. Especially for this kind of general-audience software, were users usually don't have any technical background. From the user point of view, emojis have nothing to do with the clipboard, and thus this behavior should be considered as a bug (and a critical one if you consider that it can results in data-loss in the case of your clipboard containing the only copy of something - after using ctrl+X for instance).

EDIT: Maybe restoring the clipboard state after pasting the emoji could be a solution.

paullaffitte avatar May 06 '22 11:05 paullaffitte

Pull requests are welcome

tom-james-watson avatar May 06 '22 12:05 tom-james-watson

As I realize that I cannot reasonably stop using this software (I have to admit that it is quite useful) I will try to present a pull request soon

EDIT: I've found a way to not even use the clipboard and it works on my computer (using X11). I will try to make it clean and submit a PR in the week-end.

paullaffitte avatar May 06 '22 12:05 paullaffitte

@tom-james-watson Was #42 a reasonable place to start?

reitzig avatar May 07 '22 10:05 reitzig

Sorry I forgot that that PR existed. My opinion on that is still https://github.com/tom-james-watson/Emote/pull/42#issuecomment-860185632. Restoring clipboard contents is problematic because of the issues mentioned. The main thing to bear in mind as well is that on Wayland, which is going to be the default for probably the majority of users over the next year or two, cannot perform a paste and so relies entirely on copying.

tom-james-watson avatar May 07 '22 11:05 tom-james-watson

Sorry I didn't see your answers before doing the PR. #42 looks to be exactly what I was thinking about. I just didn't know that I needed to focus the window in order to type in it. But the main issue seems to be with Wayland from what I understand ? Why not merging #42 now and then wait until mutter supports virtual-keyboard-unstable-v1 to use wtype in Wayland ?

paullaffitte avatar May 07 '22 14:05 paullaffitte

Restoring clipboard contents is problematic because of the issues mentioned.

I for one would be fine with a configuration flag switching between using clipboard and fake-typing. Using the clipboard still frequently breaks my (work)flow, esp. in combination with taking screenshots.

The main thing to bear in mind as well is that on Wayland, which is going to be the default for probably the majority of users over the next year or two, cannot perform a paste and so relies entirely on copying.

I can't comment on Wayland; your prognosis seems rather optimistic to me, though. To my knowledge, Ubuntu 22.04 LTS does use Wayland by default but I find many voices saying it doesn't work well for them, still. I for one see little advantage in using Wayland with i3 (which would mean replacing i3 completely, no less); not enough to rewrite a whole bunch of scripts and configs, anyway. Not that X is good, but I've learned to live with it, as have roughly all Linux desktop users. :tipping_hand_man: Anyway, that's all just guesswork at this point. Suffice to say, I don't think using a prognosis regarding adoption of Wayland is a good argument for either side of this.

reitzig avatar May 10 '22 11:05 reitzig

FWIW, it seems espanso has solved the very same issue. They reference

Thanks to libxdo and xclip, used to implement the Linux port. Thanks to libxkbcommon and wl-clipboard, used to implement the Wayland port. Thanks to wxWidgets for providing a powerful cross-platform GUI library.

reitzig avatar Aug 19 '22 10:08 reitzig

By the same issue do you mean injecting text under wayland? I have spent about an hour looking through these / doing some research.

As far as I can tell, wl-clipboard is only useful for cli interaction.

It looks like maybe with libxkbcommon it may be possible, but there's a lot of unknowns (to me) and concepts and systems that I'm not familiar with here, as well as a language I'm not very familiar with (C).

I personally am stuck. If somebody knows of an approach to either simualte a keypress (to do ctrl+v) or of some way of globally injecting text with wayland, please let me know!

tom-james-watson avatar Aug 19 '22 11:08 tom-james-watson

I am going to close this out, because for now copying the selection to clipboard is the intended behaviour of the app. I can understand the argument for X11 to not do this, but the default on linux these days is Wayland and currently there is no known way to recreate the insertion of arbitrary characters with Wayland. I don't want the app to behave different on X11 vs Wayland, so I don't think it makes sense to make any changes here.

I would potentially accept a PR that implements an option in preferences that turns off clipboard copying, as long as by default copying is turned on and if the preference is only visible if running under X11. I'll close this out because at the moment this is not planned. Thanks!

tom-james-watson avatar Jun 20 '23 13:06 tom-james-watson