Version: 0.9.7 (using KDE 3.5.10) OS: Linux Installed from: Ubuntu Packages Klipper is one of my most used utilities, but it fills up quickly and sorting through it for a specific entry can be time consuming. The search feature is nice, but duplicate entries can make it less practical. If it removed duplicate entries, it would make searching faster/easier, and there would be less 'trash' in Klipper's History, allowing it to retain more useful entries longer before they are removed due to History size limits. This removal of duplicate entries could be upon machine start, or shut down, or via a menu selection/button, set for a specific time, or some other option/setting, if a real-time comparison and removal would be too cumbersome or CPU intensive. Personal preference, but if this is implemented, I would rather old entries be removed, leaving the newer ones closer to the beginning of displayed history, but perhaps this too could be a selectable option. Right now, Klipper is pretty much All or Nothing. It would be nice if I could arrow to an entry and delete entries I know I will not want/need in the future. Thank you for taking the time to read this! Erica
Hi, Erica! You're talking about the situation when you copy "something", then copy "somethinng else" and then again copy "something", right? So you end up with two "something"'s :) Just to make it clear for me. I'm also interested in a use case. I.e. what data do you copy to get that much of duplicates? What is the workflow?
Dimitry, I have Klipper set up to retain both items that I have highlighted and then selected Copy, as well as items I simply highlighted. I actively/consciously use the fact that in essence, Linux allows me to have two items in the clipboard that are accessible through mouse clicks, meaning either middle-button paste (for highlighted only items) or right click, select paste (for highlighted and selected copy items.) However there are times when I find myself shuffling more than just two large segments of text around, while editing a document, so invariably one or more segments will be sent to Klipper more than one time. Of course now that I am putting it in words, it does seem to be an inefficient use of Klipper. I should just send all of the segments to Klipper and then go to Klipper when I need each segment. I wonder if I have some sort of mental hang up about keeping my mouse pointer in the working space. lol Other times of multiple entries usually revolve around error messages, where I find myself opening multiple Google searches to try to track down information and solutions when I am unable to get Linux to do what I think it should be able to do. In the course of following one possibly related set of circumstances, only to figure out that it is not the same problem, it gives me leads on another search. It is quicker just to re-copy the error message off of the page I am reading to paste into Google, than it is to copy it from Klipper. The difference being: move the mouse a couple of inches, click-hold left mouse button, drag to highlight, versus move the mouse to the bottom right of the screen, click to open Klipper, visually search for the entry, move the mouse over it, click to select it. But yes, it is a situation of copying object-A, then object-B, then object-C, then object-A again. I admit, I do get lazy about typing/retyping things, so there are many easy-to-type one word entries in Klipper (hence my suggestion about allowing us to edit what has been saved in Klipper's History) but most of the time I am using Klipper for either large blocks of text, or error messages, where I want the exact use of spaces, punctuation, capitalization to be captured in Klipper, or hard to remember package names+version numbers, or complex commands... things that do not lend themselves to being easily retyped from memory.
This is actually a regression in the porting to 4.0. Klipper should remove duplicate entries, but somehow a string compare become a pointer compare.
I have a fix for this in my local git. I want to test some more before pushing it, though. Good chances of it getting in before 4.4
SVN commit 1055586 by esben: Switch history to a doubled intrusively linked hashmap instead of a QList, using sha1 hash'es as key. BUG: 189242 M +99 -46 history.cpp M +28 -29 history.h M +12 -1 historyimageitem.cpp M +30 -1 historyitem.cpp M +36 -1 historyitem.h M +2 -1 historystringitem.cpp M +17 -1 historyurlitem.cpp M +20 -16 klipper.cpp M +20 -19 popupproxy.cpp M +1 -2 popupproxy.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1055586