There's no reason to have different behaviour depending on whether the
UI is presented in an applet or not.
Details
Details
- Reviewers
- None
- Group Reviewers
Plasma - Commits
- R120:6fb7ed2384db: Register klipper DBus interface when in non-standalone mode
Looked in qdbusviewer
Diff Detail
Diff Detail
- Repository
- R120 Plasma Workspace
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
| klipper/klipper.cpp | ||
|---|---|---|
| 100 | +1 The header file says Q_CLASSINFO("D-Bus Interface", "org.kde.klipper.klipper") | |
| klipper/klipper.cpp | ||
|---|---|---|
| 100 | right, but that's different to the service name. service.name /some/path interface.name method I'm matching the service name that's in the .desktop file for standalone mode. | |
Comment Actions
There was probably a reason why I did it that way. Unfortunately I don't remember :-( The most obvious would be that the exported scriptable objects don't make sense or won't work in the non standalone mode. E.g. a slot which would crash.
Comment Actions
FWIW, judging from a quick test the patch works and the applets history can be cleared via sweeper.
In the case this causes problems, would there be another solution to clear the history?
Comment Actions
if the whole idea of this change is to support external clipboard clearing through tools like sweeper I'm strictly against it. I'm now extremely blunt: these tools are bullshit. You cannot clear a clipboard history on X11, the mere idea is ridiculous as any application can listen to clipboard changes. These tools give a wrong feeling of security and they don't understand the problem or they would not offer it at all. If there is a malicious program which reads your sensitive clipboard data, you have a problem and sweeper won't help you. If there is no such problem, then there is no real reason to clear the clipboard. And even if you want: klipper provides that in the UI.
Comment Actions
You cannot clear a clipboard history on X11
But you can clear klipper's history. As you point out yourself "klipper provides that in the UI." From our POV what does it matter if that's exposed via a button here, or elsewhere. The fact that you could have malware doesn't remove the legit reasons to talk to the clipboard manager you're running.
I have no idea how Sweeper presents their call to us in their UI - and I don't really care. If they make some outrageous claim about removing any blocking all clipboard loggers, that's clearly on them.
But clearing isn't the only thing in that interface - for me it's about KPasteTextAction in KConfigWidgets, which replaces the regular paste action with a menu of entries and stuff.
Comment Actions
which is a valid use case. Though we have to be careful here as if at some day klipper works on Wayland, we cannot have a dbus api to extract what apps are not supposed to get. Not an issue right now for this change, just something to keep in mind.
Comment Actions
But you can clear klipper's history. As you point out yourself "klipper provides that in the UI." From our POV what does it matter if that's exposed via a button here, or elsewhere. The fact that you could have malware doesn't remove the legit reasons to talk to the clipboard manager you're running.
+1
I'd also consider it a valid use case to hide the clipboard history from an human observer, e.g. a bystander behind your shoulder, or a friend you give your laptop for a quick task.
I have no idea how Sweeper presents their call to us in their UI - and I don't really care. If they make some outrageous claim about removing any blocking all clipboard loggers, that's clearly on them.
It offers to clear "Saved Clipboard Contents" with "Clears the clipboard contents stored by Klipper" as description, which is IMHO quite a solid claim.