Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!UIAMVS.BITNET!AWCTTYPA
From: AWCTTYPA@UIAMVS.BITNET ("David A. Lyons")
Newsgroups: comp.sys.apple
Subject: hackers/users--interface issues
Message-ID: <8806220019.aa06928@SMOKE.BRL.ARPA>
Date: 22 Jun 88 10:40:44 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 160
X-Unparsable-Date: Tuesday 21 Jun 88 11:18 PM CT

>Date:         Tue, 21 Jun 88 05:50:24 GMT
>From:         Sean Kamath 
>Subject:      Re: hackers/users--interface issues

>But what are te majority of the toolbox calls for?  Hmmmmm?  Yes, the
>use of the mac environment. . . Which is slow.

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.)

>I'm not saying this is necessarily a bad thing, since Apple deemed it
>appropriate to allocate *8* megabytes for ROM, and therefore the
>waste of space is *not* an issue.  What I *am* saying is that perhaps
>the space could have been put to better use. . .

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

>Now *you* wait (Come one, Dave, you should be used to it, what with the
>Launcher. . . :-) :-) :-) )

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.

>Dave, what language are you in?  Forgive me, but that looks a *lot*
>like C.

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);

>[...] look at how big the code is for the toolbox routine (though I
>give you that I had not initially mentioned this at all.).  How much
>stack space is used total?  How much code (in bytes) is created?
>Certainly more than 20 6F FD. . .

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.)

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!

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.

>Frankly (though I have to admit I'm very used to the structure used,
>etc, and I *do* agree it is "better") I feel that it is a *little*
>(:-) more complicated,

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.

>passing two ints, a string, an address to a
>filter (?), some *function* return value (whoo!  Now that's a *BIG*
>step.  REALLY BIG.)

I'm not following that too well...what's passed is the address of a
Pascal function that looks likes the one below.  This complication is
OPTIONAL!  If you want *all* the files to be selectable, you can just
pass 'nil' instead of a function pointer!  (There's also a simpler
approach...the TypeListPtr parameter can point to an array of
filetypes--I don't use that approach myself because it doesn't give
the option of having files appear but be dimmed.)

function MyFilter(p: DirEntryPointer): integer;
begin
  if p^.filetype = {whatever you want} then
    MyFilter := 2   {2 means the file will be selectable}
  else
    MyFilter := 1;  {1 means the file will appear in the list but
                     won't be selectable}
   {return 0 if the file shouldn't appear in the list at all}
end;

>>The Standard File tools let the user select a disk and a directory in
>>a nice, standard way [...]
>Yeah, but again, code size. I *agree* that the mac face is *easier* to
>*use*.  But say I try and write the identically implemented program
>on a //e?

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!

>I *DON'T* like having to hang on the the mouse button for an hour and
>a half while I scroll to the file I want (Don't believe me?  OK, not
>an hour, but look at something like a disk repaire program, Suddenly,
>you have about 40 files, all called "UNNAMED FILE #xx", so you can't
>just type a U and go to it!

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!

>AN *SOME* (*NOT* *ALL*) programs *DO NOT ALLOW YOU TO ENTER A
>FILENAME!*.)  The problem with standardization is that they restrict.

On the contrary!  Standardization isn't the problem at all.
Standarization lets you CUSTOMIZE!  On the IIgs, if you don't like
the way Standard File works, you can write your own and put it in
your */SYSTEM/TOOLS directory.  And it will be available in *every*
program that uses the Standard File.  (If you don't think this is a
reasonable thing to do, I might just have to do it to annoy
you...I've been wishing I could go BACKWARDS through the list of
disks, instead of advancing to the NEXT one...takes too long with my
excessive collection of drives.)

>(Ever been to north liberty, anyone?  Rockin' sockin' town, I tell
>you! :-) (I hope you appreciate that, Dave.  You have to admit, the
>atmosphere is *very* condusive to coding. . . :-)

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.  

>Sean Kamath
>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!)

--David A. Lyons  a.k.a.  DAL Systems
  PO Box 287 | North Liberty, IA 52317
  BITNET: AWCTTYPA@UIAMVS
  CompuServe: 72177,3233
  GEnie mail: D.LYONS2