"cargo build" OK but "cargo build --release" not OK about rust-clipboard HOT 9 CLOSED

@aweinstock314 awesome to see this fixed with the recent PRs ! Thanks 😃

from rust-clipboard.

I wasn't able to reproduce this issue on Debian8 with XFCE (either with https://github.com/conradkleinespel/rust-clipboard-issue or embedded in Servo), it works in both debug and release mode for me.

Specifically, I've tested (with each of rust-clipboard-issue's builds running in the background):

• CTRL-V in mousepad (the XFCE built in text editor)
• middle click in xterm (with "Select to clipboard" enabled in xterm via CTRL-middleclick)
• Servo (pasting into the textbox on './mach run -r https://wikipedia.org')

I've also tried a few pasting into mousepad/servo/xterm under similar conditions with text copied in servo via CTRL-C.

Could you share more details of your setup/which programs you've tried pasting into?

from rust-clipboard.

Thanks for taking the time to test this @aweinstock314. I will test again shortly and get back on this thread with more information about my setup.

from rust-clipboard.

@aweinstock314 I just tested again, this time on Ubuntu 16.04. Seems to work fine in release mode too. Maybe this was just an issue with my specific Arch setup. Anyway, this seems to rule out rust-clipboard itself being the issue.

Thanks again for taking the time to test this.

from rust-clipboard.

I've run into this problem on Arch Linux as well. Pasting content from other programs works fine in release mode, but copying (essentially, calling set_contents) doesn't work for me. 😞

from rust-clipboard.

@jmacdonald I'm having the same problem on Ubuntu 16.04 now again. So I'm re-opening in case anyone else has more information about this.

from rust-clipboard.

Even in debug mode I'm noticing strange behaviour:

1. Copy some text to the clipboard.
2. Paste text. This seems fine.
3. Copy another bit of text.
4. Paste text. The first bit of text (from step 1) is pasted.
5. Paste text again. The second bit of text (from step 3) is pasted.

It's almost as if the clipboard is behaving as a stack (albeit inconsistently). For what it's worth, xclip works fine on this system (and its copied content pastes correctly through rust-clipboard).

from rust-clipboard.

I too suffer from this bug using KDE Neon (based on Ubuntu 16.04).

If I compile in --release what I send to the clipboard using .set_contents( ) doesn't get caught by my systems clipboard manager, however it seems like .get_contents() gets the updated result.
If I compile in cargo's debug-profile however the updated clipboard gets caught by my systems clipboard manager.

Strange, and likely to present a problem to me later on but for now I can just stick with the debug profile.

from rust-clipboard.

I've run into this bug too, and as far as I can tell it only affects pasting in qt-based programs. I suggest using e.g. kate to test this.

from rust-clipboard.