Hi. In Wayland, (among others) I like the approach to security. I initially evaluated Gnome 3 + Wayland years ago when I started to be available in Fedora, however I had some general problems at that time. I come back to it regularly and at the time being, there is only blocker for me to switch permanently - a problem with multi-element clipboard manager (which I am addicted to). As I might miss something obvious, I write here to ask if my (simple) use case can be somehow realized in Wayland.
Btw, if you think, I should ask about that in some other place, please let me know!
My simple use case.
I can copy text in a regular way (CTRL-C or right click and copy).
I can use a keyboard shortcut (e.g. CTRL-Meta-V, preferably used defined) to display a list of X recently copied values, select one with ↓/↑ and press Enter to paste that chosen value.
With X server, I use clipit, but under Wayland it has a problem (among others) with binding own keyboard shortcuts (they are ignored). I tried, some other clipboard managers, but they state to do not support Wayland at all or only partially (usually there is a problem with the shortcuts or reading values copied in Wayland-native apps)…
I know about wl-clipboard, however, Mutter doesn’t support (and doesn’t seem to want to support) the wlroots data-control protocol. Mutter has some internal clipboard manager, but I wasn’t able to find information if it supports the in-memory list of old entries and how to manage it.
Question: How can I achieve the multi-element clipboard manager functionality in Gnome 3/Gnome Shell/Mutter?
Thanks Andy! I didn’t know that extension. I gave it a try and in general, it fulfills my requirements, nice.
There is just one somehow problematic case I spotted - when the in-memory mode is used (I don’t like to keep my passwords on disk), the entries are removed every time Gnome Shell is (un)locked - as the extensions seems to be killed/unloaded and instantiated/loaded again.
Unfortunately, the same as the plugin developers, I don’t see a good solution for that. The extension lifecycle is bound to Gnome Shell and some external mechanism to keep secrets would have to be used, which can impact security (extension cannot keep any “key to unlock” as it is being restarted constantly. Writing any custom extension would have similar problem and as I understood, it is problematic to hook to the clipboard being a standalone app :-(.
Nevertheless, it’s just one issue and in general I like the extension. Thanks for your suggestion!
I’m not really sure I see the difficulty with this problem? Just keep clipboard entries in a Map in the top level of a script or some other persistent scope and it will not be cleared when the screen locks/unlocks.
I’m completely not familiar with programming Gnome Shell extensions. Could you, by any chance, provide a link to some documentation or even better to an existing extension, so I could forward it to the Clipboard indicator developers to as an alternative solution?
There is some documentation on the GNOME Wiki for creating extensions and API documentation at https://gjs-docs.gnome.org. This isn’t particular to GNOME Shell extensions at all though; it’s just a matter of scope and not clearing whatever container type is used to store the history items:
// You could use a Map, Object, Set or Array; whichever suits the use-case best
const ClipboardHistory = new Map();
function init() {
}
function enable() {
// Setup for extension
// Add/remove item history
ClipboardHistory.set('history-item-id', 'clipboard content');
ClipboardHistory.delete('history-item-id');
}
function disable() {
// Teardown for extension
}
I didn’t know that global variables are kept across (un)locks, but - with a help of the suggested video tutorial (nice!) - I did a small PoC and it worked fine. I suggested it in the corresponding issue and I hope the developers will find it useful to fix the aforementioned problem. Thanks again!
Hmm, Discourse doesn’t allow me to post the link to GitHub… (please fix it manually)
https:// GH /Tudmotu/gnome-shell-extension-clipboard-indicator/issues/91#issuecomment-716144130
Update. After 30 minutes I retried and the link was successfully saved.
