Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucbvax!decwrl!purdue!bu-cs!bloom-beacon!mit-eddie!uw-beaver!tektronix!reed!kamath
From: kamath@reed.UUCP (Sean Kamath)
Newsgroups: comp.sys.apple
Subject: Re: hackers/users--interface issues
Message-ID: <9704@reed.UUCP>
Date: 28 Jun 88 06:17:31 GMT
References: <8806220019.aa06928@SMOKE.BRL.ARPA>
Reply-To: kamath@reed.UUCP (Sean Kamath)
Organization: Reed College, Portland OR
Lines: 157

In article <8806220019.aa06928@SMOKE.BRL.ARPA> AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") writes:
>>[me]
>No!!!  The *environment* isn't slow; only the current
>*implementation* is slow.  And it's not all *that* slow--mostly it
>just BOOTS slowly.  (If you open enough windows at a time, you can
>MAKE it slow, of course; and more speed in the GS+ will certainly
>help make real GS word processors usable.)

Then I claim the only implementation that will speed it up is mass hardware
upgrades, like coprocessors and a dedicated video CPU, as well as DMA disk
access, with intelligent caching. . .  Wait a minute. . .

>All right...what do you think should be added to ROM besides the rest
>of the toolbox?

How about allowing the user to expand his/her usable RAM to up to 12 Meg,
and saving 4 meg for ROM?  Actually,I'm really coming close to biting my own
ass off here, I don't know exactly how it's reserved.  I'm sure gobs o'
space go to the video firmware (by way of screen buffers, etc.).  Just how
much of the "reserved" ROM is unused?  It seems to me that only about 2-4
megs should *ever* be actual ROM. . .

>I don't normally *use* the Launcher...I use Davex.  The Launcher
>isn't even slow--just LOADING THE RAM TOOLS is slow.  And if you
>have been running other desktop-based software, they will already be
>loaded & you can zip in & out of the Launcher and Finder pretty
>quickly.

Pretty quickly compared to what?  Until the graphics environment becomes
faster than the text environemt, I will probably use the text environment.
(the reason I say probably is that *sometime* (rarely) I actually use
graphics!)

>Actually, it was TML Pascal, but you're right--it does look a lot
>like C.  The reason it doesn't look like Pascal is that there are
>some extensions to make toolbox access easy:  "@" takes the address
>of a function, procedure, or variable.  Type identifiers can be used
>LIKE FUNCTIONS (but no code is produced) for changing one type into
>another.
>
>TML Pascal (as shown in my previous msg):
>
>  SFGetFile(120, 35, 'Open what Icon file:', @MyFilter,
>                   TypeListRecPtr(nil), myReply);
>
>APW C (looks almost the same!):
>  SFGetFile(120, 35, "Open what Icon file:", MyFilter,
>                   (TypeListRecPtr) NIL, &myReply);

Uh, Dave, if @ takes the address of the funct, then you ought to have a '&'
before the MyFilter above. . .  Generally, I find pascal to be a little
wierd. The current variation on Pascal I use always sends addresses.  They
are always 4 bytes wide, and that takes care of that.  So it's a little
wierd that you have to address MyFilter, but not myReply, yet in C you send
the address of myReply, obviously for modification my SFGetFile. . .  Well,
this is all sort of academic.  Either I don't get it, or you haven't fully
explained everything (such as data types and specs for the calls. . . ).

>How much stack space is used?  I really don't care, since it has no
>effect on my program.  I suspect it uses somewhere around 2 pages of
>stack, since StdFile calls WindowMgr to get a modal dialog, the
>dialog manager calls the control manager, and the control manager
>calls QuickDraw.  (This is oversimplified, but it gives a reasonable
>picture of what's happening.)

Well, don't you thing you ought to care?  I mean, suppose you use up your
entire bank of stack space?  With todays current recusive wonder-routines...

>The *point* is that the programmer doesn't need to care about any of
>this--it's all taken care of, and *much* simpler than trying to
>provide anything in your own code with the functionality of Standard
>File.  Remember it lets the user do treewalking to explore the
>directory structure of any online disk!

If you really want to do all this (and *I* do, sometimes), you write in a
high level language and use prolific macros.  And if you plan on getting
really serious, you get an Apollo or Sun workstation.  If you recall my
*original* point, it was that given the size of code generated, time
involved, and ease of use *from assembly*, it just doesn't cut it!  Include
compile time!  Geez, we are really talking Apples and Oranges here!  I'm
*not* saying that that is bad for Major applications (including serious
utilities etc), just not for the quick hack!

>How much *code* is generated I can answer:  3 bytes for pushing each
>16-bit word on the stack (10 words * 3 bytes = 30 bytes), plus 7 to
>make the call (LDX with a word and JSL to the tool dispatcher), then
>4 to store the error code in Pascal's "ToolErrorNum" variable.
>Total=41.

Ha!  that's a 1300% increase it space!  Gaaaaaa.a. . .a.,

>Yup, it is a little more complicated, but it provides a LOT more
>functionality as well as consistency for the user.  It's well worth
>it.

There you go again, arguing functionalitiy vs. ease of program usage.  Why
is it that programs for apps get so *damn* large so *damn* fast?  Because of
the freaking *functionality* of their user interface.

>[More prolific examples of functionality]

Again, David, the discussion was not concerning functionality, or
"correctness" of code, or anything related to that.  It was on "hacking" and
the user_interface. (jeez, can you tell I'm getting used to those
underscores at work!).  I maintain that as a programmer, it is, and always
be, easier for me in a low level language to dispense with the user
interface as best I can (making truely cryptic prompts such a "1:" or "in",
and not a little window showing me all the choices, and a nice message
saying "please select the file that you would like to convert, then click on
'open'".), and get to the actual work at hand.  When that is done, then I
can go back and get to work on a nice user interface.

>Identically-implemented isn't possible, but I assume you mean you
>want the user interface to be the same.  Then you have a
>problem--since there's no Standard File stuff in the //e's sytem
>software, you have to write it yourself or change your user
>interface.  Portability is not generally one of the benefits of a
>desktop interface!

Exactly.  Whoopie.

>Okay, so put the little mouse pointer in the shaded "page down" area
>below the scroll thumb, and click the little mouse button a few
>times.  Or pick up the thumb and move it where you want.  I'm *sure*
>you nkow this, but I'm not sure why you're complaining!

The point is that sometimes programs hedge on the guidlines.  Also, if you
have ove about 100 options, you really can't use the thumb effectively, you
end up going up and down, and spend as much time as whamming on the mouse
button in the first place!

>On the contrary!  Standardization isn't the problem at all.
>[example of customization]

Standardization supposedly guarantees that you always get the same thing
when the same type of event occurs.  And I can just see me sitting at your
GS, and trying to figure out just exaclty *how* to use your fileselector!
:-)

>Hey!  Capitalize my town's name, or I'll start decapitalizing your
>name, sean!  I know what you mean about the atmosphere...it was
>about 103 degrees here today, so I'm just staying inside and writing
>an Icon Editor.  

Sorry 'bout that.  Jeez, I sure hope you guys get some rain soon!

>>Sean Kamath (see, it really was mine!)

>--David A. Lyons  a.k.a.  DAL Systems

PS, for anyone who didn't see it in Open-Apple this month, Dave got
prominent mention by Tom Waisar this month.  Congrats on getting Roger
Wagner to publish your NDA thingie!  :-)
-- 
UUCP:  {decvax allegra ucbcad ucbvax hplabs ihnp4}!tektronix!reed!kamath
CSNET: reed!kamath@Tektronix.CSNET  ||  BITNET: reed!kamath@PSUVAX1.BITNET
ARPA:  reed!kamath@PSUVAX1.CS.PSU.EDU
US Snail: 3934 SE Boise, Portland, OR  97202-3126 (I hate 4 line .sigs!)