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