How do I disable this clipboard. It’s recording all kinds of little information. I’m constantly clearing the clipboard and I don’t know where some of this information is coming from. It’s got a mind of its own.
I find the clipboard very very useful but you can modify its behavior via right click configure or right click in the system tray and remove it from the tray. Note I don’t think it stops it just hides it, think it is needed for any copy/paste operation.
If you turn it off in the system tray settings, it will not even be loaded, so it will be disabled completely not just hidden.
But you need to logout/login, it isn’t quit/unloaded in the running session.
think it is needed for any copy/paste operation.
No, it’s not needed for copy/paste operation. That’s provided by X11 itself.
It is needed for the selection to be remembered though.
I can understand if this was catching my copy/paste stuff. This clipboard is recording a number of things that I am typing. It even catches images. I went into the config settings and modified its settings and it continued to behave as it always has.
I’m going to cut the hot wire on this thing somehow. I just need someone to show me the wire.
No, it doesn’t record anything that you are typing, it records the things that you mark/select with the mouse and/or cut/copy.
I’m going to cut the hot wire on this thing somehow. I just need someone to show me the wire.
As mentioend, you can disable the clipboard widget in the “System Tray Settings”. Right-click on an empty space in the system tray (e.g. the up-arrow that shows the hidden icons) to reach them.
The “Ignore Images” option has been broken for some time. Bug report here: 348932 – "Ignore Images" does not... that I filed back in June 2015.
I’m going to cut the hot wire on this thing somehow. I just need someone to show me the wire.
You could delete the clipboard plasmoid… ( /usr/share/plasma/plasmoids/org.kde.plasma.clipboard/ ) but an update may install it again at a later date.
I can say right now that there were things that I had no part in by any way shape or form.
But it doesn’t matter at this point, because I was able to find the way to turn it off through your instructions
Thank you
I just tried it, and that option actually works fine in principle.
If you select some graphics in e.g. Krita and cut/copy it, klipper will only add it to its history if you turned “Ignore Images” off.
With “Ignore Images” turned on, klipper ignores clipboard data that contains graphics.
But: If you cut/copy a graphics file in e.g. dolphin, the filename is copied to the clipboard, not the actual graphics.
As this is text, klipper will accept it regardless of the “Ignore Images” option.
Maybe it should not only check the mimetype of the clipboard data, but also the mimetype of the file if it’s a filename/URL…
Btw, the KDE4 version had the same “problem” already.
The only change is that the new Plasma5 applet displays a preview of the file’s contents, while the stand-alone klipper (still) only displays the filename/URL.
You could delete the clipboard plasmoid… ( /usr/share/plasma/plasmoids/org.kde.plasma.clipboard/ ) but an update may install it again at a later date.
Why delete it, if you can just turn it off?
And that is the ‘problem’, logically (from a users pov), if the clipboard set to ignore images then one would not expect to see an image, thumbnail or otherwise appear on the clipboard.
Why delete it, if you can just turn it off?
Paranoia… 
(I’m not saying it’s so in this case as I don’t know, but sometimes ‘off’, just equates to hidden…)
But the clipboard (and klipper) doesn’t contain an image in this case, it contains a file or rather a filename/URL.
Thinking more about it, I actually don’t think it would even make sense to ignore image files when “Ignore Images” is enabled. The main purpose of this option I suppose is to prevent to get image data into klipper’s history if one only wants to paste text (and most applications probably wouldn’t accept image data anyway).
Maybe it would be better to add a separate option “Ignore Files” (or similar) though…
And the option is probably named too generic.
One could argue whether the applet should show a file preview or not (as mentioned the stand-alone klipper, that’s still included and actually shares most of the code with the applet, only shows the filename/URL), but I think it may come in handy. Maybe an option to enable/disable it might be nice, but the problem is that the config dialog is shared between the app and the applet too and I don’t think it’s even possible to show the preview in the app because of the way the GUI is designed.
OK Yes understood… But… The option that is needed is “Don’t show thumbnails for images”, or some such wording.
If I copy a file which is an image, the filename/URL appearing on the clipboard is OK, although probably unneeded. What I, and it seems others, don’t
want, is the thumbnail image generated.
Edit: Just read your edit…
Erm, this is not restricted to image files at all.
You’ll get an “image” (preview or icon) for other file types as well, e.g. if you cut/copy a text file.
And I just noticed that there seems to be no way even to enable/disable the thumbnail generation for certain file types in the applet.
TBH, I think that your bug report was too vague.
Judging from the comments, the developers seem to assume that the setting is not saved correctly on your system for some reason (which obviously is not the problem).
And that the other bug report (about the “synchronize selection and clipboard” option) has been marked as duplicate seems to confirm this.
(I think in that case it’s just a complete misunderstanding in what that option is actually supposed to do, that option works fine AFAICT)
Yeah… there’s rather a lot of vagueness here.
Maybe better off closing the original bug report and creating a new feature request.
Personally, what I’d like to see is:
-
The option to “Ignore Images / Image Files” (Meaning that nothing relating to copying images / filename/URLs will appear on the clipboard. As per your suggestion of “Ignore Files”)
-
The option to “Disable Thumbnails”
Although it’s rather a moot point as since I filed the original bug report I’ve been using the stand alone version of klipper.