This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Various starting X problems


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]