New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Copied text lost after Komodo is closed (Linux) #534

Closed
ervumlens opened this Issue Aug 17, 2015 · 11 comments

Comments

Projects
None yet
4 participants
@ervumlens

ervumlens commented Aug 17, 2015

9.2.0 Linux. Cannot reproduce in Windows.

Problem
I copied text from an editor in Komodo Edit, then closed Komodo. The text I copied was no longer available to paste.

This only occurs for text copied from within KE and only from KE editors/buffers. The clipboard is unaffected if the copy occurred in another program before closing KE. Also, I can copy the text from a textbox in Preferences and the text is available to paste after closing KE.

Steps to Reproduce

  1. Cut or copy some text out of a Komodo editor.
  2. Close Komodo.
  3. Open some other editor or open Komodo again.
  4. Attempt to paste into it.

Expected
The copied text appears.

Actual
The paste action is not available.

The following macro doesn't produce this problem. Good for you, macro!

//this is a javascript macro
xtk.clipboard.setText("Don't blame me! I exist on the clipboard after Komodo is closed.");

However, the text copied by this macro does produce the problem. The text is lost after closing KE.

//this is also a javascript macro
var editor = require('ko/editor');
var scimoz = editor.scimoz();
var message = "I have failed you, Master.";

scimoz.copyText(message.length, message);
@ervumlens

This comment has been minimized.

ervumlens commented Aug 17, 2015

The lowest I can dig here is in ScintillaGTK. The gtk_clipboard_set_can_store call "Hints that the clipboard data should be stored somewhere when the application exits...". There are conditions that reset this, as explained in the documentation.

@Naatan

This comment has been minimized.

Member

Naatan commented Aug 17, 2015

Hey ervumlens. This is a feature in Linux, not something we could (should) fix.

See for more details: https://wiki.ubuntu.com/ClipboardPersistence

@Naatan Naatan closed this Aug 17, 2015

@ervumlens

This comment has been minimized.

ervumlens commented Aug 17, 2015

Thanks for the link.

I'm more concerned about this being dropped as "works as intended" than I am about seeing a fix. I'd like to make a few points to this effect.

First, Firefox had the same defect, it was logged as a bug, and fixed as a bug. This is why Komodo's own xtk.clipboard persists data after close.

Second, Komodo is actually doing what the Ubuntu page says will produce persistence:

GTK+
Applications that use GTK+ features can provide persistence by setting set_can_store on clipboard contents whenever they gain ownership of the clipboard [or by] saving clipboard contents on quit with gtk_clipboard_store.

Komodo is calling gtk_clipboard_set_can_store. The line is there to ensure the clipboard data is persisted after close (as I mentioned above). Some other behavior is preventing that. That other behavior is the bug here.

Third, non-Komodo editors on Linux persist the clipboard data without issue. It's hard to argue that they have a bug and Komodo has a feature.

I can live without a fix, but I think it's wrong to call the behavior a feature. I hope you'll reconsider reopening this, just as a backlogged enhancement.

@Naatan

This comment has been minimized.

Member

Naatan commented Aug 18, 2015

I was not aware of this optional persistence, it bugs me that such an inconsistency exists by design. However as it does exist I'd agree that it'd be better to support persistence.

@ervumlens

This comment has been minimized.

ervumlens commented Aug 18, 2015

it bugs me that such an inconsistency exists by design.

Same here. I think it's a part of the (apparent) Linux desktop philosophy of "let's have a thousand different ways to do each thing." 😞

Thanks for reopening it, Nathan.

@Naatan

This comment has been minimized.

Member

Naatan commented Aug 18, 2015

I think it's more a case of xkcd.com/927 than anything else.

@Defman21

This comment has been minimized.

Contributor

Defman21 commented Aug 18, 2015

lol this picture is so true! 😄

@ervumlens

This comment has been minimized.

ervumlens commented Aug 18, 2015

Ha, that's it.

@Defman21

This comment has been minimized.

Contributor

Defman21 commented Oct 15, 2016

I'm able to reproduce it. Copied qwerty from the scintilla view, closed Komodo and I'm not able to paste it anywhere.

Gonna try building Komodo myself to see if the change was backported to the IDE and there's a build for it.

@Defman21

This comment has been minimized.

Contributor

Defman21 commented Oct 15, 2016

Works fine for me when I'm using my own build (Komodo Edit).

@mitchell-as

This comment has been minimized.

Member

mitchell-as commented Oct 18, 2016

Yeah, you'll have to build yourself since we haven't done a nightly yet.

Naatan added a commit that referenced this issue Nov 8, 2016

fix: Linux: editor: Persist editor clipboard contents on Komodo exit -
…fixes #534

Any text copied in Mozilla widgets is fine. It's just Scintilla's copied text
that remained unpersisted.

rn=

(integrated from the KomodoIDE master branch change 69fdfde by Mitchell <mitchellb@activestate.com>)

Komodo/KomodoIDE@69fdfde
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment