Xwinclip doesn't work with Konsole

[Harold L Hunt II]

Hmm...

xwinclip-Test06 actually works the exact same way with Emacs... I am 
pretty sure this is just because Emacs 21 finally fixed the way that the 
selections were handled.  So, I think we can now safely say that if 
someone has an application that unhighlights the selection when xwinclip 
is running:  fix the *?$%ing application!!!  :)

As far as Konsole is concerned, take a look at the xwinclip snapshot 
that I just posted... it has diagnostic messages that print the atom 
name that was just re-owned.  Konsole owns both the CLIPBOARD and the 
PRIMARY atoms, and it turns out that not reowning the PRIMARY atom and 
only reowning the CLIPBOARD atom keeps the text highlighted in Konsole.

Arrgh... I am just confused now.  Is the unhighlighting of selections 
our problem anymore?  I am starting to think that it is not.

Harold

Harold L Hunt II wrote:
> Jozsef,
> 
> I think I see the problem.  The code that handles converting the text 
> format (added by Kensuke Matsuzaki) *always* looks at the PRIMARY 
> selection, whereas I have just done some testing that seems to indicate 
> that Konsole is using the CLIPBOARD selection.  Therefore, the converted 
> text is blank.  I am not sure why this was hard coded... it seems to be 
> an accident.  The code should be trying to convert the atom specified by 
>  event.xselection.selection instead.
> 
> Download this version of xwinclip and let me know if it works:
> http://www.msu.edu/~huntharo/xwin/xwinclip/xwinclip-20021121-1800.exe.bz2 
> (5 KiB)
> 
> The faster you respond, the more likely I am to finish up this patch, 
> and the happier I will be.
> 
> 
> On a side note... I seem to have done something strange to this version 
> of xwinclip.  I have been playing around with various patches to try and 
> stop from having to grab ownership of the selection and, well, I seem to 
> have stumbled on an improvement, though I cannot explain it and I fear 
> that it might turn out not to be an improvement.  The behavior is as such:
> 
> 1) Go into emacs under X, select some text.  The text remains selected.
> 
> 2) Go into Notepad, paste the text.  The expected text is pasted.
> 
> 3) Go back into emacs under X, select some new text.  Again, the text 
> remains selected.
> 
> 4) Go back into Notepad, paste the text.  Again, the expected text is 
> pasted.  The behavior of xwinclip has been such that second selections 
> would not work if the PRIMARY selection was not re-owned.  I seem to 
> have done something that is stopping the PRIMARY selection from being 
> reowned while still allowing notification of selection updates.  I 
> checked my code and I am not watching XA_CUT_BUFFER0, so I have no idea 
> what is going on.
> 
> 5) Konsole still unselects the selected text immediately.
> 
> 6) Strange.
> 
> I am still calling XSetSelectionOwner on event.xselection.selection... 
> so I should be re-owning the PRIMARY or CLIPBOARD selection... maybe I 
> will just leave this alone so that I can enjoy my delusion of having 
> fixed the main problem with xwinclip.
> 
> Anyway, someone tell me if it works for them, please, please, please.
> 
> 
> Harold
> 
> Kercso Jozsef wrote:
> 
>> Hi!
>>
>>  > Can you give me the output of my xwinclip when you run these tests?
>> Here it is:
>> $ ./xwinclip.exe
>> UnicodeSupport - Windows NT/2000/XP
>> [[Prev mail Point 1. Second section("paste in Konsole works")]]
>> FlushXEvents - CreateNotify parent: 54  window: 16777870
>> FlushXEvents - CreateNotify parent: 54  window: 23069034
>> [[Prev mail Point 2. Nothing happens!!]]
>> [[Prev mail Point 3.]]
>> SelectionNotify UTF8
>> [[Prev mail Point 4. Nothing happens.]]
>> $
>>
>>  > I will post the built exe and the dll for my version as well, just to
>>  > remove compilation issues.
>> Great!
>>
>> Best Regards
>>   Jozsef Kercso
>>
>