Re: Xwinclip doesn't work with Konsole
If, on the other hand, the applications work fine with xclipboard, then maybe we will be able to do a better job of handling the selections. Well actually I can't even get the cygwin one to run let alone do anything. It pops up a small window with a very confused button set then shows cancel or something similar every time I try to use it. Using the openwin (solaris) xclipboard these applications work fine, the selection is fine and everything works as expected. We are not doing a very good job of figuring out how the commercial X applications out there handle clipboard integration. They *never* grab the primary selection and they always have the most recently selected text from either clipboard. Only ever when you leave one of their windows. Don't forget that they, like you know when you're window is left. That is the time to find out if anything has been grabbed. Also I'm fairly sure that most messages go through the X server so it shouldn't be very difficult to trap drags, ctrl+c's etc. Or more likely the real message ids. Maybe they are doing this through polling, which we are trying to avoid, but I am not even sure how polling would solve the problem (unless you poll for the selection, compare it to the old data, and act accordingly, which would put a huge demand on network bandwidth...). I doubt polling would solve much. Either way you are still causing unnecessary bandwith hogging when you steal ownership, not much most of the time but heh. More importantly the way that most X users expect the selection system to work (again as a user) is like my fix had made i.e. don't grab the selection. As a side point, yes I prefer my version of xwinclip to exceeds rather poor clipboard handling, including the recent release. Plus it always crashes and it's dead slow. I prefer cygwin/xfree86 by a long shot. It is our problem (well anyone who wants to use xwinclip) and it should be fixed. The hook dll doesn't need to be used as XWin can notify the app itself (if you have it inbuilt into xwin then multiple instances of xwin won't work properly together (although I'm not sure they do anyway), i'm talking about running xwin more than once not a screen option). Oh please. Integrating the clipboard support into the XWin.exe executable is not going to forbid it from working with multiple screens run by one executable, nor is it going to forbid multiple instances of XWin.exe. The oh please is a little childish don't you think? I never said it would forbid anything. But in terms of real issues that would have to be tackled: - setjmp and longjmp would not be usable within the xwin, they work on stack unwinding and would unwind the whole stack (pos solution to run as a thread but xlib doesn't like that very much). - if you do have multiple instances of the code that does the selection handling you will have to use ipc mechanisms to handle the change in selection loop (xwinclip a and b). A notices that an applicaiton in it's instance has changed the selection, it copies it to the clipboard. B notices that the clipboard has changed and claims ownership, a notices that an app If R4 programmers could do it, I'm sure you or I could. You might have to program a little more carefully, but there is nothing about having the functionality present in XWin.exe that prevents anything from working correctly. Never said there was. You have mentioned before that X-Win32 is using an Xt-app for their clipboard support... but I have never noticed such an app. I'm a little confused here I have never mentioned X-Win32 before in my life. I did mention Klipper for KDE that I found before solving the problem of inter toolkit selection grabbing. But never X-Win32. I can remove the hook by patching xwin to send out WM_ACTIVATE message's to a single xwinclip instance (this of course can be run from within XWin anyway). But I think that's not what you want either. I just want a solution that works identically to the dozen or so commerical implementations that have conquered this very problem. I won't be satisfied until we have clipboard support that rivals the commercial X Servers for MS Windows. As I and others have said here, the commercial ones aren't much better but they don't grab the selection (it's about the only good thing they do). Either way unless you can obtain source code or a developer who worked on these you're stuck as to identically doing it. The question you have to ask yourself is if you need to do that. You seem dedicated to copying the selection every time a user highlights something. Why? I doubt seriously that commercial software is doing something so obviously wastefull. Chris _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: Xwinclip doesn't work with Konsole
Hi Harold, Harold L Hunt II [EMAIL PROTECTED] writes: I just want a solution that works identically to the dozen or so commerical implementations that have conquered this very problem. I won't be satisfied until we have clipboard support that rivals the commercial X Servers for MS Windows. I couldn't help smiling here. I am already using xwinclip with a commercial server (an older version though, eXceed 6.2) because I wasn't satisfied with the functionality that the server gave me. Your work is appreciated ;-) so long, benny
Re: Xwinclip doesn't work with Konsole
Benny, Heh heh... that's pretty odd. I never would have thought that people would prefer xwinclip functionality over their commerical X Server's clipboard integration. I never even realized that xwinclip could be used with a commercial X Server :) Harold Benjamin Riefenstahl wrote: Hi Harold, Harold L Hunt II [EMAIL PROTECTED] writes: I just want a solution that works identically to the dozen or so commerical implementations that have conquered this very problem. I won't be satisfied until we have clipboard support that rivals the commercial X Servers for MS Windows. I couldn't help smiling here. I am already using xwinclip with a commercial server (an older version though, eXceed 6.2) because I wasn't satisfied with the functionality that the server gave me. Your work is appreciated ;-) so long, benny
Re: Xwinclip doesn't work with Konsole
Hi Harold! No, it doesn't work correctly. The output is: UnicodeSupport - Windows NT/2000/XP ## Select something in Konsole SelectionNotify CompoundText (the selection remains selected) ## Click somewhere in X SelectionNotify CompoundText SelectionNotify UTF8 ## Click somewhere in X SelectionNotify UTF8 SelectionNotify - Reasserted ownership of ATOM: PRIMARY SelectionNotify - Reasserted ownership of ATOM: CLIPBOARD Now the paste in a Windows application works. If I do not follow the procedure described, the paste operation in a Windows application doesn't work. The reversed procedure(copy from Windows to X) has a chaotic behaviour. I can't reproduce it every time. Sometimes works, sometimes not. 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. Best Regards Jozsef Kercso
RE: Xwinclip doesn't work with Konsole
Hi Chris Can you build the xwinclip exe and use the dll supplied (i've put the build_dll.sh in there as well)? Let me know what happens (and the output). The copy from X works just like I wrote in my previous mail to Harold (see log1), but when I try to copy from Windows, the results are unpredictable. (see log2) Best Regards Jozsef Kercso log1.zip Description: Binary data log2.zip Description: Binary data
RE: Xwinclip doesn't work with Konsole
Hi Chris Can you build the xwinclip exe and use the dll supplied (i've put the build_dll.sh in there as well)? Let me know what happens (and the output). The copy from X works just like I wrote in my previous mail to Harold (see log1), but when I try to copy from Windows, the results are unpredictable. (see log2) Thanks Jozsef, The output looks as I'd expect for Harolds reasoning. I've put in his changes for selecting the CLIPBOARD (an issue with me for a while) output but I haven't made the thing work yet. It recognises an owner and calls xconvertselection, then the flushxevents function is called but the XNextEvent doesn't show a new message. Bizarre. I'll keep trying to get clipboard working properly maybe that will be enough. chris PS (the wierd behaviour with pasting back the windows clipboard is because it won't claim ownership unless a windows application has changed the clipboard since the last primary selection. This is in my code only. It makes logical sense but it doesn't work the way the old one did, as far as possible it leaves XWin to do it's thing, only claiming the primary selection once the clipboard has been changed). _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
Re: Xwinclip doesn't work with Konsole
Harold == Harold L Hunt, Harold writes: Harold Hmm... Harold xwinclip-Test06 actually works the exact same way with Emacs... I am Harold pretty sure this is just because Emacs 21 finally fixed the way that Harold the selections were handled. So, I think we can now safely say that Harold if someone has an application that unhighlights the selection when Harold xwinclip is running: fix the *?$%ing application!!! :) I know of 2 applications which unhighlight the selection. Xemacs and Nedit. I just tested them with your xwinclip-20021121-1800.exe. But I got a patched version of xwinclip from Chris Twiner once which works perfect even with Xemacs and Nedit. There must be an e-mail about this in the archive. Ciao Volker
Re: Xwinclip doesn't work with Konsole
Chris, I'd have to disagree in a big way. xterm, dtterm, nedit, netscape , and countless other X applictions that behave in the right way won't because xwinclip breaks the standard by reclaiming ownership. I've tested your release with at least the above and it causes functionality issues with anything that uses the selection. Run these same applications with xclipboard and see if the behavior is similar. If it is, then I say it is simply a problem with the way that the X clipboard system is designed and we leave it at that. If, on the other hand, the applications work fine with xclipboard, then maybe we will be able to do a better job of handling the selections. We are not doing a very good job of figuring out how the commercial X applications out there handle clipboard integration. They *never* grab the primary selection and they always have the most recently selected text from either clipboard. Maybe they are doing this through polling, which we are trying to avoid, but I am not even sure how polling would solve the problem (unless you poll for the selection, compare it to the old data, and act accordingly, which would put a huge demand on network bandwidth...). It is our problem (well anyone who wants to use xwinclip) and it should be fixed. The hook dll doesn't need to be used as XWin can notify the app itself (if you have it inbuilt into xwin then multiple instances of xwin won't work properly together (although I'm not sure they do anyway), i'm talking about running xwin more than once not a screen option). Oh please. Integrating the clipboard support into the XWin.exe executable is not going to forbid it from working with multiple screens run by one executable, nor is it going to forbid multiple instances of XWin.exe. You might have to program a little more carefully, but there is nothing about having the functionality present in XWin.exe that prevents anything from working correctly. You have mentioned before that X-Win32 is using an Xt-app for their clipboard support... but I have never noticed such an app. I have always been under the impression that the cipbard support is integrated into X-Win32's executable. In any case, we are unlikely to be able to use Xt because we have to interleave handling of Win32 message with X events... trying to do that with Xt may be difficult if not impossible. There is nothing to say that we cannot handle the selections exactly as Xt does, and doing so does not mean that we actually have to use Xt. Shoot... we have the source code to Xt, so it isn't like something is stopping us from understanding what Xt is doing. I can remove the hook by patching xwin to send out WM_ACTIVATE message's to a single xwinclip instance (this of course can be run from within XWin anyway). But I think that's not what you want either. I just want a solution that works identically to the dozen or so commerical implementations that have conquered this very problem. I won't be satisfied until we have clipboard support that rivals the commercial X Servers for MS Windows. Harold
RE: Xwinclip doesn't work with Konsole
Hi! I have to make some correction to my previous testcases. Now I see clearer what the situation is: 1. I copy something in a Windows application - paste in a Windows application works - paste in Konsole works 2. I select something in Konsole - in the clipboard viewer I see the _old_ selection(from 1.) - xwinclip says: SelectionNotify UTF8 - paste in Konsole(or xterm) works(paste the selection from Konsole) - paste in a Windows application doesn't work (paste the _old_ selection, that is: selection from 1.) 3. I copy something in a Windows application - in the clipboard viewer I see the _previous_ selection from Konsole!!! - xwinclip says: SelectionNotify UTF8 - paste in a Windows application works(selection from Konsole) - paste in Konsole works(selection from Konsole) 4. I copy something again in a Windows application - in the clipboard viewer I see the current selection - paste in a Windows application works(current selection) - paste in Konsole works(current selection) 5. With xterm everything is fine. So I think, that Konsole use the PRIMARY SELECTION, but I don't see what the problem is. I made some other tests too, but the results were too chaotish, I can't reproduce them every time. Best Regards Jozsef Kercso
RE: Xwinclip doesn't work with Konsole
Hi, Thanks for the feedback, I will post another version of mine tonight (forgot to last night). Can you give me the output of my xwinclip when you run these tests? I will post the built exe and the dll for my version as well, just to remove compilation issues. It seems as though it doesn't recognise that there is a primary selection. This seems related to the qt bug but I don't know quite how to proove it. Chris _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus
RE: Xwinclip doesn't work with Konsole
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
RE: Xwinclip doesn't work with Konsole
Hi, Can you build the xwinclip exe and use the dll supplied (i've put the build_dll.sh in there as well)? Let me know what happens (and the output). Thanks, Chris _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail xwinclip_hook.zip Description: Zip compressed data
Re: Xwinclip doesn't work with Konsole
/ Chris Twiner [EMAIL PROTECTED] wrote: | Thanks Jozsef, | That's perfect information. From what I can tell (quick research) it uses CLIPBOARD and PRIMARY. Sorry, this I don't understand, what this sentence means. Can you explain it? | I think so, the Konsole app doesn't seem to use the PRIMARY selection | properly (i.e. in a standard way), that is why test6 doesn't | automatically remove the selection from it. Hi! Sorry for private mail, but I am not sure I can mail to the list.. reading it from news. Just a quick thought.. as you say it does not use the PRIMARY selection properly, does it use the primary selection at all? I mean, modern X and like the CDE on solaris has two clipboards, one is for CDE, and can be accessed by apps compiled to CDE through the menus edit-copy edit-paste, while the other, in xterms, emacs and so on uses the ancient select with mouse, and paste with middle button.. It is not like Konsole uses the alternative clipboard? Or you are supposed to use it.. Or maybe even you need to select the text, and do a edit-copy to get it to the clipboard? /Andy -- The eye of the beholder rests on the beauty!
Re: Xwinclip doesn't work with Konsole
Hi! Sorry for private mail, but I am not sure I can mail to the list.. reading it from news. No problems. I had to register with the global posting list (on sources.redhat.com) to post properly, I had so many returned to me. Using the global list means you don't have to receive all message postings. Just a quick thought.. as you say it does not use the PRIMARY selection properly, does it use the primary selection at all? According to the docs on it, yes. It's apparently a well known problem, if it is the problem that was suggested. I mean, modern X and like the CDE on solaris has two clipboards, one is for CDE, and can be accessed by apps compiled to CDE through the menus edit-copy edit-paste, while the other, in xterms, emacs and so on uses the ancient select with mouse, and paste with middle button.. Strictly speaking the acient select with mouse and paste option is the correct ICCM standard, that's why qt3 is moving to that way of operating. It's probable that it's current implementation is just using it's own wierd solution but the postings on google seem to indicate it uses both CLIPBOARD and PRIMARY so it may be it's just not using it properly. It is not like Konsole uses the alternative clipboard? Or you are supposed to use it.. Nope it's non standard. However that doesn't mean that xwinclip shouldn't be changed to work with it. Or maybe even you need to select the text, and do a edit-copy to get it to the clipboard? Could be, but I'd like to see what the latest output would be. Chris _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
Re: Xwinclip doesn't work with Konsole
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
Re: Xwinclip doesn't work with Konsole
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
Re: Xwinclip doesn't work with Konsole
Hi! Just to check (I don't have kde available) this when you say copy/paste do you mean the edit menu copy and paste? No. Or do you mean highlight in Konsole and then use the middle button. Yes, this is what I meant. Best Regards Jozsef Kercso
Re: Xwinclip doesn't work with Konsole
Hi! Damn this is interesting. Just to check (I don't have kde available) this when you say copy/paste do you mean the edit menu copy and paste? No. good good. Or do you mean highlight in Konsole and then use the middle button. Yes, this is what I meant. What does the output of my xwinclip have in it? does it show something like : no xa_primary owner or maybe XToWindows XA_PRIMARY convertselect() failed It would mean that there is some dodgy non-standard activity going on or that the format can't be converted. Chris _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
RE: Xwinclip doesn't work with Konsole
-Original Message- From: Chris Twiner [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 4:08 PM To: [EMAIL PROTECTED] Subject: Re: Xwinclip doesn't work with Konsole It would mean that there is some dodgy non-standard activity going on or that the format can't be converted. I don't know the details, but I've heard it said that some aspect of copy and paste is broken in Qt 2 when it comes to interoperating with clients using other widget sets, but is fixed in Qt 3. Maybe this is what you're up against? -- Peter Oliver Midrange Services Aquila Networks Services Ltd Confidentiality: This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, use of this information (including disclosure, copying or distribution) may be unlawful. Please notify [EMAIL PROTECTED] and delete the message immediately. Security: Internet e-mail is not a 100% secure communications medium. Viruses: This e-mail (and any attachments) has been checked (using Sophos Sweep 3.63 + patches) and found to be clean from any virus infection before leaving. Therefore neither Aquila Networks Services Ltd nor Midlands Electricity plc or any of their group undertakings (as defined by the Companies Act 1989) (together referred to as the Companies) accept legal responsibility for this message or liability for the consequences of any computer viruses which may have been transmitted by this e-mail. Monitoring: All electronic communications with the Companies may be monitored in accordance with the UK Regulation of Investigatory Powers Act, Lawful Business Practice Regulations, 2000. If you do not consent to such monitoring, you should contact the sender of this e-mail. Aquila Networks Services Limited, Registered office: Whittington Hall, Whittington, Worcester, WR5 2RB Registered in England and Wales number 3600545 This e-mail may be sent on behalf of any of the Companies.
