From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-057 Date: Tue, 13 Sep 1994 15:09:42 +0200 (MET DST) C.S.M.P. Digest Tue, 13 Sep 94 Volume 3 : Issue 57 Today's Topics: Best Sprite Package? CW PASCAL vs THINK PASCAL Items in system menu bar Text searches. Ticks (was: Clover+. interrupt?) What is the point of MPW? Where have the standards gone? [a high level question] The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP digest are available there. Also, the digests are available to WAIS users. To search back issues with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html. ------------------------------------------------------- >From gkm@jolt.mpx.com.au (Gavin K Maxwell) Subject: Best Sprite Package? Date: 19 Aug 1994 06:15:19 GMT Organization: Microplex Pty Ltd I would like to know peoples impressions of the available sprite animation libraries. The two I'm aware of are SpriteWorld and Sprite Animation Toolkit (SAT), are there any others? Which is the best? Are there any gotchas to watch out for? What are their limitations? Any help would be appreciated, -- Gavin, +---------------------+-----------------------------+ ||||||| | Gavin Maxwell, | "You can't have everything. | | _ _ | | gkm@jolt.mpx.com.au | Where would you put it!!" | | O O | | +61-2-3426236 | | | ^ | +---------------------+-----------------------------+ \ ~ / --- +++++++++++++++++++++++++++ >From mab22@po.cwru.edu (Mike Balfour) Date: 19 Aug 1994 14:47:14 GMT Organization: Overload Engineering In article <331iln$4fq@inferno.mpx.com.au>, gkm@jolt.mpx.com.au (Gavin K Maxwell) wrote: > I would like to know peoples impressions of the available sprite > animation libraries. The two I'm aware of are SpriteWorld and Sprite > Animation Toolkit (SAT), are there any others? Which is the best? > Are there any gotchas to watch out for? What are their limitations? > Well, it seems that more people out there are using SpriteWorld, just because it was released about a month before SAT. SpriteWorld is also more geared to C, where SAT was originally written for Pascal and has since been updated to be usable from C. Between the two, I'm very biased toward SAT. I beta-tested it for several months, and I found it was very easy to learn, easy to use, and just good quick code. It even makes my bad code run fast (who else can claim that?)! Somebody else recently posted the concern that SAT still has warnings in it from the author, Ingemar, about various kluges. I wouldn't be concerned - everything's actually amazingly stable. I should know, I tried some pretty strange things from time to time to try to make it break... MB -- - --------------------------------+-------------------------------- Mike Balfour, Partner | BS/MS Candidate - ECMP Overload Engineering | Case Western Reserve University "New Ideas for a Brighter Future" | Cleveland, OH +++++++++++++++++++++++++++ >From al@crucible.powertools.com (Al Evans) Date: 19 Aug 94 14:57:16 GMT Organization: PowerTools, Austin, Texas In article <331iln$4fq@inferno.mpx.com.au> gkm@jolt.mpx.com.au (Gavin K Maxwell) writes: >I would like to know peoples impressions of the available sprite >animation libraries. The two I'm aware of are SpriteWorld and Sprite >Animation Toolkit (SAT), are there any others? Which is the best? >Are there any gotchas to watch out for? What are their limitations? You might want to have a look at Graphic Elements. To my way of thinking, it offers a lot more flexibility than either SpriteWorld or SAT -- but then, I'm the author:-) As to which is best for you, that probably depends on what you want to do. Graphic Elements has lots of built-in features: buttons and sliders, horizontal and vertical mirroring, special effects. SpriteWorld has good performance with free licensing and complete source code. SAT has both C and Pascal interfaces and offers excellent support for older systems. Both Graphic Elements and SpriteWorld offer native PPC support; I'm not sure about SAT. --Al Evans-- -- Al Evans | Graphic Elements: A new standard for ________________________|__ high-performance interactive Macintosh graphics. al@crucible.powertools.com | Available from mac.archive.umich.edu - -------------------------| /mac/development/libraries/graphicelements2.sit.hqx +++++++++++++++++++++++++++ >From ez033265@ucdavis.edu (Will Iverson) Date: Fri, 19 Aug 1994 18:01:34 GMT Organization: University of California, Davis In article <479@crucible.powertools.com>, al@crucible.powertools.com (Al Evans) wrote: > In article <331iln$4fq@inferno.mpx.com.au> gkm@jolt.mpx.com.au (Gavin K Maxwell) writes: > > As to which is best for you, that probably depends on what you want > to do. Graphic Elements has lots of built-in features: buttons and > sliders, horizontal and vertical mirroring, special effects. SpriteWorld > has good performance with free licensing and complete source code. SAT > has both C and Pascal interfaces and offers excellent support for older > systems. Both Graphic Elements and SpriteWorld offer native PPC support; > I'm not sure about SAT. SAT (as of version 2.1.2) doesn't offer native PPC support. -Will Iverson +++++++++++++++++++++++++++ >From we37026@vub.ac.be (DICTUS ROY) Date: 20 Aug 1994 21:50:45 GMT Organization: Brussels Free Universities (VUB/ULB), Belgium I've looked at all three packages a while ago; SAT, SpriteWorld and Graphics Elements. I've written a few games using SAT and was most impressed with it. Good interface, logical structure, fast and reliable code. SpriteWorld looks good too, but seems much harder to use than SAT. Graphics Elements, to be frank, I wasn't very impressed with (no offense to the author). I liked SAT and SW better. I'll stick to SAT. I just like it the best and it has proven itself. Games on the Net that were written with SAT: - Asterax - Bachman 2 - CyberNation - Missions of the Reliant - Warbirds - ... How many games have been written with SpriteWorld? I don't recall ever having seen any reference to it in any game... Just my $0.02, - Roy +++++++++++++++++++++++++++ >From hamptn@uow.edu.au ( Dan Hampton ) Date: 25 Aug 1994 12:00:10 +1000 Organization: University of Wollongong, NSW, Australia. we37026@vub.ac.be (DICTUS ROY) writes: >I've looked at all three packages a while ago; SAT, SpriteWorld and >Graphics Elements. >I've written a few games using SAT and was most impressed with it. Good >interface, logical structure, fast and reliable code. >SpriteWorld looks good too, but seems much harder to use than SAT. >Graphics Elements, to be frank, I wasn't very impressed with (no offense >to the author). I liked SAT and SW better. >I'll stick to SAT. I just like it the best and it has pr >Games on the Net that were written with SAT: >- Asterax >- Bachman 2 >- CyberNation >- Missions of the Reliant >- Warbirds >- ... >How many games have been written with SpriteWorld? I don't recall ever >having seen any reference to it in any game... Yeah that is true, It'd be interesting to see if anything decent has been made with SpriteWorld. The latest version is very complete and packed with features, PPC native, and extremely fast. There can be a bit of fiddling around with things that you'd rather not have to deal with thou. Where can Graphic Elements be gotten from anyway? (ftp site {which one}) - -------------------------------------------------------------------- It is an important and popular fact that things are not always what they seem. For instance, on the planet Earth, man had always assumed that he was more intelligent than dolphins because he had achieved so much -- the wheel, New York, wars and so on -- whilst all the dolphins had ever done was muck about in the water having a good time. But conversely, the dolphins had always believed that they were far more intelligent than man -- for precisely the same reasons. -- Douglas Adams "The Hitch-Hikers' Guide To The Galaxy". - -------------------------------------------------------------------- Dan Hampton -- Austinmer, NSW, Australia. - -------------------------------------------------------------------- +++++++++++++++++++++++++++ >From al@crucible.powertools.com (Al Evans) Date: 25 Aug 94 14:29:13 GMT Organization: PowerTools, Austin, Texas In article <33gtva$gs7@wumpus.cc.uow.edu.au> hamptn@uow.edu.au ( Dan Hampton ) writes: >Yeah that is true, It'd be interesting to see if anything decent has been >made with SpriteWorld. The latest version is very complete >and packed with features, PPC native, and extremely fast. I have recently done some (contract) finishing work on a piece of educational software from a major educational publishing company that used SpriteWorld for its animation. >There can be a bit of fiddling around with things that you'd >rather not have to deal with thou. Although I did not deal directly with the animation routines in this package, it seemed to me that they required an enormous number of lines of code for what they did. >Where can Graphic Elements be gotten from anyway? (ftp site {which one}) See my .signature. --Al Evans-- -- Al Evans | Graphic Elements: A new standard for ________________________|__ high-performance interactive Macintosh graphics. al@crucible.powertools.com | Available from mac.archive.umich.edu - -------------------------| /mac/development/libraries/graphicelements2.sit.hqx +++++++++++++++++++++++++++ >From ingemar@lysator.liu.se (Ingemar Ragnemalm) Date: 28 Aug 1994 10:28:19 GMT Organization: (none) ez033265@ucdavis.edu (Will Iverson) writes: >SAT (as of version 2.1.2) doesn't offer native PPC support. This is true, and the reason is that CodeWarrior is so damn buggy! I've tried porting some smaller hacks to it, and I'm getting tired of rebooting over and over again, with the debugger not catching any problems at all. Actually, if there is some SKILLED programmer out there, with some experience with CodeWarrior Pascal, I'd be happy to let him/her try porting it. Perhaps a CodeWarrior version could skip the 68000 support and all blitters except 8-bit, just to get it running for PPC? Considering what package is BEST, I think it's a matter of needs and taste. SW is written as an Apple Manager. Fairly general, not too quick to get started with, handles sprite management only. I found it a little worrying to find out that it's made by a programmer who hasn't made a computer game in his life (that we know of). I mean, if HE can't make games with it, why should I believe I can? (The big problem I'm aiming at is the lack of a full game demo.) I'm not sure it has more USERS than SAT. More people have it, and I'm sure lots of people grab code from it, but who knows how many people uses it? It has some strong points, like staggered drawing (which isn't impossible in SAT, but a bit harder) and grouping the sprites in distinct so-called layers. SAT is written for kick-start coding, for getting up in the air quickly, with a very small set of calls for the beginner. It includes asynch sound, simply because 99.9% of the programmers will need that too, and you don't want all the hassle making it work with Sound Manager 2! Good support for Pascal as well as C is a must. Pascal is easier to work with, and SAT is made to be beginner-friendly. NONE of the others support Pascal to any extent that is worth mentioning. SAT clearly has the best support for Macs not supporting 8-bit color (i.e. old Macs and Powerbooks), and supports scrolling games. Graphical Elements, I've hardly had time to look at that at all, but I got the impression of a slightly different scope, not only at games. (I'll leave it to Al to make more specific statements.) -- - - Ingemar Ragnemalm, PhD Image processing, Mac shareware games E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se +++++++++++++++++++++++++++ >From dwareing@apanix.apana.org.au (David Wareing) Date: 29 Aug 94 03:21:33 GMT Organization: Apanix Public Access Unix, +61 8 373 5485 (5 lines) mab22@po.cwru.edu (Mike Balfour) writes: >In article <331iln$4fq@inferno.mpx.com.au>, gkm@jolt.mpx.com.au (Gavin K >Maxwell) wrote: >> I would like to know peoples impressions of the available sprite >> animation libraries. The two I'm aware of are SpriteWorld and Sprite >> Animation Toolkit (SAT), are there any others? Which is the best? >> Are there any gotchas to watch out for? What are their limitations? >Well, it seems that more people out there are using SpriteWorld, just >because it was released about a month before SAT. SpriteWorld is also more >geared to C, where SAT was originally written for Pascal and has since been >updated to be usable from C. Between the two, I'm very biased toward SAT. >I beta-tested it for several months, and I found it was very easy to learn, >easy to use, and just good quick code. It even makes my bad code run fast >(who else can claim that?)! Somebody else recently posted the concern that >SAT still has warnings in it from the author, Ingemar, about various >kluges. I wouldn't be concerned - everything's actually amazingly stable. >I should know, I tried some pretty strange things from time to time to try >to make it break... I'm not sure about the "more people use SpriteWorld" claim, but there have been several shareware games released lately that use SAT. And there are several more on the way. Seems to be a fairly hip and happening product. -- David Wareing Adelaide, South Australia dwareing@apanix.apana.org.au - ------------------------------------------------------------ Freelance Macintosh Games & Multimedia Programming --------------------------- >From jc@ac.dal.ca (JOHN CHRISTIE) Subject: CW PASCAL vs THINK PASCAL Date: 18 Aug 94 11:57:04 -0300 Organization: Dalhousie University, Halifax, Nova Scotia, Canada PASCAL keeners read this Has anyone here used MW PASCAL and THINK PASCAL. I would be terribly interested in hearing how they compare from those who have used them. Thanks John +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Fri, 19 Aug 1994 11:07:15 +0800 Organization: Department of Computer Science, The University of Western Australia In article <1994Aug18.115704.26744@dal1>, jc@ac.dal.ca (JOHN CHRISTIE) wrote: > Has anyone here used MW PASCAL and THINK PASCAL. I would be terribly >interested in hearing how they compare from those who have used them. The big difference between MW Pascal and Think Pascal is that MW Pascal is going somewhere, and Think Pascal isn't. MW Pascal still has it's problems (I'm still on 3.5 so my info may be out of date) but it's certainly a usable tool. [For 68K, the PPC one is very much a development version.] Think Pascal is, quite simply, the nicest development environment for the Macintosh. *However* MW is catching up quick and Think isn't going anywhere ): [for a variety of technical and marketting reasons] So it'll only be a matter of time before MW wins. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From drickey@irus.rri.uwo.ca (Daniel W. Rickey) Date: 18 Aug 1994 19:06:11 GMT Organization: Imaging Research Labs I have tried both. Actually, I have not had a chance try out the latest release (CW4). Version 3.5 was still too buggy to evaluate properly. However, it looks like debugging in Think Pascal is much easier. CW has a different way of implementing writelns - it automatically creates an output window like TP, and it takes over the menu bar. This makes the writeln mechanism mostly useless for debugging (as far as I can tell). It will probably be a long time before the CW debugger is as nice as the ThinkP debugger...but we can hope! Moving code from ThinkP to CW is proving to be "interesting". A few library functions are missing in CW, although this is not too big of a deal. There may be a few other differences in the way typecasting/type conversions are done between the two compilers. One of the VERY nice features of CW is that it gives compile time warnings, e.g., variable declared but not used, etc. The CW pascal and C compilers are also very similar, unlike Symantec's compilers. This should make mixing of C and Pascal code in the same application much easier. Daniel W. Rickey drickey@.irus.rri.uwo.ca Imaging Research Laboratories The J.P. Robarts Research Institute 100 Perth Drive London, Ontario CANADA N6A 5K8 +++++++++++++++++++++++++++ >From ez033265@ucdavis.edu (Will Iverson) Date: Thu, 18 Aug 1994 20:25:20 GMT Organization: University of California, Davis In article <1994Aug18.115704.26744@dal1>, jc@ac.dal.ca (JOHN CHRISTIE) wrote: > PASCAL keeners read this > > Has anyone here used MW PASCAL and THINK PASCAL. I would be terribly > interested in hearing how they compare from those who have used them. > > Thanks > John I've used both, although I've used Think Pascal far more. I haven't been able to port my Think Pascal project over to MW Pascal yet because of (apparent) lack of full SANE support (and maybe something else I haven't found yet!) - although I'm not sure who to blame. The Think debugger is fully integrated with the editor. You want to set a breakpoint? Just click while you're in the editor. Lightsbugs lets you look at memory, data structures, etc. You can stop your program and change values, as well as write small pieces of code to be executed instantly from within the program. I find the entire programming cycle to be very short. The debugger for MW is a seperate program, which has advantages & disadvantages. The good news is that you can edit a program without resetting it, but it's a lot more of a pain to to set breakpoints. The Think Editor supports pretty-printing, which means you can basically forget about formatting and have it do it all for you. The MW Editor is sparser (keyword & comment coloring, no pretty-printing). It is smarter about things like having the cursor run off the right edge, however. Think Pascal hasn't seen an update in years. MW Pascal is being updated as we speak, but doesn't feel as complete. When I can switch my project over to MW Pascal, then my whole lab will switch over and we'll get a couple more copies of MW. Of course, which is better also depends on what you're trying to do. -Will Iverson +++++++++++++++++++++++++++ >From philip@cs.uct.ac.za (Philip Machanick) Date: 19 Aug 1994 12:17:47 +0200 Organization: Computer Science Department, University of Cape Town Will Iverson (ez033265@ucdavis.edu) wrote: : The Think debugger is fully integrated with the editor. You want to set a : breakpoint? Just click while you're in the editor. Lightsbugs lets you : look at memory, data structures, etc. You can stop your program and : change values, as well as write small pieces of code to be executed : instantly from within the program. I find the entire programming cycle to : be very short. The Think Pascal environment is wonderful. If only it had been developed properly - in same ways it is still the best but you can't allow something to languish for so long without losing your lead eventually. Another thing no one has mentioned in MW's favour: you get a free C and C++ compiler thrown in with it ;) -- Philip Machanick philip@cs.wits.ac.za Computer Science Department, University of he Witwatesrand 2050 Wits, South Africa 27(11)716-3309 fax 339-7965 (at University of Cape Town until November: 27(21)650-4058) +++++++++++++++++++++++++++ >From oberst@gov.nt.ca (David Oberst) Date: Fri, 19 Aug 1994 15:10:03 GMT Organization: Government of the NWT, Canada In article <3320sb$16f@cs.uct.ac.za> philip@cs.uct.ac.za (Philip Machanick) writes: >Another thing no one has mentioned in MW's favour: you get a free >C and C++ compiler thrown in with it ;) >-- >Philip Machanick philip@cs.wits.ac.za >Computer Science Department, University of he Witwatesrand >2050 Wits, South Africa 27(11)716-3309 fax 339-7965 >(at University of Cape Town until November: 27(21)650-4058) Of course, to the true Pascalite, this could be considered a drawback instead of a positive . David Oberst/GNWT Bureau of Statistics/Yellowknife, NWT, Canada oberst@gov.nt.ca +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Sat, 20 Aug 1994 17:55:22 +0800 Organization: NCRPDA, Curtin University >version.] Think Pascal is, quite simply, the nicest development >environment for the Macintosh. *However* MW is catching up quick and >Think isn't going anywhere ): [for a variety of technical and marketting >reasons] So it'll only be a matter of time before MW wins. "a matter of time" likely being somewhere around about the end of the year when Metrowerks have said they will have their pascal compiler both supporting objects and compiling to PPC. Peter. -- Peter N Lewis - Macintosh TCP fingerpainter +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Sun, 21 Aug 1994 14:52:23 +0800 Organization: Department of Computer Science, The University of Western Australia In article <330bf3$eia@falcon.ccs.uwo.ca>, drickey@irus.rri.uwo.ca (Daniel W. Rickey) wrote: >Moving code from ThinkP to CW is proving to be "interesting". A few >library functions are missing in CW, although this is not too big of a >deal. There may be a few other differences in the way typecasting/type >conversions are done between the two compilers. MW Pascal implements MPW Pascal, not Think Pascal. I've used both Think and MPW Pascal a lot and I know whether the differences lie. But there are lots of gotchas out there for hard-core Think Pascal users. Good luck. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Sun, 21 Aug 1994 14:53:05 +0800 Organization: Department of Computer Science, The University of Western Australia In article <3320sb$16f@cs.uct.ac.za>, philip@cs.uct.ac.za (Philip Machanick) wrote: >Another thing no one has mentioned in MW's favour: you get a free >C and C++ compiler thrown in with it ;) ^^^ I'm not sure whether I'd consider this an advantage (: -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From Vik_Rubenfeld@lamg.com (Vik Rubenfeld) Date: 21 Aug 1994 13:41:55 GMT Organization: Los Angeles Macintosh Group BBS Q> MW Pascal implements MPW Pascal, not Think Pascal. I've used both Q> Think and MPW Pascal a lot and I know whether the differences lie. Q> But there are lots of gotchas out there for hard-core Think Pascal Q> users. Good luck. Could you post a list describing some of the differences? Thanks in advance. +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Mon, 22 Aug 1994 10:55:49 +0800 Organization: Department of Computer Science, The University of Western Australia In article <1088487199.6340968@lamgnet.lamg.com>, Vik_Rubenfeld@lamg.com wrote: >Could you post a list describing some of the differences? Thanks in advance. This is covered in one of the appendices in the Think Pascal reference manual. My personal favourite gotcha is the differences in the built-in string function copy. MPW (and MW) returns '' if any of the parameters are out of bounds whereas Think makes a best effort. eg copy('abcd', 3, 255) returns '' in MPW and MW and 'cd' in Think. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From trentmd@scooby.beloit.edu (Michael Trent) Date: 22 Aug 1994 23:08:50 GMT Organization: Beloit College Quinn "The Eskimo! (quinn@cs.uwa.edu.au) wrote: : In article <1994Aug18.115704.26744@dal1>, jc@ac.dal.ca (JOHN CHRISTIE) wrote: : > Has anyone here used MW PASCAL and THINK PASCAL. I would be terribly : >interested in hearing how they compare from those who have used them. : The big difference between MW Pascal and Think Pascal is that MW Pascal is : going somewhere, and Think Pascal isn't. AMEN BROTHER! As cool as it is to have a "We will not be Emulated!" c/c++ compiler, it was a new Pascal that drove me to order MWCW Gold! I've spent too much time fighting the age of THINK Pascal to enjoy it anymore. -- Mike Trent | Macintosh Specialist | Beloit College trentmd@stu.beloit.edu | Academic Computing | Beloit Wisconsin +++++++++++++++++++++++++++ >From kn@doc.ic.ac.uk (Keng Ng) Date: 23 Aug 1994 11:46:16 GMT Organization: Imperial College, Dept. of Computing In article , peter.lewis@info.curtin.edu.au (Peter N Lewis) wrote: > >version.] Think Pascal is, quite simply, the nicest development > >environment for the Macintosh. *However* MW is catching up quick and > >Think isn't going anywhere ): [for a variety of technical and marketting > >reasons] So it'll only be a matter of time before MW wins. > > "a matter of time" likely being somewhere around about the end of the year > when Metrowerks have said they will have their pascal compiler both > supporting objects and compiling to PPC. ^^^^^^^ Does that mean that we'll be able to use it for MacApp 2.0.1 projects ? -Keng _________________________________________________________________ Keng T. Ng Email: kn@doc.ic.ac.uk Imperial College, Dept. of Computing, Phone: +44 71 594 8287 180 Queen's Gate, Fax: +44 71 581 8024 London SW7 2BZ, UK _________________________________________________________________ +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Thu, 25 Aug 1994 11:30:54 +0800 Organization: Department of Computer Science, The University of Western Australia In article , kn@doc.ic.ac.uk (Keng Ng) wrote: >Does that mean that we'll be able to use it for MacApp 2.0.1 projects ? For PPC code? Unlikely without a lot of work. MacApp 2.0.1 is full of lots of skanky things that make taking it native tricky. Specifically: exception handling. -- Quinn "The Eskimo!" "Scout in a can. Simple, cheap, easy to use and it's expendable!" +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Thu, 25 Aug 1994 12:38:05 +0800 Organization: NCRPDA, Curtin University In article , quinn@cs.uwa.edu.au (Quinn "The Eskimo!") wrote: >My personal favourite gotcha is the differences in the built-in string >function copy. MPW (and MW) returns '' if any of the parameters are out >of bounds whereas Think makes a best effort. > >eg copy('abcd', 3, 255) returns '' in MPW and MW and 'cd' in Think. Yeah, this is mind nummingly anoying (although not quite annoying as DR/2s behaviour of copy :-) function TPcopy (source: string; start, count: integer): string; var i: integer; begin if (start < 1) then begin count := count - (1 - start); start := 1; end; if start + count > length(source) then begin count := length(source) - start + 1; end; if count < 0 then begin count := 0; end; source[0] := chr(count); BlockMove(@source[start], @source[1], count); TPcopy := source; end; Non optiomal, but who cares? Enjoy, Peter. -- Peter N Lewis - Macintosh TCP fingerpainter +++++++++++++++++++++++++++ >From ingemar@lysator.liu.se (Ingemar Ragnemalm) Date: 28 Aug 1994 09:54:00 GMT Organization: (none) peter.lewis@info.curtin.edu.au (Peter N Lewis) writes: >>version.] Think Pascal is, quite simply, the nicest development >>environment for the Macintosh. *However* MW is catching up quick and >>Think isn't going anywhere ): [for a variety of technical and marketting >>reasons] So it'll only be a matter of time before MW wins. >"a matter of time" likely being somewhere around about the end of the year >when Metrowerks have said they will have their pascal compiler both >supporting objects and compiling to PPC. I doubt it. Even though PPC support is a strong point, they are so much behind in all other areas. No auto-indentation, not even on command. The debugger is a pain in the ass compared to Lightsbug - and where are Observe and Instant, my two favourite features? The debugger doesn't even seem to catch any errors to speak of. I hate when the program stops running, and the debugger says nothing, and I don't even know where it stopped. And the resource file is handled in the BRAIN-DAMAGED way that Think C used up to version 5. I hope they can make a decent product of it, but I can see my productivity going down... Back to the Lightspeed C days, when debugging took several times longer, since there were no decent debugger arund. -- - - Ingemar Ragnemalm, PhD Image processing, Mac shareware games E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se +++++++++++++++++++++++++++ >From ingemar@lysator.liu.se (Ingemar Ragnemalm) Date: 28 Aug 1994 10:00:26 GMT Organization: (none) Vik_Rubenfeld@lamg.com (Vik Rubenfeld) writes: >Q> MW Pascal implements MPW Pascal, not Think Pascal. I've used both >Q> Think and MPW Pascal a lot and I know whether the differences lie. >Q> But there are lots of gotchas out there for hard-core Think Pascal >Q> users. Good luck. >Could you post a list describing some of the differences? Thanks in advance. Some obvious differences are that no managers are automatically used (thus, I'm building up a set of stuff to "uses" in all files - finding out exactly what standard managers to use is a pain), and initializations aren't automatic. All QuickDraw globals are in a "qd" record. -- - - Ingemar Ragnemalm, PhD Image processing, Mac shareware games E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se +++++++++++++++++++++++++++ >From howarth@bromo.med.uth.tmc.edu (Jack W. Howarth) Date: 28 Aug 1994 18:28:52 GMT Organization: University of Texas Medical School In article <33pn7q$l5h@newsy.ifm.liu.se> ingemar@lysator.liu.se (Ingemar Ragnemalm) writes: > Some obvious differences are that no managers are automatically used (thus, > I'm building up a set of stuff to "uses" in all files - finding out exactly > what standard managers to use is a pain), and initializations aren't > automatic. All QuickDraw globals are in a "qd" record. Are you sure that some of your complaints are directed at the new Universal Headers from Apple and not MW Pascal itself? Jack W. Howarth, Ph.D. Univ. of Texas Medical School Research Fellow P.O. Box 20708 Department of Biochemistry Houston, Texas 77225 +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Mon, 29 Aug 1994 10:10:52 +0800 Organization: NCRPDA, Curtin University >Some obvious differences are that no managers are automatically used (thus, >I'm building up a set of stuff to "uses" in all files - finding out exactly >what standard managers to use is a pain), and initializations aren't ObiWan will tell you which unit to include for a given procedure. I have the same problem, but a few compiles and it's fixed. Also, you can use stuff like this: {$IFC undefined THINK_Pascal} uses Events; {$ENDC} To avoid having to include all the dummy unix in THINK Pascal. Peter. -- Peter N Lewis - Macintosh TCP fingerpainter --------------------------- >From chrism@col.hp.com (Chris Magnuson) Subject: Items in system menu bar Date: 17 Aug 1994 20:17:44 GMT Organization: HP Colorado Springs Division I was reading about the Menu Manager last night, trying to figure out how to stick icons in the Finder's menu bar (right up there next to the balloon, for example). Anyone have any ideas on how to do this? Is this considered Menu #0 and you just GetMenuHandle() on that? Hmm. Any hints would be appreciated. Thanks, Chris Magnuson chrism@col.hp.com +++++++++++++++++++++++++++ >From spencerl@crl.com (Spencer Low) Date: Wed, 17 Aug 1994 15:33:08 -0800 Organization: LowTek Creations In article <32tr98$pfg@hp-col.col.hp.com>, chrism@col.hp.com (Chris Magnuson) wrote: > I was reading about the Menu Manager last night, trying to figure out > how to stick icons in the Finder's menu bar (right up there next to > the balloon, for example). Anyone have any ideas on how to do this? > Is this considered Menu #0 and you just GetMenuHandle() on that? If you want to install a System Menu (i.e. ColorSwitch, OtherMenu, Help menu, Application menu, etc.), check out the "star-menu" source at UMICH. Or read up on TSM menus in Inside Mac: Text. Spencer +++++++++++++++++++++++++++ >From Jens Alfke Date: Thu, 25 Aug 1994 00:27:15 GMT Organization: Apple Computer Chris Magnuson, chrism@col.hp.com writes: > I was reading about the Menu Manager last night, trying to figure out > how to stick icons in the Finder's menu bar (right up there next to > the balloon, for example). Anyone have any ideas on how to do this? > Is this considered Menu #0 and you just GetMenuHandle() on that? There are really two things you want: (1) How to give a menu an icon as a title. Simple: It has to have a five character name, of which the first byte is '\01' (Ascii 01) and the other four are a handle to an icon suite. Needless to say, don't dispose the icon suite before the menu goes away. (2) How to put a menu on the right side of the menu bar. There's a particular range of negative menu IDs that signal a system menu; if you add a menu with such an ID it automatically goes on the right side, and it automatically will be added to the menu bar of every app that's launched. This means it's best to install such menus as soon as the menu bar first comes up; e.g. by patching DrawMenuBar. Make sure you load the icon into the System heap, of course, otherwise it'll be disposed when the current app quits. I believe there is sample code somplace showing how to do this. Disclaimer: None of this stuff is supported by Apple (though it's cool) and these techniques may break in the future. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From rollin@newton.apple.com (Keith Rollin) Date: Sun, 28 Aug 1994 18:39:36 -0800 Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows? In article <32tr98$pfg@hp-col.col.hp.com>, chrism@col.hp.com (Chris Magnuson) wrote: > I was reading about the Menu Manager last night, trying to figure out > how to stick icons in the Finder's menu bar (right up there next to > the balloon, for example). Anyone have any ideas on how to do this? > Is this considered Menu #0 and you just GetMenuHandle() on that? The following tips concerning being compatible with future Mac OSes were distributed (I think) at the last WWDC: 7. Extensions that try to modify menus in applications without their knowledge will no longer work. 8. Extensions that install menus in the system portion of the menu bar will break if they access Menu Manager data without using the Menu Manager API. 9. Extensions that augment or override the behavior of the Apple menu (like adding hierarchical menus) will break. That said, here's an INIT written by someone in Mac DTS that does what you're asking. Given the above warnings, I would consider the following hack to be unsupported, but about as best as you can do given today's Toolbox API. ; Sample INIT that puts up a system wide menu and installs a handler for it. ; The general idea of this is that it waits for the system to install a system menu and then ; when that menu is installed it installs its own menu. The patch to SystemMenu is what is ; used to determine what to do when an item is selected. ; ; Use the following MPW commands to build the INIT: ; ; asm SampleINIT.a -o SampleINIT.a.o ; Link -o SampleINIT -rt INIT=128 -ra Main=resSysHeap -t INIT SampleINIT.a.o ; duplicate SampleINIT "{SystemFolder}Extensions:aSampleINIT" ; ; Hack courtesy of Apple Developer Tech Support ; Change History: ; 12/10/93 JLM Created the INIT and made items beep with sysbeep ; PRINT PUSH,OFF ; don't print any of this stuff INCLUDE 'ToolEqu.a' INCLUDE 'Traps.a' INCLUDE 'PackMacs.a' INCLUDE 'QuickEqu.a' INCLUDE 'SysEqu.a' PRINT POP ; restore the PRINT options theStub proc Export Import ENTRY bra ENTRY EndP MyGlobals Record 0 OldInsertMenu ds.L 1 OldSystemMenu ds.L 1 MyMenuHand ds.L 1 MyMenuID ds.W 1 EndR tenderID equ $BF99 ; this looks like a good start Globals proc Export ds MyGlobals Export MyMenuStr MyMenuStr dc 'Item1;Item2' ; Export MyMenuTitle MyMenuTitle dc 'SMU' ; and our menu EndP MyInsertMenu proc Export InsMenuFrame Record {xA6Link},DECR xParmBegin equ * theMenu ds.L 1 before ds.W 1 xParmSize equ xParmBegin-* xRetAddr ds.L 1 xJumpThru ds.L 1 ; store the real address here on stack for unwinding xA6Link ds.L 1 * Insert local vars here ZoneSave ds.L 1 xLocalSize equ * endr with InsMenuFrame,MyGlobals clr.L -(sp) ; for the return address of this routine LINK A6,#xLocalSize movem.L D0-D2/A0-A4,-(sp) ; save these temp registers lea Globals,A4 ; get our globals pointer so we can test further move.L theMenu(A6),A0 ; get the menu handle being installed move.L (A0),A0 ; deref it tst.W (A0) ; see if its a system menu bpl.s @IgnorePatch ; if so ignore the patch stuff move.W MyMenuID(A4),D0 tst.W D0 ; see if we are installed yet... beq.s @InstallMe ; nope better install ourselves first cmp.W (A0),D0 ; see if our menu has the same ID as this menu bne.s @IgnorePatch ; it does not, we can leave now @IDConflict ; if we get here the system menu ID number we have choosen is in conflict with a system menu ; used by the system. We could try to change our number or bail out. I choose bailing out ; for this example. The proper thing to do might be to examine the menu list and try a different ; number. move.W MyMenuID(A4),-(sp) ; first delete the menu from the menu bar _DeleteMenu ; ok now the menu is deleted move.W #1,MyMenuID(A4) ; and reset our menu ID to not ever be a system menu but be non-zero move.L MyMenuHand(A4),-(sp) _DisposeMenu ; and dump the menu itself move.L #1,MyMenuHand(A4) ; and zots the menu handle as well bra.s @ignorePatch ; and exit @InstallMe move.L theZone,zoneSave(A6) move.L SysZone,A0 _SetZone ; insure that the new menu goes into the system heap clr.L -(sp) ; first create our menu move.W #tenderID,-(sp) ; move our projected ID on the stack pea MyMenuTitle ; and push our title pointer _NewMenu move.L (sp),MyMenuHand(A4) ; set up our menu handle in memory pea MyMenuStr _AppendMenu ; now we have built us a menu move.W #tenderID,MyMenuID(A4) move.L zoneSave(A6),A0 _SetZone ; switch back to the app heap move.L MyMenuHand(A4),-(sp) move.W #tenderID,-(sp) move.L OldInsertMenu(A4),A0 jsr (A0) ; call the real insert menu to insert us ; ok, now we are inserted and we will work just fine... ; @ignorePatch ; dummy up the stack to have the address of the real patch so's I can use RTS to jump to ; the real patch instead of A0 move.L OldInsertMenu(A4),xJumpThru(A6) movem.L (sp)+,D0-D2/A0-A4 ; restore the stack unlk A6 ; and A6 rts ; now call back the original EndP MySystemMenu proc Export InsMenuFrame Record {xA6Link},DECR xParmBegin equ * theItem ds.W 1 theMenuID ds.W 1 xParmSize equ xParmBegin-* xRetAddr ds.L 1 xJumpThru ds.L 1 ; store the real address here on stack for unwinding xA6Link ds.L 1 * Insert local vars here xLocalSize equ * EndR with InsMenuFrame,MyGlobals clr.L -(sp) ; for the return address of this routine LINK A6,#xLocalSize movem.L D0-D2/A0-A4,-(sp) ; save these temp registers lea Globals,A4 ; get our globals pointer so we can test further move.W theMenuID(A6),D0 cmp.W MyMenuID(A4),D0 ; see if its our menu bne.s @ignorePatch ; if not simply call thru to he other side ; else this is our menu, for right now we will simply beep at the user move.L #$00050005,-(sp) ; set up to beep twice _Sysbeep _SysBeep ; and since we handled the menu we will now return to the caller movem.L (sp)+,D0-D2/A0-A4 ; restore the stack unlk A6 ; and A6 addQ.L #4,sp ; remove the long we pushed on the stack earlier move.L (sp)+,(sp) ; and remove the return address and place it on top of the parms rts ; and return to our regularly scheduled app. @ignorePatch ; dummy up the stack to have the address of the real patch so's I can use RTS to jump to ; the real patch instead of A0 move.L OldSystemMenu(A4),xJumpThru(A6) movem.L (sp)+,D0-D2/A0-A4 ; restore the stack unlk A6 ; and A6 rts ; now call back the original EndP ENTRY proc export With MyGlobals _Debugger ; enter the debugger so's I can test this stuff out movem.L A0-A5/D0-D7,-(sp) ; save regs to be safe lea Globals,A4 ; set up our globals move.L SysZone,A0 _SetZone lea theStub,A0 ; now get our handle detach and lock it down its already _RecoverHandle ; in the system heap move.L A0,-(sp) _DetachResource ; and detach the bad boy... Move.W #$A935,D0 ; now insert my patch to InsertMenu $A935 _GetTrapAddress move.L A0,OldInsertMenu(A4) lea MyInsertMenu,A0 Move.W #$A935,D0 _SetTrapAddress Move.W #$A9B5,D0 ; now insert my patch to SystemMenu $A9B5 _GetTrapAddress move.L A0,OldSystemMenu(A4) lea MySystemMenu,A0 Move.W #$A9B5,D0 _SetTrapAddress moveQ #0,D0 move.W D0,MyMenuID(A4) Move.L D0,MyMenuHand(A4) move.L ApplZone,A0 _SetZone movem.L (sp)+,A0-A5/D0-D7 ; save regs to be safe rts EndP End - -------------------------------------------------------------------------- Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton --------------------------- >From zorro@cats.ucsc.edu (zorro) Subject: Text searches. Date: 16 Aug 1994 17:52:29 GMT Organization: University of California; Santa Cruz Constantly I find myself in the situation that Dina described... not knowing where to look for a particulat #define, variable, or function. So what I end up doing is uploading whole directories to my trusty Sparc and using the 'grep' command. I realize this is wrong on a very basic level and so what I want to ask is, does anyone know of an MPW Tool that duplicates the functionality of 'grep'? I could write one myself, all it would have to do is look through .c and .h files for a text pattern, but I would prefer it if I didn't have to. So, has anyone out there implemented 'grep'?? - Dan +++++++++++++++++++++++++++ >From mcrawfor@bio.ri.ccf.org (Mike Crawford) Date: Tue, 16 Aug 1994 19:08:16 GMT Organization: The Cleveland Clinic Foundation In article 2pg@darkstar.UCSC.EDU, zorro@cats.ucsc.edu (zorro) writes: > > >Constantly I find myself in the situation that Dina described... not knowing >where to look for a particulat #define, variable, or function. >So what I end up doing is uploading whole directories to my trusty Sparc >and using the 'grep' command. I realize this is wrong on a very basic level >and so what I want to ask is, does anyone know of an MPW Tool that duplicates >the functionality of 'grep'? >I could write one myself, all it would have to do is look through .c and .h >files for a text pattern, but I would prefer it if I didn't have to. > >So, has anyone out there implemented 'grep'?? > >- Dan > MPW  has a tool called 'search' which functions just like the 'grep' command. Ex. search "Str255" {CIncludes}*.h // searches all .h files in the current directory for // any occurance of 'Str255' ****  NOTE, the wildcard character is not an asterisk, it's a double skwiggly line and can be created by the option-x key combination... I just couldn't duplicate it in this message. Sorry for the crudity of my example. the search command is very useful... I use it daily good luck mwc - ---------- Internet: mcrawfor@bio.ri.ccf.org AOL: Marlin89@aol.com eWorld: Marlin89@eworld.com - ---------- "And the people all said, "Sit down!" your rockin the boat..." - ---------- +++++++++++++++++++++++++++ >From siegel@netcom.com (Rich Siegel) Date: Tue, 16 Aug 1994 23:01:36 GMT Organization: Bare Bones Software In article <32quct$2pg@darkstar.UCSC.EDU> zorro@cats.ucsc.edu (zorro) writes: >So what I end up doing is uploading whole directories to my trusty Sparc >and using the 'grep' command. I realize this is wrong on a very basic level >and so what I want to ask is, does anyone know of an MPW Tool that duplicates >the functionality of 'grep'? > >So, has anyone out there implemented 'grep'?? Time to read the fine manual, particularly the chapter which describes the "Search" tool. The MPW intrinsic "Help" has also proven safe and effective when used as directed, particularly when combined with the words "Expressions" and "Search". R. -- Rich Siegel % siegel@netcom.com % President & CEO, Bare Bones Software Inc. --> For information about BBEdit, finger bbedit@world.std.com <-- +++++++++++++++++++++++++++ >From bobo@reed.edu (Eric Bowman) Date: 17 Aug 1994 03:56:27 GMT Organization: Reed College, Portland, Oregon In article <32quct$2pg@darkstar.ucsc.edu>, zorro wrote: >Constantly I find myself in the situation that Dina described... not knowing >where to look for a particulat #define, variable, or function. >So what I end up doing is uploading whole directories to my trusty Sparc >and using the 'grep' command. I realize this is wrong on a very basic level >and so what I want to ask is, does anyone know of an MPW Tool that duplicates >the functionality of 'grep'? >I could write one myself, all it would have to do is look through .c and .h >files for a text pattern, but I would prefer it if I didn't have to. Well, "Search" has all the functionality of "grep", except it uses MPW's regular expression syntax instead of unix's. Other than that, though, it works great; better, even, than grep since it's so easy to jump to the results of the search by double-clicking lines spewed out by search. I just used it to do a very nasty search: I needed to "touch" every source file with an ASSERT, Debugger, or DebugStr (just got ETO 15!)...to do this you need only do the following: setfile -m . \d `grep -s /[AD][Se][Sb][Eu][Rg][TSg][te]*[r]*\d(/ \x.cp | \d streamedit -d -e '/File \d"(\x)\r1\d"\d;/ print \r1' | \d sort -unique` where \d = option-d \r = option-r \x = option-x Oh yeah, I have search aliased as "grep" :) Just try and do *that* in any other IDE... cheers, bobo +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Wed, 17 Aug 1994 15:26:30 +1200 (NZST) Organization: (none) zorro@cats.ucsc.edu (zorro) writes: > Constantly I find myself in the situation that Dina described... not knowing > where to look for a particulat #define, variable, or function. > So what I end up doing is uploading whole directories to my trusty Sparc > and using the 'grep' command. I realize this is wrong on a very basic level > and so what I want to ask is, does anyone know of an MPW Tool that duplicates > the functionality of 'grep'? > I could write one myself, all it would have to do is look through .c and .h > files for a text pattern, but I would prefer it if I didn't have to. What's wrong with "search"? Name too obscure, or something? search CloseWindow "{cincludes}"Å.h -- Bruce +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Wed, 17 Aug 1994 07:57:22 GMT Organization: Adobe Systems Incorporated writes > zorro@cats.ucsc.edu (zorro) writes: > > Constantly I find myself in the situation that Dina described... not knowing > > where to look for a particulat #define, variable, or function. > > So what I end up doing is uploading whole directories to my trusty Sparc > > and using the 'grep' command. I realize this is wrong on a very basic level > > and so what I want to ask is, does anyone know of an MPW Tool that duplicates > > the functionality of 'grep'? > > I could write one myself, all it would have to do is look through .c and h > > files for a text pattern, but I would prefer it if I didn't have to. > > What's wrong with "search"? Name too obscure, or something? There is a port of the GNU grep command to MPW. I picked it up off ftp.apple.com a year or two ago. Its faster and has more functionality than search. The Mac is still relatively slow at this sort of thing compared to a decent UNIX box though. -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 It seems like once people grow up, they have no idea what's cool. - Calvin +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Thu, 18 Aug 1994 03:11:36 +1200 (NZST) Organization: (none) zstern@adobe.com (Zalman Stern) writes: > There is a port of the GNU grep command to MPW. I picked it up off > ftp.apple.com a year or two ago. Its faster and has more functionality than > search. The Mac is still relatively slow at this sort of thing compared to a > decent UNIX box though. "search" used to be slow. I wrote my own tool to search for literal strings and it ran at 1.5 MB/sec on a Q700 with Quantum LPS240 HD, searching 40 MB of 200K files, while "search" ran at 300 KB/sec or so. Then, a year or two ago, I got a new version of MPW and the search ran at the same 1.5 MB/sec as my simple program did. I've gone back to MPW Search ever since. -- Bruce +++++++++++++++++++++++++++ >From becker@Xenon.Stanford.EDU (Denizen of the Deep) Date: 17 Aug 1994 16:35:59 GMT Organization: Computer Science Department, Stanford University. In article <32quct$2pg@darkstar.UCSC.EDU>, zorro wrote: > > >Constantly I find myself in the situation that Dina described... not knowing >where to look for a particulat #define, variable, or function. >So what I end up doing is uploading whole directories to my trusty Sparc >and using the 'grep' command. I realize this is wrong on a very basic level >and so what I want to ask is, does anyone know of an MPW Tool that duplicates >the functionality of 'grep'? >I could write one myself, all it would have to do is look through .c and .h >files for a text pattern, but I would prefer it if I didn't have to. > >So, has anyone out there implemented 'grep'?? > >- Dan > If you are working in MPW, there are tools you can use to accomplish the same effect (though it's not as nice as grep IMHO). The "files" tool will list all the files in the specified directory, while the "search" tool will search all the given files for the specified pattern. In my worksheet, I have the following line marked as "Search in includes": search -s /Gestalt/ `files -o -f -t TEXT "{mpw}"Interfaces:CIncludes` This will search through all the MPW C header files for the given pattern. In this case, it is searching for Gestalt. To search for something else, just change what's inside the '/' delimiters. To search a different directory, replace the "{mpw}"Interfaces:Cincludes with the directory of your choice. You can also specify the -r option to the files tool, which will make the search recursively descend into subdirectories. Hope that helps. -Jon +++++++++++++++++++++++++++ >From timothys@hood.uucp (Timothy Sherburne) Date: 17 Aug 94 16:37:32 GMT Organization: University of Portland Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes: >zorro@cats.ucsc.edu (zorro) writes: >> Constantly I find myself in the situation that Dina described... not knowing >> where to look for a particulat #define, variable, or function. >> So what I end up doing is uploading whole directories to my trusty Sparc >> and using the 'grep' command. I realize this is wrong on a very basic level >> and so what I want to ask is, does anyone know of an MPW Tool that duplicates >> the functionality of 'grep'? >> I could write one myself, all it would have to do is look through .c and .h >> files for a text pattern, but I would prefer it if I didn't have to. >What's wrong with "search"? Name too obscure, or something? > search CloseWindow "{cincludes}"Å.h >-- Bruce All these suggestions to use the "search" tool are fine, but you can also install the "poptag" tool (found on the May '94 Tool Chest CD, but I couldn't find it on ETO 15 :( It works like this: highlight some function name, etc. and type cmd-P. The definition will be given. Works well IF you've got some extra space on your HD and the time to install it. t -- | Timothy Sherburne | Software Engineer | | Internet: timothys@uofport.edu | Prometheus Products, Inc. | | AppleLink: D6164@applelink.apple.com | 1-800-477-3473 | *All comments are my own and in no way represent those of Prometheus Products* +++++++++++++++++++++++++++ >From sw@network-analysis-ltd.co.uk (Sak Wathanasin) Date: Thu, 18 Aug 94 10:35:34 BST Organization: Network Analysis Ltd In article <1994Aug17.075722.17513@adobe.com> (comp.sys.mac.programmer), zstern@adobe.com (Zalman Stern) writes: > There is a port of the GNU grep command to MPW. I picked it up off > ftp.apple.com a year or two ago. Its faster and has more functionality than > search. The Mac is still relatively slow at this sort of thing compared to a > decent UNIX box though. There's also "agrep" which is very fast; can't remember where I got this from, but I can post to macgifts if people want it. Unfortunately, it doesn't generate MPW-executable output like "Search", but it's dead useful just for seeing which header file contains which definition. Sak Wathanasin Network Analysis Limited 178 Wainbody Ave South, Coventry CV3 6BX, UK Internet: sw@network-analysis-ltd.co.uk uucp: ...!uknet!nan!sw AppleLink: NAN.LTD Phone: (+44) 203 419996 Mobile:(+44) 850 587411 Fax: (+44) 203 690690 +++++++++++++++++++++++++++ >From lsr@taligent.com (Larry Rosenstein) Date: Fri, 19 Aug 1994 17:30:55 GMT Organization: Taligent, Inc. In article , sw@network-analysis-ltd.co.uk wrote: > There's also "agrep" which is very fast; can't remember where I got > this from, but I can post to macgifts if people want it. Unfortunately, If it's the same one I'm thinking of, then this is a fast string searcher that allows for errors in the text (ie, it's more of a fuzzy match). The information I have says the source is available at ftp://cs.arizona.edu/agrep/. -- Larry Rosenstein Taligent, Inc. lsr@taligent.com +++++++++++++++++++++++++++ >From hammett@sbsu1.auckland.ac.nz (Tim Hammett) Date: 20 Aug 1994 23:25:41 GMT Organization: University of Auckland becker@Xenon.Stanford.EDU (Denizen of the Deep) writes: >search -s /Gestalt/ `files -o -f -t TEXT "{mpw}"Interfaces:CIncludes` Why not use: search -s /Gestalt/ "{CIncludes}=.h" (where = is option-x, i.e. the squiggly equals sign) -- Tim Hammett, School of Biological Sciences, Auckland University, New Zealand. t.hammett@auckland.ac.nz Phone: +64-9-373-7599 x7298 FAX: +64-9-373-7416 +++++++++++++++++++++++++++ >From rollin@newton.apple.com (Keith Rollin) Date: Wed, 24 Aug 1994 13:38:37 -0800 Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows? In article <32te9f$goj@Times.Stanford.EDU>, becker@Xenon.Stanford.EDU (Denizen of the Deep) wrote: > >If you are working in MPW, there are tools you can use to accomplish the >same effect (though it's not as nice as grep IMHO). I have a question for you, Jon: What does "grep" do that makes it so much nicer than "search"? >The "files" tool >will list all the files in the specified directory, while the "search" >tool will search all the given files for the specified pattern. > >In my worksheet, I have the following line marked as "Search in includes": > >search -s /Gestalt/ `files -o -f -t TEXT "{mpw}"Interfaces:CIncludes` > >This will search through all the MPW C header files for the given pattern. >In this case, it is searching for Gestalt. To search for something else, >just change what's inside the '/' delimiters. To search a different >directory, replace the "{mpw}"Interfaces:Cincludes with the directory >of your choice. You can also specify the -r option to the files tool, >which will make the search recursively descend into subdirectories. Geeze, you make it look so difficult. I simply use: search Gestalt "{CIncludes}" Actually, I fibbed. I never do that. I just select the item in my Edit menu that lets me search a common directory. In my UserStarup*Keith file, I have: Set FabFolders "`quote '{CIncludes}' '{PInterfaces}' '{AIncludes}' '{RIncludes}' '{MACPlusIncludes}' '{MALibraries}' '{MPWCustom}Scripts:' '{MPW}Scripts:' `" For f in {FabFolders} AddMenu "Find" "Search in {f}" "SearchIn "{f}" "{WorkSheet}"" End "SearchIn" is the following script: Set Expr "`Request 'Enter regular expression' || Echo ''`" Exit If "{Expr}" == "" open "{WorkSheet}" if "{expr}" =~ /[a-z0-9]+/ Search "{Expr}" "{1}" else Search /{Expr}/ "{1}" end - -------------------------------------------------------------------------- Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton +++++++++++++++++++++++++++ >From rollin@newton.apple.com (Keith Rollin) Date: Thu, 25 Aug 1994 16:06:09 -0800 Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows? In article , sw@network-analysis-ltd.co.uk wrote: >In article <1994Aug17.075722.17513@adobe.com> (comp.sys.mac.programmer), zstern@adobe.com (Zalman Stern) writes: > >> There is a port of the GNU grep command to MPW. I picked it up off >> ftp.apple.com a year or two ago. Its faster and has more functionality than >> search. The Mac is still relatively slow at this sort of thing compared to a >> decent UNIX box though. > >There's also "agrep" which is very fast; can't remember where I got >this from, but I can post to macgifts if people want it. Unfortunately, >it doesn't generate MPW-executable output like "Search", but it's dead >useful just for seeing which header file contains which definition. I got a copy, dated Jan 1992, from cs.arizona.edu as agrep/agrep-2.04.tar. Comes with source. I haven't tried it though. - -------------------------------------------------------------------------- Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton +++++++++++++++++++++++++++ >From rollin@newton.apple.com (Keith Rollin) Date: Sun, 28 Aug 1994 18:21:13 -0800 Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows? In article <3363dl$sil@ccu2.auckland.ac.nz>, hammett@sbsu1.auckland.ac.nz (Tim Hammett) wrote: >becker@Xenon.Stanford.EDU (Denizen of the Deep) writes: >>search -s /Gestalt/ `files -o -f -t TEXT "{mpw}"Interfaces:CIncludes` > >Why not use: > >search -s /Gestalt/ "{CIncludes}=.h" > >(where = is option-x, i.e. the squiggly equals sign) Using the following is much faster: search -s Gestalt "{CIncludes}=.h" The reason for this is that delimiting the search string with slashes tells the Shell to perform a regular expression search. But the Shell can also perform faster searches using a Boyer-Moore algorithm when it thinks it's OK. Right now, the only way it can tell this is when you feed it a straight string. It would be nice if the searching routines would look in the slashes and determine if it can use a Boyer-Moore search, but that's not the way it works right now. - -------------------------------------------------------------------------- Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton --------------------------- >From rmartin@luddites.tiac.net (Rich Martin) Subject: Ticks (was: Clover+. interrupt?) Date: Mon, 29 Aug 1994 14:58:16 -0500 Organization: Luddite Softwerks PMJI, but this Ticks thing still haunts me. A project I worked on recently was real-time intensive, and I assumed that Ticks would be incremented every 1/60th second. IM told me that this was not guaranteed to happen every time, but my assumption was that I would get no *more* than 60 ticks in a second. All my time measurements went haywire. After much hair pulling, we did some empirical tests and discovered that we were getting something like 3605 ticks per minute. Yow! Slightly more than 60 ticks per second! Over the course of 30 minutes, my program behaved as though it were late when it actually was not. Once we accounted for this unexpected Tick rate, timing improved sufficiently. Comments? -- ____________________________________________________________________ http://www.mps.ohio-state.edu/cgi-bin/hpp?RichMartin.html | Not | __________________________________________________________| Insane! | It's Easy to be Easy when You're Easy... |_________| +++++++++++++++++++++++++++ >From michael.martz@aldus.com (Michael Martz) Date: 29 Aug 1994 20:41:40 GMT Organization: Aldus Corporation, Seattle, WA USA I had the very same thing happen to me a while ago. I set up code using the time manager to count the number of ticks per second expecting to find 55-60. When it turned out that I was getting 60+, I double checked everything and then compared it to an external timing source. I concluded that IM was incorrect. I don't know why this occurs, but rest assured you are sane. For periods around 30 minutes you really should be using the new Time Manger rather than Ticks. _______________________________________________________________________ Michael Martz michael.martz@aldus.com Aldus Corp. +++++++++++++++++++++++++++ >From spector@bach.seattleu.edu (Mitchell S. Spector) Date: 30 Aug 1994 09:24:58 -0700 Organization: Seattle University, Seattle, Washington, U.S.A. In article , Rich Martin wrote: >PMJI, but this Ticks thing still haunts me. A project I worked on recently >was real-time intensive, and I assumed that Ticks would be incremented >every 1/60th second. IM told me that this was not guaranteed to happen >every time, but my assumption was that I would get no *more* than 60 ticks >in a second. All my time measurements went haywire. After much hair >pulling, we did some empirical tests and discovered that we were getting >something like 3605 ticks per minute. Yow! Slightly more than 60 ticks per >second! Over the course of 30 minutes, my program behaved as though it >were late when it actually was not. Once we accounted for this unexpected >Tick rate, timing improved sufficiently. Comments? I know IM says in various places that a tick is 1/60 of a second. But, according to the discussion of the video interface in IM vol. III, the vertical scan rate of the original Macintosh monitor was 60.15 Hz, not 60 Hz. I presume this implies that VBL interrupts were generated every 1/60.15 sec, a little faster than 1/60 sec. This would mean that there were 3609 ticks per minute. I have no idea if Apple has maintained compatibility with the original Mac to the point of generating VBL interrupts at exactly the same frequency as on the original Mac. But I take all this to mean that Apple does not guarantee the exact frequency of the VBL interrupt, and that no program should use ticks for exact timing. The Time Manager should be used for that. >-- >____________________________________________________________________ >http://www.mps.ohio-state.edu/cgi-bin/hpp?RichMartin.html | Not | >__________________________________________________________| Insane! | > It's Easy to be Easy when You're Easy... |_________| -- Mitchell Spector Dept. of Computer Science and Software Engineering Seattle University E-mail: spector@seattleu.edu +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Tue, 30 Aug 1994 20:33:13 +0200 Organization: Royal Institute of Something or other In article , rmartin@luddites.tiac.net (Rich Martin) wrote: >were late when it actually was not. Once we accounted for this unexpected >Tick rate, timing improved sufficiently. Comments? Yeah, there are 60.15 ticks per second. This is documented. What you should do is use the NewImprovedREALLYDriftFreeTimeManager to install a ReallyDriftFree TimeManager task that increments a variable. The plus side of this is that you get to set the interval of the "ticks" Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Reality exists only in your imagination. +++++++++++++++++++++++++++ >From radixinc@aol.com (RadixInc) Date: 30 Aug 1994 18:16:06 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <33vmgq$sqi@bach.seattleu.edu>, spector@bach.seattleu.edu (Mitchell S. Spector) writes: <> Apple has maintained compatibility; regardless of the actual monitor frequency, a "VBL" interrupt is synthesized, supposedly at the original 60.15/sec rate. As others have mentioned using the Ticks/VBL mechanism for accurate timing is not advised, because (a) the frequency is not guaranteed, and (b) VBL tasks (and updating Ticks) don't happen while interrupts are disabled. Gregory Jorgensen Radix Consulting Inc. --------------------------- >From tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) Subject: What is the point of MPW? Date: 13 Aug 1994 15:39:41 GMT Organization: The Ohio State University Hi: I was given a copy of MPW 3.3 (not pirated, I was given all of the materials in the huge box),and have the current shell from CodeWarrior. I am doing all of my own work on CodeWarrior and I want to devote some energy to learning MPW. What priority should I give this, though. Exactly what can I do with MPW which I cannot do with CodeWarrior or SC++? Thanks; Tim +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Sat, 13 Aug 1994 20:06:23 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) writes: >I was given a copy of MPW 3.3 (not pirated, I was given all of the >materials in the huge box),and have the current shell from CodeWarrior. > I am doing all of my own work on CodeWarrior and I want to devote some >energy to learning MPW. What priority should I give this, though. >Exactly what can I do with MPW which I cannot do with CodeWarrior or >SC++? The MPW compilers are so out-of-date that unless you have old software developed under MPW you need to maintain, don't bother. MPW is basically a UNIX-like command line oriented environment, under which you can run various UNIX-like tools. It's useful if you need to build UNIX-like tools to process data as part of your program-building process. MPW dates from when the Mac could only run one program at a time, and it has its own hack for running "MPW tools" under its own shell. John Nagle +++++++++++++++++++++++++++ >From mclow@san_marcos.csusm.edu (Marshall Clow) Date: Sat, 13 Aug 1994 13:53:09 -0800 Organization: Aladdin Systems In article <32ipft$18t@charm.magnus.acs.ohio-state.edu>, tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) wrote: > Hi: > > I was given a copy of MPW 3.3 (not pirated, I was given all of the > materials in the huge box),and have the current shell from CodeWarrior. > I am doing all of my own work on CodeWarrior and I want to devote some > energy to learning MPW. What priority should I give this, though. > Exactly what can I do with MPW which I cannot do with CodeWarrior or > SC++? > Try this in CodeWarrior (or Think, for that matter). Build an application containing 4 LDEFs, 2 MDEFs, 3 WDEFs, as well as 12 plug in tools, putting the 'CODE' resources and the xDEF resources in a file of type 'APPL', while each of the tools goes in a seperate file. Don't forget to put the build date (and time) into the 'vers' resource so that testers can tell exactily what they have. After you have built the application, compress the resources in the application. Oh yes, do this by choosing a single menu option. -- Marshall Clow Aladdin Systems mclow@san_marcos.csusm.edu +++++++++++++++++++++++++++ >From afcjlloyd@aol.com (AFC JLloyd) Date: 13 Aug 1994 16:59:05 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , nagle@netcom.com (John Nagle) writes: >tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) writes: >>I was given a copy of MPW 3.3 (not pirated, I was given all of the >>materials in the huge box),and have the current shell from CodeWarrior. >> I am doing all of my own work on CodeWarrior and I want to devote some >>energy to learning MPW. What priority should I give this, though. >>Exactly what can I do with MPW which I cannot do with CodeWarrior or >>SC++? > > The MPW compilers are so out-of-date that unless you have old >software developed under MPW you need to maintain, don't bother. > > MPW is basically a UNIX-like command line oriented environment, >under which you can run various UNIX-like tools. It's useful if you >need to build UNIX-like tools to process data as part of your >program-building process. MPW dates from when the Mac could only run >one program at a time, and it has its own hack for running "MPW tools" >under its own shell. Although I agree a little with John Nagle's intent, I strongly disagree with his message. Although I use Think and CodeWarrior more than MPW, MPW is still my preferred development environment when working on large projects. The best thing about TPM and CodeWarrior is that they remove the need for make files. On small and medium sized projects, and even large projects where only a single application is to be built, the ability to let the environment deal with dependencies is a real blessing. The worst thing about TPM and CodeWarrior is that remove the ability to use custom make files. On large projects where many loosely related components must be built, the project-based environments are a pain. Maybe someday these enviroments will properly support subprojects or makefiles, but until then, MPW is still superior for this kind of development. As to the MPW compilers being out of date, I suppose this is true if by "MPW compilers" you mean Apple's C, Pascal, and CFront. However, both Symantec and Metrowerks have provided their compilers as MPW tools, and the hybrid MrC available on ETO 15 looks like it may be a real winner (I've only been using it for a couple days, so it's too soon for me to say). Jim Lloyd afcjlloyd@aol.com +++++++++++++++++++++++++++ >From hanrek@cts.com (Mark Hanrek) Date: Sat, 13 Aug 1994 15:10:32 -0800 Organization: The Information Workshop In article <32ipft$18t@charm.magnus.acs.ohio-state.edu>, tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) wrote: > I was given a copy of MPW 3.3 (not pirated, I was given all of the > materials in the huge box),and have the current shell from CodeWarrior. > I am doing all of my own work on CodeWarrior and I want to devote some > energy to learning MPW. What priority should I give this, though. > Exactly what can I do with MPW which I cannot do with CodeWarrior or > SC++? Tim, For one thing, you will have the privilege of compiling and easily playing with example source code from Apple, which is quite often only available in MPW format. Apple is getting better at this, or perhaps it is because of the individuals at Apple who realize that... "If you want programmers out there to move quickly, don't make them jump through the hoop of having to convert MPW source code to their environment." ... and have graciously provided source code ready-to-compile for all the big-three environments. I am in the same situation as you are -- minus MPW. Personally, I am really pissed, because I have Symantec C++, and the PowerPC SDK, and I also have CodeWarrior 3.5, and that adds up to a good chunk of change and a major investment of time. For a while there, MPW was abandoned. But now, I have been unable to participate as an OpenDoc early adopter, or to even take advantage of the recent develop article on OSA -- which is critical to my work -- just because I can't afford to purchase MPW, who's price just went up to $450 the other day. It makes my head spin. I want to smash something. I have always felt that all would-be Mac developers should be alerted that it is not realistic to undertake developing software for the Macintosh without having a minimum of $10,000 to spend on the minimum things you need, and at least one year to write the simplest of programs (due to the incredible wastes of time). I wouldn't have then gone through all this anguish, and embarrassing myself in front of so many people ( you know... investors, friends, parents, c.s.m.p. ). I can't blame anyone except myself. I know that. Even so, the world can be a screwed up place to write Mac software in. So much needed talent -- wasted. Mark Hanrek The Information Workshop - --------------------------------------------------------- P.S. Tim: Keep it. You'll need it. +++++++++++++++++++++++++++ >From hanrek@cts.com (Mark Hanrek) Date: Sat, 13 Aug 1994 16:03:09 -0800 Organization: The Information Workshop In article , hanrek@cts.com (Mark Hanrek) wrote: > ...can't afford to purchase MPW, who's price just went up to $450 oops. After I went to check my facts, I realized that the $350 option still remains. But I can save money by spending a hundred dollars more! :) - --------- A humorous aside... The rich get extra "quantity discounts". The poor get extra "late fees". Crazy man, crazy. :) Mark Hanrek The Information Workshop +++++++++++++++++++++++++++ >From spencerl@crl.com (Spencer Low) Date: Sat, 13 Aug 1994 20:15:26 -0800 Organization: LowTek Creations In article , mclow@san_marcos.csusm.edu (Marshall Clow) wrote: > Try this in CodeWarrior (or Think, for that matter). Build an > application containing 4 LDEFs, 2 MDEFs, 3 WDEFs, as well as 12 plug in > tools, putting the 'CODE' resources and the xDEF resources in a file of... [more incredibly complex make stuff deleted :-] Isn't this possible to do with ToolServer and some of the MPW tools? Or does it get even more complex then? (The worse I've had to do is to get AppleScript to talk to ToolServer to Rez some files (with a special MPW/ToolServer script), open up my CW project, link and make it, etc.) Thanks, Spencer ________________________________________________________________________ Spencer "MaxRAM" Low ------ LowTek Creations ----- spencerl@crl.com +++++++++++++++++++++++++++ >From joseph@joebloe.maple-shade.nj.us (Joseph Nathan Hall) Date: Sat, 13 Aug 94 22:20:46 MST Organization: 5 Sigma Software In article (comp.sys.mac.programmer), nagle@netcom.com (John Nagle) writes: ) tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) writes: ) >I was given a copy of MPW 3.3 (not pirated, I was given all of the ) >materials in the huge box),and have the current shell from CodeWarrior. ) > I am doing all of my own work on CodeWarrior and I want to devote some ) >energy to learning MPW. What priority should I give this, though. ) >Exactly what can I do with MPW which I cannot do with CodeWarrior or ) >SC++? ) ) The MPW compilers are so out-of-date that unless you have old ) software developed under MPW you need to maintain, don't bother. ) ) MPW is basically a UNIX-like command line oriented environment, ) under which you can run various UNIX-like tools. It's useful if you ) need to build UNIX-like tools to process data as part of your ) program-building process. MPW dates from when the Mac could only run ) one program at a time, and it has its own hack for running "MPW tools" ) under its own shell. Yeah, it's a bummer when a tool dies, since it takes the shell with it. Oh, well. But anyway, yes, the compilers are slow and have some inappropriately glib error messages that become less funny at 4 in the morning. However, there is no equivalent to MPW make in either TPM or CW. Applescripts are a somewhat awkward alternative, I guess, but for those of us who have special needs (yacc-generated sources, or perhaps some inputs generated by a perl script), MPW is basically the only way to automate the building of complex projects. I think that you will find many commercial developers using MPW to build auxiliary stuff even if they don't use it for compiles in general. Also, MPW gives you input redirection and piping for tools, which is handy and not available otherwise. The word from Apple, which I will take under advisement, is that the compilers are scheduled for a rev for speed later this year. =============== O Fortuna, velut Luna, statu variabilis =============== uunet!joebloe!joseph (602) 732-2549 day joseph%joebloe@uunet.uu.net 1400 N Alma School #163 Chandler, AZ 85224 Copyright 1994 by Joseph N. Hall. Commercial use prohibited. "The division-WINNING Phillies!" -- Section 236, Row 08, Seat 03 (well, those were the days) +++++++++++++++++++++++++++ >From wysocki@netcom.com (Chris Wysocki) Date: Sun, 14 Aug 1994 07:41:37 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) In article , Mark Hanrek wrote: >I have always felt that all would-be Mac developers should be alerted that >it is not realistic to undertake developing software for the Macintosh >without having a minimum of $10,000 to spend on the minimum things you >need, and at least one year to write the simplest of programs (due to the >incredible wastes of time). Mark, would you care to enlighten all of us as to exactly how you arrived at this $10,000 figure? I personally have been programming the Macintosh since 1985, and over the course of these nine years I have not spent a combined $10k on all the development tools, books, documentation and other resources that I have purchased, and I own a fairly complete library of Macintosh development tools. Today anyone can go out and buy Code Warrior Bronze for $99, THINK Reference for $50, the new Inside Macintosh CD for $99, a subscription to develop for $30, and a few good tutorial books for $200, and they'll have an excellent set of tools for learning how to program the Macintosh, all for less than $500. One certainly could easily spend far more than this, but saying that $10k is needed to start programming the Macintosh is akin to saying that one must purchase a $90,000 BMW 850iL in order to learn how to drive a car. Chris. +++++++++++++++++++++++++++ >From sw@network-analysis-ltd.co.uk (Sak Wathanasin) Date: Sun, 14 Aug 94 11:45:04 BST Organization: Network Analysis Ltd In article (comp.sys.mac.programmer), mclow@san_marcos.csusm.edu (Marshall Clow) writes: > Try this in CodeWarrior (or Think, for that matter). Build an > application containing 4 LDEFs, 2 MDEFs, 3 WDEFs, as well as 12 plug in > tools, putting the 'CODE' resources and the xDEF resources in a file of > type 'APPL', while each of the tools goes in a seperate file. Don't forget > to put the build date (and time) into the 'vers' resource so that testers > can tell exactily what they have. After you have built the application, > compress the resources in the application. > > Oh yes, do this by choosing a single menu option. Never mind that - just building a fat PPC/68K application with CW is a pain in the nether regions. With CW you have to maintain 2 separate projects, one for 68K, one for PPC. With MPW, I have 1 makefile to look after. Another thing that gets me with the CW/Think approach is that you must include all of the srcs files for TCL, MacApp, PowerPlant, whatever into your project if you want symbolic debugging of the libs. That means a copy of the lib (with symbols) for every project that uses the class lib. OK, so 1 GB disks are ten a penny these days. But when I get a new release of TCL, MacApp, or whatever, it means recompiling every TC/CW project that uses these libs. So if you have 10 projects that use, say, MacApp, that means recompiling MacApp 10 times. With MPW, I recompile the class lib once, build a library, then relink; at most I only have to recompile my srcs (because of header changes). Much more civilized. Luckily, from CW 3.5 on, I have the best of both worlds. Sak Wathanasin Network Analysis Limited 178 Wainbody Ave South, Coventry CV3 6BX, UK Internet: sw@network-analysis-ltd.co.uk uucp: ...!uknet!nan!sw AppleLink: NAN.LTD Phone: (+44) 203 419996 Mobile:(+44) 850 587411 Fax: (+44) 203 690690 +++++++++++++++++++++++++++ >From partingt@fwi.uva.nl (Vincent Partington) Date: 14 Aug 1994 15:20:23 GMT Organization: FWI, University of Amsterdam spencerl@crl.com (Spencer Low) writes: >Isn't this possible to do with ToolServer and some of the MPW tools? Or >does it get even more complex then? I've written a small MPW Tool that can send a "Make Project" event to the CodeWarrior environment. I use a makefile for stuff that needs to be built by MPW Tools (Rez, Flex, Bison) and a CW project for the C code. I type the following in the ToolServer window to have everything updated automatically: Make >__commands __commands delete __commands MPWMake O yeah, the tool doesn't need AppleScript to do this. Funnily enough I got CW4 yesterday and it contains some sample code to send AppleEvents to the CW environment. Anyway the source can be gotten by fingering partingt@gene.fwi.uva.nl. Vincent. -- appel peer banaan baksteen ||| The Fingerware Project: schelp zon zand rolstoel ||| Put your code snippets in your .plan! groen wit geel flatgebouw ||| If you want to know more boer postbode bouwvakker roos ||| finger partingt@gene.fwi.uva.nl +++++++++++++++++++++++++++ >From nick+@pitt.edu ( nick.c ) Date: Sun, 14 Aug 94 18:19:05 GMT Organization: The Pitt, Chemistry In Article , hanrek@cts.com (Mark Hanrek) wrote: >Personally, I am really pissed, because I have Symantec C++, and the >PowerPC SDK, and I also have CodeWarrior 3.5, and that adds up to a good >chunk of change and a major investment of time. > >For a while there, MPW was abandoned. > >But now, I have been unable to participate as an OpenDoc early adopter, or >to even take advantage of the recent develop article on OSA -- which is >critical to my work -- just because I can't afford to purchase MPW, who's >price just went up to $450 the other day. Not sure if this helps (you might be talking about the Apple compilers), but there is a fully configured version of the MPW shell for use with CW on CW4 - I think it was there for 3.5 too. Interet: nick@pitt.edu _/ _/ _/ _/_/_/ _/ _/ eWorld: nick _/_/ _/ _/ _/ _/ _/_/_/ CIS: 71232,766 _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/_/_/ _/ _/ "Science is nothing but perception" - Plato +++++++++++++++++++++++++++ >From Ken Prehoda Date: 14 Aug 1994 21:29:19 GMT Organization: Univ of Wisc-Madison In article nick.c, nick+@pitt.edu writes: > Not sure if this helps (you might be talking about the Apple > compilers), but there is a fully configured version of the MPW > shell for use with CW on CW4 - I think it was there for 3.5 too. I think Mark was talking about the MPW compilers, since he said he has codewarrior AND the PPC SDK, both of which contain the MPW 3.3 shell. Currently, MPW C++ is pretty much required to do build opendoc part editors. I, and I'm sure many others, are waiting for the opendoc beta (that uses SOM instead of ASLM) so we can use MW C++ (or Symantec). However, there is a folder on the OpenDoc A6 CD for building opendoc with codewarrior which can get you a long way until the beta arrives. -Ken Prehoda kenp@nmrfam.wisc.edu +++++++++++++++++++++++++++ >From Gavriel State Date: 14 Aug 1994 18:36:49 GMT Organization: Metrowerks Inc. In article Sak Wathanasin, sw@network-analysis-ltd.co.uk writes: > Another thing that gets me with the CW/Think approach is that you must > include all of the srcs files for TCL, MacApp, PowerPlant, whatever > into your project if you want symbolic debugging of the libs. That In CW4 you can debug PPC shared libraries in source. Just build MacApp, Powerplant, or whatever as a shared library, include it in your project, and go. -- Gavriel State | 4A Systems Design Engineering/Economics | Univ. of Waterloo - --------------------------------------------------------------------------- Email: grstate@metrowerks.ca | "Sentence fragment. Another. Good device. - ------------------------------| Will be used more later." - This is the Metrowerks CodeWarrior Pascal | title of the story, which is also found Co-Op Engineering Student Person| several times in the story itself. +++++++++++++++++++++++++++ >From chrism@col.hp.com (Chris Magnuson) Date: 15 Aug 1994 04:07:20 GMT Organization: HP Colorado Springs Division Chris Wysocki (wysocki@netcom.com) wrote: : In article , : Mark Hanrek wrote: : Mark, would you care to enlighten all of us as to exactly how you : arrived at this $10,000 figure? I personally have been programming : the Macintosh since 1985, and over the course of these nine years I : have not spent a combined $10k on all the development tools, books, : documentation and other resources that I have purchased, and I own a : fairly complete library of Macintosh development tools. Today anyone : can go out and buy Code Warrior Bronze for $99, THINK Reference for : $50, the new Inside Macintosh CD for $99, a subscription to develop : for $30, and a few good tutorial books for $200, and they'll have an : excellent set of tools for learning how to program the Macintosh, all : for less than $500. One certainly could easily spend far more than : this, but saying that $10k is needed to start programming the : Macintosh is akin to saying that one must purchase a $90,000 BMW 850iL : in order to learn how to drive a car. Well, you forgot to buy a Mac for one thing. :) Chris Magnuson chrism@col.hp.com +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Mon, 15 Aug 1994 14:30:46 +0800 Organization: Department of Computer Science, The University of Western Australia In article <01050166.75ttt1@joebloe.maple-shade.nj.us>, joseph@joebloe.maple-shade.nj.us wrote: >Yeah, it's a bummer when a tool dies, since it takes the shell with it. >Oh, well. The tool has to die pretty badly for "g sysrecover" to fail. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Mon, 15 Aug 1994 14:33:32 +0800 Organization: Department of Computer Science, The University of Western Australia In article , spencerl@crl.com (Spencer Low) wrote: >Isn't this possible to do with ToolServer and some of the MPW tools? Or >does it get even more complex then? I've built things in MPW that would make your hair curl. Specifically trying to hack MW or TPM to build something as complicated as LabMaster would have been defeating the point of these environments. Use the right tools for the job. If you're building an application then using MW or TPM. If you're building something hideous then MPW is your friend. Besides [warning, holy way bait!] MPW's editor is *sooo* much better than any other editor on the Mac. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From tree@bedford.symantec.com (Tom Emerson) Date: 15 Aug 1994 11:41:55 GMT Organization: Symantec Development Tools Group In article , quinn@cs.uwa.edu.au (Quinn "The Eskimo!") wrote: > Besides [warning, holy way bait!] MPW's editor is *sooo* much better than > any other editor on the Mac. So, what features of the MPW editor do you prefer over those provided by any other editor? -tre -- Tom Emerson Software Engineer Development Tools Group Symantec Corporation tree@bedford.symantec.com "I dreamed I had to take a test, in a Dairy Queen, on another planet." +++++++++++++++++++++++++++ >From neal@farallon.com (Neal Trautman) Date: 15 Aug 1994 14:04:01 GMT Organization: Farallon Computing, Inc. In article , mclow@san_marcos.csusm.edu (Marshall Clow) writes: > > Try this in CodeWarrior (or Think, for that matter). Build an > application containing 4 LDEFs, 2 MDEFs, 3 WDEFs, as well as 12 plug in > tools, putting the 'CODE' resources and the xDEF resources in a file of > type 'APPL', while each of the tools goes in a seperate file. Don't forget > to put the build date (and time) into the 'vers' resource so that testers > can tell exactily what they have. After you have built the application, > compress the resources in the application. > > Oh yes, do this by choosing a single menu option. > I agree. Timbuktu has two applications, a Desk Accessory, an Extension with an INIT, a DRVR and stand-alone code resources, an AOCE catalog template, an Installer script, and two help files. Most all of these files are also compressed. AND, I can build all this in 4 languages (English, French, German, and Kanji) by selecting one menu command. Now, on the other hand, for the Metroweks Profiler viewer application, I used CodeWarrior and PowerPlant there was only one piece to build. ========================================================================== Neal Trautman I climbed to the top of the ladder Timbuktu Lead Software Engineer of success only to realize it was Metrowerks CodeWarrior Profiler co-author leaning against the wrong wall. ========================================================================== +++++++++++++++++++++++++++ >From hanrek@cts.com (Mark Hanrek) Date: Mon, 15 Aug 1994 09:36:04 -0800 Organization: The Information Workshop In article <32m2bf$ilh@news.doit.wisc.edu>, Ken Prehoda wrote: > In article > nick.c, nick+@pitt.edu writes: > > Not sure if this helps (you might be talking about the Apple > > compilers), but there is a fully configured version of the MPW > > shell for use with CW on CW4 - I think it was there for 3.5 too. > > I think Mark was talking about the MPW compilers, since he said he > has codewarrior AND the PPC SDK, both of which contain the MPW 3.3 > shell. > > Currently, MPW C++ is pretty much required to do build opendoc part > editors. I, and I'm sure many others, are waiting for the opendoc > beta (that uses SOM instead of ASLM) so we can use MW C++ (or > Symantec). > > However, there is a folder on the OpenDoc A6 CD for building opendoc > with codewarrior which can get you a long way until the beta arrives. > > -Ken Prehoda > kenp@nmrfam.wisc.edu Thanks, Ken, for clarifying that for me. And thanks for the reference to that folder! I quadruple-checked for anything to do with CodeWarrior on the A6 CD, and found a read-me that referred to a folder that does not exist, at least on the WWDC version of OpenDoc A6. So, is it the case that this folder does exist on another version of the OpenDoc A6 release? I looked on eWorld, but those files come in clumps. :) Still trying... Mark Hanrek +++++++++++++++++++++++++++ >From mclow@san_marcos.csusm.edu (Marshall Clow) Date: Mon, 15 Aug 1994 10:14:05 -0800 Organization: Aladdin Systems In article , tree@bedford.symantec.com (Tom Emerson) wrote: > In article , > quinn@cs.uwa.edu.au (Quinn "The Eskimo!") wrote: > > > Besides [warning, holy way bait!] MPW's editor is *sooo* much better than > > any other editor on the Mac. > > So, what features of the MPW editor do you prefer over those provided by > any other editor? > Tom -- My _favorite_ MPW editor feature is the "double click on open paren/brace/bracket/slash/quote and select everything up to the matching symbol. (Also works with 2x-clicking on the closing symbol. If you hold the mouse button down after the second click, you can move the cursor around and see the selection change to show differing "matches" MUCH, much better than the "Balance" command in Think. -- Marshall [ Who's trying to turn an potential flame war into a rational discussion. ] -- Marshall Clow Aladdin Systems mclow@san_marcos.csusm.edu +++++++++++++++++++++++++++ >From kenp@tuli (Kenneth Prehoda) Date: 15 Aug 1994 18:31:25 GMT Organization: Division of Information Technology Mark Hanrek (hanrek@cts.com) wrote: : Thanks, Ken, for clarifying that for me. And thanks for the reference to : that folder! : I quadruple-checked for anything to do with CodeWarrior on the A6 CD, and : found a read-me that referred to a folder that does not exist, at least on : the WWDC version of OpenDoc A6. : So, is it the case that this folder does exist on another version of the : OpenDoc A6 release? I looked on eWorld, but those files come in clumps. : :) : Still trying... : Mark Hanrek The "Building Opendoc with Codwarrior" Folder is only on the OpenDoc A6 with source disk, I believe (Jens, can you help me out here?). This is because to use codewarrior you currently have to build your part editor inside of opendoc and hence requires building opendoc in CW. -Ken Prehoda kenp@nmrfam.wisc.edu +++++++++++++++++++++++++++ >From lambert_l@measurex.com (Leon Lambert) Date: Mon, 15 Aug 1994 17:58:53 GMT Organization: measurex In article <32ipft$18t@charm.magnus.acs.ohio-state.edu> tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) writes: > Hi: > > I was given a copy of MPW 3.3 (not pirated, I was given all of the > materials in the huge box),and have the current shell from CodeWarrior. > I am doing all of my own work on CodeWarrior and I want to devote some > energy to learning MPW. What priority should I give this, though. > Exactly what can I do with MPW which I cannot do with CodeWarrior or > SC++? > > Thanks; > > Tim I find the scripting language in MPW to be great. It takes quite an investment to learn but really pays off if you have a lot of tedious repetative editing to do. I do a lot of porting of code to other platforms and find it very useful. The comparefiles script is worth its weight in Gold. I have not found a better file comparison utility on any platform out there. Since switching to CW I find myself spending about 85% of my time there, but still need to switch to MPW to do some fancy stuff. MPW allows you to hook your own functions to keys to do fancy editing. For instance I can double click a function name and do a cmd 0 and the proper #include is inserted at the top of my C file. I wish CW would put some sort of scripting/macro ability into their editor. lambert_l@measurex.com (Leon Lambert) lambertlb@aol.com +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Tue, 16 Aug 1994 11:10:30 +0800 Organization: Department of Computer Science, The University of Western Australia In article , tree@bedford.symantec.com (Tom Emerson) wrote: >So, what features of the MPW editor do you prefer over those provided by >any other editor? [On no, I'm gonna get in twubble again... (: ] #1 most important feature... it edits arbitrary sized files. I get *really* annoyed when I edit a file and programs go "not enough memory to edit this document". But I recognise that this feature is a) hard and b) unnecessary for programming. It's just that MPW has it and no one else does. I also like the way MPW's command, option & shift arrow keys all seem to work they way I expect. And, if worst comes to worst, I can use SetKey to fix them (: Double-clicking on brackets to match them! [Although that's supposed to have arrived in CW4.] I *really* like MPW's search and replace system, especially the way that shift works to search backwards. I just can't get the the hang of any Think editor's search and replace. CW is good but the non-modal dialog just confuses me (: I also like the power of MPW's regular expressions. [And unlike most of my unix-raised bretheren, I understand them better than unix regexs.] I also make quite a bit of use adding scripts into menus. I suspect that Alpha provides most of the flexibility that I need in an editor. But unfortunately Alpha is both ugly (IMHO of course) and Dvorak keyboard unfriendly. [Yes I know you can tweak it but that's *no* excuse.] I want MPW's editor ripped out of MPW so that I can use it with CW and TPM without blowing away multiple megabytes!!! We have ToolServer and SourceServer, why not EditorServer (: Share and Enjoy. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia Who's just come from one flame war in c.s.m.hardware and doesn't really want to start another here ): +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Tue, 16 Aug 1994 16:24:50 +1200 (NZST) Organization: (none) mclow@san_marcos.csusm.edu (Marshall Clow) writes: > My _favorite_ MPW editor feature is the "double click on open > paren/brace/bracket/slash/quote and select everything up to the matching > symbol. (Also works with 2x-clicking on the closing symbol. If you hold > the mouse button down after the second click, you can move the cursor > around and see the selection change to show differing "matches" > > MUCH, much better than the "Balance" command in Think. Holy cow! I've been using MPW since 1987, and have used the "double-click on a bracket" feature forever, but I've never discovered the "hold the button down" feature. Cool! -- Bruce +++++++++++++++++++++++++++ >From stevec@jolt.mpx.com.au (Stephen F Coy) Date: 16 Aug 1994 10:23:29 GMT Organization: Microplex Pty Ltd Quinn "The Eskimo! (quinn@cs.uwa.edu.au) wrote: : In article , tree@bedford.symantec.com : (Tom Emerson) wrote: : >So, what features of the MPW editor do you prefer over those provided by : >any other editor? : [On no, I'm gonna get in twubble again... (: ] : #1 most important feature... it edits arbitrary sized files. I get : *really* annoyed when I edit a file and programs go "not enough memory to : edit this document". But I recognise that this feature is a) hard and b) : unnecessary for programming. It's just that MPW has it and no one else : does. : I also like the way MPW's command, option & shift arrow keys all seem to : work they way I expect. And, if worst comes to worst, I can use SetKey to : fix them (: : Double-clicking on brackets to match them! [Although that's supposed to : have arrived in CW4.] : I *really* like MPW's search and replace system, especially the way that : shift works to search backwards. I just can't get the the hang of any : Think editor's search and replace. CW is good but the non-modal dialog : just confuses me (: I also like the power of MPW's regular expressions. : [And unlike most of my unix-raised bretheren, I understand them better : than unix regexs.] : I also make quite a bit of use adding scripts into menus. : I suspect that Alpha provides most of the flexibility that I need in an : editor. But unfortunately Alpha is both ugly (IMHO of course) and Dvorak : keyboard unfriendly. [Yes I know you can tweak it but that's *no* : excuse.] : I want MPW's editor ripped out of MPW so that I can use it with CW and TPM : without blowing away multiple megabytes!!! We have ToolServer and : SourceServer, why not EditorServer (: : Share and Enjoy. : -- : Quinn "The Eskimo!" "Support HAVOC!" : Department of Computer Science, The University of Western Australia : Who's just come from one flame war in c.s.m.hardware and doesn't : really want to start another here ): I could not have said this better myself. In fact, one of the reasons I like Object Master so much is that it emulates (mostly anyway) the keyboard and search/replace behaviour of MPW. Everytime I fire up the Symantec C++ IDE, the editor drives me nuts in short order. - ------ Steve Coy Resolve Software (WA) Pty Ltd Sydney Australia +++++++++++++++++++++++++++ >From Willie Abrams Date: 16 Aug 1994 13:21:15 GMT Organization: OU Health Sciences Center In article Tom Emerson, tree@bedford.symantec.com writes: >So, what features of the MPW editor do you prefer over those provided by >any other editor? Tom, hate to make a pointed remark...MPW can open up files to just look at and edit individually (unlike TPM, where I can't unless I have a project open.) It is a small, but modal inconvenience that keeps me from even going to TPM look at hardly any source files - I find myself dragging and dropping on to BBEdit Lite. Willie Abrams willie-abrams@uokhsc.edu Telemedicine Software Guy OU Health Sciences Center It's a classic Pincer's Movement. It can't fail against a ten-year-old! +++++++++++++++++++++++++++ >From Willie Abrams Date: 16 Aug 1994 13:22:35 GMT Organization: OU Health Sciences Center In article Quinn, quinn@cs.uwa.edu.au writes: >unnecessary for programming. It's just that MPW has it and no one else >does. BBEdit hardly ever has this problem... Willie Abrams willie-abrams@uokhsc.edu Telemedicine Software Guy OU Health Sciences Center It's a classic Pincer's Movement. It can't fail against a ten-year-old! +++++++++++++++++++++++++++ >From tree@bedford.symantec.com (Tom Emerson) Date: Tue, 16 Aug 1994 15:30:56 -0500 Organization: Symantec Development Tools Group In article <32qegb$36f@romulus.ucs.uoknor.edu>, Willie Abrams wrote: > In article Tom Emerson, > tree@bedford.symantec.com writes: > >So, what features of the MPW editor do you prefer over those provided by > >any other editor? > > Tom, hate to make a pointed remark...MPW can open up files > to just look at and edit individually (unlike TPM, where I can't > unless I have a project open.) Sure, I understand. But that is an environment issue, not an editor issue. Just picking nits ;-) This is something that is, contrary to many peoples belief, something that is non-trivial to change in the design of the TPM, not that it hasn't been discussed. Who knows what the future may hold, though. -tre -- Tom Emerson Software Engineer Development Tools Group Symantec Corporation tree@bedford.symantec.com "I dreamed I had to take a test, in a Dairy Queen, on another planet." +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Wed, 17 Aug 1994 10:12:19 +0800 Organization: Department of Computer Science, The University of Western Australia In article <32qeir$36f@romulus.ucs.uoknor.edu>, Willie Abrams wrote: >BBEdit hardly ever has this problem... Yeah, I know, BBEdit uses temporary memory. But it still bites me. I only have 20MB (: and when I'm programming and documenting XCMDs I need MPW, HyperCard and my documentation tools open all at once which means that I regularly run out of temporary memory. Then I got to poke around in a PostScript file at the same time... Just one of those inconveniences that I can do without. And given the other advantages of MPW's editor. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia And don't even mention LabView. +++++++++++++++++++++++++++ >From Manuel Veloso Date: Wed, 17 Aug 1994 07:35:44 GMT Organization: Ibex Productions In article <32qeir$36f@romulus.ucs.uoknor.edu> Willie Abrams, willie-abrams@uokhsc.edu writes: >Quinn, quinn@cs.uwa.edu.au writes: >>unnecessary for programming. It's just that MPW has it and no one else >>does. > >BBEdit hardly ever has this problem... Actually, I was dealing with Postscript files a while back, and MPW is the only editor (besides MS Word) that would open them - no matter how big (ie: a couple of megs). Of course, I could have changed BBEdit's partition size, but I use it as my 'normal' editor and wouldn't want to keep changing it. BBEdit's major strength, IMO, is its multi-file search browser. Too bad you can't edit in it, though. +++++++++++++++++++++++++++ >From Manuel Veloso Date: Wed, 17 Aug 1994 07:43:10 GMT Organization: Ibex Productions In article <32ipft$18t@charm.magnus.acs.ohio-state.edu> tfullert, tfullert@bottom.magnus.acs.ohio-state.edu writes: >Exactly what can I do with MPW which I cannot do with CodeWarrior or >SC++? Well, there are three main things: (1) you can do a multitude of incredibly complicated things with MPW's scripting language/makefiles. In essence, you have complete control over the shell, and can issue commands, etc. (2) you can have completely integrated projector support (how many times have you moved a ProjectorDB file and gotten the "can't check in file blah because the project was not found" using the TPM/SS combo? This never happens w/Projector. Plus, check in active/check out active work, and the checkin window doesn't take forever in MPW.) (3) You can be macho <-- arguably the most important thing you can't do if you use CW/SymC +++++++++++++++++++++++++++ >From Manuel Veloso Date: Wed, 17 Aug 1994 07:46:44 GMT Organization: Ibex Productions In article Quinn, quinn@cs.uwa.edu.au writes: >>Yeah, it's a bummer when a tool dies, since it takes the shell with it. >>Oh, well. > >The tool has to die pretty badly for "g sysrecover" to fail. You can also use "g stoptool". I'm not sure which one's recommended, though. +++++++++++++++++++++++++++ >From bix.com!dvanhoozer Date: 17 Aug 1994 08:53:26 GMT Organization: Mad Bomber Software In article <2859899090@hoult.actrix.gen.nz> Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes: >mclow@san_marcos.csusm.edu (Marshall Clow) writes: >> the mouse button down after the second click, you can move the cursor >> around and see the selection change to show differing "matches" >> >> MUCH, much better than the "Balance" command in Think. > >Holy cow! > >I've been using MPW since 1987, and have used the "double-click on a bracket" >feature forever, but I've never discovered the "hold the button down" >feature. My face is just as red BH, like you that one has some how got past me. I wonder what else I don't know.... :-) Dewayne o-* +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Thu, 18 Aug 1994 03:17:32 +1200 (NZST) Organization: (none) Manuel Veloso writes: > Actually, I was dealing with Postscript files a while back, and MPW > is the only editor (besides MS Word) that would open them - no matter > how big (ie: a couple of megs). Of course, I could have changed > BBEdit's partition size, but I use it as my 'normal' editor > and wouldn't want to keep changing it. BBEdit lets you open any size file without changing the partition size -- it uses System memory. In my moonlighting job as a consultant to a DTP company, I often use BBEdit to edit PostScript files of up to 80 or 100 MB in size. It handles it without a complaint, with very good performance (once the file is all read into memory), in the standard BBEdit memory partition. MPW and Word simply can't cope with files this size with any sort of performance at all. You done good, Rich. This *is* on a Q950 with 136 MB of RAM, mind you. -- Bruce +++++++++++++++++++++++++++ >From mem@pha.jhu.edu (Mel Martinez) Date: Wed, 17 Aug 1994 15:57:25 -0500 Organization: The Johns Hopkins Univ. - Dept. of Physics In article <2860024652@hoult.actrix.gen.nz>, Bruce@hoult.actrix.gen.nz (Bruce Hoult) wrote: > Manuel Veloso writes: > > Actually, I was dealing with Postscript files a while back, and MPW > > is the only editor (besides MS Word) that would open them - no matter > > how big (ie: a couple of megs). Of course, I could have changed > > BBEdit's partition size, but I use it as my 'normal' editor > > and wouldn't want to keep changing it. > > BBEdit lets you open any size file without changing the partition > size -- it uses System memory. > > In my moonlighting job as a consultant to a DTP company, I often use > BBEdit to edit PostScript files of up to 80 or 100 MB in size. It > handles it without a complaint, with very good performance (once the > file is all read into memory), in the standard BBEdit memory partition. > > MPW and Word simply can't cope with files this size with any sort of > performance at all. You done good, Rich. > > This *is* on a Q950 with 136 MB of RAM, mind you. > > -- Bruce Err.. thank you. You may sit down now, please. :-) Now back to dealing with problems for 'the rest of us' (with single & double digit memory)... Sheesh! Mel +++++++++++++++++++++++++++ >From siegel@netcom.com (Rich Siegel) Date: Wed, 17 Aug 1994 19:36:24 GMT Organization: Bare Bones Software In article <2860024652@hoult.actrix.gen.nz> Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes: >In my moonlighting job as a consultant to a DTP company, I often use >BBEdit to edit PostScript files of up to 80 or 100 MB in size. It >handles it without a complaint, with very good performance (once the >file is all read into memory), in the standard BBEdit memory partition. > >MPW and Word simply can't cope with files this size with any sort of >performance at all. You done good, Rich. I appreciate the compliment, but in good conscience can't take -all- the credit. The text engine was original written by Jon Hueras, with modifications by me, and Jon also did the rewrite for PowerPC. (That won't stop me from taking -some- of the credit, though. :-]) R. -- Rich Siegel % siegel@netcom.com % President & CEO, Bare Bones Software Inc. --> For information about BBEdit, finger bbedit@world.std.com <-- +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 17 Aug 1994 13:43:17 -0700 Organization: SRI International, Menlo Park, CA In article tree@bedford.symantec.com (Tom Emerson) writes: >Sure, I understand. But that is an environment issue, not an editor issue. >Just picking nits ;-) This is something that is, contrary to many peoples >belief, something that is non-trivial to change in the design of the TPM, >not that it hasn't been discussed. Who knows what the future may hold, >though. We have seen the future (rainbow that is) and you better hurry up and make it so or else you won't have a market left. Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 19 Aug 94 16:05:30 +1200 Organization: University of Waikato, Hamilton, New Zealand In article , tree@bedford.symantec.com (Tom Emerson) writes: > In article , > quinn@cs.uwa.edu.au (Quinn "The Eskimo!") wrote: > >> Besides [warning, holy way bait!] MPW's editor is *sooo* much better than >> any other editor on the Mac. > > So, what features of the MPW editor do you prefer over those provided by > any other editor? Of course, one of the things that gets me waxing so lyrical is that MPW is so much more than just an editor. On more than one occasion now, I've been involved in upgrading our departmental AppleShare server. We've been through 2-3 hard disk upgrades and one change of machine over the past couple of years. Each time, of course, I've had to copy all the files from the old hard disk to the new one, and preserve all their folder protections. I've never bothered getting any proper backup software to do this, since I've made it quite clear to our users that they have to back up their own data, all I'm responsible for is the server configuration itself. The file-copying part was never a big deal: I just drag everything across in the Finder, and leave it copying for a few hours, or overnight, or whatever. For transferring the folder protections (and for backing them up), I use MPW. The MPW Shell has this neat convention in some commands: it uses the same command for both examining a setting and for changing it. The clever thing is, when you ask the command to display the existing setting, it outputs a command which can be used to set the setting to that value. For example, the SetPrivilege tool lets you examine and change folder protections. The command "SetPrivilege -i" displays the current protections in the form of "SetPrivilege" commands. So to dump out all the existing protections on the old volume, I issued the command: SetPrivilege -i -r "OldVolume:" (the -r option says to recursively list subfolders as well). Then I did a global search and replace on the output, replacing all occurrences of OldVolume with NewVolume, and finally I selected the result and pressed Enter to execute it. Voila! All the protections transferred with a minimum of work. As I keep saying, if you can't do it with MPW, it isn't worth doing. :-) Lawrence D'Oliveiro fone: +64-7-856-2889 Info & Tech Services Division fax: +64-7-838-4066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 +++++++++++++++++++++++++++ >From Jens Alfke Date: Fri, 19 Aug 1994 23:32:41 GMT Organization: Apple Computer Kenneth Prehoda, kenp@tuli writes: > The "Building Opendoc with Codwarrior" Folder is only on the > OpenDoc A6 with source disk, I believe (Jens, can you help > me out here?). This is because to use codewarrior you currently > have to build your part editor inside of opendoc and hence > requires building opendoc in CW. You're 100% right. I guess it might have been possible to precompile all the OD code into a library that you'd link into an app along with your part implementation, but I didn't have time to do that. Of course the beta release will work fine with CodeWarrior (in fact that's what we do our primary development with now, with brief excursions to MPW to run the SOM compiler.) --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Sun, 21 Aug 1994 14:58:28 +0800 Organization: Department of Computer Science, The University of Western Australia In article , tree@bedford.symantec.com (Tom Emerson) wrote: >This is something that is, contrary to many peoples >belief, something that is non-trivial to change in the design of the TPM [...] Working as designed ): -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia >From eric.larson@f620.n2605.z1.fidonet.org (eric larson) Subject: What is the point of MPW? Date: 18 Aug 94 19:11:49 - Organization: FidoNet: Shockwave Rider, USR V.Everything +1(908)294-0659 >>MPW and Word simply can't cope with files this size with any sort of >>performance at all. You done good, Rich. > I appreciate the compliment, but in good conscience can't take -all- > the credit. The text engine was original written by Jon Hueras, with > modifications by me, and Jon also did the rewrite for PowerPC. I've had similar experiences with BBEdit. When making literally thousands of changes using search and replace on a 10 MB text file, every other editor I've tried chokes. BBEdit handles the job smoothly, without complaint. +++++++++++++++++++++++++++ >From khatt@shell.portal.com (Judy Ann Kettenhofen) Date: 28 Aug 1994 21:52:51 GMT Organization: Portal Communications Company -- 408/973-9111 (voice) 408/973-8091 (data) eric larson (eric.larson@f620.n2605.z1.fidonet.org) wrote: : >>MPW and Word simply can't cope with files this size with any sort of : >>performance at all. You done good, Rich. : > I appreciate the compliment, but in good conscience can't take -all- : > the credit. The text engine was original written by Jon Hueras, with : > modifications by me, and Jon also did the rewrite for PowerPC. : I've had similar experiences with BBEdit. When making literally thousands of : changes using search and replace on a 10 MB text file, every other editor I've : tried chokes. BBEdit handles the job smoothly, without complaint. Sorry, I didn't see the first part of this message. In general, MPW should have problems with large files in two cases: 1) Where there are a large number of markers 2) Where you make a lot of changes. For the first, you are out of luck, to the best of my knowledge. For the second, you can do some things to help. 1. Save your file frequently after changes. This helps MPW Shell to basically do garbage collection, and requires less of the file to be resident in memory. 2. There is a way to change the size of the editor heap. I don't recall what it is right now. If you know you are going to have large files, you can try enlarging the editor heap. The MPW Shell has code to create subsequent editor heaps if it runs out of space in the first one, but I don't think that code has been exercised much. --Judy --former MPW hack. +++++++++++++++++++++++++++ >From dlopez@sailsun (Dean Lopez) Date: 30 Aug 1994 13:00:34 GMT Organization: NASA Johnson Space Center, Houston, TX, USA eric larson (eric.larson@f620.n2605.z1.fidonet.org) wrote: > I've had similar experiences with BBEdit. When making literally thousands of > changes using search and replace on a 10 MB text file, every other editor I've > tried chokes. BBEdit handles the job smoothly, without complaint. I just started using BBEdit Lite (v2.3? - whatever the latest rev is), and I've noticed whenever I open an existing file, BBEdit promptly puts a single garbage character at the end of my file. It doesn't mark the file as 'dirty' though, so if I close the file, the garbage character doesn't get saved to the file. If I make any edits to the file and THEN save, the garbage character ends up at the end of my file, which promptly causes my compiler to complain. Has anyone had this problem with the commercial BBEdit? -- +--------------------------------------+------------------------------+ | Dean Lopez | | | SAIL DPS Engineer | dlopez@sailsun.jsc.nasa.gov | | Rockwell Space Operations Co. | deanlopez@aol.com | | JSC Shuttle Avionics Integration Lab | dean_lopez@maclair.sccsi.com | +--------------------------------------+------------------------------+ #include /* The opinions expressed are all mine. RSOC doesn't speak for me and I don't speak for RSOC After all, I'm only an engineer - what do I know? */ --------------------------- >From netcom.com!kira!davidjohn (David John Burrowes) Subject: Where have the standards gone? [a high level question] Date: Fri, 19 Aug 1994 03:17:20 GMT Organization: No organization at this time. I was reading the article about System 7.5 in the September 1994 issue of MacUser (p. 79-84), and it raised a gigantic question in my mind. After some thought, I decided to see what opinions others (yourselves) might have. The 'screenshots' on pages 80-81 and 82-83 of the above issue shows several new features of this system software release. In them, I noted five new window styles: - a strange little thing for 'post-it' notes - a green one for the CD player (the title bar is similar to the standard document titlebar, but not the same) - the Find File windows have a funky styled background - the Launcher window gives us a window with, presumably, a standard pink background with square/tile/chicklet(sp?) icons - A window that is reminiscent of the 'palette' titlebar, but with close and zoom boxes. (the TV stuff in another article has yet another window style variation). For buttons, I notice these new styles (in *addition* to standard flat Mac push-buttons) - '3D' buttons in the Launcher window, - two types of CD player-like buttons in the CD player window (also found on the TV control panel in that other article) - plus, two other '3D' styles for the help system (one with icons, and one that looks like 'shallow' buttons at the bottom of the palette-ish windows. (plus, what looks like another '3d'ish style is seen in the TV control panel) Individually, many of these don't look that bad, I suppose (but, that's another issue, really). However, as I recall, one of the advertised strengths of the Macintosh, in past years, was its highly consistent interface. Buttons looked and behaved the same everywhere. Windows with a particular style almost always behaved the same as other windows with the same style. Etc. I find myself concerned, therefore, with all of these new innovations. I do not see a great deal of consistency here. What kind of message is this sending to developers? It seems to me it's something like, 'Sure, go ahead, bypass the toolbox (as I assume some or much of the above stuff is). Make up whatever non-standard user interface features you want so your app looks unusual and snazzy. Users will figure it out eventually.' Sure, I know, some developers have always felt compelled to do things their own way. But, since this is Apple doing non-standard things, many more people will feel justified in going off and doing *their own* things. By itself, I find this to be a depressing prospect. But, with Microsoft coming out with a significantly improved user interface for Windows soon (Chicago), this all strikes me as Apple shooting itself in the foot, bigtime, which I find more depressing still. If you've read this far, I'm curious what your thoughts are, either through personal email or on the newsgroup. Maybe I'm very much in the minority, and folks generally think the 'highly consistent' interface was too constraining? Thanks. david john burrowes davidjohn@kira.net.netcom.com +++++++++++++++++++++++++++ >From wysocki@netcom.com (Chris Wysocki) Date: Fri, 19 Aug 1994 09:51:10 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) In article <1994Aug19.031720.1465@kira.net.netcom.com>, David John Burrowes wrote: >I find myself concerned, therefore, with all of these new innovations. I do >not see a great deal of consistency here. What kind of message is this >sending to developers? It seems to me it's something like, 'Sure, go ahead, >bypass the toolbox (as I assume some or much of the above stuff is). Make up >whatever non-standard user interface features you want so your app looks >unusual and snazzy. Users will figure it out eventually.' >Sure, I know, some developers have always felt compelled to do things their >own way. But, since this is Apple doing non-standard things, many more >people will feel justified in going off and doing *their own* things. By >itself, I find this to be a depressing prospect. But, with Microsoft coming >out with a significantly improved user interface for Windows soon (Chicago), >this all strikes me as Apple shooting itself in the foot, bigtime, which I >find more depressing still. I wholeheartedly concur. Apple has done far too little in recent years to promote UI consistency across applications. Their reluctance to provide standard implementations of UI features such as floating windows, menus with multiple-modifier keyboard shortcuts, and basic controls such as up-down arrows, sliders and progress bars have forced developers to implement these features themselves, with varying and sometimes inconsistent results. At the Worldwide Developers Conference in May some Apple engineers spoke in nebulous terms about future UI enhancements which are coming down the road, but it struck me and others with whom I spoke as too little, too late.... Chris. +++++++++++++++++++++++++++ >From pcastine@prz.tu-berlin.de (Peter Castine) Date: Fri, 19 Aug 1994 11:11:19 GMT Organization: Process Control Center In article <1994Aug19.031720.1465@kira.net.netcom.com>, netcom.com!kira!davidjohn (David John Burrowes) wrote: > I was reading the article about System 7.5 in the September 1994 issue of > MacUser (p. 79-84), and it raised a gigantic question in my mind. After > some thought, I decided to see what opinions others (yourselves) might have. > > The 'screenshots' on pages 80-81 and 82-83 of the above issue shows several > new features of this system software release. In them, I noted five new > window styles: [schnipp...] > If you've read this far, I'm curious what your thoughts are, either through > personal email or on the newsgroup. Maybe I'm very much in the minority, > and folks generally think the 'highly consistent' interface was too > constraining? I think the subject is worthy of general discussion, so I'll post; in any case, our mail server is currently down. It seems to me that standards are going out the window, and that this is a negative development. Conventional buttons and WDEFs may seem a little unadventurous, but in day-to-day work the security of knowing how to recognize a button and where the window title is are a great advantage. I always disliked HyperCard's anything-can-be-a-button attitude, because it leaves you with the challenge of clicking on *everything*, just to see if maybe that little chicklet-shaped object triggers some sort of action. This is fine and dandy for an adventure game, but frustrating when you're trying to get on with your work. As one example, I was looking at the new(ish) AppleCD Audio Player. The only reason I even tried clicking on the little green triangle in the lower left corner was because I knew that the fore-runner software had a track list and I was sure that the newer software _must_ have a track list somewhere. I looked in the menus, to no avail, so I started clicking around and the mouse finally landed on said triangle. Voila! Success at last! But, why the hell should I spend my time clicking around a window to find a substitute for the Zoom box? (Use of the zoom box as a sort of {show|hide}-details-of-a-dialog-window is not officially sanctioned, but has found it's way into a number of utility programs). Sure, if I'd turned on Balloon Help, I might have found this button sooner, but an experienced Mac user shouldn't need Balloon Help to find an _Ersatz_ zoom box. That said, let me add that it *is* important for UIs to develop; I'm not going to advocate cast-in-platinum Human Interface Guidelines. The _Macintosh Humand Interface Guidelines_ discuss the subject of ``Going Beyond the Guidelines'' quite specifically. The problem with System 7.5 seems to be that Apple has simply integrated a couple of 3rd party extensions where graphic design went out of control, and nobody bothered to talk with Human Interface about what was good, bad, or useful. There is considerable irony in this, in light of Pete Bickford's article in the August _AppleDirections_. Of course, if you want to see some really funky non-standard windows, look at any of the MIDI Products coming from Mark of the Unicorn. Users cried bloody murder when MotU introduced it's ``Miami Vice'' look, but MotU has stayed with it. The ``Mini-Menu'' that was added to most windows are arguably functional, but, even after using their software for several years, I fail to recognize the advantage of a triangular close box or a misplaced zoom box. So, in short: yes, this bothers me. Who else? -- Peter Castine | In old days books were written by men of pcastine@prz.tu-berlin.de | letters and read by the public. Nowadays books Process Control Center | are written by the public and read by nobody. Technical University Berlin | -- Oscar Wilde +++++++++++++++++++++++++++ >From rmah@panix.com (Robert Mah) Date: Fri, 19 Aug 1994 08:19:17 -0500 Organization: One Step Beyond netcom.com!kira!davidjohn (David John Burrowes) wrote: ) ... ) Individually, many of these don't look that bad, I suppose (but, that's ) another issue, really). However, as I recall, one of the advertised ) strengths of the Macintosh, in past years, was its highly consistent ) interface. Buttons looked and behaved the same everywhere. Windows ) with a particular style almost always behaved the same as other windows ) with the same style. Etc. I wholeheartedly concur. Apple's HIG seems to have lost its way -- either that or they have lost their authority to override developer's and designers taste for the strange. One would expect that with Don Norman in charge (he is in charge of HIG isn't he?) that HIG would be less worried over the "look" and more about the "feel". That they would hire fewer graphic designers and more people versed in psychology and sociology. For example, a few months ago there were threads here and on AppleLink about the new windoid look used for Apple Guide. Apple's first excuse was that they "did research" and discovered that the de-facto standard for floating palette title bars was too small a target. Fine, why didn't they simply make the de-facto standard a couple pixels taller? Noooo, instead then said that they hired some graphics designer (as if graphic designers somehow are better at human interface design...). Of COURSE they'll get something that looks different! Who could expect anything else? If the designer returned with something the same as the existing de-facto standard he would be a braver man than most. Hell, they could have saved hard $$$ by buying Infinity Windoid from Troy Gual. The sticky note windows are even more bothersome. As is the inclusion of single-click to launch in the Launcher palette. I've found that it takes users time to learn the double click to launch method in the Finder, but once they do, they understand it. Now, IN THE SAME PROGRAM, there are _two_ methods to open files. This is good? Looking farther into the future, does the pre-emption of the "File" menu with a "Document" menu in OpenDoc bother anyone? This seems to me to be a gratuitous market decision in a vain attempt to differentiate" OpenDoc from the current crop of applications. Hogwash. Changing the name of "File" to "Document" only confuses people, takes up menu bar space, and will NOT increase market share one tiny bit. Do users a vavor, dump the "Document" menu and the old, expected and unsuprising "File". Consistancy and the route of least suprise are _very_ important principles and I wish that stupid columnists would quit harping about the "tired old Mac interface". An interface _should_ be "boring" and "underwhelming". It should not overwhelm the functionality of the system. It should be as invisible as possible. Since computer interfaces are definately not intuative, only through consistancy will we even approach the goal of invisibility. If people want funky looking buttons and windows, third party options exist. But at least most third party options work over all applications, thus still providing some consistancy on that single machine. Finally, lest anyone say that these issues should have been brought up long ago...they were. Both here, on AppleLink and probably other on-line services as well. Cheers, Rob _____________________________________________________________________ Robert S. Mah Software Development +1.212.947.6507 One Step Beyond and Network Consulting rmah@panix.com +++++++++++++++++++++++++++ >From andrew@csgrad.cs.vt.edu (Andrew Southwick) Date: 19 Aug 1994 14:34:06 GMT Organization: IBM SWSD, Lexington, KY, USA wysocki@netcom.com (Chris Wysocki) writes: >David John Burrowes wrote: >>I find myself concerned, therefore, with all of these new innovations. These new interface elements are truly surprising, since they haven't implemented all the stuff that they should have - see below. >.... Their reluctance >to provide standard implementations of UI features such as floating >windows, menus with multiple-modifier keyboard shortcuts, and basic >controls such as up-down arrows, "spinners", such as for the Time field in what used to be known as the General control panel? >sliders and progress bars have forced >developers to implement these features themselves, with varying and >sometimes inconsistent results. This really (constantly) surprises me. THIS is the part of the human interface that APPLE should be working on. Why do I have to create all these controls by hand? Why has Apple refused to develop these interface enhancements? They recognize that (at least some) of them are needed, and Apple products use almost all of these (multiple- modifiers being the one exception, correct me if you've found an Apple product that does use them) interface methods themselves. >At the Worldwide Developers >Conference in May some Apple engineers spoke in nebulous terms about >future UI enhancements which are coming down the road, but it struck >me and others with whom I spoke as too little, too late.... I'd like to confront some Apple management types about this stuff, but given that it's not likely, I thought I'd vent my spleen here. >Chris. Another poster mentions MotU's Performer - which I've seen and used (for 9 months or so). It's something you get used to - but why should I change my methods at all? I use Opcode's Vision, which has a more Mac-like interface. It does use drop-down menus in windows. More like pop-ups, actually. They drop down from icons - but the icons have drop shadows. A more consistent Mac-like interface, and rather than being 'artsy' to appeal to (what? I have no idea), it's just a plain, simple, boring, underwhelming, IGNORABLE interface. You get on with your work, because you don't have to think about the interface! As far as changing interface elements: tools like QuickChange allow users to affect interface elements at their leisure. I use 3D buttons, check boxes, and radio buttons. What annoys me is those apps that bypass the Toolbox calls to use these things - or use different background or foreground colors, such that my (new) controls contrast sharply with whatever's in the menus. I can just imagine how confusing 6 more button types and 6 more window types will be, especially with the 3 more that I (an end user) add myself. Apple, catch a clue. Please. Best Premises, andrew@csgrad.cs.vt.edu Andrew R. Southwick asouthwick@vnet.ibm.com +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: Fri, 19 Aug 1994 10:23:50 -0800 Organization: Integer Poet Software In article , rmah@panix.com (Robert Mah) wrote: > Consistancy and the route of least suprise are _very_ important principles > and I wish that stupid columnists would quit harping about the "tired old > Mac interface". An interface _should_ be "boring" and "underwhelming". > It should not overwhelm the functionality of the system. It should be > as invisible as possible. Since computer interfaces are definately not > intuative, only through consistancy will we even approach the goal of > invisibility. I don't know about your experience, but in mine I have found that the columnists who say this are usually Intel columnists. By that I don't mean they work for Intel directly, but that they write about Windows or OS/2 or perhaps even DOS. The phrase I see most is "The Macintosh interface is showing signs of its age." The thing that's ironic about it is that the Windows interface, a blatant copy, is basically just as old, even though it started out radically different (and of course much much worse, but that's a different problem). I'm not really sure what the columnists are trying to get at, other than the fact that the Mac interface doesn't change. That's the whole point. The Windows interface changes whenever some jokers like Borland decide to throw in *even more* interface elements differentiated only by color and *even more* mysterious icons decodable only by Westerners and sometimes even only by Americans. These columnists were weaned on DOS, where every app had a new interface. So when most every Windows app has some new interface element for which one must read the docs, they cope. And then they complain that the Mac interface is "getting old" because they don't have to cope so much or so often. It seems like one or a combination of the below things is happening. (1) Apple Marketing reads these columnists and figures they must know what they're talking about. (2) The market reads these columnists, figures they must know what they're talking about, and tells Apple Marketing, who in turn thinks it has no alternative but to respond. (3) More and more non-Macintosh engineers are getting hired at Apple and there's nobody left to brainwash them properly. Frankly, from what I've seen of System 7.5, there's less and less reason to develop for Macintosh. That ought to scare the shit out of Apple, because the only way they'll survive is if people think there's reason to bother. -- Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com "Even during a particularly harsh (Colorado) winter... many of the 300 families in the VCTV (movies-on-demand) trial continued to go to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62 +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: Fri, 19 Aug 1994 10:28:35 -0800 Organization: Integer Poet Software In article <332fsu$v0o@watnews1.watson.ibm.com>, andrew@csgrad.cs.vt.edu wrote: > Why has Apple refused to develop these > interface enhancements? They recognize that (at least some) of them > are needed, and Apple products use almost all of these (multiple- > modifiers being the one exception, correct me if you've found an Apple > product that does use them) interface methods themselves. I don't think "refused" is quite the right word. I think what's going on is that Apple is a disgusting fragmented byzantine re-organized bureaucracy at this point. Nobody has the authority to put their foot down and say "dammit, add floating window support to the Window Manager". Lots of people can produce paperwork showing why it should wait until next year when the Frobozzination Manager comes out. But nobody can put their foot down. -- Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com "Even during a particularly harsh (Colorado) winter... many of the 300 families in the VCTV (movies-on-demand) trial continued to go to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62 +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: Fri, 19 Aug 1994 10:32:17 -0800 Organization: Integer Poet Software In article <1994Aug19.031720.1465@kira.net.netcom.com>, netcom.com!kira!davidjohn (David John Burrowes) wrote: > But, with Microsoft coming > out with a significantly improved user interface for Windows soon (Chicago), > this all strikes me as Apple shooting itself in the foot... Don't worry about Chicago's interface. Windows programmers are too "creative" to let Microsoft get away with imposing an interface standard. Not that Microsoft's choices would be any good. I'm more concerned that Apple is giving eveything away by failing to internally impose standards they worked so hard to establish. -- Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com "Even during a particularly harsh (Colorado) winter... many of the 300 families in the VCTV (movies-on-demand) trial continued to go to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62 +++++++++++++++++++++++++++ >From kanderso@mabillon.ICS.UCI.EDU (Ken Anderson) Date: 19 Aug 94 18:05:20 GMT Organization: (none) >One would expect that with Don Norman in charge (he is in charge of HIG >isn't he?) that HIG would be less worried over the "look" and more about >the "feel". Don Norman is an Apple Fellow and is in charge of the Personal Digital Assistants group. The first product from that group was of course the Newton. The person in charge of the Human Interface group is I belive Joy Mountford, who gave a really snazzy talk at Boston last April at CHI94. FYI, Ken -- - ------------------------------------------------------------------------------ -Ken Anderson Ken_Anderson@acm.org U.C. Irvine- - "A knowledge of C is probably better than nothing." -- J.G.P. Barnes - - Finger kanderso@ics.uci.edu for PGP Public Key - - ------------------------------------------------------------------------------ +++++++++++++++++++++++++++ >From shebs@cygnus.com (Stan Shebs) Date: Fri, 19 Aug 1994 18:48:18 GMT Organization: /cygint/s1/users/shebs/.organization In article rmah@panix.com (Robert Mah) writes: I wholeheartedly concur. Apple's HIG seems to have lost its way -- either that or they have lost their authority to override developer's and designers taste for the strange. One would expect that with Don Norman in charge (he is in charge of HIG isn't he?) that HIG would be less worried over the "look" and more about the "feel". That they would hire fewer graphic designers and more people versed in psychology and sociology. Last I heard, Don Norman was just a researcher in ATG, and was not in charge of any actual product work. The only HI-related product person I've talked to recently had just left Apple... One of the functions of the Blue Meanies was to balance the desires of internal developers and designers against the need for compatibility. An Architect with real authority would do this kind of thing also. Alas, Apple seems not to have either these days... Stan Shebs Cygnus Support shebs@cygnus.com +++++++++++++++++++++++++++ >From rob@eats.com (Rob Newberry) Date: Fri, 19 Aug 1994 15:17:28 UNDEFINED Organization: Education and Technology Solutions Well, I can't tell if I agree or disagree with the others in this thread. But in some ways, I'm quite sure I favor enhancements to the user interface. In my opinion, many things in the interface need to evolve. I am terribly excited about the new things in System 7.5. As I understand it, Apple is readying a new Appearance Manager, which will let the user customize much of the interface. I think this is a "good thing". I'm sure it will come with a "default", but I like the idea of being able to take control. On the other hand, as a programmer, if I gave up on Apple already, and started trying to implement my own 3D buttons or the like, what will happen when Appearance Manager comes out? Will the user be able to customize every application (oh, yeah, by then, my app won't be an app, but an OpenDoc "document manager") except mine? Yikes! In short, I wish Apple had loosened the reigns a little more earlier. Though I don't think they're far behind in the standard look and feel, a lot of developers have moved on and done things that needed to be done on their own. Rob +++++++++++++++++++++++++++ >From dnebing@andy.bgsu.edu (bgsuvax) Date: 19 Aug 1994 19:41:27 GMT Organization: Bowling Green State University Where have the standards gone? Out the window. But that's been a long time coming. Standards are good if they are robust and evolve with change. However the HIG standard, while at first introduction was quite robust, didn't keep up with what was being published in the industry. Take for example Word's toolbar that can be found in most of their apps now and can also be found in other vendor's apps (i.e. CodeWarrior). The HIGs never evolved to encompass toolbars, hence the thread that started here some time back about toolbar icons representing nouns or verbs, and which was appropriate. There has always been things that we, as Mac programmers, have wanted to do but were limited by the HIGs. So the choice between following the guidelines or throwing the HIGs out the window and just do what was necessary. While most programmers have followed the guidelines, there are several apps out there that have had to break the HIGs in order to do what was necessary. If the HIGs are dead, then RIP. If not, then the HIG people at Apple have some major work to do to bring the HIGs up to snuff with respect to new interface elements and then coerce us (the programmers) that the HIGs are worth following. Dave ============================================================ Dave Nebinger dnebing@bgsuvax.bgsu.edu Network Manager, Biology Dept. dnebing@opie.bgsu.edu Bowling Green State University dnebing@bgsuopie (bitnet) Bowling Green, OH 43403 #include *THE* alt.sources.mac supporter! +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Fri, 19 Aug 1994 22:27:27 +0200 Organization: Royal Institute of Something or other In article <1994Aug19.031720.1465@kira.net.netcom.com>, netcom.com!kira!davidjohn (David John Burrowes) wrote: >- a strange little thing for 'post-it' notes >- a green one for the CD player (the title bar is similar to the standard > document titlebar, but not the same) These are specialized apps that don't use standard documents, and as such are entitled to having their own user interface, sort of. The more they go in with the Mac look, the better; and both of these can have the window colors set to white. >- the Find File windows have a funky styled background It's funky in the betas, where's its a structured noise pattern; in the release it's just a kind of subtle weave that I don't like half as much. I pasted back the gray pattern from the betas :-) That pattern is available from the system file (ID=42) for anyone who wants a gray background, presumably. >- A window that is reminiscent of the 'palette' titlebar, but with close > and zoom boxes. Yeah, but that's the new floating window WDEF that Apple wants ALL of us to use; i e it's a STANDARD as opposed to all the variants of floating palettes we've seen now. However, I have this feeling people are not going to use this floating WDEF, since the title bar is too bloody large for most floating pallette uses - Apple says that's to make it easier to hit for newbies, but to me, that seems less important than real productivity for real users... Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden "TextEdit does everything right." ‹ Jon W{tte +++++++++++++++++++++++++++ >From sanford@CS.Arizona.EDU (Sanford H. Selznick) Date: 19 Aug 1994 17:58:35 -0700 Organization: University of Arizona CS Department, Tucson AZ Why did Apple change it's UI so drastically in 7.5? Marketing. When Joe computer buyer walks into a Sears or BizMart he's going to see two computers. He'll see a 486 box running windows 3.1 and a Mac running system 7.1. The 486 will undoubtedly have the calculator open. And, well, at first glance it looks darned good. It's got that electric grey background, 3D buttons, and it's big. Is this something you'd want to use every day? No way. The Mac will undoubtedly have the trash window open. The trash icon will be sitting in the middle of the screen. So the sales rep says "the mac has a calculator too." And what does it look like? A small blue piece of crap that obviously hasn't evolved as fast as the windows calculator. It just doesn't look as good. Before I go on, let me say I've been 1000% more productive on my mac than I have been on a 486 box running windows. I like the mac calculator better too. But when it comes time to sell a machine to Joe Shmo, he wants to see that electric grey calculator. Of course the graphic calculator that comes with the PPC blows everything else away... and that's a step in the right direction. Not funky post-its. IMHO, Sanford +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: Fri, 19 Aug 1994 19:43:47 -0800 Organization: Integer Poet Software In article , rob@eats.com (Rob Newberry) wrote: > As I understand it, Apple is readying a new Appearance Manager, which will > let the user customize much of the interface. I think this is a "good thing". > I'm sure it will come with a "default", but I like the idea of being able to > take control. This is a Really Bad Thing, IMO. Sure, Windows has it. So what? Windows has a SYSTEM.INI, too. Suddenly you're going to have every half-baked ResEdit jockey creating new Appearances, and co-workers are going to be confused by each other's machines. It's only a matter of time before the Control Panel interface is replaced by a text file, I guess. > Though I don't think (Apple is) far behind in the standard look and feel... Apple *is* the standard look and feel. It's the other vendors who've gone off into the weeds. Some (collective) genius at Apple now thinks it's a good idea to follow them there. -- Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com "Even during a particularly harsh (Colorado) winter... many of the 300 families in the VCTV (movies-on-demand) trial continued to go to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62 +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: Fri, 19 Aug 1994 19:49:00 -0800 Organization: Integer Poet Software In article <3331t7$rc8@falcon.bgsu.edu>, dnebing@andy.bgsu.edu (bgsuvax) wrote: > ...the HIG standard, while at first introduction was quite > robust, didn't keep up with what was being published in the > industry. Take for example Word's toolbar ... My God, the day has come to kill myself. Someone is seriously referring to a Microsoft product as having a good interface. To be a little less histionic, the ToolBar(tm) is the worst thing to happen to interface in a long time, IMO. It's all well and good to have clickable icons represent metaphorical paint tools, but when it comes to down to saving a file, there's no good icon. But Microsoft didn't let a little detail like *that* stop them. After all, 30 people at Microsoft thought it was a good idea -- who else counts? > While most programmers have followed the guidelines, there > are several apps out there that have had to break the HIGs > in order to do what was necessary. Examples being? -- Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com "Even during a particularly harsh (Colorado) winter... many of the 300 families in the VCTV (movies-on-demand) trial continued to go to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62 +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: Fri, 19 Aug 1994 21:25:17 -0800 Organization: Integer Poet Software In article , gurgle@dnai.com (Pete Gontier) wrote: > To be a little less histionic Don'tcha just hate it when you use a 50 cent word and typo it? -- Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com "Even during a particularly harsh (Colorado) winter... many of the 300 families in the VCTV (movies-on-demand) trial continued to go to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62 +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 19 Aug 94 21:57:03 MST Organization: (none) In article <1994Aug19.031720.1465@kira.net.netcom.com>, netcom.com!kira!davidjohn (David John Burrowes) writes: > I was reading the article about System 7.5 in the September 1994 issue of > MacUser (p. 79-84), and it raised a gigantic question in my mind. After > some thought, I decided to see what opinions others (yourselves) might have. > > The 'screenshots' on pages 80-81 and 82-83 of the above issue shows several > new features of this system software release. In them, I noted five new > window styles: [examples of inconsistant interface and ruminations on the subject snipt] > If you've read this far, I'm curious what your thoughts are, either through > personal email or on the newsgroup. Maybe I'm very much in the minority, > and folks generally think the 'highly consistent' interface was too > constraining? I think that it is obvious that 7.5 is a rush-job. Aside from AppleScript, AOCE, GX nad one or two other exceptions, the new stuff in 7.5 all appears to be licensed from 3rd parties and included as is without any attempt to make it more System 7-ish. It ain't that impressive from an HI or integrated-design standpoint, but it DOES add needed functionality. Maybe the 7.8 upgrade will address these issues? Lawson +++++++++++++++++++++++++++ >From L.H.Wood@student.lut.ac.uk Date: Fri, 19 Aug 1994 13:58:07 GMT Organization: Loughborough University, UK. In article pcastine@prz.tu-berlin.de (Peter Castine) writes: >In article <1994Aug19.031720.1465@kira.net.netcom.com>, >netcom.com!kira!davidjohn (David John Burrowes) wrote: > >> I was reading the article about System 7.5 in the September 1994 issue of >> MacUser (p. 79-84), and it raised a gigantic question in my mind. After >> some thought, I decided to see what opinions others (yourselves) might have. >> >> The 'screenshots' on pages 80-81 and 82-83 of the above issue shows several >> new features of this system software release. In them, I noted five new >> window styles: > >[schnipp...] > >> If you've read this far, I'm curious what your thoughts are, either through >> personal email or on the newsgroup. Maybe I'm very much in the minority, >> and folks generally think the 'highly consistent' interface was too >> constraining? > The new mini-window bar is generally considered ugly, and generated a lot of discussion in csmp. [..] >It seems to me that standards are going out the window, and that this is a >negative development. Conventional buttons and WDEFs may seem a little >unadventurous, but in day-to-day work the security of knowing how to >recognize a button and where the window title is are a great advantage. I >always disliked HyperCard's anything-can-be-a-button attitude, because it >leaves you with the challenge of clicking on *everything*, just to see if >maybe that little chicklet-shaped object triggers some sort of action. >This is fine and dandy for an adventure game, but frustrating when you're >trying to get on with your work. > >As one example, I was looking at the new(ish) AppleCD Audio Player. The >only reason I even tried clicking on the little green triangle in the >lower left corner was because I knew that the fore-runner software had a >track list and I was sure that the newer software _must_ have a track list >somewhere. I looked in the menus, to no avail, so I started clicking >around and the mouse finally landed on said triangle. Voila! Success at >last! > >But, why the hell should I spend my time clicking around a window to find >a substitute for the Zoom box? (Use of the zoom box as a sort of >{show|hide}-details-of-a-dialog-window is not officially sanctioned, but >has found it's way into a number of utility programs). Sure, if I'd turned >on Balloon Help, I might have found this button sooner, but an experienced >Mac user shouldn't need Balloon Help to find an _Ersatz_ zoom box. > I think of these as 'Easter Eggs', which I dislike. If a tool surprises me (and a computer is a tool) then it's not transparent to me, which means it's badly designed. >That said, let me add that it *is* important for UIs to develop; I'm not >going to advocate cast-in-platinum Human Interface Guidelines. The >_Macintosh Humand Interface Guidelines_ discuss the subject of ``Going >Beyond the Guidelines'' quite specifically. > >The problem with System 7.5 seems to be that Apple has simply integrated a >couple of 3rd party extensions where graphic design went out of control, >and nobody bothered to talk with Human Interface about what was good, bad, >or useful. > Didn't Apple sack most of Human Interface a while back, on the grounds that they needed the redundancies and human-interface people don't generate money? [The number of applications rolling in different 3D buttons is annoying. I don't like 3D buttons; I want consistent 2D buttons, not 3D buttons that differ in every application.] Quick question - how many human-interface people have ever worked for Microsoft? This bothers me, a lot. L. -- _____________________________________________________________________________ L.H.Wood@student.lut.ac.uk Email me for a copy of the Mac screensaver FAQ +++++++++++++++++++++++++++ >From tgaul@halcyon.com (Troy Gaul) Date: Sat, 20 Aug 1994 00:46:27 -0700 Organization: Infinity Systems This discussion has brought up a lot of good points about the Bad Things that are happening to the interface, particularly with System 7.5. One point I'd like to make is that most of the things we're talking about here aren't things that Apple _had_ to invent from scratch because there weren't already prefectly good ways of doing them. One of the things that the HI people at Apple keep saying is to not invent new interface elements when the ones that are available will suit the purpose. (I'll expand this to include that one shouldn't create new appearances for essentially the same controls, as that effectively makes them into new controls.) Back when System 7 first came out, I was really glad that they finally did something about the black-and-white titlebars and scrollbars in windows. You will notice, however, that even though they added color and 3D effects, they did so in a tasteful manner (IMHO). This new look was what inspired me to write the Infinity Windoid WDEF, as the old black-and-white WDEF of the past were just lacking something. When I first made it, however, I tried first and foremost to stay true to the original design of floater WDEFs. The size and position of the gadgets were the same, and the coloring scheme matched that of the new System 7 windows. Although the height of the titlebar has grown 2 pixels since this first version, I think it is still true to the earlier WDEF, and I think that makes it easy for people to identify as a floater. When I see the new Apple 7.5 titlebar, I instantly think 'Help Window', because this is where it is seen most often. Maybe this will change if apps start using it for floaters, but I'm not sure. As for the comments about the design of the new AppleCD Audio Player, I don't find that as offensive as some of the other people who've commented on it. The main reason I feel this way is that this is what I'll call a 'consumer interface' program (it's designed to look more like a 'real' CD Player's control panel). My main gripe is the triangle control. Apple has the 'turn knob' control like is used in the old Alarm Clock DA that would has served the purpose without adding yet another new interface element. (But [sarcastic tone], of course that doesn't have any color in it...) The new application to control the 630's TV Tuner, if you look at it, has an interface that is similar, as it is also a consumer-type controller. Now, we have the post-it note application. The reason for the window design there is that the titlebar and grow box are attempting to stay out of the way as much as possible, so that it looks like a post-it, even when the titlebar is active. I may not love the fact that the interface is different, but I at least understand it, and since I never use it anyway... I'm not saying these changes are all good, by any means, but _some_ of them are understandable (if they are kept in check). As for the Find File application window, all I can say is that Apple has given guidelines for a 3D beveled interface in a past issue of Develop (where a 'flat' light gray is used as the main color). Why couldn't they just use this interface? And similarly, the 3D icon-buttons described in that article would work for the buttons in the help window (without the edges being quite so thick, as they were at least in the beta). Though, I didn't like the alternate push buttons, radio buttons, and check boxes given in that article. Use the standard CDEF, darn it!... If people want gray standard buttons, they can install something like Greg's Buttons and at least have it done consistently. Oh, and don't forget that the AppleScript Script Editor and the PowerTalk mailer, which both use something like the Develop-described beveled interface, even seem to use different shades of gray for the main part of the window(!). I could go on, but I think I'm preaching to the choir here. Anyway, I'd like to hear from some of the Apple people who are on the list as to how this stuff goes on. How do these designs get into products? I understand that there was one person in particular who did most of the designs for the color icons when System 7 was released, why isn't there a similar person who could enforce some amount of user interface consistency? _troy //////// //////___Troy Gaul____________________tgaul@halcyon.com___// // // Infinity Systems // // // // Redmond, Washington // // //////____________________________________________________// +++++++++++++++++++++++++++ >From gasser@masg1.epfl.ch (Laurent Gasser) Date: 20 Aug 1994 12:50:33 GMT Organization: Ecole Polytechnique Federale de Lausanne The Human Interface Guideline specifically ban the window toolbar as too numerous icons. (It is in the scroll bar chapter, if my memory is faithfull. They show two windows, one with one or two additional functionality to scroll bar, the other, bad example looks like Word's windows.) The spirit of Mac interface is quite stringent. Remember the guidelines about the use of color? Don't use it as the single way to convey information except when it is the whole information. Basically, make the interface look simple, so simple it looks dumb. Don't even do that: make it look sober! In article <3331t7$rc8@falcon.bgsu.edu>, dnebing@andy.bgsu.edu (bgsuvax) writes: [edited] |> Standards are good if they are robust and evolve with change. |> However the HIG standard, while at first introduction was quite |> robust, didn't keep up with what was being published in the |> industry. |> |> Take for example Word's toolbar that can be found in most of |> their apps now and can also be found in other vendor's apps |> (i.e. CodeWarrior). The HIGs never evolved to encompass |> toolbars, hence the thread that started here some time back |> about toolbar icons representing nouns or verbs, and which |> was appropriate. |> [edited] |> Dave |> |> ============================================================ |> Dave Nebinger dnebing@bgsuvax.bgsu.edu |> Network Manager, Biology Dept. dnebing@opie.bgsu.edu |> Bowling Green State University dnebing@bgsuopie (bitnet) |> Bowling Green, OH 43403 #include |> |> *THE* alt.sources.mac supporter! -- Laurent Gasser (gasser@dma.epfl.ch) Computers do not solve problems, they execute solutions. I know very few ideas worth dying for, none is worth killing. +++++++++++++++++++++++++++ >From rmah@panix.com (Robert Mah) Date: Sat, 20 Aug 1994 09:09:14 -0500 Organization: One Step Beyond gurgle@dnai.com (Pete Gontier) wrote: ) rmah@panix.com (Robert Mah) wrote: ) ) > Consistancy and the route of least suprise are _very_ important ) > principles and I wish that stupid columnists would quit harping ) > about the "tired old Mac interface". An interface _should_ be ) > ... ) ) I don't know about your experience, but in mine I have found that the ) columnists who say this are usually Intel columnists. By that I don't ) mean they work for Intel directly, but that they write about Windows ) or OS/2 or perhaps even DOS. The phrase I see most is "The Macintosh Umm, well I have seen the Mac rags talk about this, but whatever, my statement was a low blow and most journalists didn't deserve it. Even if they _do_ say, what I attributed to them, that certainly doesn't mak them "stupid". I appologize to any who may be listening in. Cheers, Rob _____________________________________________________________________ Robert S. Mah Software Development +1.212.947.6507 One Step Beyond and Network Consulting rmah@panix.com +++++++++++++++++++++++++++ >From rmah@panix.com (Robert Mah) Date: Sat, 20 Aug 1994 09:26:38 -0500 Organization: One Step Beyond rob@eats.com (Rob Newberry) wrote: ) But in some ways, I'm quite sure I favor enhancements to the user ) interface. In my opinion, many things in the interface need to evolve. Just like steering wheels and typewriters, huh? Seriouslly, techies have a love of the new and always want change. Change, for no good reason, however, is anethma to a good human interface. Again, the goals are invisibility and no supprise. Obviouslly, these cannot be reached, but we can try to get closer by maintaining consistancy. When research shows, conclusively that some interface element is out of whack and needs change, then I'm all for it. However, the change should be made with respect to the existing system. For example, Apple folk have said that research showed that normal float- ing window move bars were too small. OK, fine, we should make them bigger. BUT, there is already a de-facto standard for their look (i.e. 50% gray lines seperated by 1 pixel of background). Why diverge from it? There is NO sound human interface or technical reason. ) As I understand it, Apple is readying a new Appearance Manager, which ) will let the user customize much of the interface. I think this is a ) "good thing". I'm sure it will come with a "default", but I like the ) idea of being able to take control. Control is fine. Customization is fine. But ONLY after one has mastered the basics. And by rolling such a feature into the basic OS, as someone else mentioned, one assures that inexperienced users will change the look of their machines. This is not good. They will only get confused when they have to use some- one else's machine. They will call tech support lines and complain that the pictures in the manual don't match what they see on their computer. In general, the interface will become an obstical instead of an aid. ) In short, I wish Apple had loosened the reigns a little more earlier. ) Though I don't think they're far behind in the standard look and feel, ) a lot of developers have moved on and done things that needed to be ) done on their own. But that's _part_ of the "official" guidelines. If there is no accept- able standard interface element that fits, create something new that does. Just make sure you consider the standard and de-facto standard elements first. Cheers, Rob _____________________________________________________________________ Robert S. Mah Software Development +1.212.947.6507 One Step Beyond and Network Consulting rmah@panix.com +++++++++++++++++++++++++++ >From rmah@panix.com (Robert Mah) Date: Sat, 20 Aug 1994 09:36:11 -0500 Organization: One Step Beyond h+@nada.kth.se (Jon W{tte) wrote: ) netcom.com!kira!davidjohn (David John Burrowes) wrote: ) ) >- a strange little thing for 'post-it' notes ) >- a green one for the CD player (the title bar is similar to the standard ) > document titlebar, but not the same) ) ) These are specialized apps that don't use standard documents, ) and as such are entitled to having their own user interface, ) sort of. The more they go in with the Mac look, the better; and ) both of these can have the window colors set to white. I disagree. The CD-Player controls an external device with a small number of discrete controls. While its similarity to "real world" CD players could be argued, I must point out that _my_ real CD player looks nothing at all like the software CD-Player. Actually, now that I think about it, very few real CD-players look like that program's main window. As for the Post-It (r) notes software. Give me a break. It's just a bunch of windows for jotting quick notes that remember their locations. I'm not denigrating the app, it's quite nicely done, but really...user selectable color backgrounds would have been OK, but no standard (or even miniature) grow box, etc., etc. There's no excuse except ego gratification. ) Yeah, but that's the new floating window WDEF that Apple wants ALL of ) us to use; i e it's a STANDARD as opposed to all the variants of float- ) ing palettes we've seen now. What "varients" ?. Except for a few apps that use the standard WDEF for their floaters, they all look very similar (other than the use of color). Only Apple's looks different. They are the varient, the one at odds with the de-facto standard that has emerged over the last few years. If Apple had simply bought Troy's Infinity Windoid, everyone would have been better off. Especially the users (even if they wouldn't know it). Cheers, Rob _____________________________________________________________________ Robert S. Mah Software Development +1.212.947.6507 One Step Beyond and Network Consulting rmah@panix.com +++++++++++++++++++++++++++ >From rmah@panix.com (Robert Mah) Date: Sat, 20 Aug 1994 09:54:50 -0500 Organization: One Step Beyond dnebing@andy.bgsu.edu (bgsuvax) wrote: ) Standards are good if they are robust and evolve with change. However ) the HIG standard, while at first introduction was quite robust, didn't ) keep up with what was being published in the industry. This is an irrelavent argument. There is no "human interface" industry to keep up with (though I understand you meant the computer or software industry). And I would argue that keeping up with the Joneses is not a worthy goal. Human interface design should pay more attention to new perspectives in the fields of psycology, sociology, cognition, perception, linguistics, learning theory, etc. than the computer and software field. These "soft" fields are much more important, because the purpose of human interface design is to mold the machine (or software) the person. A better under- standing of human behaviour will lead to better designs. ) Take for example Word's toolbar that can be found in most of their apps ) now and can also be found in other vendor's apps (i.e. CodeWarrior). ) The HIGs never evolved to encompass toolbars, hence the thread that ) started here some time back about toolbar icons representing nouns or ) verbs, and which was appropriate. The previous discussion to which you refer was more about whether one should mix nouns, verbs and adjectives/adverbs in palettes. Microsoft made the cardinal sin of not considering the underlying rational for tool palettes (e.g. in paint programs). They never stopped to examine just what was being presented to the user and why tool palettes were a valuable addition to the user interface. Instead, they said (or so I surmise)... "Let's add icons -- icons are cool." "But what icons? We don't have any tools like paint bucket in Word..." "How about something for the basic commands like print and save?" "Yeah, that's it!" "OK, how 'bout a spell checker icon?" "Cool man." ... ... "Uh, Joe, what does that icon mean?" "Oh, that's the 'Paste special' icon, can't you tell?" "Well, no...I guess we should add some help" "Great idea! That way, no one will get confused because we'll have text explaining what each icon does!" "Cool man." My question: if you need text to explain a large percentage of the icons, then why use the silly icons in the first place? The REASON why the toolbars in word and excel (and other programs) are undeciferable by modern man are twofold. 1. They depart from the normal practice of using icons to represent nouns. That is _things_ that can be manipulated. 2. Each application has it's own "vocabulary", leading to a Tower of Babel. Users must learn a new and different "iconic language" for each app. This is obviouslly not a good thing. If there were a standardized vocabulary AND verb-icons could be visually distinguished from noun-icons and modifier-icons (i.e. adjectives and adverbs) then, and only then, will toolbars become a truely useful interface element. Note that, on the Mac anyway, there is already a standardized vocuabulary for many graphics app-oriented tool icons. Color seed fill tools are paint buckets. Color grabbers are little eye droppers. Pencils draw points and free form lines that follow the cursor. This standardized vocabulary allows these tools to become "invisble" once they learn them. Learn them once. This goes back to more subtle things like the Apple's own special look for floating windows. Now people have to recognize TWO types of windows as floaters. This is not good. Phew! Enough typing for now. Cheers, Rob _____________________________________________________________________ Robert S. Mah Software Development +1.212.947.6507 One Step Beyond and Network Consulting rmah@panix.com +++++++++++++++++++++++++++ >From dnebing@andy.bgsu.edu (bgsuvax) Date: 20 Aug 1994 18:15:31 GMT Organization: Bowling Green State University Whew, mention Word's toolbars and I end up catching some flames! ;-) Anyway, all points mentioned about Word's toolbars don't have much thought behind them are true. I never meant to say that Word's interface was the best and we should all turn towards Washington and say "We're not worthy!" I did want to show how graphical elements like Word's toolbar have been popping up and there is nothing in the HIGs to govern their appearance nor what they should contain (nouns, verbs, adjectives/adverbs). Other items have been world floating windows, system menus, etc. There are lots of examples of things that have been done which aren't covered in the HIGs. Do the HIGs say anything about removing the Help menu like SpeedyFinder does, etc. As far as Word's toolbar goes, I like it. I like the fact that I can set up my own tool to represent a command which I might use from time to time that I forget what the key combination is (is that cmd-opt-u or cmd-opt-cntrl-u or cmd-opt-shift-u ...). Other apps have been adding toolbars, too. OmniPage 5.0 has one, most MS products have one, I understand that CodeWarrior has one too. Toolbars are showing up all over the place, but the HIGs don't say whether nouns, verbs, or adj/advs should be used. My whole point was that the HIGs have to be constantly evolving to cover new things like toolbars, etc. You can't just set up some standards and expect them to stay golden forever without change. Dave ============================================================ Dave Nebinger dnebing@bgsuvax.bgsu.edu Network Manager, Biology Dept. dnebing@opie.bgsu.edu Bowling Green State University dnebing@bgsuopie (bitnet) Bowling Green, OH 43403 #include *THE* alt.sources.mac supporter! +++++++++++++++++++++++++++ >From Jaeger@fquest.com (Brian Stern) Date: 20 Aug 1994 18:21:56 GMT Organization: The University of Texas at Austin, Austin, Texas In article , rmah@panix.com (Robert Mah) wrote: > The REASON why the toolbars in word and excel (and other programs) are > undeciferable by modern man are twofold. > > 1. They depart from the normal practice of using icons to represent nouns. > That is _things_ that can be manipulated. > > 2. Each application has it's own "vocabulary", leading to a Tower of Babel. > Users must learn a new and different "iconic language" for each app. > This is obviouslly not a good thing. > > If there were a standardized vocabulary AND verb-icons could be visually > distinguished from noun-icons and modifier-icons (i.e. adjectives and > adverbs) then, and only then, will toolbars become a truely useful interface > element. > > Note that, on the Mac anyway, there is already a standardized vocuabulary > for many graphics app-oriented tool icons. Color seed fill tools are paint > buckets. Color grabbers are little eye droppers. Pencils draw points and > free form lines that follow the cursor. This standardized vocabulary > allows these tools to become "invisble" once they learn them. Learn them > once. > > Phew! Enough typing for now. > > Cheers, > Rob > _____________________________________________________________________ > Robert S. Mah Software Development +1.212.947.6507 > One Step Beyond and Network Consulting rmah@panix.com Let me add a bit of grist to this mill. It is simply not true that icons on the Mac are always used as nouns. This is true in the Finder where icons represent files, and in Resedit. The icon buttons used in graphics programs indicate something like 'change the cursor to a pencil tool' or 'change the cursor to the paint bucket tool'. Icon buttons are a hybrid between icons and buttons. All buttons act as verbs, including icon buttons. I don't think there is ever a confusion between icons-as-nouns and icons-as-verbs. The drop shadow One could argue that the calculater DA uses a primitive icon-button interface. The '*' and '/' and '+' keys use symbols to indicate their functions. These buttons are also not standard Mac pushbuttons. This interface works because it's so similar to real calculaters that there is little or no learning curve. Hypercard uses '->' buttons to indicate 'go to the next card'. The old Font/DA mover had a standard pushbutton with '>>' on it to transfer fonts from the left list box to the right list box. Admittedly that interface wasn't God's gift to interfaces but it is a case where a symbol, rather than words was used on a button. That interface lives on in lots of places, like 'Add Files' dialog boxes, although often there is a word rather than a symbol. Presumably we'll be seeing drag-and-drop replacements for this RSN ;). The problem with icon buttons is that it's often hard to remember what they represent and there are often too damn many of them. FWIW I never use Word's toolbar. (Also Word's toolbar takes a loooong time to redraw.) In Word's defense the toolbar can be turned off, and anything that you can do with the toolbar can also be done with the menus, and in many cases with command key equivalents. The icons on icon buttons are simply meant to replace the words that would go there. And this is done to save space on the buttons, and to be cool, of course. I think that the key to good icon buttons is to have not very many of them. That allows you to remember what they do. -- Brian Stern :-{)} Jaeger@fquest.com +++++++++++++++++++++++++++ >From rmah@panix.com (Robert Mah) Date: Sat, 20 Aug 1994 20:42:57 -0500 Organization: One Step Beyond Jaeger@fquest.com (Brian Stern) wrote: ) Let me add a bit of grist to this mill. It is simply not true that icons ) on the Mac are always used as nouns. This is true in the Finder where ) icons represent files, and in Resedit. The icon buttons used in graphics ) programs indicate something like 'change the cursor to a pencil tool' or ) 'change the cursor to the paint bucket tool'. Icon buttons are a hybrid ) between icons and buttons. All buttons act as verbs, including icon ) buttons. I don't think there is ever a confusion between icons-as-nouns ) and icons-as-verbs. The drop shadow To you, the programmer, the pencil icon may mean, "change internal mode to kPencilToolMode", but to the user it means, "I wanna use the pencil now". That is, the icon is a graphical representation of a tool, a thing. That this "thing" doesn't actually exist is not relavent. I.e. when I talk about nouns-vs-verbs, I'm looking at the icons from the user's viewpoint. Icon buttons, without text are, IMO, not good, because they try to represent actions as icons. Same problem as MS-style toolbars. ) One could argue that the calculater DA uses a primitive icon-button ) interface. The '*' and '/' and '+' keys use symbols to indicate their ) functions. These buttons are also not standard Mac pushbuttons. This ) interface works because it's so similar to real calculaters that there ) is little or no learning curve. Software calculator interfaces work because of three reasons... 1. As you mention, there are real world analogues to the user interface. 2. The buttons represent well known concepts (the digits, adding etc.) 3. The graphical representation of these concepts have been standardized. I.e. there is a common and accepted vocabulary. "+" means add. "=" means equals. Etc. Thus, as you say, there is no confusion. However, imagine what would happen if you added a "save paper tape to file" button to the caculator Note that, in this specific case, the criteria that I set forth for the use of icons to represent verbs have been fullfiled. Thus, it works. Most applications and software in general do not fullfil these criteria. ) Hypercard uses '->' buttons to indicate 'go to the next card'. Don't even get me started on HyperCard! No thought seemed to have been given to interface design on that thing. Problems like floating palettes that de-hilite, fixed window sizes, dynamically changing menus, too many modes, modal editors, etc. Many problems were fixed in later versions and the current one is actually starting to get decent. ) The old Font/DA mover had a standard pushbutton with '>>' on it to ) transfer fonts from the left list box to the right list box. Admittedly ) that interface wasn't God's gift to interfaces but it is a case where a ) symbol, rather than words was used on a button. That interface lives on ) in lots of places, like 'Add Files' dialog boxes, although often there is ) a word rather than a symbol. Presumably we'll be seeing drag-and-drop ) replacements for this RSN ;). Ever remember seeing someone try to figure out Font/DA Mover? The concept is simple to those who understand the mechanics, but to normal users who don't want to understand resources and such, it was a royal nightmare. Wouldn't it have been better to title the buttons as "Move ->" or even better "Move To File XYZ". Or even better, drop the damn thing and move its functionality to the Finder where people don't have to learn yet another method of moving objects around. Cheers, Rob _____________________________________________________________________ Robert S. Mah Software Development +1.212.947.6507 One Step Beyond and Network Consulting rmah@panix.com +++++++++++++++++++++++++++ >From hanrek@cts.com (Mark Hanrek) Date: 21 Aug 1994 01:37:23 GMT Organization: The Information Workshop When I explain what is heappening in the world of computers to non-computer people, I like to draw an analogy to the early days of automobiles, when between the different manufacturers, there were different ways to steer, and different ways to start, stop, and make the horseless-carriage go. Maybe that analogy is useful in this discussion. Today, we can get into a 1965 Galaxie 500, or a 1994 Supra, and easily know what to do to drive either of them. Perhaps we are at the stage where we can be a little loose, and allow for some differing styles on our screens. As long as the close box, zoom box, grow box, and drag bar are clearly obvious and work the expected ways, a window is a window. The same with buttons. Maybe this is the beginning of wriggling out of the super-restricted user-interface thinking we have been in for so long. At first it was "the march to enforce consistency", and the Macintosh made its point. Now that we have done that, and everyone understands the fundamental value of consistency, we can let up and allow some style. You know those telephones with the gigantic numbers on buttons that are 2 inches on a side?.... :) Mark Hanrek The Information Workshop +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Sun, 21 Aug 1994 02:21:21 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) sanford@CS.Arizona.EDU (Sanford H. Selznick) writes: >Of course the graphic calculator that comes with the PPC blows >everything else away... and that's a step in the right direction. Not >funky post-its. Agreed. With the PowerMac, application developers are guaranteed a certain floor of performance, which makes possible apps that depend on that floor. Graphic Calculator is an example; something like that is too unwieldy to use if it updates slowly. 3D editing programs can be written to assume the model can be manipulated interactively. Look at Ashlar Vellum for something that intelligently uses CPU time in an interactive way. This is the way to a "killer app" that sells PowerMacs to PC users. Unless Apple comes up with something that moves users from PCs to Macs, Apple's market share will steadily decrease, because users are already moving the other way. John Nagle +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Sun, 21 Aug 1994 02:49:17 GMT Organization: The World Public Access UNIX, Brookline, MA In article <1994Aug19.031720.1465@kira.net.netcom.com>, David John Burrowes wrote: >If you've read this far, I'm curious what your thoughts are, either through >personal email or on the newsgroup. Maybe I'm very much in the minority, >and folks generally think the 'highly consistent' interface was too >constraining? Others must have noticed that Apple, Microsoft, and any plethora of other GUI builders are doing what they've always been doing. Stealing (uh, adapting) ideas from eachother. Apple anounces a new feature, Microsoft isn't far behind. Microsoft announces a new feature, Apple isn't far behind (my favorite example of this is preemptive multitasking and threads). What you're seeing is Apple doing what it has always done, and will continue to do. Their documentation as to "standards" is temporary gibberish; there are so many standards of such short life-spans, that the term "standard" in computer-world has little meaning. In the end, I don't think users really care if their buttons are 3-D shadowed, or if they're rounded, square, or whatever. They just want software that's useful or fun, or that, at a minimum, marketing can convince them to buy. It doesn't really matter if it's a mac, a windows, a car, a dog, or a cat. People are people are people, and will always behave as people. Oh gosh, I'm straying. Let me get off of my soap box. Ah, that's better. Cheers! -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Sun, 21 Aug 1994 03:10:46 GMT Organization: The World Public Access UNIX, Brookline, MA In article , Pete Gontier wrote: >Frankly, from what I've seen of System 7.5, there's less and less reason >to develop for Macintosh. That ought to scare the shit out of Apple, >because the only way they'll survive is if people think there's reason to >bother. For me, it's not 7.5. It's the pathetic state of the APIs and documentation. Who wants to spend their life looking through 16000 pages? There is no reason the OS needs to be that complicated. And no, a legacy OS is not a reason for rampant complexity. And OpenDoc is only going to make it worse. Oh ya, and six (SIX!!!) books for QDGX. Geesh. Unfortunately for the world, Microsoft is making the exact same mistakes. Oh well. And then, there are the development tools. We all know what sorry state they've been in and continue to be in. And the pathetic languages used for development (this isn't a mac-only problem; none of this is a mac-only problem). Finally, there's the market share. Many more windows machines than macs. Solution? Some cross-platform package. Well, then you get into deciding which one to use, will the company be around, convincing your engineers, etc. Why do I do mac development? Because I learned it years ago and manage to keep up with a minimum of the dumb system junk they produce. And I can still get work doing it, because there are several million macs out there, and that's a reasonably sized market. And because learning another OS is a major hastle (see above). And it pays my bills so I can do what I want to do. And no, that's not program computers all the time. Really. No, really. Here's my schpiel: computers suck. They all suck. But they're useful tools for certain problems. But give me 50 years, maybe 100, and no one will talk of digital computers. It will be about systems that immitate biological systems. We all run around with the most powerful information processing system on our shoulders. It's the ultimate in portability. Well, obviously we don't do matrix multiplications too fast, but that's about all computers beat us at. Yes, biology is the future. Even a single living cell (even a bacterium!) puts computers to shame. Small, efficient, fast, robust (!!), disposable, recyclable. Engineering on the atomic level. People who talk about nano-machines don't know squat about the future. An enzyme is a nano-machine, built atom by atom, in a process no one can describe fully. And you've got so many trillions of them, constantly being built and destroyed, of such an incredible variety. Really, computers do suck. And yes, they're useful tools. Heck, they pay the food bills, so this biological entity can continue to pontificate and study itself :-) -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Sun, 21 Aug 1994 03:19:49 GMT Organization: The World Public Access UNIX, Brookline, MA In article , Pete Gontier wrote: >I don't think "refused" is quite the right word. I think what's going on >is that Apple is a disgusting fragmented byzantine re-organized >bureaucracy at this point. Nobody has the authority to put their foot down >and say "dammit, add floating window support to the Window Manager". Lots >of people can produce paperwork showing why it should wait until next year >when the Frobozzination Manager comes out. But nobody can put their foot >down. I put my foot down. Oh, but it doesn't seem to have done any good :-) Too bad the only PC company to come along in the last 10 years to offer something useful died (well, sort of, it's not dead yet). NeXT of course. We could all have been 5 years ahead of the game had NeXT pinned Apple and MS against the ropes. -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Sun, 21 Aug 1994 03:26:00 GMT Organization: The World Public Access UNIX, Brookline, MA In article <9668AA7AE24F.450EE@klkmac004.nada.kth.se>, Jon W{tte wrote: >However, I have this feeling people are not going to use this >floating WDEF, since the title bar is too bloody large for most >floating pallette uses - Apple says that's to make it easier to >hit for newbies, but to me, that seems less important than real >productivity for real users... Why couldn't they just have bought Troy's cool Windoid (or done their own, if they disliked the idea of anyone ever knowing that Apple ever had anything to do with something that was, gasp, free with source code) and added a "Windows" control panel that let users set the height of stupid title bar? Users who need BIG title bars could click the BIG TITLE BAR button, and users who need tiny title bars could click the tiny title bar button, and super expert users could enter a measurement (in centimeters or inches, NOT pixels) into a little text field. The modifications to the windoid to make its title bar's height adjustable would have been miniscule, and would have made the UI adaptable to the particular needs of individuals with minimal impact on overall consistency. -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Sun, 21 Aug 1994 03:30:46 GMT Organization: The World Public Access UNIX, Brookline, MA In article <1994Aug19.215703@west.cscwc.pima.edu>, <103t_english@west.cscwc.pima.edu> wrote: >I think that it is obvious that 7.5 is a rush-job. Aside from AppleScript, >AOCE, GX nad one or two other exceptions, the new stuff in 7.5 all appears to >be licensed from 3rd parties and included as is without any attempt to make it >more System 7-ish. With all those 3-rd party ideas included in sys 7.5, why, oh why, couldn't they have included drop-down menus and stick-up menus? It would have made life so much easier on my tired hands (that have to click, hold, and drag to access a menu command, a very very bad thing from a human engineering POV). -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. +++++++++++++++++++++++++++ >From sanford@CS.Arizona.EDU (Sanford H. Selznick) Date: 20 Aug 1994 20:21:36 -0700 Organization: University of Arizona CS Department, Tucson AZ In article , [poof!] >... In the end, I don't think users really care if their >buttons are 3-D shadowed, or if they're rounded, square, or whatever. >They just want software that's useful or fun, or that, at a minimum, >marketing can convince them to buy. It doesn't really matter if it's a >mac, a windows, a car, a dog, or a cat. So this actually brings up an important point. Is the mac supposed to be a computer to _buy_ or a computer to _use_? Is there a happy medium? I say yes, but not when you put mail software under the special menu and Shut Down in the Apple menu. What percentage of macs end up on a network anyway? (Does it even do POP3?) The transition from 6 to 7 added a lot of good features. The transition from 7 to 7.5 adds too many bells and whistles for my taste. As I bring up yet one more point in the same breath... When I'm not in school or working for the U, I do independent consulting. One thing I can always count on is macintosh consistency. I can sit down at any mac and know my way around. The users (once they get good, and they do so rather quickly) see this too. And that too is a selling feature they they can talk about to their friends. Different is good. Different with efficiency is even better. IMHO, Sanford +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Sun, 21 Aug 1994 03:43:35 GMT Organization: The World Public Access UNIX, Brookline, MA In article , Robert Mah wrote: >Human interface design should pay more attention to new perspectives in >the fields of psycology, sociology, cognition, perception, linguistics, >learning theory, etc. than the computer and software field. These "soft" >fields are much more important, because the purpose of human interface >design is to mold the machine (or software) the person. A better under- >standing of human behaviour will lead to better designs. Ok, here's the new alert for deleting a locked file: "While it's ok to delete a locked file, you should remember that this does not deal with the more basic problem of why the file is locked. Merely deleting this file will not solve your problems, which arrise out of years of neglect and rejection. ----------------- -------------------- ---------------- | Call My Shrink | | Load Caring Mother | | Please Help Me | ---------------- -------------------- | Understand My | | Inner Child | ---------------- " Sorry, I couldn't resist it. I do agree with Rob, though. Boy, this thread is so much fun. I haven't posted so many stupid and irrelevant things since, uh, oh I don't know. -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. +++++++++++++++++++++++++++ >From rmah@panix.com (Robert Mah) Date: Sun, 21 Aug 1994 05:55:39 -0500 Organization: One Step Beyond ari@world.std.com (Ari I Halberstadt) wrote: ) Ok, here's the new alert for deleting a locked file: ) ) "While it's ok to delete a locked file, you should remember that this ) does not deal with the more basic problem of why the file is locked. ) Merely deleting this file will not solve your problems, which arrise ) out of years of neglect and rejection. ) ) ----------------- -------------------- ---------------- ) | Call My Shrink | | Load Caring Mother | | Please Help Me | ) ---------------- -------------------- | Understand My | ) | Inner Child | ) ---------------- Damn that's funny! I'm not quite sure _why_ I thought it was so funny.. ..maybe it has something to do with supressed memories of my childhood.. Cheers, Rob _____________________________________________________________________ Robert S. Mah Software Development +1.212.947.6507 One Step Beyond and Network Consulting rmah@panix.com +++++++++++++++++++++++++++ >From Jaeger@fquest.com (Brian Stern) Date: 21 Aug 1994 12:48:46 GMT Organization: The University of Texas at Austin, Austin, Texas In article , rmah@panix.com (Robert Mah) wrote: > Jaeger@fquest.com (Brian Stern) wrote: > > ) Let me add a bit of grist to this mill. It is simply not true that icons > ) on the Mac are always used as nouns. This is true in the Finder where > ) icons represent files, and in Resedit. The icon buttons used in graphics > ) programs indicate something like 'change the cursor to a pencil tool' or > ) 'change the cursor to the paint bucket tool'. Icon buttons are a hybrid > ) between icons and buttons. All buttons act as verbs, including icon > ) buttons. I don't think there is ever a confusion between icons-as-nouns > ) and icons-as-verbs. The drop shadow > > To you, the programmer, the pencil icon may mean, "change internal mode to > kPencilToolMode", but to the user it means, "I wanna use the pencil now". > That is, the icon is a graphical representation of a tool, a thing. That > this "thing" doesn't actually exist is not relavent. I.e. when I talk > about nouns-vs-verbs, I'm looking at the icons from the user's viewpoint. > > Icon buttons, without text are, IMO, not good, because they try to represent > actions as icons. Same problem as MS-style toolbars. > > Cheers, > Rob > _____________________________________________________________________ > Robert S. Mah Software Development +1.212.947.6507 > One Step Beyond and Network Consulting rmah@panix.com All buttons represent verbs; if you click a button then some action occurs. Buttons also have some information on them to help you remember the action associated with them. In the traditional case this is in the form of words, in the case at hand it is little pictures. I agree that we should look at this from the user's perspective. Clicking on the pencil button does mean 'use the pencil now', and that's an action, not a noun. If a graphics program was to maintain the Finder's paradigm of 'select a file and then select an action to be done to that file', there would be a tool palette that had some number of tool icons on it. To change the current tool to the pencil the user would select the pencil icon in the tool palette and then choose a menu item or hit a standard button that said something like 'use selected tool'. This could work but would probably be less convenient than the icon-button approach. The fact that these buttons have icons on them is an implementation detail. I think that you're seeing them from a programmer's perspective. I doubt that many users think of these as icon-buttons. They're merely buttons. I don't believe that there is any confusion between the pictures on these buttons and the pictures that the Finder shows you. Everyone knows that clicking on a button does something. The hard part is remembering or figuring out what a particular button does. I agree that excessive use of icon-buttons causes problems (see your physician or clergyman for treatment:) I don't agree that this has anything to do with nouns or verbs. The problem is that when you have a whole slew of them it's very hard to remember what they all do. One of the most important strengths of the Mac interface is the way that it's easy to remember how things work. When people say that the Mac interface is intuitive what they really mean is that things are 'easy to remember'. Intuitive really means 'easy to figure out'. Icon buttons are usually not 'easy to remember' and they're often not 'easy to figure out' either. -- Brian Stern :-{)} Jaeger@fquest.com +++++++++++++++++++++++++++ >From rmah@panix.com (Robert Mah) Date: Sun, 21 Aug 1994 14:47:56 -0500 Organization: One Step Beyond Jaeger@fquest.com (Brian Stern) wrote: ) ) All buttons represent verbs; if you click a button then some action occurs. Yes, I'll agree with this. However, tool palettes as commonly used in graphics apps are not like normal buttons because they stay hilited over time. Normal buttons initiate an action and then return to their unhilited state immediately (or should). But leaving that asside for now, you raise an interesting point... ) Clicking on the pencil button does mean 'use the pencil now', and ) that's an action, not a noun. If you point to the pencil tool icon and ask users, "what is that?" Most usrers will not say, "that's the button that turns on the pencil tool". They will say, "that's the pencil tool". That icon has taken on the meaning of that tool. It is a word, expressed as a heiroglyph that represents the tool, "pencil", in the mind of the user. In short, a noun. Turning that around, if you ask, "what does that do?", then they may say, "it lets me use the pencil". The reason for this seeming dichotomy is the question itself. The second question was phrased in a manner that elicits a functional responce instead of a descriptive one. This can be easily turned around and used to "proove" that a common soft- ware "verb" is actually a "noun". Point to the a scroll bar in a window and ask, "What is that?". Which could easily lead to a responce such as, "That's a scroll bar". Then again, ask, "What does this do?" and you, of course, get, "It makes the text move up and down". It's all a matter of perspective and language. ) I agree that excessive use of icon-buttons causes problems (see your ) physician or clergyman for treatment:) I don't agree that this has ) anything to do with nouns or verbs. The problem is that when you have ) a whole slew of them it's very hard to remember what they all do. ) [...] ) Icon buttons are usually not 'easy to remember' and they're often not ) 'easy to figure out' either. One point in differentiating between "noun" icons and "verb" icons is that a standard vocabulary is much easier to build with "noun" icons. That is why, in fact, a small one already has. It's easier because "nouns" are often used to represent software-things which one can easily represent with a picture of a similar real-world analogue. Verbs, however, by their very nature are more ephemeral. They are not as easily represented by pictures, and in fact, some designers have taken to using pictures of _things_ to represent _actions_. E.g. printer icon buttons to print documents. This is NOT the same as the use of printer icons in Quickdraw GX on the desktop. Here, they are used to represent things...a destination that prints documents. So, it fits within the overall scheme of the Finder. So, finally, I would like to stress that it's not toolbars, per se, that bother me, it's the gratuitous use of babbeling icons to represent actions (i.e. verbs) without regard for standardization. The icons used in these buttons ARE a written language. Just as ancient Egyptian hieroglyphics is a written language. But a language needs a commonly recognized vocabulary to be decipherable. Until we have one, I feel that it is almost always more appropriate to use the local language of choice. Cheers, Rob _____________________________________________________________________ Robert S. Mah Software Development +1.212.947.6507 One Step Beyond and Network Consulting rmah@panix.com +++++++++++++++++++++++++++ >From Jaeger@fquest.com (Brian Stern) Date: 21 Aug 1994 21:02:27 GMT Organization: The University of Texas at Austin, Austin, Texas In article , rmah@panix.com (Robert Mah) wrote: [snip] > So, finally, I would like to stress that it's not toolbars, per se, that > bother me, it's the gratuitous use of babbeling icons to represent actions > (i.e. verbs) without regard for standardization. > > The icons used in these buttons ARE a written language. Just as ancient > Egyptian hieroglyphics is a written language. But a language needs a > commonly recognized vocabulary to be decipherable. Until we have one, I > feel that it is almost always more appropriate to use the local language > of choice. > > Cheers, > Rob > _____________________________________________________________________ > Robert S. Mah Software Development +1.212.947.6507 > One Step Beyond and Network Consulting rmah@panix.com I think what this comes down to is problems with the replacement of text with graphics. Consider the icons (or pictographs) at the tops of the reply windows in NewsWatcher and Eudora. In these cases icons are used to replace the text in checkboxes. The Newswatcher one works for me because there are only three icons. Interestingly, the Send function is accomplished by a standard pushbutton with text in it. The icons in Eudora's reply window never worked for me because I never could figure out what they all meant and I only used the program occasionally. Consider also the icons in alert boxes. These can't be manipulated in any way. They just convey the meaning of 'Warning' or 'here's something you should know'. This works because there are relatively few different alert icons. Imagine a program with a different alert icon for each error message. So what we're seeing is the replacement of text with graphics in a number of places. I do agree that it is usually more difficult to describe a verb with a graphic than it is to describe a noun with a graphic. I think, again, that the problem is one of ease of remembering and ease of figuring out. OTOH, what about command key equivalents. At first blush it would seem that pictures are better at describing actions than random letters. However, noone complains that command key equivalents are 'bad'. I guess part of it is that you can always look up the meaning of a command key equivalent by pulling down the menus, and another part is that they are completely unobtrusive if you don't use them. I think you're right that there needs to be some standardization [hey we got back to the title of this thread] of icons for use in place of text. It won't be easy though. And tool palettes are too sexy for most developers to think twice about not implementing them wherever they can. -- Brian Stern :-{)} Jaeger@fquest.com +++++++++++++++++++++++++++ >From heilmayr@uclink.berkeley.edu (Klaus) Date: 21 Aug 1994 23:16:27 GMT Organization: Parentheses and Ellipses In article tgaul@halcyon.com (Troy Gaul) writes: > As for the comments about the design of the new AppleCD Audio Player, I > don't find that as offensive as some of the other people who've commented > on it. The main reason I feel this way is that this is what I'll call a > 'consumer interface' program (it's designed to look more like a 'real' CD > Player's control panel). When you're playing a CD, you see a lit-up "pause" control. When you have a CD paused, you see a lit-up "play" control instead. Rather unlike a 'real' CD player, in which the lit-up control is the one that's currently active (e.g. when you're playing a CD, the "play" control is lit up). This violates another principle of user interface design: If you make changes to an interface, those changes should be obvious. You should never have a familiar-looking interface element perform an unexpected function. -Klaus (heilmayr@math.berkeley.edu) +++++++++++++++++++++++++++ >From hvoth@news.etc.bc.ca (Herb Voth) Date: Mon, 22 Aug 1994 03:09:38 GMT Organization: Ministry of Education The way I see this button problem is this: -MS basically duplicated all their menu and key combo features in buttons. This can never be intuitive because there are too many options to remember. Whoever decided that we needed a 'cut' button was more interested in the gee whiz MTV factor than productivity. The fact that MS has advertised the hell out of it, calling it productive does not make it so. -MS changed the metaphor that was introduced with MacPaint where buttons basically changed the context of editing a document. The buttons were more like tools. MS decided that menus were dumb and has basically made them redundant rather than complementing them the way MacPaint did. -Programs are getting so feature rich that MS's metaphor of implementing all features in buttons is a diminishing return, very short-sighted interface. Having 15 button bars is not productive, it just sells 21" monitors. -People (who pay our salaries, of course) want buttons. So, we must implement them. For them to be useful, they must be customizable. And, *most importantly* they must be able to be hidden. As such, they must be only one way of accessing each feature. I hate it when I have to turn on a button bar just to access a feature. -How about a button bar that appears when you press CTRL? -Randall -- +++++++++++++++++++++++++++ >From hanrek@cts.com (Mark Hanrek) Date: 22 Aug 1994 04:25:07 GMT Organization: The Information Workshop In article , ari@world.std.com (Ari I Halberstadt) wrote: > For me, it's not 7.5. It's the pathetic state of the APIs and > documentation. Who wants to spend their life looking through 16000 > pages? There is no reason the OS needs to be that complicated. And no, > a legacy OS is not a reason for rampant complexity. And OpenDoc is > only going to make it worse. Oh ya, and six (SIX!!!) books for QDGX. > Geesh. > > And then, there are the development tools. We all know what sorry > state they've been in and continue to be in. And the pathetic > languages used for development (this isn't a mac-only problem; none of > this is a mac-only problem). Ari, I agree with your assessment 100%. I have come to discover that one of the reasons things are this way is because programmers aren't as demanding as they could/should be. A majority accept things too easily, and adapt to the way things are too easily. Often, programmers figure that if they don't understand something, it is their fault, and then won't say anything. Our tools ARE pretty crummy, yet look at the amazing and sophisticated things we create with them routinely for others. Why don't we want tools that are equally sophisticated? Why do we put ourselves through building fine creations with just a screwdriver and a hammer? :) - --- It reminds me of the "typical" mechanic, who can fix and tweak your car and make it sing, but his car runs like ****. :) Likewise, programmers build the eWorlds, and the First Class BBSs, and slick collaborative groupware for those how know it is a competitive must... ... but for some reason programmers find the less-than-primitive nature of the internet newsgroup to be "just fine" for discussing sophisticated technologies and rearing their young. Amazing, ain't it? Mark Hanrek The Information Workshop +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Mon, 22 Aug 1994 09:24:36 +0200 Organization: Royal Institute of Something or other In article , Jaeger@fquest.com (Brian Stern) wrote: >Clicking on the pencil button does mean 'use the pencil now', and that's >an action, not a noun. If a graphics program was to maintain the Finder's Now it's getting interesting. Clicking on a pencil BUTTON would mean "use the pencil now" which is giving a command. However, picking up a pencil from a palette (toolbox) would be akin to doing just that, physically, in the real world; picking up a pencil out of a toolbox, and there the pencil tool is most definately a noun. These are two ways of using icons that differ subtly. I hope that subtlety doesn't get lost in a noise of toolbars... Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Not speaking for the Microsoft Corporation. +++++++++++++++++++++++++++ >From siddoway@ee.utah.edu (Derick Siddoway) Date: 22 Aug 1994 07:58:52 GMT Organization: University of Utah In article ari@world.std.com (Ari I Halberstadt) writes: > Here's my schpiel: computers suck. They all suck. Spiel? That's my *mantra*. - --------- Derick H. Siddoway __o If you stew cranberries like siddoway@ee.utah.edu _>\<,_ applesauce, they taste much University of Utah (_)/ (_) more like plums than rhubarb Department of Electrical Engineering does. - (Groucho Marx) - +++++++++++++++++++++++++++ >From Jaeger@fquest.com (Brian Stern) Date: 22 Aug 1994 11:25:06 GMT Organization: The University of Texas at Austin, Austin, Texas In article <9668AA7E1F54.3CFD6E@klkmac014.nada.kth.se>, h+@nada.kth.se (Jon W{tte) wrote: > In article , > Jaeger@fquest.com (Brian Stern) wrote: > > >Clicking on the pencil button does mean 'use the pencil now', and that's > >an action, not a noun. If a graphics program was to maintain the Finder's > > Now it's getting interesting. > > Clicking on a pencil BUTTON would mean "use the pencil now" > which is giving a command. > > However, picking up a pencil from a palette (toolbox) would be > akin to doing just that, physically, in the real world; picking > up a pencil out of a toolbox, and there the pencil tool is most > definately a noun. > > These are two ways of using icons that differ subtly. I hope > that subtlety doesn't get lost in a noise of toolbars... > > Cheers, > > / h+ > > > -- > Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden > Not speaking for the Microsoft Corporation. In thinking about this some more, and looking at a graphics program, I've realized that some of these tool pallettes are actually groups of radiobuttons. You have a bunch of choices, from which you can only choose one, and that selection remains hilited. Choosing one changes the channel, if you will. So all three of the standard Mac text-based controls can also be rendered graphically: pushbuttons, radiobuttons, and checkboxes. (Scrollbars were always graphical.) Most of the graphics on word-processor toolbars are pushbuttons, with the exception of a few radiobuttons. Things like line spacing and text justification are really radiobuttons, and these properties are really adjectives: singlespaced, left justified etc. I don't think that there is much confusion about this noun/verb/adjective thing, however. For one thing the pushbutton analogues are drawn as buttons; they have a drop shadow and they move when pushed. The graphical checkboxes in Newswatcher and Eudora check and uncheck themselves when clicked. The graphical radio buttons hilite one of the choices at all times and change in an obvious way when clicked. The fact that these are implemented as icons really isn't important, because they really do look different and act differently from each other enough so that the user can intuitively figure out how they work. The problem is the difficulty in figuring out what a particular graphic represents without having the text as a reminder. Perhaps liberal use of ballon help would give us the best of both worlds. -- Brian Stern :-{)} Jaeger@fquest.com +++++++++++++++++++++++++++ >From Willie Abrams Date: 22 Aug 1994 13:36:19 GMT Organization: OU Health Sciences Center In article <3331t7$rc8@falcon.bgsu.edu> bgsuvax, dnebing@andy.bgsu.edu writes: > Take for example Word's toolbar that can be found in most of >their apps now and can also be found in other vendor's apps >(i.e. CodeWarrior). The HIGs never evolved to encompass >toolbars, hence the thread that started here some time back >about toolbar icons representing nouns or verbs, and which >was appropriate. Toolbars are not cool, or good, or even mildly redeeming. Come on, please, the goal of any good UI is to get the hell out of the users way so that they can get their work done. The icons in Toolbars don't make sense. They aren't consistent. And why do I need a toolbar icon to save, open or cut, copy, paste, etc. Ugh. I don't highlight an icon in the Finder and click on a "copy" icon, why the heck should I want to in a word processor or compiler. Toolbars are not quickly removed or added, rarely are they resizeable, and they almost always go horizontal. (Damnit, most monitors are landscape oriented - now I have to decrease even further my vertical space? No.) I can't move'm, reshape them, nor can I tell what is going on in my compiles without it being there. And from the looks of it, Word 6 with all of its damn toolbars, will be better known as "Honey, I shrunk the document window!" Willie Abrams willie-abrams@uokhsc.edu Telemedicine Software Guy OU Health Sciences Center It's a classic Pincer's Movement. It can't fail against a ten-year-old! +++++++++++++++++++++++++++ >From pcastine@prz.tu-berlin.de (Peter Castine) Date: Mon, 22 Aug 1994 15:51:32 GMT Organization: Process Control Center In article , gurgle@dnai.com (Pete Gontier) wrote: > > While most programmers have followed the guidelines, there > > are several apps out there that have had to break the HIGs > > in order to do what was necessary. > > Examples being? How about Pop-Up menus. Was a time, there was no such thing in HIG. I seem to remember seeing them for the first time in dBase for Mac. Several developers followed suit, the idea caught on, and pop-ups were canonized in the HI chapter of IM IV. Hierarchical submenus were also officially introduced in IM IV, but I'm sure that a couple of apps had introduced this trick before it was ``canonized''. Same for tri-state checkboxes. There's a human interface note that acknowledges the appropriateness of tri-state objects and discusses the solution used for menus that show state information (to wit, the Labels menu in the Finder when the selected objects have different labels). The note does not directly deal with the solution found in Microsoft products, which, IMHO, is at least as good as the suggestion proposed in the note. Facit: The Human Interface needs to grow (cf. _Macintosh Human Interface Guidelines_, pp 38-40). As the book says, changes should be made _cautiously_, with user testing and a sense of aesthetic compatibility with the existing interface elements. There should be compelling reasons for developing a new interface element. Changes should not be made arbitrarily. -- Peter Castine | C (n.): A programming language that is sort of pcastine@prz.tu-berlin.de | like Pascal except more like assembly except Process Control Center | that it isn't very much like either one, or Technical University Berlin | anything else. -- Ray Simard +++++++++++++++++++++++++++ >From dnebing@andy.bgsu.edu (bgsuvax) Date: 22 Aug 1994 16:46:48 GMT Organization: Bowling Green State University Willie Abrams writes: > > Toolbars are not cool, or good, or even mildly redeeming. > Come on, please, the goal of any good UI is to get the hell > out of the users way so that they can get their work done. For some of the Word commands they do act as shortcuts, and they increase my productivity in those situations. > > The icons in Toolbars don't make sense. They aren't consistent. > And why do I need a toolbar icon to save, open or cut, copy, > paste, etc. Ugh. I don't highlight an icon in the Finder and > click on a "copy" icon, why the heck should I want to in a > word processor or compiler. Yes, icons for cut & paste are pretty pointless. But the beauty behind Word's toolbar is that it is *CUSTOMIZABLE*. You can take out the 'Save' icon and replace it with a 'Save As' icon (for which there is either no keyboard command equivalent or it is so esoteric that I can't ever remember it). I don't set up the buttons for simple commands which the keyboard equivalents are easily remembered. I have buttons for the ones that are (somewhat ;-) cryptic. Granted, my settings would confuse a newbie and also the icons that I have set for the command hardly leave a clue as to what the command is, but for me they make sense. > > Toolbars are not quickly removed or added, rarely are they > resizeable, and they almost always go horizontal. (Damnit, > most monitors are landscape oriented - now I have to decrease > even further my vertical space? No.) > These features are customizable in Word. Verticle on either side is OK. > I can't move'm, reshape them, nor can I tell what is going on > in my compiles without it being there. > Maybe they don't make alot of sense in CodeWarrior (I haven't seen them yet... ;-) That doesn't mean they don't have a place in UI design. > And from the looks of it, Word 6 with all of its damn toolbars, > will be better known as "Honey, I shrunk the document window!" And if the toolbars are similar to the 5.1 version, then they will not only be customizable but hideable also. That means that if you don't want to see 'em you can make 'em go away. Now don't get me wrong, I am not a big MS fan. I think they are a huge Goliath that will fall to a smaller David (Apple? ;-) someday. But the goal of this thread was to discuss the HIGs and why Apple was abandoning them in 7.5. I brought up the toolbar thing because there is a market for them, and the HIGs don't cover toolbars (yet?). Dave ============================================================ Dave Nebinger dnebing@bgsuvax.bgsu.edu Network Manager, Biology Dept. dnebing@opie.bgsu.edu Bowling Green State University dnebing@bgsuopie (bitnet) Bowling Green, OH 43403 #include *THE* alt.sources.mac supporter! +++++++++++++++++++++++++++ >From sichase@csa5.lbl.gov (SCOTT I CHASE) Date: 22 Aug 1994 15:37 PST Organization: Lawrence Berkeley Laboratory - Berkeley, CA, USA In article , pcastine@prz.tu-berlin.de (Peter Castine) writes... > >As one example, I was looking at the new(ish) AppleCD Audio Player. The >only reason I even tried clicking on the little green triangle in the >lower left corner was because I knew that the fore-runner software had a >track list and I was sure that the newer software _must_ have a track list >somewhere. I looked in the menus, to no avail, so I started clicking >around and the mouse finally landed on said triangle. Voila! Success at >last! > >So, in short: yes, this bothers me. Who else? Me! I just discovered this last night. I was helping a friend set up her 840 AV. Having never used an AV Mac before, I was having fun playing with all the neat tools. I fooled around with the AppleCD Audio Player for at least 15 minutes before I accidentally, at random, hit that little green triangle. That's a button? Jeez. -Scott - ------------------ Physics is not a religion. If Scott I. Chase it were, we'd have a much easier SICHASE@CSA2.LBL.GOV time raising money. -Leon Lederman +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 22 Aug 94 16:44:49 MST Organization: (none) In article <33a9kj$504@romulus.ucs.uoknor.edu>, Willie Abrams writes: > In article <3331t7$rc8@falcon.bgsu.edu> bgsuvax, dnebing@andy.bgsu.edu > writes: >> Take for example Word's toolbar that can be found in most of >>their apps now and can also be found in other vendor's apps >>(i.e. CodeWarrior). The HIGs never evolved to encompass >>toolbars, hence the thread that started here some time back >>about toolbar icons representing nouns or verbs, and which >>was appropriate. > > Toolbars are not cool, or good, or even mildly redeeming. > Come on, please, the goal of any good UI is to get the hell > out of the users way so that they can get their work done. > > The icons in Toolbars don't make sense. They aren't consistent. > And why do I need a toolbar icon to save, open or cut, copy, > paste, etc. Ugh. I don't highlight an icon in the Finder and > click on a "copy" icon, why the heck should I want to in a > word processor or compiler. > The only place where "Toolbars" make sense is where they have always been: rulers -a convenient way to control lots of little options that can change drastically depending on where you are in your document. Rulers (toolbars) in this case allow you to not only control the parameters of the document but also get visual feedback as to what they are. The only other use that makes sense, H-I-wise, is when you use a certain menu-item a LOT that happens to be nested deep in a hierarchical menu. THEN you want it to appear on the toolbar because it is more convenient than using the menu, and is more consistent that rearranging the menu-order to suit your whim for what may be a specialized need in a specific document. Hmmm... Does Word even allow document specific toolbars? Lawson +++++++++++++++++++++++++++ >From chuck@molecule.Physics.Drexel.Edu (Chuck Browne) Date: 23 Aug 1994 00:16:47 GMT Organization: Drexel University (Computing Services) SCOTT I CHASE (sichase@csa5.lbl.gov) wrote: : In article , pcastine@prz.tu-berlin.de (Peter Castine) writes... : > : >As one example, I was looking at the new(ish) AppleCD Audio Player. The : >only reason I even tried clicking on the little green triangle in the : >lower left corner was because I knew that the fore-runner software had a : >track list and I was sure that the newer software _must_ have a track list : >somewhere. I looked in the menus, to no avail, so I started clicking : >around and the mouse finally landed on said triangle. Voila! Success at : >last! : > : >So, in short: yes, this bothers me. Who else? : Me! I just discovered this last night. I was helping a friend set up : her 840 AV. Having never used an AV Mac before, I was having fun playing : with all the neat tools. I fooled around with the AppleCD Audio Player : for at least 15 minutes before I accidentally, at random, hit that : little green triangle. That's a button? Jeez. That got me too! I found it totally by accident - I saw the triangle, and thought it was just a power LED, just like on a non-virtual stereo. When I accidentally clicked on it and the track list opened, I got that "Hey, this program is like Myst in the puzzles that delight" feeling... Chuck : -Scott : -------------------- Physics is not a religion. If : Scott I. Chase it were, we'd have a much easier : SICHASE@CSA2.LBL.GOV time raising money. -Leon Lederman +++++++++++++++++++++++++++ >From gewekean@student.msu.edu (Andrew Geweke) Date: Mon, 22 Aug 1994 21:26:57 -0500 Organization: Michigan State University In article <33a9kj$504@romulus.ucs.uoknor.edu>, Willie Abrams writes: > In article <3331t7$rc8@falcon.bgsu.edu> bgsuvax, dnebing@ > andy.bgsu.edu writes: > > Take for example Word's toolbar that can be found in most of > >their apps now and can also be found in other vendor's apps > >(i.e. CodeWarrior). The HIGs never evolved to encompass toolbars, > >hence the thread that started here some time back about toolbar > >icons representing nouns or verbs, and which was appropriate. > > Toolbars are not cool, or good, or even mildly redeeming. > Come on, please, the goal of any good UI is to get the hell out of > the users way so that they can get their work done. Amen. Doesn't *anybody* here like the kind of application where you get one big window to work on your document that takes up all of your monitor? (Assuming, of course, the document's natural size is at least that big? :-) > The icons in Toolbars don't make sense. They aren't consistent. > And why do I need a toolbar icon to save, open or cut, copy, paste, > etc. Ugh. I don't highlight an icon in the Finder and click on a > "copy" icon, why the heck should I want to in a word processor or > compiler. You shouldn't, obviously. Here's the major sticking point, too: Toolbars may or may not be an advantage for the first-time user. (I tend to think they aren't.) However, they are a * disadvantage* for anybody familiar with the program. Try this: Do these three things, and see which is fastest. (1) Hit a command key for a menu command. (I'm assuming you're at least a competent touch-typist). (2) Pull down the menu to that command. (3) Find the toolbar button for that command and click it. Unless the toolbar buttons are at least 40x40 pixels, I think (2) is probably faster than (3). (1) is by far the fastest. In Windows, where every last app has a different key shortcut for Cut, Copy, and Paste, toolbars may make sense; however, on the Mac, Command-X flies off my fingertips while (find the right button) -> (maneuver to the tiny button) - > (click the button) takes forever. And finally, of course, as Apple has pointed out, menus have an "infinite" height. I've got NowMenus set to automatically pull menus for me and leave them down. I shove the mouse up to the top of the screen and bang, I've got menus. It takes almost no effort at all. > And from the looks of it, Word 6 with all of its damn toolbars, will > be better known as "Honey, I shrunk the document window!" No shit. Excel 4 is already bad enough. C'mon, let's all cheer on WordPerfect! Cheers, Andrew +++++++++++++++++++++++++++ >From tgaul@halcyon.com (Troy Gaul) Date: Mon, 22 Aug 1994 23:33:18 -0700 Organization: Infinity Systems In article <9408222126.AA57236@geweke.ppp.msu.edu>, gewekean@student.msu.edu (Andrew Geweke) wrote: > Here's the major sticking point, too: Toolbars may or may not be an advantage > for the first-time user. (I tend to think they aren't.) However, they are a * > disadvantage* for anybody familiar with the program. Try this: Do these three > things, and see which is fastest. (1) Hit a command key for a menu command. > (I'm assuming you're at least a competent touch-typist). (2) Pull down the > menu to that command. (3) Find the toolbar button for that command and click > it. > > Unless the toolbar buttons are at least 40x40 pixels, I think (2) is probably > faster than (3). (1) is by far the fastest. Not true. Often, (except for the highly consistent, often used command key shortcuts like cut, copy, paste, save, etc) it is either just as fast or faster to use a menu as it is to use a key command that corresponds with it. I don't want to go into all the details here because it is described in the book _Tog On Interface_. A couple relavent quotes, from page 26: "We discovered, among other things, two pertinent facts: -- Test subjects consistently report that keyboarding is faster than mousing. -- The stopwatch consistently proves mousing is faster than keyboarding. The contradiction between user-experience and reality apparently forms the basis for many user/developers' belief that the keyboard is faster." The difference is that using the mouse to issue a command doesn't require "high-level cognitive engagement" and is in fact "boring", according to Tog. Deciding what command keys ("abstract symbols") to use is a "high-level cognitive function." He goes on to say that, "Not only is this decision not boring, the user actually experiences amnesia! *Real* amnesia! The time-slice spent making the decision simply ceases to exist." Before you argue, please read the rest of this interesting article from Tog's book. It was also in the Apple Direct (or whatever it was called then) magazine in August of 1989. Now, when you think of the action in these terms, using a toolbar to execute a command becomes a similar kind of "high-level cognitive function." This means that your mind is engaged in finding the icon that represents the action you want to perform, and the same sort of rules would seem to apply. Now, as we all know, for some common actions, key commands are actually faster than the mouse (for example, when demoing products, I've tried using key commands for undo, cut, copy and paste, and it was always much more difficult than using the keys). In a similar fashion, for those people who decide to use a toolbar, I'm sure that there are commands that they learn the positions/appearances of in a similar fashion so as to be useful. For instance, while generally against toolbars, I do use the Metrowerks toolbar to issue the Run and Preferences commands. The majority of the others go unused, though. > > And from the looks of it, Word 6 with all of its damn toolbars, will > > be better known as "Honey, I shrunk the document window!" > > C'mon, let's all cheer on WordPerfect! Which would be a good time to point out that WordPerfect has its own version of 'toolbar hell', which occurs when you lose over half of your screen if you show all of its toolbars simultaneously. However, it does so in a way that seems (to me as someone who hasn't actually _used_ the program) like a much better scheme. You basically have one bar that lets you access the others given on the type of actions you wish to perform (by name, not icon you'll notice). It doesn't really fit the definition of toolbar as is being discussed in this article, as these are sets of controls, not only icons, that are grouped for doing things like changing text font, alignment, etc. If I did much word processing, I'd try it out to see if it's as good an idea as it looks. Oh, and one last parting shot: I've noticed that other complex applications, including Photoshop, Illustrator, Freehand, PageMaker, Quark Xpress, and many others get by fine without using toolbars at all. Just think of what life would be like if every program had a toolbar, with a separate set of icons, commands, etc. (Makes me think of Windows, actually...) _troy //////// //////___Troy Gaul____________________tgaul@halcyon.com___// // // Infinity Systems // // // // Redmond, Washington // // //////____________________________________________________// +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Tue, 23 Aug 1994 12:16:59 GMT Organization: Adobe Systems Incorporated Troy Gaul writes > Oh, and one last parting shot: I've noticed that other complex > applications, including Photoshop, Illustrator, Freehand, PageMaker, Quark > Xpress, and many others get by fine without using toolbars at all. Just > think of what life would be like if every program had a toolbar, with a > separate set of icons, commands, etc. (Makes me think of Windows, > actually...) We have something called the "toolbar pact" among the Photoshop engineering team. Collectively, we will stop at nothing to prevent toolbars from creeping into the app. On the other hand the reward for adding a cool new floating palette is at least a free beer. Go figure :-) -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 Please do not change color while I am talking to you -- MC 900 Ft Jesus. +++++++++++++++++++++++++++ >From dnebing@andy.bgsu.edu (bgsuvax) Date: 23 Aug 1994 14:34:48 GMT Organization: Bowling Green State University 103t_english@west.cscwc.pima.edu writes: > > The only place where "Toolbars" make sense is where they have always been: > > The only other use that makes sense, H-I-wise, is when you use a certain > menu-item a LOT that happens to be nested deep in a hierarchical menu. THEN you > want it to appear on the toolbar because it is more convenient than using the > menu, and is more consistent that rearranging the menu-order to suit your whim > for what may be a specialized need in a specific document. > How about when an app (like Word) has so many menu items that the frequently used menu items are far down in the menu, so far that the menu has to scroll? > Hmmm... Does Word even allow document specific toolbars? > No, but you can configure it to contain customized commands. Dave (p.s. Down with MicroSoft [i.e. I am not an MS-lover!] ;-) ============================================================ Dave Nebinger dnebing@bgsuvax.bgsu.edu Network Manager, Biology Dept. dnebing@opie.bgsu.edu Bowling Green State University dnebing@bgsuopie (bitnet) Bowling Green, OH 43403 #include *THE* alt.sources.mac supporter! +++++++++++++++++++++++++++ >From dnebing@andy.bgsu.edu (bgsuvax) Date: 23 Aug 1994 14:46:32 GMT Organization: Bowling Green State University gewekean@student.msu.edu (Andrew Geweke) writes: > Try this: Do these three > things, and see which is fastest. (1) Hit a command key for a menu command. > (I'm assuming you're at least a competent touch-typist). (2) Pull down the > menu to that command. (3) Find the toolbar button for that command and click > it. > > Unless the toolbar buttons are at least 40x40 pixels, I think (2) is probably > faster than (3). (1) is by far the fastest. I have one example which will prove you wrong. On my Word toolbar, I have customized the toolbar. One of the icons I have set up as the little paintbrush, and the command associated with it is 'Insert Graphic'. There is no key command normally associated with this command. It is also far down the menu so that I have to scroll to get to it. In this situation, the icon is easy to identify and is much faster than trying to get to the menu. It is not always the case that toolbars are either good or bad. It is a personal preference, just like picking a big-blue box or a Mac. So whether you like them or you don't is not the question. How the HIGs should standardize them is the question. Dave ============================================================ Dave Nebinger dnebing@bgsuvax.bgsu.edu Network Manager, Biology Dept. dnebing@opie.bgsu.edu Bowling Green State University dnebing@bgsuopie (bitnet) Bowling Green, OH 43403 #include *THE* alt.sources.mac supporter! +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 23 Aug 1994 08:07:03 -0700 Organization: SRI International, Menlo Park, CA In article tgaul@halcyon.com (Troy Gaul) writes: >Anyway, I'd like to hear from some of the Apple people who are on the list >as to how this stuff goes on. How do these designs get into products? I >understand that there was one person in particular who did most of the >designs for the color icons when System 7 was released, why isn't there a >similar person who could enforce some amount of user interface >consistency? Apple doesn't write all of its own software. For example Apple Guide was written by a third party. That third party is the one who wrote the IDE drivers for the new computers I believe. That's just two cases that I know about. Looks like 7.5 is full of Third Party stuff. Why they didn't include your WDEF is beyond me. >//////// //////___Troy Gaul____________________tgaul@halcyon.com___// > // // Infinity Systems // > // // // Redmond, Washington // ^^^^^^^^^^^^^^^^^^^ Getting to close to the evil empire eh? Can you feel the dark side of the force? Obiwan may be your only hope. :-) Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 23 Aug 1994 08:19:51 -0700 Organization: SRI International, Menlo Park, CA In article hanrek@cts.com (Mark Hanrek) writes: >Maybe that analogy is useful in this discussion. > >Today, we can get into a 1965 Galaxie 500, or a 1994 Supra, and easily >know what to do to drive either of them. But do you know how to turn on the lights or High Beams? What about air conditioning? When ever you get into a car you never been in before it takes a while to find out where these things are and how they work. When car companies started using icons it got worse. Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From Willie Abrams Date: 23 Aug 1994 13:34:08 GMT Organization: OU Health Sciences Center In article <1994Aug23.121659.18750@adobe.com> Zalman Stern, zstern@adobe.com writes: >We have something called the "toolbar pact" among the Photoshop engineering >team. Collectively, we will stop at nothing to prevent toolbars from >creeping into the app. On the other hand the reward for adding a cool new >floating palette is at least a free beer. Go figure :-) Good. I am happy. Maybe you all can start redesigning that control palette in PageMaker. Palettes are infinitely better than toolbars as they are moveable (not just the sides of the screens), easily closed (Wow, I can click the close box to make it go away. What a concept!), and they follow function. I can sit down at about any copy of Photoshop or Illustrator and work with any users setup. This is because the palettes follow a particular function, not just any arbitrary user configuration. Toolbars were invented by Microsoft so that they wouldn't have to do palettes. I refuse to accept a copout design as standard interface, or even blessed HIG, when palettes simply work better. Willie Abrams willie-abrams@uokhsc.edu Telemedicine Software Guy OU Health Sciences Center It's a classic Pincer's Movement. It can't fail against a ten-year-old! +++++++++++++++++++++++++++ >From pat@postoffice.manassas.ibm.com (Pat LaVarre) Date: 23 Aug 1994 17:32:59 GMT Organization: Loral Federal Systems - Manassas, VA Yea. I think of a toolbar like a mini-desktop: a place where I can build my own collection of data & tools. For example, by putting a folder of aliases on the desktop, I build a widget that works a lot like the Apple menu, without mucking up the Apple menu that people generally expect. -- Pat LaVarre p.lavarre@ieee.org The ASCII punctuation set here is !"#$%&'()*+,-./ :;<=>?@ [\]^_` {|}~ +++++++++++++++++++++++++++ >From gbolsinga@aol.com (GBolsinga) Date: 23 Aug 1994 14:40:12 -0400 Organization: America Online, Inc. (1-800-827-6364) My two Cents: I don't care if there are toolbars or not. I just want to be able to get rid of them if I want (which is usually true). Greg MPI Multimedia +++++++++++++++++++++++++++ >From jonpugh@netcom.com (Jon Pugh) Date: Tue, 23 Aug 1994 18:18:23 GMT Organization: Will hack for food Mark Hanrek (hanrek@cts.com) wrote: > I have come to discover that one of the reasons things are this way is > because programmers aren't as demanding as they could/should be. > A majority accept things too easily, and adapt to the way things are too > easily. > Often, programmers figure that if they don't understand something, it is > their fault, and then won't say anything. > Our tools ARE pretty crummy, yet look at the amazing and sophisticated > things we create with them routinely for others. > Why don't we want tools that are equally sophisticated? Why do we put > ourselves through building fine creations with just a screwdriver and a > hammer? :) I think the main reason is that we are more interested in creating than complaining (except for whining on c.s.m.p of course ;). I don't know about you, but I've been under severe deadlines on my past 5 projects and don't have time to whine about the tools. I just try to find ones that work and cope with it. God, I love creating though. Jon +++++++++++++++++++++++++++ >From francis@pinza.demon.co.uk (Francis H Knight) Date: Tue, 23 Aug 1994 21:53:37 GMT Organization: Hertfordshire Mac Oasis I tend to share the majority concern for the Mac's 'disippating' human interface. I got to wondering what the simplest explanation for this state of affairs might be. Knowing what that was could provide an insight into the way to fix it. I've come to the conclusion that in the battle with Macrosoft, Apple has allowed Windows to close to a sufficiently short range that the most effective tactical ammunition now is the 'bullet point'. Most consumers seem easily swayed by what they see in the press, and a comparison of feature lists is staple fare for computer journalists. On the surface, one of the best things about System 7.5 is the bundling of MacTCP, but when you read that Chicago is slated to incorporate a TCP stack, and to be promoted as 'Internet-Ready', or some such slogan, then you could be forgiven for suspecting that Apple is now merely a reactive organisation. If there is a strategy to move out of range again, as opposed to a tactic for short-term survival, then maybe OpenDoc is it. I just hope it's not too radical for MIS types to contemplate embracing. I can imagine them fearing facing a choice between an administrative nightmare and software anarchy. UK MacUser has quotes from Microsoft who believe these fears will work in their favour. Francis +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 23 Aug 94 15:22:30 MST Organization: (none) In article <33d1e8$g64@falcon.bgsu.edu>, dnebing@andy.bgsu.edu (bgsuvax) writes: > 103t_english@west.cscwc.pima.edu writes: >> >> The only place where "Toolbars" make sense is where they have always been: >> >> The only other use that makes sense, H-I-wise, is when you use a certain >> menu-item a LOT that happens to be nested deep in a hierarchical menu. THEN you >> want it to appear on the toolbar because it is more convenient than using the >> menu, and is more consistent that rearranging the menu-order to suit your whim >> for what may be a specialized need in a specific document. >> > How about when an app (like Word) has so many menu items that the > frequently used menu items are far down in the menu, so far that the > menu has to scroll? > Nested, long [scrolling] list, same bad design, IMHO... >> Hmmm... Does Word even allow document specific toolbars? >> > No, but you can configure it to contain customized commands. > Decent. Does it allow Applscript-attachability/tinkerability to appear? > Dave > > (p.s. Down with MicroSoft [i.e. I am not an MS-lover!] ;-) > MicroSoft-lovers don't admit to their bad habits in public (from the undiscovered Notebooks of Lazurus Long) Lawson +++++++++++++++++++++++++++ >From Ross Scott Rubin Date: Tue, 23 Aug 1994 23:01:43 GMT Organization: Salomon Brothers Inc In article Chris Wysocki, wysocki@netcom.com writes: >I wholeheartedly concur. Apple has done far too little in recent >years to promote UI consistency across applications. Their reluctance >to provide standard implementations of UI features such as floating >windows, menus with multiple-modifier keyboard shortcuts, and basic >controls such as up-down arrows, sliders and progress bars have forced >developers to implement these features themselves, with varying and >sometimes inconsistent results. At the Worldwide Developers >Conference in May some Apple engineers spoke in nebulous terms about >future UI enhancements which are coming down the road, but it struck >me and others with whom I spoke as too little, too late.... An excellent response, Chris. I believe System 8 is supposed to restore consistency toward creating a Mac interface in the world beyond the black and white screen. +-- +--\ --- ---------------------------------------------------------------+ | | / | Ross Scott Rubin | Internet: rrubin@sbi.com | +-+ +-< | Salomon Brothers, Inc.| AOL, eWorld: rossrubin | CIS:72137,2627 | | | \ | "Opinions are mine alone. Who else would admit to them?" | --+ +--/ --- ---------------------------------------------------------------+ +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 24 Aug 1994 01:11:25 GMT Organization: Apple Computer netcom.com!kira!davidjohn, writes: > Individually, many of these don't look that bad, I suppose (but, that's > another issue, really). However, as I recall, one of the advertised > strengths of the Macintosh, in past years, was its highly consistent > interface... This discussion came up after WWDC when people were playing with the beta version of 7.5. The fundamental issue is that the HI has to move forward; that the old mostly black and white interface is getting old. Future system software will have drastic changes, but there are incremental ones in 7.5. > - a strange little thing for 'post-it' notes Yeah, I wrote that. I did my own WDEF because the notes have to be tiny and inconspicuous. There used to be some shareware post-it apps that used normal WDEFs, and they looked pretty godawful. > - the Find File windows have a funky styled background So do the majority of new commercial products these days, or at least a gray background. There's no law saying all windows have to be white. > - A window that is reminiscent of the 'palette' titlebar, but with close > and zoom boxes. That's the new official palette WDEF, right in the System file. Many people do prefer e.g. the Infinity WDEF, but apparently the HI people had good reasons for making this one look the way it does. As for buttons, there are official Apple HI guidelines for 3D buttons. Check out develop issue 17 (or was it 16?) which has an article complete with pictures and sample code. > What kind of message is this > sending to developers? It seems to me it's something like, 'Sure, go ahead, > bypass the toolbox Writing new WDEFs or CDEFs is not 'bypassing the toolbox', at least not in the same sense that slamming bits onto the screen is. The Window Manager is meant to be extensible. It's hoped that one will have a good reason for using a custom WDEF, but at least in my case I feel that I did. (It would certainly have been a zillion times easier for me to use a normal WDEF; writing WDEFs from scratch is a pain.) --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From will@cs.su.oz.au (William Uther) Date: 24 Aug 1994 11:28:31 +1000 Organization: Basser Dept of Computer Sciece, Uni of Sydney, Australia In article , Troy Gaul wrote: >In article <9408222126.AA57236@geweke.ppp.msu.edu>, >gewekean@student.msu.edu (Andrew Geweke) wrote: >I don't want to go into all the details here because it is described in >the book _Tog On Interface_. A couple relavent quotes, from page 26: > >"We discovered, among other things, two pertinent facts: > > -- Test subjects consistently report that keyboarding is faster than mousing. > > -- The stopwatch consistently proves mousing is faster than keyboarding. > > The contradiction between user-experience and reality apparently forms >the basis for many user/developers' belief that the keyboard is faster." > This raises an intesting marketing point. From a purely pragmatic point of view, the software producer wants the user to like the product rather than the product actually being useful for the user. In this case pleasing the user would mean that you use keyboard commands because the user thinks they are being faster. I'm not saying I condone the practice, but I think that if one were a complete #@%*!!$@ one might act like this. \x/ill :-} will@cs.su.oz.au #include +++++++++++++++++++++++++++ >From pcastine@prz.tu-berlin.de (Peter Castine) Date: Wed, 24 Aug 1994 11:32:36 GMT Organization: Process Control Center In article <1994Aug23.121659.18750@adobe.com>, zstern@adobe.com (Zalman Stern) wrote: > Troy Gaul writes > > Oh, and one last parting shot: I've noticed that other complex > > applications, including Photoshop, Illustrator, Freehand, PageMaker, Quark > > Xpress, and many others get by fine without using toolbars at all. Just > > think of what life would be like if every program had a toolbar, with a > > separate set of icons, commands, etc. (Makes me think of Windows, > > actually...) > > We have something called the "toolbar pact" among the Photoshop engineering > team. Collectively, we will stop at nothing to prevent toolbars from > creeping into the app. On the other hand the reward for adding a cool new > floating palette is at least a free beer. Go figure :-) Question: What's the difference between a toolbar and a palette? Gee, I don't *know* the answer either. I'd suggest that a well thought-out toolbar can make sense in a UI design (actually, I have done so in other posts). Buttons as shortcuts for frequent tasks actually makes sense. However, I also find implementation in MS products unsatisfying. I think the problem is that for the activities in the toolbar, the icons are too difficult to associate with the actions. Style attributes work well enough, but Save? Undo?--as The Book says in Icons, Chapter II, Verse 28 ``Verily, I sayeth unto you, there is a time for icons and a time for text; a time to sow, and a time to reap. And he that knoweth the difference shall find a place at the HI beer bust.'' -- Peter Castine | C (n.): A programming language that is sort of pcastine@prz.tu-berlin.de | like Pascal except more like assembly except Process Control Center | that it isn't very much like either one, or Technical University Berlin | anything else. -- Ray Simard +++++++++++++++++++++++++++ >From pcastine@prz.tu-berlin.de (Peter Castine) Date: Wed, 24 Aug 1994 12:14:58 GMT Organization: Process Control Center In article <33d248$inl@falcon.bgsu.edu>, dnebing@andy.bgsu.edu (bgsuvax) wrote: > gewekean@student.msu.edu (Andrew Geweke) writes: > > Try this: Do these three > > things, and see which is fastest. (1) Hit a command key for a menu command. > > (I'm assuming you're at least a competent touch-typist). (2) Pull down the > > menu to that command. (3) Find the toolbar button for that command and click > > it. > > > > Unless the toolbar buttons are at least 40x40 pixels, I think (2) is probably > > faster than (3). (1) is by far the fastest. ~~~~~~~~~~~~~~~~~~~~~~~~~~ Do you have any studies to confirm that? There are several studies that show (2) to be the fastest in most cases. Don't believe it? Do some research (either in the lab or the library--in the library you should look up Card's work at PARC in the early 80's). > > I have one example which will prove you wrong. On my Word toolbar, > I have customized the toolbar. One of the icons I have set up as > the little paintbrush, and the command associated with it is > 'Insert Graphic'. There is no key command normally associated with > this command. It is also far down the menu so that I have to scroll > to get to it. In this situation, the icon is easy to identify and is > much faster than trying to get to the menu. Since you can configure your menus in Word pretty much however you want, there are a couple of alternatives, such as defining a keyboard shortcut for the command. However, the toolbar is not a bad solution. BTW, have you tried putting the toolbar on the right side of the screen? I've found that a much better solution. (Personal preference) -- Peter Castine | C (n.): A programming language that is sort of pcastine@prz.tu-berlin.de | like Pascal except more like assembly except Process Control Center | that it isn't very much like either one, or Technical University Berlin | anything else. -- Ray Simard +++++++++++++++++++++++++++ >From cwood@io.com (Charlie Wood) Date: Wed, 24 Aug 1994 09:12:34 -0600 Organization: Illuminati Online This discussion really hits home with me, since we have an internal user-interface war raging at my company. The problem is exaggerated by the fact that half of the development staff consists of Windows programers. No offense. I wholeheartedly agree with the low opinion of toolbars voiced here (and totally agree that MS' UI people should be locked up). I've read Tog and have seen His Way. I'm definitely a Mac purist at heart, even though I did design that one five-level-deep hierarchical popup menu with 1400 items in it. (I *swear* it was the best way! ;-) But, in reading this thread, I find myself wishing for a "Next Article" button in NewsWatcher. Yes, I can type cmd-I, but when I'm doing almost everything else with the mouse, I wish I could access this highly-repetitive function in the same way. Yes, of course I can select the menu item with the mouse, but that's not nearly as elegant as a button-click would be. However, if Peter Lewis ever adds a cut, copy, or paste button, I will become a DOS programmer just out of spite. Regards, Charlie -- Charlie Wood | Wanna see me travel into the future? cwood@io.com | Wanna see it again? +++++++++++++++++++++++++++ >From fyock@mathworks.com (Lee Fyock) Date: Wed, 24 Aug 1994 10:40:24 -0400 Organization: The MathWorks, Inc. In article <1994Aug24.011125.11263@gallant.apple.com>, Jens Alfke wrote: > > - the Find File windows have a funky styled background > > So do the majority of new commercial products these days, or at least a gray > background. There's no law saying all windows have to be white. No, there's no law... But page 258 of the Mac HIG says that "Apple's goal in adding color to the interface is to enhance meaning, not just to color things to improve aesthetics". I think that the problem (if there is one) in the Find File windows is that the background isn't a smooth gray (as kind of recommended on pg. 265), but is a gray pattern, unlike any other window background I've ever seen. > > - A window that is reminiscent of the 'palette' titlebar, but with close > > and zoom boxes. > > That's the new official palette WDEF, right in the System file. Many people > do prefer e.g. the Infinity WDEF, but apparently the HI people had good > reasons for making this one look the way it does. It scares me when people say "they must have had a good reason..." How do we know that it wasn't just some co-op? :-) > As for buttons, there are official Apple HI guidelines for 3D buttons. Check > out develop issue 17 (or was it 16?) which has an article complete with > pictures and sample code. But why weren't CDEFs included? Why aren't the CDEFs part of the system? Why isn't the progress bar documented and standard for the system? Developers are forced to write their own. Then, when Apple changes the appearance of windows or controls, those developers' apps look goofy. I remember several programs that drew their own grow icons in windows -- when System 7 came out, they were instantly dated. That's not a great example, since they shouldn't have drawn the grow boxes that way, but how about apps' floating window WDEFs? We finally have a standard, but how long have commercial apps been using their own WDEFs for floating windows? Too long... Just my 2 cents. Have fun! Lee - ------------------------------------------------------------------ Lee Fyock "I think I would remain fyock@mathworks.com perfectly still." +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 24 Aug 1994 22:34:38 GMT Organization: Apple Computer In article Robert Mah, rmah@panix.com writes: > One would expect that with Don Norman in > charge (he is in charge of HIG isn't he?) that HIG would be less worried > over the "look" and more about the "feel". That they would hire fewer > graphic designers and more people versed in psychology and sociology. Apple has a mix of both, and both types of designers are involved in products. In the 3rd party utilities I think more attention went to the appearance since that's easier to change when the code comes from somebody outside; although there were changes in behavior dictated during the process (I had to deal with several of them.) > The sticky note windows are even more bothersome. I agree that the windows are nonstandard, but I really, really didn't think I had a choice. Doing post-its with normal WDEFs looks really ugly. Just try it sometime and see what you think, or look at any of the freeware post-it programs. They suck. > Looking farther into the future, does the pre-emption of the "File" menu > with a "Document" menu in OpenDoc bother anyone? This seems to me to be > a gratuitous market decision in a vain attempt to differentiate" OpenDoc > from the current crop of applications. There were two reasons -- (1) to make it clear that the user is in an OpenDoc document and not in a traditional app; this is not just a marketing thing, since OpenDoc documents have capabilities that regular apps don't and it's important for the user to have an idea of which they're in. And (2) to get away from the document==file thing that may not be true in the future with more sophisticated data storage schemes. There is nothing that says an OpenDoc document has to live in a file. You also mentioned the problem of menubar real estate -- most of the problems in this regard happen on non-English systems (esp. German and French). In those languages the name of the File menu is already more equivalent to the English "Document" and there would not be a hit in menu size. There's room for debate here, but don't jump to the conclusion that people at Apple are idiots or totally incapable of making decisions, OK? It gets a bit tiresome debating against that attitude. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 24 Aug 1994 23:39:54 GMT Organization: Apple Computer Andrew Southwick, andrew@csgrad.cs.vt.edu writes: > This really (constantly) surprises me. THIS is the part of the human > interface that APPLE should be working on. Why do I have to create > all these controls by hand? Why has Apple refused to develop these > interface enhancements? Because there's a big difference between the HI designers designing the best way to implement a feature, and engineering actually implementing the feature in a standard portable way (e.g. a CDEF) that will be fully tested and released to developers. It's hard enough just getting the major stuff that only Apple can do out the door; usually lower-priority things like writing a date/time control either never make it to the product stage or are canceled so their resources can be transferred to larger projects. On the other hand, I think that writing these kinds of controls and things is something that'd be great for DTS to do -- they could release them with source code both as stuff for developers to take advantage of, and as sample code for how to write your own. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From absurd@apple.com (Tim Dierks) Date: Wed, 24 Aug 1994 23:45:45 GMT Organization: Apple Computer, Inc. In article <1994Aug19.031720.1465@kira.net.netcom.com>, netcom.com!kira!davidjohn (David John Burrowes) wrote: ... Comments on the user interface consistency of System 7.5 ... Elizabeth Moller of our Human Interface group wrote this response to David and asked me to post it. - - - - - - - - - David, Your comments got forwarded (several times) to me here in the AppleSoft Human Interface Design Center. I was disappointed in the quality of the HI of the System 7.5 additions. I think that some of the goodies are OK using non-standard windows (sticky notes and launcher) because the design is key to the usability. I do wish we had the appropriate items in the toolbox (especially the icon buttons), but that will have to wait. There is no HI excuse for the CD Player and the patterns in the backgrounds of the DAs. Our marketing folks felt they were appropriate. The palette (AKA utility window) titlebar is now avialable in the system. We're working hard to get our toolbox updated so we have a leg to stand on. Unfortunately consistency for the user (in the long run) doesn't seem to be a big selling point with our marketing dept. System 7.5 has made our job harder for the reasons you have pointed out. I hope there are developers out there that still believe that standard is best. Elizabeth Moller Elizabeth.M@AppleLink.Apple.COM -- Tim Dierks absurd@apple.com +++++++++++++++++++++++++++ >From kenyon@lmsc.lockheed.com (Bob Kenyon) Date: Wed, 24 Aug 1994 22:47:12 GMT Organization: Lockheed Missiles & Space Co. In article <22AUG199415370028@csa5.lbl.gov>, sichase@csa5.lbl.gov (SCOTT I CHASE) wrote: > In article , pcastine@prz.tu-berlin.de (Peter Castine) writes... > > > >As one example, I was looking at the new(ish) AppleCD Audio Player. The > >only reason I even tried clicking on the little green triangle in the > >lower left corner was because I knew that the fore-runner software had a > >track list and I was sure that the newer software _must_ have a track list > >somewhere. I looked in the menus, to no avail, so I started clicking > >around and the mouse finally landed on said triangle. Voila! Success at > >last! > > > >So, in short: yes, this bothers me. Who else? > > Me! I just discovered this last night. I was helping a friend set up > her 840 AV. Having never used an AV Mac before, I was having fun playing > with all the neat tools. I fooled around with the AppleCD Audio Player > for at least 15 minutes before I accidentally, at random, hit that > little green triangle. That's a button? Jeez. Hang on a sec. It just struck me that the little triangle is exactly analogous to the triangle that appears next to the names in the "List View" of a Finder window. When you click on those triangles, they rotate ninety degrees and the contents "spill" out. This triangle also appears in a number of other programs, one of which is InterSLIP. It's a new paradigm, but it's not unreasonable. Bob -- Bob Kenyon (bkenyon@lmsc.lockheed.com) | "It's called Windows Spacecraft Engineering & Technology | because it's a real Lockheed Missiles & Space Co., Sunnyvale, CA USA | pane." - Dave Barry +++++++++++++++++++++++++++ >From egmiller@cpcug.org (Eric G. Miller) Date: Wed, 24 Aug 1994 22:29:48 -0500 Organization: Express Access Online Communications, USA In article , cwood@io.com (Charlie Wood) wrote: > But, in reading this thread, I find myself wishing for a "Next Article" > button in NewsWatcher. Yes, I can type cmd-I, but when I'm doing almost > everything else with the mouse, I wish I could access this > highly-repetitive function in the same way. Yes, of course I can select > the menu item with the mouse, but that's not nearly as elegant as a > button-click would be. Yes, the ability to repeat the same action over and over by just clicking the mouse button (with one hand) is really great for those times when you are trying to enjoy a really slimy/greasy snack (with the other hand). Toolbars may stink but they rank well above keyboard condoms in my book. The human-computer interface is neither as time-tested nor as vital as the human-snack food interface. Perhaps what really needs more work is the computer-snack food interface... Bottoms up! - egm +++++++++++++++++++++++++++ >From Jaeger@fquest.com (Brian Stern) Date: 25 Aug 1994 05:56:52 GMT Organization: The University of Texas at Austin, Austin, Texas In article , Elizabeth.M@AppleLink.Apple.COM wrote: > David, I was disappointed in the quality of the > HI of the System 7.5 additions. I think that some of the goodies are OK > using non-standard windows (sticky notes and launcher) because the design > is key to the usability. There > is no HI excuse for the CD Player and the patterns in the backgrounds of > the DAs. Our marketing folks felt they were appropriate. The palette > (AKA utility window) titlebar is now avialable in the system. > > We're working hard to get our toolbox updated so we have a leg to stand > on. Unfortunately consistency for the user (in the long run) doesn't seem > to be a big selling point with our marketing dept. System 7.5 has made our > job harder for the reasons you have pointed out. I hope there are > developers out there that still believe that standard is best. > > Elizabeth Moller > Elizabeth.M@AppleLink.Apple.COM I guess this is a good news-bad news situation. The good news is that there ARE people at Apple who know about and care about HI. The bad news is that they are overruled by marketing types. (I had to delete some of the quoted message because my silly newsserver won't let me post messages where the new text is less than the included text.) -- Brian Stern :-{)} Jaeger@fquest.com +++++++++++++++++++++++++++ >From Willie Abrams Date: 25 Aug 1994 13:32:01 GMT Organization: OU Health Sciences Center In article Tim Dierks, absurd@apple.com writes: >David, >Your comments got forwarded (several times) to me here in the AppleSoft >Human Interface Design Center. I was disappointed in the quality of the >HI of the System 7.5 additions. I think that some of the goodies are OK >using non-standard windows (sticky notes and launcher) because the design >is key to the usability. I do wish we had the appropriate items in the >toolbox (especially the icon buttons), but that will have to wait. There >is no HI excuse for the CD Player and the patterns in the backgrounds of >the DAs. Our marketing folks felt they were appropriate. The palette >(AKA utility window) titlebar is now avialable in the system. > >We're working hard to get our toolbox updated so we have a leg to stand >on. Unfortunately consistency for the user (in the long run) doesn't seem >to be a big selling point with our marketing dept. System 7.5 has made our >job harder for the reasons you have pointed out. I hope there are >developers out there that still believe that standard is best. > >Elizabeth Moller >Elizabeth.M@AppleLink.Apple.COM > >-- >Tim Dierks >absurd@apple.com Tim, thanks for posting this one. Why isn't Elizabeth (or anyone in HIG) being heard? Is marketing truly to blame for all of this? If so, I am much more worried about the HI stuff now than when I was at WWDC. At least there, it seemed, that HI was a critical point in the entire Apple world view. What was the quote, "The user is the center of everything we do." - I hope for all of our sakes, as Apple developers, employees and users, that the quality of the Human-Machine interaction remains paramount in our minds. And, it would seem, the best group to steer and maintain that quality at Apple is the HIG, not marketing. Willie Abrams willie-abrams@uokhsc.edu Less is more. God is in the details. - Mies van der Rohe +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Fri, 26 Aug 1994 12:33:47 +1200 (NZST) Organization: (none) cwood@io.com (Charlie Wood) writes: > But, in reading this thread, I find myself wishing for a "Next Article" > button in NewsWatcher. Yes, I can type cmd-I, but when I'm doing almost > everything else with the mouse, I wish I could access this > highly-repetitive function in the same way. Yes, of course I can select > the menu item with the mouse, but that's not nearly as elegant as a > button-click would be. What are you doing with the mouse in NewsWatcher? The spacebar, or the keypad 0 work pretty well for "next article". -- Bruce +++++++++++++++++++++++++++ >From mab22@po.cwru.edu (Mike Balfour) Date: 25 Aug 1994 15:48:34 GMT Organization: Overload Engineering In article <33i6gh$sfa@romulus.ucs.uoknor.edu>, Willie Abrams wrote: > Why isn't Elizabeth (or anyone in HIG) being heard? Is marketing truly > to blame for all of this? If so, I am much more worried about the HI > stuff now than when I was at WWDC. At least there, it seemed, that > HI was a critical point in the entire Apple world view. > > What was the quote, "The user is the center of everything we do." - > I hope for all of our sakes, as Apple developers, employees and users, > that the quality of the Human-Machine interaction remains paramount > in our minds. And, it would seem, the best group to steer and maintain > that quality at Apple is the HIG, not marketing. > Well, here's a little something to consider before jumping on Apple. It could be that they're ditching some of these standards because the user wants it that way (of course, what's *best* for the user doesn't matter:). When someone's out there trying to decide which computer to buy, and they see a Mac with a CD-ROM drive with this cool window on the screen that controls it - a window that will make their computer look cool to their friends - it appeals to them. It's what they want, so they buy it. While HIG is best suited for determining how to make the machine easiest to use, marketing really is the best group for determining what the user wants, unfortunately. In my opinion, this *does* seem like a rather blind way of looking at things, 'cause the easiest-to-use machine is ultimately what the user will want, if it's done correctly. Candy features are nice, and they'll sell things, and they appeal to people, but they'll only give you empty calories and rot your teeth :). (BTW Jens, don't take offense at my calling the post-it notes that you designed "candy". I'm a chocoholic.:) To sum up: Don't jump on Apple's case too quickly. As a company, they're not here to tell us what's best for us; they're here to give us what we want, and what we ask for... Should I smiley that last sentence? MB -- - --------------------------------+-------------------------------- Mike Balfour, Partner | BS/MS Candidate - ECMP Overload Engineering | Case Western Reserve University "New Ideas for a Brighter Future" | Cleveland, OH +++++++++++++++++++++++++++ >From Willie Abrams Date: 26 Aug 1994 13:57:42 GMT Organization: OU Health Sciences Center In article Mike Balfour, mab22@po.cwru.edu writes: >While HIG is best suited for determining how to make the machine easiest >to use, marketing really is the best group for determining what the user >wants, unfortunately. In my opinion, this *does* seem like a rather blind I agree. Case in point, ideally the interaction should go like this: Marketing: The user needs to be able to do this. Engineering: We can program anything... :-) HIG: This is what the user experience should be. Not marketing deciding what interface is appropriate, and HIG not being utilized for their expertize. I am not jumping on Apple, per se, but I use and program Macs by choice. The entire user experience and consistency of the Mac is the reason I use them. The minute I start getting visually assualted by my Macintosh is the minute I start panicking. The moment I spend trying to figure out why I can't find the program list in the CD remote, or why the find file box has got a weirdo color scheme unlike the rest of Mac, is a moment lost for no good reason. Do it consistently or don't do it at all. I won't standby and watch my Mac turn into an enitre mish-mash of metaphors, visual clues, and interface elements. I will turn it off first. Willie Abrams willie-abrams@uokhsc.edu Less is more. God is in the details. - Mies van der Rohe +++++++++++++++++++++++++++ >From Hank_Gillette@smtp.esl.com (Hank Gillette) Date: 26 Aug 1994 23:05:05 GMT Organization: esl.com In article <33d248$inl@falcon.bgsu.edu>, dnebing@andy.bgsu.edu (bgsuvax) wrote: > I have one example which will prove you wrong. On my Word toolbar, > I have customized the toolbar. One of the icons I have set up as > the little paintbrush, and the command associated with it is > 'Insert Graphic'. There is no key command normally associated with > this command. It is also far down the menu so that I have to scroll > to get to it. In this situation, the icon is easy to identify and is > much faster than trying to get to the menu. But there's nothing stopping you from assigning a key command to 'Insert Graphic', since Word allows you to assign key commands to any command. Hank Gillette -- Hank_Gillette@smtp.esl.com +++++++++++++++++++++++++++ >From rmah@panix.com (Robert Mah) Date: Sat, 27 Aug 1994 00:08:29 -0500 Organization: One Step Beyond Willie Abrams wrote: ) The moment I spend trying to figure out why I can't find the program ) list in the CD remote, or why the find file box has got a weirdo color ) scheme unlike the rest of Mac, is a moment lost for no good reason. ) Do it consistently or don't do it at all. ) ) I won't standby and watch my Mac turn into an enitre mish-mash of ) metaphors, visual clues, and interface elements. I will turn it off ) first. Amen. Only on the Mac could you have the audience of a demo tell the demonstrator how to access functions that they've never seen. I've seen it happen. The reason it can happen is the interface consistency between applications. This is more than just conforming to guidelines, it also includes being aware that _other_ people may have had the same interface problem and making your solution similar to theirs. I'm afraid that Apple is losing it's way. I wonder how much the top execs actually use their Macs for more than writing memos. Cheers, Rob _____________________________________________________________________ Robert S. Mah Software Development +1.212.947.6507 One Step Beyond and Network Consulting rmah@panix.com +++++++++++++++++++++++++++ >From dnebing@andy.bgsu.edu (bgsuvax) Date: 27 Aug 1994 18:00:19 GMT Organization: Bowling Green State University Hank_Gillette@smtp.esl.com (Hank Gillette) writes: > In article <33d248$inl@falcon.bgsu.edu>, dnebing@andy.bgsu.edu (bgsuvax) wrote: > >> I have one example which will prove you wrong. On my Word toolbar, >> I have customized the toolbar. One of the icons I have set up as >> the little paintbrush, and the command associated with it is >> 'Insert Graphic'. There is no key command normally associated with >> this command. It is also far down the menu so that I have to scroll >> to get to it. In this situation, the icon is easy to identify and is >> much faster than trying to get to the menu. > > But there's nothing stopping you from assigning a key command to 'Insert > Graphic', since Word allows you to assign key commands to any command. Yes, but conceivably one could have so many keyboard commands in word that it is easy to forget what one might be. However, a familiar icon in the toolbar is hard to forget. Dave ============================================================ Dave Nebinger dnebing@bgsuvax.bgsu.edu Network Manager, Biology Dept. dnebing@opie.bgsu.edu Bowling Green State University dnebing@bgsuopie (bitnet) Bowling Green, OH 43403 #include *THE* alt.sources.mac supporter! >From eric.larson@f620.n2605.z1.fidonet.org (eric larson) Subject: Where have the standards gone? [a high level question] Date: 20 Aug 94 09:31:50 - Organization: FidoNet: Shockwave Rider, USR V.Everything +1(908)294-0659 > That said, let me add that it *is* important for UIs to develop; I'm not > going to advocate cast-in-platinum Human Interface Guidelines. The > _Macintosh Humand Interface Guidelines_ discuss the subject of ``Going > Beyond the Guidelines'' quite specifically. > So, in short: yes, this bothers me. Who else? Me too. The consistency of the Apple user interface has long been one of it's strengths. Having so many disparate design elements onscreen is quite jarring to someone really used to the standard ways of doing things. It's one thing to introduce new elements to support new technologies (OpenDoc's interface elements might well need to EXTEND the current paradigm considerably), or to replace elements when a better way becomes obvious. But it should be done in a CONSISTENT fashion. The Zoom box should be the same on EVERYTHING. The StickyNotes stuff is an abomination. +++++++++++++++++++++++++++ >From heilmayr@uclink.berkeley.edu (Klaus) Date: 29 Aug 1994 02:13:11 GMT Organization: Parentheses and Ellipses In article <1994Aug24.011125.11263@gallant.apple.com> Jens Alfke writes: > The fundamental issue is that the HI has to move forward; > that the old mostly black and white interface is getting old. What does it mean for the HI to "move forward"? Yes, the interface is getting old, but that doesn't mean it's going bad. As someone once remarked, the usual windows interface looks like an explosion in a cartoon factory. A wild jumble of colors and patterns, for no apparent reason other than to look whizzy. It's the computer equivalent of those stereo components with lots of pointless buttons and flashing lights whose only purpose is to make the box look high-tech. In fact, it just looks tacky. I think one of the reasons that graphic design professionals like to use Macs is that the Mac has an elegant interface. I'd hate to see Apple give up that elegance in the name of "moving forward." >> - the Find File windows have a funky styled background > So do the majority of new commercial products these days, or at least a > gray background. There's no law saying all windows have to be white. No, there's no law, but it violates one of the principles of user interface design: consistency. One should not change the interface unless there is a good reason for the change -Klaus (heilmayr@math.berkeley.edu) +++++++++++++++++++++++++++ >From heilmayr@uclink.berkeley.edu (Klaus) Date: 29 Aug 1994 02:23:43 GMT Organization: Parentheses and Ellipses In article mab22@po.cwru.edu (Mike Balfour) writes: > Well, here's a little something to consider before jumping on Apple. It > could be that they're ditching some of these standards because the user > wants it that way What I suspect is that it's not the current Mac users who want it that way, but the Windows users whom Apple is trying to win over. Unfortunately, making a Mac look like a Windows box isn't likely to win over many Windows users, but it'll probably alienate a lot of Mac users. Most Windows users have chosen their platform because it's the most common one, or because there are more applications (especially games) available for it. Most Mac users have chosen their platform because of its elegant and consistent interface. Making the Mac more like a Windows box won't really give the Windows users any reasons to switch, but it may well make some Mac users decide that there's no reason to stick with the Mac. -Klaus (heilmayr@math.berkeley.edu) --------------------------- End of C.S.M.P. Digest **********************