goldman@apple.com (Phil Goldman) (04/05/89)
In article <28689@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu (David Phillip Oster) writes: > The standard, from Apple is "Don't even try to do this". Most people do > it by checking to see if the end of the system heap is close to the > beginning of the application heap. If it is, no multifinder. This is a very bad thing to do, and, as was mentioned in a previous posting, the one known legitimate reason for doing so will soon be fixed in SysEnvirons. Reasons such as putting up a dialog box saying "Cannnot do...with MultiFinder" are very poor ones. When MF was first released there were certain apps that had these same warnings for Switcher. These dialogs became very embarrassing for the developers, and an annoyance for users. This will happen again apparently. Doing such checks makes it very much harder to move MultiFinder functionality to the System or ROM. Worse, it makes it dirtier to add new Mac OS functionality. -Phil Goldman Apple Computer
matthews@eleazar.dartmouth.edu (Jim Matthews) (04/05/89)
I don't have any good reasons for wanting to detect MultiFinder's presence, but I would like a call to find out whether my program is in the background. I know about suspend and resume events, but I want to find out where my program is *right now*. The reason is that it's easy to drop a suspend or resume event, particularly when ModalDialog or one of the Alert calls is getting the events. It's uncommon for major switching to occur with a modal dialog is in front, but it isn't impossible -- the foreground application can quit, and setting startup to multiple applications can cause it also. Dropping one suspend or resume event can leave the application out of synch for a long time, with ugly effects in terms of cursor tracking, notification of asynchronous events, and other application-specific things. One alternative is to compare my name to CurApName, but it isn't impossible for the user to run two identically-named programs. So is there a sure-fire way to tell whether I'm in background, or any plans to provide one? Jim Matthews Dartmouth Software Development
ech@pegasus.ATT.COM (Edward C Horvath) (04/06/89)
This isn't a need-to-know, but rather an annoyance. I have an application that tries to be a good citizen by shrinking windows when it's not the foreground app. I'm not the author of VersaTerm, but it does this also. No problem: initially set up for foreground; then on a Suspend event, switch to background appearance; on a Resume, switch to foreground. This works fine EXCEPT when the application is part of a "Set Startup" set and does not wind up frontmost. The app is set up in background, and stays in background, but doesn't receive an initial Resume OR Suspend. Minor, but several of my users have complained about it. Simplest fix for Apple is just to make sure startup apps get a Suspend event (preferably excepting the frontmost app). =Ned Horvath= ech@pegasus.att.com; AppleLink D1619
ech@pegasus.ATT.COM (Edward C Horvath) (04/06/89)
From article <12904@dartvax.Dartmouth.EDU>, by matthews@eleazar.dartmouth.edu (Jim Matthews): > ...but I would like a call to find out whether my program is > in the background...it's easy to drop a suspend or resume event... > ...with ugly > effects in terms of cursor tracking, notification of asynchronous > events, and other application-specific things. > One alternative is to compare my name to CurApName... No good: your copy of CurApName is always yours (like most low memory globals). =Ned=
earleh@eleazar.dartmouth.edu (Earle R. Horton) (04/06/89)
In article <1179@internal.Apple.COM> goldman@apple.com (Phil Goldman) writes: >In article <28689@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu (David >Phillip Oster) writes: >> The standard, from Apple is "Don't even try to do this". Most people do >> it by checking to see if the end of the system heap is close to the >> beginning of the application heap. If it is, no multifinder. > >This is a very bad thing to do, and, as was mentioned in a previous >posting, the one known legitimate reason for doing so will soon be fixed >in SysEnvirons. > I fully agree that it is bad to check for Multifinder in terms of future compatibility. If Apple wants developers to refrain from doing this, they should NOT DISTRIBUTE DEVELOPER'S TOOLS WHICH OBVIOUSLY DO. I have MPW Shell 2.0.2, and it obviously knows whether Launch will return or not, and therefore knows whether MultiFinder is active. It undoubtedly uses some non-approved method of finding out whether MultiFinder is active or not. Apple cannot reasonably expect developers to refrain from checking for MultiFinder active, and at the same time sell them a program which does. "Don't do as I do, do as I say." is not very convincing coming from anybody. > >Doing such checks makes it very much harder to move MultiFinder >functionality to the System or ROM. Worse, it makes it dirtier to add new >Mac OS functionality. Yes. I can imagine all sorts of nifty features that could be added to MultiFinder and the OS, and that would be incompatible with present applications which check for MultiFinder active. So please, don't attempt to find out, and ignore the bad example set by certain distributors of development systems. Earle
mnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) (04/06/89)
In article <1179@internal.Apple.COM> goldman@apple.com (Phil Goldman) writes: >This is a very bad thing to do, and, as was mentioned in a previous >posting, the one known legitimate reason for doing so will soon be fixed >in SysEnvirons. But for now you can check if the standard MDEF (id=0) is in the system heap or the application heap. If it's in the system heap then MF is probably running. I say probably because an init I'm working on loads the MDEF into the system heap and there may be other inits that do this too. >Doing such checks makes it very much harder to move MultiFinder >functionality to the System or ROM. Worse, it makes it dirtier to add new >Mac OS functionality. > >-Phil Goldman >Apple Computer What he said. Use my method only at your own risk. ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
cep@apple.com (Christopher Pettus) (04/06/89)
In article <2749@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) writes: > I have an application that tries to be a good citizen by shrinking windows > when it's not the foreground app. While for some applications this might make sense, remember that the interface guidelines strongly advise against messing with the size or position of user-defined windows except under user control. For example, if the user had set up a screen neatly so that they could see some info in your application before bringing another forward, they would be rather upset if the windows then moved so as to be invisible. -- Christopher Pettus, cep@apple.com
siegel@endor.harvard.edu (Rich Siegel) (04/06/89)
In article <1200@internal.Apple.COM> cep@apple.com (Christopher Pettus) writes: >In article <2749@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) >writes: >> I have an application that tries to be a good citizen by shrinking >windows >> when it's not the foreground app. > >While for some applications this might make sense, remember that the >interface guidelines strongly advise against messing with the size or >position of user-defined windows except under user control. For example, >if the user had set up a screen neatly so that they could see some info in >your application before bringing another forward, they would be rather >upset if the windows then moved so as to be invisible. > In any case, this branch of the discussion is made moot by Set Aside. One reason for wanting to know about MultiFinder is so that an application can know to leave room for the Finder's icons along the right- hand edge of the screen, when zooming windows. For example, More II does this. [Well, More II does lots of other bizarre things, but... :-) ] --Rich ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "She told me to make myself comfortable, so I pulled down my pants and sat in the pudding." -Emo Phillips ~~~~~~~~~~~~~~~
lsr@Apple.COM (Larry Rosenstein) (04/06/89)
In article <12910@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > I have MPW Shell 2.0.2, and it obviously knows whether Launch will > return or not, and therefore knows whether MultiFinder is active. It As someone pointed out (and is mentioned in the Tech Notes), there is no approved way to know if the Launch trap will return or not. As Phil Goldman mentioned, this is being fixed. If your application launches programs and cares about this (as does MPW) then there is currently no alternative. Such applications are relatively uncommon, and Tech Support discourages people from writing such applications. I would go so far as t osay MPW is folowing the rules. It is checking for a particular system feature and altering it behavior depending on whether it is present or not. The only problem is that there is no 100% approved mechanism for making this test. As always the price for not following the rules is possibly having to rev your program for a new system. Presumably, MPW uses the best known technique for detecting whether Launch can return, which means it has a reasonable chance of being compatible with future systems. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
lsr@Apple.COM (Larry Rosenstein) (04/06/89)
In article <20057@srcsip.UUCP> mnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) writes: > But for now you can check if the standard MDEF (id=0) is in the system > heap or the application heap. If it's in the system heap then MF is > probably running. I say probably because an init I'm working on loads Then I would say that this is probably a bad idea. You give a simple case where this check would fail. The result of relying on this check will be a program that doesn't work when your INIT is installed. It is also conceivable that a future system would have the system MDEF in ROM, or would load the MDEF in the system heap all the time to improve program launch time under UniFinder. People are looking at this from the wrong perspective. It is natural to want to ask "How do I know if MultiFinder is running?" but that is the wrong way to look at your program. You should be looking at the system from the point of view of system features, not how those features are implemented. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
levin@bbn.com (Joel B Levin) (04/06/89)
In article <1558@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: | One reason for wanting to know about MultiFinder is so that an |application can know to leave room for the Finder's icons along the right- |hand edge of the screen, when zooming windows. . . Better, and getting back to the real functionality, why not let the use decide (a) what the zoomed and unzoomed sizes are (kept in the resource fork) - VersaTerm does this; and (b) what the defaults for this should be (this is rare, but I think someone does this - maybe MPW Shell?)? What if I'm using a finder substitute and I don't want to waste the space on the right for those icons? Let the user set these values and their defaults on the basis of needs or wants; don't presuppose what they should be based on external circumstances which you might not be able to get right anyhow. /JBL == UUCP: {backbone}!bbn!levin POTS: (617) 873-3463 INTERNET: levin@bbn.com
lsr@Apple.COM (Larry Rosenstein) (04/07/89)
In article <1558@husc6.harvard.edu> siegel@endor.harvard.edu (Rich Siegel) writes: > One reason for wanting to know about MultiFinder is so that an > application can know to leave room for the Finder's icons along the right- > hand edge of the screen, when zooming windows. For example, More II does This is similar to shrinking windows when in the background. Given that Set Aside exists this feature is not needed. Let's assume that this is in fact a desirable feature. What you want to know then is not whether MultiFinder is running, but rather if there are icons on the desktop that you might not want to cover up. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
dee@XAIT.Xerox.COM (Donald Eastlake) (04/07/89)
In article <1179@internal.Apple.COM> goldman@apple.com (Phil Goldman) writes: >In article <28689@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu (David >Phillip Oster) writes: >> The standard, from Apple is "Don't even try to do this". Most people do >> it by checking to see if the end of the system heap is close to the >> beginning of the application heap. If it is, no multifinder. >This is a very bad thing to do, ... >Reasons such as putting up a dialog box saying "Cannnot do...with >MultiFinder" are very poor ones. ... Thanks for reminding me. There is another place I "check for MultiFinder". My program allows a user to Unmount volumes. Unfortunately, there is a bug in MultiFinder, which is supposed to close the DeskTop file when an application does an Unmount, where it fails to do this on flat file system volumes and you get a busy error message. Things are a bit complicated because a volume could be legitamately busy but if I get this error when trying to unmount a volume and its non-hierarchial and MF (actually the temp mem traps) is present I suggest the user try switching to the Finder and drag the volume to the trash, which will work if this MF bug is their problem. -- +1 617-969-9570 Donald E. Eastlake, III ARPA: dee@XAIT.Xerox.COM usenet: {cbosg,decvax,linus}!cca!dee P. O. Box N, MIT Branch P. O., Cambridge, MA 02139-0903 USA
ech@pegasus.ATT.COM (Edward C Horvath) (04/07/89)
From article <1200@internal.Apple.COM>, by cep@apple.com (Christopher Pettus): > ...interface guidelines strongly advise against messing with the size or > position of user-defined windows except under user control... > -- Christopher Pettus, cep@apple.com Exactly. Now if the behavior is one the user WANTS, I ought to be able to deliver, right? So NOW can I have the Suspend event? =Ned Horvath=
ech@pegasus.ATT.COM (Edward C Horvath) (04/07/89)
From article <1203@internal.Apple.COM>, by lsr@Apple.COM (Larry Rosenstein): > People are looking at this from the wrong perspective. It is natural to > want to ask "How do I know if MultiFinder is running?" but that is the > wrong way to look at your program. You should be looking at the system > from the point of view of system features, not how those features are > implemented. This requires a mild flame. I'll concede the point. However, the most important "feature" of the Macintosh interface, as perceived by the end-user, is the appearance of the graphical screen. Under MultiFinder, that appearance is QUALITATIVELY DIFFERENT, since there is "other stuff" behind (or in front of) the graphical objects that are provided by my app. As long as screen real estate is at a premium (which is the forseeable future, especially on the Compact and Laptop macs), I'm going to want to help my user get the most mileage out of that screen appearance. That means I want to be SENSITIVE to the presence of other apps, just so I can get out of the way. Arguments to the effect that apps that launch, or react visibly to suspend events "shouldn't do that" -- that ONLY Apple can break Apple's rules -- reflect a bad attitude. If Apple needs to do it, someone else does too. The market is capable of assessing departures from the interface guidelines and deciding if the departure is appropriate or not. VersaTerm's behavior is a case in point: I NEED the whole screen for a 24x80 terminal emulator, but I want it OUT OF THE WAY when I'm not typing at it. Lonnie did the right thing, and the guidelines be damned: they're guidelines, not dogma. Larry, you have my respect on most issues, but on this one you need to reassess your position. Apple does not know best about everything, your need to innovate is the same as my need to innovate (does SmallTalk-80 follow the interface guidelines?), don't tell me what I need isn't important, or isn't appropriate. The Finder ain't perfect. MultiFinder isn't either. The criticisms in the forum have been constructive, not nasty. When Apple does well, we all do well. And vice versa. OK, flame off. Keep up the good work, and thanks! =Ned Horvath
mnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) (04/07/89)
In article <1558@husc6.harvard.edu> siegel@endor.harvard.edu (Rich Siegel) writes: > One reason for wanting to know about MultiFinder is so that an > application can know to leave room for the Finder's icons along the right- > hand edge of the screen, when zooming windows. For example, More II does Aha! Note that Finder icons are not restricted to the right side of the screen. The user can put them just about anywhere. Thus trying to leave room for Finder icons would really mean putting your windows in deep space. (How's that for floating windows?) ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
goldman@apple.com (Phil Goldman) (04/07/89)
In article <2749@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) writes: > This works fine EXCEPT when the application is part of a "Set Startup" > set and does not wind up frontmost. The app is set up in background, > and stays in background, but doesn't receive an initial Resume OR Suspend. > > Minor, but several of my users have complained about it. Simplest fix for > Apple is just to make sure startup apps get a Suspend event (preferably > excepting the frontmost app). MF *does* give background apps a suspend event as the first event. However, like all suspend/resume events the event will be dropped if the app calls _WaitNextEvent/_GetNextEvent/EventAvail with app4 events masked out. Perhaps this is why your app does not see it. -Phil Goldman Apple Computer
goldman@apple.com (Phil Goldman) (04/07/89)
In article <43465@XAIT.Xerox.COM> dee@XAIT.Xerox.COM (Donald Eastlake) writes: > Thanks for reminding me. There is another place I "check for MultiFinder". > My program allows a user to Unmount volumes. Unfortunately, there is a bug > in MultiFinder, which is supposed to close the DeskTop file when an > application does an Unmount, where it fails to do this on flat file > system volumes and you get a busy error message. Things are a bit > complicated because a volume could be legitamately busy but if I get > this error when trying to unmount a volume and its non-hierarchial and > MF (actually the temp mem traps) is present I suggest the user try > switching to the Finder and drag the volume to the trash, which will > work if this MF bug is their problem. This is a bug, albeit a minor one, in the system. The problem is that it is extremely difficult to find the Desktop file on an MFS disk, because the FCB does not contain a name. There are gross ways to do it, but the feeling was that it was unimportant since there is no reason to use MFS disks in any case. Anway...if you are convinced that this is a serious bug, you should probably tell Mac Tech support. If enough developers complain then we would reevaluate the priority of the bug fix. You might also inform them if you can think of a clever fix. -Phil Goldman Apple Computer
cep@apple.com (Christopher Pettus) (04/07/89)
In article <2755@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) writes: > From article <1200@internal.Apple.COM>, by cep@apple.com (Christopher Pettus): > > ...interface guidelines strongly advise against messing with the size or > > position of user-defined windows except under user control... > Exactly. Now if the behavior is one the user WANTS, I ought to be able to > deliver, right? Well, not exactly. You wish to cause automatic behavior, without user intervention, which you presume that the user wants. The user interface guidelines say that if the user wants the windows to be in a certain place, s/he will put them there, so don't do it yourself. -- Christopher Pettus, cep@apple.com
goldman@apple.com (Phil Goldman) (04/07/89)
In article <12910@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > In article <1179@internal.Apple.COM> goldman@apple.com (Phil Goldman) writes: > >In article <28689@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu (David > >Phillip Oster) writes: > >> The standard, from Apple is "Don't even try to do this". Most people do > >> it by checking to see if the end of the system heap is close to the > >> beginning of the application heap. If it is, no multifinder. > > > >This is a very bad thing to do, and, as was mentioned in a previous > >posting, the one known legitimate reason for doing so will soon be fixed > >in SysEnvirons. > > > I fully agree that it is bad to check for Multifinder in terms of > future compatibility. If Apple wants developers to refrain from doing > this, they should NOT DISTRIBUTE DEVELOPER'S TOOLS WHICH OBVIOUSLY DO. > I have MPW Shell 2.0.2, and it obviously knows whether Launch will > return or not, and therefore knows whether MultiFinder is active. It > undoubtedly uses some non-approved method of finding out whether > MultiFinder is active or not. Apple cannot reasonably expect > developers to refrain from checking for MultiFinder active, and at the > same time sell them a program which does. "Don't do as I do, do as I > say." is not very convincing coming from anybody. As I mentioned in the original posting, there is currently one legitimate reason to check for MF. It can be done by applications that need to know whether _Launch will return. This will be fixed in a future System release. Until then, the approved method, which the MPW Shell uses, is to check for the existence of the temporary memory trap. What Apple says (in the Technotes), and does (in the code for the Shell) is to request that _Launch not even be called, unless the application is a programming environment and is willing to be broken across System releases. This is a bit harsh, and will probably not happen, but both criteria are true of the Shell. -Phil Goldman Apple Computer
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (04/07/89)
In article <1234@internal.Apple.COM> goldman@apple.com (Phil Goldman) writes: >In article <2749@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) >writes: .> This works fine EXCEPT when the application is part of a "Set Startup" .> set and does not wind up frontmost. The app is set up in background, .> and stays in background, but doesn't receive an initial Resume OR .Suspend. >MF *does* give background apps a suspend event as the first event. >However, like all suspend/resume events the event will be dropped if the >app calls _WaitNextEvent/_GetNextEvent/EventAvail with app4 events masked >out. Perhaps this is why your app does not see it. Or perhape we are all calling GetNextEvent 4 times before actually looking at the event returned [I forget what this hack was for]? Or calling FlushEvents at the start of the App? Marc Kaufman (kaufman@polya.stanford.edu)
mithomas@bsu-cs.bsu.edu (Michael Thomas Niehaus) (04/07/89)
In article <2756@pegasus.ATT.COM>, ech@pegasus.ATT.COM (Edward C Horvath) writes: > This requires a mild flame. > > I'll concede the point. However, the most important "feature" of the > Macintosh interface, as perceived by the end-user, is the appearance of > the graphical screen. Under MultiFinder, that appearance is QUALITATIVELY > DIFFERENT, since there is "other stuff" behind (or in front of) the > graphical objects that are provided by my app... How about this: in the next generation of Macintoshes, let's use a 3- dimensional screen, with the ability to move windows onto any three- dimensional plane. Then, when you want to move some of your windows out of the way, you can move them so that they are perfectly horizontal from the user's perspective. Doing this, they would appear as just one thin line (assuming that a window would have debth as well). Just think of how many of these windows you could have on the screen at one time (not to mention how hard it would be to click on one specific one to bring it back into view :-). I must say, I don't really care for applications that move windows around on their own (take MacWrite's spell checker for example), just as much as I don't like people trying to guess what I would like. My vote goes for not violating the user interface guidelines. > OK, flame off. Keep up the good work, and thanks! > > =Ned Horvath I'll agree with that. Very good work. -Michael p.s. To Apple, I am just a number. To Ball State, I am just a source of income. -- Michael Niehaus UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!mithomas Apple Student Rep ARPA: mithomas@bsu-cs.bsu.edu Ball State University AppleLink: ST0374 (from UUCP: st0374@applelink.apple.com)
jackiw@cs.swarthmore.edu (Nick Jackiw) (04/07/89)
In article <2756@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) writes: > > As long as screen real > estate is at a premium (which is the forseeable future, especially on > the Compact and Laptop macs), I'm going to want to help my user get the > most mileage out of that screen appearance. That means I want to be > SENSITIVE to the presence of other apps, just so I can get out of the way. > > Arguments to the effect that apps that launch, or react visibly to suspend > events "shouldn't do that" -- that ONLY Apple can break Apple's rules -- > reflect a bad attitude. If Apple needs to do it, someone else does too. > The market is capable of assessing departures from the interface guidelines > and deciding if the departure is appropriate or not. VersaTerm's behavior > is a case in point: I NEED the whole screen for a 24x80 terminal emulator, > but I want it OUT OF THE WAY when I'm not typing at it. Lonnie did the > right thing, and the guidelines be damned: they're guidelines, not dogma. > Excellent points, Ned. Furthermore, Apple's guidelines allegedly apply to commercial (or at least public) "development." Believe it or not, some of us still "write programs" instead of developing. If I want to draw directly to the screen, for my OWN PRIVATE ENDS, I feel like I've paid enough for my machine and documentation to be able to do this. When I do, though, it would be really nice to be able to say "Can't use under Multifinder" simply to prevent me from trying anything stupid. A more vital example: a buggy app, almost guaranteed to crash and perhaps fatally, undergoing testing. Did you forget to save all your files in all other partitions before launching it? No? Well, I wish I could warn you you should; but Apple won't let me. Note also that the mysterious "Set Aside" option which is currently being offered by the party-line as pancea to all our woes is simply a meta-hack. Apple is downgrading the incredibly clever and useful visual nature of MultiFinder to Switcher's seemingly uni-process model. Larry, how am I going to compare data from two apps with one of them set aside? How am I going to click on the app I want next (I don't use Suitcase, and so my full Apple-menu is tremendously tedious to navigate). Moreover, what's going to happen to things like your TimeKeeper, or Brecher's PowerStation, or Sinclair's MacEyes, or my Tescher ... all aesthetically (and some practically) useful additions to my desktop? It really seems like Apple has Set Aside its usual good sense to stick to an ideologically- entrenched but conceptually-faulty idea. > Larry, you have my respect on most issues, but on this one you need to > reassess your position. Apple does not know best about everything, your > need to innovate is the same as my need to innovate (does SmallTalk-80 > follow the interface guidelines?), don't tell me what I need isn't > important, or isn't appropriate. Agreement...to ALL parts. -- _ _|\____ Nick Jackiw | Visual Geometry Project | Math Department / /_/ O> \ ------------+-------------------------+ Swarthmore College | O> | 215-328-8225| jackiw@cs.swarthmore.edu| Swarthmore PA 19081 \_Guernica_/ ------------+-------------------------+ USA
jackiw@cs.swarthmore.edu (Nick Jackiw) (04/07/89)
In article <8235@polya.Stanford.EDU> kaufman@polya.Stanford.EDU (Marc T. Kaufman) writes: > [Bulk deleted] > Or perhape we are all calling GetNextEvent 4 times before actually looking > at the event returned [I forget what this hack was for]? > Marc Kaufman (kaufman@polya.stanford.edu) Do it before calling {Get}NewWindow in order to establish your layer as top- most instead of bottom-most. Windows come up on top instantly, instead of FIRST on bottom, THEN on top. Still a requisite hack, I believe. -- _ _|\____ Nick Jackiw | Visual Geometry Project | Math Department / /_/ O> \ ------------+-------------------------+ Swarthmore College | O> | 215-328-8225| jackiw@cs.swarthmore.edu| Swarthmore PA 19081 \_Guernica_/ ------------+-------------------------+ USA
ech@pegasus.ATT.COM (Edward C Horvath) (04/08/89)
From article <1234@internal.Apple.COM>, by goldman@apple.com (Phil Goldman): > MF *does* give background apps a suspend event as the first event. > However, like all suspend/resume events the event will be dropped if the > app calls _WaitNextEvent/_GetNextEvent/EventAvail with app4 events masked > out. Perhaps this is why your app does not see it. Thanks, Phil, I'll go look for that. I don't mask out ANYTHING. Unfortunately, I also notice that (consistent with ancient guidelines!) my app calls FlushEvents (allEvents) early...I'll try it with app4Events unflushed. =Ned Horvath=
han@Apple.COM (Byron Han, wyl E. coyote ) (04/08/89)
In article <8235@polya.Stanford.EDU> kaufman@polya.Stanford.EDU (Marc T. Kaufman) writes: > >Or perhape we are all calling GetNextEvent 4 times before actually looking >at the event returned [I forget what this hack was for]? Or calling >FlushEvents at the start of the App? I personally always call EventAvail which doesn't do anything to the event queue... +-----------------------------------------------------------------------------+ | Disclaimer: Apple has no connection with my postings. | +-----------------------------------------------------------------------------+ Byron Han, Communications Architect Cereal, anyone? :-) A1! Apple Computer, Inc. ------------------------------------- 20525 Mariani Ave, MS27Y Internet: han@apple.COM Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han -------------------------------------- GENIE: BYRONHAN ATTnet: 408-974-6450 Applelink: HAN1 CompuServe: 72167,1664 ------------------------------------------------------------------------------
earleh@eleazar.dartmouth.edu (Earle R. Horton) (04/08/89)
In article <2749@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) writes: >This isn't a need-to-know, but rather an annoyance. > >I have an application that tries to be a good citizen by shrinking windows >when it's not the foreground app. I'm not the author of VersaTerm, but it >does this also. > I for one do not ever want to have to write code which does this. Window sizes and locations should always be under user control. The new MultiFinder (6.1a2, I ftp'ed if from somewhere, and don't remember where if you're asking) has an option to "Set Aside" applications so that their windows are not visible. This means that you can use it sort of like Switcher if you want, or like the "regular" MultiFinder if you want. If Apple ever makes an official release out of it, lots of problems like those above will vanish. One of the beauties of MultiFinder is how surprisingly little you have to do to be compatible with it. If developers resort to tricks like shrinking their windows when suspended, I think they are second-guessing what Apple is going to do, and what users are going to need, and will probably experience problems in the future. ... >This works fine EXCEPT when the application is part of a "Set Startup" >set and does not wind up frontmost. The app is set up in background, >and stays in background, but doesn't receive an initial Resume OR Suspend. I agree that this is definitely a bug. Keeping track of Resume/Suspend events is not a good way for an application to find out if is in the background or foreground, especially if there are conditions where you don't get all of them you are entitled to. Earle
dee@XAIT.Xerox.COM (Donald Eastlake) (04/08/89)
In article <1235@internal.Apple.COM> goldman@apple.com (Phil Goldman) writes: >In article <43465@XAIT.Xerox.COM> dee@XAIT.Xerox.COM (Donald Eastlake) writes: >> My program allows a user to Unmount volumes. Unfortunately, there is a bug >> in MultiFinder, which is supposed to close the DeskTop file when an >> application does an Unmount, where it fails to do this on flat file >> system volumes and you get a busy error message. ... >This is a bug, albeit a minor one, in the system. The problem is that it >is extremely difficult to find the Desktop file on an MFS disk, because >the FCB does not contain a name. There are gross ways to do it, but the >feeling was that it was unimportant since there is no reason to use MFS >disks in any case. I don't know how the current kludge for unmounting volumes works but why do you need a name? TN 180 clearly says that MF asks the finder to close the DeskTop file. If the Finder is what opened it and keeps it opne how can it possibly be any problem for it to close it??? There will be MFS disks around for MANY YEARS. Ignoring them is a bad idea. (My program even makes a try at running under the 64K ROM although many of its features are disabled.) -- +1 617-969-9570 Donald E. Eastlake, III ARPA: dee@XAIT.Xerox.COM usenet: {cbosg,decvax,linus}!cca!dee AppleLink: D2002 Box N, MIT Branch PO, Cambridge, MA 02139 USA
earleh@eleazar.dartmouth.edu (Earle R. Horton) (04/08/89)
In article <1558@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: ... > One reason for wanting to know about MultiFinder is so that an >application can know to leave room for the Finder's icons along the right- >hand edge of the screen, when zooming windows. For example, More II does >this. [Well, More II does lots of other bizarre things, but... :-) ] > The Finder has no business drawing on the DeskTop. The Finder authors are simply going to have to learn to draw things in their own layer, like everyone else. I say that leaving room for the Finder's icons is questionable programming, and you will probably uncover only the column of disk icons on the right, anyway. Many people like to have lots and lots of document, folder, and application icons out when working with the Finder, so you have no hope of knowing there the Finder icons are, really. DON'T USE THIS TECHNIQUE. IT PREVENTS USERS FROM SEEING THAT THE FINDER NEEDS TO FIND SOME OTHER PLACE TO PUT THIS STUFF. Earle
tim@hoptoad.uucp (Tim Maroney) (04/08/89)
In article <1558@husc6.harvard.edu> siegel@endor.harvard.edu (Rich Siegel) writes: > One reason for wanting to know about MultiFinder is so that an > application can know to leave room for the Finder's icons along the right- > hand edge of the screen, when zooming windows. For example, More II does In article <1212@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >Let's assume that this is in fact a desirable feature. What you want to >know then is not whether MultiFinder is running, but rather if there are >icons on the desktop that you might not want to cover up. Actually, what I'd prefer is for the Finder to come into line with the Mac interface and stop writing into the desktop altogether. The volume and trash icons should be in a window, not on the desktop. I run MultiFinder and I'm bloody well sick and tired of moving other application's windows to the left just so I can get at my hard disk and trash icons. If they were in windows, they would come up when the Finder came to the front, and I would be spared a lot of aggravation. Why is that Apple's software (e.g., Hypercard, Finder, Font/DA Mover, ResEdit, original MacPaint) is so cavalier about the Mac interface standards, while any of us who dare to violate them get our little wrists slapped? -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Americans will buy anything, as long as it doesn't cross the thin line between cute and demonic." -- Ian Shoales
mnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) (04/08/89)
In article <2756@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) writes: > >I'll concede the point. However, the most important "feature" of the >Macintosh interface, as perceived by the end-user, is the appearance of >the graphical screen. Under MultiFinder, that appearance is QUALITATIVELY No. It's the combination of graphics and CONSISTENCY from app to app. >Arguments to the effect that apps that launch, or react visibly to suspend >events "shouldn't do that" -- that ONLY Apple can break Apple's rules -- >reflect a bad attitude. If Apple needs to do it, someone else does too. It reflects the fact that Apple is the keeper of the OS/Interface etc. If every one who thinks they have a better way of doing things did it their way (like Microsoft) then you'd lose the consistency of the interface. ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
lsr@Apple.COM (Larry Rosenstein) (04/08/89)
In article <2756@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) writes: > >the graphical screen. Under MultiFinder, that appearance is QUALITATIVELY >DIFFERENT, since there is "other stuff" behind (or in front of) the That is an implementation detail. What you really want to know is whether there are icons on the desktop, or whether there are icons in certain positions. It just so happens that at present, having MultiFinder running is a necessary condition for this. >the Compact and Laptop macs), I'm going to want to help my user get the >most mileage out of that screen appearance. That means I want to be >SENSITIVE to the presence of other apps, just so I can get out of the way. In this case, my preference would be for each application to use the limited screen space to its best advantage. I would be really annoyed if MacWrite or MacTerminal (to use 2 examples) shrunk their windows horizontally under MultiFinder. In both those applications, you really need the maximum horizontal screen space on a compact Mac. If your application is one than can work effectively in a smaller window, then that should be its default, and you can provide a way for the user to set the default window location. You should also adapt to the size of the screen so that users with larger screens get larger default windows. Even if the user isn't using MultiFinder, they might have DAs or other program windows up, so that defaulting to a smaller window size might make some sense all the time. I don't think you can predict how people are going to organize their DA windows or their desktops, and that it only makes sense to provide a way to change the default window placement (short of using ResEdit). >Arguments to the effect that apps that launch, or react visibly to suspend >events "shouldn't do that" -- that ONLY Apple can break Apple's rules -- >reflect a bad attitude. If Apple needs to do it, someone else does too. You are talking about a different issue here; one of launching applications. The Tech Note doesn't say only Apple is allowed to do this, it says that only applications that want to act as program shells should. It then goes on to tell you how to do it the best way given the present system software. >but I want it OUT OF THE WAY when I'm not typing at it. Lonnie did the >right thing, and the guidelines be damned: they're guidelines, not dogma. Shrinking the window while in the background sounds like a good idea to me, although, I'm sure that I would want to turn this off sometimes. (I never argued that this wasn't a good idea; I was simply giving reasons why you should not be asking the question "Is MultiFinder running?") You can also do this without worrying about whether MultiFinder is running; all you care about is whether you get a suspend event or not. You are absolutely right about the guidelines; they are only guidelines. We don't make up user interface or programming guidelines just for fun. People here put a lot of thought into them, and the guidelines are intended to tell developers important information. Often we don't give sufficient justification for the guidelines, which makes them look somewhat arbitrary. It still is in your best interest to look at them and think about the consequences of not following the guidelines. Several people have said in this and other forums, that if you have a legitmate piece of information about the system to make a suggestion to Tech Support. You are going to have a hard time, however, convincing them that SysEnvirons needs a isMultiFinderRunning bit. Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
keith@Apple.COM (Keith Rollin) (04/08/89)
In article <6915@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > >Why is that Apple's software (e.g., Hypercard, Finder, Font/DA Mover, >ResEdit, original MacPaint) is so cavalier about the Mac interface >standards, while any of us who dare to violate them get our little >wrists slapped? >-- Who's slapped your wrist? Has anyone come by and taken your software away? You are welcome to do anything you want. However, Apple has to take a responsible position and not encourage you to do anything that might cause your programs to break in the future. So why don't we do as we say? Why do we seemingly come out with software that breaks our own guidelines? Using the the example of MacPaint wasn't really fair. That was one of the first programs ever written for the Mac, well before all of the guidelines had been established. As you well know, MacPaint has been revised to work well within today's current standards. I don't know what you are referring to when you mention ResEdit. I think that the current version (1.2b3 or b4) works fairly well. Earlier versions didn't follow all of the rules, and as you have probably noticed, they failed with newer releases of the System. By not following the rules, even we get bit. F/DA Mover and the Finder are System Software. I think that F/DA Mover is the only program that we say is OK to modify the System file (actually, there is the Installer, too). As such, it gets to have a little carnal knowledge of the System. The Finder, obviously, is integral to the working of your Macintosh. Asking why it gets to know about MultiFinder is a bit like asking why Multi- Finder gets to know about the Finder. However, I personally think that some thought might have to go into this Desktop drawing thing. Right now, its little hiney is covered by Macintosh Technote #194, which says that the Window Manager port is reserved for the system (ie, Finder), but it sets a bad example to all the developers out there. Finally, there's HyperCard. On that one, I take the Fifth. HyperCard hides and draws directly into the menubar, plays around with locating the mouse, draws directly to the screen when it can, doesn't have a grow box or scrollbars, is limited to just one window, and probably knows how to sublaunch. As a member of Apple's Developer Technical Support group, I am not the one to defend this. All I can say is that they did it without help from us! If you want to use any of these techniques, you are in the same boat as Bill Atkinson. ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
stores@unix.SRI.COM (Matt Mora) (04/11/89)
In article <28602@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >All I can say is that they did it without help from us! If you want to use any >of these techniques, you are in the same boat as Bill Atkinson. As if Bill would really need your help :-) >------------------------------------------------------------------------------ >Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support >INTERNET: keith@apple.com > UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith >"Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions I think that the Desktop window for the finder is a great idea. The clean up desktop command would really work. Also you could but the Icons where you want (the User not the system. "your program should not change things that the user is allowed to move" this should also be the case for the {multi}Finder) -- ___________________________________________________________ Matthew Mora SRI International stores@SRI.COM ___________________________________________________________
kent@lloyd.camex.uucp (Kent Borg) (04/12/89)
In article <38341@bbn.COM> levin@BBN.COM (Joel B Levin) writes: [In talking about detecting whether MultiFinder is running, whether there are icons along the right edge of the screen, whether the user is running a Finder replacement...] >Let the user set these values and their defaults on the basis of needs >or wants; don't presuppose what they should be based on external >circumstances which you might not be able to get right anyhow. > > /JBL >== >UUCP: {backbone}!bbn!levin POTS: (617) 873-3463 >INTERNET: levin@bbn.com Two comments. 1) Finder replacements seem more-and-more delicate to me. I hope MDTS is working closely with any brave souls who are doing this. 2) ``Let the user set these values...'' No, No, and No. When the Mac user interface was first being designed there were many tough questions: ``Should we go with A or B?''. Engineers have been faced with tough questions for years, and engineers are usually payed lots of money to find good answers. People accept that--nothing new. Now move to the field of user interfaces and people start popping up with the suggestion: ``Let the user decide!!'', ``I know, we'll make it user configurable!!'', etc. No, that's poor engineering. It is not legitimate to pass engineering decisions off to the end user. (I do dub thee ``Kent's Law of User Interfaces'' ~boing~) If you have an engineering problem (``How do I know whether there are icons I might be covering up?''), then come up with a well engineered solution (even ask MDTS for help), do *not* leave it for the user to fix. That is not a legitimate solution with other fields of engineering, it is not legitimate with the Macintosh (IBM users might get a macho buzz out of configuring their own software and hardware--but this is comp.sys.MAC.programmer). Wait! Before you all kill me for locking out the user, I certainly think there should be lots of room for end-user customizing. I'll even say ``as much as possible''. But think first. I can adjust the seat in my car--but I don't need to configure the door latches. I can set how brown I want my toast--but I don't need to reshape the heating elements. = If a user adjustable feature is a cop-out for making an engineering descision, it is a mistake. = If the user adjustable feature will make your gizmo dangerous, it is a mistake. (``Car Crash! ID=-1, Wheels fell off. Sorry, you should have configured to run with lug nuts `on'. '') The bottom line is that you should design a complete, well thought out, and useful product. The user should not have to finish building it for you. Whatever customization you can add within those bounds is great, but even then, stop and look: = What will customization `X' offer? = Is there a way we can give that to user's *without* forcing the user to play with options--sometimes you can get some great ideas this way. Remember, the Macintosh is simple to use, but getting it that way was not simple. Think very hard about user interface decisions you make. Be wary of little, incremental, one-off changes which make the larger design worse. They are one of the causes of `featuritis'. Partial exception: You can sometimes reasonably pass engineering decisions off to other engineers if they are your market and you are building an engineering tool--but even then don't use this as an excuse. Even engineers can sometimes spot that. Kent Borg kent@lloyd.uucp or ...!hscfvax!lloyd!kent
cole@sas.UUCP (Tom Cole) (04/18/89)
In article <1200@internal.Apple.COM>, cep@apple.com (Christopher Pettus) writes: > In article <2749@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) > writes: > > I have an application that tries to be a good citizen by shrinking > windows > > when it's not the foreground app. > > While for some applications this might make sense, remember that the > interface guidelines strongly advise against messing with the size or > position of user-defined windows except under user control. For example, > if the user had set up a screen neatly so that they could see some info in > your application before bringing another forward, they would be rather > upset if the windows then moved so as to be invisible. > > -- Christopher Pettus, cep@apple.com Righto! In fact, when the newer versions of MultiFinder finally become part of the normal system, then the user can specifically control what happens to the windows of an application that is switched out, by using the option key when clicking on the "switch" icon in the upper right corner, or using "Set Aside..." from the apple menu. It seems much much more desirable to always let the user decide what happens. Parenthetical opinion: it is somewhat irksome that PrintMonitor will always set aside or otherwise obliterate its windows when suspended. There are many times when I have wished I could leave the Print Monitor window up in some corner of the screen (north 40, perhaps) and watch the progress of my printing while continuing work. I suppose Print Monitor has its reasons, but it would be nice if it worked otherwise, waiting for me to explicitly send its window away... Tom Cole SAS Institute l i n e e a\ t e r s b e g o n e
darin@Apple.COM (Darin Adler) (04/20/89)
In article <1001@sas.UUCP> cole@sas.UUCP (Tom Cole) writes: > Parenthetical opinion: it is somewhat irksome that PrintMonitor will > always set aside or otherwise obliterate its windows when suspended. There > are many times when I have wished I could leave the Print Monitor window > up in some corner of the screen (north 40, perhaps) and watch the progress > of my printing while continuing work. I suppose Print Monitor has its > reasons, but it would be nice if it worked otherwise, waiting for me > to explicitly send its window away... This is a good idea, and PrintMonitor allows for it. Open the Preferences dialog in PrintMonitor and change the "Show PrintMonitor's Window When Printing" radio button to Yes. PrintMonitor will no longer its window whenever it's suspended. -- Darin Adler, System Software Scapegoat, Apple Computer Internet: darin@Apple.com UUCP: {nsc,sun}!apple!darin