re: Direction of xwinclip

["Chris Twiner" <c_twiner at hotmail dot com>]

> I now remember what it was that I did not like: Ownership of the X 
> selection
> is grabbed when XWin.exe loses focus.  Is that correct?
No.  It only takes ownership selection when XWin is gaining activation (and 
not from another window).  When Xwin looses activation (and therefore focus) 
it merely grabs whatever is in the selections, if anything, and puts it into 
the windows clipboard.

> Robert's method of watching for changes in XA_CUT_BUFFER0 might be hack, 
> but
> I think it is probably closer to what other X Servers for Windows are 
> doing,
> as those other X Server do not grab ownership of the X selection when they
> lose the focus.
Neither does my code, but see later...

> Have you got any objections to watching for changes in
> XA_CUT_BUFFER0 as a signal that we should request another copy of the X
> selection?
Yes I have, the ICCM standard says don't use it in new applications and the 
rest of the x development community says don't use it in new applications.  
Seemingly only a few do.  Motif apps have some wierd logic for working out 
wether to try and use it but they don't use it directly (they've got their 
own wierd and wonderful way of doing things for CLIPBOARD).

Basically as the ICCM says it's obsolete.  You can write a compliant X 
selection app that works with PRIMARY without problems but never uses the 
cut buffers.  How many applications have you tried it with, sorry I can't 
try it at mine, gcc's specs don't seem to work for my box (or the work box I 
have it on).

> If we decide to go with the XA_CUT_BUFFER0 hack, then there will probably
> need to be only one more release of xwinclip.  After that we can 
> concentrate
> on integrating the clipboard support into XWin.exe.
I think that it would be usefull (possibly as thats the way xceed works, 
when it does, to make it an xt/xm app as well) so that we can get the motif 
clipboard if it's being used.

However within XWin it may not be the best approach either way, as all 
messages go through the xserver anyway should not a simple hook into the 
server code be better then making a client within a server (and having to 
look at threading it or more complicated setjmp's).

> By the way... I like the setjmp/longjmp stuff... I thought it was two
> assembly language instructions that were used.  Imagine my surprise when I
> saw setjmp.h and realized that setjmp and longjmp were (used like)
> functions.  That is a heck of a lot easier than I had thought it would be.
Glad it could help.

> Thanks for your contributions Chris.
cheers,

Chris

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail