elwell@osu-eddie.UUCP (Clayton M. Elwell) (01/15/86)
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
korn@ucbvax.BERKELEY.EDU (Peter "Arrgh" Korn) (01/15/86)
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
bruceb@amiga.UUCP (Bruce Barrett) (01/16/86)
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
elwell@osu-eddie.UUCP (Clayton M. Elwell) (01/17/86)
(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
gus@Shasta.ARPA (01/20/86)
> (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.
elwell@osu-eddie.UUCP (Clayton M. Elwell) (01/24/86)
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
gnu@hoptoad.uucp (John Gilmore) (01/25/86)
elwell@osu-eddie.UUCP (Clayton M. Elwell) writes (excerpted): > On multitasking systems...each > application has its own persistent window, while on the Mac and GEM, each > application usually has several persistent windows. 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. > > 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. It sounds like what he's advocating is that each application gets a big window which it can subdivide to its heart's content into little windows (not necessarily tiled, but probably tiled). This is the way the Mac runs multiple things at once with Switcher. You just have to treat the entire screen as the "big window" within which you can arrange things. When you bring up another application, the "big window" gets hidden behind (or to the side of) another "big window" for the new application. The relevant point here is that you can't intermix sub-windows from one application with those from another -- and this is true on Suns, Macs, etc, they just use different nomenclature. As long as PL for the Mac gives you the whole screen as your "window", while PL for multitasking machines gives you a sub-portion (which you can move, resize, etc), things should work fine. -- # I resisted cluttering my mail with signatures for years, but the mail relay # situation has gotten to where people can't reach me without it. Dammit! # John Gilmore {sun,ptsfa,lll-crg,nsc}!hoptoad!gnu jgilmore@lll-crg.arpa