Re: X under full keyboard control
Takuma, Takuma Murakami wrote: Michael, I don't know what you mean with "hook DLL" though. I'm not sure if we need a separate DLL... See this article and follow links in it for details. http://sources.redhat.com/ml/cygwin-xfree/2004-02/msg00149.html Here is why we don't need a separate DLL for hooking these keyboard messages, from MSDN: "A global hook monitors messages for all threads in the same desktop as the calling thread. A thread-specific hook monitors messages for only an individual thread. A global hook procedure can be called in the context of any application in the same desktop as the calling thread, so the procedure must be in a separate dynamic-link library (DLL) module. A thread-specific hook procedure is called only in the context of the associated thread. If an application installs a hook procedure for one of its own threads, the hook procedure can be in either the same module as the rest of the application's code or in a DLL. If the application installs a hook procedure for a thread of a different application, the procedure must be in a DLL. For information, see Dynamic-Link Libraries." You see, we are only hooking messages in our own thread, so this approach works fine. The reason we keep mentioning a hook DLL is that we also want to hook mouse messages when our application is not receiving mouse events; in those cases the hook is processed in the context of whatever process/thread is currently receiving mouse events, which is why those "global" hooks need to be DLLs. The only problem with the hook approach for the key combinations in question is that it will only work for NT-based platforms and for only those running NT 4.0 SP3 or later; we will need to check for this before we turn on this hook and we need to make sure that all of this is conditional on whether or not this feature is enabled at runtime or not. I would go ahead and make this the default, but I would add a runtime option called "-nokeyhook" that allows it to be turned off on platforms that support it. Harold
Re: Various starting X problems
Harold L Hunt II wrote: > Well, then don't feel upset that I'm disregarding your 2c. > > "[...] breaks all sorts of existing scripts [...]" is pretty hard to > believe since it took the collective mailing list two weeks to even > notice the move. I had an "exec /usr/X11R6/bin/xterm" in my XWin.rc and wondered why xterm did not start up. I've changed it in no time but I think it is more applicable to place xterm in /usr/X11R6/bin because it is there on nearly any unix platform (or at least in a directory like /usr/dt/bin or /usr/X/bin). bye ago NP: Velvet Acid Christ - Haunted -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: X under full keyboard control
Michael, > I don't know what you mean with "hook DLL" though. I'm not sure if we need a separate DLL... See this article and follow links in it for details. http://sources.redhat.com/ml/cygwin-xfree/2004-02/msg00149.html Takuma Murakami
Re: Various starting X problems
On Fri, 2 Apr 2004, Harold L Hunt II wrote: > Igor Pechtchanski wrote: > > Harold, > > > > On Thu, 1 Apr 2004, Harold L Hunt II wrote: > > > >>Igor, > >> > >>Igor Pechtchanski wrote: > >> > >>>On Thu, 1 Apr 2004, Harold L Hunt II wrote (irrelevant parts snipped): > >>> > Phil Betts wrote: > > >Luke said: > > > >>>In my .xinitrc I *don't* have an explicit path for xterm. However, I > >>>see xterm has moved from /usr/X11R6/bin to /usr/bin! Did many other > > > >Slightly OT: I noticed that the start menu entry for xterm no longer > >works. Entering the command from the shortcut directly into the cmd.exe > >shell returns without an error or any output (that I can find). From > >bash, the command works fine. The other shortcuts that I've tried > >(e.g.. xcalc) all worked, so there is presumably something unusual about > >the way that xterm starts that causes a silent exit when started from a > >vanilla DOS/Windows shell. My guess is that it's relying on some env > >var. > > I'm aware of this. I don't remember the exact details, but there is a > sort of Catch-22 situation for setting the "start in" folder for the > xterm shortcut; neither '/usr/bin' nor '/usr/X11R6/bin' work for > different reasons. Furthermore, I believe that the script that creates > the shortcuts needs to be modified to be able to support shortcuts to > programs that live in /usr/bin. You'll notice that the emacs shortcut > also does not work for the same reason. > >>> > >>>I don't recall any discussion or a heads-up that xterm now resides in > >>>/usr/bin... Any particular reason for this decision? > >> > >>It wasn't a change... the "xterm" package has always been this way since > >>its inception a couple weeks ago. > > > > It was a change from the users' point of view. Their xterm used to be in > > /usr/X11R6/bin, and now it's in /usr/bin all of a sudden. The fact that > > it also moved into a separate package is incidental. > > > >>Chris and I discussed on cygwin-apps that there was no reason to put new > >>X packages in /usr/X11R6 so I have not been doing this for most new X > >>packages; barring those that do broken things and need to be stuck in > >>/usr/X11R6, like libXft. > > > > For new packages -- sure, but moving something as fundamental as xterm is > > not something to be taken lightly. > > > > There *is* a reason to put X11 binaries (and especially libraries) in the > > same directory. The reason is Windows dynamic linking. By default, > > Windows apps look for DLLs in the current directory before looking in the > > PATH. So, for apps that are in /usr/X11R6/bin, all the X DLLs are found > > automatically. Once xterm moves into /usr/bin, either all the DLLs it > > requires should also move there, or /usr/X11R6/bin should be *added* to > > the PATH (it wasn't required before). > > > > Also, moving xterm to /usr/bin breaks all sorts of existing scripts (those > > that hardcode the path to it as /usr/X11R6/bin, because it's not usually > > in the Windows PATH by default). At the very least there should have been > > an announcement declaring in large friendly letters that xterm won't work > > anymore unless you (a) change all your scripts that expect to find it in > > /usr/X11R6/bin, and (b) add /usr/X11R6/bin to your Windows system path, > > otherwise the necessary DLLs won't be found. > > > > Frankly, I think that moving 1 app to /usr/bin doesn't solve the problem, > > it only creates more. If you want to be rid of /usr/X11R6/bin, first move > > all the libraries to /usr/bin, and then move all the apps in one fell > > swoop. Until then, you'll only be causing users unnecessary anguish'. > > Just my 2c. > > Well, then don't feel upset that I'm disregarding your 2c. Harold, If I had a penny for every time my 2c was disregarded, I'd still be losing money... :-) > "[...] breaks all sorts of existing scripts [...]" is pretty hard to > believe since it took the collective mailing list two weeks to even > notice the move. > > Harold Well, people who run xterm from non-login shells will notice this as soon as they upgrade. Maybe they just haven't upgraded yet (I haven't), or I'm one of the very few who invoke X apps this way. FYI, it will break my scripts (embedded in a bunch of shortcuts, FWIW) as soon as I upgrade. To fix this, I plan to create a symlink to /usr/bin/xterm in /usr/X11R6/bin (a good compatibility measure in a postinstall script, BTW). This won't help the DLL loading issue, but that should be fixable by just adding "c:\cygwin\usr\X11R6\bin" to the PATH. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "I have since come to realize
Re: Possible bug trying to run Eclipse GTK?
On Saturday 03 April 2004 01:35, [EMAIL PROTECTED] wrote: > I do think that the FAQ item needs to be clarified to include the > information about the -Y parameter. Could I suggest that the FAQ be changed to something along the lines of | Starting with OpenSSH 3.8 you will need the switch "ForwardX11Trusted yes" | in the client configuration to allow remote clients full access to the | xserver, or use -Y as the paramater instead of -X. Cheers, Rasjid -- Rasjid Wilcox Canberra, Australia (UTC +10 hrs) http://www.openminddev.net
NOTIFICATION OF BEQUEST
ATTENTION;Sir NOTIFICATION OF BEQUEST . This may sound surprising;but you are very lucky,this is sequel to your non response of our earlier letter to you One-half of the Trustees and Executors to the Will of late of Sir Engr.Willy Bubenik (ksm),I wish to notify you that you were listed as a beneficiary to the bequest of the sum of US$5,100.000.00 [Five Million One Hundred Thousand US Dollars] in the codicil and last testament of the deceased. The late Sir Willy Bubenik until his death was a former Managing Director and pioneer staff of a big construction company here in Netherlands. He was a very dedicated Sufis and a great philanthropist during his life time. Late Sir Willy Bubenik died on 9th February 2003 at the age of 68,He was buried on the23rd of February. Late Sir Willy Bubenik even though he was an American living and working in here as a foreigner he requested before his death that he be buried here in his words, "I regard here as My home and the people as my people". He said that this token is to support your ministry and help to the less- privileged. I hereby request that you forward any proof of identities of yours, your current telephone and fax numbers and your forwarding address to enable us file necessary documents at the International Court of Justice probate division for the release of this bequest of money. Congratulations. Yours faithfully, Dr Thomas Van Vugt PS.To be sure you got my email,reply to my personal email address : [EMAIL PROTECTED]
Re: Various starting X problems
Igor Pechtchanski wrote: Harold, On Thu, 1 Apr 2004, Harold L Hunt II wrote: Igor, Igor Pechtchanski wrote: On Thu, 1 Apr 2004, Harold L Hunt II wrote (irrelevant parts snipped): Phil Betts wrote: Luke said: In my .xinitrc I *don't* have an explicit path for xterm. However, I see xterm has moved from /usr/X11R6/bin to /usr/bin! Did many other Slightly OT: I noticed that the start menu entry for xterm no longer works. Entering the command from the shortcut directly into the cmd.exe shell returns without an error or any output (that I can find). From bash, the command works fine. The other shortcuts that I've tried (e.g.. xcalc) all worked, so there is presumably something unusual about the way that xterm starts that causes a silent exit when started from a vanilla DOS/Windows shell. My guess is that it's relying on some env var. I'm aware of this. I don't remember the exact details, but there is a sort of Catch-22 situation for setting the "start in" folder for the xterm shortcut; neither '/usr/bin' nor '/usr/X11R6/bin' work for different reasons. Furthermore, I believe that the script that creates the shortcuts needs to be modified to be able to support shortcuts to programs that live in /usr/bin. You'll notice that the emacs shortcut also does not work for the same reason. I don't recall any discussion or a heads-up that xterm now resides in /usr/bin... Any particular reason for this decision? It wasn't a change... the "xterm" package has always been this way since its inception a couple weeks ago. It was a change from the users' point of view. Their xterm used to be in /usr/X11R6/bin, and now it's in /usr/bin all of a sudden. The fact that it also moved into a separate package is incidental. Chris and I discussed on cygwin-apps that there was no reason to put new X packages in /usr/X11R6 so I have not been doing this for most new X packages; barring those that do broken things and need to be stuck in /usr/X11R6, like libXft. For new packages -- sure, but moving something as fundamental as xterm is not something to be taken lightly. There *is* a reason to put X11 binaries (and especially libraries) in the same directory. The reason is Windows dynamic linking. By default, Windows apps look for DLLs in the current directory before looking in the PATH. So, for apps that are in /usr/X11R6/bin, all the X DLLs are found automatically. Once xterm moves into /usr/bin, either all the DLLs it requires should also move there, or /usr/X11R6/bin should be *added* to the PATH (it wasn't required before). Also, moving xterm to /usr/bin breaks all sorts of existing scripts (those that hardcode the path to it as /usr/X11R6/bin, because it's not usually in the Windows PATH by default). At the very least there should have been an announcement declaring in large friendly letters that xterm won't work anymore unless you (a) change all your scripts that expect to find it in /usr/X11R6/bin, and (b) add /usr/X11R6/bin to your Windows system path, otherwise the necessary DLLs won't be found. Frankly, I think that moving 1 app to /usr/bin doesn't solve the problem, it only creates more. If you want to be rid of /usr/X11R6/bin, first move all the libraries to /usr/bin, and then move all the apps in one fell swoop. Until then, you'll only be causing users unnecessary anguish'. Just my 2c. Well, then don't feel upset that I'm disregarding your 2c. "[...] breaks all sorts of existing scripts [...]" is pretty hard to believe since it took the collective mailing list two weeks to even notice the move. Harold
Re: Various starting X problems
Harold, On Thu, 1 Apr 2004, Harold L Hunt II wrote: > Igor, > > Igor Pechtchanski wrote: > > On Thu, 1 Apr 2004, Harold L Hunt II wrote (irrelevant parts snipped): > > > >>Phil Betts wrote: > >> > >>>Luke said: > >>> > >In my .xinitrc I *don't* have an explicit path for xterm. However, I > >see xterm has moved from /usr/X11R6/bin to /usr/bin! Did many other > >>> > >>>Slightly OT: I noticed that the start menu entry for xterm no longer > >>>works. Entering the command from the shortcut directly into the cmd.exe > >>>shell returns without an error or any output (that I can find). From > >>>bash, the command works fine. The other shortcuts that I've tried > >>>(e.g.. xcalc) all worked, so there is presumably something unusual about > >>>the way that xterm starts that causes a silent exit when started from a > >>>vanilla DOS/Windows shell. My guess is that it's relying on some env > >>>var. > >> > >>I'm aware of this. I don't remember the exact details, but there is a > >>sort of Catch-22 situation for setting the "start in" folder for the > >>xterm shortcut; neither '/usr/bin' nor '/usr/X11R6/bin' work for > >>different reasons. Furthermore, I believe that the script that creates > >>the shortcuts needs to be modified to be able to support shortcuts to > >>programs that live in /usr/bin. You'll notice that the emacs shortcut > >>also does not work for the same reason. > > > > I don't recall any discussion or a heads-up that xterm now resides in > > /usr/bin... Any particular reason for this decision? > > It wasn't a change... the "xterm" package has always been this way since > its inception a couple weeks ago. It was a change from the users' point of view. Their xterm used to be in /usr/X11R6/bin, and now it's in /usr/bin all of a sudden. The fact that it also moved into a separate package is incidental. > Chris and I discussed on cygwin-apps that there was no reason to put new > X packages in /usr/X11R6 so I have not been doing this for most new X > packages; barring those that do broken things and need to be stuck in > /usr/X11R6, like libXft. For new packages -- sure, but moving something as fundamental as xterm is not something to be taken lightly. There *is* a reason to put X11 binaries (and especially libraries) in the same directory. The reason is Windows dynamic linking. By default, Windows apps look for DLLs in the current directory before looking in the PATH. So, for apps that are in /usr/X11R6/bin, all the X DLLs are found automatically. Once xterm moves into /usr/bin, either all the DLLs it requires should also move there, or /usr/X11R6/bin should be *added* to the PATH (it wasn't required before). Also, moving xterm to /usr/bin breaks all sorts of existing scripts (those that hardcode the path to it as /usr/X11R6/bin, because it's not usually in the Windows PATH by default). At the very least there should have been an announcement declaring in large friendly letters that xterm won't work anymore unless you (a) change all your scripts that expect to find it in /usr/X11R6/bin, and (b) add /usr/X11R6/bin to your Windows system path, otherwise the necessary DLLs won't be found. Frankly, I think that moving 1 app to /usr/bin doesn't solve the problem, it only creates more. If you want to be rid of /usr/X11R6/bin, first move all the libraries to /usr/bin, and then move all the apps in one fell swoop. Until then, you'll only be causing users unnecessary anguish'. Just my 2c. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "I have since come to realize that being between your mentor and his route to the bathroom is a major career booster." -- Patrick Naughton
Re: grace
Hi Jack, Dear Volker Q, Volker Z, and anyone else involved: I just build grace 5.1.14 with lesstif 0.93.94 and your XmHTML package. Works and looks beautiful. Would it be possible to release an updated Grace (and lesstif, if necessary)? lesstif is already released (as a test version, use setup to install it.) I could also provide a grace test version, but I thought it would be nice to use XmHTML for the new version. I cannot do that until XmHTML is accepted as official cygwin package, test version or not. *Hint to all package maintainers*: XmHTML is reviewed and good-to-go, but one more vote is needed! If XmHTML doesn't get that vote soon I'll produce a grace test version, again with lynx as help viewer. Volker -- PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D pgp0.pgp Description: PGP signature
Re: Shouldn't we put [cygwin] or [CygXwin] here depending on the question?
On Fri, Apr 02, 2004 at 04:09:36PM +0200, Corinna Vinschen wrote: >On Apr 2 13:51, Michel Bardiaux wrote: >> Christopher Faylor wrote: >> >That's a shame, but please don't ask us >> >> *US* ? I am not at all sure the majority of the members agree with the >> peremptory refusal expressed by a very few. > >Well, "us" in that case is the royal us. Subject tagging won't happen, >so there's no gain in discussing that further. Right. Thinking about this from the context of the age of the project, you'd come to the conclusion that this particular issue has come up many times. Searching the archives, you'd see that the answer is always the same -- sort your email using the headers provided. If this seems unbelievably mean then you have an alternative -- don't use the free service that we (that is again the royal we) have provided. cgf
Re: X under full keyboard control
On Friday 02 April 2004 15:56, Takuma Murakami wrote: > Michael, > > > Is there a way to start X in a way so that all (but one dedicated) > > keycuts are sent to X11. eg I want that alt-tab does not switch > > to another windows-window but is processed by X? > > Cygwin/X has no such capability. We may need a hook DLL > to do it. > > Takuma Murakami Thanx for your reply. I don't know what you mean with "hook DLL" though. I think I just have to live with it then. Thanx again, Michael
RE: Various starting X problems
Hi Harold, >> vanilla DOS/Windows shell. My guess is that it's relying on some env >> var. > >I'm aware of this. I don't remember the exact details, but there is a >sort of Catch-22 situation for setting the "start in" folder for the >xterm shortcut; neither '/usr/bin' nor '/usr/X11R6/bin' work for >different reasons. Furthermore, I believe that the script that creates I've just cracked this on my PC - it was a side effect of moving /usr onto my D: drive. PATH under cmd.exe still had C:\cygwin\usr\X11R6\bin which meant that xterm couldn't link with cygX11-6.dll. This only became an issue once xterm moved to /usr/bin. That point aside, is it not safer to work with /bin instead of /usr/bin ? After all, that is where the files are really located: $ cygpath -w /usr/bin C:\cygwin\bin On my PC, there is no "bin" in the usr directory so .bat files don't stand a chance of finding anything in there! >I don't have time to fix this. I would appreciate it if someone else >would grab the -src package for X-start-menu-icons via setup.exe and >work on fixing it; I don't want a half-assed untested patch either, I >want one that has been thoroughly tested (you know, tough stuff like >clicking at least one of the tree classes of shortcuts: /usr/bin X >programs, /usr/X11R6/bin X programs, and /usr/X11R6/bin terminal >programs) since the sort of changes required may break the other links >that the scripts create (this is part of the Catch-22 I was talking about). If somebody does have time, I guess it's safest to assume (or insist) that users have the result of "cygpath -w /bin" in their Windows PATH, but not necessarily /usr/X11R6/bin. It would therefore work if the shortcut starts in /usr/X11R6/bin. This WFM: Target: D:\cygwin\usr\X11R6\bin\run.exe xterm -display 127.0.0.1:0.0 Start in: D:\cygwin\usr\X11R6\bin Obviously the "D:\cygwin\usr\X11R6\bin" part needs to be worked out at installation time. There does appear to be a problem with run.exe. If the target program can be found, but fails to link, the error is silently swept under the carpet rather than passing on the message to the user. To reproduce: * start a CMD shell * set PATH= * cd to where your /bin lives * type "xterm" * you should get a dialog "xterm.exe - Unable To Locate DLL" with enough information to let you track down the problem * now type xterm * result: no dialog, no error messages, no xterm. >haven't finished it yet. The problems I ran into were that I could get >the paths I needed, but exposing them to the batch file as a variable of >some sort was darn near impossible. Exactly! >Give it a try. Download the X-startup-scripts -src package via I'll see what I can come up with. I've got looming deadlines at work and I've only got flavours of Linux at home so don't hold your breath... >I wouldn't go for the gold yet... just make a batch file that runs the >shell script first so that people can still create Windows shortcuts to >the batch file, then we can go from there. OK. That's what I had in mind anyway. >> There was mention a while ago of making multiwindow a standalone window >> manager. Has anything been done in this direction? > >This isn't really a viable option at this time. Splitting the window Pity, but not a problem. >What I would rather see is some very minor tweaks (I have been thinking >about doing these myself) that let the mutli-window window manager >silently exit without causing a crash if another window manager is >detected. In fact, I would also like to create another dialog box that >lets you check boxes to enable and disable -multiwindow and -clipboard >during the current session. The first thing this will require a is a >continuation of the cleanup that I have been doing to the shutdown >process for the -clipboard code and a cleanup of the shutdown process >for the -multiwindow code. This sounds like a reasonable plan. When I used to run fvwm at home, the system menu had entries for switching to twm, mwm etc. This, I guess, just forked a non-window-manager process to perform the switch then exited (if you tried to switch to a non-existant or broken WM, you ended up with no WM) You'd need to be careful though. Say the user starts X without multiwindow, running an external WM at the end of their ~/.xinitrc. You wouldn't want to kill their WM process if the user tried to switch to multiwindow or some other WM because that would end their X session. In effect, what you need is a way to coerce the running WM to use one of the execxx variants to start the new WM so that the WM PID never dies. This is certainly not trivial! An easier alternative would be to have a small wrapper program, say runwm, whose sole job would be to keep a WM going. The ~/.xinitrc would then end with something like: exec runwm wmaker Killing the wmaker process could either restart wmaker, or perhaps fall back to multiwindow mode. Further attempts to run runwm e.g. "runwm fvwm", w
grace
Dear Volker Q, Volker Z, and anyone else involved: I just build grace 5.1.14 with lesstif 0.93.94 and your XmHTML package. Works and looks beautiful. Would it be possible to release an updated Grace (and lesstif, if necessary)? Thanks in advance.
Re: Re: Possible bug trying to run Eclipse GTK?
Harold, Thanks for your response. Although I try hard not to be an idiot sometimes, it does happen! The original response to my note mentioned the -Y parameter and provided this link http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-ssh-no-x11forwarding. I immediately went to the link and validated that things in my setup matched up to that FAQ item. Unfortunately, I didn't see anything in that FAQ item about the -Y parameter and so I promptly forgot about it. Switching to the -Y parameter does seem to solve the problem, so I definitely appreciate that. I do think that the FAQ item needs to be clarified to include the information about the -Y parameter. A text search on "-Y" on the entire FAQ does not return any hits. So, it isn't so much that I don't believe you guys and I'm not willing to do the work. Instead, I trusted the FAQ to include all of the necessary information rather than realizing the FAQ information needed to be reconciled with the email information I was given. In summary, -Y appears to solve my problem, but I believe the FAQ needs some clarification to avoid others having this problem. Oh, and thanks so much for this project. It helps me build and test my open-source EclipseME plugin for Linux users. Thanks, Craig > > Craig, > > [EMAIL PROTECTED] wrote: > > > OK. I'm fine with all of the FAQ items specified. (Running an older OpenSSH on > > Redhat Linux 9). Here is my XWin.log. > > No, you are not fine unless you tried "ssh -Y" instead of "ssh -X". > > Why? Well, I might just say, "why the heck don't people believe us when > we try to help them?". > > So, would you please clarify if you actually tried "ssh -Y" instead of > "ssh -X"? > > Harold >
Re: Possible bug trying to run Eclipse GTK?
Craig, [EMAIL PROTECTED] wrote: OK. I'm fine with all of the FAQ items specified. (Running an older OpenSSH on Redhat Linux 9). Here is my XWin.log. No, you are not fine unless you tried "ssh -Y" instead of "ssh -X". Why? Well, I might just say, "why the heck don't people believe us when we try to help them?". Here it is: OpenSSH has *supported* trusted X11 tunelling for many versions; it was changed to be the *default* in the OpenSSH 3.8 *client*. So, you can be running an older version of sshd on your Linux box and you're still might have trusted X11 tunnelling turned on by default since you are using OpenSSH 3.8 as your client. Another interesting thing to note is that you can use an ssh client that doesn't support trusted X11 tunelling and you won't have any problems, such as PuTTY (free) or SSH Secure Shell (not free). So, would you please clarify if you actually tried "ssh -Y" instead of "ssh -X"? Harold
Re: /usr/bin/xterm
On Fri, 2 Apr 2004, Harold L Hunt II wrote: > All of the old school X guys (Jim Gettys, Keith Packard, I think Kaleb > Keithley, etc.) all say that /usr/X11R6 is an abomination and the sooner > it goes away the better. It was a fix for the cases where people were running X11R5 and X11R6 clients. The underlying issue doesn't really go away, but we revisit it from time to time. > You can now go back to your old school Unix guy and tell him he needs to > get with the times on what people in the X Window System community are > advocating. ;) hmm - what's that quote from Toynbee? -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: Error starting Xclock and Xterm
Grab the libXft package, you don't have it. Harold Wright, David L wrote: I recently installed all of the new XFree86 packages to a working cygwin installation. Now when I start the X-server, the server starts but I can't start Xclock or Xterm. I get the following message: This application has failed to start because cygXft-2.dll was not found. Re-installing the application may fix this problem. I don't know what package this dll is in so that I can re-download and re-install. Can you help? Thank You, David Wright
Re: /usr/bin/xterm
[EMAIL PROTECTED] wrote: On 1 Apr, Igor Pechtchanski wrote: > I don't have time to fix this. I would appreciate it if someone else > would grab the -src package for X-start-menu-icons via setup.exe and > work on fixing it; I don't want a half-assed untested patch either, I > want one that has been thoroughly tested (you know, tough stuff like > clicking at least one of the tree classes of shortcuts: /usr/bin X > programs, /usr/X11R6/bin X programs, and /usr/X11R6/bin terminal > programs) since the sort of changes required may break the other links > that the scripts create (this is part of the Catch-22 I was talking about). I don't recall any discussion or a heads-up that xterm now resides in /usr/bin... Any particular reason for this decision? I'm certainly interested to hear more. I got some ridicule dumped on me (in my role of Cygwin evangelist) when I mentioned this to an old-time Unix guy here. All of the old school X guys (Jim Gettys, Keith Packard, I think Kaleb Keithley, etc.) all say that /usr/X11R6 is an abomination and the sooner it goes away the better. You can now go back to your old school Unix guy and tell him he needs to get with the times on what people in the X Window System community are advocating. ;) Harold
Re: Re: Possible bug trying to run Eclipse GTK?
OK. I'm fine with all of the FAQ items specified. (Running an older OpenSSH on Redhat Linux 9). Here is my XWin.log. Thanks. Craig Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.66 Contact: [EMAIL PROTECTED] XWin was started with the following command line: XWin -multiwindow -clipboard ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1280 h 1024 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0007 winScreenInit - dwWidth: 1280 dwHeight: 1024 winSetEngine - Multi Window => ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel winCreateBoundingWindowWindowed - User w: 1280 h: 1024 winCreateBoundingWindowWindowed - Current w: 1280 h: 1024 winAdjustForAutoHide - Original WorkArea: 0 0 988 1280 winAdjustForAutoHide - Adjusted WorkArea: 0 0 988 1280 winCreateBoundingWindowWindowed - WindowClient w 1280 h 988 r 1280 l 0 b 988 t 0 winCreateBoundingWindowWindowed - Returning winAllocateFBShadowGDI - Creating DIB with width: 1280 height: 988 depth: 32 winAllocateFBShadowGDI - Dibsection width: 1280 height: 988 depth: 32 size image: 5058560 winAllocateFBShadowGDI - Created shadow stride: 1280 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winRandRInit () winCreateDefColormap - Deferring to fbCreateDefColormap () null screen fn ReparentWindow null screen fn RestackWindow winFinishScreenInitFB - Calling winInitWM. InitQueue - Calling pthread_mutex_init InitQueue - pthread_mutex_init returned InitQueue - Calling pthread_cond_init InitQueue - pthread_cond_init returned winInitWM - Returning. winFinishScreenInitFB - returning winScreenInit - returning winInitMultiWindowWM - Hello winInitMultiWindowWM - Calling pthread_mutex_lock () winMultiWindowXMsgProc - Hello winMultiWindowXMsgProc - Calling pthread_mutex_lock () InitOutput - Returning. 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 (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: "0409" (0409) (EE) Keyboardlayout "US" (0409) is unknown Rules = "xfree86" Model = "pc101" Layout = "us" Variant = "(null)" Options = "(null)" Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from list! winPointerWarpCursor - Discarding first warp: 640 494 winBlockHandler - Releasing pmServerStarted winInitMultiWindowWM - pthread_mutex_lock () returned. winBlockHandler - pthread_mutex_unlock () returned winProcEstablishConnection - Hello winInitClipboard () winProcEstablishConnection - winInitClipboard returned. winClipboardProc - Hello DetectUnicodeSupport - Windows NT/2000/XP winClipboardProc - DISPLAY=127.0.0.1:0.0 winMultiWindowXMsgProc - pthread_mutex_lock () returned. winMultiWindowXMsgProc - pthread_mutex_unlock () returned. winMultiWindowXMsgProc - DISPLAY=127.0.0.1:0.0 winInitMultiWindowWM - pthread_mutex_unlock () returned. winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0 winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display. winClipboardProc - XOpenDisplay () returned and successfully opened the display. winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display. winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning. winMultiWindowXMsgProcErrorHandler - ERROR: BadWindow (invalid Window parameter)
Re: Shouldn't we put [cygwin] or [CygXwin] here depending on the question?
On Apr 2 13:51, Michel Bardiaux wrote: > Christopher Faylor wrote: > >That's a shame, but please don't ask us > > *US* ? I am not at all sure the majority of the members agree with the > peremptory refusal expressed by a very few. Well, "us" in that case is the royal us. Subject tagging won't happen, so there's no gain in discussing that further. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: numlock
> Perhaps he was wondering why NumLock is turned on initially. Cygwin/X just inherits NumLock state from Windows. If NumLock is off when Cygwin/X is invoked, then it is also off in the Cygwin/X. Takuma Murakami
Re: X under full keyboard control
Michael, > Is there a way to start X in a way so that all (but one dedicated) > keycuts are sent to X11. eg I want that alt-tab does not switch > to another windows-window but is processed by X? Cygwin/X has no such capability. We may need a hook DLL to do it. Takuma Murakami
Re: Possible bug trying to run Eclipse GTK?
Craig, Please, check the FAQ entry. "ssh -Y" is the former "ssh -X". http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-ssh-no-x11forwarding And then show your /tmp/XWin.log if your problem remains. Takuma Murakami
Possible bug trying to run Eclipse GTK?
Hello, I'm trying to run Eclipse M8 GTK version via the multiwindow mode. I have no trouble running it in full desktop mode using XDMCP, but when I try to run just Eclipse (via an xterm) using either multiwindow or rootless mode, the application crashes. Strangely, it seems to be fine until I move the cursor over the window and then it crashes. Is this a Cygwin Xfree bug or an Eclipse bug or something else altogether? Here is the error I get: The program '' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 63899 error_code 3 request_code 38 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will recieve the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaninful backtrace from your debugger if you break on the gdk_x_error() function.) Thanks, Craig
Error starting Xclock and Xterm
I recently installed all of the new XFree86 packages to a working cygwin installation. Now when I start the X-server, the server starts but I can't start Xclock or Xterm. I get the following message: This application has failed to start because cygXft-2.dll was not found. Re-installing the application may fix this problem. I don't know what package this dll is in so that I can re-download and re-install. Can you help? Thank You, David Wright
Re: Shouldn't we put [cygwin] or [CygXwin] here depending on the question?
Christopher Faylor wrote: On Thu, Apr 01, 2004 at 11:53:42AM -0600, David wrote: 1) I understand what you feel. But, as I put, " it doesn't seem that I can sort mails to different folders.", I tried, and I realized that I could not make it at all. It turned out that it's impossible to do that with this email account. That's a shame, but please don't ask us *US* ? I am not at all sure the majority of the members agree with the peremptory refusal expressed by a very few. to change the mailing list to accommodate you. Can we stop talking about this now, please? cgf -- Michel Bardiaux Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles Tel : +32 2 790.29.41
Re: Problem report: Netscape program launched from a client server
Tam T Nguyen wrote: > Hi, > > I launched the Netscape program from a remote Sun Solaris machine to be > displayed on a Xterm window of laptop PC using X-Cygwin. The Netscape > could not start and came back with an error message as the followings: > > Error of failed request: Badrawable (invalid Pixmap or Window Parameter) > Major opcode o failed request: 73 (X_GetImage) > Resource ID in failed request: 0x3a > Serial number of failed request: 78 > Current serial number in output stream: 78 > > Exit 1netscape Your using OpenSSHs X11 Forwarding? Try using ssh -Y instead of ssh -X. http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-ssh-no-x11forwarding bye ago NP: Silke Bischoff - The Devils Teeth -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
/usr/bin/xterm (was: Re: Various starting X problems)
On 1 Apr, Igor Pechtchanski wrote: > > I don't have time to fix this. I would appreciate it if someone else > > would grab the -src package for X-start-menu-icons via setup.exe and > > work on fixing it; I don't want a half-assed untested patch either, I > > want one that has been thoroughly tested (you know, tough stuff like > > clicking at least one of the tree classes of shortcuts: /usr/bin X > > programs, /usr/X11R6/bin X programs, and /usr/X11R6/bin terminal > > programs) since the sort of changes required may break the other links > > that the scripts create (this is part of the Catch-22 I was talking about). > > I don't recall any discussion or a heads-up that xterm now resides in > /usr/bin... Any particular reason for this decision? I'm certainly interested to hear more. I got some ridicule dumped on me (in my role of Cygwin evangelist) when I mentioned this to an old-time Unix guy here. luke
Re: Fwd: Re: Various starting X problems
On 1 Apr, Harold L Hunt II wrote: > Luke, > > > > [EMAIL PROTECTED] wrote: > >>>cat: /cygdrive/d/home/luke/.Xauthority: No such file or directory > >>>xinit: No such file or directory (errno 2): no program named > "/usr/X11R6/bin/xterm" in PATH > >> > >> > >> Something else must be wrong with your path. > > > > > > I don't think so. FWIW, here is my full and ugly PATH, wrapped for > > easy reading but no other changes: > > Oh no, once again I am right on this one... read on for a full > explanation of what you need to tell us in the future when you have such > problems. Sorry, there was no way that you could know that the startx.bat script wsa *not* involved; it's only used from the desktop shortcut. It lives in "/", and that's not on my path. > > I definitely have a custom .xinitrc file. In fact part of our site > > post-install process was to create a default one, since initially > > Cygwin's XFree didn't include it. I hadn't realised it was colliding > > with one from Cygwin. Our standard site post-install creates the > > ~/.xinitrc. Sounds like I'd better try to back that out. > > /etc/X11/xinit/xinitrc can be copied to ~/.xinitrc, but your copy looks > pretty close to stock except for the window manager that you are running. Makes sense. .xinitrc is just vanilla X stuff. > > How much does Cygwin's XFree depend on the (traditionally) > > user-controlled .xinitrc file, to work properly? Does it also depend > > on specific Cygwin things in ~/.Xresources? > > Not sure what you are asking here... I don't think the things you are > worried about matter in this case. Well, if it doesn't matter whether I'm using mine or using the default one from the XFree install, then there's nothing to worry about. > >> I think you can override the defaultserverargs in your .xinitrc so that > >> you could have a .xinitrc that both starts its own wm and prevents > >> startx from passing "-multiwindow" to XWin.exe. I'm not an xinit/startx > >> expert, so you'll have to look for docs on that elsewhere. > > > > > > Are there any docs on -multiwindow and using the Windows desktop as > > your window manager? I gather that -multiwindow in effect includes a window manager, and that's the main thing to know. > > I tried startxwin.sh without a lot of joy. I can't see where it gets > > its starting set of windows, and I can't see how to start up any > > windows conveniently either. (Currently it has -multiwindow and > > -clipboard hardwired in - it doesn't seem to do any argument > > processing.) > > > > I may change that and send you a revised one, if you'd be interested. > > > > Perhaps my question is, why would anyone choose to run multiwindow > > using the Windows desktop? There seems to be no easy way to start X > > applications, except presumably from the command line. > > > > It doesn't seem to use .xinitrc how I'd expect. Sure, if I add an > > "exec wmaker" then it all fails because it thinks a window manager (the > > Windows desktop) is running, and bails out. But if instead I add an > > xmessage "Quit X" at the end instead, that never appears. I just end > > up with the "console window" with yellow text on black background, and > > an icon in the Windows tray, that I can use to exit X or unhide the > > root window. > > > > If I unhide the root window, then the X cursor disappears. Nor can you > > call up a root menu, since I suppose Windows doesn't understand that. > > And I know of no way to get a root menu in the Windows + multiwindow > > "environment" or mode. > > > > Also, as I said, if I unhide the root window in this mode you can't > > exit from X. You can request to do so, but it doesn't exit until you > > rehide the root window. You can also exit from the taskbar icon if you > > have the root window hidden, but not if the root window is displayed. > > > > Hope this makes some sense, and/or is of some use! You'll notice that all the above problems were with using your startxwin.sh script. > > This looks fine to me. > > > --- cygwin/startx.bat - > > @echo off > > > > rem The D: gets replaced by the real Cygwin drive during installation: > > C: > > > > chdir \cygwin\bin > > > > rem For use with sample .profile: stop the exec in user's .profile for the > > rem case where we're really starting the X server. > > set STARTX=df > > > > rem > > rem Comment out the -rootless line if you *do* want the whole X desktop. > > rem -multiwindow had both hopeless performance and inability to get > > rem character input into an rxvt or xterm window under WindowMaker. > > rem > > > > bash --login -c "PATH=$PATH:/usr/X11R6/bin; startx" > > rem bash --login -c "PATH=$PATH:/usr/X11R6/bin; startx -- -rootless" > > rem bash --login -c "PATH=$PATH:/usr/X11R6/bin; startx -- -multiwindow" > > > > pause > > Yeah, there is the money shot baby. This whole time you've been using a > poor
