Steps for 1 item in the history =============================== Say the clipboard is empty. 1) Copy with "Ctrl+C" some text from any software (for example gedit). There's now 1 item in the clipboard history. 2) Click on the clipman icon on the panel and choose "Clear". Result: the item is not cleared, so there's still 1 item in the history. 3) Click again on the clipman icon on the panel and choose "Clear". Result: the history is now cleared. No item remains. Steps for several items in the history ====================================== Say the clipboard is empty. 1) Copy with "Ctrl+C" some text from any software (for example gedit). There's now 1 item in the clipboard history. 2) Copy again with "Ctrl+C" some text. There's now 2 items in the history. 3) Copy again with "Ctrl+C" some text. There's now 3 items in the history. 4) Click on the clipman icon on the panel and choose "Clear". Result: the first two items are cleared, but the last one remains, so there's still 1 item in the history. 5) Click again on the clipman icon on the panel and choose "Clear". Result: the history is now cleared. No item remains. More information ================ - xfce4-clipman-plugin 1.2.6 - In the preferences, I checked "Store last copied image", "Ignore selections" and "Reorder history items". All other checkboxes are unchecked. I also have "Size of the history: 10" and "Paste instantly: None". - Xubuntu 14.10 Beta 1 (64-bit) - Note that I didn't have this bug with xfce4-clipman-plugin 1.2.5 on Xubuntu 14.04.
I can't reproduce the bug since a recent update.
Actually, it's still reproducible. I reopen the report.
I am consistently having this issue on xubuntu 14.04 and clipman 1.2.5 on my desktop/workstation. The only comment to add is that after about 1 hour of copying something, I don't need to do the double clear. On this same system (before I upgraded to xubuntu 14.04) when running xubuntu 13.04, I almost always could never get the last clipboard item to clear. Before I was running xubuntu 13.04 (don't remember what that previous version was), I didn't have this problem much. I'm not sure if there could be some other program interacting with the clipboard that is triggering this to happen. This system was originally installed as ubuntu, but I switched it over to xubuntu after unity came out and I think I've removed most gnome and unity desktop packages by now. On my laptop, which also has xubuntu 14.04 and clipman 1.2.5 I have never had this problem once. This system had a fresh install of xubuntu 14.04 .
It looks like I just fixed this for my setup... I *think* I first noticed it after upgrading Fedora 23 to Fedora 24 using 'dnf system-upgrade', but there is a chance that it was already happening without my having noticed it. System is a fully updated Fedora 24 that was a fresh install of F21 but has been upgraded without any skips to the current 24. My fix: 1. Add a second copy of Clipman to the panel. 2. Test by adding a few items and confirm that they show in both old and new instance. 3. Clean using the new instance and then notice that all items were cleared from it. 4. Also notice that the first instance did not have those same items cleared. 5. Removed the first instance and move the new one into that position. 6. Confirm that a single clear now works as expected. I will return and update if the issue returns; but note that I have not rebooted yet to give it a proper test.
I tried what you have said, but I cannot add two instances of clipman to the panel. If I already have one in there, then the clipman is greyed out in the "Add New Items" window and if I try to drag it to the panel anyway, it just drags an X icon and then disappears when I leg go of the mouse button. I am using Ubuntu 14.04.4
Andy: Have you tried to see if you can remove and reinstall clipman from the panel?
I can remove and then re-add clipman from the panel, but never add a second one without removing the first. Removing and re-adding does not fix the problem.
Could you try 1.4.0 and see whether you can reproduce the problem?
Hi. I see this behavior too, with both 1.4.0 and latest version from git repository. But only sometimes. I tried to add printf-like tracing to figure out what happens. And it looks like clear command does what it should, it clears list. But then "owner-changed" signal is triggered. It then causes clipman to read data from clipboard and insert it into the history. I don't have detailed understanding of what happens, but since Xlib selection API is asynchronous, it has to be asynchronous in GTK+ too. And perhaps, some interference between gtk_clipboard_set_text() and gtk_clipboard_clear() happens which causes X application to keep its selection, which is then echoes back into clipman.
Created attachment 6894 Avoid calling gtk_clipboard_clear() I think there is no sense in calling gtk_clipboard_clear() after gtk_clipboard_set_text(). Latter makes a copy of data, and sets required reply callback, so other applications will get an empty string which is fine. Calling _clear() makes GTK+ to call XSetSelectionOwner() with owner=None, which may cause change of selection owner with "strikeback" effect. Also passing length of 1 looks wrong. String is empty, so its length should be 0. Luckily, GTK+ uses g_strndup() inside, which makes it an empty string rather than a string of one '\0'. This patch fixes issue for me. I could reproduce it before the patch, and can't reproduce after.
@Rinat: Hey this sounds plausible and your patch seems very straightforward. However I'd like to be able to reproduce this in order to verify the patch before pushing it into the next release. Can you give some instructions as to how to get to this erroneous behavior?
(In reply to Simon Steinbeiss from comment #11) > Can you give some instructions as to how to get to this erroneous behavior? It's irregular. At the moment, I can open text editor (Geany in my case), make some random keystrokes, then copy text multiple times. Select, Ctrl-C, select another, Ctrl-C. Then click on clipman icon (I use systray version), select "clear history". It makes all item except one disappear. After I click "clear history" second time, that last item disappears too. But half an hour ago I did the same steps, and history was cleared at a heat.
(In reply to Simon Steinbeiss from comment #11) I've got an idea. Since I believe the issue is kind of race condition, it's worth to try to add delays to make it apparent. For example, to insert "sleep(1)" at the end of cb_clear_history().
@Rinat: Ok, let us know how it goes! Sorry that I haven't found the time to reproduce the issue so far.
(In reply to Simon Steinbeiss from comment #14) > @Rinat: Ok, let us know how it goes! Sorry that I haven't found the time to > reproduce the issue so far. Actually, this was supposed for you to try :-) You said earlier that you need a way to reproduce the issue to make sure that proposed patch actually fixes it. So that's what I came up with, delays. I have no problems reproducing issue on my machine lately, so can't tell whenever it helps to reveal it or not. I thought it's easier to add a "sleep(1);" line manually than to apply patch. But anyway, here it is: ------------ diff --git a/panel-plugin/menu.c b/panel-plugin/menu.c index 0f24fa7..d682a6a 100644 --- a/panel-plugin/menu.c +++ b/panel-plugin/menu.c @@ -264,6 +264,7 @@ cb_clear_history (ClipmanMenu *menu) clipboard = gtk_clipboard_get (GDK_SELECTION_PRIMARY); gtk_clipboard_set_text (clipboard, "", 1); gtk_clipboard_clear (clipboard); + sleep(1); } /* ------------
Sorry for the misunderstanding, of course I could've added the sleep myself. I thought you wanted to find a sleep that makes this more reproducible. I've now cleared my history for about 10 minutes and it always worked (with the panel plugin though)...
Today I tried one more time. And now can't reproduce it, with or without added "sleep(1);". So, that method doesn't work. I doubt I'll be able to find another way, but I'll try.
I'm wondering if the problem described here appears if the mouse selection is also stored in the history (uncheck "Ignore mouse selections" in the history tab in 1.6.x).
Currently (1.6.1) if "Remember history" was on, and you enter settings and switch it to off, then [Close], the file in which history is stored ie. ~/.cache/xfce4/clipman/textsrc remains intact until the next time something is copied into clipboard. Similarly if the setting is turned on, the file is created only next time something is copied. (just pasting without copying first, has no effect on the file)
I guess the history could be cleared/stored upon changing that setting, but that's really not the problem originally described in this bugreport.
(In reply to Simon Steinbeiss from comment #20) > but > that's really not the problem originally described in this bugreport. oh crp, you're right! forget I said anything. Sorry for the noise.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/panel-plugins/xfce4-clipman-plugin/-/issues/4. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev