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