Skip to content
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

[Regression] Copy entry does not seem to copy anything on the clipboard #56

Open
gpoo opened this issue Sep 26, 2020 · 9 comments
Open
Labels

Comments

@gpoo
Copy link
Contributor

gpoo commented Sep 26, 2020

Overview

PyGObject does not suspport Gtk.Clipboard.set_with_data due
to a limitation in introspecting with more than one callback.

That was the method used with Gtk2, but with the new port does not
work.

Although, the statusbar says the entry was copied, the clipboard looks
unchanged.

Steps to Reproduce

  1. Open Revelation with a file of keys
  2. Select an entry
  3. Select Copy or press Ctrl+C

Expected Behavior

The clipboard should contain a text representation of the entry

Actual Behavior

The clipboard does not seem to hold anything.

Context

Revelation - 0.5.3
Operating System: Ubuntu 20.04
Desktop Env: Gnome
Windowing System: Wayland

@gpoo gpoo added the bug label Sep 26, 2020
@gbm19
Copy link
Contributor

gbm19 commented Sep 26, 2020

Entry "Drag and Drop" and Copy/Paste use a special clipboard: EntryClipboard (revelation.py:331, data.py:146).
The contents of that special clipboard is only available in the EntryTree widget but it can handle copy/paste between different revelation instances, even if some are pygtk2 and the other pygtk3.
The behavior described here (#56) was already so in pygtk2 version 0.4.14.

@gpoo
Copy link
Contributor Author

gpoo commented Sep 26, 2020

It does not seem to handle it in the same instance, for example, if I want to use one as a template of a new one.

@gbm19
Copy link
Contributor

gbm19 commented Sep 26, 2020

Sometimes (not always) for Paste to work, you have to be sure that EntryTree widget got the focus by pressing Mouse Left button on the empty space in the EntryTree widget.

@gpoo
Copy link
Contributor Author

gpoo commented Sep 30, 2020

Sometimes (not always) for Paste to work, you have to be sure that EntryTree widget got the focus by pressing Mouse Left button on the empty space in the EntryTree widget.

I tried the following steps in both Revelation 0.4.14 and master:

  1. Create a new folder: Foo
  2. Create a new entry: Foo.
  3. Right after pressing the button Add entry, I press Ctrl+C
  4. Press Ctrl+V

In Revelation 0.4.14 the got a duplicated entry under the current one. The status bar shows Entries copied and later Entries pasted.

In Revelation master I only get the status bar Entries copied.

Both of them on a Wayland session. Gnome 3.36.3 (Ubuntu 20.04).

@gbm19
Copy link
Contributor

gbm19 commented Oct 1, 2020

I am afraid this is a problem/feature of Wayland.

According to https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection:
"X has a generic selection mechanism which lets application own arbitrary selections and exchange data via them."
"The original Wayland protocol very intentionally supports only a single clipboard, which corresponds to the CLIPBOARD selection under X and works for explicit copy-paste"

And from https://wiki.archlinux.org/index.php/wayland
"GTK 3 The gtk3 package has the Wayland backend enabled.
GTK will default to the Wayland backend, but it is possible to override it to Xwayland by modifying an environment variable: GDK_BACKEND=x11"

Thus, until a better workaround is found, to get copy/paste working on entries you have to set GDK_BACKEND=x11 before running revelation

Can you please confirm that with GDK_BACKEND=x11 copy/paste in revelation works as expected?

@mikelolasagasti
Copy link
Owner

With GDK_BACKEND=x11 revelation I'm able to cut/copy & paste.

@gpoo
Copy link
Contributor Author

gpoo commented Oct 2, 2020

Why cannot we use the same clipboard? or in other words, why do we need to different clipboards: default and custom one?

Although the sentence quote there, I think is more related to having PRIMARY and CLIPBOARD, where PRIMARY is what the user gets when storing something just by selecting a text. It may be coincidence.

@gbm19
Copy link
Contributor

gbm19 commented Oct 2, 2020

I don't know for sure, but I guess it is for security reasons.
When using the CLIPBOARD selection, complete details of your copied/cut entries are available to any program running in your system.
By using a custom clipboard, with a name that you can change (src/lib/data.py:152), that data is only available to revelation instances.

@gpoo
Copy link
Contributor Author

gpoo commented Oct 2, 2020

I don't know for sure, but I guess it is for security reasons.

We may need to check the logs, or ChangeLog to check if that was the rationale. It could also be that the data copied has a special format.

When using the CLIPBOARD selection, complete details of your copied/cut entries are available to any program running in your system.
By using a custom clipboard, with a name that you can change (src/lib/data.py:152), that data is only available to revelation instances.

Or any application that "listens" to that clipboard. That said, when we copy the password, we make it available to every application.

Anyhow, the use case is to duplicate an entry. We can provide just that, duplicating the entry underneath the current one. Later the use can move it. Or, we can offer “Duplicate to…”, to duplicate the entry in a different folder.

Later we can duplicate to another instance via a D-Bus.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants