NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/softsys/andrew/1180

Text File | 1992-08-26 | 4.0 KB | 79 lines

Newsgroups: comp.soft-sys.andrew
Path: sparky!uunet!stanford.edu!morrow.stanford.edu!decwrl!adobe!usenet
From: [e-mail] (Zalman Stern)
Subject: Re: Hasn't the message line bogosity gone on long enough?
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET NEWS)
Organization: Adobe Systems Incorporated
References: <[e-mail]>
Date: Wed, 26 Aug 1992 21:53:45 GMT
Lines: 67

In article <[e-mail]> [e-mail] (Robert
Andrew Ryan) writes:
> Excerpts from internet.other.info-andrew: 26-Aug-92 Re: Hasn't the
> message line.. Zalman [e-mail]. (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 [e-mail]. (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           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson