Article-I.D.: osu-eddi.1115
Posted: Tue Jan 14 16:14:47 1986
Date-Received: Wed, 15-Jan-86 01:23:21 EST
Reply-To: elwell@osu-eddie.UUCP (Clayton M. Elwell)
Organization: Ohio State Univ., CIS Dept., Cols, Oh.
Lines: 50
Xref: watmath net.micro.mac:4076 net.micro.amiga:1538

The Portable User Interface Library (henceforth referred to as "PL"; I
hate typing the whole thing out) is progressing nicely.  For the curious,
I will detail the one major problem I have run into, and the solution I
came up with.  If anyone is (a) violently opposed to this approach, and
(b) able to suggest a better alternative (this is important), please send
me mail with details before I get knee-deep in code.

First, I'll define two useful terms.  A ``persistent window'' is a window
that remains on the screen until it is explicitly removed by the user.
Document windows, etc. are good examples of persistent windows.  Temporary
windows are things like alerts, modal dialogs, pop-up and pull-down menus,
etc.

Here is the problem: On multitasking systems, such as Intuition, Microsoft
Windows, Sunwindows, the Apple Lisa Office System (R.I.P.), etc., each
application has its own persistent window, while on the Mac and GEM, each
application usually has several persistent windows.  What this boils down
to is a difference in philosophy about who controls the desktop.  To
illustrate, let's imagine you have a (hypothetical) program called ``PL Paint''
which lets you edit, save, & print bitmapped pages.  If this program acted
like MacPaint and opened up three or so windows (a palette, a tool chest,
and a document window), it would work fine on a Mac, but would get confusing
real fast on a Sun or Amiga, since you could easily get confused if you were
running two instances at once.  Since that would be a reasonable thing to
do in many circumstances, that is obviously not The Right Way.

After doing (a) some deep thinking about this, and (b) a lot of playing
around with existing systems, including Sunwindows, Smalltalk-80, Xerox XDE,
Microsoft Windows, GEM, the Mac, and Interlisp-D, I have come to a conclusion.
The right way to approach the problem is to use a concept that is used in all
multitasking systems and some Mac/GEM programs.  This is the concept of a
``pane''.  A good example for Mac users is MacDraw.  Each document window
is split into several parts: the tool chest, the document, the rulers, etc.
Controls such as scroll bars can also be thought of as special-purpose
panes.

Because of the reasons mentioned above, PL will encourage the following
windowing behavior: a program should have one persistent window per open
document (or more accurately, per user context) which should be split
up into panes if necessary.  This way you get the benefits of multiple windows
without losing track of what windows are associated with which document or
application.

Comments? Suggestions? Words of Wisdom? (No religious flames please.  If
you object, defend your answer :-))
-- 
				-- Clayton Elwell
				Elwell@Ohio-State.CSNET
				Elwell%Ohio-State@CSNET-RELAY.ARPA
				...!cbosgd!osu-eddie!elwell

Article-I.D.: ucbvax.11411
Posted: Wed Jan 15 15:38:13 1986
Date-Received: Fri, 17-Jan-86 03:21:18 EST
References: <1115@osu-eddie.UUCP>
Reply-To: korn@ucbvax.UUCP (Peter "Arrgh" Korn)
Organization: University of California at Berkeley
Lines: 9
Xref: watmath net.micro.mac:4100 net.micro.amiga:1561

I've been racking my brain for an existing program as an example, but as I
haven't, a description will have to do: take J.Random's text adventure; one
window the user types in her instructions, another tells the user about
the situation, a third shows graphically the surroundings, a fourth is
the user's inventory, etc. etc.  How would PL handle this (as I understood
your letter, you've been unsuccessful getting PL to do this)?

-----
Peter Korn	korn@ucbvax.Berkeley.EDU     {dual,dscvax,sdcsvax}!ucbvax!korn

Article-I.D.: amiga.553
Posted: Wed Jan 15 23:52:56 1986
Date-Received: Fri, 17-Jan-86 06:44:17 EST
References: <1115@osu-eddie.UUCP>
Reply-To: bruceb@hunter.UUCP (Bruce Barrett)
Organization: Commodore-Amiga Inc., 983 University Ave #D, Los Gatos CA 95030
Lines: 36
Xref: watmath net.micro.mac:4113 net.micro.amiga:1568

In article <1115@osu-eddie.UUCP> elwell@osu-eddie.UUCP (Clayton M. Elwell) 
writes:
	(... lots of nice observations on windows, conclusion is
	a window pane solution...)

Although not a general purpose solution (expandable to all multi-tasking 
window environments, or even applications) the Amiga does have a nice 
feature/solution for this kind of problem.   Use custom screens.

Advantages:
	1) Any number of sizeable, dragable, layerable windows may be 
	   used per given application.
	2) Different depth and color palattes can be made available
	   (1 bit plane for text editor, 6 for paint program,...)
	3) Very clear association of windows to task(s) running
	4) Quick access to any application by pushing the current
	   screen to back until the desired one is found.  (See  also
	   disadvantage #3)
	5) Each application can use the full screen (almost, see
	   disadvantage #3) and not interfere with any others.

Disadvantages:
	1) Might(!) cost more in terms of memory for display because the
	   workbench screen is not being "reused"
	2) Might(!) be less easy to get to each application if you don't
	   leave the screen front/back gadgets exposed.
	3) You need to leave the to screen gadgets in the upper right
	   hand corner of the screen exposed if you want very fast access
	   to all applications.
	4) Not all applications lend themselves to being on only one 
	   screen.  For example "Amiga BASIC" has you programming in a
	   2 bit plane screen, with your output (possibly) going to
	   another style screen.

Looking forward to other comments/ideas...
Bruce Barrett

Article-I.D.: osu-eddi.1133
Posted: Fri Jan 17 10:56:10 1986
Date-Received: Sat, 18-Jan-86 01:26:54 EST
References: <1115@osu-eddie.UUCP> <11411@ucbvax.BERKELEY.EDU>
Reply-To: elwell@osu-eddie.UUCP (Clayton M. Elwell)
Organization: Ohio State Univ., CIS Dept., Cols, Oh.
Lines: 12
Xref: watmath net.micro.mac:4124 net.micro.amiga:1584

(Re: multiple windows in a text adventure)

No prblem. You seem to have been a little confused by what I meant by
a "pane".  Think of panes as tiled (non-overlapping) subwindows within
another window.  On the Mac, for instance, Microsoft Word implements
this to let you look at two pieces of the same document.

-- 
				-- Clayton Elwell
				Elwell@Ohio-State.CSNET
				Elwell%Ohio-State@CSNET-RELAY.ARPA
				...!cbosgd!osu-eddie!elwell

Article-I.D.: Shasta.1666
Posted: Mon Jan 20 15:43:18 1986
Date-Received: Thu, 23-Jan-86 21:02:42 EST
References: <1115@osu-eddie.UUCP> <11411@ucbvax.BERKELEY.EDU> <1133@osu-eddie.UUCP>
Organization: Stanford University
Lines: 20
Xref: watmath net.micro.mac:4240 net.micro.amiga:1663

 >  (Re: multiple windows in a text adventure)
 >  
 >  No prblem. You seem to have been a little confused by what I meant by
 >  a "pane".  Think of panes as tiled (non-overlapping) subwindows within
 >  another window.  On the Mac, for instance, Microsoft Word implements
 >  this to let you look at two pieces of the same document.
 >  

If this is the only way that you will be able to have multiple windows for
one application, I really would not want to use your library. This sounds to 
me like really butchering the user interface for the sake of portability.

Seriously, this is starting to sound like you are trying to set up an
interface that pleases everyone but satisfies no-one. Perhaps you should take
two steps backward and re-think the way you handle certain issues. Perhaps
the first idea that comes to your head is not the best.

Regarding the multiple windows issue, consider bringing all of an
application's window to the top when it is selected, and sharing certain
windows such as palettes between documents of the same application.

Article-I.D.: osu-eddi.1176
Posted: Thu Jan 23 16:05:06 1986
Date-Received: Fri, 24-Jan-86 09:23:17 EST
References: <1115@osu-eddie.UUCP> <11411@ucbvax.BERKELEY.EDU> <1133@osu-eddie.UUCP> <1666@Shasta.ARPA>
Reply-To: elwell@osu-eddie.UUCP (Clayton M. Elwell)
Organization: Ohio State Univ., CIS Dept., Cols, Oh.
Lines: 32
Xref: watmath net.micro.mac:4262 net.micro.amiga:1684

So far I have gotten a lot of mail on the issue of panes vs. multiple
persistent windows per context.  So far panes are beating multiple windows
by a ratio of about 20:1.  However, this is ultimately the decision of
the author of a given piece of software.  PL will not require you to
use panes.  Any program will be able to open as many windows as the
underlying machine can handle.  However, it will make it just as easy
to use panes (or "panels", as Apple calls them).  If you just want to
use it as a Mac programming tool, that's fine.  Your programs will look
"Macish" and just happen to run on other machines.  However, if you are
trying to write a program that will perform as well as possible on as
many machines as possible, PL will let you do that.  In either case,
PL uses the native facilities as far as possible.  On a Sun, you get
pop-up menus keyed off the third mouse button; on a Mac you get a menu bar.
The program doesn't care.  It just says "I want these menus available.
When such-and-such a menu option is selected, call this function over here."

I hope this helps.  I'm not trying to duplicate Aztec C and turn your Mac
into a 24x80 terminal :-).

Aside:
The folowing sections of PL are now running on the Mac and the Sun:
	Window handling (Sun users will get a small suprise here)
	Menu handling
	Partial control handling (scroll bars & buttons for now)
The next part is the event handler.  When that is done the first
preliminary release will go out over net.sources.  This will be enough
to try it out and write a large class of portable programs.
-- 
				-- Clayton Elwell
				Elwell@Ohio-State.CSNET
				Elwell%Ohio-State@CSNET-RELAY.ARPA
				...!cbosgd!osu-eddie!elwell