Hi Harold, Firstly, it's generally bad form to quote verbatim email addresses - although Luke did so in his original posting, so he can't complain if a spam harvester latches onto him ;-).
Now... 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 X >> applications also move into there? > > My system does not have a >> problem finding xterm in /usr/bin because > /usr/bin should always be >> in your Cygwin shell path... something else is > wrong with your Cygwin >> setup if that is not the case. 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 only noticed that xterm had moved because when I start X with >> -multiwindow (or with -clipboard), it complains like this and exits: >> >> $ PATH="$PATH:/usr/X11R6/bin" startx -multiwindow -- :0 Surely this should be: $ PATH="$PATH:/usr/X11R6/bin" startx -- -multiwindow My understanding is that all args before the -- are client args and all following it are server args. If no client is specified, the default client, which is hardcoded to be /usr/X11R6/bin/xterm is used and -multiwindow is passed as an argument to it. >> So if I remove the "exec wmaker" from .xinitrc, X starts and stops >> instantly. So I add an "xterm" at the end of .xinitrc (since X doesn't >> realise the wmaker would have started lots of windows from its saved >> workspace state if it had been given a few seconds to run). > > Yeah, you have to have a "magic client" that is started with an exec at > the end of your .xinitrc, otherwise the behavior that you described is > exactly what is supposed to happen. The point is that xinitrc is somewhat misnamed as it drives the entire x session from conception to grave. It's just a shell script and once the last command exits and the script ends, the session is terminated. Any old command that won't return until you've finished with X will do. From the xinit(1) man page: An important point is that programs which are run by .xinitrc should be run in the background if they do not exit right away, so that they don't prevent other programs from starting up. However, the last long- lived program started (usually a window manager or terminal emulator) should be left in the foreground so that the script won't exit (which indicates that the user is done and that xinit should exit). >> I wonder how I can run multiwindow with wmaker as my window manager? Why would you want to Luke? multiwindow IS a window manager that just wraps the X window's client area in MS Windows' frames and has an invisible root window. If your aim is to have wmaker style frames without an X root window, try the -rootless option with wmaker. I used to use X this way until multiwindow got so good :-) >> Maybe keep the "exec wmaker" and set display to :1 ... No, "startx >> -multiwindow -- :1" triggers the "no program named >> "/usr/X11R6/bin/xterm" in PATH" crash. So I don't quite see how to >> achieve that. I tried xinit -multiwindow but that started up a full >> desktop. > >Seriously, the easiet way is to use startxwin.bat and modify it >according to the instructions in that file. Or, if you really want to >start from a Cygwin shell, use startxwin.sh and modify it accorinding to >its instructions. There are pre-made lines that are just commented out >that start a window manager etc. > >Lets have you try these things first and see where it goes. > >Harold Harold, I'm quickly coming to the opinion that .bat should really be spelled .bad !! My / is the recommended C:\cygwin, but /usr is mounted on D:\cygwin\usr. This means that the all of the %CYGWIN_ROOT%\usr based paths in the script are all wrong. There is no way (major kludges aside) to generate the correct paths in a generic .bat file. Consequently, every time I install a newer version, I need to hack the new .bat file (or patch my own script with any changes you've made). If you'd be interested in a unified approach, where the .bat just runs bash -c startxwin.sh (which will probably in turn be just a wrapper for startx) I might be able to make time for this. The ultimate goal being to make any configuration of startup parameters external to the scripts and therefore remove ANY need for users to hack the scripts themselves. There was mention a while ago of making multiwindow a standalone window manager. Has anything been done in this direction? It would certainly ease making a "one size fits all" startup and remove much of the confusion this thread typifies - i.e. the rule would be: "always run one window manager" rather than "always run a window manager unless you start X with -multiwindow (whether you're aware that you are or not) in which case you etc..." If you're interested, I'd appreciate some advice on how you'd like the patches submitted. I'm assuming that I'll need to check out the latest CVS source, make the changes and submit the diffs as a patch. Since I've only ever seen tiny patches appear in this list, do most patches get sent directly to you? Phil ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************
