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.
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 set_text( ) and gtk_clipboard_ clear() happens which
Xlib selection API is asynchronous, it has to be asynchronous in
GTK+ too. And perhaps, some interference between
gtk_clipboard_
causes X application to keep its selection, which is then echoes
back into clipman.