sam@neoucom.UUCP (Scott A. Mason) (04/04/89)
Hello,
Just a few quick and hopefully not too difficult questions for the
Mac gurus out there.
Firstly, what is the standard way of checking for MultiFinder
existence?
Lastly, what is the standard way of keeping track of the windows,
so that it can be redrawn or updated after a MF switch?
(I hate it when upon returning from the Finder in MF, I find my
window has been erased by all the folders)
Thanks for the info.
--
--------------------------------------------------------------------------------
"If it ain't broke, don't fix it," and certainly don't blame me.
UUCP: {pitt, scooter, hal, cwjcc}!neoucom!sam INTERNET: sam@neoucom.UUCP
Scott A. Mason, Coordinator of Systems Operations, NEOUCOMkeith@Apple.COM (Keith Rollin) (04/05/89)
In article <1562@neoucom.UUCP> sam@neoucom.UUCP (Scott A. Mason) writes: > >Firstly, what is the standard way of checking for MultiFinder >existence? There currently is no way to determine if MultiFinder is running, but that's mostly because we haven't seen a need for this. In DTS, we've found that almost all of the people who ask this questions really want to find out if WaitNextEvent or the MFMemory calls are implemented. In those cases, there are documented methods for finding this out. Just check out Technotes #158, 177, 180, and 205 (the answer's in one of them). If you do have a valid reason for needing to know if MultiFinder is running, please let me know! So far it's been a battle, with developers saying "We need to know!" and Apple saying "No you don't!". Finding a legitimate reason for knowing would put an end to this contest. So far, there is only one valid reason that I know about, and this will be resolved with a future release of the System Disk. It revolves around sub- launching and whether or not you need to save open documents and configura- tions. If you have a reason other than this, again, please let me know! >Lastly, what is the standard way of keeping track of the windows, >so that it can be redrawn or updated after a MF switch? >(I hate it when upon returning from the Finder in MF, I find my > window has been erased by all the folders) This shouldn't be happening. If the Finder is obscuring your windows, and your application is brought to front, you will get an update event (as long as your event mask allows them). ------------------------------------------------------------------------------ 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
oster@dewey.soe.berkeley.edu (David Phillip Oster) (04/05/89)
In article <1562@neoucom.UUCP> sam@neoucom.UUCP (Scott A. Mason) writes: >Firstly, what is the standard way of checking for MultiFinder >existence? 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. >Lastly, what is the standard way of keeping track of the windows, >so that it can be redrawn or updated after a MF switch? You've missed the fundamental point of Mac (or X for that matter) programming. Mac programs work by associating a data structure with a window. During the course of the program, it mutates the data structure. There is a "Draw()" function in the program, that can prowl the data structure, drawing as it goes. Call this in response to an Update event, or if you wish to print, call it with the a grafport from the Printer Manager. The specific data structure is what is appropriate for _your_ program. Some programs use an offscreen GrafPort, which they mutate by standard draw commands, but most use higher level data structures than just the raw pixels. (Thus allowing zooming, panning, or other alternate views of the same data.) "Draw()" defines a function from the internal data structures to screen graphics. Many programs define the inverse of this function "Pick()" which lets the user select an object on the screen with the mouse.
dee@XAIT.Xerox.COM (Donald Eastlake) (04/07/89)
In article <28399@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >In article <1562@neoucom.UUCP> sam@neoucom.UUCP (Scott A. Mason) writes: >>Firstly, what is the standard way of checking for MultiFinder >>existence? >There currently is no way to determine if MultiFinder is running, but that's >mostly because we haven't seen a need for this. ... >If you do have a valid reason for needing to know if MultiFinder is running, >please let me know! So far it's been a battle, with developers saying "We need >to know!" and Apple saying "No you don't!". Finding a legitimate reason for >knowing would put an end to this contest. The way I try to guess if MultiFinder is running is by checking for the temporary memory assignment traps. The reason I want to know is that I dynamicly generate windows in my application with stepped locations and I don't want to cover the volume, etc., Icons that MF likes to put down the right edge of the screen. I also have a "cover sheet" feature to cover all of my windows after some period of user inactivity. For convenience I also contrain it from the right edge under MultiFinder. I suspect that 90%+ of large real applications and a significant proportion of smaller programs check for MF one way or the other. Many of them may not need to but quite a few have arguably good reasons to do so. By refusing to authorize a way to do this, Apple is guaranteeing problems for these applications in the future. In fact, if the goal of Apple is to make it easy to generate programs that will be compatible into the future an authorized way to meet a purely psychological need to know if MF is present seems reasonable to me. Sometimes you should assume the customer is right even if you think you know better. It has always been easy to find out if Switcher is present and I don't know of that every causing any particular problems. While I am sending this message, I'd like to put in my vote for a couple of new traps: TrapExist ( trapnumber ) or the like would do the obvious thing with get trap addresses and the guaranteed undefined trap returning a Boolean. Why make everyone do it the hard way? And glue could check the ROM version... ApplicationTrap ( ... ); this trap would be guaranteed to never be used by Apple but the application would have license to patch it. Sort of like ApplScratch but in the trap number space. -- +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
svc@well.UUCP (Leonard Rosenthol) (04/07/89)
In article <1562@neoucom.UUCP>, sam@neoucom.UUCP (Scott A. Mason) writes: > > Firstly, what is the standard way of checking for MultiFinder > existence? I think I will take the Apple party line on this one - YOU CAN'T! You should not have any need to detect that MF is running. If you need a particular 'feature' of MF like WNE or the MF Mem routines, then simply test for them and if they exist you can use them - but that does NOT imply that MF is running. {I still think Apple should add a isMFRunning field to the SysEnvRec} > Lastly, what is the standard way of keeping track of the windows, > so that it can be redrawn or updated after a MF switch? > (I hate it when upon returning from the Finder in MF, I find my > window has been erased by all the folders) Seems to me that if you have the proper bits sets in the SIZE resource to tell the O.S. that you are MF friendly/aware and that your application handles Update/Activate events properly you should have no problems... -- +--------------------------------------------------+ Leonard Rosenthol | GEnie : MACgician Lazerware, inc. | MacNet: MACgician UUCP: svc@well.UUCP | ALink : D0025
cep@apple.com (Christopher Pettus) (04/07/89)
In article <43464@XAIT.Xerox.COM> dee@XAIT.Xerox.COM (Donald Eastlake) writes: > The way I try to guess if MultiFinder is running is by checking for the > temporary memory assignment traps. My understanding is that as of System 6.0.x, the traps which were previously implemented only under Multifinder are now implemented both under Multifinder and Finder. -- Christopher Pettus, cep@apple.com
omh@brunix (Owen M. Hartnett) (04/08/89)
In article <28399@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >In article <1562@neoucom.UUCP> sam@neoucom.UUCP (Scott A. Mason) writes: >> >>Firstly, what is the standard way of checking for MultiFinder >>existence? > [comments deleted] >If you do have a valid reason for needing to know if MultiFinder is running, >please let me know! So far it's been a battle, with developers saying "We need >to know!" and Apple saying "No you don't!". Finding a legitimate reason for >knowing would put an end to this contest. > Why does there have to be a reason? Why not just put up a flag in Sysenvirons? Apple DTS always seems to have the attitude that it knows best what developers should know about (or rather, not know about). There may be developers out there with legitimate need to know - to fix bugs, to implement a novel feature, or for reasons yet unknown. If the information is available, and properly documented that there should be no reasons for using it (that we are currently aware of), then the programmer will know he has to take the responsibility for using it. True, some developers will misuse it, but then it's their problem. Apple should endeavor to make as much information available as possible, and let us developers write some "insanely great" applications with it. -Owen Owen Hartnett Brown University Computer Science omh@cs.brown.edu.CSNET
keith@Apple.COM (Keith Rollin) (04/09/89)
In article <3637@brunix.UUCP> omh@zaphod.UUCP (Owen M. Hartnett) writes: >In article <28399@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: > >>If you do have a valid reason for needing to know if MultiFinder is running, >>please let me know! So far it's been a battle, with developers saying "We need >>to know!" and Apple saying "No you don't!". Finding a legitimate reason for >>knowing would put an end to this contest. >> > >Why does there have to be a reason? Why not just put up a flag in Sysenvirons? >Apple DTS always seems to have the attitude that it knows best what >developers should know about (or rather, not know about). From one point of view, DTS *DOES* know best what developers should know about. We know what is coming down in the future. We know what changes are being made to the System Software. Based on this knowledge, we try our best to prevent developers from burning themselves. We try to quide them down the road of Future Compatibility. That's our job. So when we make position statements like this, it is with these reasons in mind. Believe me, it's NOT because our egos are too large to even consider that developers have brains of their own. If they were that large, I wouldn't be asking the question that I did. > ... There may be >developers out there with legitimate need to know - to fix bugs, to implement >a novel feature, or for reasons yet unknown. Could you expand on this? - "To fix bugs": What bugs need to be fixed that require the knowledge that MultiFinder is running? - "To implement a novel feature": What kind of features? I would like to know about them. So far, most features that developers want to implement revolve around questions like "Are there icons on the desktop?", or "How do I safely sublaunch?", or "Am I able to unmount an MFS disk", NOT "Is MultiFinder active?" - "For reasons yet unknown": Until those reasons DO become known, there is no reason for checking for MultiFinder. I can't see a developer saying "Gee, let's check for MultiFinder. I don't know why, but it might come in handy in the future." >If the information is available, and properly documented that there >should be no reasons for using it (that we are currently aware of), then >the programmer will know he has to take the responsibility for using it. > >True, some developers will misuse it, but then it's their problem. Apple >should endeavor to make as much information available as possible, and let >us developers write some "insanely great" applications with it. It's not just the developer's problem. It's Apple's problem and it's the customer's problem. If a developer writes a program that misuses information, the customer loses out when their program breaks when they upgrade to the next version of System Software. And Apple loses out because we get blamed for breaking that software. The customer doesn't know what is going on behind the scenes; all they know is that their Macintosh doesn't work, and that Apple makes Macintoshes. You should read our Customer mail! We've already seen the misuse of MultiFinder information happen. When System 6.0 came out, WaitNextEvent was implemented all of the time. Many applications subsequently failed to work properly. This was despite warnings about this in Technotes. As a major computer company, Apple has to be responsible about the kinds of information it gives out. We cannot in good conscience give out information to developers that they can use to hang themselves. This is Tech Support's current stance. Do you disagree with it? Do you think that DTS should supply the rope? If we did, do you think that the customers who constantly have to put up with broken software could ever forgive us? > >Owen Hartnett >Brown University Computer Science > ------------------------------------------------------------------------------ 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
omh@brunix (Owen M. Hartnett) (04/09/89)
In article <28638@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >In article <3637@brunix.UUCP> omh@zaphod.UUCP (Owen M. Hartnett) writes: >>In article <28399@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >> >>>If you do have a valid reason for needing to know if MultiFinder is running, >>>please let me know! So far it's been a battle, with developers saying "We need >>>to know!" and Apple saying "No you don't!". Finding a legitimate reason for >>>knowing would put an end to this contest. >>> >> >>Why does there have to be a reason? Why not just put up a flag in Sysenvirons? >>Apple DTS always seems to have the attitude that it knows best what >>developers should know about (or rather, not know about). > >From one point of view, DTS *DOES* know best what developers should know >about. We know what is coming down in the future. We know what changes are >being made to the System Software. Based on this knowledge, we try our best to >prevent developers from burning themselves. We try to quide them down the road >of Future Compatibility. That's our job. So when we make position statements >like this, it is with these reasons in mind. Believe me, it's NOT because our >egos are too large to even consider that developers have brains of their own. >If they were that large, I wouldn't be asking the question that I did. > I don't mean to imply that your egos are too large - I'm saying that you've reserved a *lot* of areas as "stuff you shouldn't know." Witness the entire Printing Manager. I know your motives are pure, but we both can see what the result of this is: If there is a need to know something, Programmers will implement a hack. Just look at the responses to this posting that appeared previously, there were several methods to find out if MF is running, some good, some bad, all verboten and tenuous. And... if there's a legitimate feature that should be implemented, then somebody like Microsoft will implement it (i.e. printing closer to the page margins than the LaserWriter driver allows) and then you'll have to support it because you won't want to break a MS product which has sold millions. Now if Ashton-Tate or Informix uses another method, then there's another method to deal with. Meanwhile, smaller developers without the time or resources to invent such hacks have to leave them out of their programs, while the big software houses are being, albeit grudgingly, subsidized by Apple. What I'm saying is that we should have more information available to us. Please consider the plight of the software developer who obeyed all the rules, but by doing so was forced to leave out features which his larger competitors were able to use. Don't get me wrong here - I know the work that went into writing Inside Mac and the technotes - which was tremendous. It's just that things which will enable valuable features are often sacrificed to future compatibility. >> ... There may be >>developers out there with legitimate need to know - to fix bugs, to implement >>a novel feature, or for reasons yet unknown. > >Could you expand on this? > > - "To fix bugs": What bugs need to be fixed that require the knowledge > that MultiFinder is running? You've already pointed out the sublaunching problem. Were I to attempt sublaunching without reading the previous articles and relying on the printed material, I'd be in Dire Straits. > - "To implement a novel feature": What kind of features? I would like > to know about them. So far, most features that developers want > to implement revolve around questions like "Are there icons > on the desktop?", or "How do I safely sublaunch?", or "Am I > able to unmount an MFS disk", NOT "Is MultiFinder active?" Suppose someone wanted to know if a file was in the trash? Why, because it's a configuration file, and if it exists, then rewrite the file, but if it doesn't, create a new one. Under MF, the file could be in the unemptied trash, but there's no reliable way to tell. > - "For reasons yet unknown": Until those reasons DO become known, there > is no reason for checking for MultiFinder. I can't see a > developer saying "Gee, let's check for MultiFinder. I don't > know why, but it might come in handy in the future." > Just looking at the responses here shows that a number of programmers have already implemented ways to effect this. Maybe they've just written this code for the fun of it, but I know I only write code when I have a need for it. And there are some *excellent* programmers on this net. Besides, does DTS feel that confident that any particular application *won't* have a need? And if a legitimate need does crop up, will the developer get a stone wall at DTS? [comments about misusing documentation deleted to make inews happy] >As a major computer company, Apple has to be responsible about the kinds of >information it gives out. We cannot in good conscience give out information to >developers that they can use to hang themselves. This is Tech Support's >current stance. Do you disagree with it? Do you think that DTS should supply >the rope? If we did, do you think that the customers who constantly have to put >up with broken software could ever forgive us? > Believe it or not, I do appreciate your concerns. But rather than giving up ropes that we can use to hang ourselves, we'd really love to see some ladders to save ourselves with: Apple-approved methods of solving problems that won't break in the future. (I know, I'm asking for a lot! But you guys invented that great computer and now we're all spoiled!) Owen Hartnett Brown University Computer Science omh@cs.brown.edu.CSNET
dudek@ai.toronto.edu (Gregory Dudek) (04/10/89)
In article <3637@brunix.UUCP> omh@zaphod.UUCP (Owen M. Hartnett) writes: > >Why does there have to be a reason? Why not just put up a flag in Sysenvirons? >Apple DTS always seems to have the attitude that it knows best what >developers should know about (or rather, not know about). There may be >developers out there with legitimate need to know - to fix bugs, to implement >a novel feature, or for reasons yet unknown. > >If the information is available, and properly documented that there >should be no reasons for using it (that we are currently aware of), then >the programmer will know he has to take the responsibility for using it. > >True, some developers will misuse it, but then it's their problem. It's not true that it's merely "their problem" is some (commercial) developers write bad software. For any machine, it success or failure is, to a large extent, determined by the commercial software that exists for it. This is particularly true for the Mac. As we all know, the consistency of the 3rd party software has being a major factor in its success. If apple expects to make all or many of MF's features standard aspects of the OS itself, it would be just asking for trouble by encouraging people to build MF-dependent applications. If you are simply asking for short-term solutions that will cease to work very soon, then just test for the temporary memory allocation calls or something like that. Gregory Dudek -- Dept. of Computer Science (vision group) University of Toronto Nice mailers: dudek@ai.utoronto.ca UUCP: {uunet,decvax,linus,pyramid, dalcs,watmath,garfield,ubc-vision,calgary}!utai!dudek ARPA: user%ai.toronto.edu@relay.cs.net
sbb@esquire.UUCP (Stephen B. Baumgarten) (04/11/89)
In article <28638@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: > - "To implement a novel feature": What kind of features? I would like > to know about them. So far, most features that developers want > to implement revolve around questions like "Are there icons > on the desktop?", or "How do I safely sublaunch?", or "Am I > able to unmount an MFS disk", NOT "Is MultiFinder active?" Here's a useful feature not currently supported by the System: it's nice to be able to shrink down or partially hide your windows when you're not frontmost. Versaterm is a good example of a program that does this. It lets the user decide whether or not to shrink its main window, and if so, what size it should be and where on the screen it should be located. In some ways, this is even better than having the application zoom down to an icon; since the window is still visible, you can always watch what's going on, even when the application is in the background. Of course, if you have a 19" monitor this isn't so much of a problem, but most Mac users don't and must suffer with overly cluttered 9" screens. I understand what you guys in DTS are saying, but it seems to me that the world is full of budding Microsoft's (i.e., people and companies who do what they want, regardless of the "official" line), and if you don't provide a legal way to do something, saying "don't do this" won't prevent it from being done. I think you have to look at the end result, which currently is that people are doing all sorts of terrible (by DTS standards) things to check for the existence of Multifinder. Give them a "legal" way to do it and you have at least a small chance that things won't all break with the next System release. -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." cmcl2!esquire!sbb | esquire!sbb@cmcl2.nyu.edu | - David Letterman
dee@XAIT.Xerox.COM (Donald Eastlake) (04/11/89)
In article <28638@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >In article <3637@brunix.UUCP> omh@zaphod.UUCP (Owen M. Hartnett) writes: >>Why does there have to be a reason? Why not just put up a flag in Sysenvirons? >>Apple DTS always seems to have the attitude that it knows best what >>developers should know about (or rather, not know about). >From one point of view, DTS *DOES* know best what developers should know >about. We know what is coming down in the future. We know what changes are >being made to the System Software. Based on this knowledge, we try our best to >prevent developers from burning themselves. We try to quide them down the road >of Future Compatibility. That's our job. ... I don't have any problem with guidelines. I don't even have problems with guidelines that Apple software breaks. It is fine for DTS to want some motivating informatin before they release some info and to release it with caveats. But that is not really what is going on with MultiFinder. What we have is a deliberate attempt to make it impossible for the developer to find out if MultiFinder is running. You can find out the version number of the System File, you can find out the version number of the Finder, you can find out the version number of AppleTalk, your hardware processor, whether you have a floating point coprocessor, etc., etc., etc. Of course programs should not lightly be made dependent on such things. But with all of these myriad other version dependencies available, it is just absurd that such an attitutde of deliberate conceilment has deveoped for MultiFinder. You can easily check for Switcher and I don't notice it causing the world to fall apart. I have not done much with AUX so I don't know if there is any easy way to check for it, but there should be. SysEnvirons should return the MultiFinder version number and/or a multi-tasking field with perhaps various values for none (0), Switcher active (1), MutliFinder active (2), and maybe other values for AUX or future systems. >We've already seen the misuse of MultiFinder information happen. When System >6.0 came out, WaitNextEvent was implemented all of the time. Many applications >subsequently failed to work properly. This was despite warnings about this in >Technotes. This WAS NOT the misuse of MultiFinder information. If Apple were not wedged on this subject and had provided some approved method of checking for MultiFinder, such as a version number in SysEnvirons, 90% + of these problems would probably not have occured. >As a major computer company, Apple has to be responsible about the kinds of >information it gives out. We cannot in good conscience give out information to >developers that they can use to hang themselves. This is Tech Support's >current stance. Do you disagree with it? Do you think that DTS should supply >the rope? If we did, do you think that the customers who constantly have to put >up with broken software could ever forgive us? The above is ABSOLUTE BULLSHIT. There is already so many cubic miles of rope available in the Macintosh system to hang oneself that it does not bear talking about. Can you name any significant facility of the Mac that CANNOT be used to hang oneself??? This insane quest for perfect safety, which I can not realy believe is DTS policy, is the recipie for absolute paralysis. The Mac prospered as an open and flexible system. I guess it is reasonable, as things grow up, for the release of internals details to get a bit more closed. But the wedged conceilment of the presence of MultiFinder is way at the other end of the spectrum, totally un Mac-like, and really quite sad. -- +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
mnkonar@smallberries.SRC.Honeywell.COM (Murat N. Konar) (04/12/89)
All this stuff about being able to tell whether MF is running
or not may soon be moot. I seem to recall that eventually,
there will be no UniFinder and that MultiFinder will always
be running. Any one at DTS care to comment? (Unofficially,
of course. :) )
____________________________________________________________________
Have a day. :^|
Murat N. Konar Honeywell Systems & Research Center, Camden, MN
mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)kehr@felix.UUCP (Shirley Kehr) (04/13/89)
In article <20319@srcsip.UUCP> mnkonar@src.honeywell.com (Murat N. Konar) writes:
<All this stuff about being able to tell whether MF is running
<or not may soon be moot. I seem to recall that eventually,
<there will be no UniFinder and that MultiFinder will always
<be running. Any one at DTS care to comment? (Unofficially,
<of course. :) )
Don't assume that everyone will upgrade to System 7.0.
The MacWeek rumor column (Mac the Knife) had some sneak previews in the
11 April issue. In the last paragraph:
"One of the Knife's more reliable informants insists that to take full advantage of the new software, Macs will likely need a ROM upgrade. That would make
the newer models with SIMM-socketed ROMs and the aggressively priced
SE/30 upgrade that much more attractive."
I just wonder if we're going into a real incompatibility war. If I upgrade
to system 7 at home and they don't at work, I wonder if there are any
implications other than having to work differently.
Shirley Kehrurlichs@smurf.ira.uka.de (Matthias Urlichs) (04/14/89)
In comp.sys.mac.programmer sbb@esquire.UUCP (Stephen B. Baumgarten) writes:
<
< Here's a useful feature not currently supported by the System: it's
< nice to be able to shrink down or partially hide your windows when
< you're not frontmost.
<
< Versaterm is a good example of a program that does this. [...]
.MILD FLAME ON
Ever heard about "Suspend-Resume events" ???
.MILD FLAME OFF
< I understand what you guys in DTS are saying, but it seems to me that
< the world is full of budding Microsoft's (i.e., people and companies
< who do what they want, regardless of the "official" line), and if you
< don't provide a legal way to do something, saying "don't do this"
< won't prevent it from being done. I think you have to look at the end
< result, which currently is that people are doing all sorts of terrible
< (by DTS standards) things to check for the existence of Multifinder.
< Give them a "legal" way to do it and you have at least a small chance
< that things won't all break with the next System release.
<
Well, but what if the next System release doesn't distinguish at all whether
MF is running or not?
The fact(s) that the Notification Manager will completely stop the foreground
application, or that I only have to copy a few more PD programs onto my
hard disk to get the most spectacular crash (if not running under Desktop
Manager), are more pressing problems than putting in a feature no one
has any legitimate use for.
The above is strictly my personal opinion!
BTW, yes I know about the problem with _Launch, but that will be adressed
shortly (or so I hope). And yes, I know that you want to leave space for
the Finder's icons when zooming out and if MF is running, but having a
check box in your preferences is the better way to do it. So there.
--
Matthias Urlichs -- Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- FRG
urlichs@smurf.ira.uka.de -- ++49+721-621127@PTTstores@unix.SRI.COM (Matt Mora) (04/28/89)
In article <20319@srcsip.UUCP> mnkonar@src.honeywell.com (Murat N. Konar) writes: > >All this stuff about being able to tell whether MF is running >or not may soon be moot. I seem to recall that eventually, ^^^^ Are you sure that its moot and not moof :-) -- ___________________________________________________________ Matthew Mora SRI International stores@SRI.COM ___________________________________________________________