Re: Feature request: version report
Harold L Hunt II <[EMAIL PROTECTED]> writes: >>If you could add some means to manually kill and/or restart the >>clipboard code inside the X server then I could switch back without >>the risk of losing work, >I would add a manual kill/restart as a last resort in a few months. >Until then I would prefer to swat bugs rather than try to work around >the problem. I agree that fixing the bugs is better, but as well as testing XWin to find bugs I also try to use it for work, and if Windows apps hang unrecoverably then I can't use the clipboard support. So you may be able to swat bugs faster if users can use the software with less risk. >XFree86-xserv-4.3.0-49 has some changes that may help to recover from >and/or to prevent the deadlock situations. Please try it and let me >know if it improves things or not. Thanks for looking at this - I will try 4.3.0-50. (And try running with -clipboard once again.) -- Ed Avis <[EMAIL PROTECTED]>
Re: Feature request: version report
Ed Avis wrote: Harold L Hunt II <[EMAIL PROTECTED]> writes: Regarding xwinclip, you should really be using (XWin -clipboard) There are a couple of problems with -clipboard (discussed earlier on this list) which have led me to switch back to xwinclip: - Clipboard support seems to die, that is, the Windows clipboard and the X selection stop affecting one another. xwinclip also tends to die occasionally but when this happens it can be restarted. - Windows apps hanging when I try to paste into them. This seems to have started since I began using two displays (though I am not 100% sure). This bug reliably kills any Windows application so it is too dangerous for me to run XWin with clipboard enabled. I have not seen this problem with xwinclip. If you could add some means to manually kill and/or restart the clipboard code inside the X server then I could switch back without the risk of losing work, and I'd be happy to report the contents of Xwin.log on the occasions when such a manual restart was necessary. I would add a manual kill/restart as a last resort in a few months. Until then I would prefer to swat bugs rather than try to work around the problem. XFree86-xserv-4.3.0-49 has some changes that may help to recover from and/or to prevent the deadlock situations. Please try it and let me know if it improves things or not. (In general, I think the clipboard support could be a bit noisier in its logging since the contents of XWin.log never seems to give much away about clipboard or selection change events - but maybe it is more informative to you than to me.) The new source tree has support for specifying the verbosity of log messages... we should be releasing from that tree within a few weeks. Until then it is all or nothing and most users don't want logs measured in megabytes. :) Harold
Re: Feature request: version report
Harold L Hunt II <[EMAIL PROTECTED]> writes: >Regarding xwinclip, you should really be using (XWin -clipboard) There are a couple of problems with -clipboard (discussed earlier on this list) which have led me to switch back to xwinclip: - Clipboard support seems to die, that is, the Windows clipboard and the X selection stop affecting one another. xwinclip also tends to die occasionally but when this happens it can be restarted. - Windows apps hanging when I try to paste into them. This seems to have started since I began using two displays (though I am not 100% sure). This bug reliably kills any Windows application so it is too dangerous for me to run XWin with clipboard enabled. I have not seen this problem with xwinclip. If you could add some means to manually kill and/or restart the clipboard code inside the X server then I could switch back without the risk of losing work, and I'd be happy to report the contents of Xwin.log on the occasions when such a manual restart was necessary. (In general, I think the clipboard support could be a bit noisier in its logging since the contents of XWin.log never seems to give much away about clipboard or selection change events - but maybe it is more informative to you than to me.) -- Ed Avis <[EMAIL PROTECTED]>
Re: Feature request: version report
Ed Avis wrote: I hope the developers will consider adding the following features to make bug reporting easier: - Version number of the X server printed at the top of XWin.log - xwinclip --version Ed, We must think alike :) I have just been thinking about how to have our own version numbers reported by 'xdpyinfo' and possibly other places (like the log file or an 'About' box). Regarding xwinclip, you should really be using (XWin -clipboard) as it now works with Xdmcp connections and it no longer steals ownership of the selection in X everytime you highlight something in programs like emacs. Harold
Feature request: version report
I hope the developers will consider adding the following features to make bug reporting easier: - Version number of the X server printed at the top of XWin.log - xwinclip --version -- Ed Avis <[EMAIL PROTECTED]>
