From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-030 Date: Wed, 25 May 94 10:42:16 MET DST C.S.M.P. Digest Wed, 25 May 94 Volume 3 : Issue 30 Today's Topics: Apple's blatant disregard for User Interface Guidelines List Manager clikLoop problem... but whose it? Opening a file with C standard i-o routines Sym CDK vs CodeWarrior PPC: first impressions Where is the inheritance in AE objects? [Q] How to prevent _DragWindow from selecting the window? [Q] casting Str255 <--> (char*) 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 as comp.sys.mac.programmer.src. ------------------------------------------------------- >From jjvbl@lhdsy1.lahabra.chevron.com (John V. Blzka) Subject: Apple's blatant disregard for User Interface Guidelines Date: 2 May 94 15:26:59 GMT Organization: Chevron, La Habra, CA Hello, I've been working on a presentation on Human Factors Engineering. I am using Apple's User Interface Guidelines as an example. What I would like to know is: Does Apple violate it's own Guidelines in any of it's System 7 software? If so, can I easily demonstrate it? Thanks in advance, John jjvbl@chevron.com -- =================================================================== John Blyzka | jjvbl@chevron.com "the BLITZ" | "only the good die young" +++++++++++++++++++++++++++ >From cwiltgen@mcs.com (Charles Wiltgen) Date: Tue, 03 May 1994 19:54:07 -0600 Organization: Lederhosen 'R' Us - Worldwide Leaders in Lederhosen In article <16674@lhdsy1.lahabra.chevron.com>, jjvbl@lhdsy1.lahabra.chevron.com (John V. Blzka) wrote: > Hello, > I've been working on a presentation on Human Factors Engineering. > I am using Apple's User Interface Guidelines as an example. > What I would like to know is: > Does Apple violate it's own Guidelines in any of it's System 7 > software? > If so, can I easily demonstrate it? How 'bout dragging a disk to the trash to eject it? -- Charles Wiltgen "Love is a snowmobile racing across the tundra and cwiltgen@mcs.com then suddenly it flips over, pinning you underneath. (INTP) At night, the ice weasels come." - Nietzsche (Groening) World Wide Web http://venus.mcs.net/~cwiltgen/home.html +++++++++++++++++++++++++++ >From rmah@panix.com (Robert S. Mah) Date: Tue, 03 May 1994 21:57:11 -0500 Organization: One Step Beyond cwiltgen@mcs.com (Charles Wiltgen) wrote: > jjvbl@lhdsy1.lahabra.chevron.com (John V. Blzka) wrote: > > > I've been working on a presentation on Human Factors Engineering. > > I am using Apple's User Interface Guidelines as an example. > > What I would like to know is: > > Does Apple violate it's own Guidelines in any of it's System 7 > > software? If so, can I easily demonstrate it? > > How 'bout dragging a disk to the trash to eject it? That is, in fact, a wonderful example of the _process_ of iterative user interface design. Complete with pragmatic compromises and soul searching about paradigm stability and all that. There was a thread over in comp.human-factors about this where one of Apple's Human Interface people stopped by and asked for suggestions. The winner got a T-shirt. Suffice it to say that no one could come up with anything better, given the constraints at hand. It's a pretty damn tough problem. Cheers, Rob ___________________________________________________________________________ Robert S. Mah -=- One Step Beyond -=- 212-947-6507 -=- rmah@panix.com +++++++++++++++++++++++++++ >From pcastine@jake.prz.tu-berlin.de (Peter Castine) Date: Wed, 4 May 1994 11:13:39 GMT Organization: PRZ TU-Berlin jjvbl@lhdsy1.lahabra.chevron.com (John V. Blzka) asked: >> Does Apple violate it's own Guidelines in any of it's System 7 >> software? >> If so, can I easily demonstrate it? cwiltgen@mcs.com (Charles Wiltgen) replied: >How 'bout dragging a disk to the trash to eject it? Although the semantics and history of this gesture have been much debated, I find myself asking "What Human Interface Principle does this violate?" It certainly supports the principles Direct Manipulation, See-and-Point, and User Control. Admittedly, it weakens the metaphor of trashcan- as-device-of-destruction, but since that's not what the trash can is (it's more a metaphor of device-to-get-things -off-my-desktop) and metaphors are meant to be *extensible* ("Metaphors in the computer interface suggest a use for something, but that use doesn't define or limit the implementation of the metaphor", _Macintosh Human Interface Guidelines_ p. 5), that's not really the problem. In short, although dragging a disk to the trash (as an alternative to the Put Away command) may seem to be a strange gesture, it's not a violation. As far was the original question is concerned, you can find a number of violations if you want to nit-pick. For instance, ResEdit 2.1.1 does not use the new, canonical layout for its "Maybe you want to save before closing/quitting?" dialog. Also, some of the recommendations regarding movabale modal dialogs and modeless dialogs were slow in percolating through to the entire system software. I think, however, you will be hard-pressed to find a violation in the Finder. Hope this helps, -- Peter Castine | Da sprach Jesus zu ihm: Stecke dein pcastine@prz.tu-berlin.de | Schwerdt an seinen Ort; denn wer das - ---------------------------------| Schwerdt nimmt, der soll durchs ``Have Mac, will travel'' | Schwerdt umkommen. (Matthai 26:52) +++++++++++++++++++++++++++ >From u9119523@sys.uea.ac.uk (Graham Cox) Date: Wed, 4 May 1994 20:24:52 GMT Organization: School of Information Systems, UEA, Norwich In article , cwiltgen@mcs.com (Charles Wiltgen) wrote: > In article <16674@lhdsy1.lahabra.chevron.com>, > jjvbl@lhdsy1.lahabra.chevron.com (John V. Blzka) wrote: > > > Hello, > > I've been working on a presentation on Human Factors Engineering. > > I am using Apple's User Interface Guidelines as an example. > > What I would like to know is: > > Does Apple violate it's own Guidelines in any of it's System 7 > > software? > > If so, can I easily demonstrate it? > > How 'bout dragging a disk to the trash to eject it? Oh, THAT old chestnut! Be honest- could YOU live without it? Here's a trivial example- not in the system but in most graphics programs, including MacDraw and ClarisWorks- the guidelines say that the cursor keys should never be used to position graphic elements, but most programs do this. However, in my opinion, it is the guideline that's stupid- WHY NOT!!! > > -- > Charles Wiltgen "Love is a snowmobile racing across the tundra and > cwiltgen@mcs.com then suddenly it flips over, pinning you underneath. > (INTP) At night, the ice weasels come." - Nietzsche (Groening) > World Wide Web http://venus.mcs.net/~cwiltgen/home.html - ------------------------------------------------------------------------ Love & BSWK, Graham -Everyone is entitled to their opinion, no matter how wrong they may be... - ------------------------------------------------------------------------ +++++++++++++++++++++++++++ >From zz1bb@impending.ucsd.edu (Barry Brown) Date: 4 May 94 17:17:18 GMT Organization: (none) In <1994May4.111339.29072@prz.tu-berlin.de> pcastine@jake.prz.tu-berlin.de (Peter Castine) writes: >jjvbl@lhdsy1.lahabra.chevron.com (John V. Blzka) asked: >>> Does Apple violate it's own Guidelines in any of it's System 7 >>> software? >>> If so, can I easily demonstrate it? >cwiltgen@mcs.com (Charles Wiltgen) replied: >>How 'bout dragging a disk to the trash to eject it? >Although the semantics and history of this gesture have been >much debated, I find myself asking "What Human Interface >Principle does this violate?" It certainly supports the >principles Direct Manipulation, See-and-Point, and User >Control. I believe it violates the (perhaps unwritten) "no surprises" and the "one object, one action" rules. A novice user is surprised to find out that trashing a disk doesn't erase it, but ejects it instead. S/he also discovers that selecting Eject from the Special menu doesn't remove the disk image from the desktop and may even ask him/her for the disk again in the future! Second, the Trash can is used for two purposes: removing files and ejecting disks -- two very different actions. The Trash is just a folder (albeit a special one); trashed files show up in its window before you empty it. Why don't trashed disks show up in it, either? -- Barry E. Brown Internet: bbrown@ucsd.edu UCSD Academic Computing Services AOL: BarryBrown Student Consultant My WWW Home Page +++++++++++++++++++++++++++ >From sjb8502@ucs.usl.edu (Bienvenu Jay ) Date: Wed, 4 May 1994 18:06:50 GMT Organization: Univ. of Southwestern La., Lafayette Does Claris count as part of Apple? If so, I've got one: MacWrite does not display a watch cursor while saving a file. Jay Bienvenu sjb8502@usl.edu +++++++++++++++++++++++++++ >From Paul Ferguson Date: 4 May 1994 23:48:17 GMT Organization: Kaleida Labs, Inc. In article <16674@lhdsy1.lahabra.chevron.com> John V. Blzka, jjvbl@lhdsy1.lahabra.chevron.com writes: > Does Apple violate it's own Guidelines in any of it's System 7 > software? One classic example that comes to mind is the Alarm Clock, which suffers from a bunch of violations: non-standard controls, non-standard title bar (not to mention using the title bar to display the time), non-standard close box, a cross-hair cursor to select a field, the big-small display modes, flashing the Apple menu forever when the alarm goes off (how many people at some point in their life were mystified to see a flashing alarm clock where the Apple menu is?) It's hard to find anything about the alarm clock that doesn't violate the HIG. Rumor has it that this DA was originally developed by Microsoft, which might explain some of it. It has not evolved at all from it's earliest incarnation, which is pretty lame on Apple's part. How hard is it to write an alarm clock? --fergy +++++++++++++++++++++++++++ >From Brad Koehn Date: 5 May 1994 01:35:32 GMT Organization: University of Wisconsin In article <1994May4.111339.29072@prz.tu-berlin.de> Peter Castine, pcastine@jake.prz.tu-berlin.de writes: >I think, however, you will be hard-pressed to find >a violation in the Finder. Oh, let's see, where to start: If you get info on a file on a server, or on a local volume with file sharing turned on, clicking on the name changes it to it's DOS equivilant. It doesn't give background applications any time (hardly). I know this probably isn't spelled out in the HIG, but it should be. When copying files, the menus don't dim. If you click in the menu bar during a copy, the dim all of a sudden. With the sharing box open, there's now way to save changes. You have to hit the close box, and dismiss the (up to three) annoying dialogs. Dragging items onto a system folder that's not the one you booted with doesn't put them in the right place, even if the icons in the folder (e.g. apple menu items folder) show correctly. You may call these bugs, but I say bugs are the most obvious form of HIG violation. _________________________________________________________________________ Brad Koehn Data Transformations, Inc. koehn@macc.wisc.edu +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Thu, 05 May 1994 10:03:13 +0800 Organization: Department of Computer Science, The University of Western Australia In article <1994May4.111339.29072@prz.tu-berlin.de>, pcastine@jake.prz.tu-berlin.de (Peter Castine) wrote: >I think, however, you will be hard-pressed to find >a violation in the Finder. OK, I've got a good one! Why, when you drag a file into a folder where there already exists a file of the same name, do you have the option of replacing the original. Why doesn't the Finder move it to the Trash??? OK, so maybe it's not a *real* HIG violation but it's really inconsistent and consistency is one of the central precepts of the HIG. Other (more obvious) problems become apparent when you install PowerTalk. Try the following... 1) Open your catalogue. 2) Drag a file into the catalogue window. 3) See Finder highlight catalogue window. 4) Let go. 5) See file zoom back to its original position. Or try this... 1) Open your catalogue. 2) Find a user record (either in your Personal Catalogue or in a PowerShare catalogue) and drag it to the catalogue window. 3) See Finder highlight catalogue window. 4) Let go. 5) Read dialog telling you that you can't do it because you don't have privileges. Question #1 Why does it highlight the window (in both cases)? Question #2 Why does it have different behaviour when it finally realises that it's failed? Basically AOCE's HI is severely broken in a lot of places. Unfortunately it's a Finder extension, which means that these problems appear to be Finder problems. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From alister@netcom.com (Rick Reynolds aka GreenGoo) Date: Thu, 5 May 1994 06:32:08 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) >How 'bout dragging a disk to the trash to eject it? I never really thought much about this issue but I think there should have been a disk drive icon on the desktop, always visable but somehow conveying to the user that a disk is inserted. When the user wants to change disks they can press an "eject" button on the icon. But alas that brings up the problem of having a control (which woule have to be smaller then other controls) on a Finder icon. Hmmm... -- Richard Reynolds alister@netcom.com "Most dreams are made of glass. You throw just one stone and then there goes your last window" -RJD +++++++++++++++++++++++++++ >From deguzman@binkley.math.uiuc.edu (Alan DeGuzman) Date: 5 May 1994 13:17:32 GMT Organization: Calculus&Mathematica at UIUC alister@netcom.com (Rick Reynolds aka GreenGoo) writes: >>How 'bout dragging a disk to the trash to eject it? >I never really thought much about this issue but I think there should >have been a disk drive icon on the desktop, always visable but somehow >conveying to the user that a disk is inserted. Uh, what about the disk's icon? Granted, it can be hidden behind windows, but I'd rather have what *I* want to stay on top of the desktop layer rather than some floating icons or whatever. >When the user wants >to change disks they can press an "eject" button on the icon. But alas >that brings up the problem of having a control (which woule have to be >smaller then other controls) on a Finder icon. Now you're on to something. How about letting every icon that is a volume have a 'switch' or 'button' drawn on (or near) the icon that let's you eject the volume (eject in the sense of "Put Away"). It could even be dimmed out for volumes that can't be "Put Away", like the startup volume. -- Alan A. DeGuzman "The problem with people is that they're only human." Calculus&Mathematica DISCLAIMER: "The University - Hobbes to Calvin from can't afford my opinions." 'The Indispensible Calvin and Hobbes' +++++++++++++++++++++++++++ >From tzs@u.washington.edu (Tim Smith) Date: 5 May 1994 13:52:44 GMT Organization: University of Washington School of Law, Class of '95 > I've been working on a presentation on Human Factors Engineering. > I am using Apple's User Interface Guidelines as an example. > What I would like to know is: > Does Apple violate it's own Guidelines in any of it's System 7 > software? > If so, can I easily demonstrate it? In the thingy that is used to select a color (get it by selecting "other..." for your highlight color in the Colors control panel, or double clicking on a palette entry in the pattern editor in the General control panel), they use a scroll bar to set brightness. I think this violates something in the User Interface Guidelines. --Tim Smith +++++++++++++++++++++++++++ >From Thomas Reed Date: 5 May 1994 15:00:06 GMT Organization: Washington University In article <2q9ih4$nhs@news.doit.wisc.edu> Brad Koehn, koehn@macc.wisc.edu writes: >It doesn't give background applications any time (hardly). I know this >probably isn't spelled out in the HIG, but it should be. I don't think that this kind of stuff is in the interface guidelines, though I can't say that for sure. Actually, the amount of time background applications get depends on the background application. Any application can grab as much or as little of the CPU time as it needs. That's how the Mac's cooperative multitasking works. >When copying files, the menus don't dim. If you click in the menu bar >during a copy, the dim all of a sudden. I think my menus dim, all except the Apple, Balloon Help, and Application (you know, the one on the far right) menus. If they don't dim, it's probably for one of two reasons: 1) you can use them even during a copy, or 2) you have an extension or control panel installed that does something with your menus. >With the sharing box open, there's now way to save changes. You have to >hit the close box, and dismiss the (up to three) annoying dialogs. Agreed on this one. It'd be nice if there was a friendlier way to do sharing stuff. Though I'm not going to complain too much -- I don't mind the way it's done now. >Dragging items onto a system folder that's not the one you booted with >doesn't put them in the right place, even if the icons in the folder >(e.g. apple menu items folder) show correctly. Yes, I've often done this. However, there's really only one way for the computer to know that a folder is the system folder without doing more stuff than it should have to do -- if it has the active system in it. If every time you dropped something in a folder, the system had to search that folder for a copy of the Finder, then all your moves would take a little longer. Not only that, but it wouldn't be reliable -- sometimes I keep copies of the Finder around in different places to play with them. -Thomas ===================================================== Thomas Reed Washington University Reed@telesphere.wustl.edu Medical School (also: Reed@medicine.wustl.edu) - --------------------------------------------------- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain ===================================================== +++++++++++++++++++++++++++ >From Paul Ferguson Date: 5 May 1994 15:30:12 GMT Organization: Kaleida Labs, Inc. In article <2qatnc$bon@news.u.washington.edu> Tim Smith, tzs@u.washington.edu writes: > In the thingy that is used to select a color (get it by > selecting "other..." for your highlight color in the Colors > control panel, or double clicking on a palette entry in the > pattern editor in the General control panel), they use a scroll > bar to set brightness. I think this violates something in the > User Interface Guidelines. HIG page 215: "Use scroll bars only for representing the relative position of the visible portion of a document and in scrolling lists." I suppose one could argue that in the color picker, the "document" is the entire color space and that you are scrolling through it to see different views. On the other hand, what the slider is doing is changing the brightness from 0-65535, which is exactly what the example shown on that page says is an incorrect use of a scroll bar. This does raise the issue of why Apple explicitly talks about sliders (in a section entitled "Controls Not Supported by the Macintosh Toolbox") and gives guidelines as to their use, but have never provided any sort of standard slider controls for programmers to use. Other environments like Motif provide slider widgets with the same look and feel as their scroll bars, check boxes, etc. I think Apple's OS and UI groups have failed by not providing the same. Hence the scroll bar often does get misused because it is much easier to use what's there than write it from scratch (and writing a smooth slider is not a trivial task). --fergy - ------------------------------------------------------------------ Paul Ferguson | "It's a sick world, I'm a happy guy..." pferguson@kaleida.com | - ------------------------------------------------------------------ +++++++++++++++++++++++++++ >From hades@coos.dartmouth.edu (Brian V. Hughes) Date: 5 May 1994 17:33:26 GMT Organization: Dartmouth College, Hanover, NH, USA Thomas Reed writes: >Brad Koehn, koehn@macc.wisc.edu writes: >>It doesn't give background applications any time (hardly). I know this >>probably isn't spelled out in the HIG, but it should be. >I don't think that this kind of stuff is in the interface guidelines, >though I can't say that for sure. No it's not in the HIG, but that's because there is no human interface involved with background applications getting CPU time. >Actually, the amount of time background applications get depends on the >background application. Any application can grab as much or as little >of the CPU time as it needs. That's how the Mac's cooperative >multitasking works. Nope, sorry. There's this little routine called WaitNextEvent() that must be called, at a decent interval, by the forgroung application so that when the background application calls GetNextEvent() there's something there to be gotten. Applications have to be written to perform as both foreground and background apps, nicely, so that the Mac cooporative scheme works the way it's supposed to. -Hades +++++++++++++++++++++++++++ >From Chuck Simciak Date: Thu, 5 May 1994 17:28:00 GMT Organization: Cleveland Clinic Foundation In article <2qatnc$bon@news.u.washington.edu> Tim Smith, tzs@u.washington.edu writes: >> I've been working on a presentation on Human Factors Engineering. >> I am using Apple's User Interface Guidelines as an example. >> What I would like to know is: >> Does Apple violate it's own Guidelines in any of it's System 7 >> software? >> If so, can I easily demonstrate it? I'm not sure if this counts as breaking an interface guideline but it is very annonying. Say I go to save a file, the StandardPutFile dialog emerges and I have to navigate several folders to get to my desitination. The file name field has already been filled with a defualt. Here's the catch. Upon having navigated the multiple folders to place the file, the SAVE button is now an OPEN button. I then have to click in the filename text field to cause the button to CHANGE to SAVE. This "feature" was introduced in System 7 and has been a source of nuisance ever since. later.... Chuck Simciak !"The broken image of Man moves in minute by minute wxs@po.cwru.edu ! and cell by cell... Poverty, hatred, war, police- simciac@ccsmtp.ccf.org ! criminals, bureaucracy, insanity, all symptoms of WRUW 91.1 FM Cleveland ! The Human Virus." - William S. Burroughs +++++++++++++++++++++++++++ >From dn_crow@bean.open.ac.uk (dn_crow) Date: Thu, 5 May 1994 18:43:00 GMT Organization: (none) An example that has always rather amused me is the one about switching between applications. The guidlines state that if I click outside any window belonging to my application, this action should switch me to the application whose window I have clicked over (e.g. the Finder). The only action of this click, or indeed double-click, should be to switch applications. In particular, the guidelines state that the clicks should *not* be sent to the application being clicked upon. However, the Finder disregards this: try loading an application and bringing it to the front, while still being able to see a finder window behind it. If you now click over a visible finder icon, the appropriate Finder window is brought to the front (correct) but the icon is selected (incorrect). This, along with most of the other problems mentioned in this thread, is pretty minor, so if, as your rather biased title suggests, you're trolling for Apple-bashing material, I think you'll have a pretty weak case... Dan +++++++++++++++++++++++++++ >From pcastine@jake.prz.tu-berlin.de (Peter Castine) Date: Thu, 5 May 1994 19:48:30 GMT Organization: PRZ TU-Berlin quinn@cs.uwa.edu.au (Quinn "The Eskimo!") writes: >pcastine@jake.prz.tu-berlin.de (that's me) wrote: > >>I think, however, you will be hard-pressed to find >>a violation in the Finder. > >OK, I've got a good one! Why, when you drag a file into a folder where >there already exists a file of the same name, do you have the option of >replacing the original. Why doesn't the Finder move it to the Trash??? >OK, so maybe it's not a *real* HIG violation but it's really inconsistent Inconsistent with what? >and consistency is one of the central precepts of the HIG. Consistency is, IMHO, a secondary concern. Smith et.al. discuss the practical issues of maintaining consistency in real world applications in their 1982 article "Designing the Star user interface." (Originally printed in Byte 7(4), reprinted in Baecker & Buxton's _Readings in Human-Computer Interaction_, the paper is a must-read). Short precis: consistency is the hobgoblin of small minds. >Other (more obvious) problems become apparent when you install PowerTalk. This is cheating--PowerTalk extensions aren't the Finder. I suppose they look that way, though. >Try the following... > >1) Open your catalogue. >2) Drag a file into the catalogue window. >3) See Finder highlight catalogue window. >4) Let go. >5) See file zoom back to its original position. > This example comes practically straight from the discussion in the above-mentioned article. Geez--maybe I should just violate copyright and type in the entire paper. :-) >Or try this... > >1) Open your catalogue. >2) Find a user record (either in your Personal Catalogue or in a >PowerShare catalogue) and drag it to the catalogue window. >3) See Finder highlight catalogue window. >4) Let go. >5) Read dialog telling you that you can't do it because you don't have >privileges. > >Question #1 Why does it highlight the window (in both cases)? For performance reasons? (Checking privileges might slow down feedback, direct manipulation. I'm obviously guessing on this one). >Question #2 Why does it have different behaviour when it finally realises > that it's failed? What's it supposed to do? Not tell you that it failed? Disregard privileges? >Basically AOCE's HI is severely broken in a lot of places. Severely? Well, I'll let that pass before a flame war breaks out. > Unfortunately >it's a Finder extension, Like I said, cheating. >which means that these problems appear to be >Finder problems. Well, touche. -- Peter Castine | Da sprach Jesus zu ihm: Stecke dein pcastine@prz.tu-berlin.de | Schwerdt an seinen Ort; denn wer das - ---------------------------------| Schwerdt nimmt, der soll durchs ``Have Mac, will travel'' | Schwerdt umkommen. (Matthai 26:52) +++++++++++++++++++++++++++ >From Thomas Reed Date: 5 May 1994 20:31:38 GMT Organization: Washington University In article <1994May5.172800.22102@bme.ri.ccf.org> Chuck Simciak, simciac@ccsmtp.ccf.org writes: > The file name field has already been filled with a defualt. Here's the >catch. Upon having navigated the multiple folders to place the file, the >SAVE button is now an OPEN button. I then have to click in the filename >text field to cause the button to CHANGE to SAVE. This "feature" was >introduced in System 7 and has been a source of nuisance ever since. I believe this problem is caused not by the system, but by Directory Assistance II. (Or a similar program.) My System 7.x machine never did this until I installed Directory Assistance II, so... -Thomas ===================================================== Thomas Reed Washington University Reed@telesphere.wustl.edu Medical School (also: Reed@medicine.wustl.edu) - --------------------------------------------------- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain ===================================================== +++++++++++++++++++++++++++ >From Thomas Reed Date: 5 May 1994 20:48:08 GMT Organization: Washington University In article <2qbal6$3tu@dartvax.dartmouth.edu> Brian V. Hughes, hades@coos.dartmouth.edu writes: >>Actually, the amount of time background applications get depends on the >>background application. Any application can grab as much or as little >>of the CPU time as it needs. That's how the Mac's cooperative >>multitasking works. > > Nope, sorry. There's this little routine called WaitNextEvent() that >must be called, at a decent interval, by the forgroung application so >that when the background application calls GetNextEvent() there's >something there to be gotten. Yes, it's true that there has to be "something to be gotten", but I think most applications these days, background or not, call WaitNextEvent, so they can control directly how much time they get by giving different numbers for the sleep value. A low value causes the app to be given time more often, a high value causes the app to be given time less often. Plus, if the background app doesn't call WaitNextEvent AT ALL for a while, they get ALL of that processing time. WaitNextEvent is the key behind applications getting CPU time. -Thomas ===================================================== Thomas Reed Washington University Reed@telesphere.wustl.edu Medical School (also: Reed@medicine.wustl.edu) - --------------------------------------------------- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain ===================================================== +++++++++++++++++++++++++++ >From pcastine@jake.prz.tu-berlin.de (Peter Castine) Date: Thu, 5 May 1994 20:39:17 GMT Organization: PRZ TU-Berlin Chuck Simciak writes: > >I'm not sure if this counts as breaking an interface guideline but it is >very annonying. Say I go to save a file, the StandardPutFile dialog >emerges and I have to navigate several folders to get to my desitination. > The file name field has already been filled with a defualt. Here's the >catch. Upon having navigated the multiple folders to place the file, the >SAVE button is now an OPEN button. I then have to click in the filename >text field to cause the button to CHANGE to SAVE. This "feature" was >introduced in System 7 and has been a source of nuisance ever since. I like this one, because the Standard Save File dialog is being *consistent* (that's right, folks!). The Save button only changes to Open when you've selected a folder in the directory list. When this is the case, the EditText field with the document name is no longer the active item in the dialog, the directory list is the active item (highlighted with an extra two-pixel thick box surrounding it). So, the Save button is being context-sensitive, changes to 'Open' and behaves the same way a double-click on the currently selected item would behave. BTW, you don't need to click on the document name, you only have to deselect any folder, for the button to change back to Open. I'm just waiting for someone to say "Why don't they add another button, so you've got one for Save and one for Open?" Before you ask that question, read Tognazzini's article on Consistency in _The Art of Human-Computer Interface Design_ ;-q -- Peter Castine | Da sprach Jesus zu ihm: Stecke dein pcastine@prz.tu-berlin.de | Schwerdt an seinen Ort; denn wer das - ---------------------------------| Schwerdt nimmt, der soll durchs ``Have Mac, will travel'' | Schwerdt umkommen. (Matthai 26:52) +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Fri, 06 May 1994 10:41:44 +0800 Organization: Department of Computer Science, The University of Western Australia In article <2qatnc$bon@news.u.washington.edu>, tzs@u.washington.edu (Tim Smith) wrote: >In the thingy that is used to select a color (get it by selecting "other..." >for your highlight color in the Colors control panel, or double clicking >on a palette entry in the pattern editor in the General control panel), >they use a scroll bar to set brightness. I think this violates something >in the User Interface Guidelines. Actually it violates the letter, *but not IMHO the spirit*, of the guideline that states that you should only put settings, as opposed to commands, in a popup menu. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From jfinete@cats.ucsc.edu (Joseph Manuel Finete) Date: 6 May 1994 03:04:26 GMT Organization: University of California; Santa Cruz In article <1994May5.203917.29612@prz.tu-berlin.de> pcastine@jake.prz.tu-berlin.de (Peter Castine) writes: > >I like this one, because the Standard Save File dialog is being >*consistent* (that's right, folks!). > >The Save button only changes to Open when you've selected a folder >in the directory list. When this is the case, the EditText field >with the document name is no longer the active item in the dialog, >the directory list is the active item (highlighted with an extra >two-pixel thick box surrounding it). So, the Save button is being >context-sensitive, changes to 'Open' and behaves the same way >a double-click on the currently selected item would behave. > >BTW, you don't need to click on the document name, you only have >to deselect any folder, for the button to change back to Open. Also, hitting the TAB key will let you cycle through the dialog items. So if the file list is selected, hit TAB and then the EditText field will be selected. My problem is that its not obvious enough that the file list is selected or that the Edit Text field is not selected, although, I really don't have a good idea on how to alleviate this. -- Joe Finete jfinete@cats.ucsc.edu +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 6 May 1994 08:34:14 GMT Organization: The Royal Institute of Technology In <1994May5.172800.22102@bme.ri.ccf.org> Chuck Simciak writes: >catch. Upon having navigated the multiple folders to place the file, the >SAVE button is now an OPEN button. I then have to click in the filename >text field to cause the button to CHANGE to SAVE. This "feature" was Or you can press TAB. This is so you can actually type-select folder names in the list, instead of having to use arrow keys. Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe (on a Swedish scale) -- What we need is a good GNU [...] licence manager implementation. -- Raphael Manfredi +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 6 May 1994 08:36:21 GMT Organization: The Royal Institute of Technology In <1994May5.184300.25982@leeds.ac.uk> dn_crow@bean.open.ac.uk (dn_crow) writes: >only action of this click, or indeed double-click, should be to switch >applications. In particular, the guidelines state that the clicks >should *not* be sent to the application being clicked upon. This recommendation is going away with the new, direct manipulation, Drag Manager, and AOCE which uses it (or its cousin) and it will DEFINATELY not be the case when you run OpenDoc. Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe (on a Swedish scale) -- What we need is a good GNU [...] licence manager implementation. -- Raphael Manfredi +++++++++++++++++++++++++++ >From sw@network-analysis-ltd.co.uk (Sak Wathanasin) Date: Fri, 6 May 94 09:47:25 GMT Organization: Network Analysis Ltd In article <1994May5.184300.25982@leeds.ac.uk> (comp.sys.mac.advocacy,comp.sys.mac.programmer), dn_crow@bean.open.ac.uk (dn_crow) writes: > applications. In particular, the guidelines state that the clicks > should *not* be sent to the application being clicked upon. As with all guidelines, this is not meant to be slavishly adhered to. It's up to the appl whether to accept the first click, and in the case of the Finder what it does makes a lot of sense. Although the desktop is a window in some sense, in a way it isn't. You have to select a piece of paper (window) to write in it, but surely you don't expect to "select" your desk to pick something up or put it down. (I'd also argue that you should be able to "click through" to most appls, just like I can scribble a note in the margin of a sheet of paper without having to move it to the front, but that's another story.) The Finder also does the same with folder windows. Does anyone remember what it used to be like? When you wanted to drag a file from one folder to another, you clicked on the src icon which would bring its window to the front. This would sometimes cover up the window you wanted to drag to, so you'd have to go back and move it out from underneath (then move it back after the drag if you're obsessively tidy like me :-). The way it does it now is MUCH better, and I'm pleased to see that the Drag Mgr supports this way of working. If the guidelines say that you can't do this, then the guidelines should be changed. 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 Willie Abrams Date: 5 May 1994 15:02:28 GMT Organization: OU Health Sciences Center In article Quinn, quinn@cs.uwa.edu.au writes: >Basically AOCE's HI is severely broken in a lot of places. Unfortunately AOCE is real screwed up as far as HIG goes. If we are going to flame its flaws, here are my complaints: The standard mailer is a specific size, which means if you make the window smaller, it cuts off the damn mailer, and if you make the window bigger, you can't take advantage of the extra space to the right of the mailer. The way the mailer is shaped, You can only see about three enclosures... AppleMail has a real sluggish event loop. I know this isn't necessarily a HIG flaw, but it is a real UI flaw. I end up reading mail in ClarisWorks, since it responds to my stimulus faster. PowerShare admin stuff is just plain ugly. Chicago and Geneva are the System and Application typefaces for a reason - they are readable on screen. This Palatino stuff, with fixed sixed panes are a real pain. At least with AppleShare, you had nice resizeable and movable lists that allowed you to manage it. (although it didn't remember window positions...ugh!) I can move the keys off the desktop, but I can't move the catalogs (I guess I can sort of see that) - QuickDraw GX suffers there too, with all of those desktop printers...a real pain in the butt for those of use who move frequently from enviroment to enviroment with the same system. Another UI problem - Symantec/Think C - I can't open a source file without opening a project. Great! Modal Functionality... Probably why I like Metrowerks... Is there a forum where people can talk and discuss about UI issues? Would that be a thread that should be here in csmp? I think we have a real opportunity to jolt some people back into thinking about how software is used. There are real usability issues that are not related to functionality that need to be addressed. We as programmers need to address these head on, as we implement the great (or horrid) user interfaces. I will stop now. I am getting incensed. Willie Abrams Telemedicine Software Guy Internet: willie-abrams@uokhsc.edu OU Health Sciences Center AppleLink: Willie +++++++++++++++++++++++++++ >From John Hamilton Slye Date: Fri, 6 May 1994 12:55:38 -0400 Organization: Junior, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA On 06-May-94 in Re: Apple's blatant disrega.. user Joseph Manuel Finete@cat writes: >Also, hitting the TAB key will let you cycle through the dialog items. >So if the file list is selected, hit TAB and then the EditText field >will be selected. My problem is that its not obvious enough that the >file list is selected or that the Edit Text field is not selected, >although, I really don't have a good idea on how to alleviate this. When the test field is not selected, the caret isn't in it anymore...and when the file list is selected, there is an outline box around it... O------------------O---------------------O----------------------------------O | | jsbr@andrew.cmu.edu | "I know that there are people in | | J. Hamilton Slye | | the world who do not love their | | | ham@ece.cmu.edu | fellow human beings...and I HATE | O------------------O---------------------O people like that!" | | 1071 Morewood Ave. | - Tom Lehrer | | Pittsburgh, Pa. 15213 O----------------------------------O | (412) 862-3739 | THIS SPACE FOR RENT! | O----------------------------------------O----------------------------------O +++++++++++++++++++++++++++ >From Robert Hess Date: Fri, 6 May 1994 18:44:40 GMT Organization: MacWEEK In article Quinn, quinn@cs.uwa.edu.au writes: >Other (more obvious) problems become apparent when you install PowerTalk. Oh, I have an even better one... A letter sits in the In Tray. I drag it out of the In Tray into a folder. Have I moved the letter? No, I've copied it. The copied letter and the letter remaining in the In Tray, appear to be identical (same icon, same name). In one window I can see the sender date sent, etc. In another window I see size, date modified, etc. Can I modify the name of something in the In Tray? No. How about in a folder? Yes. Can I move something from a folder back into the In Tray? No. I love PowerTalk but it imposes a whole set of new (i.e. inconsistent) rules on new users and, like you said, makes the Finder seem awkward. ======================================================================== Robert Hess, WEEKgeek robert_hess@macweek.ziff.com MacWEEK AppleLink: WNDZSX 301 Howard CompuServe: 72511,333 San Francisco, Calif. 94105 America Online: MacWEEK (415) 243-3576 days MCI: RHESS (415) 243-3651 fax (415) 647-5549 nights I speak for myself. now doesn't that make you feel better? And sometimes not even that. ======================================================================== +++++++++++++++++++++++++++ >From Robert Hess Date: Fri, 6 May 1994 18:46:25 GMT Organization: MacWEEK In article Quinn, quinn@cs.uwa.edu.au writes: >1) Open your catalogue. >2) Find a user record (either in your Personal Catalogue or in a >PowerShare catalogue) and drag it to the catalogue window. >3) See Finder highlight catalogue window. >4) Let go. >5) Read dialog telling you that you can't do it because you don't have >privileges. Or, better yet, drag a user record into the "mount points" list of the File Sharing Monitor. It hightlights, indicating it is willing to accept a drag. Why on Earth would it do that? (Or, for that matter, why would someone try to do this? But that's not the point. ;) ======================================================================== Robert Hess, WEEKgeek robert_hess@macweek.ziff.com MacWEEK AppleLink: WNDZSX 301 Howard CompuServe: 72511,333 San Francisco, Calif. 94105 America Online: MacWEEK (415) 243-3576 days MCI: RHESS (415) 243-3651 fax (415) 647-5549 nights I speak for myself. now doesn't that make you feel better? And sometimes not even that. ======================================================================== +++++++++++++++++++++++++++ >From pcastine@jake.prz.tu-berlin.de (Peter Castine) Date: Fri, 6 May 1994 19:43:02 GMT Organization: PRZ TU-Berlin Willie Abrams writes: > >Is there a forum where people can talk and discuss about >UI issues? Would that be a thread that should be here in csmp? > How about comp.human-factors? That might have been a more appropriate place to follow-up. -- Peter Castine | Da sprach Jesus zu ihm: Stecke dein pcastine@prz.tu-berlin.de | Schwerdt an seinen Ort; denn wer das - ---------------------------------| Schwerdt nimmt, der soll durchs ``Have Mac, will travel'' | Schwerdt umkommen. (Matthai 26:52) +++++++++++++++++++++++++++ >From pcastine@jake.prz.tu-berlin.de (Peter Castine) Date: Fri, 6 May 1994 20:03:56 GMT Organization: PRZ TU-Berlin Joseph Manuel Finete@cat writes: >>Also, hitting the TAB key will let you cycle through the dialog items. >>So if the file list is selected, hit TAB and then the EditText field >>will be selected. My problem is that its not obvious enough that the >>file list is selected or that the Edit Text field is not selected, >>although, I really don't have a good idea on how to alleviate this. John Hamilton Slye responded: > >When the test field is not selected, the caret isn't in it anymore...and >when the file list is selected, there is an outline box around it... I think Joseph may have been aware of this behavior. It is, however, a bit on the subtle side. It becomes more obvious when the EditText field is entirely selected, because it highlights/unhighlights when you tab in and out of it. -- Peter Castine | Da sprach Jesus zu ihm: Stecke dein pcastine@prz.tu-berlin.de | Schwerdt an seinen Ort; denn wer das - ---------------------------------| Schwerdt nimmt, der soll durchs ``Have Mac, will travel'' | Schwerdt umkommen. (Matthai 26:52) +++++++++++++++++++++++++++ >From jaeger@kunikpok.icus.com (Jaeger) Date: Fri, 06 May 94 13:20:30 CDT Organization: Kunikpok Kennels and Komputers (Pet Project) Here's a blatantly diregarded interface guidline. When formatting floppies there is no progress indicator. Anything that takes as long as formatting a floppy should have a progress bar. Brian Stern :-{)} Jaeger@fquest.com +++++++++++++++++++++++++++ >From mikec@mv.mv.com (Mike Callaghan) Date: Fri, 6 May 1994 21:51:04 GMT Organization: MV Communications, Inc. In article <1994May5.184300.25982@leeds.ac.uk>, dn_crow wrote: >However, the Finder disregards this: try loading an application and >bringing it to the front, while still being able to see a finder window >behind it. If you now click over a visible finder icon, the appropriate >Finder window is brought to the front (correct) but the icon is >selected (incorrect). If I'm not mistaken, this is simple to correct with ResEdit by changing the Finder's SIZE resource (Get Front Clicks, I believe). Personally, I like it, and wish more programs did it. MikeC -- Michael D. Callaghan Nashua, New Hampshire - -------------------------------------------------------------------- RULE: "(sqrt(-1)) before (2.71828), except after (186,000 miles/sec)." [THE DANGERS OF MIXING GRAMMAR AND SCIENCE] +++++++++++++++++++++++++++ >From scgkr@mucc.mahidol.ac.th (Graham Keith Rogers - SCLG) Date: 7 May 1994 02:06:49 GMT Organization: Mahidol University, Thailand. Paul Ferguson (pferguson@kaleida.com) wrote: : select a field, the big-small display modes, flashing the Apple : menu forever when the alarm goes off (how many people at some : point in their life were mystified to see a flashing alarm clock : where the Apple menu is?) It's hard to find anything about the Is *that* what that is. Jeez, how do I turn it off? Please.... Graham +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 7 May 1994 09:03:08 GMT Organization: The Royal Institute of Technology In Robert Hess writes: >A letter sits in the In Tray. I drag it out of the In Tray into a folder. Have I >moved the letter? No, I've copied it. Of course! It's the same thing as "a file is sitting on a floppy disk, and I drag it to a folder on my hard disk." However, QuickDraw GX desktop printers are another thing: A file sits in the printer queue, and I drag it to the desktop. It is MOVED there. I then drag it to the printer again, and it is COPIED into the printer. It makes sense, of course, since moving it to the printer would delete it once it was printed, but it's still eerie. -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe (on a Swedish scale) -- "Anyone who tries to make a distinction between education and entertainment doesn't know the first thing about either" -- Trip Hawkins +++++++++++++++++++++++++++ >From tzs@u.washington.edu (Tim Smith) Date: 7 May 1994 09:46:06 GMT Organization: University of Washington School of Law, Class of '95 Quinn "The Eskimo!" wrote: >>In the thingy that is used to select a color (get it by selecting "other..." >>for your highlight color in the Colors control panel, or double clicking >>on a palette entry in the pattern editor in the General control panel), >>they use a scroll bar to set brightness. I think this violates something >>in the User Interface Guidelines. > >Actually it violates the letter, *but not IMHO the spirit*, of the >guideline that states that you should only put settings, as opposed to >commands, in a popup menu. I was thinking of page 215, where it says that scroll bars are *only* to be used to manipulate the relative position in a document or list. They explicitly say that scroll bars are not to be used where sliders should be used. Thus, the color selector is a blatant violation. --Tim Smith +++++++++++++++++++++++++++ >From hall_j@sat.mot.com (Joseph Hall) Date: Fri, 6 May 1994 17:11:28 GMT Organization: Motorola Inc., Satellite Communications Seems it was dn_crow@bean.open.ac.uk (dn_crow) who said: >An example that has always rather amused me is the one about switching >between applications. The guidlines state that if I click outside any >window belonging to my application, this action should switch me to the >application whose window I have clicked over (e.g. the Finder). The >only action of this click, or indeed double-click, should be to switch >applications. In particular, the guidelines state that the clicks >should *not* be sent to the application being clicked upon. Is this correct? There is one of the finder flags (the application bits you can change with ResEdit) that can be set so that the click will be delivered to the application after it is brought to the front. I have found this a very appropriate behavior in the case of apps like THINK Reference. You click on the "thinker" icon in the background, and wham, there's THINK Reference for you. -- Joseph Nathan Hall | Joseph's Law of Interface Design: Never give your users Software Architect | a choice between the easy way and the right way. Gorca Systems Inc. | joseph@joebloe.maple-shade.nj.us (home) (on assignment) | (602) 732-2549 (work) Joseph_Hall-SC052C@email.mot.com +++++++++++++++++++++++++++ >From derek@netcom.com (Derek LeLash) Date: Sat, 7 May 1994 18:07:00 GMT Organization: Corner of Walk & Don't Walk In article johan.solve@itn.hh.se (Johan Solve) writes: > >Metaphors that needs to be explained (as the trashcan in the remove-disk >case) are not good metaphors. Picture a new user who has never seen a Mac >before. He inserts a disk and wants to get it out again. I don't think he >even dare to think of dragging it to the trash. There has to be a Mac guru >around to explain to him that "in this special case, nothing gets deleted. >But the disk will disappear from the desktop (and reappear on the real life >desktop...)" > >Not good. No. The user selects the disk icon and chooses "Put Away" from the File menu. Anything else is an optional short cut. Does the fact that *everyone* drags disks to the Trash *regardless* of how "pure" the metaphor is tell you anything about how the Finder was designed to give users multiple ways to perform an action, so that they can pick the one they want? I guarantee you that five minutes after someone learns that you *can* (not *must*) eject a disk by throwing it in the trash, that will be the only method they ever use. Who cares if the metaphor is perfect? Derek -- Derek LeLash, SrTechWriter/INFP | "Everyone lays off their Prozac for a week BASYS Automation Systems, Inc. | before I come to town. Nothing serious, home: derek@netcom.com | just enough to get a little dip going." work: derek@scooter.amc.dec.com | -- Shawn Colvin +++++++++++++++++++++++++++ >From de19@umail.umd.edu (Dana S Emery) Date: Sat, 07 May 1994 15:54:44 -0500 Organization: Botany, UMCP In article <2qb1lmINNh21@medicine.wustl.edu>, Thomas Reed wrote: > >Dragging items onto a system folder that's not the one you booted with > >doesn't put them in the right place, even if the icons in the folder > >(e.g. apple menu items folder) show correctly. > > Yes, I've often done this. However, there's really only one way for the > computer to know that a folder is the system folder without doing more > stuff than it should have to do -- if it has the active system in it. disagree, the Finder already knows if a viable system is inside, it has to in order to show the proper icon for a system folder. The rest is simply a matter of searching for tagged folders and directing the files, and I, as a user would expect that behaviour to be consistant for any folder showing the blessed system icon, no matter if it was in fact the booted system. -- Dana S Emery +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 8 May 1994 10:09:08 GMT Organization: The Royal Institute of Technology In de19@umail.umd.edu (Dana S Emery) writes: >disagree, the Finder already knows if a viable system is inside, it has to >in order to show the proper icon for a system folder. So far so good. >The rest is simply a matter of searching for tagged folders and directing >the files, and I, as a user would expect that behaviour to be consistant >for any folder showing the blessed system icon, no matter if it was in fact >the booted system. Exactly how would the Swedish Finder know about the names of the Hindu special folders? Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe (on a Swedish scale) -- There's no sex act that can't be made better with Jell-O. +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Mon, 09 May 1994 10:34:31 +0800 Organization: Department of Computer Science, The University of Western Australia In article <2qfo0u$7kn@news.u.washington.edu>, tzs@u.washington.edu (Tim Smith) wrote: >Quinn "The Eskimo!" wrote: >>Someone else wrote: >>>In the thingy that is used to select a color (get it by selecting "other..." >>>for your highlight color in the Colors control panel, or double clicking >>>on a palette entry in the pattern editor in the General control panel), >>>they use a scroll bar to set brightness. I think this violates something >>>in the User Interface Guidelines. >> >>Actually it violates the letter, *but not IMHO the spirit*, of the >>guideline that states that you should only put settings, as opposed to >>commands, in a popup menu. > >I was thinking of page 215, where it says that scroll bars are *only* to >be used to manipulate the relative position in a document or list. True enough. [Whoops, forgot to *read* the post!] I was talking about the "Other..." on the popup menu, not the scroll bars for selecting values. The scroll bars are obviouly broken. btw This "thingy" is called the Colour Picker. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia Repeat 100 times... I will read the post before replying. +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Mon, 09 May 1994 10:56:32 +0800 Organization: Department of Computer Science, The University of Western Australia In article <1994May5.194830.28693@prz.tu-berlin.de>, pcastine@jake.prz.tu-berlin.de (Peter Castine) wrote: >quinn@cs.uwa.edu.au (Quinn "The Eskimo!") writes: >>pcastine@jake.prz.tu-berlin.de (that's me) wrote: >> >>>I think, however, you will be hard-pressed to find >>>a violation in the Finder. >> >>OK, I've got a good one! Why, when you drag a file into a folder where >>there already exists a file of the same name, do you have the option of >>replacing the original. Why doesn't the Finder move it to the Trash??? >>OK, so maybe it's not a *real* HIG violation but it's really inconsistent > >Inconsistent with what? Inconsistent with the fact that every other time you try to delete a file in the Finder you have a chance to undo that action by dragging it out of the Trash. >>and consistency is one of the central precepts of the HIG. > >Consistency is, IMHO, a secondary concern. Smith et.al. discuss the >practical issues of maintaining consistency in real world applications >in their 1982 article "Designing the Star user interface." (Originally >printed in Byte 7(4), reprinted in Baecker & Buxton's _Readings in >Human-Computer Interaction_, the paper is a must-read). Short >precis: consistency is the hobgoblin of small minds. No, *mindless* adherence to consistency is the hobgoblin of small minds. Actually I'd like to know where you precis comes from because my copy of Smitch et al says... %Everyone agrees that consistency is an admirable goal. However, it %is perhaps the single hardest characterist of all to achieve in a %a computer system. In fact, in systems of even moderate complexity, %consistency may not be well defined. The fact that seemingly inconsistent behaviour may be good for the user (eg their classic drog document on printer example, also dragging floppies to the Trash) doesn't imply that you shouldn't evaluate your behaviour in terms of the consistent environment you're creating. Besides the behaviour I advocate (moving replaced files to the Trash) is simply better than the alternative (deleting them). Are you arguing otherwise? If so then you're arguing directly with the HIG, which advocate "Forgiveness" (p10) and says... #You can encourage people to explore your application by building in #forgiveness. Forgiveness means that actions on the computer are #generally reversible. People need to feel that they can try things #without damaging the system; /create safety nets/ for people so that #they feel comfortable learning and using your product. [my italics] >>Question #1 Why does it highlight the window (in both cases)? > >For performance reasons? (Checking privileges might slow down >feedback, direct manipulation. I'm obviously guessing on this one). Personally I think that's crap -- but I don't know enough about AOCE programming to prove it (: >>Question #2 Why does it have different behaviour when it finally realises >> that it's failed? > >What's it supposed to do? Not tell you that it failed? Disregard >privileges? Yeah, but why *2* different behaviours? >>Basically AOCE's HI is severely broken in a lot of places. > >Severely? Well, I'll let that pass before a flame war breaks out. Well I've got some support out there; see the comments by Willie Abrams . -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From howden@munta.cs.mu.OZ.AU (Nicholas James HOWDEN) Date: Mon, 9 May 1994 04:16:44 GMT Organization: Computer Science, University of Melbourne, Australia Paul Ferguson writes: >In article <16674@lhdsy1.lahabra.chevron.com> John V. Blzka, >jjvbl@lhdsy1.lahabra.chevron.com writes: >> Does Apple violate it's own Guidelines in any of it's System 7 >> software? >One classic example that comes to mind is the Alarm Clock, which >suffers from a bunch of violations: non-standard controls, ... >point in their life were mystified to see a flashing alarm clock >where the Apple menu is?) It's hard to find anything about the >alarm clock that doesn't violate the HIG. Another good one is when someone sets the alarm clock, but then removes the item from the apple menu after it goes off. You then have a flashing alarm clock in the apple menu with no way to turn it off (this certainly sounds like a Micro$oft 'feature' to me ;-) Nick. -- - ----------------------------------------------------------------------------- ******** I F Y O U Q U I T , Y O U ' L L N E V E R W I N ******** - ----------------------------------------------------------------------------- +++++++++++++++++++++++++++ >From tzs@u.washington.edu (Tim Smith) Date: 9 May 1994 07:49:53 GMT Organization: University of Washington School of Law, Class of '95 Thomas Reed wrote: >>Dragging items onto a system folder that's not the one you booted with >>doesn't put them in the right place, even if the icons in the folder >>(e.g. apple menu items folder) show correctly. > >Yes, I've often done this. However, there's really only one way for the >computer to know that a folder is the system folder without doing more >stuff than it should have to do -- if it has the active system in it. If >every time you dropped something in a folder, the system had to search >that folder for a copy of the Finder, then all your moves would take a >little longer. Not only that, but it wouldn't be reliable -- sometimes I It would only have to do this when you dropped an extension, control panel, or other magic file into a folder. For most dropping, it doesn't matter if the destination is a System Folder, so it would not have to do more work in the vast majority of cases. --Tim Smith +++++++++++++++++++++++++++ >From dn_crow@bean.open.ac.uk (dn_crow) Date: Mon, 9 May 1994 08:43:17 GMT Organization: (none) In article jmiller@connected.com (James Miller) writes: > In article <1994May5.184300.25982@leeds.ac.uk>, dn_crow@bean.open.ac.uk > (dn_crow) wrote: > > > However, the Finder disregards this: try loading an application and > > bringing it to the front, while still being able to see a finder window > > behind it. If you now click over a visible finder icon, the appropriate > > Finder window is brought to the front (correct) but the icon is > > selected (incorrect). > > The Finder is not really an application in Apple's eyes, it is the user > interface to the system. The reason an icon will stay selected when > another window is brought to the front, is to allow it to more easily copy > files from one window to another. I'm not arguing that Apple is *wrong* to make the Finder work this way: personally, I would like all applications to work like this as I find it very useful. OTOH, I can also see why you don't want to do this: there are some applications where I need to see the whole window before deciding where I click on it, and having to click on the window border to bring it to the front would be a pain. Sigh. An insoluable problem, probably. However right Apple may be in their decision, they are still inconsitent with their own HIGs (which apply to the User Interface of the whole system: Finder and applications alike). Dan +++++++++++++++++++++++++++ >From leblonk@netcom.com (Marcel Blonk) Date: Mon, 9 May 1994 09:51:40 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Maybe this should come under the header of "Apple's blatant disregard for User Opinions" In this thread there have been many complaints about the AOCE UI. Not at all unwaranted IMO. My $.02 on this: before AOCE was released, it was shown a couple of times on the WWDC. I, and many others that I've talked to, always found that the interface needed *major* changes (desktop clutter/finderlookalikebutnotthesameafterall type things). These concerns were often voiced, in the different AOCE forums and workgroups. To apple in general and to the development team in particular. Yet, it was released with all the same UI problems that people (in this case, developers mostly) complained about. What up with that???? To me it seems that Apple has entered a stage, in which the big company mentality is slowly creeping in, in which each little department has it's own little territory to defend and defend it they shall, against every one who'd dare challenge them on their terrain (just one example: how come something like AppendDITL is part of the comm toolbox! It's a generic routine, that has NOTHING to do with communications. If the CTB group wanted this routine to be added, it should have been added in a generic place, NOT the CTB toolbox. What if the already poorly supported CTB becomes extinct or replaced by something better? Would the system still have to support CTB just for the xxxDITL routines (which probably are being used by programs that have nothing to do with the CTB, since they are documented as dialog manager extensions)). We see it all the time, different systems extensions are released, and each uses its own ( different) interface philosophy. There is no consistancy between them anymore. In several workgroup discussions at the WWDC, I found that the teams showed a certain resistance to remarks coming from the developers like: "wouldn't it be better to combine/make consistant/integrate x with y" where x was developed by a different group than y (again, the AOCE group showed this quite distinctively). Is this the end of the Apple we once knew and loved? Is Apple after all, just another company grown big, rigid and more guided by internal politics than by the drive for a better product? I don't know, but that is what I fear is happening. Oops, guess I dropped a few cents more then I was planning to. mb +++++++++++++++++++++++++++ >From resnick@cogsci.uiuc.edu (Pete Resnick) Date: Mon, 09 May 1994 11:15:33 -0500 Organization: University of Illinois at Urbana-Champaign In article , u9119523@sys.uea.ac.uk (Graham Cox) wrote: >Here's a trivial example- not in the system but in most graphics programs, >including MacDraw and ClarisWorks- the guidelines say that the cursor keys >should never be used to position graphic elements, but most programs do >this. That's simply false. From the Macintosh Human Interface Guidlines, chapter 10: In a graphics application, the arrow keys can be used for fine movement of selected objects, particularly since graphics applications typically have no insertion point. If a graphics application uses arrow keys, it should be only to move the selected object by the smallest possible increment (one pixel or one grid unit). For example, the user could select an object and use the arrow keys to move one pixel per keystroke in the direction of the arrow key pressed. pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet: resnick@cogsci.uiuc.edu +++++++++++++++++++++++++++ >From resnick@cogsci.uiuc.edu (Pete Resnick) Date: Mon, 09 May 1994 11:23:16 -0500 Organization: University of Illinois at Urbana-Champaign In article <2qido4$8c4@news.kth.se>, d88-jwa@dront.nada.kth.se (Jon Wätte) wrote: >In de19@umail.umd.edu (Dana S Emery) writes: > >>disagree, the Finder already knows if a viable system is inside, it has to >>in order to show the proper icon for a system folder. > >So far so good. > >>The rest is simply a matter of searching for tagged folders and directing >>the files, and I, as a user would expect that behaviour to be consistant >>for any folder showing the blessed system icon, no matter if it was in fact >>the booted system. > >Exactly how would the Swedish Finder know about the names of the >Hindu special folders? The same way it knows what the names of the Swedish special folders are: GetResource('fld#', 0); pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet: resnick@cogsci.uiuc.edu +++++++++++++++++++++++++++ >From jfw@ksr.com (John F. Woods) Date: 9 May 1994 20:36:43 GMT Organization: Kendall Square Research johan.solve@itn.hh.se (Johan Solve) writes: >etaphors that needs to be explained (as the trashcan in the remove-disk before. He inserts a disk and wants to get it out again. I don't think he around to explain to him that "in this special case, nothing gets deleted. desktop...)" Let's remember how this came about. Originally you ejected disks by selecting Eject from the menu (or typing command-E); this left a ghost image that had to be thrown away. A lot of people asked for a short cut, and the obvious one was the one chosen. Of course, if you don't KNOW what it's a shortcut for, it does seem to mean something else. On the other hand, if you had an Ejector on the desktop, what would it mean to drag an ordinary file onto it? +++++++++++++++++++++++++++ >From maynard@elwing.otago.ac.nz (Maynard James Handley) Date: Mon, 9 May 1994 22:49:13 GMT Organization: University of Otago Tim Smith (tzs@u.washington.edu) wrote: > Quinn "The Eskimo!" wrote: > >>In the thingy that is used to select a color (get it by selecting "other..." > >>for your highlight color in the Colors control panel, or double clicking > >>on a palette entry in the pattern editor in the General control panel), > >>they use a scroll bar to set brightness. I think this violates something > >>in the User Interface Guidelines. > > > >Actually it violates the letter, *but not IMHO the spirit*, of the > >guideline that states that you should only put settings, as opposed to > >commands, in a popup menu. > I was thinking of page 215, where it says that scroll bars are *only* to > be used to manipulate the relative position in a document or list. They > explicitly say that scroll bars are not to be used where sliders should > be used. Thus, the color selector is a blatant violation. > --Tim Smith I just want to add two point. Firstly, this use of a scroll bar to select the color may seem a minor matter, but I have found it really irritating over and over. It should be fixed by Apple even if it seems silly. Secondly, Apple have been really dumb by not releasing the slider CDEF inti the system, like they did with the PopupMenu CDEF. If they added this to the system so that programmers could trivially access and use it, problems like this would go away. Maynard Handley +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Tue, 10 May 1994 11:23:03 +0800 Organization: Department of Computer Science, The University of Western Australia In article , leblonk@netcom.com (Marcel Blonk) wrote: >Is this the end of the Apple we once knew and loved? Is Apple after all, >just another company grown big, rigid and more guided by internal politics >than by the drive for a better product? I thought "guided by internal politics" *was* the Apple we once knew and loved (: -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From rmah@panix.com (Robert S. Mah) Date: Tue, 10 May 1994 01:48:31 -0500 Organization: One Step Beyond maynard@elwing.otago.ac.nz (Maynard James Handley) wrote: > Secondly, Apple have been really dumb by not releasing the slider CDEF > into the system, like they did with the PopupMenu CDEF. If they added > this to the system so that programmers could trivially access and use > it, problems like this would go away. Agreed. Also why were the little up/down arrow thingies never rolled into the system? I guess we'll never know... Also, I never did quite understand why both push buttons, radio buttons, check boxes and scroll bars were all rolled into one CDEF. If _I_ were designing things, I would have put buttons into 1, radio buttons and check boxes in another and scroll bars in a third. Good thing they didn't let me do this :-). Cheers, Rob ___________________________________________________________________________ Robert S. Mah -=- One Step Beyond -=- 212-947-6507 -=- rmah@panix.com +++++++++++++++++++++++++++ >From deguzman@binkley.math.uiuc.edu (Alan DeGuzman) Date: 10 May 1994 07:21:34 GMT Organization: Calculus&Mathematica at UIUC jfw@ksr.com (John F. Woods) writes: [snip] >On the other hand, if you had an Ejector on the desktop, what would it mean to >drag an ordinary file onto it? Nothing. If this Ejector was written only to eject volumes, the Ejector's icon would not darken if a file was dragged onto it. -- Alan A. DeGuzman "The problem with the future is that it Calculus&Mathematica keeps turning into the present." DISCLAIMER: "The University can't afford my opinions." - Calvin to Hobbes +++++++++++++++++++++++++++ >From Greg_Marriott@genmagic.com (Greg Marriott) Date: Tue, 10 May 1994 09:09:44 -0800 Organization: General Magic, Inc. rmah@panix.com (Robert S. Mah) wrote: > Also, I never did quite understand why both push buttons, radio buttons, > check boxes and scroll bars were all rolled into one CDEF. They weren't. Buttons are in one CDEF and the scrollbar is in another. > I would have put buttons into 1, radio buttons and check > boxes in another and scroll bars in a third. Separating the buttons would have been a good idea, but it's not so bad the way it is since there's a bunch of common code that is shared. -- Greg Marriott Just Some Guy General Magic, Inc. Disclaimer: My opinions are not necessarily the same as General Magic's. (can a company even HAVE an opinion?) +++++++++++++++++++++++++++ >From Jens Alfke Date: Tue, 10 May 1994 17:47:24 GMT Organization: Apple Computer Thomas Reed, reed@medicine.wustl.edu writes: > Yes, it's true that there has to be "something to be gotten", but I think > most applications these days, background or not, call WaitNextEvent, so > they can control directly how much time they get by giving different > numbers for the sleep value. Yes, but if the front app is calling WNE with a very small sleep time -- like zero -- then there will be much less time for bg apps to run unless they do something evil like running for several seconds at a time without calling WNE. The foreground app should always use a sleep time of infinity unless it needs to be doing something periodically like blink an i-beam or check for modifier key changes, and even then it should sleep at least 15 ticks or so at a time (depending on GetCaretTime, of course.) That said, does the Finder really call WNE with a zero sleep time? I'd be surprised if it did. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From Jens Alfke Date: Tue, 10 May 1994 18:17:22 GMT Organization: Apple Computer Paul Ferguson, pferguson@kaleida.com writes: > On the other hand, what the > slider is doing is changing the brightness from 0-65535, which > is exactly what the example shown on that page says is an incorrect > use of a scroll bar. That's the old color picker. If you install ColorSync you get the New & Improved, All Singing All Dancing color picker, which is much, much nicer and features sliders instead of scrollbars. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From platypus@cirrus.som.cwru.edu (Gary Kacmarcik) Date: 10 May 1994 22:11:36 GMT Organization: Case Western Reserve University, Cleveland, Ohio (USA) In article rmah@panix.com (Robert S. Mah) writes: > Also, I never did quite understand why both push buttons, radio buttons, > check boxes and scroll bars were all rolled into one CDEF. If _I_ were > designing things, I would have put buttons into 1, radio buttons and check > boxes in another and scroll bars in a third. Good thing they didn't let > me do this :-). push buttons, check boxes and radio buttons are in one CDEF (CDEF 0, with variation codes of 0, 1 and 2, respectively) scrollbars are in a separate CDEF (CDEF 1) -gary j kacmarcik platypus@cirrus.som.cwru.edu +++++++++++++++++++++++++++ >From rmah@panix.com (Robert S. Mah) Date: Tue, 10 May 1994 19:10:18 -0500 Organization: One Step Beyond Greg_Marriott@genmagic.com (Greg Marriott) wrote: > rmah@panix.com (Robert S. Mah) wrote: > > > Also, I never did quite understand why both push buttons, radio buttons, > > check boxes and scroll bars were all rolled into one CDEF. > > They weren't. Buttons are in one CDEF and the scrollbar is in another. Woops! You are quite right. I don't know why I thought that until you pointed out the error of my ways... > > I would have put buttons into 1, radio buttons and check > > boxes in another and scroll bars in a third. > > Separating the buttons would have been a good idea, but it's not so bad > the way it is since there's a bunch of common code that is shared. Yes, I understand that many compromises had to be made to fit the original Mac OS into a scant 64K of ROM and 128K of RAM. That they did it was a marvel. Cheers, Rob ___________________________________________________________________________ Robert S. Mah -=- One Step Beyond -=- 212-947-6507 -=- rmah@panix.com +++++++++++++++++++++++++++ >From DACRXL01.OURX124@tcp30.dx.deere.com (Juan Ingles) Date: Wed, 11 May 1994 15:28:57 GMT Organization: Proteus Ventures, Inc. In article <2qkpv1$e9o@news.u.washington.edu> tzs@u.washington.edu (Tim Smith) writes: > It would only have to do this when you dropped an extension, control panel, > or other magic file into a folder. For most dropping, it doesn't matter > if the destination is a System Folder, so it would not have to do more > work in the vast majority of cases. > > --Tim Smith Yes it would: It would have to check every single file to see if it was an extension, control panel, or other magic file. Juan Ingles -- Proteus Ventures, Inc. - Computer Software Consulting and Development 1514 Oriole Ave * Waterloo, IA 50701 * (319) 232-0985 +++++++++++++++++++++++++++ >From mbishop@pliny.ccs.itd.umich.edu (Michael J. Bishop) Date: 11 May 1994 18:00:02 GMT Organization: University of Michigan John F. Woods (jfw@ksr.com) wrote: : johan.solve@itn.hh.se (Johan Solve) writes: : >etaphors that needs to be explained (as the trashcan in the remove-disk : before. He inserts a disk and wants to get it out again. I don't think he : around to explain to him that "in this special case, nothing gets deleted. : desktop...)" : Let's remember how this came about. Originally you ejected disks by selecting : Eject from the menu (or typing command-E); this left a ghost image that had : to be thrown away. A lot of people asked for a short cut, and the obvious one : was the one chosen. Of course, if you don't KNOW what it's a shortcut for, : it does seem to mean something else. : On the other hand, if you had an Ejector on the desktop, what would it mean to : drag an ordinary file onto it? Here's what I think Apple should do. Let me know if you think it is good or bad. -- after I installed the Hardware system update on my powerbook, when I hit the power button, it performed the same command as if I had selected "Shut Down". It's the old "hardware/software integration" genius that Apple is famous for. Why don't they do this for the disk drive? Why don't they make a button that when pushed performs the same command as if the user selected "Put Away" from the File menu? People expect there to be an eject button like on a PC. Putting a button which triggers the software is the best compromise, I believe because it still allows Apple to do that cool hardware integration stuff but is still intuitive to the user. I personally *hate* having to select Shut Down to turn of my mac so the Hardware update was genius and much needed IMO. -- _____________________________________________________________________________ Michael Bishop "The best way to predict the future is to invent it." mbishop@umich.edu - Alan Kay +++++++++++++++++++++++++++ >From Ron_Hunsinger@bmug.org (Ron Hunsinger) Date: Wed, 11 May 94 06:26:41 PST Organization: Berkeley Macintosh Users Group To: resnick@cogsci.uiuc.edu (Pete Resnick),UUCP >In article <2qido4$8c4@news.kth.se>, d88-jwa@dront.nada.kth.se (Jon Wdtte) >wrote: > >>Exactly how would the Swedish Finder know about the names of the >>Hindu special folders? > >The same way it knows what the names of the Swedish special folders are: > > GetResource('fld#', 0); > Wouldn't work. This would only tell the Swedish Finder the names of the *Swedish* special folders. Although... If Apple was hard-pressed, I suppose the active Finder could look in the boot blocks of the other System Folder's volume to get the name of the other Finder, then open the other Finder's resource fork and get the folder names from it. And do all this only if the destination folder matches the id of the blessed folder (available from vcbFndrInfo). Might actually be doable in reasonable time, because you would only have to open the other Finder if you actually had files to disburse into special folders. >pr >-- >Pete Resnick (...so what is a mojo, and why would one be rising?) According to "The Official Scrabble Players Dictionary (Second Edition)": MOJO n, pl. -JOS or -JOES, a magic charm. I believe this is New Orleans slang, possibly of Cajun origin. In any event, "Mr. Mojo Risin" is an anagram for "Jim Morrison". Just so you'll know... -Ron Hunsinger +++++++++++++++++++++++++++ >From ruhl@du.edu (ROBERT A. UHL ) Date: Wed, 11 May 1994 22:04:07 GMT Organization: University of Denver In article <2qarlc$e1n@vixen.cso.uiuc.edu> aad@uiuc.edu writes: >alister@netcom.com (Rick Reynolds aka GreenGoo) writes: > >>>How 'bout dragging a disk to the trash to eject it? > > >>I never really thought much about this issue but I think there should >>have been a disk drive icon on the desktop, always visable but somehow >>conveying to the user that a disk is inserted. > >Uh, what about the disk's icon? Granted, it can be hidden behind windows, >but I'd rather have what *I* want to stay on top of the desktop layer >rather than some floating icons or whatever. > >>When the user wants >>to change disks they can press an "eject" button on the icon. But alas >>that brings up the problem of having a control (which woule have to be >>smaller then other controls) on a Finder icon. > >Now you're on to something. How about letting every icon that is a volume >have a 'switch' or 'button' drawn on (or near) the icon that let's you >eject the volume (eject in the sense of "Put Away"). It could even be dimmed >out for volumes that can't be "Put Away", like the startup volume. >-- >Alan A. DeGuzman Here's another idea: I've always thought that ejecting the disk should get rid of it; you know, if it's out, I can put it in the box and forget about it. Also, the 'Eject' button in the SF dialogs is not a true (IMO) eject; nothing is more annoying to be flipping through floppies on the SF dialog (which I do a lot) and, when you quit, finding a whole mess of grey floppy icons. So... I propose that 'Eject' take the place of the current 'Put Away', and that the 'spit-out-the-disk-but-keep-it-mounted' action be renamed. Not only would this be helpful in the above mentioned ways, but command-E would truly eject the ?!*% disk. -- - ------------------------------------------------------- | Bob Uhl | Spectre | Christos Anesti! | | U of D | Baron Robert von Raetzin | Alithos Anesti! | - ------------------------------------------------------- +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 12 May 94 17:14:12 +1200 Organization: University of Waikato, Hamilton, New Zealand In article <2qido4$8c4@news.kth.se>, d88-jwa@dront.nada.kth.se (Jon Wätte) writes: > > Exactly how would the Swedish Finder know about the names of the > Hindu special folders? I guess the same way it would know about the Muslim special folders, or the Christian special folders, or the Jewish ones, or the atheist ones. :-) Lawrence (born in a place long influenced by Indian culture) +++++++++++++++++++++++++++ >From pcastine@tubprz.prz.tu-berlin.de (Peter Castine) Date: Thu, 12 May 1994 11:10:49 GMT Organization: PRZ TU-Berlin In article ruhl@du.edu (ROBERT A. UHL ) writes: > >So... I propose that 'Eject' take the place of the current 'Put Away', >and that the 'spit-out-the-disk-but-keep-it-mounted' action be >renamed. Not only would this be helpful in the above mentioned ways, >but command-E would truly eject the ?!*% disk. No, no, no, no. You need the 'spit-out-the-disk-but-keep-it-mounted' feature in order to copy disks on Macs with only one floppy drive (which is surely the vast majority of machines out there). There is NOTHING to be gained by renaming menu commands in 1994. There are people out there who have been happily dragging disks to the trash for over ten years. To quote Tog: "An imporant aspect of consistency was defined by Smith et al. [1983] in this way: 'Consistency asserts that mechanisms should be used in the same way wherever they occur.' I would add, by inference, 'and _when_ever they occur': first release or fifth release." (from "Consistency", in The Art of Human-Computer Interface Design, Addison-Wesley 1990, Tog's emphasis.) We now have in the current system: 1) A menu command (w/ command-key equivalent) for ejecting a disk. 2) A menu command (w/ command-key equivalent) for ejecting AND unmounting a disk. 3) A simple mouse gesture for ejecting AND unmounting a disk. I honestly can *NOT* understand all this bitching about (3) above. If you don't want to drag the disk to the trash, then DON'T DO IT. Hit Command-Y and shut up. (BTW, despite my current .sig, this is one point where there is simply nothing to be gained by negating the principle of consistency.) -- Peter Castine | Con'sis'ten'cy (n., pl. -cies) pcastine@prz.tu-berlin.de | 1a) last refuge of the unimaginative - -----------------------------| b) hobgoblin of little minds ``Have Mac, will travel'' | (Apologies to Webster, Emerson, & Wilde) +++++++++++++++++++++++++++ >From gjw2824@hertz.njit.edu (Greg Weston) Date: 12 May 94 05:04:11 GMT Organization: New Jersey Institute of Technology, Newark, New Jersey In article <1994May5.172800.22102@bme.ri.ccf.org>, Chuck Simciak wrote: >I'm not sure if this counts as breaking an interface guideline but it is >very annonying. Say I go to save a file, the StandardPutFile dialog >emerges and I have to navigate several folders to get to my desitination. > The file name field has already been filled with a defualt. Here's the >catch. Upon having navigated the multiple folders to place the file, the >SAVE button is now an OPEN button. I then have to click in the filename >text field to cause the button to CHANGE to SAVE. This "feature" was >introduced in System 7 and has been a source of nuisance ever since. I find it tedious, too. But it is a little easier (I find) to press tab, which toggles between manipulating the list and the field, than to grab the mouse and click. (Since in that situation, I've usually had my hands on the keyboard up til then anyway.) Greg +++++++++++++++++++++++++++ >From gt7344b@prism.gatech.edu (MMMMM MMMMM) Date: 12 May 1994 11:57:20 -0400 Organization: Georgia Institute of Technology In article <1994May12.111049.29637@prz.tu-berlin.de> pcastine@tubprz.prz.tu-berlin.de (Peter Castine) writes: >In article ruhl@du.edu (ROBERT A. UHL ) writes: >I honestly can *NOT* understand all this bitching about (3) above. If >you don't want to drag the disk to the trash, then DON'T DO IT. Hit >Command-Y and shut up. > I think you're forgetting the original point of this thread. Yes, dragging a disk to the trash is quick, easy, and we all do it. But it does violate the Mac HIG. It's unintuitive. And I'm willing to admit that I was terrified the first time I tried dragging a floppy to the trash. -- /////////\ /////////\ /////////\ /////////\ /////////\ \_____// / //\____// / //\____// / //\____// / //\____// / ///////// / ///////// / ///////// / ///////// / /////////\ \_______\/ \_______\/ \_______\/ \_______\/ \_______\/ +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 12 May 1994 08:54:10 -0700 Organization: SRI International, Menlo Park, CA In article <1994May12.111049.29637@prz.tu-berlin.de> pcastine@tubprz.prz.tu-berlin.de (Peter Castine) writes: >No, no, no, no. > >You need the 'spit-out-the-disk-but-keep-it-mounted' feature in order >to copy disks on Macs with only one floppy drive (which is surely >the vast majority of machines out there). nah, what we need to implement is Andy Herzfeld (sp?) velocity feature. Pick up a disk icon with the mouse and throw it off the desktop to eject it. :-) The disk icon would then glide across the desktop and when it the icon was completly off the desktop, it would eject. Kind of like when a disk falls off your desk. If you didn't throw it hard enough it would glide to a halt some where on your desktop. Ejecting a disk should be fun! Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From sbb@panix.com (Steve Baumgarten) Date: 12 May 94 12:51:39 Organization: PANIX Public Access Unix, NYC In article <2qtjl0$ob9@acme.gatech.edu> gt7344b@prism.gatech.edu (MMMMM MMMMM) writes: I think you're forgetting the original point of this thread. Yes, dragging a disk to the trash is quick, easy, and we all do it. But it does violate the Mac HIG. No it doesn't. It's a shortcut you don't have to use. Try selecting "Put Away" from the menu; or select "Eject", and then with the disk in your hand you should have no fear of dragging the dimmed icon to the trash. It's unintuitive. And I'm willing to admit that I was terrified the first time I tried dragging a floppy to the trash. Should have tried using the menus first; that's what they're there for. If it were the Mac's sole means of ejecting a floppy, then yes, I'd agree that it's not intuitive. But a menu choice labeled "Eject" is pretty intuitive, you have to admit... -- Steve Baumgarten | "New York... when civilization falls apart, PANIX, New York, NY | remember, we were way ahead of you." | Email: sbb@panix.com | - David Letterman +++++++++++++++++++++++++++ >From pcastine@tubprz.prz.tu-berlin.de (Peter Castine) Date: Thu, 12 May 1994 17:11:36 GMT Organization: PRZ TU-Berlin gt7344b@prism.gatech.edu (MMMMM MMMMM) writes: > >pcastine@tubprz.prz.tu-berlin.de (Peter Castine) writes: >>I honestly can *NOT* understand all this bitching about (3) above. If >>you don't want to drag the disk to the trash, then DON'T DO IT. Hit >>Command-Y and shut up. >> > >I think you're forgetting the original point of this thread. Yes, >dragging a disk to the trash is quick, easy, and we all do it. But it >does violate the Mac HIG. No it doesn't. It's an extension of the Finder's interface. Take a look at HIG p. 38 ('When to go beyond the guidelines'): There are times when the standard user interface doesn't cover the needs of your application. This is true in the following situations: o Your are creating a new feature for which no element or behavior exists. In this case, you can extend the Macintosh user interface in a prescribed way. o An existing element does almost everything you need it to, but a little modification that improves its functions makes the difference to your application. The drag-disk-to-trash convention is *built on an existing interface convention.* (Cf. HIG p. 39) To repeat: the original method was to Eject (or Command-E) the disk and drag the off-line icon to the trash. >It's unintuitive. And I'm willing to admit that I was terrified the first >time I tried dragging a floppy to the trash. Gee, I dunno. I seem to remember way back in spring of '84 wondering "how do I get rid of this disk?", checking out the menus and finding Eject. Sure, I was a little surprised when the shadow of the disk stayed on the desk, but since there didn't seem to be any other appropriate menu items, I dragged the outline to the trash. A day or two later, I thought "Why not combine the two steps and drag the disk straight to the trash? This is a Mac, before something aweful happens, one of these funny message window thingies is sure to pop up and let me back out." (How many people remember the funny alert icons Apple used back then? Now, *those* were worth changing.) Nowadays, I think a lot of beginners click on that funny question mark thingie at the top right of the screen. Guess what Balloon Help says about the trash? BTW, the adjective should be 'unintuitable'. See _Tog on Interface_. Sorry, I'm getting pedantic. Admittedly, naive Mac users sometimes get nervous when they see me dragging a disk to the trash. When this happens, I also go into teacher mode, do the two-step Eject/Trash Outline procedure, demonstrate the Put Away command, and then show the one-step Trash shortcut. But I'd bet they hit on the idea in a couple of weeks on their own. Wonder which people work out faster--dragging a disk to the trash or the 'xp' trick in vi? -- Peter Castine | Con'sis'ten'cy (n., pl. -cies) pcastine@prz.tu-berlin.de | 1a) last refuge of the unimaginative - -----------------------------| b) hobgoblin of little minds ``Have Mac, will travel'' | (Apologies to Webster, Emerson, & Wilde) +++++++++++++++++++++++++++ >From Antoine Paul Brusseau Date: Thu, 12 May 1994 16:34:49 -0400 Organization: Carnegie Mellon, Pittsburgh, PA Excerpts from netnews.comp.sys.mac.programmer: 12-May-94 Re: Apple's blatant disrega.. by Peter Castine@tubprz.prz > Take a look at HIG p. 38 ('When to go beyond the guidelines'): > > There are times when the standard user interface doesn't cover the > needs of your application. This is true in the following situations: > > o Your are creating a new feature for which no element or behavior > exists. In this case, you can extend the Macintosh user interface > in a prescribed way. > > o An existing element does almost everything you need it to, but > a little modification that improves its functions makes the > difference to your application. > >The drag-disk-to-trash convention is *built on an existing interface >convention.* (Cf. HIG p. 39) To repeat: the original method was to Eject >(or Command-E) the disk and drag the off-line icon to the trash. If Apple had added a close box to disk icons, people wouldn't be declaring this a violation of HIG. The problem is, the trash icons most common analogy is that of a place one puts items in order to *PERMANENTLY DESTROY THEM*. Putting a disk in the trash, does not do this. This violates peoples expectations. Thus, it is a poor UI design decision. Whereas, a close box is used to remove an item from the desktop. Putting a close box on disk icons would have built on an existing interface convention without violating any preexisting ones (I think:). Tony +++++++++++++++++++++++++++ >From Stephen Jonke Date: 12 May 1994 22:09:24 GMT Organization: NASA GSFC Sorry if this is a repeat, but you can use "Put Away" (Command-Y) in the "File" menu to unmount a disk. I can't remember when this capabilit was added to Put Away - some version of System 7 in any case. This concept is somewhat intuitive, except that "Eject Disk" seems like it should do this and it draws the users attention. My sister has been using Eject Disk when she wants to just get the disk out and I can understand why as this seems the intuitive thing to do. Does anyone every use "Eject Disk" in its current form intentionally any more? Seems like the simple solution is to change it's functionality so that it unmounts the disk without leaving the ghost icon on the desktop, as one would expect. Keep the drag to trash alternative since lots of Mac users are use to that. And then have it so that if you select a floppy disk and pick "Duplicate" it does the floppy copying shennanigans. Doesn't this make a heck of a lot more sense? Steve - ------------------- jonke@gsfc.nasa.gov - ------------------- +++++++++++++++++++++++++++ >From pcastine@tubprz.prz.tu-berlin.de (Peter Castine) Date: Fri, 13 May 1994 08:38:56 GMT Organization: PRZ TU-Berlin mbishop@pliny.ccs.itd.umich.edu (Michael J. Bishop) writes: > >Here's what I think Apple should do. Let me know if you think it is good >or bad. > >-- after I installed the Hardware system update on my powerbook, when I >hit the power button, it performed the same command as if I had selected >"Shut Down". It's the old "hardware/software integration" genius that >Apple is famous for. > >Why don't they do this for the disk drive? Why don't they make a button >that when pushed performs the same command as if the user selected "Put >Away" from the File menu? > >People expect there to be an eject button like on a PC. Putting a button >which triggers the software is the best compromise, I believe because it >still allows Apple to do that cool hardware integration stuff but is >still intuitive to the user. There is a question of cost. Anyone care to estimate what that would add to the price of a Mac? A simple mechanical switch isn't going to do the trick, you need something that will send a signal to the logic board, etc. And don't forget that adding, say $5, to manufacturing costs means a three digit price increse for the consumer. Still, it's not a bad idea. But see my next comment. >I personally *hate* having to select Shut Down to turn of my mac so the >Hardware update was genius and much needed IMO. Using the power switch as a shortcut for Shut Down makes sense on a PowerBook for two reasons: 1) the switch already has the necessary connections to the logic board (you couldn't do this on an SE, where the power switch simply cuts of the power supply) and 2) you can normally reach the switch on a PB without any inconvenience. Many Quadra and Mac II boxes are stuck under a desk (and with them the diskette drives)--in this configuration, menu commands are considerably more convenient. And, although I use the PowerKey extension so I can drop into MacsBugs from the keyboard, I don't really want to have the Shut Down command anywhere on my keyboard--too easy to hit by accident (of course, some people *do* map some key combinations to the Shut Down command... and one of them wrote an extension so that Shut Down produces an Alert "Do you really want to shut down now?" because he hit the key combination by accident too often. This is progress :-? ) I'm not sure if it's possible for an extension to catch the signal sent by the power switch on the Mac II family and cause it to initiate the Shut Down sequence. Now that the subject has been on the net, I expect somebody will try. ;-) -- Peter Castine | Con'sis'ten'cy (n., pl. -cies) pcastine@prz.tu-berlin.de | 1a) last refuge of the unimaginative - -----------------------------| b) hobgoblin of little minds ``Have Mac, will travel'' | (Apologies to Webster, Emerson, & Wilde) +++++++++++++++++++++++++++ >From pcastine@tubprz.prz.tu-berlin.de (Peter Castine) Date: Fri, 13 May 1994 09:07:26 GMT Organization: PRZ TU-Berlin Antoine Paul Brusseau writes: > > If Apple had added a close box to disk icons, people wouldn't be >declaring this a violation of HIG. The problem is, the trash icons most >common analogy is that of a place one puts items in order to >*PERMANENTLY DESTROY THEM*. *NO IT DOES NOT*. Drag some files to the trash. See the trash can get fat. Open the trash. There are your files. Select a file. Use the Put Away command. Hey, presto-the file is back where it came from. Drag another file onto the desktop. There it is--this is not permanent destruction. This is a Mac, not an Atari. Selecting "Empty Trash" permanently destroys the file (well, for most users it's close enough to destruction). You also get an alert warning you of this (just like HIG advises). > Putting a disk in the trash, does not do >this. This violates peoples expectations. Thus, it is a poor UI design >decision. Whereas, a close box is used to remove an item from the >desktop. Putting a close box on disk icons would have built on an >existing interface convention without violating any preexisting ones (I >think:). A disk icon is a fairly small object. 32x32 pixels. A close box is also a small object. 10x10 pixels. That's 10% of a disk icon. 10% is actually a lot (particularly nowadays, with custom disk icons that have rockets shooting out of them). [As a footnote, Fitt's law would indicate that it takes about three times as long to move the mouse to a close box as it does to move the mouse to grab a disk icon for dragging. Someone want to do a comparison of these two alternatives for un-mounting a disk a la Card et.al.'s _The Psychology of Human-Computer Interaction_?] I'm not saying that the suggestion to add a close box is a bad one. However, I think it needs to be thought through more thoroughly. -- Peter Castine | Con'sis'ten'cy (n., pl. -cies) pcastine@prz.tu-berlin.de | 1a) last refuge of the unimaginative - -----------------------------| b) hobgoblin of little minds ``Have Mac, will travel'' | (Apologies to Webster, Emerson, & Wilde) +++++++++++++++++++++++++++ >From pcastine@tubprz.prz.tu-berlin.de (Peter Castine) Date: Fri, 13 May 1994 09:28:02 GMT Organization: PRZ TU-Berlin Stephen Jonke writes: >Sorry if this is a repeat, but you can use "Put Away" (Command-Y) in the >"File" menu to unmount a disk. I can't remember when this capabilit was >added to Put Away - some version of System 7 in any case. 7.0d1, if I'm not mistaken. As far as users are concerned, since day 1 A.S. (anno septimum, or whatever the Latin would be :) > This concept >is somewhat intuitive, except that "Eject Disk" seems like it should do >this and it draws the users attention. My sister has been using Eject >Disk when she wants to just get the disk out and I can understand why as >this seems the intuitive thing to do. Does anyone every use "Eject Disk" >in its current form intentionally any more? Yes!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Constantly. > Seems like the simple >solution is to change it's functionality No. Changing functionality of commands between software versions is one of the worst possible violations of human interface design concievable. Think about it--what would happen if Ford swapped the position of the emergency brake and the gear shift. Or, if you're using automatic transmission, how about swapping the gas pedal and the brake. Think about it--do you really want to have to check the system software version every time you sit down at a new Mac so that you know which command configuration you've got? >so that it unmounts the disk >without leaving the ghost icon on the desktop, as one would expect. Keep >the drag to trash alternative since lots of Mac users are use to that. >And then have it so that if you select a floppy disk and pick "Duplicate" >it does the floppy copying shennanigans. Doesn't this make a heck of a >lot more sense?a System 8 might extend Duplicate to copying disks. I rather expect not, since the current trend in the interface is towards enhanced use of mouse gestures (there will be less Cut/COpy/Paste as drag-and-drop is implemented in more and more applications). In fact, the mouse gesture for copying disks was one of the earliest implementations of drag-and-drop on Macintosh. -- Peter Castine | Con'sis'ten'cy (n., pl. -cies) pcastine@prz.tu-berlin.de | 1a) last refuge of the unimaginative - -----------------------------| b) hobgoblin of little minds ``Have Mac, will travel'' | (Apologies to Webster, Emerson, & Wilde) +++++++++++++++++++++++++++ >From D.A.G.Gillies@bradford.ac.uk (David Gillies) Date: Fri, 13 May 1994 12:25:46 GMT Organization: Unseen University, Ankh-Morpork In article ruhl@du.edu (ROBERT A. UHL ) writes: >Here's another idea: >I've always thought that ejecting the disk should get rid of it; you >know, if it's out, I can put it in the box and forget about it. Also, >the 'Eject' button in the SF dialogs is not a true (IMO) eject; >nothing is more annoying to be flipping through floppies on the SF >dialog (which I do a lot) and, when you quit, finding a whole mess of >grey floppy icons. >So... I propose that 'Eject' take the place of the current 'Put Away', >and that the 'spit-out-the-disk-but-keep-it-mounted' action be >renamed. Not only would this be helpful in the above mentioned ways, >but command-E would truly eject the ?!*% disk. > Of course 'Eject' ejects the disk. It enables you to remove it from the disk drive, doesn't it? That fits any reasonable definiton of eject in my book. It takes most people with an IQ higher than that of a potato to realise the difference between 'Eject', and 'Put Away'. For those amongst us who are not completely illiterate, the distinction is also pointed out in *the manual* (you know, that big thick ring-bound thing that is put on one side by MacBozos and never read, thereby generating 98% of tech support traffic, and giving rise to those 'Tricks'n'Tips' columns in magazines, full of things like "did you know that if you hold down the option key when opening a folder, the parent folder will disappear?") Changing the way this works now would only serve to confuse the people who extracted their heads from their arses long enough to actually understand how to use a Mac. Keeping volumes mounted is a time-saving feature. If you had to wait the twenty seconds or so it takes to mount a floppy every time you popped one out of the slot in the Standard File dialog, you'd go mad. It's not perfect, but until someone comes up with abetter solution we're stuck with it. ______________________________________________________________________ David A. G. Gillies (D.A.G.Gillies@bradford.ac.uk) University of Bradford, Bradford, West Yorkshire, England (c) 1994 Wittgenstein and The Furniture Depository of The Living Dead A little learning is a dangerous thing - but not half as dangerous as a lot of ignorance. - ---------------------REPLIES VIA EMAIL PLEASE----------------------- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ +++++++++++++++++++++++++++ >From D.A.G.Gillies@bradford.ac.uk (David Gillies) Date: Fri, 13 May 1994 12:30:48 GMT Organization: Unseen University, Ankh-Morpork In article <2qtjf2$4us@unix.sri.com> mxmora@unix.sri.com (Matt Mora) writes: >In article <1994May12.111049.29637@prz.tu-berlin.de> pcastine@tubprz.prz.tu-berlin.de (Peter Castine) writes: > >>No, no, no, no. >> >>You need the 'spit-out-the-disk-but-keep-it-mounted' feature in order >>to copy disks on Macs with only one floppy drive (which is surely >>the vast majority of machines out there). > >nah, what we need to implement is Andy Herzfeld (sp?) velocity >feature. Pick up a disk icon with the mouse and throw it off the desktop >to eject it. :-) The disk icon would then glide across the desktop and when it >the icon was completly off the desktop, it would eject. Kind of like when >a disk falls off your desk. > >If you didn't throw it hard enough it would glide to a halt some where on >your desktop. > >Ejecting a disk should be fun! > Great idea! Anyone want to write this? It could be a bit tricky... ______________________________________________________ David A. G. Gillies (D.A.G.Gillies@bradford.ac.uk) (c) 1994 Wittgenstein's Amazing Underwater Supermarket _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ +++++++++++++++++++++++++++ >From Antoine Paul Brusseau Date: Fri, 13 May 1994 09:30:06 -0400 Organization: Carnegie Mellon, Pittsburgh, PA Excerpts from netnews.comp.sys.mac.programmer: 13-May-94 Re: Apple's blatant disrega.. by Peter Castine@tubprz.prz > > If Apple had added a close box to disk icons, people wouldn't be > >declaring this a violation of HIG. The problem is, the trash icons most > >common analogy is that of a place one puts items in order to > >*PERMANENTLY DESTROY THEM*. > > *NO IT DOES NOT*. Drag some files to the trash. See the trash can > get fat. Open the trash. There are your files. Select a file. Use > the Put Away command. Hey, presto-the file is back where it came > from. Drag another file onto the desktop. There it is--this is > not permanent destruction. I think you misread my post. I said "in order to *PERMANENTLY DESTOY THEM*", not "so that they are *IMMEDIATELY DESTROYED*". To further the analogy, if I put an object from my desk into the rubish bin, it is not immediately destroyed. If I choose, I can take the object out any time before the cleaning staff comes. This is the correct analogy, and it is followed consistently with file icons. Putting a floppy disk into the trash in order to eject it does not follow this analogy. This is the point of my previous post. Tony +++++++++++++++++++++++++++ >From dowdy@apple.com (Tom Dowdy) Date: Fri, 13 May 1994 15:40:32 GMT Organization: Apple Computer, Inc. In article , cwiltgen@mcs.com (Charles Wiltgen) wrote: > In article <16674@lhdsy1.lahabra.chevron.com>, > jjvbl@lhdsy1.lahabra.chevron.com (John V. Blzka) wrote: > > > Hello, > > I've been working on a presentation on Human Factors Engineering. > > I am using Apple's User Interface Guidelines as an example. > > What I would like to know is: > > Does Apple violate it's own Guidelines in any of it's System 7 > > software? > > If so, can I easily demonstrate it? > > How 'bout dragging a disk to the trash to eject it? I'm not sure how this is a direct violation of the UI guidelines (and maybe it is)...It *is* probably a non-intuative feature, that wasn't well thought out for first implementation. However, I'd like to ask you if you now use the "Put Away" menu item in System 7, which performs the same function. Or, do you continue to drag the disk to the trash. If you continue to drag the disk to the trash -- why? If we took away that feature, would you complain? -- Tom Dowdy Internet: dowdy@apple.COM Apple Computer MS:302-3KS UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy 1 Infinite Loop AppleLink: DOWDY1 Cupertino, CA 95014 "The 'Ooh-Ah' Bird is so called because it lays square eggs." +++++++++++++++++++++++++++ >From mbishop@ovid.ccs.itd.umich.edu (Michael J. Bishop) Date: 13 May 1994 16:28:51 GMT Organization: University of Michigan Peter Castine (pcastine@tubprz.prz.tu-berlin.de) wrote: : mbishop@pliny.ccs.itd.umich.edu (Michael J. Bishop) writes: : Anyone care to estimate what that would add to the price of a Mac? : A simple mechanical switch isn't going to do the trick, you need : something that will send a signal to the logic board, etc. : And don't forget that adding, say $5, to manufacturing costs means : a three digit price increse for the consumer. : Still, it's not a bad idea. But see my next comment. : >I personally *hate* having to select Shut Down to turn of my mac so the : >Hardware update was genius and much needed IMO. : Using the power switch as a shortcut for Shut Down makes sense on a : PowerBook for two reasons: 1) the switch already has the necessary : connections to the logic board (you couldn't do this on an SE, where : the power switch simply cuts of the power supply) and 2) you can : normally reach the switch on a PB without any inconvenience. Many : Quadra and Mac II boxes are stuck under a desk (and with them the : diskette drives)--in this configuration, menu commands are considerably : more convenient. And, although I use the PowerKey extension so I : can drop into MacsBugs from the keyboard, I don't really want to : have the Shut Down command anywhere on my keyboard--too easy : to hit by accident (of course, some people *do* map some key : combinations to the Shut Down command... and one of them wrote : an extension so that Shut Down produces an Alert "Do you really : want to shut down now?" because he hit the key combination by : accident too often. This is progress :-? ) Ah ha! I can build on that. The ergonomic keyboard comes with an extension which allows the keyboard to switch the volume up and down. How hard would it be to use one of those "new" keys to eject the disk? Then both the power key and the "put away" key are both accessible from the keyboard. Apple adds new keys all the time that do cool new things. I think they could have added a "put away" key. : -- : Peter Castine | Con'sis'ten'cy (n., pl. -cies) : pcastine@prz.tu-berlin.de | 1a) last refuge of the unimaginative : -------------------------------| b) hobgoblin of little minds : ``Have Mac, will travel'' | (Apologies to Webster, Emerson, & Wilde) -- _____________________________________________________________________________ Michael Bishop "The best way to predict the future is to invent it." mbishop@umich.edu - Alan Kay +++++++++++++++++++++++++++ >From mwalker@netcom.com (Mel Walker) Date: Fri, 13 May 1994 16:37:17 GMT Organization: Committee to Elect Dan Quayle Lord of the Cosmos Antoine Paul Brusseau (ab2y+@andrew.cmu.edu) wrote: : If Apple had added a close box to disk icons, people wouldn't be : declaring this a violation of HIG. The problem is, the trash icons most : common analogy is that of a place one puts items in order to : *PERMANENTLY DESTROY THEM*. No, the common analogy is that one puts items into a trash can in order to *GET RID OF THEM*. Thus, when I want to get rid of a disk, I throw it in the trash. I does not violate my expectations in the slightest. : Putting a disk in the trash, does not do : this. This violates peoples expectations. Thus, it is a poor UI design : decision. Whereas, a close box is used to remove an item from the : desktop. Putting a close box on disk icons would have built on an : existing interface convention without violating any preexisting ones (I : think:). What happens when you double-click on the disk to open it, and hit the close box? Since the close box would take a sizeable amount of the disk icon, I figure that it would happen quite a bit. In addition, the close box would interfere with my cool custom icons. :-) Just out of curiousity, are there any GUIs that put close boxes on a disk icon? -- Mel Walker mwalker@netcom.com +++++++++++++++++++++++++++ >From Stephen Jonke Date: 13 May 1994 17:47:43 GMT Organization: NASA GSFC In article <1994May13.092802.16931@prz.tu-berlin.de> Peter Castine, pcastine@tubprz.prz.tu-berlin.de writes: >Changing functionality of commands between software versions >is one of the worst possible violations of human interface design >concievable. Think about it--what would happen if Ford swapped the >position of the emergency brake and the gear shift. Or, if you're >using automatic transmission, how about swapping the gas pedal >and the brake. I disagree with this opinion. You can't compare these two things, because the consequences are quite drastically different. If you do what you suggest with cars, people can be killed. If you do what I suggest with Empty Trash and duplicate, you risk people being annoyed once or twice, then seeing that it's better and being happy with it. That's not much of risk and there is great reward. If lots of people use the current Eject Disk functionality for things other then copying, then they could throw in a new command that does this (offhand I can't think of a name) that is NOT "Eject Disk". You can go overboard with consistency and this is a perfect example. You are being consistent with something that was wrong to start with. That is a greater mistake, IMHO. Plus, Apple's goal these days is to attract NEW Mac users and if there are quirks like the Eject Disk "feature", they are going to pick these out and say "boy, this is stupid, I'm going back to my PC which is just as good" (not that this is true, but we are talking about PC users who are confinced their PCs are just as good! :) Actually, here's another alternative that would be a better, but not as good as my first suggestion. Keep Eject Disk and have it appear to do the same as usual, but make it so that it no longer asks you to put the disk in if you shutdown (or whatever.) Also, you should be able to drag the greyed disk icon to the trash similarly. This is actually the way it use to work anyway, right? Steve - ------------------- jonke@gsfc.nasa.gov - ------------------- +++++++++++++++++++++++++++ >From David Casseres Date: Fri, 13 May 1994 17:46:08 GMT Organization: Apple Computer, Inc. In article Tom Dowdy, dowdy@apple.com writes: > I'm not sure how this is a direct violation of the UI guidelines > (and maybe it is)...It *is* probably a non-intuative feature, > that wasn't well thought out for first implementation. > > However, I'd like to ask you if you now use the "Put Away" menu > item in System 7, which performs the same function. Or, do > you continue to drag the disk to the trash. If you continue > to drag the disk to the trash -- why? If we took away > that feature, would you complain? I bet anything that if we took away that feature there would be howls of rage from so many people that we'd put it right back in as quickly as possible. I was around when this was invented, and I guarantee that everyone knew it was unintuitive, and thought hard about it. But everyone also knew that there really had to be a way to eject a diskette with just a simple mouse gesture, and no one could come up with a better way to do it. There are lots of things about GUI design that simply can't be accounted for in guidelines. For example, when you drag a file from one folder to another, it disappears from its original location and appears in the new location. *Except*... if you are dragging it from one disk to another then it doesn't disappear from the original location. It's completely inconsistent and not even intuitive, but it's *right*. We know this because on the Lisa it worked the other way, and the file was erased from its original disk after being copied to the new one. And this turned out to be *wrong*, even though it was consistent and intuitive. Sometimes even the best guidelines need to be blatantly disregarded. - ----------- David Casseres Exclaimer: Hey! +++++++++++++++++++++++++++ >From resnick@cogsci.uiuc.edu (Pete Resnick) Date: 13 May 1994 18:44:39 GMT Organization: University of Illinois at Urbana Ron_Hunsinger@bmug.org (Ron Hunsinger) writes: >resnick@cogsci.uiuc.edu (Pete Resnick) writes: >>In article <2qido4$8c4@news.kth.se>, d88-jwa@dront.nada.kth.se (Jon Wdtte) >>wrote: >> >>>Exactly how would the Swedish Finder know about the names of the >>>Hindu special folders? >> >>The same way it knows what the names of the Swedish special folders are: >> >> GetResource('fld#', 0); >> >Wouldn't work. This would only tell the Swedish Finder the names of the >*Swedish* special folders. Although... >If Apple was hard-pressed, I suppose the active Finder could look in >the boot blocks of the other System Folder's volume to get the name of >the other Finder, then open the other Finder's resource fork and get the >folder names from it. And do all this only if the destination folder >matches the id of the blessed folder (available from vcbFndrInfo). I think you are getting confused here. The question is, if I drag to a non-blessed system folder, why can't the Finder figure out where to put the files? To realize it's a legitamate (albeit unblessed) system folder in the first place, you must *already* notice that there is a System and a Finder in that folder. You don't need to go looking in boot blocks to figure that out; you simply need to look at file types. Once you discover that there are appropriate System and Finder files using the file types, you can then open the appropriate one (I forget whether the fld# is in the System or the Finder; I believe it's the former) and do the GetResource from that file (I guess using Get1Resource instead of GetResource actually). You won't get the ones from the Swedish system since the Hindu (or whatever) system is the current resource file. It doesn't have to be the blessed folder since any system folder will be reasonable to put things into appropriate places. Right? pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet: resnick@cogsci.uiuc.edu +++++++++++++++++++++++++++ >From peirce@outpost.SF-Bay.org (Michael Peirce) Date: 13 May 94 00:44:48 GMT Organization: Peirce Software, Inc. In article (comp.sys.mac.advocacy,comp.sys.mac.programmer), zig@wc.novell.com (Zig Zichterman) writes: > One place Apple violates its suggested guidelines in in the Finder's > "About This Macintosh..." menu item. The Mac HI Guidelines book (pages 67-70) > suggests that the ellipsis (...) should appear only on menu items that > require *additional* information before they can complete (such as > choosing a file from an Open... dialog, or setting up options in a > Preferences... dialog, and so on). For menu items that execute without > further information from the user, such as Cut, Copy, showing an About > box, and so on, the ellipsis should not appear. > > After 10 years of tradition, who's going to really remove the ellipsis > from their "About..." menu? I've always interpretted the presence of an ellipsis to mean a dialog will be called up, i.e. something will interupt you focus on the current window. Or more specifically, you'll have to do something to get back to where you were. With this interpretation, the About... is correct. __ Michael Peirce __ peirce@outpost.sf-bay.org __ Peirce Software, Inc. __ 719 Hibiscus Place, Suite 301 __ __ San Jose, California USA 95117-1844 __ Makers of: Smoothie & __ voice: +1.408.244.6554 fax: +1.408.244.6882 __ Peirce Print Tools __ AppleLink: peirce & AOL: AFC Peirce +++++++++++++++++++++++++++ >From Antoine Paul Brusseau Date: Fri, 13 May 1994 15:42:40 -0400 Organization: Carnegie Mellon, Pittsburgh, PA Excerpts from netnews.comp.sys.mac.programmer: 13-May-94 Re: Apple's blatant disrega.. by Mel Walker@netcom.com > No, the common analogy is that one puts items into a trash can in order > to *GET RID OF THEM*. Thus, when I want to get rid of a disk, I throw it > in the trash. I does not violate my expectations in the slightest. Unfortunately, the most common consequence of getting rid of something is that it is permanently destroyed (i.e., the trash icon is most often used to destroy files). Thus, the association in many peoples' minds is a place where one puts an item in order to permanently destroy it. The reason I bring this up, is that more than a few people that I've taught to use Apple computers have been shocked that putting a disk in the trash can is the easiest way of ejecting a disk. Several non-technically oriented people I know actively balk at using this feature because they are afraid their data is going to be erased (no matter how many times I reassure them it isn't). Philosophically and empirically, the evidence indicates that this feature is more than a little dubious as a UI shortcut. Since many people including myself make extended use of this feature, it is obviously desirible to have a UI shortcut for ejecting a disk (menus are just too incovenient and command-y is too arcane). That's why I think some other method (that doesn't violate common expectations), such as having a close button on ejectable media volumes or dragging ejectable media icons off the desktop, as a way of ejecting them is preferable. Tony +++++++++++++++++++++++++++ >From Antoine Paul Brusseau Date: Fri, 13 May 1994 15:55:08 -0400 Organization: Carnegie Mellon, Pittsburgh, PA Excerpts from netnews.comp.sys.mac.programmer: 13-May-94 Re: Apple's blatant disrega.. by David Casseres@apple.com > Sometimes even the best guidelines need to be blatantly disregarded. That's by far the best argument I've heard in support of dragging icons into the trash. But what about putting a close box on (or near) floppy icons, or dragging them off the desktop in order to eject them? Both of these methods sound intuitive and consistent (at least superficially). Tony +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 14 May 94 04:04:01 MST Organization: (none) In article , Antoine Paul Brusseau writes: > If Apple had added a close box to disk icons, people wouldn't be > declaring this a violation of HIG. The problem is, the trash icons most > common analogy is that of a place one puts items in order to > *PERMANENTLY DESTROY THEM*. Putting a disk in the trash, does not do > this. This violates peoples expectations. Thus, it is a poor UI design > decision. Whereas, a close box is used to remove an item from the > desktop. Putting a close box on disk icons would have built on an > existing interface convention without violating any preexisting ones (I > think:). > > Tony Now figger out how to make sure that the close box was clicked on and the user wasn't trying to either select or open the file... Lawson +++++++++++++++++++++++++++ >From pcastine@jake.prz.tu-berlin.de (Peter Castine) Date: Sat, 14 May 1994 10:31:04 GMT Organization: PRZ TU-Berlin Antoine Paul Brusseau writes: >...more than a few people that I've taught >to use Apple computers have been shocked that putting a disk in the >trash can is the easiest way of ejecting a disk. Several non-technically >oriented people I know actively balk at using this feature because they >are afraid their data is going to be erased (no matter how many times I >reassure them it isn't). So, what do the people do instaed of dragging the disk to the trash? Before System 7.0, the alternative was to Eject and then trash the shadow. Did users back then (or the 40% of machines still running System <7) keep on doing this? Or did they get used to the idea of the shortcut? (Anybody have any data on this? Experience? Anecdotes?) Do new users running System 7.x still keep to the Put Away command (or the keyboard equivalent)? Or do they find the mouse gesture more convenient? When I've done Mac training (this is, admittedly, a while ago), I always demonstrated the two-step method first, which seemed not to bother people (except that it took two steps). *THEN* I showed the disk-to-trash shortcut. SOme people like it. Some people get used to it. Others don't. HIG lists no less than five different flavors of consistency. Only one of these is consistency with people's expectations. Meeting the expectations of ALL users is impossible (HIG is coy on this one, and just says "it's difficult to meet the expectations of everyone." It ain't difficult. It's 'mpossible.) Take the following example: I've trained people who expected the backspace key to work like the left arrow (move the I-beam cursor to the left in text editing without deleting characters). Why? Because that's the way most typewriters work. How about this: Teach people who've never worked with a computer before how to use a spreadsheet. They will invariably type 'x' instead of '*' for multiplication. Sorry for the continuing sermon. I really just wanted to know how long it takes people to become comfortable with the disk- to-trash shortcut. I suspect that (with the exception of those who have been forced to work with a Mac and are determined to hate any aspect of it they can), the time is resonably short. -- Peter Castine | Con'sis'ten'cy (n., pl. -cies) pcastine@prz.tu-berlin.de | 1a) last refuge of the unimaginative - -----------------------------| b) hobgoblin of little minds ``Have Mac, will travel'' | (Apologies to Webster, Emerson, & Wilde) +++++++++++++++++++++++++++ >From pcastine@jake.prz.tu-berlin.de (Peter Castine) Date: Sat, 14 May 1994 10:39:02 GMT Organization: PRZ TU-Berlin >Excerpts from netnews.comp.sys.mac.programmer: 13-May-94 Re: Apple's >blatant disrega.. by David Casseres@apple.com >> Sometimes even the best guidelines need to be blatantly disregarded. ~~~~~~~~~ No. The guidelines (all eleven of 'em, as well as a few other unstated concerns such as efficiency and convenience for the user, as well as cost and time for the developers) have to be balanced with one another. -- Peter Castine | Con'sis'ten'cy (n., pl. -cies) pcastine@prz.tu-berlin.de | 1a) last refuge of the unimaginative - -----------------------------| b) hobgoblin of little minds ``Have Mac, will travel'' | (Apologies to Webster, Emerson, & Wilde) +++++++++++++++++++++++++++ >From bizarre@leland.stanford.edu (Bruce Templeton) Date: Sat, 14 May 1994 13:51:42 -0800 Organization: Stanford University In article <1994May14.103104.5587@prz.tu-berlin.de>, pcastine@jake.prz.tu-berlin.de (Peter Castine) wrote: > So, what do the people do instaed of dragging the disk to the trash? > Before System 7.0, the alternative was to Eject and then trash the > shadow. Did users back then (or the 40% of machines still running > System <7) keep on doing this? Or did they get used to the idea of > the shortcut? (Anybody have any data on this? Experience? Anecdotes?) > Sorry for the continuing sermon. I really just wanted to know > how long it takes people to become comfortable with the disk- > to-trash shortcut. I suspect that (with the exception of > those who have been forced to work with a Mac and are determined > to hate any aspect of it they can), the time is resonably short. I'm embarassed to admit, I had my Mac Plus for *two years* before I realized that you could get rid of the ghost disk by dragging it to the trash. I just sat there and swapped disks until it let me go. When I got too many ghost disks on my desktop, I restarted my computer. Note that I was a very novice user, and did not know anyone else who had a Macintosh. I was very jealous of my friends who had eject buttons on their PC's. When I got to college, someone dragged my disk with a paper on it to the trash and I almost had a heart attack. As far as shortcuts go, Apple actually removed the one I really liked with the introduction of System 7. You could type Command-Option-E and hold the option key down until the disk ejected and the ghost would disappear. With the Put Away command, you have to select the disk with the mouse before it works. Yup, Apple screwed up ejecting pretty bad. -Bruce -- |*Bruce Templeton ______________ *| |*bizarre@leland.stanford.edu DFOTB /______________/|*| |*Disclaimer: The statements above reflect the | o o o | |*| |*opinions of virtually everyone I have ever met. |_____________|/ *| +++++++++++++++++++++++++++ >From oster@netcom.com (David Phillip Oster) Date: Sat, 14 May 1994 23:02:06 GMT Organization: Netcom Online Communications Services (408-241-9760 login: guest) After all these years, surely the finder could have a little more Undo for +++++++++++++++++++++++++++ >From tzs@u.washington.edu (Tim Smith) Date: 14 May 1994 05:39:07 GMT Organization: University of Washington School of Law, Class of '95 Speaking of how manipulating things on the screen should be fun, surely I'm not the only one who wants to be able to move the cursor by having commands for "rotate left", "rotate right", and "thrust", am I? --Tim Smith +++++++++++++++++++++++++++ >From shimpei@leland.Stanford.EDU (Shimpei Yamashita) Date: 15 May 1994 09:32:28 GMT Organization: Stanford University, CA 94305, USA In article <1994May13.122546.950@bradford.ac.uk>, David Gillies wrote: :Of course 'Eject' ejects the disk. It enables you to remove it from the disk :drive, doesn't it? That fits any reasonable definiton of eject in my book. :It takes most people with an IQ higher than that of a potato to realise :the difference between 'Eject', and 'Put Away'. For those amongst us who are :not completely illiterate, the distinction is also pointed out in *the manual* I've been using System 6 on a Plus since 1988. I saw System 7 for the first time when I came to college, and I freely admit that it took me about six months to realize that "Put Away" is the menu equivalent of dragging the disk to the trash. It *is* counterintuitive that "ejecting the disk" and "restoring files to their original folders" fall under the same command, IMHO. And no, I could not have read the manual since they don't have System 7 manuals lying around in the computer clusters.... -- Shimpei Yamashita, Stanford University shimpei@leland.stanford.edu +++++++++++++++++++++++++++ >From stk@uropax.contrib.de (Stefan Kurth) Date: 9 May 1994 02:13:04 +0200 Organization: Contributed Software GbR Speaking of arrow keys in lists: what would be the correct behaviour when the user types down-arrow, but nothing is currently selected? Should the topmost or the bottom-most item be selected? The standard file package behaves different from finder windows in this regard, which is a really annoying inconsistency, if you ask me. _____________________________________________________________________ Stefan Kurth Berlin, Germany stk@contrib.de +++++++++++++++++++++++++++ >From gdl@stlawrence.maths (Greg Landweber) Date: 15 May 1994 21:41:25 GMT Organization: (none) In article <2qjv6g$cj4@uropax.contrib.de> stk@uropax.contrib.de (Stefan Kurth) writes: Speaking of arrow keys in lists: what would be the correct behaviour when the user types down-arrow, but nothing is currently selected? Should the topmost or the bottom-most item be selected? The standard file package behaves different from finder windows in this regard, which is a really annoying inconsistency, if you ask me. I'm not 100% sure, but I think that in such a situation the arrow keys do nothing. I'm using the ArrowKeyInList routine straight out of More Macintosh Toolbox, and it returns empty handed when passed a list with no current selection. Of course, the sample code and the documentation may not agree (and I seem to recall that the sample code had a few bugs). -- Greg gdl@maths.ox.ac.uk +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Mon, 16 May 1994 16:41:52 +1200 (NZST) Organization: (none) dowdy@apple.com (Tom Dowdy) writes: > However, I'd like to ask you if you now use the "Put Away" menu > item in System 7, which performs the same function. Or, do > you continue to drag the disk to the trash. I can't remember the last time I dragged a disk to the trash. It's always -Y for me. +++++++++++++++++++++++++++ >From ruhl@du.edu (ROBERT A. UHL ) Date: Mon, 16 May 1994 17:24:43 GMT Organization: University of Denver In article <2qtjl0$ob9@acme.gatech.edu> gt7344b@prism.gatech.edu (MMMMM MMMMM) writes: >In article <1994May12.111049.29637@prz.tu-berlin.de> pcastine@tubprz.prz.tu-berlin.de (Peter Castine) writes: >>In article ruhl@du.edu (ROBERT A. UHL ) writes: >>I honestly can *NOT* understand all this bitching about (3) above. If >>you don't want to drag the disk to the trash, then DON'T DO IT. Hit >>Command-Y and shut up. >> I'd like to say that the above quote belongs to Peter castine, not me; the poster misquoted. The quote is not at all my style. -- - ------------------------------------------------------- | Bob Uhl | Spectre | Christos Anesti! | | U of D | Baron Robert von Raetzin | Alithos Anesti! | - ------------------------------------------------------- +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Tue, 17 May 1994 18:14:49 +1200 (NZST) Organization: (none) stk@uropax.contrib.de (Stefan Kurth) writes: > Speaking of arrow keys in lists: what would be the correct behaviour when > the user types down-arrow, but nothing is currently selected? Should the > topmost or the bottom-most item be selected? The standard file package > behaves different from finder windows in this regard, which is a really > annoying inconsistency, if you ask me. It annoys me too. I much prefer getting the topmost item in this situation, and that's how I write my own programs. I think Finder windows are the *only* place it happens the other way around, and it's stupid. Think how you select the third (say) item in a list. In the Finder you need to hit the up arrow once, then down twice. Anywhere else you just hit down three times (or hold the key down for items further down the list). -- Bruce +++++++++++++++++++++++++++ >From jdc0864@u.cc.utah.edu (Jeff Croft) Date: 17 May 1994 01:31:02 -0600 Organization: University Of Utah Computer Center David Gillies (D.A.G.Gillies@bradford.ac.uk) wrote: : Keeping volumes mounted is a time-saving feature. If you had to wait the : twenty seconds or so it takes to mount a floppy every time you popped one out : of the slot in the Standard File dialog, you'd go mad. It's not perfect, but : until someone comes up with abetter solution we're stuck with it. Gee. It's too bad that it takes that long to mount a floppy. Jeff +++++++++++++++++++++++++++ >From Ron_Hunsinger@bmug.org (Ron Hunsinger) Date: Tue, 17 May 94 06:50:16 PST Organization: Berkeley Macintosh Users Group resnick@cogsci.uiuc.edu (Pete Resnick) writes: >Ron_Hunsinger@bmug.org (Ron Hunsinger) writes: > >>If Apple was hard-pressed, I suppose the active Finder could look in >>the boot blocks of the other System Folder's volume to get the name of >>the other Finder, then open the other Finder's resource fork and get the >>folder names from it. And do all this only if the destination folder >>matches the id of the blessed folder (available from vcbFndrInfo). > >I think you are getting confused here. The question is, if I drag to a >non-blessed system folder, why can't the Finder figure out where to >put the files? To realize it's a legitamate (albeit unblessed) system >folder in the first place, You're right, I was confused here. I had forgotten that it is now permitted again to have more than one system folder on a volume. I still think it's spooky to do so, though. >you must *already* notice that there is a >System and a Finder in that folder. You don't need to go looking in >boot blocks to figure that out; you simply need to look at file types. Well, I think that looking at vcbFndrInfo for the directory id of the blessed folder is easier than looking at file types. But yeah, if you want to support unblessed system folders, you will have to scan the files inside the folder. I hadn't realized that the System and Finder files now had their own unique type/creator. Back on system 3 or so it was not uncommon for people to create files with the same type/creator as the Finder, so they wouldn't have to hassle with BNDL resources to give the file an icon. Apple started it (if memory serves me right, but I could be wrong) by doing this with the Clipboard File and the Scrapbook File, and then other vendors did the same with their "just-as-important" data and preference files. In light of that, are you sure that identifying the files by type/creator is reliable? I still find ZSYS/MACS and ZSYS/ERIK files on my disk that were put there by current non-Apple software. I know that System 7 now uses zsys/MACS and FNDR/MACS for the System and Finder, but are you sure that nobody is going to try to get a free icon out of the new codes like they did out of the old ones? And like many people do now by giving their preferences files a type of 'pref'? Related Question That May Answer This Question: How do the utility programs that let you switch between system folders on the same volume deal with the possibility that the folders might be in different languages? If they ignore the problem, using the System/Finder names from the boot blocks, then you should also. If they identify System/ Finder by their type/creator, as you are suggesting, and copy the names to the boot blocks, then your argument gains a lot of support. Similar Question: What happens now when you copy files that have the "wrong" names but the "right" type/creator into a folder on a volume that does not already have a blessed folder? That is, if I rename System and Finder to something else, say "System copy" and "Finder copy", and copy them into a folder on an otherwise blank disk, does that folder get blessed? Should it? Do those names get copied to the boot blocks? What if the names are longer than 15 bytes? If the folder gets blessed, that bolsters your contention that a system folder is defined in terms of the types of the files within it, rather than their names. And if not, you are of course free to argue that this is yet another oversight that ought to be corrected, but you will then have the additional burden of convincing us that this would be the correct behavior. You would have to answer questions like: What if I have two finders in the same folder under different names? Which one is the real one? What if I remove one of them from the blessed folder? Does the folder become unblessed, or does the other finder get selected? Which other one if I started with more than two? >Once you discover that there are appropriate System and Finder files >using the file types, you can then open the appropriate one (I forget >whether the fld# is in the System or the Finder; I believe it's the >former) and do the GetResource from that file (I guess using >Get1Resource instead of GetResource actually). You won't get the ones >from the Swedish system since the Hindu (or whatever) system is the >current resource file. It doesn't have to be the blessed folder since >any system folder will be reasonable to put things into appropriate >places. You're right about the fld# resource being in the System file. Too bad. The resource map for the System file is huge, and it takes a while to open it. Of course, you only need to open it to get the folder names, and you only need those if you are actually going to disburse files into the appropriate subfolders, and you aren't going to do that until the user responds to the dialog that comes up asking the user whether it's OK to do so. All of which means you could hide the time it takes by doing it while the user is reading the dialog. -Ron Hunsinger +++++++++++++++++++++++++++ >From ruhl@du.edu (ROBERT A. UHL ) Date: 11 May 94 21:53:07 GMT Organization: University of Denver In article zig@wc.novell.com (Zig Zichterman) writes: >One place Apple violates its suggested guidelines in in the Finder's >"About This Macintosh..." menu item. The Mac HI Guidelines book (pages 67-70) >suggests that the ellipsis (...) should appear only on menu items that >require *additional* information before they can complete (such as >choosing a file from an Open... dialog, or setting up options in a >Preferences... dialog, and so on). For menu items that execute without >further information from the user, such as Cut, Copy, showing an About >box, and so on, the ellipsis should not appear. Oops... I thought that the ellipsis indicated a dialog box (and, as far as I know, that item is a dialog box). >--Zig Zichterman >ziggr@eWorld.com > -- - ------------------------------------------------------- | Bob Uhl | Spectre | Christos Anesti! | | U of D | Baron Robert von Raetzin | Alithos Anesti! | - ------------------------------------------------------- --------------------------- >From egurney@vcd.hp.com (Eddy J. Gurney) Subject: List Manager clikLoop problem... but whose it? Date: Mon, 9 May 1994 22:02:04 GMT Organization: Hewlett-Packard VCD Over the weekend, I was adding some new features to some lists I have in my app, and came across an interesting problem. Running under Think C 7, all optimizations on. I have a List Manager click loop, declared as follows (yes, it is declared pascal Boolean; I know a Pascal boolean is 1 bit and a C boolean is 16 bits... and that Think C should take care of everything for me :-)... pascal Boolean MyClickLoop(void); now, if MyClickLoop looks like this: pascal Boolean MyClickLoop(void) { Boolaen result = true; return true; } everything works as expected. BUT if MyClickLoop uses something like this: pascal Boolean MyClickLoop(void) { Boolean result = true; return result; } it *DOESN'T* work. I compared the disassembly of the two; nothing out of the ordinary, really: First version (at least the important parts): LINK A6 ... MOVE.B #$01,$0008(A6) UNLK A6 RTS Second version: LINK A6 MOVE.L D7,-(A7) MOVEQ #$01,D7 ... MOVE.B D7,$0008(A6) MOVE.L (A7)+,D7 UNLK A6 RTS Now, this shouldn't make any difference, EXCEPT that the List Manager (_Pack0) calls the user-defined clikLoop routine with the following code: JSR (A0) BEQ ... As you can see, it immediately checks the Z condition code after the routine finishes... which assumes that the last command executed in the user-defined clikLoop routine sets that condition code correctly. This is NOT the case in the second version, since the MOVE.L (A7)+,D7 (to restore the value of D7) clobbers the condition code set by the MOVE.B D7,$0008(A6). [If more than one register needed to be saved on the stack and a MOVEM was used, this wouldn't matter since it doesn't change the condition codes. So this is kind of a "special" case (but it SHOULD still work!)] So my real clikLoop routine has a bunch of "return true" and "return false" all over it, instead of a bunch of "result = true" and "result = false" with one "return result" at the end... Anyway... whose problem is this? Should Think C be "smart" enough to work around this, or is the List Manager doing a Bad Thing by assuming the condition codes are valid without first popping something off the stack? -- Eddy J. Gurney N8FPW Hewlett-Packard Company, Vancouver (USA!) Division egurney@vcd.hp.com #include "Failures are divided into two classes-- those who thought and never did, and those who did and never thought." John Charles Salak +++++++++++++++++++++++++++ >From sears@netcom.com (Daniel Sears) Date: Tue, 10 May 1994 05:23:17 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Eddy, your summary of the clikLoop problem was very good. I've been having problems porting my clickLoop to the PPC with its mixed mode madness and your summary clarified things. On page 4-101 of Mo' Mac Toolbox, it says: A click-loop procedure should ordinarily set the Z flag to 1 just before returning. If a click-loop sets the Z flag to 0, then the LClick function immediately returns. It later says in the Assembly Language Information section: Your click-loop procedure should ordinarily set register d0 to 1. To stop the LClick function from calling your procedure for the current mouse-down event, set register d0 to 0. This second section could be a docubug or it could mean shut up, just stop calling me. As for whose problem this is, it sounds like a ThinkC code generation bug. I can't think of any reason why return true; and result = true; return result; should be different. Hope this helps. Dan -- E-mail: sears@netcom.com Phone: 415.695.0650 Address: 2440 16th Street #283 San Francisco, CA 94103-4211 +++++++++++++++++++++++++++ >From leblonk@netcom.com (Marcel Blonk) Date: Tue, 10 May 1994 08:32:14 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) : As for whose problem this is, it sounds like a ThinkC code generation bug. : I can't think of any reason why It's definitely not a Think C bug, since C compilers don't have anything to do with returning condition codes as function results. Maybe the Think C manual says somewhere that the CC return values are undefined (but not likely, since there is NO reason at all to assume that the CC should have any significance) so: : return true; and result = true; return result; should be different. are EXACTLY equal in C terms. Who to blaim? Apple I'd have to say. Their documentation says to declare the ClickLoop proc as a pascal Boolean returning function (in fact, the assembly-language note only reasserts that). So, if in this case, the ClickLoop is supposed to return with the Z-bit set appropiately, the documentation should have said so (and should have indicated that this routine can only be written with the appropiate assembler glue code) (It's a strange peace of programming interface anyway, since it also states that D5 contains the current mouse point "for your convenience". That's a real no-no, if you ask me. The least they could have done, is move D5 to D1 (it is eg. impossible to declare D5 as a pragma parameter, only D0-D1 and A0-A1 (maybe one more), since that is the convention that is used throughout the system) Anyway, to conclude, seeing that the Z-bit has to be set appropiately, the only way to write a proper ClickLoop function, is to add assembler glue code. You can in no way rely on the C compiler to do this for you. mb +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Wed, 11 May 1994 14:06:00 +0800 Organization: NCRPDA, Curtin University >On page 4-101 of Mo' Mac Toolbox, it says: > > A click-loop procedure should ordinarily set the Z flag to 1 > just before returning. If a click-loop sets the Z flag to 0, > then the LClick function immediately returns. This is correct for the 68k machines, at least in my experience. > >It later says in the Assembly Language Information section: > > Your click-loop procedure should ordinarily set register d0 to 1. > To stop the LClick function from calling your procedure for the > current mouse-down event, set register d0 to 0. This works only in that it sets the Z flag above. My solution (in Pascal) was to do it like this: {$PUSH} {$D-} function MyClickLoop: boolean; { returns the bloody equal flag for gods sake! } begin MyClickLoop := MyClickLoop2; { BE VERY CAREFUL! Returns the equal flag! } end; {$POP} Comments left unchanged :-) Peter. _______________________________________________________________________ Peter N Lewis Ph: +61 9 368 2055 +++++++++++++++++++++++++++ >From Dave Allcott Date: 11 May 1994 14:32:18 GMT Organization: Symantec Corporation In article Daniel Sears, sears@netcom.com writes: >As for whose problem this is, it sounds like a ThinkC code generation bug. >I can't think of any reason why > > return true; and result = true; return result; should be different. > >Hope this helps. I thinks it's still arguable but I'll see what we can do about it in the future. We should at least have oddities like this documented. Dave Depending on condition codes between function calls. tsk tsk. :) --------------------------- >From Mark A. Saper Subject: Opening a file with C standard i-o routines Date: 9 May 1994 15:41:13 GMT Organization: Biophysic, Univ. of Michigan This is a question from a novice: I am writing a drag and drop routine that handles AE's to open a document. The result from this is an FSSpec. How can I use this to open a file and read it with Think C's standard I/O routines like gets? I can open the file, read it into a buffer with Toolbox functions, but is there any way to link the standard I/O stream with my allocated buffer? Thanks for your help. Mark Saper, saper@umich.edu +++++++++++++++++++++++++++ >From rmah@panix.com (Robert S. Mah) Date: Mon, 09 May 1994 19:01:12 -0500 Organization: One Step Beyond Mark A. Saper wrote: > I am writing a drag and drop routine that handles AE's to open a > document. The result from this is an FSSpec. How can I use this to open > a file and read it with Think C's standard I/O routines like gets? I can > open the file, read it into a buffer with Toolbox functions, but is there > any way to link the standard I/O stream with my allocated buffer? Translate the FSSpec to a full pathname and then send that to fopen. Code to do this is on the developer CD's and on ftp.apple.com in /dts/mac/snippets/files/ (or somewhere like that) Cheers, Rob ___________________________________________________________________________ Robert S. Mah -=- One Step Beyond -=- 212-947-6507 -=- rmah@panix.com +++++++++++++++++++++++++++ >From marks77@aol.com (MarkS77) Date: 9 May 1994 20:46:07 -0400 Organization: America Online, Inc. (1-800-827-6364) This may not be the solution you want, but I've been extracting the file name, using toolbox calls to set the current directory and just using the standard C++ stream techniques to access the file. Mark +++++++++++++++++++++++++++ >From rmah@panix.com (Robert S. Mah) Date: Tue, 10 May 1994 01:44:48 -0500 Organization: One Step Beyond marks77@aol.com (MarkS77) wrote: > This may not be the solution you want, but I've been extracting the file > name, using toolbox calls to set the current directory and just using the > standard C++ stream techniques to access the file. Don't use working directory functions. The main reason they exist is to ensure backward compatibility with the old 400K disks (i.e. the MFS file system). If you need to use standard ANSI (or UNIX or C++ streams) files use the full pathname. This is 100% safe and guaranteed to always work. All it takes is the addition of 1 function to create the path name from the FSSpec. Cheers, Rob ___________________________________________________________________________ Robert S. Mah -=- One Step Beyond -=- 212-947-6507 -=- rmah@panix.com +++++++++++++++++++++++++++ >From marks77@aol.com (MarkS77) Date: 10 May 1994 23:42:02 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , rmah@panix.com (Robert S. Mah) writes: Don't use working directory functions. The main reason they exist is to ensure backward compatibility with the old 400K disks (i.e. the MFS file system). Actually, I usually get an SFReply from Standard File and use the vRefNum to do a SetVol call. After this all I need is the file name to do use standard C++ I/O. Are we talking about the same thing? Mark +++++++++++++++++++++++++++ >From rmah@panix.com (Robert S. Mah) Date: Wed, 11 May 1994 01:06:17 -0500 Organization: One Step Beyond marks77@aol.com (MarkS77) wrote: > rmah@panix.com (Robert S. Mah) writes: > > Don't use working directory functions. The main reason they exist is to > ensure backward compatibility with the old 400K disks (i.e. the MFS file > system). > > Actually, I usually get an SFReply from Standard File and use the > vRefNum to do a SetVol call. After this all I need is the file name > to do use standard C++ I/O. Are we talking about the same thing? Yes, that's what I mean. Don't use SetVol. There's a tech note on it that explains why and the inherent dangers. Convert it to the full pathname, it's much safer. Cheers, Rob ___________________________________________________________________________ Robert S. Mah -=- One Step Beyond -=- 212-947-6507 -=- rmah@panix.com +++++++++++++++++++++++++++ >From Daniel C. Flatin Date: 11 May 1994 15:49:05 GMT Organization: Physics Dept., The Ohio State University Here is how I use the Mac FSSpec and the standard io calls. I think I got some of this information from "The Mac Programming Public Domain FAQ" Dan Flatin Physics Department The Ohio State University dcf@mps.ohio-state.edu /* ---------------------------------------------------------------------- This is an fopen which uses a folder FSSpec for the file path instead of a full path name. - -------------------------------------------------------------------- */ FILE *fopenFS( char *name, FSSpec folder, const char *mode ) { FILE *cFile; short oldWDVol, oldTrueVol; long oldDir, oldProc, folderID; cFile = nil; /* save current working directory */ if ( GetVol( nil, &oldWDVol ) ) return( nil ); /* save current default volume info */ if ( GetWDInfo( oldWDVol, &oldTrueVol, &oldDir, &oldProc ) ) return( nil ); FolderFFSpecToDirID( folder, &folderID ); /* set selected info as default */ if ( HSetVol( nil, folder.vRefNum, folderID ) ) return( nil ); fflush( nil ); // flush all buffers cFile = fopen( name, mode ); // open the file HSetVol( nil, oldTrueVol, oldDir ); // restore default volume info SetVol( nil, oldWDVol ); // restore working directory return( cFile ); } /* ---------------------------------------------------------------------- This version of GetFOpen does not require a full path name to open the file. The use of full path names to identify files is frowned upon by Apple. - -------------------------------------------------------------------- */ FILE *GetFOpen( void ) { FILE *cFile; StandardFileReply mySFR; SFTypeList myTypeList; char name[64]; short oldWDVol, oldTrueVol; long oldDir, oldProc; cFile = nil; myTypeList[0] = 'TEXT'; StandardGetFile( nil, 1, myTypeList, &mySFR ); if ( mySFR.sfGood ) { /* save current working directory */ if ( GetVol( nil, &oldWDVol ) ) return( nil ); /* save current default volume info */ if ( GetWDInfo( oldWDVol, &oldTrueVol, &oldDir, &oldProc ) ) return( nil ); /* set selected info as default */ if ( HSetVol( nil, mySFR.sfFile.vRefNum, mySFR.sfFile.parID ) ) return( nil ); PascalStrCpy( name, (char *)mySFR.sfFile.name ); p2cstr( (unsigned char *)name ); fflush( nil ); // flush all buffers cFile = fopen( name, "r" ); // open the file HSetVol( nil, oldTrueVol, oldDir ); // restore default volume info SetVol( nil, oldWDVol ); // restore working directory } return( cFile ); } /* ---------------------------------------------------------------------- the folder FSSpec contains the volume reference number and the name. We need PBGetCatInfo() to get the directory ID. This routine does not (yet) check to see that the FFSpec does indeed describe a folder. - -------------------------------------------------------------------- */ OSErr FolderFFSpecToDirID( FSSpec folder, long *theDirID ) { CInfoPBRec pb; OSErr err; pb.hFileInfo.ioCompletion = NULL; pb.hFileInfo.ioNamePtr = folder.name; pb.hFileInfo.ioVRefNum = folder.vRefNum; pb.hFileInfo.ioFDirIndex = 0; pb.hFileInfo.ioDirID = folder.parID; err = PBGetCatInfo( &pb, FALSE); if ( err == noErr) *theDirID = pb.dirInfo.ioDrDirID; else *theDirID = 0; return ( err ); } /* ---------------------------------------------------------------------- PascalStrCpy Just like strcpy except that it takes pascal strings as arguments. - -------------------------------------------------------------------- */ char *PascalStrCpy( char *s1, char *s2 ) { *s1 = *s2; return( (char *)memcpy( s1+1, s2+1, *s1 ) ); } --------------------------- >From scouten@maroon.tc.umn.edu (Eric Scouten) Subject: Sym CDK vs CodeWarrior PPC: first impressions Date: Tue, 10 May 1994 14:23:26 GMT Organization: University of Minnesota, Student Affairs Just got my copy of Symantec's CDK yesterday and ran some tests of it against CodeWarrior PPC on a large application. (Don't consider these tests scientific by any means; it's just a first glance.) The application was the Art Class demo from Symantec's TCL 2.0 demos. For SC++ I used it unmodified from the TCL 2.0.1 disks; for CW, I used the version that was patched in my CW TCL port (see my earlier post on comp.sys.mac.oop.tcl for details). Here are the stats: SC++ CDK CW/PPC -------- -------- 10 12 Compile project from scratch (160+ files) 4 1 Link/build application 330K 415K Final application size 85K 1.5M Number of lines compiled* (see explanation below) Tests were conducted on my PowerMac 6100/60, 16MB RAM, 160MB disk, virtual memory off, very few extensions (only those required for debugging). Getting the CDK to run in 16MB is a hassle. I have to maintain two copies of the Think Project Manager on my disk; one set for 5MB partition (for compiling), the other set for 3.5MB (for linking, to share with the 8.5MB ToolServer partition). To me, the CDK package is *much* less attractive than the Symantec 68K compiler or either CodeWarrior compiler. It lacks the quick compile-link-run turnaround that the others have, and debugging is a step down from awful. I don't have two Macs sitting side-by-side to do debugging, so the Apple debugger that's included with the package is completely useless. Even if I could convince another debugger to work with the CDK-built apps, it would be only minimally useful, since there's no access to symbolic information -- the CDK compiler emits line numbers only. To its credit, the CDK package produces much smaller code (note the almost 25% difference in app size above). I haven't tested execution speed between the two compilers. *Number of lines compiled: I attribute the relatively slow compile time for CodeWarrior to the fact that most of the TCL headers couldn't be precompiled. (CW doesn't allow class definitions in precompiled headers. ) Thus, CodeWarrior was compiling 17 times more code in only 20% more time. (!) When CW is able to manage class definitions in the headers, there will be no comparison! BTW, the Bedrock Exception Library is pretty flaky when compiled under either PPC compiler. Fairly simple things, like opening too many new documents, cause fatal crashes. (It does seem to be more stable when compiled under Symantec's 68K compiler.) -Eric -- Eric Scouten * Univ of Minn * Student Affairs * Minneapolis, MN 55455 USA * * +1 612 626 0746 I always thought that 'Intel Inside' was a warning required by Truth in Advertising laws... -Anonymous --------------------------- >From cwat03@cs.aukuni.ac.nz (Christopher James F Waters) Subject: Where is the inheritance in AE objects? Date: 26 Apr 1994 23:19:37 GMT Organization: University of Auckland I am writing my first scriptable application. After coming to grips with IM InterApplication Communications and the AE registry it isn't really as difficult as I expected. However there is one thing that puzzles me. The registry talks about inheritance all the time and it is mentioned briefly in IM but there doesn't seem to be any way that inheritance is enforced. Is it up to me to ensure that all subclasses include the properties and elements of their superclass? I would have thought that there would be a field in the aete resource for specifying the superclass, then it wouldn't be necessary to redfine properties and elements that have been defined previously. Also, am I right in thinking that the aete shouldn't contain definitions for abstract classes? Chris Waters. Department of Electrical & Electronic Engineering University of Auckland. +++++++++++++++++++++++++++ >From rmah@panix.com (Robert S. Mah) Date: Tue, 26 Apr 1994 21:13:01 -0500 Organization: One Step Beyond cwat03@cs.aukuni.ac.nz (Christopher James F Waters) wrote: > registry talks about inheritance all the time and it is mentioned briefly > in IM but there doesn't seem to be any way that inheritance is enforced. > Is it up to me to ensure that all subclasses include the properties and > elements of their superclass? Yes. The inheritance is conceptual only. Cheers, Rob ___________________________________________________________________________ Robert S. Mah -=- One Step Beyond -=- 212-947-6507 -=- rmah@panix.com +++++++++++++++++++++++++++ >From paul@ctalk.exnet.com (Paul G Smith) Date: Wed, 27 Apr 94 12:49:03 GMT Organization: commstalk, & Full Moon Software Inc In article <2pk7i9$ffl@ccu2.auckland.ac.nz> (comp.sys.mac.programmer), cwat03@cs.aukuni.ac.nz (Christopher James F Waters) writes: > > I am writing my first scriptable application. After coming to grips with IM > InterApplication Communications and the AE registry it isn't really as > difficult as I expected. However there is one thing that puzzles me. The > registry talks about inheritance all the time and it is mentioned briefly in > IM but there doesn't seem to be any way that inheritance is enforced. Is it > up to me to ensure that all subclasses include the properties and elements > of their superclass? I would have thought that there would be a field in the > aete resource for specifying the superclass, then it wouldn't be necessary to > redfine properties and elements that have been defined previously. > > Also, am I right in thinking that the aete shouldn't contain definitions for > abstract classes? > > Chris Waters. > Department of Electrical & Electronic Engineering > University of Auckland. > As it happens, the AppleScript 1.1 headers do define a constant you can use to indicate object inheritance (this from ASRegistry.h): pInherits = 0x6340235e, // 'c@#^' // You can define a property, using this constant, to indicate an object inherits the properties and elements of another class. Here is an example of the aete definition for a sub-class: /* [4] */ "my subclass", cSubClass, "A radio button", { /* array Properties: 1 elements */ /* [1] */ "", pInherits, cSuperClass, "subclass of my superclass", reserved, singleItem, notEnumerated, readWrite, reserved, reserved, reserved, reserved, reserved, reserved, reserved, reserved, reserved, notFeminine, notMasculine, singular, }, { /* array Elements: 0 elements */ }, The definition will say, to the user who examines your program Dictionary using a Script Editor, that the class inherits from another; the Dictionary display will format the property as something like: superclass name The above is not the whole story. You do NOT have to duplicate all the properties class by class, and the 'pInherits' property is no more than a hint to the user, because AppleScript will allow any property, declared anywhere in the aete, to be specified for 'get data' or 'set data' for any class. In other words, AppleScript doesn't know or care what object classes support what properties: it is up to the program that is asked to resolve those properties to complain if an incorrect property is specified. However, because users look to the Dictionary to tell them what properties are valid for what object classes, you should use the 'pInherits' mechanism to tell them what's going on. Lastly, you might want to look out for the next issue of 'develop' magazine, which includes an article I wrote about developing OSA-savvy programs. It doesn't cover the 'pInherits' property, but it does come with a lot of sample code that will be helpful to newcomers to the OSA. ('develop' magazine is published by Apple Computer Inc.) best regards, Paul - -------------------------------------------------------------- Paul G Smith, Commstalk HQ || UK ph: +44 727 844232 P O Box 116, ST ALBANS || fax: +44 727 856139 Hertfordshire. AL1 2RL. UK || US ph: 408 253 7199 & Full Moon Software, Inc || fax: 408 252 2378 P O Box 700237, SAN JOSE, CA 95170 || AppleLink: COMMSTALK.HQ +++++++++++++++++++++++++++ >From Alan_B._Harper@bmug.org (Alan B. Harper) Date: Tue, 3 May 94 10:41:34 PST Organization: Berkeley Macintosh Users Group As far as I can tell, the "inheritance" in apple-event objects is purely for the solopsistic inconvenience of the designer of the classes. There seems to be no support for inheritance, and there is no reason at all for abstract classes. I have been proceeding by ignoring inheritance, and it doesn't seem to be a problem. I haven't written my aete yet, though. BTW, is your application recordable? How do you handle open events for files? As far as I can tell, the only way to send yourself an "open file" apple event is to parse the FSSpec into an absolute file name and then send it to yourself. Do you know if there is a better way? Alan +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 4 May 1994 07:40:33 GMT Organization: The Royal Institute of Technology In <001479A1.fc@bmug.org> Alan_B._Harper@bmug.org (Alan B. Harper) writes: >files? As far as I can tell, the only way to send yourself an "open file" apple >event is to parse the FSSpec into an absolute file name and then send it to >yourself. >Do you know if there is a better way? Definately. You can put the FSSpec in the array of files, or you can put aliases there, created by NewAlias. The latter is the most preferrable. -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe (on a Swedish scale) -- "Just because you're paranoid(P) doesn't mean they aren't after(A) you" !(P -> !A) == !(!P | !A) == !(!(P & A)) == P & A +++++++++++++++++++++++++++ >From leonardr@netcom.com (Leonard Rosenthol) Date: Wed, 4 May 1994 17:42:46 GMT Organization: Aladdin Systems, Inc. In article <2q7jhh$gqr@news.kth.se>, d88-jwa@dront.nada.kth.se (Jon Wätte) wrote: > In <001479A1.fc@bmug.org> Alan_B._Harper@bmug.org (Alan B. Harper) writes: > > >files? As far as I can tell, the only way to send yourself an "open file" apple > > >event is to parse the FSSpec into an absolute file name and then send it to > >yourself. > >Do you know if there is a better way? > > Definately. You can put the FSSpec in the array of files, or you > can put aliases there, created by NewAlias. The latter is the most > preferrable. > Yup, that's the way. And here is the code from my DropShell that shows how to do it... Leonard - --- /* This routine is the low level routine used by the SendODOCToSelf routine. It gets passed the list of files (in an AEDescList) to be sent as the data for the 'odoc', builds up the event and sends off the event. It is broken out from SendODOCToSelf so that a SendODOCListToSelf could easily be written and it could then call this routine - but that is left as an exercise to the reader. Read the comments in the code for the order and details */ void _SendDocsToSelf (AEDescList *aliasList) { OSErr err; AEAddressDesc theTarget; AppleEvent openDocAE, replyAE; /* First we create the target for the event. We call another utility routine for creating the target. */ err = GetTargetFromSelf(&theTarget); if (err == noErr) { /* Next we create the Apple event that will later get sent. */ err = AECreateAppleEvent(kCoreEventClass, kAEOpenDocuments, &theTarget, kAutoGenerateReturnID, kAnyTransactionID, &openDocAE); if (err == noErr) { /* Now add the aliasDescList to the openDocAE */ err = AEPutParamDesc(&openDocAE, keyDirectObject, aliasList); if (err == noErr) { /* and finally send the event Since we are sending to ourselves, no need for reply. */ err = AESend(&openDocAE, &replyAE, kAENoReply + kAECanInteract, kAENormalPriority, 3600, NULL, NULL); /* NOTE: Since we are not requesting a reply, we do not need to need to dispose of the replyAE. It is there simply as a placeholder. */ } /* Dispose of the aliasList descriptor We do this instead of the caller since it needs to be done before disposing the AEVT */ err = AEDisposeDesc(aliasList); } /*and of course dispose of the openDoc AEVT itself*/ err = AEDisposeDesc(&openDocAE); } } /* This is the routine called by SelectFile to send a single odoc to ourselves. It calls the above low level routine to do the dirty work of sending the AEVT - all we do here is build a AEDescList of the file to be opened. */ void SendODOCToSelf (FSSpec *theFileSpec) { OSErr err; AEDescList aliasList; AEDesc aliasDesc; AliasHandle aliasH; /*Create the descList to hold the list of files*/ err = AECreateList(NULL, 0, false, &aliasList); if (err == noErr) { /* First we setup the type of descriptor */ aliasDesc.descriptorType = typeAlias; /* Now we add the file to descList by creating an alias and then adding it into the descList using AEPutDesc */ err = NewAlias(NULL, theFileSpec, &aliasH); aliasDesc.dataHandle = (Handle)aliasH; err = AEPutDesc(&aliasList, 0, &aliasDesc); DisposHandle((Handle)aliasH); /*Now call the real gut level routine to do the dirty work*/ _SendDocsToSelf(&aliasList); /*_SendDocsToSelf will dispose of aliasList for me*/ } } - ------------------------------------------------------------------------ Leonard Rosenthol Internet: leonardr@netcom.com Director of Advanced Technology AppleLink: MACgician Aladdin Systems, Inc. GEnie: MACgician +++++++++++++++++++++++++++ >From isis@netcom.com (Mike Cohen) Date: Wed, 4 May 1994 17:45:41 GMT Organization: ISIS International Alan_B._Harper@bmug.org (Alan B. Harper) writes: >BTW, is your application recordable? How do you handle open events for >files? As far as I can tell, the only way to send yourself an "open file" apple >event is to parse the FSSpec into an absolute file name and then send it to >yourself. >Do you know if there is a better way? >Alan No, the open file event takes an alias, not a file name. It's very easy to create an alias from a FSSpec (or, you could just send the FSSpec, since there's a built-in coercion handler for alias <-> FSSpec. -- Mike Cohen - isis@netcom.com NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20 +++++++++++++++++++++++++++ >From greer@utdallas.edu (Dale M. Greer) Date: 4 May 1994 19:57:23 GMT Organization: The University of Texas at Dallas Mike Cohen (isis@netcom.com) wrote: > Alan_B._Harper@bmug.org (Alan B. Harper) writes: > >BTW, is your application recordable? How do you handle open events for > >files? As far as I can tell, the only way to send yourself an "open file" apple > >event is to parse the FSSpec into an absolute file name and then send it to > >yourself. > >Do you know if there is a better way? > >Alan > No, the open file event takes an alias, not a file name. It's very easy to > create an alias from a FSSpec (or, you could just send the FSSpec, since > there's a built-in coercion handler for alias <-> FSSpec. It works with full file path names too. -- Dale Greer, greer@utdallas.edu +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Wed, 04 May 1994 20:30:55 -0700 Organization: Internet for the Olympic Peninsula In article <2q8un3$he@news.utdallas.edu>, greer@utdallas.edu (Dale M. Greer) wrote: > Mike Cohen (isis@netcom.com) wrote: > > Alan_B._Harper@bmug.org (Alan B. Harper) writes: > > > >BTW, is your application recordable? How do you handle open events for > > >files? As far as I can tell, the only way to send yourself an "open file" apple > > >event is to parse the FSSpec into an absolute file name and then send it to > > >yourself. > > >Do you know if there is a better way? > > > >Alan > > > No, the open file event takes an alias, not a file name. It's very easy to > > create an alias from a FSSpec (or, you could just send the FSSpec, since > > there's a built-in coercion handler for alias <-> FSSpec. > > It works with full file path names too. "It" only works with full path names if the application has prepared itself for non-standard forms of the open document event, or something has installed a system coercion for TEXT to FSSpec (TEXT to alias wouldn't help typical applications). Recently, "something" has indeed added a system handler for TEXT to FSSpec...I believe that the something is AppleScript, but it could be one of the apps running at this moment in my Mac. But there is one, which is why full path name works...relative path name probably works, too. The definition of the open document event calls for a list of aliases in the direct parameter. Since (a) an alias isn't what the application ultimately wants (it wants an FSSpec) and (b) the Apple Event Manager will coerce the alias to an FSSpec for you, and (c) even if something [incorrectly] sends a single alias rather than a list of one alias, the event handler should 1. ask for the direct parameter as a list (if a single item was there, you get a list of that one item, courtesy of the AE Manager) 2. count the number of items in the list 3a. ask for each item from the list, as an FSSpec (since that's how you want them). 3b. do something with each item. The extended form of the open event has a list of object specifiers. Conveniently, the needed coercions are in place so that you can ask for those, instead of the above, if you support the extended form. That too is new since the beginning (again probably it is AppleScript doing it...easy to test by starting without AppleScript). -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From jonpugh@netcom.com (Jon Pugh) Date: Wed, 11 May 1994 07:58:17 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Alan B. Harper (Alan_B._Harper@bmug.org) wrote: > As far as I can tell, the "inheritance" in apple-event objects is purely for > the solopsistic [sic] inconvenience of the designer of the classes. There > seems to be no support for inheritance, and there is no reason at all for > abstract classes. > I have been proceeding by ignoring inheritance, and it doesn't seem to be a > problem. I haven't written my aete yet, though. This is essentially correct. You do not need to worry about abstract classes and there is no support for any objects, only their resolution. Your OSL callbacks do all the object stuff and they can be object oriented. I'm doing some abstract inherited objects in my current project. I have an app with two document types. Since I want to be able to talk about documents, docfoos and docbars, it makes sense to subclass them and implement them as inherited objects. As usual, all the work is on my shoulders, but I'm used to that. ;) Jon --------------------------- >From perlis_a@math.lsu.edu (Alexander Perlis) Subject: [Q] How to prevent _DragWindow from selecting the window? Date: 9 May 1994 20:32:29 GMT Organization: Louisiana State University InterNetNews Site The _DragWindow trap follows the mouse with an outline of a window and then moves the window to the new location when the user releases the mouse. After moving the window, unless the user held down the command-key when initiating the drag, the window is also selected. I would like to let users move non-frontmost windows around even when the frontmost window is modal and must remain frontmost. If I could fake _DragWindow into thinking that the command-key had been held down on the previous mouseDown event, I'd be in business. Or if I could patch into _DragWindow in the appropriate place to prevent the window selection, I would also be in business. However, tracing through the _DragWindow code is hopeless for my less-than-perfect abilities because this routine is in various pieces which involve calls to the infamous Layer Manager which we are not supposed to touch and not even supposed to try to understand. Patching _DragWindow seems to be a bad idea. How can I convince _DragWindow that the command-key was held down? Or is there a better or more obvious way to prevent _DragWindow from selecting the window after the drag? Mystified, Alexander Perlis perlis_a@math.lsu.edu +++++++++++++++++++++++++++ >From dean@genmagic.com (Dean Yu) Date: 10 May 1994 02:36:17 GMT Organization: General Magic, Inc. In article <2qm6kt$2m8h@te6000.otc.lsu.edu>, perlis_a@math.lsu.edu (Alexander Perlis) wrote: > How can I convince _DragWindow that the command-key was held down? Or is > there a better or more obvious way to prevent _DragWindow from selecting > the window after the drag? How about not calling DragWindow, and calling DragGrayRgn instead? If you want to be really cool, you can call ClipAbove first so that the region is clipped behind any window that is above the one that you're dragging. When the user lets up, you can then call MoveWindow to move the window, passing false in the front parameter to keep the window where it is. -- Dean Yu Negative Ethnic Role Model General Magic, Inc. +++++++++++++++++++++++++++ >From Guenther Blaschek Date: Tue, 10 May 1994 10:16:02 CDT Organization: University of Linz, Austria In article Dean Yu, dean@genmagic.com writes: >> How can I convince _DragWindow that the command-key was held down? Or is >> there a better or more obvious way to prevent _DragWindow from selecting >> the window after the drag? > > How about not calling DragWindow, and calling DragGrayRgn instead? If you >want to be really cool, you can call ClipAbove first so that the region is >clipped behind any window that is above the one that you're dragging. When >the user lets up, you can then call MoveWindow to move the window, passing >false in the front parameter to keep the window where it is. Here's how I did it: VAR windH,windV:Integer; {global variables} PROCEDURE MyMoveWindow (theWindow: WindowPtr; h, v: Integer; front: Boolean); BEGIN windH := h; windV := v END; PROCEDURE MyDragWindow (w: WindowPtr; pt: Point; bounds: Rect); VAR oldA5, oldMove: LongInt; BEGIN oldA5 := SetCurrentA5; oldMove := GetTrapAddress($A91B); {MoveWindow} SetTrapAddress(LongInt(@MyMoveWindow), $A91B); {patch MoveWindow} windH := -32000; DragWindow(w, pt, bounds); SetTrapAddress(oldMove, $A91B); {restore the patch} IF windH <> -32000 THEN {only if MyMoveWindow was called} MoveWindow(w, windH, windV, FALSE); {never move the window to front} oldA5 := SetA5(oldA5) END; Call MyDragWindow instead of DragWindow. MyDragWindow temporarily patches MoveWindow by replacing it with MyMoveWindow. MyMoveWindow simply remembers the position where the window should be moved. If windH<>-32000 (i.e., if MyMoveWindow was called during DragWindow), the original MoveWindow is called with the last parameter set to FALSE, which makes MoveWindow behave as if the command key had been pressed. e -- Guenther Blaschek Tel.: +43-732-2468-521 gu -- Johannes Kepler University Linz Fax: +43-732-2468-426 Institute of Computer Science e-Mail: gue@soft.uni-linz.ac.at Software Department Blaschek@jk.uni-linz.ac.at Altenbergerstr. 69 A-4040 Linz, Austria +++++++++++++++++++++++++++ >From Kevin.R.Boyce@gsfc.nasa.gov (Kevin R. Boyce) Date: Tue, 10 May 1994 12:23:16 -0400 Organization: NASA/GSFC perlis_a@math.lsu.edu (Alexander Perlis) wrote: > The _DragWindow trap follows the mouse with an outline of a window and > then moves the window to the new location when the user releases the > mouse. After moving the window, unless the user held down the command-key > when initiating the drag, the window is also selected. Here's some code that does what Dean Yu suggested (without using ClipAbove -- that would add to the coolness). This is a part of my DoMouseDown routine. short windowPart; WindowPtr whichWindow; RgnHandle rgn, clipRgn; Rect r; long lDistVH; short h,v; GrafPtr savePort; ... windowPart = FindWindow(evp->where, &whichWindow); switch(windowPart) { case inDrag: if( progDialog == whichWindow || psStopped == processingState ) { /* * Just do a normal drag. */ DragWindow(whichWindow, evp->where, &dragRect); } else { /* * If we're processing, and trying to drag the main window, * drag it but don't select it. (We don't want to allow the user * to change any settings while processing.) Calling DragWindow() * generates an activate event (and activates the frame) unless * the command key is held down. Turning on cmdKey in the event * (*evp) doesn't help; DragWindow must check the keyboard. Yuck. * So I drag it by hand. */ GetPort( &savePort ); SetPort( WMgrPort ); rgn = NewRgn(); clipRgn = NewRgn(); GetClip( clipRgn ); ClipRect( &screenBits.bounds ); r = (*((WindowPeek)whichWindow)->strucRgn)->rgnBBox; RectRgn( rgn, &r ); r = (*((WindowPeek)whichWindow)->contRgn)->rgnBBox; h = r.left - evp->where.h; v = r.top - evp->where.v; lDistVH = DragGrayRgn( rgn, evp->where, &dragRect, &dragRect, 0, nil ); if( lDistVH != 0x80008000 ) { h += evp->where.h + ( lDistVH & 0xFFFF ); v += evp->where.v + ( (lDistVH & 0xFFFF0000) >> 16 ); MoveWindow( whichWindow, h, v, FALSE ); } SetClip( clipRgn ); SetPort( savePort ); DisposeRgn( rgn ); DisposeRgn( clipRgn ); } break; It works in my program, on my machine, with my system. Anything else is not guaranteed. But at least it gets the local<->global coordinate transformation right. -- Kevin Kevin.R.Boyce@gsfc.nasa.gov You can blow out a candle, but you can't blow out a fire. Once the flame begin to catch, the wind will blow it higher. --Peter Gabriel, 1980 _Biko_ +++++++++++++++++++++++++++ >From dean@genmagic.com (Dean Yu) Date: 10 May 1994 16:47:56 GMT Organization: General Magic, Inc. In article <19940510.101602449417.NETNEWS@ALIJKU11>, Guenther Blaschek wrote: > Call MyDragWindow instead of DragWindow. > MyDragWindow temporarily patches MoveWindow by replacing it with MyMoveWindow. > MyMoveWindow simply remembers the position where the window should be moved. > If windH<>-32000 (i.e., if MyMoveWindow was called during DragWindow), the > original MoveWindow is called with the last parameter set to FALSE, which > makes MoveWindow behave as if the command key had been pressed. This is really gross and is exactly why I tell people not to patch things. This code assumes that DragWindow calls MoveWindow to move the window after the drag is done. Sure, it's true today but it might not be tomorrow. If someone like Microsoft makes this assumption, it shackles system software from ever changing. Roll your own. Don't patch. -- Dean Yu Negative Ethnic Role Model General Magic, Inc. +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 10 May 1994 17:25:26 GMT Organization: The Royal Institute of Technology In Kevin.R.Boyce@gsfc.nasa.gov (Kevin R. Boyce) writes: > GetClip( clipRgn ); > ClipRect( &screenBits.bounds ); This won't work when you have more than one screen. You should use SetClip ( GetGrayRgn ( ) ) ; instead. Interesting trivia: you can pass something "sufficiently close" to what screenBits . bounds is as a limnitRect to DragWindow; the toolbox will check for that case and figure out you mean to drag the window within the whole gray region instead. Talk about compatibility hack... -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe (on a Swedish scale) -- The word "politics" is derived from the word "poly", meaning "many", and the word "ticks", meaning "blood sucking parasites". -- Larry Hardiman +++++++++++++++++++++++++++ >From Guenther Blaschek Date: Wed, 11 May 1994 09:29:07 CDT Organization: University of Linz, Austria In article Dean Yu, dean@genmagic.com writes: >> Call MyDragWindow instead of DragWindow. >> MyDragWindow temporarily patches MoveWindow by replacing it with MyMoveWindow. >> MyMoveWindow simply remembers the position where the window should be moved. >> If windH<>-32000 (i.e., if MyMoveWindow was called during DragWindow), the >> original MoveWindow is called with the last parameter set to FALSE, which >> makes MoveWindow behave as if the command key had been pressed. > > This is really gross and is exactly why I tell people not to patch >things. This code assumes that DragWindow calls MoveWindow to move the >window after the drag is done. Sure, it's true today but it might not be >tomorrow. If someone like Microsoft makes this assumption, it shackles >system software from ever changing. > Roll your own. Don't patch. It is correct that the code assumes that DragWindow calls MoveWindow, but I did not guess that or get this knowledge thru experiments. Rather, IT'S DOCUMENTED IN INSIDE MACINTOSH! IM Vol. I, p. 289: "... When the mouse button is released, DragWindow calls MoveWindow to move theWindow to the location to which it was dragged. If theWindow isn't the active window (and the Command key wasn't being held down), DragWindow makes it the active window by passing TRUE for the front parameter when calling MoveWindow. ..." I believe that temporarily patching MoveWindow is actually safer than re-implementing DragWindow. If, for some reason, the mechanism to move windows changed, the re-implementation would not work any longer, whereas my solution would still work because the new DragWindow would be called which would then call MoveWindow -- and that's guaranteed because it is documented. e -- Guenther Blaschek Tel.: +43-732-2468-521 gu -- Johannes Kepler University Linz Fax: +43-732-2468-426 Institute of Computer Science e-Mail: gue@soft.uni-linz.ac.at Software Department Blaschek@jk.uni-linz.ac.at Altenbergerstr. 69 A-4040 Linz, Austria --------------------------- >From parkb@bigbang.Stanford.EDU (Brian Park) Subject: [Q] casting Str255 <--> (char*) Date: 6 May 1994 21:07:07 GMT Organization: Stanford University I'm having a little problem understanding casting a (char*) to (Str255), with strict prototype checks. Consider the following small code segment in THNIK C 7.0: void do_pascal(Str255 p); void do_c(char *c) { char t[256]; strcpy(t, c); CtoPStr(t); do_pascal(t); /* gives compile time error here */ } It gives an error, saying prototype doesn't match. Now I try do_pascal((Str255)t); /* error */ do_pascal((Str255*)t); /* error */ do_pascal(*(Str255*)t); /* compiles */ Obviously, I thought I understood C strings/arrays, but I don't. Shouldn't the first one work? I don't even understand what the third one is saying, "convert t into a pointer to a pointer to array of 256 characters, then convert it to a pointer to an array of 256 char"? That's what I said in the first one. :-) Brian Park +++++++++++++++++++++++++++ >From Carl R. Osterwald Date: Fri, 6 May 1994 00:16:10 GMT Organization: National Renewable Energy Laboratory In article <2qebhr$2lk@nntp2.Stanford.EDU> Brian Park, parkb@bigbang.Stanford.EDU writes: >I'm having a little problem understanding casting a (char*) to >(Str255), with strict prototype checks. >Consider the following small code segment in THNIK C 7.0: > >void do_pascal(Str255 p); >void do_c(char *c) >{ > char t[256]; > > strcpy(t, c); > CtoPStr(t); > do_pascal(t); /* gives compile time error here */ /****argument does not match prototype****/ >} > >It gives an error, saying prototype doesn't match. Now I try > > do_pascal((Str255)t); /* error */ /****illegal cast****/ > do_pascal((Str255*)t); /* error */ /****argument does not match prototype****/ > do_pascal(*(Str255*)t); /* compiles */ The Macintosh header files define Pascal strings with _unsigned chars_, like: unsigned char Str255[256], Str63[64], Str31[32], *StringPtr; So the argument to do_pascal is really a pointer to an unsigned char. Your first attempt to call do_pascal is rejected because t is a pointer to a normal c char. The second fails because you are trying to cast a pointer into an array. The third fails because you cast a pointer to an unsigned char into a pointer to an array, which is different to the compiler. The last one works (compiles) because you dereference the pointer to an array. I don't think it will give the right answer, though. So, you can change the do_pascal call to: do_pascal( (unsigned char *)t ); Better yet, change the argument to do_pascal to a StringPtr, and you end up with: void do_pascal(StringPtr p); void do_c(char *c) { char t[256]; strcpy(t, c); CtoPStr(t); do_pascal( (StringPtr)t ); } +++++++++++++++++++++++++++ >From Shahid Alam Date: 7 May 1994 00:07:25 GMT Organization: UT Austin/General Libraries/Library Systems In article <2qebhr$2lk@nntp2.Stanford.EDU> Brian Park, parkb@bigbang.Stanford.EDU writes: > I'm having a little problem understanding casting a (char*) to > (Str255), with strict prototype checks. > Consider the following small code segment in THNIK C 7.0: > > void do_pascal(Str255 p); > void do_c(char *c) > { > char t[256]; > > strcpy(t, c); > CtoPStr(t); > do_pascal(t); /* gives compile time error here */ > } The definition of Str255 is typedef unsigned char Str255[256]; ^^^^^^^^ It's that unsigned that's causing this statement to be flagged as an error: char[256] <> unsigned char[256] With complete typechecking this conversion must be explicit. However, explicit conversion is also a problem since, you cannot typecast to array. Arrays, while glorified pointers, are special in that they cannot represent an lvalue, and similarly cannot be cast to. Which is what your problem in the next statement is: > > It gives an error, saying prototype doesn't match. Now I try > > do_pascal((Str255)t); /* error */ In order to cast to an array you must cast to the pointer to the array. The following does not work however, because here you are basically typecasting a "char[256]", conceptually same as "char*" in C, which is what t is, to a "unsigned char[256]*", conceptually "unsigned char**", thus the problem. > do_pascal((Str255*)t); /* error */ And the following typecast, "char[256]*" (pointer to t, or pointer to array of char) to "unsigned char[256]*" (String255*, or pointer to an array of unsigned char), works: > do_pascal(*(Str255*)t); /* compiles */ > > Obviously, I thought I understood C strings/arrays, but I don't. > Shouldn't the first one work? I don't even understand what the > third one is saying, "convert t into a pointer to a pointer to array > of 256 characters, then convert it to a pointer to an array of 256 char"? > That's what I said in the first one. :-) This is all as I understand it. I don't have K&R handy. If I am mistaken, I'm sure somebody will be kind enough to point it out. > Brian Park _____________________________________________________________________________ Shahid M. Alam shahid@mail.utexas.edu +++++++++++++++++++++++++++ >From parkb@bigbang.Stanford.EDU (Brian Park) Date: 9 May 1994 02:12:33 GMT Organization: Stanford University Carl R. Osterwald wrote: >So the argument to do_pascal is really a pointer to an unsigned char. [...] > do_pascal( (unsigned char *)t ); yes, yes! Now I get it! I did know that (char *) != (unsigned char *), but didn't connect it to this problem. Feel pretty stupid now. I still think that casting to (Str255) should be legal but who am I to argue with a compiler? As Carl suggested, the proper way around all this is to use the pre-defined type StringPtr. Thanks all. Brian Park --------------------------- End of C.S.M.P. Digest **********************