Re: [Bug-XBoard] Again XBoard copy

[h.g. muller]

> It looks like the Athena widgets were designed before the "new" X clipboard
> behavior was standardized, so the documentation only talks about the
> primary selection and cut buffers.  Cut buffers are obsolete -- they
> still exist, but newer programs don't use them.  There might be some
> clever way to use these actions to assert ownership of the CLIPBOARD
> selection, but I doubt it.
>
> I don't know offhand how to bind keys in the widget to custom code
> (rather than one of the provided actions).  Hopefully there is a way.

You are right: the text widgets in the engine-output window are not read-only,
and this could be consider a buglet. I cloned this code from the comment popup
before I really knew anything about X, and the comment popup has a parameter
'mutable', because it is both used for displaying and editing comments. But I
now remember that I had to fix mutable as true, because otherwise the program
could also not edit the text in the widget (which it needs to do to insert 
a line
at the top). Of course I could switch it from read-only to editable every 
time the
program want to write it, and then back, but as the text is never read back
having the user edit it has no adverse efects other than that he is 
cluttering up
his own display. So I did not bother.

I hacked in some code that seems to solve the problem. (Bear in mind that upto
yesterday I did not have the slightest idea what 'key bindings' were...) It 
is quite
ugly, and I cloned it from the copy/paste position code in xboard.c. I even 
draw
on some of that code by calling it, as what I wanted to do here (copy a string
that is in memory) is actually very similar to the copy/paste position stuff.
Actually XBoard contained a lot of examples for binding keys to custom code
(e.g. for the board the v key does flip view). So I cloned that method, and 
bound
the Ctrl-c key in the engine-output text widgets to a new routine. That new 
routine
"pastes" the selection (using code clone from Paste Position), and then 
immediately
copies it back to the clipboard. (but if the option '-pasteSelection is in 
force, it doesn't
do anything).

I had to bind the Ctrl-c key through XtOverrideTransations, rather than
XtAugmentTranslations, because indeed Ctrl-c seemed to be bound to something.
In fact it seemed to copy the current selection to the cursor location. 
This was
not listed amongst Xaw default bindings, but I could not find any code in 
XBoard
that made this binding. (And why should it?)

This is a bit of a kludge; I have the feeling that it must be possible to 
do this by
a simple Xt call to tell X that we want selection to become clipboard, 
rather than
actually fetching the data and then copying it to clipboard. But I could 
not find it.
What complicates the hack even more is that you explicitly have to set keyboard
focus to the text widget for the Ctrl-c to work reliably. Otherwise the 
binding has
no effect when the mouse pointer has left the text widget. (Another very weird
property of X, that makes me suspect I am doing something wrong.) There was
already a routine in xoptions.c that I could add to the text widgets as event
handler (for mouse clicks) that did this, which I could call upon.

Anyway, it seems to work now: I can select text in the output fields of the
engine-output window, copy to clipboard, and then paste into gedit. It required
the addition of a lot of ugly code, though.

I sent the patch to Arun. A binary Debian package is downloadable from
http://hgm.nubati.net .

Btw, I noticed that all the key bindings (from char globalTranslations[]) 
are made
to the form widget of the main window. This means they are only active when
you have last clicked within the form widget (using a menu, or clicking on 
board
or clocks). If you merely select the window by clicking the title bar, the keys
(e.g. v for flipView) do not work. This is a bit annoying. Could this be 
improved
by binding the keys to the top-level shellWidget, rather than the form widget?