clipboard cleared on exit on linux but not windows

[tedbr...@gmail.com]

Is there a way to retain the clipboard contents after
one exits a tcl/tk program (using wish) on linux. I'm running
a pop-os linux under vmware, if that makes any difference.

On windows, the clipboard text remains available for other
programs incl. other tcl/tk programs even after the
program that did [clipboard append] exits.

[Francois Vogel]

Some pointers:

https://core.tcl-lang.org/tk/tktview?name=c947c77eef
https://core.tcl-lang.org/tk/tktview/73ba07efcd3834adcebe

Basically, I believe on linux you need a clipboard manager to handle this.
Presence of such a beast is outside the control of Tk, but you can check
whether it's here or not, we do this in the test suite to avoid failrues
in case there is none:

https://core.tcl-lang.org/tk/artifact/0073c77b3cc77519?ln=20,25

Regards,
Francois

[Rich]

tedbr...@gmail.com wrote:
> Is there a way to retain the clipboard contents after
> one exits a tcl/tk program (using wish) on linux.

> On windows, the clipboard text remains available for other programs
> incl. other tcl/tk programs even after the program that did
> [clipboard append] exits.

See Francois' response for some links.

Short answer: no.

Longer answer: no, not in any way that you or the Tk maintainer's can
do anything about. The clipboard under X is built in a client/server
manner that requires a running program to be the 'source' for another
program to 'paste'. There is no "storage" anywhere for the contents to
remain after the 'source' program exits.

The windows clipboard is built differently, there is no client/server,
and the contents remain around after the 'source' exits because the
'copy to clipboard' action actively causes win to store the 'thing'
copied out. A paste into another program is then just copying from
this global windows storage area into the destination program.

> I'm running a pop-os linux under vmware, if that makes any
> difference.

None at all. The only thing that /might/ make a difference is a
Wayland server system, and only then if Wayland builds the clipboard
interface to work in a windows like manner. I do not know enough about
Wayland to make any guesses there.

Possible solutions for you under linux include, among others, the
'xclipboard' and 'xcutsel' programs (there are others, look for
xwindows clipboard managers). These work by becoming the 'global
shared storage' location, so the 'source' can exit, while what it
'copied' remains stored in one of these deamons.

[tedbr...@gmail.com]

On Thursday, December 26, 2019 at 4:02:42 PM UTC-8, Francois Vogel wrote:


> https://core.tcl-lang.org/tk/tktview?name=c947c77eef
> https://core.tcl-lang.org/tk/tktview/73ba07efcd3834adcebe
>
> Basically, I believe on linux you need a clipboard manager to handle this.

Thanks for the detailed reply.

I'm running gnome and the command as described in the link reports:

% selection get -selection CLIPBOARD_MANAGER -type TARGETS
TARGETS TIMESTAMP SAVE_TARGETS

This would appear to indicate that I've got a manager present. So, not
sure then why it's still not preserving the clipboard.

I wonder why it's only tcl/tk (wish) that clears the clipboard
on exit. I've tested this with several other programs, such as
gedit, terminal, and even a windows wine program.exe and
none of these have this behavior. What do they know that wish
doesn't?

The only time the clipboard is getting cleared is when a wish script
does a copy and then exits. If it merely pastes, then it leaves the
clipboard intact.

I see that both the tickets mentioned are now closed. But I couldn't
tell if the problem is believed to be resolved.

[Francois Vogel]

On 27/12/2019 13:04, tedbr...@gmail.com wrote:
>I wonder why it's only tcl/tk (wish) that clears the clipboard
>on exit. I've tested this with several other programs, such as
>gedit, terminal, and even a windows wine program.exe and
>none of these have this behavior. What do they know that wish
>doesn't?

There may well be outstanding issues.
There are several tickets in the Tk repository that tell a similar story as
you do, just search for the word 'clipboard' in the list of currently open
tickets:

https://core.tcl-lang.org/tk/rptview?rn=2

Most of these tickets look either outdated however, or do not contain
sufficient info to reproduce.

>The only time the clipboard is getting cleared is when a wish script
>does a copy and then exits. If it merely pastes, then it leaves the
>clipboard intact.

Thus behavior on paste looks ok to me. Pasting in wish should not result in
clearing the clipboard.

Francois

[tedbr...@gmail.com]

On Friday, December 27, 2019 at 5:31:34 AM UTC-8, Francois Vogel wrote:
> Most of these tickets look either outdated however, or do not contain
> sufficient info to reproduce.
>

Are you saying this is not reproducible by others? I have no
difficulty reproducing this.

A data point in my tests might be relevant:

I can copy from wish and then paste into a bash terminal window
multiple times – up until the wish program exits. Then
the bash window can no longer paste, and it's right-click
menu shows the paste option as disabled at (what would seem to be)
the very moment that the wish program exited, but not before that.

That suggests 2 possibilities. 1) wish is deliberately clearing
the clipboard on exit (conditional on there having been a copy
operation at some point in the run) or 2) the system itself is
doing the clearing, say, during some resource cleanup, perhaps
triggered by some channel still open when the process exits.

To test case 1, I tried to kill the wish process, in hopes
that I could get the process to end w/o having had a chance to
clear the clipboard. I was not able to do that.

I suspect all the ways I tried (control-c, kill from system monitor,
xkill from another bash window) might amount to the same thing,
and all allow for a “last chance” exit handler, run off of some signal
catch. My linux knowledge is lacking here however.

But the simpler case, that wish is just deliberately clearing the clipboard
should be easy to spot in the code if indeed that is what's happening here.
If that's the case, then it might just be a simple fix after all, assuming
everyone agrees it shouldn't be clearing the clipboard at exit.

[Rich]

tedbr...@gmail.com wrote:
> That suggests 2 possibilities. 1) wish is deliberately clearing
> the clipboard on exit (conditional on there having been a copy
> operation at some point in the run) or 2) the system itself is
> doing the clearing, say, during some resource cleanup, perhaps
> triggered by some channel still open when the process exits.

Under X11 there is no "clipboard" to clear. X11 has no centeral
storage called 'the clipboard'. Copy/paste between applications is
built by having the source and destination communicate directly over
the X11 server for data transfer from the source to the destination. A
'copy' operation, from the X11 viewpoint, is merely some program
announcing "I have data available for transfer". The transfer does not
actually occur until some other program sends that first one a message
that essentially says: "transfer the data you have to me now".

But there is no central clipboard "storage" area holding anything [1]. All
of it is implemented as direct message communication between the source
and destination programs. When the source exits, there is no longer
any program announcing "I have data available from a copy command" (at
least until some other program is asked to perform a "copy"), so there
is nothing for any other program to ask to receive.

The flow is this:

1) wish asserts "clipboard ownership" within the X11 server upon you
performing a "copy" command

2) the terminal program in which bash is running (xterm, rxvt,
gnometerminal, etc.), when you ask it to "paste" looks up in the X11
server to find out who "owns" the clipboard at the present time

3) the terminal program sends wish a message stating: "send me the data
you have selected for the clipboard"

4) wish receives the message, packages up the data, and sends the data
back

5) the terminal program receives the reply message, and inserts the
data into the pty that bash is listening on, and draws the relevant
font glyphs on the screen to show the pasted result

Once the process (wish) which had ownership exits, there is no longer a
'source' to contact to ask for the clipboard contents.


[1] This is how the X11 server handles things, and is the default way
that it is handled. But, if one runs a clipboard manager such as
xclipboard, then the flow is changed. The flow with a clipboard
manager is that the clipboard manager sees some program taking
ownership of the clipboard, and it immedately jumps in, asks for the
data contents via the same message protocol, holds onto a copy of the
data, and immedately, itself, asserts that it is now the "clipboard
owner". When this happens, the data has already been transferred out
of the wish process and another process (not 'wish') is asserting
'ownership', so any pastes occur by the destination asking that other
process for the data (i.e., the terminal asking xclipboard for a copy
of the contents it is holding).

[tedbr...@gmail.com]

On Friday, December 27, 2019 at 10:04:07 AM UTC-8, Rich wrote:

> Under X11 there is no "clipboard" to clear. X11 has no centeral
> storage called 'the clipboard'.

> But, if one runs a clipboard manager such as
> xclipboard, then the flow is changed.

In this case is there a process running, in the background
that I can look for? Something that say, ps -a might find?

Since I can close all the terminal, gedit, etc. windows and
then launch a new terminal and still do a paste says there has to
be something saving that "clipboard" data somewhere.

My pop-os system is pretty much out of the box. I didn't
install any clipboard manager that I'm aware of. However,
that line of code did indicate something is running.

selection get -selection CLIPBOARD_MANAGER -type TARGETS

And if there is in fact some manager running, AND, wish can
tell it's there, then shouldn't it be able to do whatever
all the other programs seem able to do that preserves the
ability to paste even though all the foreground programs have
exited and restarted.

[tedbr...@gmail.com]

On Friday, December 27, 2019 at 10:26:15 AM UTC-8, tedbr...@gmail.com wrote:

> In this case is there a process running, in the background
> that I can look for? Something that say, ps -a might find?

Ok, found it, gsd-clipboard. And it's tenacious, killing it off
and it just restarts.

So, I guess the remaining question is how do these other
programs work differently than wish, and is it something
that tcl/tk should be doing as well?

[briang]

On Friday, December 27, 2019 at 10:26:15 AM UTC-8, tedbr...@gmail.com wrote:

So far all the posts have been technically correct, but terribly misleading. There is no "clipboard" in X11. There is only global selection. Across all windows in all application running on a given X server DISPLAY, there is a single selection owner. The act of "paste"ing is actually a "get" from the owner of the global selection. The mechanism is completely orthogonal to the notion of a "clipboard". Windows OS only has the notion of clipboard. It has no notion of "global selection".

To be clear here, X11 - Global Selection. Windows - Clipboard. Two different and orthogonal mechanism for accomplishing the same task.

Tk supports both systems via the [selection] and [clipboard] commands. These independent systems are not connected to each other unless there is code written to do so. Once you set this concept in you head, then all this conflated and confusing behavior should become crystal clear.

Before proceeding any further you'll have to go back and determine what a menu pick "Paste" is actually doing in the Tk application? What is Control-V actually executing? What is the Button-3 actually executing?

As always, read the man pages for [selection] and [clipboard]. Also pay attention to the -exportselection property on all Tk widgets that have selection.

-Brian

[Rich]

tedbr...@gmail.com wrote:
> On Friday, December 27, 2019 at 10:04:07 AM UTC-8, Rich wrote:
>
>> Under X11 there is no "clipboard" to clear. X11 has no centeral
>> storage called 'the clipboard'.
>
>> But, if one runs a clipboard manager such as
>> xclipboard, then the flow is changed.
>
> In this case is there a process running, in the background
> that I can look for? Something that say, ps -a might find?

Besides the standard two that ship as part of X11R6 (xclipboard and
xcutsel) there are probably as many 'managers' as their are desktop
environments, so the answer here is likely "yes" [1], but I do not know
what process name to tell you to look for.

> Since I can close all the terminal, gedit, etc. windows and
> then launch a new terminal and still do a paste says there has to
> be something saving that "clipboard" data somewhere.

Yes, that would indicate some form of clipboard manager running
somewhere, unless you are 1) running wayland and 2) wayland operates
its clipboard in a windows fashion (and on point 2 I don't know how
wayland handles the clipboard).

> My pop-os system is pretty much out of the box. I didn't install any
> clipboard manager that I'm aware of. However, that line of code did
> indicate something is running.
>
> selection get -selection CLIPBOARD_MANAGER -type TARGETS

On my Linux system (no 'desktop environment', just Fvwm2) I get
"CLIPBOARD_MANAGER selection doesn't exist or form "TARGETS" not
defined" from that command, with and without xclipboard running, so
that command is not 100% reliable to detect a running clipboard
manager.

> And if there is in fact some manager running, AND, wish can tell it's
> there,

Well, that's just it, the way the X11 clipboard is handled, wish has no
way to know a manager is running or not. It simply asserts that "I
have selection data for transfer" and some other running program, at a
later time, asks: "send me the data you have". Wish has no way to know
if that other program is a manager, or the actual destination, given
the standard X11 clipboard system.

> then shouldn't it be able to do whatever all the other programs seem
> able to do that preserves the ability to paste even though all the
> foreground programs have exited and restarted.

Wish is not the one doing any 'preserving'. The source program has no
knowledge of a manager running or not, it simply responds to a "send me
your data now" message by sending the data. If the data is not being
preserved, then there is something different with how the Tcl script is
doing things that is resulting in whatever manager there is that
appears to maybe be running not actually receiving or storing the data.

[1] unless your 'desktop environment' builds one in by default such
that it is just part of one of the other running processes

[tedbr...@gmail.com]

Thanks Brian and Rich, and I've now read the [selection] command manual entry a
command that I'd never before today looked at.

And in there I saw there is one item in the manual which
says that the 2 commands do have something in common under,

clipboard get
This command is equivalent to “selection get -selection CLIPBOARD”


In my program I wanted to be able to exit and then restart and still
have the clipboard contents available to retrieve. I guess it is just
a lazy way of saving some data w/o having to deal with file names,
protections, errors, a directory, and cleanup when I'm done.

And it does the job on windows, but sadly, not on linux.

In the course of this thread, I looked at Francois' links,
and I found that others had considered that
this behavior on linux might be a bug. And so I went looking at that. I
don't know if that's the case or not any longer. Perhaps it's more in
the line of a TIP than a ticket.

Interestingly, in my searching, I found that the ubuntu community had
an article on just this same issue. The 9 year old thread is here

https://wiki.ubuntu.com/ClipboardPersistence#How_to_fix_it:_the_ClipboardManager_spec

And this seems to explain how programs such as gedit and bash across
program restarts don't clear this "clipboard". However, it would appear
that tk does not support this, hence my thinking this is more of a TIP.

Thanks again, all of you have helped me to understand the issue much better.
I'm probably going to just test for linux and use a text file in the home
directory; on windows, I'll stick with the clipboard.

[tedbr...@gmail.com]

Problem solved!

I finally tried the recommendation from the ubuntu site and,

sudo apt-get install parcellite

this completely takes care of it. Now it just works just like on windows.

:) :) :)

[Rich]

tedbr...@gmail.com wrote:
> In my program I wanted to be able to exit and then restart and still
> have the clipboard contents available to retrieve.

This is not a safe way to save state across an exit and restart, on any
system. In the time between exit and restart if another program causes
changes (on any OS), your saved state is lost.

> I guess it is just a lazy way of saving some data w/o having to deal
> with file names, protections, errors, a directory, and cleanup when
> I'm done.

And not safe if you value the data you are saving. And if you don't
value it, why save it in the first place?

> And it does the job on windows, but sadly, not on linux.

Because windows has a specific "clipboard" storage space, inside
windows proper, where data is shoved when a copy is performed. X11 has
no such system.

This is also why you get that irritating "you have saved a large amount
of data to the clipboard, do you still want it to be available" dialog
when exiting some programs after you've copied something large to the
windows clipboard.

> Interestingly, in my searching, I found that the ubuntu community had
> an article on just this same issue. The 9 year old thread is here
>
> https://wiki.ubuntu.com/ClipboardPersistence#How_to_fix_it:_the_ClipboardManager_spec
>
> And this seems to explain how programs such as gedit and bash across
> program restarts don't clear this "clipboard". However, it would appear
> that tk does not support this, hence my thinking this is more of a TIP.

No need for a tip, the first link at the page pointed to by your URL
above, the one labeled "Freedesktop's CliboardManager specification"
explains how to make it work. You will have to use the selection
command to claim ownership of an X11 selection named
"CLIPBOARD_MANAGER" to cause the freedesktop clipboard manager to be
invoked. I'd surmise they did this because deamons such as xclipboard
that watch for the standard selections often cause issues with some
programs. By using a separate selection that interference is avoided.
But at the cost that individual programs now have to know to use
"CLIPBOARD_MANAGER" to invoke the manager. Gnome specific programs
likely are programmed this way, anything else, including your Tk
script, is not likely to be using the "CLIPBOARD_MANAGER" selection for
anything. If you authored the script, then you can modifiy it to use
that selection name, at which point it should work to invoke the manager.
If you did not author the script, you could likely still modify it, but
you'll probably have more work ahead of you in that case in finding and
modifing all the various selection calls.

> I'm probably going to just test for linux and use a text file in the home
> directory; on windows, I'll stick with the clipboard.

Using a file is the safer way to hold state over an exit and restart,
no matter the underlying OS.

[tedbr...@gmail.com]

On Friday, December 27, 2019 at 5:42:39 PM UTC-8, Rich wrote:
> This is not a safe way to save state across an exit and restart, on any
> system. In the time between exit and restart if another program causes
> changes (on any OS), your saved state is lost.

Rich, you're right of course. If I did this when I was working as a
professional programmer, I would be fired immediately, and rightly so.
However, this is for a personal project and it's probably the least of
my bad programming practices.

The clipboard has become one of my favorite tools lately after I
discovered a truly wonderful little windows utility called Ditto. It's
a clipboard manager tool with many features, but most important the
history, so nothing I “copy” ever really gets lost. I find I now
typically do several sequential copy operations of snipits of code
(esp. from the wiki – love the “copy” button in code blocks), so I can
then paste them all into a program I'm writing. Ditto has changed how
I use copy/paste completely, since all my copies remain available and
easy to access.

I'm now using the clipboard to do a “save history” in my personal
debugger project which is like the console history or rlwrap, except
it's a history of all the buttons pushed or menu commands I've used in
a debugger session, but expressed as a text list, so I can edit it and
then replay it. If I chop off the last few debugger commands before a
replay, I can effectively implement a “run backwards” debug capability.

Saving the list in the clipboard, and pasting after restarting was the
quickest way to implement this feature. Even if I lost the data, it
wouldn't be a big loss.

Since I might want to use this on linux, I periodically test my code
there, and thus found this one incompatibility.

Anyway, not to worry, I'm really only programming for myself these
days. Nobody else will have to use or maintain my code. But I
completely agree with you on principle and I always appreciate your comments
and concerns.

[Donald Arseneau]

tedbr...@gmail.com writes:

> On Friday, December 27, 2019 at 10:04:07 AM UTC-8, Rich wrote:
>
>> Under X11 there is no "clipboard" to clear. X11 has no centeral
>> storage called 'the clipboard'.

Well, the desktop environment adds it.

>> But, if one runs a clipboard manager such as
>> xclipboard, then the flow is changed.

Yes, the flow goes to the clipboard, which resides in and is managed by
the clipboard manager.

> Since I can close all the terminal, gedit, etc. windows and
> then launch a new terminal and still do a paste says there has to
> be something saving that "clipboard" data somewhere.

I don't suppose you have a clipboard icon in your system tray.

It is a pain that the X selection and the clipboard are distinct.

Note (and this is why I responded) that konsole settings include the
choice "Mouse middle button:" "Paste from clipboard" or "Paste from
selection". I don't see a similar configuration in gnome-terminal.
Normally, in a terminal or various other X programs, the middle mouse
button inserts the active selection but menu-paste (or [shift]-ctrl-v)
inserts from the clipboard manager.


--
Donald Arseneau as...@triumf.ca