Clearing clipboard dysfunctional

[pmattern]

Clearing the clipboard history by clicking "Clear clipboard history" in Qlipper's context menu is valid for the current session only. All content gets restored the next session.
Topic "Clear Items on Exit" in the configuration dialogue doesn't seem to have any effect at all.

Seen on Arch Linux x86_64 or i686 running Qlipper 8bf53a8 and LXQt from recent VCS checkouts as well as on Debian testing x86_64 using the official repositories only.

[palinek]

As with regular use everything is working correctly... I believe this report is connected to the testing procedure and the logic of saving data to file (items are flushed to disk on (correct) application end and after clipboard change).

Are you testing with exiting the application by the context menu? If yes, everything should work as expected. But if the application is shut down by sending (unix) signal, then it is not ended gracefully.

[palinek]

@pmattern Please, check if the #43 makes any difference...

[pmattern]

When Qlipper is terminated by clicking "Quit" in its context menu items deleted from the clipboard are not renewed upon re-launching Qlipper running either 0862db2 or c1a901a.
When Qlipper is terminated by running kill $(pidof qlipper) items deleted from the clipboard are renewed upon re-launching Qlipper running 0862db2 but not with c1a901a.
These findings are the same in LXQt and Xfce sessions.

But when Qlipper is terminated by exiting a desktop sessions the renewal of deleted clipboard items can be seen with 0862db2 and c1a901a in LXQt sessions but with neither of both in Xfce sessions.

This makes me once again wonder whether there's something wrong with the way applications are terminated when LXQt sessions are closed.
A somewhat related finding is that both RSS Guard and Qlipper happen to crash / dump core upon closing LXQt sessions but don't in other desktop sessions. Traces from Qlipper can be found in this Gist. On the one hand these crashes seem to take place more frequently in virtual machines than on real hardware on the other hand they cannot be seen upon exiting Xfce at all.
Also, not sure to what degree this issue can be considered as fixed right now.

[palinek]

This is interesting.... it could be the way how applications are started under LXQt and Xfce.

• In LXQt: applications are started and detached (lxqt-runner, lxqt-session (autostarted app that are not lxqt modules)) -> their parent is the root process. So the session/X doesn't track started apps anyhow (the apps are segfaulting somewhere in the Qt when the X disappears).
• In Xfce: (just guessing based on the ps -efH) all (GUI) applications started by session,runner are children of either the xfce4-session or xfce4-appfinder (child of xfsettingsd). So they seem to track all the started apps and maybe send them unix signal upon the session end (the apps can quit gracefully).

[pmattern]

Interesting, indeed. Would you agree we should discuss this in an issue on its own?

[palinek]

Interesting, indeed. Would you agree we should discuss this in an issue on its own?

Of course..

[pmattern]

One thing we've forgotten a little bit is the other problem mentioned in the first comment - option "Clear Items on Exit" doesn't work as expected.
With the option checked the topic added as last comes up again when Qlipper is launched within a running session after it had been terminated by choosing "Quit" from the context menu or running kill $(pidof qlipper). Interestingly the feature does work as expected when Qlipper is terminated by closing an Xfce session it was running in (LXQt untested for the reasons discussed above).

[palinek]

With the option checked the topic added as last comes up again when Qlipper is launched within a running session after it had been terminated by choosing "Quit" from the context menu or running kill $(pidof qlipper).

This is because qlipper doesn't take ownership of the clipboard on its own. That means if you copy something to clipboard in app A, the app A is the owner of the clipboard. Qlipper just stores the values filled by app A. So if you stop qlipper, it flushes the history. But if app A is still running, the clipboard content exists on its own. Then after re-launch of qlipper it gets the current content of clipboard. <= IMO this is your scenario "added as last comes up again" and it's completely OK.

[pmattern]

The behavior is definitely inconsistent with the GUI which says "Clear Items on Exit", not "Clear Items on Exit but eventually only those which don't belong to another application that may still run."

More importantly, I was just copying some output of $ head /some/file/ from a terminal emulator so I dont' see how something like "app A" in terms of your previous comment should still have been running.

[palinek]

I was just copying some output of $ head /some/file/ from a terminal emulator so I dont' see how something like "app A" in terms of your previous comment should still have been running.

In this case app A is the terminal emulator.

I'm not a guru for the X, nor for the copy-paste behaviour/spec (https://en.wikipedia.org/wiki/X_Window_selection).

The behavior is definitely inconsistent with the GUI which says "Clear Items on Exit", not "Clear Items on Exit but eventually only those which don't belong to another application that may still run."

And what about following scenario? Qlipper isn't running. User stores something into clipboard (ctrl+c) -> the selections works normaly w/o any clipboard manager. The qlipper is started (while there is something in the clipboard). So qlipper should not care about it and begin to store the items just after something next is copied?

Basicaly, what you are suggesting is:

• either qlipper should take ownership of the clipboard (push empty value into it) while exiting (if the stated checkox is set)
• or qlipper should not store the pre-existing value of clipboard while starting

IMHO both of those is wrong, but each can be implemented relatively easy.

[palinek]

This whole issue was/is about not letting qlipper shutdown gracefully in LXQt session. After merging lxqt/lxqt-session#374 this is not the case any more.