[comp.sys.amiga] Let's use screens!

rokicki@rocky.STANFORD.EDU (Tomas Rokicki) (08/25/87)

This is not an original idea, as PARC has been pushing `rooms'
for a while, but . . .

Let's make good use of screens!

I have only recently been making serious use of an Amiga as
a workstation.  I'm talking four or five *different* jobs
running at the same time.  The problem is, the workbench is
too cluttered, and too slow.  (Each job has a few windows,
and at about seven windows, things slow down tremendously.)

It sure would be nice to move applications from screen to
screen.  This way, one screen could be for host communication
(a window for downloading, a window for Tek graphics, and a
window for the terminal emulation.)  Another screen could be
used for TeX development (an editor, the previewer, and TeX,
each with their own windows.)  The main workbench screen
should be used for launching things and icons entirely;
this way you don't need to resize and move all of your work
to get to an icon.

With enough chip memory, this would speed the system up and
clean up its interface.  Actually, since a smart refresh
window has another bitmap for overlap, you might not need
that much extra memory.  In addition, things like TeX might
work just fine in a few less bitplanes.

So, what can make this possible?

	- A way to move a window to another screen.
	Preferably with Intuition 1.3.  Perhaps a
	message as well to notify the task.

	- Programs that will run with a varying
	number of bit planes, down to 1 preferably.
	(Can scroll bar gadgets be fixed to work on
	one bit plane?)

	- Programs that can work with several 
	different windows/working directories at
	once; especially editors.  No need to
	duplicate the code.  Mike Meyer's edit:
	server would be ideal.

My TeX system (which is getting better and better)
shall allow you to reside entirely on a custom screen;
TeX, previewer, and editor (once I con an editor into
doing what I want it to.)  But this will be because I
code it this way; it would be great if this was all
automatic.

Rewriting layers won't solve the problem; none of X,
the old Sun windowing system, Sun NeWS, InterViews,
or anything else I've used has good response time with
several windows open.  But this hierarchical partitioning
into screens might do real well.

Comments?

-tom

dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/25/87)

>It sure would be nice to move applications from screen to
>screen.  This way, one screen could be for host communication
>(a window for downloading, a window for Tek graphics, and a
>window for the terminal emulation.)  Another screen could be
>used for TeX development (an editor, the previewer, and TeX,

	This is partially solved with MWB.  MWB is CLI based, and allows
you to cause windows spec'd to open on the workbench screen to open somewhere
else.  It automatically routes OpenWindow() calls for the workbench screen
to the current 'MWB' screen.  It does *NOT*, however, allow you to move
windows from screen to screen, nor open windows on other program's custom
screens, nor force programs which open windows in their own custom screens
to open them in an alternate screen instead.  You can specify everything
about the one or more 'MWB' screens except the colormap (an oversite... use
that other PD program that allows you to set palette colors of arbitrary 
screens).

	(I sent Tom a copy).  

					-Matt