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