In comp.os.linux.misc Eli the Bearded <*@eli.users.panix.com> wrote:
> In comp.os.linux.misc, T <T@invalid.invalid> wrote:
>
> I added a crosspost to comp.os.linux.x. I had also been hoping someone
> would answer before me, but...
>
>> From "man xclip" I see that I have three clipboards:
> ...
>> "secondary" or XA_SECONDARY
>>
>> I am very familiar with the first two. What is XA_SECONDARY?
>> And how do I use it?

xclip-copyfile (a sh script distributed together with xclip) uses secondary.

Other than that it is used by very few applications. Having primary and
clipboard is already confusing enough for everybody.

One of the few applications that uses the secondary is emacs when it
runs on a graphical window. Pushing Alt+middle mouse button
<M-mouse-2> runs the command mouse-yank-secondary and will paste the
secondary.

xterm can also use the secondary selection, but IIRC it is not enabled
by default, you need to enable it yourself modifying the
vt100.translations resource (as shown in the previous post by Eli).
For the rest of X clients I don't know any other that uses the
secondary selection.

Since the secondary selection is unused, it is good for storing binary
data. Putting binary data in primary/clipboard is something to be
avoided, since you risk pasting a lot of garbage in a terminal or some
other application.

That is what xclip-copyfile does. It is a very simple shell script
that stores files in tar.gz format in the secondary selection.

$ cat $(which xclip-copyfile)
...
gzip -c "${archive}" | xclip -selection secondary -loops 1 -i

$ cat $(which xclip-pastefile)
...
xclip -selection secondary -o | gunzip -c | tar xv

Most applications just ignore the secondary selection, so it's safe to
use for binary data.

Its usefulness is to be able transfer files from different hosts, as
long as you have a remote terminal open with 'ssh -X'. For exchanging
files in the same computer the simplest thing is to use cp.

The nice thing about the X selections is that X is network
transparent and programs in different computers can talk to each
other. xclip/xsel can even pass data through nested ssh connections,
which you may need to do when you are passing through firewalls (just
remember to add the '-X' option to ssh).

Another nice thing about xclip/xsel is that they work well even in the
case of high latency. The X protocol over high latency links is quite
bad for graphical applications. This is specially truth nowadays when
things gets connected over the wifi adding a lot of extra latency.
You need to rely on things like NX (which has other problems).

This is a good example of how the X protocol can be used for useful
things in tty applications without having to worry about latency.
These are the kind of things that the Wayland crew doesn't understand
and think that forwarding whole desktops is what everybody needs, and
X should be ditched altogether.

PS: X also has CUT_BUFFER0 to CUT_BUFFER7, but I have never understood
what they are. I would be grateful if somebody can explain what they are for.

In comp.os.linux.misc Javier <javier@invalid.invalid> wrote:
> PS: X also has CUT_BUFFER0 to CUT_BUFFER7, but I have never
> understood what they are. I would be grateful if somebody can
> explain what they are for.

They are defined by the ICCCM here:

https://tronche.com/gui/x/icccm/sec-3.html#s-3

They are basically what the ms-windows clipboard is (except there are
eight of them instead of just one). Specific server side storage areas
for data that can later be retreived.

Selections are the more powerful system, defined here:

https://tronche.com/gui/x/icccm/sec-2.html#s-2

They are real inter-client communication channels.

And note, X allows you to have as many selections as you want (although
few programs ever used more than the three basic selections that the
ICCCM requires always be provided):

"Note that there can be an arbitrary number of selections (each
named by an atom) and that they are global to the server."

On Mon, 06 Apr 2020 19:19:46 -0500, Javier wrote:

>
> Other than that it is used by very few applications. Having primary and
> clipboard is already confusing enough for everybody.
>

It's even more confusing in that these selections, primary, secondary, and
clipboard, are merely the standard, built-in selections. An application
can define any number of selection types for data transfer. These user-defined
selections can only be exploited if another application knows about them.
The standard, built-in selections, however, are understood by most other
applications.

The X Window selections are fundamentally different from the "clipboard"
that is found in MS Windows, but most people tend to view these two different
systems as being identical.

On 2020-04-06 19:48, F Russell wrote:
> On Mon, 06 Apr 2020 19:19:46 -0500, Javier wrote:
>
>>
>> Other than that it is used by very few applications. Having primary and
>> clipboard is already confusing enough for everybody.
>>
>
> It's even more confusing in that these selections, primary, secondary, and
> clipboard, are merely the standard, built-in selections. An application
> can define any number of selection types for data transfer. These user-defined
> selections can only be exploited if another application knows about them.
> The standard, built-in selections, however, are understood by most other
> applications.
>
> The X Window selections are fundamentally different from the "clipboard"
> that is found in MS Windows, but most people tend to view these two different
> systems as being identical.
>

Here is a wonderful video that covers all four clipboards:

http://www.cs.man.ac.uk/~chl/Secondary-Selection.mp4

In comp.os.linux.x Rich <rich@example.invalid> wrote:
> In comp.os.linux.misc Javier <javier@invalid.invalid> wrote:
>> PS: X also has CUT_BUFFER0 to CUT_BUFFER7, but I have never
>> understood what they are. I would be grateful if somebody can
>> explain what they are for.
>
> They are defined by the ICCCM here:
>
> https://tronche.com/gui/x/icccm/sec-3.html#s-3
>
> They are basically what the ms-windows clipboard is (except there are
> eight of them instead of just one). Specific server side storage areas
> for data that can later be retreived.
>
>
> Selections are the more powerful system, defined here:
>
> https://tronche.com/gui/x/icccm/sec-2.html#s-2
>
> They are real inter-client communication channels.
>
> And note, X allows you to have as many selections as you want (although
> few programs ever used more than the three basic selections that the
> ICCCM requires always be provided):
>
> "Note that there can be an arbitrary number of selections (each
> named by an atom) and that they are global to the server."

Thanks for the reference. From the text it looks like the CUT_BUFFERs
are stored in the server, so they are persistent even after the client
programs are closed. I guess this has the cost in bandwidth when
placing data in them (unlike the selections, which only use bandwidth
when the selection is requested by some other program).

There is something I still don't understand: why the does the document
ask for the CUT_BUFFER 0-7 numbers to be rotated when using them?
AFAIK that rotation doesn't happen with the selections.

In comp.os.linux.misc Javier <javier@invalid.invalid> wrote:
> In comp.os.linux.x Rich <rich@example.invalid> wrote:
>> In comp.os.linux.misc Javier <javier@invalid.invalid> wrote:
>>> PS: X also has CUT_BUFFER0 to CUT_BUFFER7, but I have never
>>> understood what they are. I would be grateful if somebody can
>>> explain what they are for.
>>
>> They are defined by the ICCCM here:
>>
>> https://tronche.com/gui/x/icccm/sec-3.html#s-3
>>
>> They are basically what the ms-windows clipboard is (except there are
>> eight of them instead of just one). Specific server side storage areas
>> for data that can later be retreived.
>>
>>
>> Selections are the more powerful system, defined here:
>>
>> https://tronche.com/gui/x/icccm/sec-2.html#s-2
>>
>> They are real inter-client communication channels.
>>
>> And note, X allows you to have as many selections as you want (although
>> few programs ever used more than the three basic selections that the
>> ICCCM requires always be provided):
>>
>> "Note that there can be an arbitrary number of selections (each
>> named by an atom) and that they are global to the server."
>
> Thanks for the reference. From the text it looks like the CUT_BUFFERs
> are stored in the server, so they are persistent even after the client
> programs are closed. I guess this has the cost in bandwidth when
> placing data in them (unlike the selections, which only use bandwidth
> when the selection is requested by some other program).

Also a cost in X server memory usage (arguably a bigger concern in the
early days of much smaller memory systems).

> There is something I still don't understand: why the does the document
> ask for the CUT_BUFFER 0-7 numbers to be rotated when using them?
> AFAIK that rotation doesn't happen with the selections.

From the looks of it, they were trying to use the eight buffers as a
form of LIFO stack so that not only could you paste the last thing you
cut, but you could also ask to go "back in time" and paste the last
eight things you had cut.

In comp.os.linux.x Rich <rich@example.invalid> wrote:
>>> They are defined by the ICCCM here:
>>>
>>> https://tronche.com/gui/x/icccm/sec-3.html#s-3
>>>
>
>> There is something I still don't understand: why the does the document
>> ask for the CUT_BUFFER 0-7 numbers to be rotated when using them?
>> AFAIK that rotation doesn't happen with the selections.
>
> From the looks of it, they were trying to use the eight buffers as a
> form of LIFO stack so that not only could you paste the last thing you
> cut, but you could also ask to go "back in time" and paste the last
> eight things you had cut.

It looks like that was the original intention of the X designers, but
I think application designers didn't implement that rotation. XTerm
uses CUT_BUFFER0, CUT_BUFFER1, but the man page says nothing about
rotating them.

In comp.os.linux.x, T <T@invalid.invalid> wrote:
> Here is a wonderful video that covers all four clipboards:
>
> http://www.cs.man.ac.uk/~chl/Secondary-Selection.mp4

That video is embedded in this page:
http://www.cs.man.ac.uk/~lindsec/secondary-selection.html

The end of which has "Feedback" section containing:

Clearly, we need some place where people can express their opinions and
experiences with trying out my system. Initially, I propose we meet in
the Usenet Group comp.os.linux.x, but I am also on the lookout for some
web forum that could host discussions, so watch this space!

So, Charles Lindsey are you reading this? Maybe you could release the
source code of your gtk changes instead of only providing a set of
shared libs for Ubuntu 14.04.

Elijah
------
the video would have been better with visible mouse/keyboard annotations

Eli the Bearded <*@eli.users.panix.com> writes:
> That video is embedded in this page:
> http://www.cs.man.ac.uk/~lindsec/secondary-selection.html
>
> The end of which has "Feedback" section containing:
>
> Clearly, we need some place where people can express their opinions and
> experiences with trying out my system. Initially, I propose we meet in
> the Usenet Group comp.os.linux.x, but I am also on the lookout for some
> web forum that could host discussions, so watch this space!
>
> So, Charles Lindsey are you reading this? Maybe you could release the
> source code of your gtk changes instead of only providing a set of
> shared libs for Ubuntu 14.04.

It’s an LGPL’d library, he’s legally required to provide the modified
source, despite the nonsense he’s put in the copyright file inside the
download.

--
https://www.greenend.org.uk/rjk/

On 07/04/2020 01:19, Javier wrote:
> In comp.os.linux.misc Eli the Bearded <*@eli.users.panix.com> wrote:
>> In comp.os.linux.misc, T <T@invalid.invalid> wrote:
>>
>> I added a crosspost to comp.os.linux.x. I had also been hoping someone
>> would answer before me, but...
>>
>>> From "man xclip" I see that I have three clipboards:
>> ...
>>> "secondary" or XA_SECONDARY
>>>
>>> I am very familiar with the first two. What is XA_SECONDARY?
>>> And how do I use it?

Well I missed the start of this thread, but I have been pointed at it.

The essential difference between the Primary and Secondary selections, at least
so far as text-like files are concerned, is that when you select a piece of text
(with the intention of copying it, for example), it also moves the insertion
point (I assume you are in some editor), so after copying it you have to go back
and find again where the insertion point used to be, so you can paste it there.
Which is a confounded nuisance.

Twenty years ago, in the days when the Xview toolkit was in vogue, editors made
use of the secondary selection as it was intended. It is still available in the
Motif toolkit, and in the nedit editor, but they made it so difficult to use
that everybody forgot about it. I was still using it on my Sun computer until
four years ago (both in the editor and the terminal); it was the best thing
since sliced bread.

When I started using Ubuntu on 386 (yech!) architectures, I started modifying
GTK to use it properly. My mistake then was to use a 32-bit version of Ubuntu
when all the rest of the world was turning to 64-bit versions, so although I
made my 32-bit version available, I don't think anybody used it. Now I have
moved to 64-bit Ubuntu, I am still running my 32-bit version on it.

So I refer you to http://www.cs.man.ac.uk/~lindsec/secondary-selection.html
where you will find a short video (it was my first attempt at creating such a
video, so excuse its clunkiness) plus a full description of what it is all about.

--
Charles H. Lindsey ---------At my New Home, still doing my own thing-----------
Tel: +44 161 488 1845 Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk Snail: 40 SK8 5BF, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

In comp.os.linux.x, Charles Lindsey <chl@clerew.man.ac.uk> wrote:
> When I started using Ubuntu on 386 (yech!) architectures, I started modifying
> GTK to use it properly. My mistake then was to use a 32-bit version of Ubuntu
> when all the rest of the world was turning to 64-bit versions, so although I
> made my 32-bit version available, I don't think anybody used it. Now I have
> moved to 64-bit Ubuntu, I am still running my 32-bit version on it.

You don't seem to have made the source code for your changes public,
which hinders other people using it. I'm not going to download random
library files and use them, but source code I might.

> So I refer you to http://www.cs.man.ac.uk/~lindsec/secondary-selection.html
> where you will find a short video (it was my first attempt at creating such a
> video, so excuse its clunkiness) plus a full description of what it is
> all about.

Yes, the video was posted in this thread and from that I found your
webpage about it.

Elijah
------
cannot recall the last time he used a 386

On 13/04/2020 20:51, Eli the Bearded wrote:
> In comp.os.linux.x, Charles Lindsey <chl@clerew.man.ac.uk> wrote:
>> When I started using Ubuntu on 386 (yech!) architectures, I started modifying
>> GTK to use it properly. My mistake then was to use a 32-bit version of Ubuntu
>> when all the rest of the world was turning to 64-bit versions, so although I
>> made my 32-bit version available, I don't think anybody used it. Now I have
>> moved to 64-bit Ubuntu, I am still running my 32-bit version on it.
>
> You don't seem to have made the source code for your changes public,
> which hinders other people using it. I'm not going to download random
> library files and use them, but source code I might.

No, and my webpage explains why. The code is full of dreadful hacks and of
itself is not the basis for an orderly extension to GTK, which would need to be
based on a much later version of GTK. So I did not want to create a fork which
people might expand in all sorts of ways and which would have no future.

I put out the code just so people could try it and, if they liked it, could put
pressure on the GTK developers to take it seriously. It failed in that regard
because nobody nowadays uses 32-bit Linux on desktops. Somewhere on my list of
Things to Do is to recompile it for 64-bit Linux, but even that would not be
easy because you will always find places where you cast a pointer to some size
of integer, and you will find that more recent versions of gcc add extra code to
detect "Stack Smashing", which is fine but exceedingly difficult to debug if it
catches you out,

Moreover the inside of gtk is a dog's dinner, and the developers seem more
intent on rushing ahead with non-backwards-compatible "improvements" and are now
pushing forward with GTK-4 when the world has hardly absorbed the change from
GTK-2. QT made a much better job of maintaining backwards compatibility, but the
world seems to have decided that GTK is the future :-(.

On top of that, the secondary selection, and the ability to create additional
selections (which is very useful if used wisely) is an X-Windows feature. It
does not map well onto Microsoft Windows or onto Wayland.
>
>> So I refer you to http://www.cs.man.ac.uk/~lindsec/secondary-selection.html
>> where you will find a short video (it was my first attempt at creating such a
>> video, so excuse its clunkiness) plus a full description of what it is
>> all about.

Look at my documentation of how I borrowed the Motif implementation of using the
secondary selection; it is, and has to be, pretty complicated if you want it to
work between different windows running different applications, and all running
under different Window Managers.

--
Charles H. Lindsey ---------At my New Home, still doing my own thing-----------
Tel: +44 161 488 1845 Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk Snail: 40 SK8 5BF, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Charles Lindsey <chl@clerew.man.ac.uk> writes:
> On 13/04/2020 20:51, Eli the Bearded wrote:
>> In comp.os.linux.x, Charles Lindsey <chl@clerew.man.ac.uk> wrote:

>>> When I started using Ubuntu on 386 (yech!) architectures, I started
>>> modifying GTK to use it properly. My mistake then was to use a
>>> 32-bit version of Ubuntu when all the rest of the world was turning
>>> to 64-bit versions, so although I made my 32-bit version available,
>>> I don't think anybody used it. Now I have moved to 64-bit Ubuntu, I
>>> am still running my 32-bit version on it.
>>
>> You don't seem to have made the source code for your changes public,
>> which hinders other people using it. I'm not going to download random
>> library files and use them, but source code I might.
>
> No, and my webpage explains why. The code is full of dreadful hacks
> and of itself is not the basis for an orderly extension to GTK, which
> would need to be based on a much later version of GTK. So I did not
> want to create a fork which people might expand in all sorts of ways
> and which would have no future.

It’s not your decision to make. GTK is LGPL, of which clause 3 requires
that if you distribute object code, you distribute source code too. If
you don’t want to distribute the source, you don’t get to distribute the
object code.

--
https://www.greenend.org.uk/rjk/

On Tue, 14 Apr 2020 21:00:01 +0100, Charles Lindsey wrote:
>
> I put out the code just so people could try it and, if they liked it,
> could put pressure on the GTK developers to take it seriously. It
> failed in that regard because nobody nowadays uses 32-bit Linux on
> desktops.

I run 32-bit on a desktop (laptop actually) and run into more and more
problems. Cannot remember clearly, but a couple of GTK issues were among
them.
--
Andreas

PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0