15,24c15
< how it's invoked from the OS.  I think the best way to do this is to define
< what files have to go where, and then say that the installation process can use
< whateve helpful installation aids may exist, and we assume that the installer
< has any privileges necessary for installation in system-protected places.</em>
< </p><p>
< <em>Don't forget to discuss how the server is installed along with the admin
< program, and that system-level administrator priveleges may be necessary to
< install such a server.  What's described here is the behavior the server must
< execute -- it's up to the implementors to figure out if such behavior requires
< system administrator privileges, and if so deal with it accordingly.</em>
---
> how it's invoked from the OS.</em>
26c17
< <a name="Installing the Calendar Tool">
---
> <a name="Regular User Installation">
28c19
< 2.15.1.  Installing the Calendar Tool
---
> 2.15.1.  Regular User Installation
32,134d22
< <em>Talk (again, as necessary) about the Calendar Tool user directory, the
< default name and location of which are "</em><tt>.CalendarTool</tt><em>",
< stored in the user's home directory.  Say home how directory is a platform-
< specific idea, and if there is no such thing on the installed platform, then
< the user will be asked to specify the name and location of the CalendarTool
< working directory the very first time the Calendar Tool is invoked.</em>
< </p><p>
< Bottom line -- when the app is invoked, it must know where to look for the
< user's CalendarTool directory.  Upon initial invocation, if such a directory is
< not found, it will ask the user to create one.  The generic default place for
< this is ~/.CalendarTool, where "~" designates the platform-dependent "home"
< directory for the user.  This location can be explicitly specified in an
< adminstirator-created distribution.  If at initial invocation the app cannot
< determine such a location for the invoking user, or if such a location exists
< but is not read/write accessible to the user, then it prompts the user for the
< directory path of where to put the CalendarTool directory (with an appropriate
< msg indicating why it's asking (i.e., cannot figure out where "home" is or the
< distribution-supplied (or expected) home does not exists or is not read/write
< accessible)).
< </p><p>
< Since the user can subsequently change the location of her CalendarTool
< directory, the app has to be built in such a way to make this possible.  The
< implementors can accomplish in any of the following ways, or some other way of
< their choosing:
< <ul>
< <li>
< put a file containing the location of the user's CalendarTool directory at some
< well-known, platform-depdendent, e.g., ~/Library/Preferences/caltool.init
< <li>
< allow the application itself to be modified to contain the changed location of
< the CalendarTool directory, as long as such a location is user-specific
< </ul><font color=black>
< The bottom line is that the way in which the change of CalTool dir is
< accomplished must remain transparent to all users in that any user can invoke
< the tool in the normal way (clicking on icon, typing its name) and have the
< directory location change made by <em>that user</em> be in effect.  That is,
< suppose users A and B are sharing the same copy of the Calendar Tool
< application.  If user <strong>A</strong> changes the location of her
< CalendarTool directory to "X" and user <strong>B</strong> changes the caltool
< directory location to "Y", the single copy of the shared copy of the
< CalendarTool will use "X" or "Y" as the location of the CalendarTool directory,
< when invoked by user "A" or "B", respectively.
< </p><p>
< <em>Also, given that the `<tt>Admin->Distribution</em>' command is gone now,
< explain how an installer, admin or otherwise, can run the regular cal tool,
< create calendars and/or a settings files, and include those with an
< installation.  These requirements don't say anything about fancy, easy-to-use
< install tools, but if they're used, they can do shit like copy installation-
< provided calendars or Settings files into the user's caltool dir.  What we can
< do in these requirements is explain the manual installation of extra shit, by
< desribinng the OS-level file commands the the stupid motherfucking user can do
< to copy the installer-supplied files to his caltool dir.</tt>
< </p><p>
< <em>In conjunction with the precedinig paragraph, we may want to mention that
< all of the place in the preceding scenarios where it says "by default, there
< are no ..." is overridden with the installer provides a calenar or Settings
< file that does define some pre-defined stuff.  This is pretty much a duh, but
< it's probably worth mentioning, just to keep the motherfucking implementors
< aware and on the hook.</em>
< </p><p>
< <em>Probably old crap:</em> When installed, the app is additionally configured
< with the following info:
< <ul>
< <li>
< the user's calendar tool directory
< </ul><font color=black>
< </p><p>
< The application must be compiled for installation following appropriate
< platform-dependent conventions as necessary.
< </p><p>
< To create an installable version of the program, these things are needed:
< <ul>
< <li>
< a compiled version of the application that is configurable to allow the
< location of the settings directory to be installed within the application, or
< have the location of a file that contains the location settings directory be in
< a well-known and accessible place.
< <li>
< write access to the directory where the app will be installed
< </ul><font color=black>
< 
< 
< 
< </p><p>
< OK, here are the user-level steps to install the cal tool raw, with no
< administrator-supplied distribution having been provided:
< <ol type=a>
< <li>
< copy the Calendar Tool application program to the desired directory
< <li>
< invoke it
< </ol>
< This raw installation assumes that the Calendar Tool user directory, i.e.,
< where Settings, etc go, is
< 
< 
< 
< </p><p>
< <em>Deal with the conflict resolution issues if one or more of items in a
< custom distribution conflicting with extant items the user already has defined;
< I think the best way to deal with that is to give the user an itemized list of
< precisely what the conflicts are, and let her choose what to do about it.</em>
< </p><p>
183c71
< 2.15.1.1.  Implementor or Adminstrator Configuration of the Calendar Tool
---
> 2.15.2.  Implementor or Adminstrator Configuration of the Calendar Tool
194c82
< <a name="Platform-Specific File Locations">
---
> <a name="Installation of the Calendar Tool on a Regular User's Local Computer">
196c84
< 2.15.1.2.  Platform-Specific File Locations
---
> 2.15.3.  Installation of the Calendar Tool on a Regular User's Local Computer
200,213c88
< <em>Talk about conventions that may exist for standard placement of application
< data files, and how platform-specific installation documentation must be
< produced for any delivered product.  Whatever platform-specific conventions may
< exist, the following minimum file requirements must be met for all installed
< platforms: ... (things like the names of files, and the general types of dirs
< they must go in, e.g. "preferences" dirs).</em>
< 
< <a name="Invoking the Calendar Tool">
< <h4>
< 2.15.2.  Invoking the Calendar Tool
< </h4>
< </a>
< </p><p>
< <em>Points to include:</em>
---
> When installed, the app is additionally configured with the following info:
216,318c91
< Cover all uncovered points about the order in which things get done at start-
< up, particularly wrt command-line (or equiv) file args.  Do this in conjunction
< with what's already done in
< <a href="file.html#Loading and Saving Settings">
< Section 2.8.5,
< </a>
< where there's a discussion of the what happens with `<tt>Settings</tt>' at
< start-up, and also in conjuntion with
< <a href="options.html#Viewing Miscellaneous Options">
< Section 2.7.4.3,
< </a>
< where there's a discussion of the "Effects of initial view settings when tool
< is invoked with file arguments" (this is the title of a table there).
< </p><p>
< Here's a somewhat-outdated list of points on the order in which files are
< handed at start-up, the outdatedness being in the mention of the no-longer-
< existent <tt>Config</tt> and <tt>Init</tt> files:
< <ol type=a>
< <li>
< Any command-line files that do not exist are created as new Calendar Tool
< files, with the contents of the <tt>Options</tt> file copied into them.
< <li>
< Any command-line files that exist as valid Calendar Tool files are opened, and
< their default view windows are opened at window-manager-controlled positions.
< <li>
< Any command-line files that are not valid Calendar Tool files or not otherwise
< readable are ignored, with a warning dialog to this effect displayed on the
< screen.
< <li>
< If there's a <tt>Configuration</tt> file and it requires opening any of the
< command-line files, these files a considered already opened.  Even if multi-
< window mode is on in a file's options, there is at most one default view window
< opened for each file.  If the positions of any of the command-line file default
< view windows are specified in the <tt>Configuration</tt> file, the windows are
< placed at those positions.  The system then proceeds to process the rest of the
< configuration file.  In this way, the start-up configuration is the union of
< the command-line files and the <tt>Configuration</tt> file.
< <li>
< If there's an <tt>Initialization</tt> file, it is executed last.  This means
< that the <tt>Initialization</tt> file can override any of the configuration
< performed as a result of command-line file specification and
< <tt>Configuration</tt> file processing.  E.g., the <tt>initialization</tt> file
< could contain the command <tt>CloseAll</tt> to undo all of the command-line and
< <tt>Configuration</tt> file processing.  Since there are no window placement
< commands in the Calendar Tool command language, there's no way to duplicate the
< window-placement functionality of <tt>Configuration</tt> file.
< </ol>
< Treat this list like fodder to be groomed as necessary, then off it to the
< rationale, as usual.  Also, most likely bill this section as a summary, given
< that major points have been covered already in earlier sections.  (There is in
< fact a new text section on this summary/redundancy idea -- pretty cool,
< actually.)
< <li>
< OK, one more motherfucking time.  We really <em>do</em> need a global
< `<tt>Initial View for New Calendars</tt>' in the global options dialog, because
< there is no ``intial view for new calendars ... saved in the calenar-specific
< component of the `<tt>Settings</tt>' file'' as it's phrase in the next
< (bullshit) bullet.  What I was thinking was that the cal-specific setting for
< `<tt>Iniital View When Open</tt>' could be used for new calendars, but that
< doesn't work, not least because we describe explicitly in the options section
< that the initial-view-when-open setting happens for a (presumably) extant
< calendar when it's opened, not for a calenar that is non-existent before the
< New operation is complete.  Get it, motherfucker??
< <li>
< Bulshit Bullet: Hmm, lemmie see if I can get this right, and if so the next two
< bullets are both bullshit.  We don't need to include `<tt>Initial View for New
< Calendars</tt>' in the (now new) global options dialog, because the intial view
< for new calendars is whatever is saved in the calenar-specific component of the
< `<tt>Settings</tt>' file.  I think this is right.
< <li>
< Non-Bulshit Bullet: The immediately following bullet is bullshit, because the
< now global setting for `<tt>Initial View for New Calendars</tt>' works
< perfectly well for the new calendar created with when the cal tool is invoked
< with no args.  I.e., the new calendar created at argless invocation is exactly
< the same kind of calendar as that created by `<tt>File->New</tt>', and thereby
< subject to exactly the same rules for using `<tt>Settings</tt>'.
< <li>
< Bullshit Bullet: When invoked with no file arg(s), the initial view is the
< month view for a new calendar, period.  There are no options to change the view
< level in the no-arg case.  I think it's fine to say that having an option for
< the view level really only makes useful sense when the user invokes with a
< specific calendar, for which there is a settable initial view option.
< <li>
< Init file only invoked one time at start-up, not at each file open
< <li>
< Prev rule means no init file happens when other user's calendars are open.
< <li>
< Allow (?provide?) both command line and GUI invocation; with command line, args
< specify files and options.  With GUI invocation, calendar files are the one or
< more selected for invocation.  In either case, all open files are opened by the
< tool.
< <li>
< The initial default calendar is an empty calendar named "unnamed"; this is
< <em>overridden</em> by icon-based file invocation, command-line arg, or option
< setting.
< <li>
< If no <tt>Settings</tt> file in caltool dir, ask user if she wants to create
< one.  Cal-specific values in the settings file are described in File section
< for creating a new cal when no <tt>Settings</tt> file exists.
< <li>
< Deal with invocation after tool is already running, including double clicking
< on an icon while tool is running.  This seems to be quite environment-specific,
< and we may want to say as much and keep things generic in these requirements.
---
> the user's calendar tool directory
321,327c94
< <a name="Installing the Calendar Tool Administration Program">
< <h4>
< 2.15.3.  Installing the Calendar Tool Administration Program
< </h4>
< </a>
< 
< <a name="Invoking the Calendar Tool Administration Program">
---
> <a name="Installation of the Calendar Tool Administration Program on a Central Host">
329c96,97
< 2.15.4.  Invoking the Calendar Tool Administration Program
---
> 2.15.4.  Installation of the Calendar Tool Administration Program on a Central
> Host
333c101
< <a name="Location of Calendar Tool Files (Probably Old Crap)">
---
> <a name="Location of Calendar Tool Files">
335c103
< 2.15.5.  Location of Calendar Tool Files (Probably Old Crap)
---
> 2.15.5.  Location of Calendar Tool Files
358c126
< <a name="Platform Dependencies">
---
> <a name="Invoking the Calendar Once Installed">
360c128
< 2.15.6.  Platform Dependencies
---
> 2.15.6.  Invoking the Calendar Once Installed
364,369c132,133
< OK, I think we probably need to talk about the potentially user-visible
< platform dependenncies here, not just, or maybe not at all, in the development
< overview section.  See the NOTE at the top of that section.
< </p><p>
< Among other things, there are the following issues:
< <ol type=a>
---
> <em>Points to include:</em>
> <ul>
371c135
< command-line args versus clicking on icons
---
> Init file only invoked one time at start-up, not at each file open
373,374c137
< environment vars, particularly ones that define default paths, as in, even more
< particularly, the path to the start-up <tt>Setttings</tt> file
---
> Prev rule means no init file happens when other user's calendars are open.
376,404c139,146
< the ways files are identified in different environments, including the whole
< Windoze registry bullshit (if it still exists in XP or whatever the latest POS
< is)
< </ol>
< While details are outdated, here's some fodder on this topic to be
< groomed/nuked as appropriate:
< <blockquote>
< </p><p>
< Note that the value of the local files directory path, user settable via the
< `<tt>File->Local Files</tt>' command, is stored in the application program
< itself, not in a file.  There's chicken-and-egg thing going on here [which I'll
< explain a bit more in due course].  OK, fuck this shit, it's time to explain it
< now.  I think the way it has to work is for at installation time, and never
< thereafter, the app is configured to look in <em>a specific place</em> for the
< local-files file, which in turn has enough information to get things boot
< strapped.  It seems most akin to THE ~/.mh_profile, or ~/.emacs, or
< ~/Library/Preferences/com.apple.mail.plist files.  Now in UNIX, we can do
< things like (1) have a list of places that an app will look, in addition to
< just the "~" place; (2) use a command-line switch to override the default.  I
< think we should skip the command-line thing, and just say that at installation
< time, the app is configured with the location of the local-files file, which
< must stay there forever (for as long as a particular installation is to work),
< which bootstraps into where the other local files are.  Hence, I think the only
< thing the the installation-time-established "known" file needs to have in it is
< whatever info is settable by the <tt>Local Files</tt> command, i.e., either
< just a directory path or a table that defines one-by-one where each necessary
< file is; I'm leaning towards the former right about now, not the least reason
< for such leaning being simplicity and cleanliness.
< </blockquote>
---
> Allow (?provide?) both command line and GUI invocation; with command line, args
> specify files and options.  With GUI invocation, calendar files are the one or
> more selected for invocation.  In either case, all open files are opened by the
> tool.
> <li>
> The initial default calendar is an empty calendar named "unnamed"; this is
> overridded by a command-line arg or icon-based file invocation.
> </ul><font color=black>