From: zstern@adobe.com (Zalman Stern)
Subject: Re: Hasn't the message line bogosity gone on long enough?
Organization: Adobe Systems Incorporated
Date: Wed, 26 Aug 1992 21:53:45 GMT

In article <keauijW00WoiAlJUlh@andrew.cmu.edu> rr2b+@ANDREW.CMU.EDU (Robert  
Andrew Ryan) writes:
> Excerpts from internet.other.info-andrew: 26-Aug-92 Re: Hasn't the
> message line.. Zalman Stern@decwrl.dec. (810)
> 
> > If it overflows, build a dialog box with a large message line and pop
> > that  up instead. See how people like that.
> 
> Unfortunately this can't really cover the case of a input request, since
> the message line could grow substantially during input.

I'm actually proposing to make this test on each Update. As soon as it gets  
too long, you "promote" it to a dialog box. This is probably 50% saracastic.

> Excerpts from internet.other.info-andrew: 26-Aug-92 Re: Hasn't the
> message line.. Zalman Stern@decwrl.dec. (810)
> 
> > You could dynamically resize the  
> > message line instead. Both of these should be relatively easy to do if I  
> recall frameview at all. (Which I probably don't).
> 
> Yes this could be done without too much hacking on frameview, but the
> runtime cost for the redraws could be prohibitive esp over slow
> networks.  Another possible solution to this might be to give text a
> notion of horizontal scrolling. (though not with a scrollbar please :-)

Designing a graphical user interface on the basis of "slow networks" is  
pretty stupid. But pointing that out to the UNIX community is wholely  
unproductive.

However in this case, the conceptual redraw can be quite efficient. Given a  
text window (or something with the same "bit gravity" as a text window)  
above the message line, all you have to do is make the bottom section of the  
lpair larger, and redraw the top scrollbar. (I.e. a line of text disappears  
off the bottom of the top textview.) Getting lpair and textview to  
accomplish this may be a hassle because they probably blast the rectangle to  
white and FullUpdate. (In fact the ATK Update/FullUpdate protocol may not  
allow this. Its been a while... If not, it should be fixed :-))

[Rob claims message lines are a win.]

Macintosh Programmers Workshop (MPW) has a notion of a console window with a  
special key sequence (either the Enter key or CMD-Return) that means send  
the current line (or current selection) as input. Programs write prompts out  
to the window and the user types something and hits CMD-Return. (The prompt  
will most likely show up in the input to the program in this scenario.) If  
you want the message line to behave as a text buffer with history, you end  
up doing something like this. (ATK could win by having the prompts marked  
with a special style so the text could be removed before handing back a  
reply.) If I were going to do this, I'd have a single message line window  
per application and throw the input focus to that window when a question is  
asked. (It might even be plausible to have a single message line window for  
all ATK applications running at one time.)

[Aside: I don't recall the timestamped message line log that Adam described.  
I'm pretty certain it wasn't in any implementation of framemessage while I  
was at the ITC. So its either relatively recent or perhaps from bx or BE I?]

Finally, forcing filename prompting into a message line is a lose. A good  
Macintosh file dialog is faster and easier to use. (Checkout Super Boomerang  
sometime.) On large screens, you can avoid losing context by having the file  
dialog show up in a standard window location that the user chooses. This  
space can then be kept more or less empty. 
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson