Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ncar!tank!kaon!arthur!paul
From: paul@arthur.uchicago.edu (Paul Burchard)
Newsgroups: comp.windows.x
Subject: xinit lacks init in it (Summary)
Message-ID: <641@kaon.uchicago.edu>
Date: 31 Aug 88 06:00:59 GMT
References: <8808291905.AA16353@EXPO.LCS.MIT.EDU>
Sender: newsuser@kaon.uchicago.edu
Reply-To: paul@zaphod.uchicago.edu (Paul Burchard)
Organization: Dept. of Mathematics, Univ. of Chicago
Lines: 111

XXXXXXX

Thanks to those who have mailed or posted replies to my proposal to extend
xinit.  I'm glad to hear that this is a matter of concern to others as
well.

XXXXXXX

The basic question: Why do I say xinit is deficient?  Because while xinit
is purely a convenience program -- it merely execs two other programs,
albeit carefully -- it is not actually convenient, because its
single-client concept of the init process is just not appropriate.  While
it is possible to use shell scripts and aliases to hide this problem, such
kludges can never replace a carefully thought-out init program.  After all,
even xinit can be more or less emulated by the simple csh alias

	alias xinit X :0\&\;sleep 5\;xterm \!\*\;kill -9 %%\;kbd_mode -a

Jim Fulton has let us know where we stand on R3 (and beyond).  Basically,
the official xinit will allow "xinit" to be a synonym for "xinit .xinitrc".
This is a small step forward.  But it looks like a real init program will
have to be contrib'ed.

Let me first review what has come my way for using the current xinit to do
the job.  The most common is probably to make xinit's main client be a
shell script.  Jef Poskanzer has a carefully honed one, whose outline
(slightly altered) is:

	#!/bin/sh
	read_defaults
	(
	  sleep xx
	  first_client &
	  sleep xx
	  second_client &
	  ...
	) &
	exec main_client

This does a lot of things right rather efficiently.  But a naive user would
probably have difficulty making successful alterations to it.  The method
of quitting X is not flexible.  System defaults are not supported.

Another good way to use the current xinit is to use the xtools program
(available on expo in the contrib material), of whose existence I was
kindly informed by Eduardo Krell.  (What I got doesn't quite fit your
description, Eduardo...)  To use it, you type "xinit xtools"; the xtools
program then starts up clients specified in your ~/.xtools file (or a
machine-specific .xtools if you have one).  It also puts up a tiny window
with a quit button (which requests confirmation of quit).  Problems: no
system defaults supported; while a uniform quit mechanism is established,
no alternate routes are supported; .xtools syntax is restrictive (it uses
straight execvp()'s).

Now on to the proposals for a replacement to xinit.  About my proposal,
Casey Leedom said

>   Well, I'm glad I'm not the only person who feels that things could be a
> bit more automatic / user friendly with X startup.  However, I'd have to
> say I couldn't endorse Paul Burchard's proposal for xinit enhancements
> because they're still too complicated.

Actually, I wholeheartedly agree; I was imposing on my scheme the
constraint of maintaining compatibility with the current xinit in the
(futile) hope that this would increase the chances of its official
adoption.  Now that I know better, I'd like to endorse Casey's specs:

>         1. if no window server is running,
>                  start one, and
>                  wait for it to come up
>         2. if no ~/.Xresources file exists,
>                 use a system standard resources configuration
>            execute xrdb against resources database
>         3. if no ~/.Xtools file exists,
>                 use a system standard applications startup configuration
>            execute /bin/sh against application startup file
>         4. exit
> 
>         A corresponding change should be made in the X server to have it
>         exit when the last client closes.  Note that this should be
>         controlled via a command line option.

I think some more flexibility could be provided in the manner of exiting X.
Here are the ideas I have heard or seen:

	A. xinit puts up a quit button with confirm
	B. xinit puts its PID into environment of clients
		to allow command-line (and hence menu) exit using signals
	C. server terminates itself when RootWindow Destroy'ed
	D. xinit exits, server terminates itself when no clients remain

Notes: (A) is from xtools, (B) is from Eduardo's description of what his
version of xtools does, (C) is from Bill Janssen, (D) is from Casey's
proposal above.  Items (C) and (D), while attractive, have the disadvantage
that they require altering not only xinit but also the server.  (D) is also
incompatible with (A) and (B).

Finally, I would add that a complete program should accept command-line
args for alternate files to replace ~/.Xresources and ~/.Xtools; the
diligent might even include the machine-specific feature that xtools
supports.

Bill Janssen reported an X10 xinit altered to support several of the
proposed features.  For what it's worth, my hack is coded up for X11.  I
wasn't clear on the status of Casey's proposal, Casey, is this still in the
planning stage, or do you have a prototype we can try out?


-----------------------------------------------------------------------------
Paul Burchard	paul@zaphod.uchicago.edu
``shepherd of the user flock''		[no, no, not flock(2)]
-----------------------------------------------------------------------------