Hi there,
In Klipper I was missing the feature from Ditto ( Ditto - Clipboard Manager | Ditto ) I use on Windows and namely to automatically paste the clipboard content after selecting it.
So I vibe coded it and it works. In Klipper settings you can choose if you want to have this feature enabled or not.
Please let me know if you are interested in this feature being part of the official Klipper package.
How does the “in terminals” detection work?
i would not be interested in this feature because i like to be in control of where items from my clipboard are pasted.
this would seem to be a security risk in that unintended content could escape from by clipboard (or be exfiltrated) without my awareness or intention.
—
and on a completely separate concern, i would not wish to see the inclusion of any “vibe coded” AI generated products into any official KDE packages.
if it works for you and you want to put it up as a 3rd party AI generated script or whatever then, you can let ppl choose if they want that to be part of their system or not.
The active window does already have access to the clipboard’s current data.
Essentially clicking on a different entry makes that the current one which the application can then manually paste even under normal circtumstances.
This has been a requested feature for quite some time but it will mostly depend on how this is implemented.
Some of the discussions I have seen on this topic indicate several hackish ways to do it and very few proper solutions.
You could find the feature request for this on bugs.kde.org and post the link to your repo
a window does not have the content until i choose to paste it tho, and by that point i’ve returned focus (and cursor position) to window where i intended to send the clipboard contents.
i could see a situation where focus follows mouse leading to untended consequences if clibpoard content were to leak to a window my mouse was passing over and not the intended window.
The active window is allowed to initiate the data transfer in either direction whenever it wants.
The trigger is usually a user interaction, e.g. paste keyboard shortcut, but it is ultimately up to the application on how to that.
Yes , when you switch what is “current” on the clipboard.
Transfer of focus is transfer of access permission, not which trigger the target application uses to start the transfer.
Say you copy text in KWrite and the switch focus to Konsole. Konsole has now access to the clipboard.
When you press CTRL+SHIFT+V (or use the contex menu) it retrieves the content and inserts it into the current shell.
But it could have retrieved the data the moment its window became the active one. For example for inspect if it is a compatible data type and change the visual state of its paste action accordingly.
That is indeed a tricky situation.
Luckily most software will wait for the “paste” trigger before getting the clipboard data
jebus, i had no idea.
it’s a little creepy envisioning all my windows are looking at my clipboard all the time just waiting for permission to pull it.
my mental cannon was that paste from the clipboard is supposed to just be a push operation.
so what this change would enable is all my windows would be given carte blanche permission to pull from the clipboard without any action on my part.
now i’m even MORE opposed to this feature.
I haven’t looked at the code, but all “this change” probably does is just to simulate a “Ctrl+V” keypress after you select an entry in the clipboard manager. I don’t see how it would be any different regarding permissions, since without “this change”, you are very likely to press “Ctrl+V” yourself about one second later. That’s probably why you select a clipboard entry, anyway.
Simply, it calls:
bool PasteInjector::isTerminalTarget() const
{
const KWayland::Client::PlasmaWindow *window = m_windowManagement ? m_windowManagement->activeWindow() : nullptr;
const QString appId = window ? window->appId() : QString();
const QString resourceName = window ? window->resourceName() : QString();
if (window && isShellWindow(appId)) {
qCWarning(KLIPPER_LOG) << "The active window is a shell window:" << appId;
}
const bool terminal = looksLikeTerminal(appId, resourceName);
qCDebug(KLIPPER_LOG) << "Target window:" << appId << resourceName << (terminal ? "using Shift+Insert" : "using Ctrl+V");
return terminal;
}
where the looksLikeTerminal method is:
const QStringList s_terminalSubstrings = {
QStringLiteral("alacritty"),
QStringLiteral("blackbox"),
QStringLiteral("console"), // GNOME Console
QStringLiteral("contour"),
QStringLiteral("ghostty"),
QStringLiteral("guake"),
QStringLiteral("hyper"),
QStringLiteral("kitty"),
QStringLiteral("konsole"),
QStringLiteral("lxterminal"),
QStringLiteral("mlterm"),
QStringLiteral("ptyxis"),
QStringLiteral("qterminal"),
QStringLiteral("rxvt"),
QStringLiteral("sakura"),
QStringLiteral("tabby"),
QStringLiteral("terminal"),
QStringLiteral("terminator"),
QStringLiteral("terminology"),
QStringLiteral("tilix"),
QStringLiteral("wezterm"),
QStringLiteral("xterm"),
QStringLiteral("yakuake"),
};
// Too generic to be matched as substrings, they have to equal a complete
// component of the application identifier or resource name
const QStringList s_terminalWords = {
QStringLiteral("foot"),
QStringLiteral("kgx"),
QStringLiteral("rio"),
QStringLiteral("st"),
QStringLiteral("tilda"),
QStringLiteral("warp"),
};
bool looksLikeTerminal(const QString &appId, const QString &resourceName)
{
const QString haystack = (appId + QLatin1Char(' ') + resourceName).toLower();
if (std::any_of(s_terminalSubstrings.cbegin(), s_terminalSubstrings.cend(), [&haystack](const QString &token) {
return haystack.contains(token);
})) {
return true;
}
const QStringList words = haystack.split(QRegularExpression(QStringLiteral("[^a-z0-9]")), Qt::SkipEmptyParts);
return std::any_of(s_terminalWords.cbegin(), s_terminalWords.cend(), [&words](const QString &token) {
return words.contains(token);
});
}
Only the active window. One of the advantages over X11 which had no such restrictions (any client can access the clipboard with/without window).
Fundamentally it is a transfer between two applications through a channel provided by the server. The “source” puts an offer on the clipboard, the “target” decides which format it wants the data in, the “source” starts sending it.
Clipboard managers like Klipper monitor essentially act like a backup and store a copy of the offer (or parts of it) in case the “source” vanishes.
Selecting an entry makes the clipboard manager the new “source”.
No that is already the case, see above.
i take in your point about only the active window and how it’s better under wayland, but with focus follows mouse the active window can be any window your mouse passes over for longer than the timer setting, so user intent can not be assumed by the clipboard based on that alone.
how does that square with
if the target is no longer the decider but instead we are enabling the clipboard to be both “source” and decider, then we have fundamentally changed that relationship between active window and the clipboard.
and we have changed it in a way that removes the human from the loop.
Copy & Paste is a multi-step process, a sort of handshake between to clients.
For example assume the currently active window is a web browser and the user selects part of a web page and triggers “copy”.
The browser, being the currently active window, can access the clipboard (in X11 this is internally called a selection, in Wayland it is called data device).
The can then create an offer for the data in multiple formats, e.g. “I can provide this data as HTML and plain text”.
At this point no data has necessarily been transferred anywhere.
The user switches to a different window, lets say a file manager.
The file manager is now allowed to access the clipboard.
When the user triggers “paste”, the file manager will check the offered formats.
Since a file manager will usually just create a file and dump the content into it, it will most likely pick the first format on offer, under the assumption that this is the “best” one.
It sends that as a request to the browser which will then transfer the data.
If a clipboard manager is present, this will be slightly different.
Additional to the above the clipboard manager itself will request the data in one or more formats to preserve in its history.
If the user selects an entry from the history, then the clipboard manager itself becomes the source, offering the data it has saved before.
The rest of the process plays out as before.