Chrome generates duplicates in history, despite smart_update
glubsy opened this issue · 6 comments
The smart_update is not very reliable, when selecting text fast, it doesn't kick in and lets a lot of "incomplete" duplicate populate the history.
text = safe_decode(text)
if not self.config.getboolean('clipster', 'duplicates'):
self.remove_history(board, text)
diff = self.config.getint('clipster', 'smart_update')
try:
last_item = self.boards[board][-1]
except IndexError:
# List was empty
last_item = ''
# Check for growing or shrinking, but ignore duplicates
if last_item and text != last_item and (text in last_item or last_item in text):
# Make length difference a positive number before comparing
if abs(len(text) - len(last_item)) <= diff:
logging.debug("smart-update: removing.")
# new selection is a longer/shorter version of previous
self.boards[board].pop()Why is diff compared here? Its value is supposed to be 1 here, how is that supposed to be efficient?
text will most likely be longer than last_item (at least when doing a selection from left to right), and there is a high chance the abs difference will yield something bigger than 1. Am I missing something?
Anyway, why is the history populating when "copy" is not even clicked on (in Chrome, after right-clicking)? Shouldn't it only populate when the clipboard is actually being updated? (the CLIPBOARD clipboard, not the PRIMARY clipboard if I understand right...)
It seems Clipster is emulating the "copy-on-selecting" from Linux in Chrome, which causes it to update the PRIMARY clipboard all the time... but then why is the CLIPBOARD clipboard updated as well?
Nice program, thanks for sharing. I'm interested because I'm trying to make a python script run automatically when the clipboard is updated. Clipster would be a nice module to use in other programs.
Nevermind, I missed the fact that diff can be set to a bigger value.
The issue is still valid though, Chrome really populates the history (and the PRIMARY clipboard) like crazy.
I'm still a bit puzzled by the two clipboards (as usual hehe, who isn't?) and the way they populate / populate clipster's history as well. But I guess setting the default_selection = CLIPBOARD as well as active_selections = CLIPBOARD should work well enough (like Clipit).
Also, nevermind, I was running Clipit at the same time, so it added to the confusing clipboard mess.
Sorry if I sound super confused, I'm trying to figure out how to hack this thing for my project. 😅
Hi - thanks for the bug report. Yes, it does appear that fast selecting breaks the smart-update - I'm pretty sure this is new, and didn't used to happen.
The code tries to ignore all clipboard changes while the mouse button is held down, and only read the clipboard state once when released. This was always done through a bit of a hack, and the code has a comment to this effect:
# FIXME: this devs hack is a bit verbose. Look instead at
# gdk_seat_get_pointer -> gdk_device_get_state
# once GdkSeat is in stable
It looks like GdkSeat might now be stable and available in gtk on most OSes now, so I'll have to take a look at replacing the mouse button code with these new methods. I'm not 100% sure that will solve this problem, but it is the most likely cause of the issue!
Hi,
Sorry for the delay in coming back to review this bug - it's taken until now for me to get to a server running gtk >3.20 (when the GtkSeat and pointer code was overhauled).
I've updated the mouse button detection code using the newly available methods - this is committed to the gtk_3.20 branch. Hopefully this will solve the issue (I've tried repeating what I think triggered it before - rapidly changing the selection - and it doesn't seem to 'misfire' any more).
If you could try running clipster from this branch and letting me know if you're still seeing the problem that would be great (obviously only if you're using an OS with gtk 3.20 or greater!)
Thanks! Tried it for a few minutes and it seems to be working perfectly fine on my end.
Running Arch Linux with gtk 3.22.
that's good to hear - I'll leave this open for bit longer as other people might want to comment - but otherwise I'll look to push this change as a new master release - will probably have to be a 2.x release due to the Gtk versioning bump!