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