weiss@watson.seas.ucla.edu (Michael Weiss) (05/12/91)
Now that System 7 is out, (well, day after tomorrow, but who's counting?) I think it's about time that we start looking very carefully at our INIT collections. See, while many INITs are true System extensions, some are more like tiny programs of their own. It seems as if these could be turned into standalone programs that respond to AppleEvents. I'm thinking of the INITs like: PopChar Pyro/After Dark Calendar Reminder INITs Those that will have to remain as extensions are ones that do fancy resource replacements like: AltWDEF Scroll2 Personality ClickChange ATM Now, I don't know enough about AppleEvents to know which category virus protection programs would fit under, but the first choice should always from now on be to make them individual programs. Make them automatically start up, and they should be much less prone to stepping on each others' toes (as long as they obey the proper AppleEvent protocol). What say you? -- \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | / - Michael Weiss weiss@watson.seas.ucla.edu | School of Engineering and - - izzydp5@oac.ucla.edu | Applied Science, UCLA - / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | \
george@swbatl.sbc.com (George Nincehelser 5-6544) (05/12/91)
In article <2729@lee.SEAS.UCLA.EDU> weiss@watson.seas.ucla.edu (Michael Weiss) writes: >Now that System 7 is out, (well, day after tomorrow, but who's counting?) >I think it's about time that we start looking very carefully at our INIT >collections. See, while many INITs are true System extensions, some are >more like tiny programs of their own. It seems as if these could be turned >into standalone programs that respond to AppleEvents. I'm thinking of the ... >What say you? I like things the way they are for the most part. I would hate to have all those little programs running around...I prefer that they hide in the system as I generally consider them to be system level functions. For example, several people seem to be advocates for screen-blanking apps instead of system extensions. Here are the problems I have with that: 1) Installation: Startup apps take more user effort to install than extensions. (i.e. You have to know about the startup sub-folder in the system folder) 2) Control: It makes sense to have a screen-blanker control in the control panel. An app could have some trouble doing this...it could be done, I'm sure, but I bet it would complicate installation. 3) Other Naughty Apps: What happens when those ill-programmed apps that are still around refuse to give time to background processes? If we had a pre-emptive OS, I'd feel differently. 4) Why?: I feel the extension conflict issue is often blown out of proportion. I myself have run into very few conflicts, and I usually run between 10 and 20 at a time. I'm sure there are are several other points that can be brought up, too. I understand why apps could be nice, but I (usually a user) like things just the way they are. Why start botching things up just because some programmer types think their way is much better? Would it really benefit the average user? -- / George David Nincehelser \ george@swbatl.sbc.com \ / / Southwestern Bell Telephone \ Phone: (314) 235-6544 \ / / / Advanced Technology Laboratory \ Fax: (314) 235-5797 \ / / / /\ 1010 Pine, St. Louis, MO 63101 \ de asini umbra disceptare \
weiss@watson.seas.ucla.edu (Michael Weiss) (05/12/91)
In article <1991May12.032859.8612@swbatl.sbc.com> george@swbatl.sbc.com (George Nincehelser 5-6544) writes: >I like things the way they are for the most part. I would hate to have all >those little programs running around...I prefer that they hide in the system >as I generally consider them to be system level functions. SuperClock would be a system level function, I agree, but Bad Disk? That's really a program all to itself that would call upon the FinderEvent of a failed disk operation (there IS one of those, isn't there???). >For example, several people seem to be advocates for screen-blanking apps >instead of system extensions. Here are the problems I have with that: > >1) Installation: Startup apps take more user effort to install than > extensions. (i.e. You have to know about the startup > sub-folder in the system folder) And with System 6, you had to know to put the INITs in the System Folder. In any case, you only need to drag it into the folder and restart. One interesting thought, though, is that we will need a startup application picker, like INITPicker (maybe INITPicker 3.1 can add this feature), so as to be able to turn the auto startup of these programs on and off at will. >2) Control: It makes sense to have a screen-blanker control in the control > panel. An app could have some trouble doing this...it could be > done, I'm sure, but I bet it would complicate installation. Ahh, but there IS no control panel per se anymore. It's an...APPLICATION! OTOH, if it were its own self-contained program, it would have its own pulldown menus, and so would actually be EASIER to modify. >3) Other Naughty Apps: What happens when those ill-programmed apps that are > still around refuse to give time to background processes? If we > had a pre-emptive OS, I'd feel differently. I think we're gonna see those programs disappear VERY soon, since a big part of the IAC in System 7 is gonna need "sharing" programs. >4) Why?: I feel the extension conflict issue is often blown out of proportion. > I myself have run into very few conflicts, and I usually run between > 10 and 20 at a time. Why? I've got two reasons. First, while the extension conflicts are not all THAT common, I've run across several (I have tried nearly every PD/Shareware INIT in existance), and this would cut down severely the number of such conflicts. In my eye, even ONE is too many, and there should be no reason for ANY application conflicts, as they won't step on each other's toes. My second reason is that it makes it much easier to have the feature only when you want it. Say, for example, that the only place you ever use QuicKeys is in MSWord (bad example, but it's 1am...what do you expect?). Before going into MSWord, you could start up QuicKeys, and then after leaving MSWord (to free up memory), you quit QuicKeys. You couldn't do something like that in System 6 without restarting the machine. As another example, if you know that one of these little programs actually DOES conflict with an application, you could quickly and easily turn it off before starting the program, and then restarting it after leaving the offended application. Furthermore, an extension could be written to automatically startup one of these little programs when you start a particular application, and quit it when you quit the application. Or, the reverse could be done. I see much more flexibility, if nothing else. >I understand why apps could be nice, but I (usually a user) like things just >the way they are. Why start botching things up just because some programmer >types think their way is much better? Would it really benefit the average >user? Well, you see the above scenarios. What do YOU think? WOULD it benefit the average user? Maybe not, but then again most users are not INIT fanatics, either. I doubt that it would HURT the average user. -- \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | / - Michael Weiss weiss@watson.seas.ucla.edu | School of Engineering and - - izzydp5@oac.ucla.edu | Applied Science, UCLA - / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | \
george@swbatl.sbc.com (George Nincehelser 5-6544) (05/13/91)
In article <2733@lee.SEAS.UCLA.EDU> weiss@watson.seas.ucla.edu (Michael Weiss) writes: >SuperClock would be a system level function, I agree, but Bad Disk? That's >really a program all to itself that would call upon the FinderEvent of a >failed disk operation (there IS one of those, isn't there???). Bad Disk as an application? Seems strange to me. I wouldn't want to run it myself. I'd prefer it remain hidden in the system. >And with System 6, you had to know to put the INITs in the System Folder. >In any case, you only need to drag it into the folder and restart. One Yes, but with startup items in 7 you have to put the item in the startup folder of the system folder...an added step when compared to a system extension or control panel item. >Ahh, but there IS no control panel per se anymore. It's an...APPLICATION! >OTOH, if it were its own self-contained program, it would have its own >pulldown menus, and so would actually be EASIER to modify. In 7 the control panel is actually a folder, not an application. The control panel has come to be the place you go to change items concerning your system environment...that makes a lot of sense. I see no real advantage to putting it elsewhere. Sure, you could use aliases, but why complicate the installation? >I think we're gonna see those programs disappear VERY soon, since a big part >of the IAC in System 7 is gonna need "sharing" programs. Those old apps aren't going to go away on May 13...they'll be hanging around just waiting to mess up your world. It only takes one bad app to spoil your whole plan. >Why? I've got two reasons. First, while the extension conflicts are not all >THAT common, I've run across several (I have tried nearly every PD/Shareware >INIT in existance), and this would cut down severely the number of such >conflicts. In my eye, even ONE is too many, and there should be no reason >for ANY application conflicts, as they won't step on each other's toes. My >second reason is that it makes it much easier to have the feature only when >you want it. Say, for example, that the only place you ever use QuicKeys is >in MSWord (bad example, but it's 1am...what do you expect?). Before going >into MSWord, you could start up QuicKeys, and then after leaving MSWord (to >free up memory), you quit QuicKeys. You couldn't do something like that in >System 6 without restarting the machine. As another example, if you know >that one of these little programs actually DOES conflict with an application, >you could quickly and easily turn it off before starting the program, and then >restarting it after leaving the offended application. Furthermore, an >extension could be written to automatically startup one of these little >programs when you start a particular application, and quit it when you quit >the application. Or, the reverse could be done. I see much more flexibility, >if nothing else. Hmmm...you're right....you gave a bad example. What makes you think applications won't step on each other's toes? Remember, we don't have protected memory. Yes, there would be more flexibility with your scheme, but is it really worth the trade-off in extra effort for installation and maintenance for the majority? Things work pretty well right now, so why start botching things up for everybody? You could do this on your own, of course. I wouldn't expect a great many people wanting to do things that way unless they really needed to. >Well, you see the above scenarios. What do YOU think? WOULD it benefit the >average user? Maybe not, but then again most users are not INIT fanatics, No, I don't think it would benefit the average user. Yes, most average users aren't INIT fanatics, but most use INITS with few problems today...why start messing with something that works? In short, things are working rather well the way they are. If it ain't broke, don't fix it. You're more than welcome to pursue such a scheme on your system, but don't be supprised if others don't see the benefit in what you are doing. -- / George David Nincehelser \ george@swbatl.sbc.com \ / / Southwestern Bell Telephone \ Phone: (314) 235-6544 \ / / / Advanced Technology Laboratory \ Fax: (314) 235-5797 \ / / / /\ 1010 Pine, St. Louis, MO 63101 \ de asini umbra disceptare \
ewright@convex.com (Edward V. Wright) (05/14/91)
In <1991May12.193300.11349@swbatl.sbc.com> george@swbatl.sbc.com (George Nincehelser 5-6544) writes: >Hmmm...you're right....you gave a bad example. What makes you think >applications won't step on each other's toes? Remember, we don't have >protected memory. Since memory protection is discussed so frequently in the comp.sys.mac news groups, I thought this would be of interest. Inside Macintosh, Vol VI states on page 3-6 that "Some Macintosh computers use memory protection and may prevent code from writing to addresses within code segments." I can't find any further details about this in IM VI, so make of it what you will.
Jim.Spencer@p510.f22.n282.z1.fidonet.org (Jim Spencer) (05/18/91)
Michael Weiss writes in a message to All >I understand why apps could be nice, but I (usually a user) like things just >the way they are. Why start botching things up just because some programmer >types think their way is much better? Would it really benefit the average >user? MW> Well, you see the above scenarios. What do YOU think? WOULD MW> it benefit the average user? Maybe not, but then again most users MW> are not INIT fanatics, either. I doubt that it would HURT the MW> average user. And maybe just as importantly, if you like things the way they are, then simply continue to use System 6.0.x. What could be simpler? * Origin: White Mailer Test Point (1.0d6) (1:282/22.510)
george@swbatl.sbc.com (George Nincehelser 5-6544) (05/21/91)
In article <674629203.9@macgate.fidonet> Jim.Spencer@p510.f22.n282.z1.fidonet.org (Jim Spencer) writes: > >And maybe just as importantly, if you like things the way they are, then >simply continue to use System 6.0.x. What could be simpler? > > * Origin: White Mailer Test Point (1.0d6) (1:282/22.510) Just because there are some powerful new capabilities in 7 doesn't mean they should be forced on all users to fit some programmer's ideal vision of the world. System 7 brings many new capabilities, but usability shouldn't be sacrificed for some programmer's "power" trip. Telling people to stick with 6 if they don't wan't what you consider "powerful" isn't the answer to anything. Programmers need to make responsible use of 7's features. By responsible I mean not making things a pain in the neck for the user. BTW, Jim, your "White Mailer Test Point" needs some work. The attributions were wrong and your aren't including line-feeds (the lack of them makes it difficult for some of us to read). -- / George David Nincehelser \ george@swbatl.sbc.com \ / / Southwestern Bell Telephone \ Phone: (314) 235-6544 \ / / / Advanced Technology Laboratory \ Fax: (314) 235-5797 \ / / / /\ 1010 Pine, St. Louis, MO 63101 \ de asini umbra disceptare \