Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!bloom-beacon!dont-send-mail-to-path-lines
From: rlk@think.COM (Robert L Krawitz)
Newsgroups: comp.windows.x
Subject: Question for net.views column in UNIX Today!
Message-ID: <9104011656.AA07022@underprize.think.com>
Date: 1 Apr 91 16:56:18 GMT
References: <1991Apr1.055516.12726@midway.uchicago.edu>
Sender: rlk@think.com
Organization: The Internet
Lines: 63


   Date: 1 Apr 91 05:55:16 GMT
   From: bkc2@quads.uchicago.edu (Benjamin Clardy)

   Since there are now toolkits that allow simultaneous devleopment of
   Motif and Openlook applications, I do not feel that the existence of
   these two standards prevents a problem from the programming point
   anyway.  With regard to the user, I would like to see some
   standardization between the two.  This, however, is not so dependent
   upon the GUI, but upon the industry and the individual programmer.  I
   agree that a standard menu setting of FILE, EDIT, and HELP with
   similar functions be established.  I still believe that the Mac has
   the best most consistent interface, and to a large extent this is due
   to a almost fascist Apple Corp.  I find it ironic that I have a
   SPARCstation at work running OpenWindows, but I recently bought an
   Macintosh Classic for home.  The simple fact of the matter is that I
   find it easier to do "simple" tasks on the Mac (word processing,
   finances, etc.) than on the Sun (not because I am Unix illiterate-I
   administer the Suns at work).

I never quite understand what FILE and EDIT mean, since their semantics
differ from application to application (and don't necessarily mean
anything for certain applications, anyhow).  I'd much rather type
"M-x frobnicate-frotz" than try to figure out anything from a menu.
Come to think of it, what I'd really like is Emacs-style command
completion, apropos, etc. and programmable (if any) menus.  Oh well,
when Emacs 19 comes out maybe I won't need any other application :-)

	   4. The ability for an application to display on icon without
	      being loaded into memory.  I think the drag and drop
	      metaphor is makes sense, but I don't always want an
	      application in memory to do that, e.g. having Pageview
	      loaded all the time to view a PostScript file.  How about
	      dynamic starting of the application in this case?

That's something the window manager can do.  I actually have a menu in
twm (which I never use, mind you) that can pop up a program.  What
you're asking in general is much harder, and rather OS-specific.  Unix,
for example, does not have any specific capability of this nature
(although you can have a stub program which sits around and acts like a
daemon, but if it has enough X stuff built in to pop a window up, it's
probably almost as big as the application).  BTW, programs under unix do
not necessarily consume physical memory when they aren't active,
although they do use swap space.  Whether that's a problem depends upon
the size of your disk or swap partition.

	   5. Font Menus.  Why can't I have OpenWindows, or OW applications, 
	      change or resize the font on command, instead of just at startup.

Gnu Emacs does this just fine (M-x x-set-font, as well as
x-set-background, x-set-foreground, etc.  and it used to have
x-change-display!).  It doesn't even use any toolkits (I don't think it
even uses Xaw).

BTW, the thing that worries me about the fancier window systems (Mac,
Next) is that they don't even have a command line interface.  Simply
getting a shell window on the Next seems to be a major undertaking.  I
suggest that people designing window systems look at the Lisp machine to
see how to make a system friendly to anyone.

ames >>>>>>>>>  |	Robert Krawitz <rlk@think.com>	245 First St.
bloom-beacon >  |think!rlk	(postmaster)		Cambridge, MA  02142
harvard >>>>>>  .	Thinking Machines Corp.		(617)234-2116