xwinclip/-clipboard - Development on no selection stealing version

[Harold L Hunt II]

I committed an XFIXES_BRANCH branch to CVS on SourceForge.  Follow the 
instructions from David's email in this thread if you don't know how to 
checkout a branch.

I hope I got all the correct files checked in... I won't be back online 
until Sunday evening.

Harold

Harold L Hunt II wrote:
> 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