Path: utzoo!mnetor!spectrix!John_M From: John_M@spectrix.UUCP (John Macdonald) Newsgroups: comp.sys.mac Subject: Init Manager, please Message-ID: <338@spectrix.UUCP> Date: 14 Dec 87 01:59:12 GMT Reply-To: jmm@spectrix.UUCP (John Macdonald) Organization: Spectrix Microsystems Inc., Toronto, Ontario, Canada Lines: 82 Summary: an init manager could order and disable inits The following request may be for something that is already being done at Apple. I hope it is. I would like to see an Init Manager. It should be able to run a dialogue that I will call the Init Chooser. The Init Chooser would present a list of available inits on the screen. There would be a check box beside each init to indicate whether the init is currently selected. Clicking the box would reverse the state. The position in the list would specify the order that the inits will be run. Dragging an init would allow you to change the order. You could open inits from places other than the system folder. This interface would be useful in two places (at least). There would be a cdev using the Init Chooser that would allow you to choose and order the set of INIT's that are normally run when you start up. Current usage is to run every init in the system folder in alphabetical order, which requires renaming and hiding in folders to control their usage. In addition, a Init Chooser could be used as a single method of dynamically modifying the default init list. The current usage is to have some combination of (shift, caps lock, option, and command) alter inits. Some inits ignore all such combinations. Some inits put up a yes/no dialogue box if their special keyset is pressed. Some inits cancel themselves if their special keyset is pressed. There is no co-ordination of which ones use shift, which use command-shift, which use caps lock, etc. You have to look up in the manual for each init you have and hope that there aren't too many that overlap too much. Some inits do not affect the screen at all when they run - you can't tell when one finishes and the next starts. If two inits both disable themselves if the shift key is pressed, but you only want to disable one of them, you have to be good at guessing when to hold the shift key down. What I would like is for one key combination to cause the Init Chooser to be run before ANY init is run. It would be used to specify the entire set of inits (and their order) for this startup. No guessing, no conflict between which inits you want to disable. Simple inits (10 lines of code) could be written without worrying about techniques for disabling, etc. that would be far more work to write than the actual init itself. (I would expect that this is a fairly straight-forward addition - after all, currently there is a piece of code that finds all inits, sorts them into alphabetical order, and then runs each one in turn. This same code could instead check for the shift key and then either use the default set or invoke the Init Chooser to be the temporary set.) In addition (and now we are getting to an area where I am not so clear on what is needed), there should be an analysis done on why some inits must be run before other inits. Whenever a specific cause is found, there could be some control flags added to inits to show how it uses objects that are causes of potential conflicts. (I SAID I was vague on what is needed.) I would guess that in most cases, one init needs something that is provided, or modified, by another init. It might be useful to have a control fields in an init that could specify reuirements of the form: this init must be run before init FOOBAR this init must be run after init FOOBAR this init should not be run unless init FOOBAR is also run this init generates system resource FOOBAR this init modifies the appearance of system resource FOOBAR this init uses system resource FOOBAR While inits could check for some of these things themselves, they can't check for inits that run later that modify resources underneath them. (e.g. an init that checked what type of screen controller was present to determine how much memory to allocate for graphics operations would have problems if a later init turned on the 32-bit-plane 4096 x 4096 x 4096 3-D I-Want-It display that was sitting uninitialized in Nubus slot 7 :-) It is useful to provide this information. The Init Chooser could do things like check all required predecessors when you check an init. It could maintain required ordering as you move inits. (e.g. you move an init to the head of the list, and the inits which must be run before it are then moved ahead of it.) -- --------- .signature eater food --------- John Macdonald UUCP: {mnetor,utzoo} !spectrix!jmm internet:Sorry. We're in range, but we're in no domain. Disc-claimer: (noun) any hack's source directory