xwinclip/-clipboard - Development on no selection stealing version

[Harold L Hunt II]

I have been working with the code for Keith Packard's XFIXES extension. 
  The XFIXES extension includes a new hook in Xserver/dix/dispatch.c 
that allows functions within the Xserver (such as the XFIXES xtension) 
to register for a callback when a selection's ownership changes, among 
other things.

The best documentation I can find for the selection portion of XFIXES is 
Owen Taylor's writeup on a RedHat list that doesn't seem to have a 
public archive anymore.  Google has a cache; both URLs are below...

https://listman.redhat.com/pipermail/xdg-list/2002-November/000937.html

http://216.239.53.100/search?q=cache:4osKtTvNNhcJ:https://listman.redhat.com/pipermail/xdg-list/2002-November/000937.html+XFixesSelectSelectionInput&hl=en&ie=UTF-8


In any case, I reincluded the XFIXES extension in my local tree from 
SourceForge.  I built the extension and modified the -clipboard module 
to register for messages from the XFIXES extension related to ownership 
changes of XA_PRIMARY.

The ownership notifications work just fine, and I am able to copy text 
from X to Windows repeatedly without having to transfer ownership of 
XA_PRIMARY to the clipboard manager (the -clipboard module).

The remaining problem is that I modified the Win32 message loop in the 
-clipboard module to add itself to the clipboard chain and to call 
XSetSelectionOwner when something comes through the Windows clipboard. 
This immediately resulted in an infinite loop, as my X event handling 
for a selection ownership change calls XConvertSelection, which ends up 
sending a SelectionNotify event back to the -clipboard module.  The 
-clipboard module copies the text from the X clipboard to the Windows 
clipboard on a SelectionNofity event.  Thus, the text makes a round-trip 
from the Windows clipboard, to the X clipboard, back to the Windows 
clipboard, ad nauseam.

I added a little break-out in the selection ownership change processing 
that prevents XSetSelectionOwner from being called if the current owner 
of the selection is the clipboard manager window.  This stops the 
infinite looping, but it causes a problem very similar to the original 
xwinclip problem: the X selection is immediately unhighlighted.

So, my questions are:

1) Does anyone feel like helping on this?  Got any ideas right off the bat?

2) What would be the best way for me to share the code with other 
developers?  I don't want to commit the XFIXES stuff to our SourceForge 
tree's HEAD, but could I use another branch?  If so, please give me some 
instructions for what to do... I haven't got time to study CVS all day.


I am pleased with my current progress point.  This version that is 
dependent upon a stripped-down XFIXES extension will represent about a 
40% completion point in new clipboard integration support that doesn't 
steal selection ownership.  The remaining work to be done could include 
removing the clipboard manager client altogether, removing any 
dependency on XFIXES and using only the internal hooking interface, etc.

Please postpone any debate on those remaining steps until the current 
programming actually works.  There will be no point to debate the merits 
of steps 5, 6, and 7 unless we can actually get step 4 to do what we intend.


Harold