Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sgi!msc@ramoth.SGI.COM
From: msc@ramoth.SGI.COM (Mark Callow)
Newsgroups: comp.sys.sgi
Subject: Re: Windows
Message-ID: <32917@sgi.SGI.COM>
Date: 16 May 89 18:54:42 GMT
References: <8905140855.aa12266@CAD.USNA.MIL> <3620@eos.UUCP>
Sender: daemon@sgi.SGI.COM
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 42

In article <3620@eos.UUCP>, timelord@eos.UUCP (G. Murdock Helms) writes:
> ("David F. Rogers") writes:
> >Mark Callow says they are working on the window performance issue for
> >release 3.2. He has really missed the point. I want the option of having
> >NO window manager.
> 
I didn't miss the point.  We are probably even going to document how to
travel on the bare metal.  But it isn't easy.  The window *system* provides
a lot of support that people tend to take for granted not realising that
it is provided by the window system.


> How about a window manager that has a toggle on it so you can turn it on if
> you want it, and off if you don't?  Most of the time the programs we
> run on our GTX require windowing, but sometimes they don't, and the
> toggle mechanism might be beneficial to a lot of folks using Irises.

Our preferred approach is to gracefully make the power of window system
available as you use it.  The counterpoint to that is if you don't use it,
it doesn't get in the way.  Think of this as an automatic switch.  If you
create a full screen window (e.g. through ginit) then the window system
is out of the way except for keyboard translation (if you are using the
keyboard), menu service (if you are using menus) and helping deliver mouse
and keyboard events.  If the window system didn't do this latter task, some
other process would have to perform the same work.  The only resource the
window system is consuming in this state is swap space.

Now if the user of your program decides he wants to also run another
application he can simply start it up and the window system will gracefully
come into play without any abrupt change from one state to another.

Yes the 3000 could run without Mex.  But could it run without a window
system?  Not really.  Pieces of the window system were in the kernel
and are used by all clients even when Mex wasn't running.  For example,
those primitive windows called textports.  Without those textport windows
almost all the programs that run without mex would be useless.  We still
see a lot of programs that are dependent on textports.

As I said up front, travelling on the bare metal isn't easy.

--
	-Mark