[EMAIL PROTECTED] (Lars Gullik Bj$Bxn(Jnes) wrote:
> Ok I have looked a tiny bit on this... I don't think this XStoreBuffer
> will work. Ok, it will work if the client that want to access this
> uses XFetchBuffer, but this does not seem to be the standard/common
> way to handle the clipboard.
Too bad. I thought it OK since I can paste to xterm window. The
distinction is actually between XA_CUT_BUFFER0--7 and XA_PRIMARY/
XA_SECONDARY. By default, X has ten clipboards, XA_PRIMARY,
XA_SECONDARY and XA_CUT_BUFFER0 through XA_CUT_BUFFER7. You can
create more if you like. The owner window of XA_CUT_BUFFER? is
always supposed to be the root so that the users do not worry
about obtaining the selection owner and use such facilities as
XStoreBuffer, XFetchBuffer and XRotateBuffers. On the other hand,
in order to use XA_PRIMARY and XA_SECONDARY users have to manage
who the owner is: request the ownership and set the handler for
the notification from the X server. The advantage of using
XConvertSelection is that users will always receives the data
of expected type, while the data type of XA_CUT_BUFFER? is
implicitely assumed to be of XA_STRING even if someone else puts
binary data of lots of null characters in it there.
So we are going to handle at least three modes of IPC's, clipboard,
DnD and the LyX server. Let me focus only on clipboard now.
We are now using (text2.C)
static LyXParagraph *simple_cut_buffer = NULL;
and (math_cursor.C)
static LyxArrayBase *selarray=0;
for storing copied/cut selection. The advantage of having selection
buffers in the local process memory is that we can store pointers
to something local, provided that we are careful not to modify the
contents in the life cycle of the selection. On the other hand, if
we store selections in X, then clipboard can be a means of IPC.
It is not only that LyX and other programs can talk, but also that
different instances of LyX, e.g. running on different machines
wihtout NFS connecting to the same X server can exchange data.
Is it not beneficial to have something as easily used as XA_CUT_BUFFER??
LyX just rotates the buffers (yes, we can have multiple clipboards!)
and stores the copied/cut data to the buffer 0 in the X memory in
the LyX internal format string. And LyX pastes data from the
buffer 0. Someone else can write a clipboard viewer which is capable
of showing, rotating the contents of the buffers. This external
program can be enhanced so that a datum in one of the buffer can be
sent to XA_PRIMARY and/or XA_CUT_BUFFER0. Now Arnd's proposal to
make shared library of LyX kernel service is a possibility, since
the LyX clipboard viewers are likely to use the writer (LaTeX, Docbook,
etc.) and the painter of LyX.
Please refer to xc/lib/X11/StBytes.c of either XFree86 or X11R6.4 for
the implementation. Other windowing systems than X may need an
implementation of something similar to X atoms as well, since Windows
and OS/2 PM atoms are not capable of such mechanisms.
Just an idea.
> | P.S. I can't checkout lyx-devel with cmd.exe as shell!
>
> Hmm. Where you able to earlier?
> Do you get a error?
It was my mistake, sorry
Regards,
SMiyata
