Re: Cygwin/x window no longer appears
On Thu, Nov 12, 2009 at 11:16 PM, Olivia Cheronet cheronetoli...@yahoo.com wrote: Hello! I have recently started to work with Cygwin/X. Until now, I have been starting Cygwin/X by using startxwin.bat in the Cygwin bash shell. Everything seemed to be working fine. However, it has now stopped working... When I type startxwin.bat in the Cygwin shell, the normal startxwin.bat - starting on Windows NT/2000/XP/2003 appears. Yet, the window which used to appear no longer does. I am really not too sure what to do about this, given that I have not (consciously!) modified anything. I have installed Cygwin (and Cygwin/x) very recently, and have tried to reinstall the latter using Cygwin's setup.exe, but to no effect. I assume it's the terminal window (xterm) that does not show up. Does the X server start up? Check if the little X in the system tray is present, and stays when you put the mouse over it . If not, you need to check /var/log/XWin.*.log; there may be some error message there. (Best to delete it and then try startxwin.bat) Another test is to start a cmd.exe and run startxwin.bat from there. Are there any error messages from running startxwin.bat ? Does startxwin.bat really try to start the xterm? Maybe it got commented out (that's what I do with my startxwin) Hope this helps somewhat, Csaba -- Life is complex, with real and imaginary parts -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Can't read lock file
// Which is bad since FAT32 has no security at all. Any process of any user on the machine can overwrite any file, even in the Windows folder. NTFS is much more secure and has a couple of features you never get with FAT32, and hardlinks are only one minor advantage. You should really update the filesystem to NTFS using the on-board convert.exe tool. Well. I took the advice and converted both FAT32 systems (one for 1.5 and one for 1.7) to NTFS. I quite like some of the file management consequences - e.g. chkdsk output, more efficient use of space - but working within Cygwin I'm not a happy bunny. I am sure that in many parallel universes the step you have advised results in huge benefits, but so far I can only report detriment to [1] use and [2] understanding. (I know [1] that requests/ complaints/ comments should not be too user-specific and as for [2] I'm really just hanging myself out to dry. But here goes ...) I operate both Cygwins 1.5 and 1.7 on a partitioned portable drive hooked up to different machines at different times. After changing to NTFS I find statements of folder permissions completely incomprehensible e.g. the + in drwxrwxrwx+; also that they do not alter after chmod instructions in the way I was expecting; that there are MANY additional user names and group names including ?? ; that files I worked on on Machine 1 now produce Permission denied when I try to work on them on Machine 2 All right, all of the above merely make manifest a complete lack of understanding of permissions, privileges, rights, etc. But it is after all my mobile drive, and every file on it was put there by me, is owned by me in some sense, and I ought to be able to do stuff. Finally (and I have tried to search for a solution) I alias ls as ls --color and had some lovely rxvt* xterm* and gnuplot* color schemes set up in ~/.Xdefaults. Now the rxvt* and xterm* color schemes have been lost (to be replaced by, I assume, some standard set, with a particularly horrid colour combination for directories (fg blue bg green). Confusingly, realised gnuplot* colors are still as set in .Xdefaults. Is there a way I can recover what I want for rxvt and xterm (maybe by putting the instructions into a different file). I think I will revert to FAT32 partitions and maybe put up with a working if not current XWin in 1.7. Like my experience with mobile phones, there is a threshold of sophistication beyond which I am just plain incapable of making progress, and the conversion of FAT32 to NTFS seems to have crossed that threshold for me with its unintended (or unexpected anyway) consequences. It is a marvellous advance in security I am sure (and I am very appreciative that Corinna and Jon took this up and responded to me) but I guess it just isn't for me. Thank you. If meanwhile you can point me somewhere for a solution to the lost colour schemes, I would be very grateful. Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Running Java application with drag and drop support in cygwin
On 30/10/2009 09:06, Dees wrote: Your reply is much appreciated Jon. I will try to be more specific about the problem in further mails. On Thu, Oct 29, 2009 at 8:11 PM, Jon TURNEYjon.tur...@dronecode.org.uk wrote: On 28/10/2009 05:57, Dees wrote: I have developed a Java application involving jTree with extensive drag and drop support, which runs correctly in my Linux box. However, when I switch to a windows box and access the same Linux box using cygwin x-server, the drag and drop in jTree stops working. Interestingly, rest of the application still works fine. After analyzing a bit I found that x-server is able to recognize the drag event but fails to recognize a drop event. Details? OS : Suse Linux Enterprise Server 10 (i586) Version : 10 Patch level : 3 Other version information: Java : JDK 5 Cygwin setup-version: 2.573.2.3 Also tried using Xming 6.9.0.31 ssh same Linux setup from Windows, but that also doesn't solve the problem. Is there any setting, which should be done prior to running the Java swing applications? Here is a sample code which behaves in exactly same way. http://www.java2s.com/Code/Java/Swing-JFC/TreeDragandDrop.htm I have no idea how to use that java code to reproduce the problem you are seeing. Using the above java code in Linux: 1. Download and Install Java Development Toolkit on your Linux box (Java sun download site: http://java.sun.com/javase/downloads/index.jsp), if you do not have it already. 2. Save the sample code in the above link with the file name TreeTester.java, say in /home/user/ 3. Navigate to TreeTester.java from shell, and compile the java code: # cd /home/user/ # /usr/java/jdk1.5.0_14/bin/javac TreeTester.java Ignore any warnings of deprecated APIs. 4. This will create a few .class files in /home/user/ directory. Final step is to run the Java code, using: # /usr/java/jdk1.5.0_14/bin/java -classpath . TreeTester This will open up a GUI, with a jTree each on left and right pane. You can drag and drop any of the leaf nodes from one jTree to the root node of the other jTree and this should add a new node in the other jTree. You will get messages on console for the operations being performed. Now ssh the same box using cygwin/xming from any other windows box, and run the application using command in step 4. You should be able to drag (a small icon will come under cursor indicating that something is being dragged) but when you will drop it, the new node would not be added to the tree. Thats where lies my problem!!! Thanks for the test case and instructions, this makes it much easier for me to try it out. However, this testcase and your jar archive both work fine for me (using Xserver 1.7.1-3)! May be my problem is related to some setting. Though, not sure. Has anybody come across something similar? What should be done then? Please let me know. No it's probably a bug in Cygwin/X. But you're going to need to be a lot more specific about the problem before any progress can be made on fixing it. Also, putting some debug messages in the code lets me conclude that it's the drop event which is not being recognized, as the main control never reaches there. There is not really any drop event, as far as the X server is concerned, just mouse click and motion events, which are passed on to you application (which has a framework to interpret them as dragging and dropping an item). Now having a better idea of the problem, it seems less likely it is an Xserver bug at all. The only Xserver cause I can think of would be if it was somehow not sending the correct events to your applications window, which you could test using xev -id your applications window id (you can use xwininfo to find the window id) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 'run xterm' fails to open a window
On 11/12/2009 10:14 PM, Ken Brown wrote: Ah, so this explains my xterm problem that started this thread. When I start xterm from a shell, I always get the message Warning: Missing charsets in String to FontSet conversion [...] It would also be nice to get rid of that xterm warning. Setting LANG=C gets rid of it, so it seems to be another locale issue. Never mind. I found the answer in a different thread: http://cygwin.com/ml/cygwin-xfree/2009-11/msg00085.html The workaround is to install the font-isas-misc, font-jis-misc, and font-daewoo-misc packages. Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Automatically positioned mouse movements are off target
On 24/08/2009 23:05, Brian Sheppard wrote: I installed Cygwin/X (latest version, according to the Cygwin installer) on my laptop. I use Putty with X11 forwarding to connect to a Red Hat Linux system. I start the X windows server on my laptop using startxwin.bat as installed. After logging in to the Red Hat system, I execute gnome-session, and the gnome desktop shows on my Windows desktop. So far, so good. I am testing a Java application using a tool called Abbot. Abbot launches your Java Swing app within Abbot’s JVM. Abbot reads the coordinates of Swing components from internal Java objects, and then issues mouse and keystroke commands to simulate user actions according to a script. My observation is that the mouse clicks are off target. Specifically, Abbot is aiming to hit the exact center of each component, but it misses either high or low. (Left and right centering seem fine.) The amount of the miss has something to do with my Task Bar. When the Windows Task Bar is locked at top, then the clicks miss below (i.e., lower on the screen) the intended component. When the Task Bar is docked to the right, left, or bottom, or if it is at the top and set to auto-hide then mouse clicks miss above the intended component. Thanks for the problem report. I did some testing against Xserver 1.7.1 with xevent [1] and xdotool [2] to position the mouse pointer, but I wasn't able to reproduce the behaviour you are seeing. I really have no idea how to get started using abbot to reproduce the problem you see, a simple test case would help a lot here. [1] http://www.isv.uu.se/~ziemann/xevent/ [2] http://www.semicomplete.com/projects/xdotool/ -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: checkX problems
From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree- ow...@cygwin.com] On Behalf Of Lothar Brendel Could you please clarify an issue here? (Sorry, it seems, I wronged to ``run'' in the previous posts.) In a Windows command prompt (being somewhere on C:) I put the line \cygwin\bin\run -p /usr/bin sleep -wait 5 into a file ``dosleep.bat''. Executing that BAT-script (w/o any wrapper), it *does* sleep. Typing that very line directly at the prompt lets ``run'' return immediately, though. Can you confirm this behaviour? I can confirm that without testing (so I'm probably chomping foot here...). The sleep is holding the console open after run quits. This comes under the console programs must have a console heading. It takes a bit ti get used to, but you'll get it soon. Looking forward to reading your patches to address any of these problems. It shouldn't be too hard to add an option to checkX to make it retry if ECONNREFUSED. This would have to manually track the elapsed time for each attempt, charging against the specified -t waittime. Another possibility would be an option ``-n'' to specify the number of retries. GAH! No, that's just lame. Just spawn/fork a sleep-then-interrupt-daddy thread/process, set up a SIGINT handler that exits with an error, loop connection attempts until successful, check X, kill child, exit with success. That enforces both types of timeout. HTH, Mike
