Re: X11R7.5 and C.UTF-8

2009-11-03 Thread Andy Koppe
2009/11/3 Jon TURNEY:
> On second look, this patch doesn't seem to be quite right, as it makes the
> en_US.UTF-8 compose sequences available in C.UTF-8 (which is not the case in
> the C locale).

I think that's ok. The compose sequences don't make sense in an ASCII
locale, since ASCII doesn't contain composed characters. Yet they can
be very useful in a UTF-8 locale, so it would be a shame to remove
them. Also, the en_US.UTF-8 compose sequences aren't actually
English-specific, since the vast majority of non-English UTF-8 locales
use the same sequences.

Andy

--
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: Problem installing cygwin/X on vista sp2 64bit

2009-11-03 Thread Larry Hall (Cygwin X)

On 11/02/2009 03:11 PM, Massimo Giovannini wrote:

Hi, I think I managed to obtain the cygcheck.out, which I attached after
having added C:\cygwing\bin to the path of windows.
Yes I am not an expert of unix and I am sorry, but I need this
application  to run Matlab on a cluster in interactive fashion.


So do you just need the X server?  Perhaps a pure Win32 one would be easier
for you.  See .


Another question: normally when I launched cygwin on my old laptop,
there  was a prompt telling my working directory, now I just get bash-3.2, why is 

that?

Same reason as all the other problems.  Your postinstall scripts didn't run.

I don't see any clear indicaton why these would fail given your cygcheck output.
Are you sure that the Lenovo Client Security Solution isn't getting in your way
(i.e. )?  That's all I can see/think of.
If that's not it, you may find that you can either:

  1. Just re-run 'setup.exe' again and it could fix what it tripped over 
the last time.

  2. Try 1.7 instead. 

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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

2009-11-03 Thread Gery Herbozo Jimenez

 <4af080a4.7050...@tlinx.org>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0



Hi Linda=2C
=20
Thanks for your answer and explanation. I just press the Xserver icon and t=
hen the xterm (most of the time) appears. If not=2C I press the xterm icon.=
 Simple like that. I don't write "run" or something like that in anycase.
=20
Hope this helps=2C
=20
Cheers=2C=20
Gery

=20
> Date: Tue=2C 3 Nov 2009 11:12:36 -0800
> From: cyg...@tlinx.org
> To: mail...@fievel.be
> CC: cygwin-xf...@cygwin.com=3b gameji...@hotmail.com
> Subject: Re: 'run xterm' fails to open a window
>=20
> Florent Fievez wrote:
>> I've exactly the same issue=2C so if you find a solution=2C please post =
it ! =3B-)=20
>> 2009/11/3 Ken Brown  wrote::
>>> "'run xterm' fails to pen a window":
>>> I don't know if this is a problem with run=2C or xterm=2C or=20
>>> something else.=20
>>> ...
>>> Obviously I have no good reason to want to start an xterm via 'run xter=
m' in
>>> an xterm window=2C but this issue is causing problems in a script I'm w=
riting.
>>> [Briefly=2C I have a desktop shortcut with target '\path\to\run.exe bas=
h -c
>>> foo.sh'. The script foo.sh calls xterm=2C which starts with no visible
>>> window=2C exactly as above.]
> ---
>=20
> I have two responses=2C 1=2C mostly to Florent Fieves=2C the other to bot=
h
> Florent=2C and Ken Brown who wrote that he also has the problem=20
>=20
> 1) to Florent Fievee=2C (you don't need to answer if you have no good
> reason=2C but if you do=2C I'm curious as to your reasoning) --=20
>=20
> Why did you copy Ken's complete note as into your response=2C when you
> simply has to say "me too"?
>=20
>=20
> 2) to both Florent and Ken?
>=20
> In addition to Gery Herbozo Jimenez's response and question to you=2C
> ( "Have you tried just starting the XWin server first and the the
> xterm? it looks like the X server doesn't recognize that line
> command." )=2C=20
>=20
> a) Have you tried starting 'xterm' without 'run' ?=20
>=20
> b) I see you have started 'Xwin'. Do either of you know what display
> 'XWin' started itself on?=20
>=20
> If you specified no value=2C it probably created the display ":0.0".
>=20
> If you then open a 'client' program that needs to attach to your
> Xwin display=2C "you" need to ensure that the new client knows what
> "X display" your client connects to (usually=2C ":0.0"). A well
> behaved X client won't make assumptions about what display to use.
>=20
> If you were running entirely under *nix=2C any X clients you opened
> afterwards would use the the display passed in the Environment via
> 'DISPLAY'. However=2C both of you appear to be starting Xwin with
> no preset value of 'DISPLAY' AND passing>>NO<< (of=20
> DISPLAY) to the 'X client' program=2C 'xterm'=2C in order to tell it
> what 'X display' to use.
>=20
>=20
> You both appear to be doing the same thing. You both start an Xserver
> in background (which is normal and what I do as well). You then appear
> to be starting a client ('xterm')=2C in a separate "session" (an empty
> Xsession=2C with no display). In order for an X client to display to=20
> an Xserver=2C it needs to know what display to open it's output window
> on.
>=20
> Suggestions:=20
> 1) Don't use the cygwin command 'run.exe' unless you are
> calling Windows programs.=20
>=20
> 2) Explicitly tell xterm what display to use. Set the value of
> the environment var 'DISPLAY' before you all xterm.
>=20
> Ex. Using the Windows 'Run' command (from the start menu=2C using the
> builtin Windows 'Run' option on the start menu):
>=20
> \bin\bash.exe -c 'DISPLAY=3D:0 xterm'
>=20
> for cygwin path=3D'C:\cygwin':
>=20
> C:\cygwin\bin\bash.exe -c 'DISPLAY=3D:0 xterm'
> or
> C:\cygwin\bash\bash.exe -c 'xterm -display :0'=20
>=20
> for cygwin path=3D 'C:\': (my value)
>=20
> C:\bin\bash.exe -c 'DISPLAY=3D:0 xterm'
>=20
> or
>=20
> C:\bash\bash.exe -c 'xterm -display :0'=20
>=20
>=20
> The above two commands work on WinXP and Vista under the 1.5.x series
> of Cygwin.=20
>=20
> Linda
>=20
_
Deja que Sietes te ense=F1e todo los secretos de Windows
http://www.sietesunpueblodeexpertos.com/=

--
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

2009-11-03 Thread Linda Walsh

Gery Herbozo Jimenez wrote:

Thanks for your answer and explanation. I just press the Xserver icon and
t hen the xterm (most of the time) appears. If not, I press the xterm
icon.  Simple like that. I don't write "run" or something like that in
anycase.

---
  Oddly enough, I find the menu items less reliable (by grouping):

  Under cygwin:
 - MinTTY, rxvt-unicode-xS, rxvt-unicode-xC: work
 - rxvt-x, rxvt-native   (*pseudo* work: come up w/poopy doublewide-font)

  Under cygwin/cygwin-X 
 - oclock works, but not xclock.

 - rxvt works (perversely, w/double-wide chars)
 - none of the rest work

  Under cygwin/cygwin-X/Toys:
 - glxgears, xeyes, xlogo, ico---  all work
 - xgc doesn't work from menu   (but does from Bash).

  Under cygwin/cygwin-x/tools:
 - only xev and xrefresh work
 - idle gives a path-not-found message (may not be installed)
 - the rest give no output, but start a process (that sits in
   background until I kill it).

  Under cygwin-xgames, texteroids brings up a window, then immediately
 exits.  From bash, I see the error message:

|  %% DPS Client Library Warning:
| Auto-launching DPS NX agent.
|  %% DPS Client Library Warning:
| FAILED to auto-launch:
| dpsnx.agent
|
|  texteroids: DPS is not available.
|  You need an X server with the DPS extension, or a DPS NX agent.
 

Hope this helps.


  In some way.  It lets me know that my reasoning for doing
workarounds, that I implemented years ago, were done for good
reason.  The default menu items don't work reliably in some
environments (like mine).  

  It is interesting to check out things I didn't even know I had 
installed! :-)


  I don't regard any of the above that don't work as 'bugs', as I 
don't know what some of them are *supposed* to do, and it could easily be

I have something interfering in my path.  I'd have to go through each menu
item in its properties and figure out why they didn't work before I'd call
them a bug -- some may be left over menu items that didn't get deleted
"properly' when an app was moved or uninstalled.  

  I see at least a few, in my setup, that still reference 
/usr/X11R6/bin for executables, when their executable is now under 
/usr/bin (though some executables are under my /usr/X11R6/bin -- maybe 
alien binaries; again, I'd only report something as a bug if I was

pretty sure it wasn't unique to my setup;  I do too many non-standard
things; :-) ).

  I don't know how the shortcut got left around, so I certainly 
wouldn't report it as "bug" or problem to the cygwin list.



  Another potential source of problem I found today, while playing
around.

I had the  setting of LANG set to incorrect value 'en_US.utf8', but it
should be 'en_US.utf-8' for some applications that 'care'.  :-)

Same could could for CTYPE or some of the LC prefixed vars -- if they are
set incorrectly it might prevent one of the X utils opening properly when
called by run.

To set those values, you need to alter them in 'System properties',
Advanced -> "Environment Variables".  I have LANG in my "System variables"
section, but DISPLAY, I made a 'User' variable.  I see LANG being SYSTEM
wide.  I see DISPLAY as only being valid with my login as it's only
when I login that the Xserver is started (I autostart it via a shortcut
in my Programs->Startup Menu group).

Linda Yakinalotski
:-)




--
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: Cygwin 1.7 beta XWin Crashs from Ubuntun 9.10 after Firefox sessions

2009-11-03 Thread ERIC HO
Hi Jon, the crash is not caused by doing some specific action or looking at 
specific
pages in firefox.  Sometimes I sit on the Firefox screen and the cash happens.
I ssh to the the remote Ubuntu Box and start up a gnome-session  there back to 
my display. I then bring up the firefox on the Ubuntu box. After a few clicks, 
the cygwin Xserver died.
I tried starting the X server with -multiwindow, but could not even get a 
complete GNOME screen back.
I've tried  -query but did not get a screen back. It could be only ssh is 
allowed into the Ubuntu box.

Thanks.

- Original Message -
From: Jon TURNEY 
Date: Tuesday, November 3, 2009 12:58 pm
Subject: Re: Cygwin 1.7 beta XWin Crashs from Ubuntun 9.10 after Firefox 
sessions
To: ERIC HO 
Cc: cygwin-xfree@cygwin.com

> 
> Thanks for the backtrace.
> 
> It's interesting, but I'm afraid it doesn't immediately let me 
> pinpoint the 
> problem.
> 
> A couple of questions I should have asked before:
> - is this crash caused by to doing some specific action or 
> looking at specific 
> pages in firefox?
> - using ssh with your X server in a window but no WM is rather 
> strange. Are 
> you starting any other programs or a window manager along with 
> firefox? Do you 
> see the problem if you start the X server with -multiwindow? Do 
> you see the 
> problem if you use -query to do an XDMCP login?
> 
> In future, please send your replies to the cygwin-xfree list, 
> rather than to 
> me personally.
> 
> On 01/11/2009 20:32, ERIC HO wrote:
> > Hi Jon, the message are as follows:
> > (gdb) run
> > Starting program: /home/eho/XWin-1.7.1-1.unstripped.exe -clipboard
> > [New thread 1120.0x720]
> > [New thread 1120.0x1374]
> > Welcome to the XWin X Server
> > Vendor: The Cygwin/X Project
> > Release: 1.7.1.0 (10701000)
> > Build Date: 2009-11-01
> >
> > Contact: cygwin-xfree@cygwin.com
> >
> > XWin was started with the following command line:
> >
> > /home/eho/XWin-1.7.1-1.unstripped -clipboard
> >
> > _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
> > _XSERVTransOpen: transport open failed for inet6/IBM-6963EB6C3F2:0
> > _XSERVTransMakeAllCOTSServerListeners: failed to open listener 
> for inet6
> > warning: Lowest section in 
> /cygdrive/c/WINDOWS/system32/wmi.dll is 
> .text    at 76d31000
> > winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
> > (II) xorg.conf is not supported
> > (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for 
> more informa   tion
> > winPrefsLoadPreferences: /etc/X11/system.XWinrc
> > LoadPreferences: Done parsing the configuration file...
> > winGetDisplay: DISPLAY=:0.0
> > winDetectSupportedEngines - Windows NT/2000/XP
> > winDetectSupportedEngines - DirectDraw installed
> > winDetectSupportedEngines - DirectDraw4 installed
> > winDetectSupportedEngines - Returning, supported engines 0007
> > winSetEngine - Using Shadow DirectDraw NonLocking
> > winAdjustVideoModeShadowDDNL - Using Windows display depth of 
> 32 bits 
> pe   r pixel
> > winFinishScreenInitFB - Masks: 00ff ff00 00ff
> > Screen 0 added at XINERAMA coordinate (0,0).
> > MIT-SHM extension disabled due to lack of kernel support
> > XFree86-Bigfont extension local-client optimization disabled 
> due to 
> lack    of shared memory support in the 
> kernel
> > (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so
> > (II) GLX: Initialized DRISWRAST GL provider for screen 0
> > [dix] Could not init font path element /usr/share/fonts/OTF/, 
> removing f   rom list!
> > [New thread 1120.0x2098]
> > winPointerWarpCursor - Discarding first warp: 509 336
> > (--) 5 mouse buttons found
> > (--) Setting autorepeat to delay=500, rate=31
> > (--) winConfigKeyboard - Layout: "0409" (0409)
> > (--) Using preset keyboard for "English (USA)" (409), type "4"
> > Rules = "base" Model = "pc105" Layout = "us" Variant = "none" 
> Options =    "none"
> > winProcEstablishConnection - Hello
> > winInitClipboard ()
> > [New thread 1120.0xee0]
> > winProcEstablishConnection - winInitClipboard returned.
> > winClipboardProc - Hello
> > DetectUnicodeSupport - Windows NT/2000/XP
> > winGetDisplay: DISPLAY=:0.0
> > winClipboardProc - DISPLAY=:0.0
> > [New thread 1120.0x2338]
> > [New thread 1120.0x2594]
> > winClipboardProc - XOpenDisplay () returned and successfully 
> opened the display.
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x005168a1 in damageRegionAppend (pDrawable=0x103bd878,
> >  pRegion=0x22cbcc, clip=1, 
> subWindowMode=0)>  at 
> /opt/wip/cygport-svn/xorg-server/xorg-server-1.7.1-1/src/xorg-
> server-1.7.1/miext/damage/damage.c:290
> > 290 /opt/wip/cygport-svn/xorg-
> server/xorg-server-1.7.1-1/src/xorg-server-
> 1.7.1/miext/damage/damage.c: No such file or directory.
> >  

Re: Cygwin 1.7 beta XWin Crashs from Ubuntun 9.10 after Firefox sessions

2009-11-03 Thread Jon TURNEY


Thanks for the backtrace.

It's interesting, but I'm afraid it doesn't immediately let me pinpoint the 
problem.


A couple of questions I should have asked before:
- is this crash caused by to doing some specific action or looking at specific 
pages in firefox?
- using ssh with your X server in a window but no WM is rather strange. Are 
you starting any other programs or a window manager along with firefox? Do you 
see the problem if you start the X server with -multiwindow? Do you see the 
problem if you use -query to do an XDMCP login?


In future, please send your replies to the cygwin-xfree list, rather than to 
me personally.


On 01/11/2009 20:32, ERIC HO wrote:

Hi Jon, the message are as follows:
(gdb) run
Starting program: /home/eho/XWin-1.7.1-1.unstripped.exe -clipboard
[New thread 1120.0x720]
[New thread 1120.0x1374]
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.7.1.0 (10701000)
Build Date: 2009-11-01

Contact: cygwin-xfree@cygwin.com

XWin was started with the following command line:

/home/eho/XWin-1.7.1-1.unstripped -clipboard

_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/IBM-6963EB6C3F2:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
warning: Lowest section in /cygdrive/c/WINDOWS/system32/wmi.dll is .text
at 76d31000
winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
(II) xorg.conf is not supported
(II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more informa
   tion
winPrefsLoadPreferences: /etc/X11/system.XWinrc
LoadPreferences: Done parsing the configuration file...
winGetDisplay: DISPLAY=:0.0
winDetectSupportedEngines - Windows NT/2000/XP
winDetectSupportedEngines - DirectDraw installed
winDetectSupportedEngines - DirectDraw4 installed
winDetectSupportedEngines - Returning, supported engines 0007
winSetEngine - Using Shadow DirectDraw NonLocking
winAdjustVideoModeShadowDDNL - Using Windows display depth of 32 bits pe
   r pixel
winFinishScreenInitFB - Masks: 00ff ff00 00ff
Screen 0 added at XINERAMA coordinate (0,0).
MIT-SHM extension disabled due to lack of kernel support
XFree86-Bigfont extension local-client optimization disabled due to lack
of shared memory support in the kernel
(II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so
(II) GLX: Initialized DRISWRAST GL provider for screen 0
[dix] Could not init font path element /usr/share/fonts/OTF/, removing f
   rom list!
[New thread 1120.0x2098]
winPointerWarpCursor - Discarding first warp: 509 336
(--) 5 mouse buttons found
(--) Setting autorepeat to delay=500, rate=31
(--) winConfigKeyboard - Layout: "0409" (0409)
(--) Using preset keyboard for "English (USA)" (409), type "4"
Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options =   
 "none"
winProcEstablishConnection - Hello
winInitClipboard ()
[New thread 1120.0xee0]
winProcEstablishConnection - winInitClipboard returned.
winClipboardProc - Hello
DetectUnicodeSupport - Windows NT/2000/XP
winGetDisplay: DISPLAY=:0.0
winClipboardProc - DISPLAY=:0.0
[New thread 1120.0x2338]
[New thread 1120.0x2594]
winClipboardProc - XOpenDisplay () returned and successfully opened the display.

Program received signal SIGSEGV, Segmentation fault.
0x005168a1 in damageRegionAppend (pDrawable=0x103bd878,
 pRegion=0x22cbcc, clip=1, subWindowMode=0)
 at 
/opt/wip/cygport-svn/xorg-server/xorg-server-1.7.1-1/src/xorg-server-1.7.1/miext/damage/damage.c:290
290 
/opt/wip/cygport-svn/xorg-server/xorg-server-1.7.1-1/src/xorg-server-1.7.1/miext/damage/damage.c:
 No such file or directory.
 in 
/opt/wip/cygport-svn/xorg-server/xorg-server-1.7.1-1/src/xorg-server-1.7.1/miext/damage/damage.c
(gdb) bt full
#0  0x005168a1 in damageRegionAppend (pDrawable=0x103bd878,
 pRegion=0x22cbcc, clip=1, subWindowMode=0)
 at 
/opt/wip/cygport-svn/xorg-server/xorg-server-1.7.1-1/src/xorg-server-1.7.1/miext/damage/damage.c:290
 pScreen = (ScreenPtr) 0x1008c8e8
 pScrPriv = (DamageScrPrivPtr) 0x1008da38
 pDamage = (DamagePtr) 0x104ec960
 pNext = (DamagePtr) 0x100944d0
 clippedRec = {extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 0},
   data = 0x61c8a8}
 pDamageRegion = (RegionPtr) 0x1008a990
 pixClip = {extents = {x1 = -13416, y1 = 34, x2 = -5217,
 y2 = 83}, data = 0x103bd890}
 draw_x = 6386704
 draw_y = 2280360
 screen_x = 0
 screen_y = 0
#1  0x00516d29 in damageDamageBox (pDrawable=0x103bd878,
 pBox=0x22cc10, subWindowMode=0)
 at 
/opt/wip/cygport-svn/xorg-server/xorg-server-1.7.1-1/src/xorg-server-1.7.1/miext/damage/damage.c:425
 region = {extents = {x1 = 5, y1 = 152, x2 = 22, y2 = 169},
   dat

Re: X11R7.5 and C.UTF-8

2009-11-03 Thread Jon TURNEY

On 29/10/2009 20:20, Andy Koppe wrote:

2009/10/29 Jon TURNEY:

I've put a patch in bugzilla [1] which can be applied to
/usr/share/X11/locale to temporarily repair this problem.

This needs to be looked at more deeply, though, as I'm not sure I've fully
understood what that locale data is being used for, or specified C.UTF-8
correctly.

[1] http://sourceware.org/bugzilla/show_bug.cgi?id=10870


I think the patch makes plenty of sense in mapping C.UTF-8 to
en_US.UTF-8, because most other UTF-8 locales are also mapped to
en_US.UTF-8, i.e. from X's perspective they're not actually
language-specific.


On second look, this patch doesn't seem to be quite right, as it makes the 
en_US.UTF-8 compose sequences available in C.UTF-8 (which is not the case in 
the C locale).



More generally, there's the issue that Cygwin allows any combination
of language and charset, whereas X has a fixed list of permitted
combinations. Cygwin also supports many charsets that aren't supported
by X (and vice versa). In particular, X only supports a few of the
Windows/DOS codepages. But I guess unsupported locales will just have
to be a case of "don't do that"?


Yes.

Treating XSupportsLocale() returning false as a fatal error as the Xserver 
currently does is wrong, I would say, unless the application has very specific 
requirement, though.



--
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

2009-11-03 Thread Linda Walsh

Florent Fievez wrote:
I've exactly the same issue, so if you find a solution, please post it ! ;-) 
2009/11/3 Ken Brown  wrote::

 "'run xterm' fails to pen a window":
I don't know if this is a problem with run, or xterm, or 
something else. 
...

Obviously I have no good reason to want to start an xterm via 'run xterm' in
an xterm window, but this issue is causing problems in a script I'm writing.
 [Briefly, I have a desktop shortcut with target '\path\to\run.exe bash -c
foo.sh'.  The script foo.sh calls xterm, which starts with no visible
window, exactly as above.]

---

  I have two responses, 1, mostly to Florent Fieves, the other to both
Florent, and Ken Brown who wrote that he also has the problem 


1) to Florent Fievee, (you don't need to answer if you have no good
  reason, but if you do, I'm curious as to your reasoning) -- 
 
 Why did you copy Ken's complete note as into your response, when you

 simply has to say "me too"?


2) to both Florent and Ken?

  In addition to Gery Herbozo Jimenez's response and question to you,
  ( "Have you tried just starting the XWin server first and the the
  xterm? it looks like the X server doesn't recognize that line
  command." ), 

  a) Have you tried starting 'xterm' without 'run' ? 


  b) I see you have started 'Xwin'.  Do either of you know what display
 'XWin' started itself on?  
  
 If you specified no value, it probably created the display ":0.0".


 If you then open a 'client' program that needs to attach to your
Xwin display, "you" need to ensure that the new client knows what
 "X display" your client connects to (usually, ":0.0").  A well
 behaved X client won't make assumptions about what display to use.

 If you were running entirely under *nix, any X clients you opened
 afterwards would use the the display passed in the Environment via
 'DISPLAY'.  However, both of you appear to be starting Xwin with
 no preset value of 'DISPLAY'   AND  passing  >>NO<<  (of 
 DISPLAY) to the 'X client' program, 'xterm', in order to tell it

 what 'X display' to use.


You both appear to be doing the same thing.  You both start an Xserver
in background (which is normal and what I do as well).  You then appear
to be starting a client ('xterm'), in a separate "session" (an empty
Xsession, with no display).  In order for an X client to display to 
an Xserver, it needs to know what display to open it's output window

on.

Suggestions: 
 1) Don't use the cygwin command 'run.exe' unless you are
calling Windows programs.  


 2) Explicitly tell xterm what display to use.  Set the value of
 the environment var 'DISPLAY' before you all xterm.

 Ex. Using the Windows 'Run' command (from the start menu, using the
 builtin Windows 'Run' option on the start menu):

   \bin\bash.exe -c 'DISPLAY=:0 xterm'

   for cygwin path='C:\cygwin':

  C:\cygwin\bin\bash.exe -c 'DISPLAY=:0 xterm'
or
  C:\cygwin\bash\bash.exe -c 'xterm -display :0' 


   for cygwin path= 'C:\': (my value)

  C:\bin\bash.exe -c 'DISPLAY=:0 xterm'

or


 C:\bash\bash.exe -c 'xterm -display :0' 



The above two commands work on WinXP and Vista under the 1.5.x series
of Cygwin.  


Linda


--
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: Problem installing cygwin/X on vista sp2 64bit

2009-11-03 Thread Massimo Giovannini




So do you just need the X server?  Perhaps a pure Win32 one would be easier
for you.  See .


Great!! This works perfect. Thank you so much!




--
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: Problem installing cygwin/X on vista sp2 64bit

2009-11-03 Thread Linda Walsh

Massimo Giovannini wrote:

Hi,
I have always installed and used cygwinX on my windows Xp 
machines without any problem.
I have been trying to install on my new Vista 64 bit laptop 
and I cannot figure out what is going wrong. 

---

  W e l c o m e   t o   V i s t a !

:-)

I've been going through similar pains playing with a still not fully
functional Vista machine (still awaiting a Win7 upgrade as well).  


Even though you got the standalone X-server to work, FWIW, on
Vista, you could also be running into permission problems even as
Admin.  Many files and directories don't have write permission enabled
for Admin.  To enable them you have to 'get violent' with Vista  and
reclaim directories you want write access to by taking over their
ownership and then making it so you have r/w access.  If you do this,
take care to note the original owner and/or accesses to make sure that
any group/ID that had access before ('TrustedInstaller', 'SYSTEM') also
has the same (usually full control) access after you take ownership.

The prompt in your cygwin window being 'broken' is possibly a symptom
of that.  By default, I found that I couldn't add files to my root
directory (a good thing, actually, too many apps still try to install
stuff there, and a default "no files" prevents accidental clutter).

Just thought I'd add an addendum, though looks like Larry gave you
the exact solution you needed.

Linda

--
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

2009-11-03 Thread Gery Herbozo Jimenez


Have you tried just starting the XWin server first and the the xterm? it looks 
like the X server doesn't recognize that line command.


 
> Date: Tue, 3 Nov 2009 09:27:23 -0500
> From: kbr...@cornell.edu
> To: cygwin-xfree@cygwin.com
> Subject: 'run xterm' fails to open a window
> 
> I don't know if this is a problem with run, or xterm, or something else. 
> If I start the X server and then type 'run xterm' in an xterm window, 
> the xterm process starts but does not open a window. Here's what 'ps' 
> shows before and after 'run xterm':
> 
> $ ps
> PID PPID PGID WINPID TTY UID STIME COMMAND
> 780 1 780 780 ? 1006 08:50:17 /usr/bin/mintty
> I 2932 780 2932 1480 0 1006 08:50:17 /usr/bin/bash
> 384 1 1708 2740 0 1006 08:50:32 /usr/bin/XWin
> 2648 384 2648 3064 ? 1006 08:51:07 /usr/bin/xterm
> 528 2648 528 3016 1 1006 08:51:11 /usr/bin/bash
> 3144 528 3144 1464 1 1006 09:05:28 /usr/bin/ps
> 
> $ run xterm
> 
> $ ps
> PID PPID PGID WINPID TTY UID STIME COMMAND
> 780 1 780 780 ? 1006 08:50:17 /usr/bin/mintty
> I 2932 780 2932 1480 0 1006 08:50:17 /usr/bin/bash
> 384 1 1708 2740 0 1006 08:50:32 /usr/bin/XWin
> 2648 384 2648 3064 ? 1006 08:51:07 /usr/bin/xterm
> 528 2648 528 3016 1 1006 08:51:11 /usr/bin/bash
> 3452 1 3452 3452 con 1006 09:05:57 /usr/bin/xterm
> 4088 528 4088 3664 1 1006 09:06:01 /usr/bin/ps
> 
> Obviously I have no good reason to want to start an xterm via 'run 
> xterm' in an xterm window, but this issue is causing problems in a 
> script I'm writing. [Briefly, I have a desktop shortcut with target 
> '\path\to\run.exe bash -c foo.sh'. The script foo.sh calls xterm, which 
> starts with no visible window, exactly as above.]
> 
> I've attached cygcheck output and the XWin log.
> 
> Ken
> 
> 
_
Date una vuelta por Sietes y conoce el pueblo de los expertos en Windows 7
http://www.sietesunpueblodeexpertos.com/

--
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

2009-11-03 Thread Dees
Jon/others in list,
Any updates? Let me know if you are stuck somewhere.
Many Thanks,
Shefali

On Fri, Oct 30, 2009 at 2:36 PM, 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 TURNEY  
> 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!!!
>
>>
>>> 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.
>
> I have been using Netbeans IDE for compiling and running java code,
> which creates an executable jar. For your convenience, I am attaching
> the same with this mail. You can observe the current behavior by
> running directly this file without the need to compile the source code
> (as specified above), using:
>        # /usr/java/jdk1.5.0_14/bin/java -jar TreeTester.jar
> 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.
>
> Let me know if you need any other specific details or come across any
> other issue.
>
>>
>> --
>> Jon TURNEY
>> Volunteer Cygwin/X X Server maintainer
>>
>
> Regards,
> Shefali
>

--
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/