jim@EXPO.LCS.MIT.EDU (Jim Fulton) (08/30/88)
The approach we've encouraged in the past has been to create two scripts:
1. something that loads the right defaults, puts some windows in a
nice place, and starts a window manager. For now, think of it
as /usr/local/bin/defxenv:
#!/bin/sh
DISPLAY=:0 ; export DISPLAY
xrdb -load $HOME/.Xres
xsetroot -solid gray &
xclock -g 50x50-0+0 -bw 0 &
xload -g 50x50-50+0 -bw 0 &
xterm -g 80x24+0+0 &
xterm -g 80x24+0-0 &
uwm
2. something called "x11" or "startx" or whatever calls xinit with
the preceeding script as an argument along with whatever the right
server ought to be (if you have more than or, if your site admin
didn't make a link called X somewhere in your path). For now,
lets pretend that it is called /usr/local/bin/x11:
#!/bin/sh
xinit /usr/local/bin/defxenv
You can then instruct your users to type "x11" to start the world.
Just to show you that we're nice guys and that we really do listen to other
people's suggestions, if you have a $HOME/.xinitrc, the R3 xinit will use that
instead of the default xterm command if no client arguments are given. But, we
still prefer friendly front-end scripts....
Jim Fulton
MIT X Consortiumpaul@arthur.uchicago.edu (Paul Burchard) (08/31/88)
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)] -----------------------------------------------------------------------------
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (08/31/88)
Date: 31 Aug 88 06:00:59 GMT
From: ncar!tank!kaon!arthur!paul@AMES.ARC.NASA.GOV (Paul Burchard)
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".
We aren't ruling out changes in the future; we've just made a decision that
significant changes to xinit for R3 are not a high priority for us.
But it looks like a real init program will
have to be contrib'ed.
That would certainly help. However, we have been doing some work on an
"xlogin daemon" (which may or may not make it into R3) to replace the
xterm -L cruft; the current design has some of the features you are
asking for, and we realize that xinit ought to have functionality
equivalent to whatever is put into the daemon.jim@EXPO.LCS.MIT.EDU (Jim Fulton) (08/31/88)
> I'm glad to hear that this is a matter of concern to others as well. This is actually one of the highest priorities of vendors of intergrated user interfaces. I don't think anybody gets the warm fuzzies from xinit, and we certainly encourage people to build (and give back :-) better ways of controlling one's environment. Nobody has ever accused the public release of being acceptable for end users. > But it looks like a real init program will have to be contrib'ed. What you are describing is typically called a "session manager" in Xspeak, and is definitely the direction in which things are moving. Many of the major vendors already have similar things under development, and everyone agrees that it would be nice to have at least a simple session manager in the public release some day. Xinit is a lot like "ed". It's works, and it's there; but, most people only use it under duress, when nothing "better" is available.
avr@mtgzz.att.com (a.v.reed) (09/02/88)
In article <8808311656.AA07475@EXPO.LCS.MIT.EDU>, jim@EXPO.LCS.MIT.EDU (Jim Fulton) writes: > This is actually one of the highest priorities of vendors of intergrated user > interfaces. I don't think anybody gets the warm fuzzies from xinit, and > we certainly encourage people to build (and give back :-) better ways of > controlling one's environment. Nobody has ever accused the public release > of being acceptable for end users. Good news: I am using a better way of controlling my environment. And I did not even have to build it myself. It came with my UNIX (TM) system. It is called a "SHELL"! Try it. You'll like it. You probably have several. The one I use is called the Korn Shell (ksh). > > But it looks like a real init program will have to be contrib'ed. You're welcome. I use the following aliases in my $ENV: alias xrun=". $HOME/.xrun 2>$HOME/x.err" alias -x xkill='kill `ps -g|/bin/grep Xsun|cut -c1-5`' My $HOME/.xrun contains the following: #/bin/ksh TTY=`tty` DISPLAY=adam:0;export DISPLAY (sleep 2 ; xterm -fn 6x10 -bw 3 =80x24+0-450 -C -rv) 2>/dev/null & (sleep 3 ; xterm -fn 6x10 -bw 3 =81x44-0-0 -rv) 2>/dev/null & (sleep 4 ; xterm -fn 6x10 -bw 3 =81x44-0+0 -rv) 2>/dev/null & (sleep 5 ; xterm -fn 6x10 -bw 3 =81x44+0-0 -rv) 2>/dev/null & (sleep 6 ; xterm -fn 6x10 -bw 3 =81x89+576+0 -rv) 2>/dev/null & (sleep 7 ; xterm -fn 6x10 -bw 3 =81x89-576+0 -rv) 2>/dev/null & (sleep 8 ; xclock -analog =83x83+0+0 -update 1 -rv) 2>xclock.out & (sleep 9 ; xsetroot -gray) 2>/dev/null & (sleep 12 ; uwm) 2>uwm.out & (sleep 14 ; xset r off m 4 2 s 600 ) 2>/dev/null & Xsun -mono -fp /usr/mtgzfs1/avr/x11r2.core/fonts/snf -a 4 -t 2 \ -co /usr/mtgzfs1/avr/x11r2.core/util/rgb/rgb -r \ >/$HOME/xsun.out 2>&1 case $TTY in /dev/ttyp* ) kbd_mode -e ;; * ) kbd_mode -a setkeys reset ;; esac clear This works perfectly, giving me exactly the server and clients I put in it. I can change it with my usual text editor. I don't need to learn any special initialization file formats. And anyone who knows sh can take take my .xrun, read it, understand it, and customize it for their own use in less time than is spent by some ignorami in reading the manual page for xinit. > Xinit is a lot like "ed". It's works, and it's there; but, most people only > use it under duress, when nothing "better" is available. Correction: most people use it only because they don't understand UNIX, which has to do with knowing what tools are available, and using the right tool for the job. To us tool-users, the very existence of an "xinit" is proof that not everyone plays with a full toolbox. Adam Reed (avr@mtgzz.ATT.COM)
casey@admin.cognet.ucla.edu (Casey Leedom) (09/02/88)
In article <641@kaon.uchicago.edu> paul@zaphod.uchicago.edu (Paul Burchard) writes: > 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? I'd say it's still in the planing stages, but I've got some pretty firm ideas (as my posting indicated). I'm right in the middle of trying to get the second release of 2.10BSD out the door, but we're cutting the tape this Monday (yet another production deadline to miss), so I'll be able to start work on this then. It shouldn't take very long to put together because I can steal all the necessary code from xinit and xtools. I'll make a preliminary version available for testing probably within a week. Casey
casey@admin.cognet.ucla.edu (Casey Leedom) (09/02/88)
In article <4479@mtgzz.att.com> avr@mtgzz.att.com (a.v.reed) writes: > I use the following aliases in my $ENV: > [a couple of small aliases] > My $HOME/.xrun contains the following: > [a complicated shell script] > > This works perfectly, giving me exactly the server and clients I put in > it. I can change it with my usual text editor. I don't need to learn any > special initialization file formats. And anyone who knows sh can take > take my .xrun, read it, understand it, and customize it for their own > use. > > > Xinit is a lot like "ed". It's works, and it's there; but, most people > > only use it under duress, when nothing "better" is available. > > Correction: most people use it only because they don't understand > UNIX, which has to do with knowing what tools are available, > and using the right tool for the job. I think you miss the point. We're talking about two things here: 1. the start up cost or learning curve associated with starting to use X, and 2. the ongoing cost for maintaining and expanding your environment. You only address the second point, and very crudely at that. I find the SunTools method far more satisfactory even for an experienced user: % toolplaces >.suntools which effectively takes a snapshot of your current screen by outputting the shell command lines that it would take to recreate the set of current windows in their current positions, etc. [I should point out at this point that X has something like this, xplaces. A better version is now available from Mark Moraes (<moraes%csri.toronto.edu@RELAY.CS.NET>) who took the original plus a version he'd put together which supported geometry. I just received a note from him saying he'd contributed the new version to MIT.] As for start up cost, your method is a hopeless mire for the novice user who basically just wants to be able to type ``go'' and get something reasonable. And even for the experienced computer user, coming upon that script for the first time is going to be uncomfortable. All we're talking about doing here is making our interface for using X a little more friendly. Casey
dce@mips.COM (David Elliott) (09/02/88)
In article <4479@mtgzz.att.com> avr@mtgzz.att.com (a.v.reed) writes: >In article <8808311656.AA07475@EXPO.LCS.MIT.EDU>, jim@EXPO.LCS.MIT.EDU (Jim Fulton) writes: >> controlling one's environment. Nobody has ever accused the public release >> of being acceptable for end users. > >Good news: I am using a better way of controlling my environment. And I >did not even have to build it myself. It came with my UNIX (TM) system. >It is called a "SHELL"! Try it. You'll like it. You probably have >several. The one I use is called the Korn Shell (ksh). There's a big difference between you (most of us, for that matter) and an end user. Your method is fine for you. I use a method that starts up everything when I login to an X server that I know about, and lets me have a separate eenvironment for every server if I want it, and it's fine for me. I think that any one of us could come up with a nice method for ourselves. The problem is that in both our cases we had to set things up by hand. There is a very large segment of the Unix user community that doesn't want to spend the time doing this or even learning how to do this. These people want to walk up to the machine and have the window system already running with a login prompt somewhere on the screen. They want that login to start up their chosen window manager and place windows where they want them. If they are application users, they want those applications ready at the click of the mouse. Real progress is going to be made when people can interactively (and with a mouse) set up and change their environment without understanding geometry specs, resource manager syntax, or even the Unix shell. Personally, I like the fact that X is so flexible for programming, and I don't mind hacking obscure files with strange names to get my environment set up, but I'm a Unix systems person and write shell scripts in my sleep, so I'm used to it. Joe EndUser doesn't want to know about it. -- David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce
jim@EXPO.LCS.MIT.EDU (Jim Fulton) (09/02/88)
> It is called a "SHELL"! Try it. You'll like it. I have. And for some things I do. However, end users justifiably don't want anything to do with it. That's why developing good tools for building quality User Interfaces is such an important area of development. > [a kludgy script that should have used xrdb and a set of aliases] > > This works perfectly, giving me exactly the server and clients I put in it. You can understand it, but the vast majority of end users would barf if they were told that they had to do something like that. Instead, they want a simple, convenient way to restart their world in a nice state and shut it down when they are done. All without having to do any UNIX garbage. > Correction: most people use [xinit] only because they don't understand > UNIX, which has to do with knowing what tools are available, > and using the right tool for the job. Or they want a little more robustness than an ugly hack will give them. > To us tool-users, the very existence of an "xinit" is proof that not > everyone plays with a full toolbox. Right, because it is woefully inadequate. Session managers will make life much nicer. There are several key points to remember: 1. X is not UNIX-specific. 2. Programmers are no longer the most important group of UNIX users, end application customers are.
avr@mtgzz.att.com (a.v.reed) (09/05/88)
In article <8809021533.AA04630@EXPO.LCS.MIT.EDU>, jim@EXPO.LCS.MIT.EDU (Jim Fulton) writes: > > It is called a "SHELL"! Try it. You'll like it. > I have. And for some things I do. > However, end users justifiably don't want anything to do with it. That's > why developing good tools for building quality User Interfaces is such > an important area of development. > > This works perfectly, giving me exactly the server and clients I put in it. > You can understand it, but the vast majority of end users would barf if they > were told that they had to do something like that. Instead, they want a > simple, convenient way to restart their world in a nice state and shut it down > when they are done. All without having to do any UNIX garbage. > .... > Programmers are no longer the most important group of UNIX users, > end application customers are. I happen to agree with all of the above. End users want canned applications, and I am as willing as anyone to provide them. The issue we disagree on is not whether or not to can applications, but what to put in the can. There is nothing to prevent a canned application from using shell scripts for things that a shell does best, namely setting up a working environment and spawning and interconnecting processes. My approach to building a canned application would be to place in */bin/xrun a script which looks at a user's environment, asks a few questions, prepends the appropriate aliases to the user's $ENV, and writes the customized running script to the user's $HOME/.xrun. The user needs to learn just two commands, "xrun" to start and "xkill" to finish. That's less "UNIX garbage" then learning the format of arguments to xinit. So who's friendlier? > > Correction: most people use [xinit] only because they don't understand > > UNIX, which has to do with knowing what tools are available, > > and using the right tool for the job. > > Or they want a little more robustness than an ugly hack will give them. I learned something about "robustness" when I ran "xinit" with $SHELL set to /bin/ksh. People who live in glass houses, etc. The bug responsible for the problem was not exactly easy to find in xinit.c. Which is another argument for using shell scripts: a script is typically 1/10th the length of an equally legible C program that does the same job. And its bugs can be found in 1/10th the time. OK, so everybody can let a bug through now and then. The ability to find the bugs in minimum time is a VERY good reason to NOT use a compiled C program when a shell script will do the job. > > To us tool-users, the very existence of an "xinit" is proof that not > > everyone plays with a full toolbox. > Right, because it is woefully inadequate. Session managers will make life > much nicer. Yes, but for maintainability I want these session managers to be built out of small, understandable modules. And the shell will remain my tool for putting the modules together, and for customizing their operation. We programmers use the shell to build our own applications for those very reasons. That's why cc, lint, and make are all managed by shell scripts. Why should we lower our standards when building for end users? > X is not UNIX-specific. Neither is ksh; I've used it on OS-9 and MS-DOS, and I'm told it has been ported to just about any OS you can find a C compiler on. Xinit, on the other hand, is about as UNIX-specific as you can get; every C program that tries to do the shell's job somehow turns out that way. Letting the shell do its job is the best way of maximizing portability between operating systems. Another reason, etc. Adam Reed (avr@mtgzz.ATT.COM)
jim@EXPO.LCS.MIT.EDU (Jim Fulton) (09/06/88)
The question is whether or not a shell script will do the complete job and will be easy enough for people to get running in their environment. Many people feel that the answer is "perhaps, but we haven't seen one yet". I think that some of the things that we are currently working on will be more to your liking. Believe it or not, we do care about modularity and portability. Jim