13,1085d12
< <p>
< Here's an idea for organizing this section -- have subsections for each 2.X-
< level section, as well as others that may have gone away and don't fit in the
< current 2.X structuring.  As far as the text goes, maybe we can leave it pretty
< raw and informal, treating it like a (b)log of thoughts along the way.  I think
< this might work, and lead to getting the fucker done before death.
< 
< <a name="For Next Check-In">
< <h3>
< 6.1.  For Next Check-In
< </h3>
< </a>
< <ul>
< <li>
< The following point got axed (hopefully permanently, when we decided not to
< have ID be part of a calendar anywhere, but to get the ID when necessary from
< the connection tab, when the current calendar is connected to a host:
< <blockquote>
< When user X opens a cal file copied from user Y, including one created by an
< admin in a distribution, user X becomes the user of record for that calendar at
< the point of opening, i.e., the opening user's ID is made part of the opened
< calendar and will be saved as such when and if the user does a subsequent
< File->Save.
< </blockquote>
< <li>
< <tt>SaveAs</tt> and <tt>Load</tt> are gone from all aux data dialogs they're
< currently in.
< <li>
< There's a <tt>Save</tt> (but no load) in the host connection table dialog; the
< rationale for this being here but not in the other aux data dialogs is that
< host connections are tool-wide as opposed to cal-specific, and hence not saved
< with the regular File->Save; the <tt>Save</tt> in the host connection dialog is
< a convenience, since it can be accomplished within the `<tt>File->Save
< Settings</tt>' dialog.
< </ul><font color=black>
< 
< <a name="Bits from and Related to File, During Push to Finish">
< <h3>
< 6.2.  Bits from and Related to File, During Push to Finish
< </h3>
< </a>
< </p><p>
< A big pilo crap follows, spewed originally in ``.sh 4 "Local Files"''.  It's
< indented to distinguish this particularly largish crap pile for the rest.
< (Indenting crap piles seems to be an evolving convention).  Each paragraph is
< also annotated with where it's been dealt with.
< <blockquote>
< </p><p>
< Say that the implementors can figure out how/where exactly to define this (the
< location of the user dir), including one or more of these ways: ... .  The
< effect must be that when the cal tool is subsequently invoked, it looks for the
< Settings file and non-path-prefixed calendar files in the specified directory.
< <em>This is pretty fucked up, but it's been dealt with in the development
< overview subsection on implementation considerations.</em>
< </p><p>
< Hmm hmm, I think having one-by-one naming for each file is probably (way)
< overkill, cfing Emacs single .emacs file; also, wait a mother-fucking minute --
< we may have a huge motherfucking chicken and egg problem with the whole local
< files thing altogether, since where the fuck does this setting get saved; i.e.,
< it would seem there needs to be at least one <em>known</em> place to look for
< things, unless we want to modify the app itself, which sounds fucked up; what I
< think we're getting at is the the local files determination needs to be made at
< installation/configuration time, not dynamically.  <em>Dealt with by having
< only one Settings file read at start up; chicken and egg problem dealt with in
< developer_overview.implementation_considerations.</em>
< </p><p>
< Hmm, maybe we want to let the user specify one-by-one where each of the
< different files goes, rather than having the idea of a specific known
< directory.   This is probably the more flexible way to do it, if it works OK.
< One fucking way or another, we need to fully figure out what known places the
< Calendar Tool needs to be aware of and what the full ramifications of knowing
< these places are.  <em>Dealt with by having one Settings file and, again, in
< implementation considerations subsection.</em>
< </p><p>
< Local Files dialog now has two items: path for local file directory and name of
< default calendar file to open when the app is launched as an app as opposed to
< from a file.  If the user specifies a value for the default start-up calendar
< and then invokes the cal tool from a file, the file from which the tool is
< invoked overrides the default start-up calendar.  <em>Dealt with in "Files Used
< by the Calendar Tool" subsection and future work item about command-line arg to
< specify start-up settings file.  The idea of a single default calendar to open
< has been extended to the "open calendars" part of the session-wide
< settings.</em>
< </p><p>
< 24jun04 NOTE: Since we've nixed the "CommunityCalendar" idea, what we can say
< about calendar files and the local files directory is that the directory so
< specified is the default place where calendars will go.  Given the current set
< up of things, all this really means is that that dir is the default path when
< calendar file chooser is initially opened.  Related to this, we need to figure
< out if the file-chooser dialogs have temporal memory, as in they come up in the
< place that they were most recently OK'd (but not Canceled) on.  I think the
< answer to this is almost certainly yes.  <em>Dealt with, as aluded to, in the
< "new setup" of things.  Temporal memory in dialogs dealt with in specific
< subsection in data entry details.
< </p><p>
< NOT to all of the following paragraph; coverage of `<tt>File->Local Files</em>'
< since it's been nuked as a command and moved to Admin options; the priv admin
< `File->Host Files</tt>' has been moved to the priv <tt>Admin</tt> menu.  So,
< what this section covers is what's in the files (a review, most likely), but
< not these two commands, since they're not on a file menu anymore.  <em>Dealt
< with as the paragraph itself explains.</em>
< </p><p>
< Need to cover `<tt>File->Local Files</tt>' command here or elsewhere, as well
< as the privileged admin `<tt>File->Host Files</tt>' command.  With
< `<tt>File->Local Files</tt>' regular users should be able to set the path to
< where the local files are.  When creating a config, admins can set the default
< value for the local files.  <em>Dealt with fine in the new scheme of things; in
< particular, admins don't do configs per se anymore, but can set location of
< user dir by creating a settings file using the regular calendar tool.</em>
< </p><p>
< There are four standard fixed-name files used by the CalendarTool:
< <ol type=a>
< <li>
< <tt>"CommunityCalendar"</tt>: [THIS IS WRONG NOW, need to decide if we want to
< keep CommunityCal around anyway as the "standard", or more likely "standard
< sample" normal calendar] the place where the central host expects to find the
< calendar that the user shares with the Calendar Tool community
< <li>
< "<tt>Options</tt>": the standard options file that is used to set the initial
< options for all new calendars
< <li>
< "<tt>Configuration</tt>": the file where the results of the `<tt>Save
< Config</tt>' command go, that says what windows are up initially and where they
< are
< <li>
< "<tt>Intialization</tt>": the command file read in by the CalendarTool whenever
< it starts up
< <li>
< "<tt>FileInfo</tt>": file containing settings established with the
< `<tt>File->Connect</tt>' and `<tt>File->Local Files</tt>' commands.
< </ol>
< <em>Dealt with by consoldating everything into cal-specific and session-wide
< settings, in cal files and settings file, resp.</em>
< </p><p>
< Given the nixing of <tt>CommunityCalendar</tt> as <em>the</em> global calendar,
< the following paragraph is WRONG.  If the <tt>CommunityCalendar</tt> file is
< deleted or corrupted, it's as if the user sets `<tt>Options.Meetings.When to
< Show Meeting Notifications</tt>' to `<tt>never</tt>', but otherwise things are
< as normal.  Note that deleting (or renaming) <tt>CommunityCalendar</tt> on the
< user's local computer <em>does not</em> delete any of the user's community
< calendar information on any central host on which the user is registered.  In
< order to do this, the user must contact the system administrator(s) on the
< host(s) from the user wants to be unsubscribed.  There need not be any
< explicitly identifiable <tt>CommunityCalendar</tt> file on the central host.
< It is up to the user to be prudent about saving backup copies of calendar
< files, including the <tt>CommunityCalendar</tt>.  There is no Calendar Tool
< command to download the contents of a <tt>CommunityCalendar</tt> file from a
< Calendar Tool central host.  <em>Dealt with as the paragraph itself explains;
< also, the matter of deleted or corrupeted files in general is dealt with in
< File subsection on this topic, as well as Error Conditions section as
< appropriate.</em>
< </p><p>
< The next NOTE was correct -- all pretty much obsolete bullshit.  Went through
< it and found a couple thigs that helped firm things up in the final version of
< the File section, so put a motherfucking fork in it.
< </p><p>
< <em>NOTE: I'm pretty sure that all of the subsubsections that follow are
< bullshit, but may have some useful info.  Check them out one last time to be
< sure.</em>
< </p><p>
< .sh 4 "Save As and Load in Editing Dialogs"
< </p><p>
< <em>9jul94 ADDITIONAL NOTE:</em> OK, I'm just about ready to fuck the
< SaveAs/Load shit in all of dialogs where they appear.  This will nicely
< simplify things, and users who give a fuck can --- OK, fuck me, we're going
< around in circles again.  If we lose the SaveAs/Load shit in the dialogs, then
< there's no particularly convenient way to get, say the options, unbundled from
< a calendar file.  One way might be to provide a "Clear all items" command, say
< in edit, that could be used to get rid of everything but the aux data, and then
< a new calendar could get another calendar's aux settings by copying the first
< calendar into the new one and then nuking  all the items in the new one.  This
< really anin't too bad, given the complication it avoids and the fact that we
< can still get done what we'd like to get done.  To whit:
< <ul>
< <li>
< ...
< </ul><font color=black>
< </p><p>
< OK, fuck me hard, one more time, way up the motherfucking ass.  Let's just
< stick with what the fuck we have, including the fucking-ass complicated new row
< of buttons in the connections table, explain it clearly and get the fuck on
< with it.
< </p><p>
< No, but now fuck me again.  Probably the bottommost line here is how useful the
< aux data file saveas/load bullshit is, and I think the answer is honestly not
< very fucking much useful.  For me, I'm likely to have a few calendars at most,
< and not be spending my motherfucking life building caltool aux data files.  So,
< I think except probably for Options, which are a big pile of do-do, we'll nix
< SaveAs/Load.  If I like the categories, lists, or filters so fucking much in
< one calendar file, then I can copy the file, do a "clear all items" and get the
< fuck on with it.
< </p><p>
< Or one more motherfucking possibility is to have a 'Save Settings' command in
< the file menu that can be used to save all of the non-scheduled-item data in
< one motherfucking Settings file (maybe even including options).  We'll also
< need a File->LoadSettings to go along with this.  This way I can save all of
< the motherfucking settings in one place and load them up if I give a fuck about
< them for some other calendar.  In this scheme, we can fuck the explicit
< <tt>Options</tt> file, having a configured distribution of the tool with the
< options settings in the tool itself, and provide a `Restore Defaults' button in
< the options dialog, instead of SaveAs and Load.  ALSO (IMPORTANT) -- nuke
< File->SaveConfig in favor of a new Options.Viewing.Misc setting that allows
< `From last time' (or something like it) for the `Initial View' option (in
< Figure 283).
< </p><p>
< <em>9jul04 NOTE:</em> (1) Itemize the dialogs in which these commands appear;
< (2) explain why only the host-connection dialog has `<tt>Save</tt>' in addition
< to `<tt>Save As</tt>', whereas all the others have only `<tt>Save As</tt>', the
< explanation being that the host-connection dialog is the only one that is
< editing non-calendar-specific data that is stored someplace other than the
< current calendar).
< </p><p>
< <em>NOTE:</em> Adjust the following fodder pulled from the options section to
< apply uniformly to all four types of aux data (which will have been clearly
< defined in the intro of this section).  What might be nice is to use this
< options-specific scenario as the concrete example for all five types of aux
< data.  See also the semi-epiphany in
< <a href="data-entry-details.html#Calendar Specificity and Modality of Dialog Windows">
< Section 2.11.32.
< </a>
< </p><p>
< The `<tt>Save As ...</tt>' button is used to save a copy of the current option
< settings in a selected file.  Saving options in different files allows the user
< to create different option configurations that can be loaded using the options
< `<tt>Load</tt>' command.  When the user presses `<tt>Save As ...</tt>', the
< system displays a dialog of the form shown in Figure 333.
< 
< <br>
< <br>
< <hr>
< <a name="Figure Options save-as dialog">
< <p align=center>
< <img src="images/options-save-as-dialog.gif">
< </p>
< </pre>
< <p align=center>
< Figure 333:  Options save-as dialog.
< </p>
< <hr>
< </a>
< <br>
< 
< The default save-as directory is the user's Calendar Tool directory, the
< default name of which is "<tt>.CalendarTool</tt>".  The four listed files are the
< standard files created when the Calendar Tool is installed, as described in
< <a href="installation.html#Location of Calendar Tool Files">
< Section .
< </a>
< <a href="file.html#Save, Save As, Save All">
< Section .
< </a>
< covers complete details of the format and use of file saving dialogs, including
< the directory browsing list and the warning issued when an extant file would be
< overwritten by the save.
< </p><p>
< To save options to a file, the user enters the filename in the save-as dialog
< and presses `<tt>OK</tt>'.  For example, Figure 334 shows the user having
< entered the file name "<tt>PersonalOptions</tt>" as the location to which options
< are saved.
< 
< <br>
< <br>
< <hr>
< <a name="Figure Saving options to a PersonalOptions file">
< <p align=center>
< <img src="images/options-save-as-dialog-filled-in.gif">
< </p>
< <p align=center>
< Figure 334:  Saving options to a PersonalOptions file.
< </p>
< <hr>
< </a>
< <br>
< 
< The `<tt>Save As</tt>' command does not execute `<tt>Apply</tt>' or `<tt>Save</tt>', it
< only saves a coy of the current options settings on the selected file.  The
< applied and saved states of options are unchanged after execution of `<tt>Save
< As</tt>'.
< </p><p>
< The `<tt>Load ...</tt>' button is used to load a previously-saved options file.
< When the user presses `<tt>Load ...</tt>', and there are no unapplied or unsaved
< options, the system displays the dialog in
< Figure 335.
< 
< <br>
< <br>
< <hr>
< <a name="Figure Options load dialog">
< <p align=center>
< <img src="images/options-load-dialog.gif">
< </p>
< </pre>
< <p align=center>
< Figure 335:  Options load dialog.
< </p>
< <hr>
< </a>
< <br>
< 
< The names of valid options files appear in normal typeface in the directory
< list; all other types of files appear in greyed typeface.
< <a href="file.html#New and Open">
< Section 2.8.2
< </a>
< covers further details on the format and use of file opening (i.e., loading)
< dialogs, including the directory browsing list and file-type validation.
< </p><p>
< To load options from a local file, the user selects or enters a filename in the
< `<tt>File:</tt>' text field.  The user can alternatively load the
< administrator-defined options file from the Calendar Tool central host
< computer, if the user is currently connected to an operational central host
< (see
< <a href="admin.html#Calendar Tool Central Host Computer">
< Section
< </a>
< ).
< If the user is not so connected, the `<tt>Load from central host</tt>' checkbox is
< disabled.  Figure 336 shows the user having selected to load from the
< "<tt>Personal Options</tt>" file.
< 
< <br>
< <br>
< <hr>
< <a name="Figure Loading from the Personal Options file">
< <p align=center>
< <img src="images/options-load-dialog-filled-in.gif">
< </p>
< <p align=center>
< Figure 336:  Loading from the Personal Options file.
< </p>
< <hr>
< </a>
< <br>
< 
< Figure 337 shows the case where the user selects to load from the central
< host.
< 
< <br>
< <br>
< <hr>
< <a name="Figure Loading options from the Calendar Tool central host">
< <p align=center>
< <img src="images/options-load-from-central.gif">
< </p>
< <p align=center>
< Figure 337:  Loading options from the Calendar Tool central host.
< </p>
< <hr>
< </a>
< <br>
< 
< When the central host checkbox is selected, the <tt>File</tt> and <tt>Directory</tt>
< data fields are cleared and disabled.  The user confirms the load by pressing
< `<tt>OK</tt>', whereupon the option settings defined in the loaded file become the
< current unapplied and unsaved settings in the options dialog.  (To restore the
< Calendar Tool to the global default options configuration, the user can save
< the options settings loaded from the central host to the local <tt>Options</tt>
< file.)
< </p><p>
< If there are unapplied or unsaved option changes when the user presses `<tt>Load
< ...</tt>', the system issues the warning shown in Figure 338,
< 
< <br>
< <br>
< <hr>
< <a name="Figure ">
< <p align=center>
< <img src="images/options-load-warning.gif">
< </p>
< <p align=center>
< Figure 338:  .
< </p>
< <hr>
< </a>
< <br>
< 
< where <em><tt>affected</tt></em> is one of "<strong><tt>unapplied</tt></strong>" or "<strong><tt>unsaved</tt></strong>",
< as appropriate.  Unapplied changes are also unsaved, given that saving
< automatically applies.  The user presses <tt>`Yes'</tt> to proceed, `<tt>No</tt>' to
< cancel the `<tt>Load</tt>' command.
< </p><p>
< The `<tt>Load</tt>' command does not perform `<tt>Apply</tt>' or `<tt>Save</tt>'.  Once
< options are loaded, they are both unapplied and unsaved.  Hence, loading has
< precisely the same effect as if the user had manually entered all of the loaded
< values in the options dialog.
< </p><p>
< <em>Leaning towards fixing the following paragraph to allow load from (and maybe
< save to) two sources -- options files and (portions of) calendar files.  If
< this happens, we need to fix above too.  See
< <a href="file.html#File Types">
< Section
< </a>
< for an overview.  So if we allow load from cal file but not save-as to cal
< file, here's how we accomplish save-into: open the cal file, load, save (as
< opposed to save-as). </em>
< </p><p>
< Even though calendar-specific options are stored within calendar files, the
< `<tt>Save As</tt>' and `<tt>Load</tt>' option commands operate only on separate
< options files, not on the options portion of calendar files.  The system
< considers calendar files and saved option files as two different file types
< (see
< <a href="file.html#File Types">
< Section
< </a>
< ).  When an extant calendar file is selected in the `<tt>Save As</tt>'
< file-selection dialog, saving to that file replaces the previous file contents
< entirely, in just the same way as saving to any other extant file would do.
< The `<tt>Load</tt>' options command can only be used to load previously saved
< options files, not the options portion of a calendar file.  Sections
< <a href="file.html#New and Open">
< Section 2.8.2
< </a>
< and
< <a href="file.html#Save, Save As, Save All">
< 
< </a>
< describe how file dialogs display inapplicable file types and the details of
< overwriting extant files.
< </p><p>
< Since options are calendar-specific, the `<tt>Apply</tt>' and `<tt>Save</tt>'
< commands operate only on one calendar at a time, namely the current calendar.
< Switching to a different current calendar always makes the options for the
< newly current calendar become active, without applying or saving options for
< the previously current calendar.  Given this behavior, there is no direct way
< to save or apply the same option settings to multiple calendars en masse.  To
< apply or save the same option settings to more than one calendar, the user must
< save the options to a file, make a new calendar current, load the saved
< options, and then apply or save the loaded options to the newly current
< calendar.
< </p><p>
< Any applied but unsaved changes are not saved by `<tt>Cancel</tt>'.  If the
< options dialog is subsequently opened on a calendar with unsaved option
< settings, the unsaved state of the options is reflected by the `<tt>Save</tt>'
< button being enabled.  If user closes a calendar with unsaved options or exits
< the Calendar Tool when one or more calendars have unsaved options, the system
< warns the user of the condition, as described in Sections
< <a href="window-viewing.html#Closing Windows">
< 2.3.6.1
< </a>
< and
< <a href="file.html#Exit">
< 2.8.7.
< </a>
< </p><p>
< <em>2jul04 NOTE:</em> Be sure to cover the (possibly subtle) distinction between
< option saving from within the cal tool admin program versus the regular-user
< cal tool.  Viz.,
< <ol type=a>
< <li>
< When an admin does regular File->Save, user-related option values always go in
< the <tt>Options</tt> file, since there is no calendar in/with which to store
< options calendar-specifically; I suppose we could say that options are
< "distribution-specific", but it seems this would not work well at all, since
< there's no distributional analog of the "current calendar".
< <li>
< Otherwise, the file-related option dialog buttons should behave the same for
< the admin as for the regular user.  The usage semantics may differ a bit, and
< be worthy of explaining, as in the reason the admin does an options-dialog
< `<tt>Save As</tt> is to create (conveniently) a reusable options "bundle", that
< may be useful generically for different custom distributions.  As with the
< regular-user version of the options dialog, `<tt>Save As</tt>' is no big deal,
< since it can be accomplished pretty easily at the OS level via file copy.
< However, it's worth having, and for fuck's sake, even if it isn't, it's not at
< this point going to get nuked from the multitude of option screen shots we
< have.
< </ol>
< </blockquote>
< </p><p>
< And here's a blast form the not-so-distant past about the now-gone
< `<tt>File->Local Files</tt>' command.
< <blockquote>
< .sh 4 "File Connect and Local Files"
< </p><p>
< The `<tt>Connect</tt>' command was described in
< <a href="admin.html#Central Host Connections">
< Section 2.6.6.1
< </a>
< on administrative commands.  When the user selects the `<tt>Local Files</tt>'
< command, the system displays the dialog shown in Figure 339.
< 
< <br>
< <br>
< <hr>
< <a name="Figure Local files dialog">
< <p align=center>
< <strong><em>Stick in the</em></strong> <strong><em>`Default Calendar Tool Directory'</em></strong>
< <br>
< <strong><em>item from the Admin tab of the Options dialog.</em></strong>
< </p>
< Also add field for entering default calendar to open on fileless app launch.
< <p align=center>
< Figure 339:  Local files dialog.
< </p>
< <hr>
< </a>
< <br>
< 
< </blockquote>
< </p><p>
< The following has been dealt with fully, including nixing the idea of being
< able to overwrite non-calendar files:
< <blockquote>
< .sh 4 "File Types"
< </p><p>
< <em>Discuss the different file types and the ramifications thereof, including
< that file types are used to do the filename greying thing in open/load dialogs,
< and that file typing may vary in different operating environments.</em>
< </p><p>
< <em>OK, try this:</em> (See the semi-epiphany in options.me.)  Also, as a
< non-annoying emacs-like behavior, we'll list all file names greyed out in all
< save-as dialogs, but all the user to select them.  This way in contexts like
< the options save-as dialog, we can let the user select the standard Options
< file in the chooser for overwriting.  Given this behavior, we may well want to
< specialize the overwrite message into two categories: (1) overwriting an
< extant file of the correct type (e.g., overwriting <tt>Options</tt> from the
< options save-as dialog or an extant cal file from <tt>File->Save As</tt>) (2)
< overwriting an extant file of the wrong type (e.g., overwriting
< <tt>Categories</tt> the options save-as dialog or an extant file of some
< non-cal-tool type from the <tt>File->Save As</tt> dialog.  It think is is all
< pretty farging sweet.
< </blockquote>
< </p><p>
< Done and expanded upon:
< <blockquote>
< .sh 4 "Calendar File Contents"
< </p><p>
< <ol type=a>
< <li>
< scheduled items -- initially empty
< <li>
< categories -- initially holidays
< <li>
< custom lists -- initially empty
< <li>
< filter settings and custom filters -- all shown, custom filters empty
< <li>
< windowing mode -- initially per-level
< <li>
< options -- initially obtained from default options file (<tt>Options</tt> by
< default) (hmm, there's potentially a chicken-and-egg problem lurking here;
< figure it the f out)
< <li>
< windows
< </ol>
< </blockquote>
< </p><p>
< Here's a slew of seriously funked up bullshit about saving and loading
< settings (hold on a minute, we're still seeing if it's really seriously funked
< up): ...  OK, I've held on and checked things out.  Some of it isn't so
< funked up after all, but things have been fixed in the latest version of the
< file section, and here's the stuff to which I refer:
< <blockquote>
< <em>12jul04 -- OK, we need to add to the</em> `<em><tt>Load Settings</tt></em>' <em>dialog
< the option to load them from the current host, which replaces the short-lived
< but seemingly uninspired</em> `<em><tt>Options->Load from Host</tt></em>' <em>command.</em>
< <p>
< It's more than just the window configuration since it includes what files are
< open.  I think the easiest way to define exactly what save configuration does
< is as a script file.  This way we can deal with the tricky issue of having the
< display look the same, but having the displayed content all be relative to
< today's date.  If for some reason the user would like to have a configuration
< that is absolute datewise, or relative some other date than today, then she can
< tweak the generated script from `<tt>Save Config</tt>', or of course write her own
< start-up script from scratch.
< An issue we need to deal with is the relationship between the option setting of
< what we call "the standard default view" in the ui-overview.  Here's what I
< think could work well: There is an option called `<tt>Start-Up View Level</tt>'
< that specifies the default viewing level from item to year.  If there is no
< init file in the user's home dir (per OS-specific definition of "home dir" and
< as discussed further in Admin section), then the Cal Tool comes up a la
< described in the initial screen config in the ui-overview.  Viz., there's a
< menubar and zero or one view window at the level specified by the setting of
< `<tt>Start-Up View Level</tt>', open on today's date.  If there is an init file or
< the tool is invoked with an start-up file in the command line or from a
< start-up file icon, then we could do one of two things:
< <ol type=a>
< <li>
< The system displays <em>no</em> windows automatically, thus ignoring entirely
< the setting of <tt>default-init-view-level</tt>; this means that the mere
< existence of an init file means there's no default display, and I don't think I
< like this; so let's try thing b ...
< <li>
< The system proceeds to put up the initial window per
< <tt>default-init-view-level</tt>, and then goes about executing the init file.  If
< the user really wants to get rid of the default initial window(s), she puts
< this code at the beginning of the init file, which code closes the initial
< window:
< <blockquote><pre>
< ViewWindows(1);
< FileClose();
< </pre></blockquote>
< This works because of the rule that says the default window is put up before
< the init file is run, which means therefore that it's window 1 in the windows
< list, hence the arg of 1 to <tt>ViewWindows</tt> (assuming lists start from 1
< like humans think, not from 0 like geeks think).  But given this, here's an
< even simpler bit of code to do the same thing:
< <blockquote><pre>
< FileCloseAll();
< </pre></blockquote>
< which works for hopefully obvious reasons.
< </ol>
< <p>
< This all seems pretty darn clean.  To be consistent, it seems with this scheme
< that the first line of the init file saved with `<tt>Save Config</tt>' will in
< fact be the preceding chunk of code to close the default window, so that the
< config file starts with a blank slate.
< </blockquote>
< </p><p>
< <strong>Another 4aug03 NOTE</strong>.  OK, I think I want to take back what I
< say in the next paragraph.  I think it's appropriate to require that each user
< calendar be stored in a separate file in a known (settable) dir, with some
< reasonable convention for file name, such as the user's ID plus ".cal"
< extension.
< </p><p>
< <strong>4aug03 NOTE (if not mentioned elsewhere):</strong> Implementors can
< choose how they implement the central host repository, e.g., having a separate
< cal file for each user or having all user cals in the same file, or some other
< implementation.  There is no requirement that a user be able to view the
< contents of a calendar in the central repository as a raw file in any form.
< Operationally, the user has her own local calendar as a file with a known name.
< On the remote host, the publicly-visible <em>contents of</em> that calendar are
< made available to other users through the calendar tool, via the operational
< effects of connecting and file saving described herein.  Again, however, there
< is no requirement for the user to see a specific calendar file on the central
< host.
< </p><p>
< Nixed the auto update of host tab in the next bit, but did address the issue of
< warning on save-as when current cal is connected:
< <blockquote>
< `<tt>Save As</tt>' needs to issue a warning when the current calendar is
< associated with a connected host.  The warning should allow the user to stay
< connected, with the host connection table automatically updated.
< </blockquote>
< </p><p>
< Decided against the following, since user can move/remove Settings file if she
< doesn't want it used on File->New, or load a cleared version of settings at any
< time:
< <blockquote>
< The `<tt>Load Settings</tt>' dialog also has a radio buttons for `<tt>load
< settings on File->New</tt>' versus `<tt>Use installed default settings on
< File->New</tt>.
< </blockquote>
< </p><p>
< I was thinking about a adding an admin option for `<tt>Auto-save tool-wide
< settings on exit</tt>' but decided it wasn't necessary because (a) there are
< only two such settings (open cals and connect tab), (b) open cals ain't that
< important, (c) there's already a convenience Save button in connect tab dialog.
< Also, I don't think it's necessary to warn the user on exit if the only unsaved
< tool-wide setting is current open cals, since that's not really a big deal
< given all the other ways that the user can save this stuff, and it's certainly
< not critical to operation if it's missed when the user wanted it not to be.
< The emacs hack would say to add the yes/no option warn-on-exit-if-open-
< calendar-names-setting-not-saved.
< </p><p>
< <em>Most likely nix the following bulleted list.</em>
< <br>
< File-related commands allow the user to perform these functions:
< <ul>
< <li>
< create new calendars
< <li>
< open existing calendar files
< <li>
< close one or all open calendars
< <li>
< save calendars
< <li>
< save the configuration of the Calendar Tool
< <li>
< set the default file directory where Calendar Tool files are stored
< <li>
< print calendars
< <li>
< exit the Calendar Tool
< </ul><font color=black>
< These commands are described in the scenarios that follow.  Before the
< scenarios, a general description is given of the different types of files used
< by the Calendar Tool, and the types of data stored in the files.
< </p><p>
< Print crap:
< <blockquote>
< The printing functionality in the initial version of the Calendar Tool is
< limited ... .  <em>Make it just screen shots.</em>
< </p><p>
< OLD: <em>Sketch of some ideas:  The print dialog should include at least the
< following options:
< <ul>
< <li>
< start date
< <li>
< end date
< <li>
< apply active filter?
< </ul><font color=black>
< But woe nelly, I just had a look at all of the features in Claris, particularly
< for the "book" option, including editing its format.  I think this will be an
< excellent place to draw the line and say that fancy printing will be part of
< future work.</em>
< </p><p>
< NOT SIMPLE ENOUGH: <em>So, here's the deal with printing.  We'll keep it
< brutally simple by printing out in the plain text form of the current example-
< items file.  In fact, we can use this file pretty much as is, except for the
< parenthetical remarks about edits made.  We'll also need to add some kind of
< indication of individual instance changes to recurring items, which will be
< done in the same brutally simple form.</em>
< </blockquote>
< </p><p>
< Exit crap:
< <blockquote>
< </p><p>
< <em>At this point, it looks like, oh please say it's so, that Exit can do
< exactly what Close All does in terms of offering to save.  Hope the fuck
< so.</em> Well, at least one additional thing Exit needs to check is if there
< have been changes to either of the session-wide settings since settings were
< last saved (including the save in the global options and connection table
< dialogs), i.e., open calendars and connection table.
< </p><p>
< If the user exits or closes a calendar with unsaved options, then in addition
< to whatever offer-to-save file messages there may be, there are also offer-to-
< save options messages.  Viz., there is one such message for each active
< calendar for which options have been applied but not saved.  The text of these
< offer-to-save messages should most likely be integrated into the file offer-to-
< save dialogs, so two dialogs don't appear if both the file data and options
< need to be saved for a particular calendar.
< </p><p>
< If the user exits or closes a calendar with notifications that have not yet
< been responded to, the system displays a dialog of the form:
< <blockquote><pre>
< There are meeting notifications you have not yet processed.  Do you want to
< review or discard the unprocessed notifications?
< 
<             Review    Discard
< </pre></blockquote>
< If the user chooses 'Review' and then grows tired of it before all
< notifications are processed (where processing means pressing one of the three
< buttons on the bottom, or explicitly closing the notification dialog (which is
< equivalent to Delay)), then she can select Exit of Close again (whichever of
< which started the whole thing, or either) and then hit Discard.  (Or use ...
< (fell the fuck off, but who gives a fuck at this point.))
< </blockquote>
< 
< <a name="Bits from Options that May Be Useful, or May Not">
< <h3>
< 6.3.  Bits from Options that May Be Useful, or May Not
< </h3>
< </a>
< </p><p>
< The change in location of the repository directory does not affect any of the
< contents of the repository files or subdirectories.  All of these files and
< subdirectories are moved in tact from their previous location to the new
< location.
< </p><p>
< When the administrator applies a change to the repository location by pressing
< `<tt>OK</tt>' <em>(should be apply)</em>, the system verifies that the
< specified file path is valid and readable and writable by the Calendar Tool
< Administration program.  If it is not, the system reports an error as described
< in
< <a href="error-conditions.html#Invalid repository path">
< Section 2.12.7.2.
< </a>
< To avoid operational disruption, the `<tt>Host Files</tt>' command is disabled
< when the server is running.
< </p><p>
< <em>NOTE 12jul04</em> -- OK, this section [admin options] is pretty well messed
< up.  The deal is that the long-held idea that the admin would define user
< options by using a mock version of the user prefs is outta here.  Instead,
< we'll have admin-relevant options tabs for `<tt>Times and Dates</tt>' (which
< turn out in fact to be relevant in an number of admin dialogs),
< `<tt>Fonts</tt>' (which are pretty much always relevant options in any app that
< does not want to be a pain in the neck by not letting users change display
< fonts), and `<tt>Administrative</tt>' (which presumably will stay the same as
< the current `<tt>Administrator</tt>' subtab, with whatever recent mods are
< necessary, at least one mod being the likely addition of the a place to set the
< host dir, to parallel the new way things are in the regular user UI, where
< `<tt>File->Local Files</tt>' is now gone).  And the way the admin will define
< user options is to invoke the regular Calendar Tool, and do the normal options
< and save-settings things there.  Even though this may not be quite as
< convenient as the old way (and this is debatable), it's way fucking less
< convoluted than having what was turning into a major pain in the neck of having
< two ways for the admin to set user options.  One of the key discoveries that
< tore it was trying to figure out where the fuck the options-containing settings
< file would go when the admin did a `<tt>File->Save</tt>' in the admin program.
< We probably could've figured something out, but it was definitely getting
< fucked up to have the two ways of admins setting user options.  So, get to it
< and fix this.
< </p><p>
< For an administrative user running the Calendar Tool Administration program,
< the `<tt>Options</tt>' command menu and top-level tabs of the options dialog
< are the same as for the regular Calendar Tool user.  Physically, the only
< difference between the administrative version of the options versus the
< regular-user version is that the `<tt>Administrative</tt>' tab has two subtabs,
< as shown in Figure 340.
< 
< <br>
< <br>
< <hr>
< <a name="Figure Administrator version of the Administrative options Tab _">
< <p align=center>
< <img src="images/options-admin-admin.gif">
< </p>
< <p align=center> Figure 340:  Administrator version of the Administrative
< options Tab _.  </p>
< <hr>
< </a>
< <br>
< 
< The `<tt>User</tt>' subtab has exactly the same format as the full
< `<tt>Administrative</tt>' tab for the regular user, shown in
< <a href="options.html#Figure Administrative options tab">
< Figure 281.
< </a>
< Details of the `<tt>Administrator</tt>' subtab shown in Figure 286 are
< explained shortly.
< </p><p>
< Functionally, the administrator version of the options dialog differs
< fundamentally from the regular-user version.  In the administrator version,
< none of the option settings, except those shown in Figure
< <a href="options.html#Figure Administrator version of the Administrative options Tab">
< Figure 286
< </a>
< applies to the Calendar Tool Administration Program itself.  Rather, when an
< administrator makes changes to options values, the changes are recorded for use
< in creating customized Calendar Tool distributions, as described in
< <a href="admin.html#Creating Calendar Tool Distributions">
< Section .
< </a>
< The point is, none of the option settings for regular-user commands apply to
< the Calendar Tool Administration program, since the administration program does
< not perform calendar scheduling or viewing.  Hence, except for the one
< administrator-specific subtab, administrator-supplied option settings apply to
< custom distributions of the Calendar Tool, not to the administration program
< itself.  In a given custom distribution, these options serve as the installed
< default settings until changed by the regular user.
< </p><p>
< In keeping with the functionality just described, the `<tt>Apply</tt>' button
< in the administrator version of the options dialog is only enabled when the
< administrator has made a change within the `<tt>Administrator</tt>' subtab.
< Otherwise, the option dialog buttons in the administrator version function the
< same as in the regular-user version of the options dialog, as described in the
< preceding scenarios.
< </p><p>
< The `<tt>Administrator</tt>' subtab in
< <a href="options.html#Figure Administrator version of the Administrative options Tab">
< Figure 286
< </a>
< applies specifically and exclusively to the Calendar Tool Administration
< program.
< </p><p>
< <em>Re. </em>`<tt>Initial View</tt>'<em> level, to be consistent with the way
< things are explained in specific-date-viewing, the default level cannot be at
< the item level.  Nor do I think it makes particularly good sense to have it be
< some list.  Therefore, the default initial view level is one of four day
< through year levels, and perhaps a "no window" option.</em>
< </p><p>
< Here's a potentially interesting bit of going around in circles regarding
< whether to have options to allow the user to change ID and password:
< <blockquote>
< <em>Add options for default caltool user ID and password.  These are the ones
< tried first for connect.  NOT -- IDs and passwds are now in connect dialog. NOT
< NOT -- they're not in the connect dialog, so we do want options here for
< default ID and passwd.  NOT NOT NOT -- the user doesn't get to change his ID
< himself, and the password is chaged using Admin->Change Password, q.v.</em>
< </blockquote>
< </p><p>
< And for an example of a brain-damaged option (at least now given that the only
< way to contact an admin is via the Admin menu):
< </p><p>
< <blockquote>
< The option to '<tt>Hide Admin menu when not connected</tt>' controls when the
< `<tt>Admin</tt>' menu appears ... .
< </blockquote>
< .sh 5 "Platform-Dependent Options"
< </p><p>
< <em>As of 23jul02, I'm saying a firm (as possible with me) NO to this.</em>
< </p><p>
< <em>Although we'd like to avoid it, it may be necessary to at least plan for
< platform-dependent options that may be needed for networking connections.  If
< at all possible, I'd like to avoid these.  They sound like a cop out to
< me.</em>
< </p><p>
< Well farg me, the hoped-for ``Final Sketch'' in the next paragraph wont fucking
< work -- take a mf look at options-admin-admin.idr.  So, do this:
< <ul>
< <li>
< In the Admin version of the options dialog, have everything be exactly the same
< as the user, except for the Administrative tab, which will have two subtabs --
< User and Administrator
< <li>
< The User subtab is identical with the Admin tab in the user options dialog, and
< like all of the other options tabs is used by the administrator to set options
< to be stored in a distribution.
< <li>
< The Administrator subtab is what's currently in options-admin-admin.idr,
< cleaned up as appropriate; in particular, we need to note that only the top
< tier of the three DB dialogs can have options set (e.g., not any of the sub-
< dialogs like the ones for location bookings); also, change the Central Host
< button to a Distribution button, since the latter dialog is now one with enough
< stuff in it to make default settings useful (albeit probably only minimally
< so).
< <li>
< No options sharing, since the only one that was shared was email app, and now
< we'll clarify that caltool admin doesn't launch an email app.
< <li>
< Much if not all of the crap below about global options and "inheritance" is
< obsolete; here's the way I think it should now work:
< <ul>
< <li>
< All of the user options set by an admin are made available to users via a
< created distribution, and in particular via the Options file that is packaged
< with that distribution.
< <li>
< There is no `Defaults' button in the user options dialog; if the user wants to
< change the distribution-supplied options for possible later reversion thereto,
< he must do the following:
< <ul>
< <li>
< save the original <tt>Options</tt> file that comes with the admin-supplied
< distribution, either with the `<tt>Save As ...</tt>' options dialog command, or
< via a regular OS file save
< <li>
< use the `<tt>Load ...</tt>' options dialog command to re-load the saved
< original <tt>Options</tt> file after any options changes have been made and
< saved (with an intervening, or move/copy the original saved file back into the
< file named "<tt>Options</tt>".
< </ul><font color=black>
< </ul><font color=black>
< </ul><font color=black>
< </p><p>
< Final Sketch:
< <ul>
< <li>
< Have options be <em>exactly</em> the same as for regular users.
< <li>
< Option values set by the admin are used as the config defaults, as described in
< the Distribution subsection.
< <li>
< The only option setting that applies to the admin program as well as to the
< config settings is the  default email program, which in the case of the admin
< program itself applies to the email program that is used to send admin messages
< to the user, as described in the Admin section.
< </ul><font color=black>
< <li>
< As far as dialog defaults go for the Admin program, the only behavior is that
< all dialogs are reopened with the values entered the last time the dialog was
< displayed.  For the program, there no other way to set specific default values
< for any of the admin edit dialogs.  When an admin dialog is initially displayed
< or cleared, the initial values are as shown in Table 20.
< 
< <br>
< <br>
<                                      <hr>
< <br>
< 
< <a name="Table Default values for all admin-dialog data fields">
< <em>whatever</em> <p align=center> Table 20:  Default values for all admin-
< dialog data fields.
< <br>
< <hr>
< </p>
< 
< <br>
< 
< <p>
< </a>
< </ul><font color=black>
< </p><p>
< NOTE: There needs to be a place for privileged admin-specific options, in
< particular these:
< <ul>
< <li>
< default size limit for user calendars; int text field with empty default,
< meaning no limit
< <li>
< defaults for db dialogs, using the same style as the defaults for scheduling
< dialogs
< <li>
< Time to Complete Meeting Scheduling While Others Are Waiting: int minutes
< (default 2)
< <li>
< possibly other stuff in the privileged admin menu
< </ul><font color=black>
< OK, it looks like the entire admin tab needs to be expanded for versions of the
< options dialog that is displayed from within the caltool admin program.  It
< almost certainly needs subtabs, more-or-less correspondent to the items on the
< privileged admin menu.
< </p><p>
< The options dialog that runs under Calendar Tool Administration has the same
< overall format as for regular users, except that the buttons along the bottom
< of the dialog are limited to, <tt>Save</tt>, <tt>Clear</tt>, and
< <tt>Cancel</tt>.
< </pre></blockquote>
< There separate dialog `<tt>Save</tt>' and there is no `<tt>Apply</tt>' button.
< Since there are no calendar viewing commands in the Calendar Tool
< Administration program, setting options does not apply to a calendar being
< viewed, but to the initial default values for those options for Calendar Tool
< users, as stored in the <tt>Options</tt> file.
< </p><p>
< <em>NOTE: This paragraph needs to be fixed per the latest and greatest options
< set up.</em>  The default option values set by the administrator are available
< to users in two ways.  When running the Calendar Tool, the user can select the
< `<tt>Defaults</tt>' button in the `<tt>Options</tt>' dialog.  This allows the
< user to set options to the default values set by an administrator, as described
< <a href="rationale.html#setting defaults">
< above.
< </a>
< </p><p>
< The other way that administrator-set options values are made available to
< regular users is through a Calendar Tool program distribution created by the
< administrator.  That is, when an administrator creates a program distribution
< using the `<tt>Admin Distribution</tt>' command, the option values that have
< been set by the administrator are installed in the distribution program as the
< defaults for that program.
< </p><p>
< Here's the deal for "inheritance" of options:
< <ol type=a>
< <li>
< First global options are set.
< <li>
< Then user-specific options are set, possibly overriding admin options.
< <li>
< Finally, calendar-specific options are set, possibly overriding either of the
< previous levels.
< </ol>
< 
< Here's some fodder axed on 11aug03 from the Admin section:
< 
< .sh 3 "Global Options"
< </p><p>
< <em>Explain how the first three kind of options are ?all? settable by user and
< are therefore explained in the next section.  The difference between what the
< admin does versus what a regular user does is that under `Admin->Global
< Options', the admin is setting the global defaults for all users, some or all
< of which may be changed by users on an individual basis.  I think it's also
< worth mentioning that an admin can be a regular user if she wants to be.  I.e.,
< there need not be a special user account that is "the" admin; there can be if
< that's how a group of users wants to set things up, but there need not be.  If
< an admin wants to be are regular user, she needs to be aware that functions
< performed under the `Admin' menu have potentially global effects, and must
< exercise according care in the execution of the functions.
< </p><p>
< The Admin options are viewable by regular users but settable only by system
< admins, so they're described here in this section of the requirements.</em>
< <p>
< .sh 4 "Administrative Options"
< <p>
< .sh 5 "Root System Administrator"
< <p>
< .sh 5 "Group Leader Privileges"
< </p><p>
< <em>A bit of rationale: Since we're nixing pencil in, there was a bit of
< thought just now that group leaders may not be all that necessary.  However,
< there are other useful reasons to have them.  Also, I think it's reasonable to
< say that group leaders are the only ones who can schedule meetings for which
< online notification will be sent by the tool.  So in effect what we've done is
< demote pencil power in to notify power.</em>
< </p><p>
< With that bit of rationale, here are the group leader privileges as we
< currently see them:
< <ol type=a>
< <li>
< Meeting notifications sent to attendees.
< <li>
< 3jul02 NOTE: The following option is obsolete, given the details described in
< the latest changing-and-deleting section, in particular the fact that a leader
< cancels a meeting without deleting it by using the change operation instead of
< delete.
< <br>
< Cancellation notice sent when group leader deletes a meeting; deleted for non-
< recurring, marked as CANCELED for recurring (maybe, or probably better just to
< nuke it or maybe make this an option).
< <li>
< Can add and remove members for group.
< </ol>
1089c16
< 6.4.  Pretty Close to the Last Pile 'o Due Due from Admin
---
> 6.1.  Pretty Close to the Last Pile 'o Due Due from Admin
1092c19
< </p><p>
---
> <p>
1156c83
< menu, the system displays the dialog 341.
---
> menu, the system displays the dialog 314.
1174c101
< Figure 341:  shit.
---
> Figure 314:  shit.
1194c121
< Figure 342 shows the user ... .
---
> Figure 315 shows the user ... .
1214c141
< (We need to define precisely the terms <em>associated</em> and
---
> <em>(We need to define precisely the terms associated</em> and
1251c178
< <em>The `Central Host' dialog looks like Figure 342.</em> -- <strong>NO</strong>, it's
---
> <em>The `Central Host' dialog looks like Figure 315.</em> -- <strong>NO</strong>, it's
1264c191
< <p align=center> Figure 342:  Central host dialog for a regular user.  </p>
---
> <p align=center> Figure 315:  Central host dialog for a regular user.  </p>
1307c234
< 6.5.  Nixed in Favor of Explicit Dialog Settings
---
> 6.2.  Nixed in Favor of Explicit Dialog Settings
1327c254
< 6.6.  What's on the Host
---
> 6.3.  What's on the Host
1340c267
< 6.7.  More nukation from admin, here re. purging and capping
---
> 6.4.  More nukation from admin, here re. purging and capping
1381c308
< 6.8.  Nuked from Change/Delete Section 28 Jul 03
---
> 6.5.  Nuked from Change/Delete Section 28 Jul 03
1389c316
< Figure 166
---
> Figure 167
1394c321
< Figure 157.
---
> Figure 158.
1399c326
< Figure 167.
---
> Figure 168.
1408c335
< Figure 166,
---
> Figure 167,
1415c342
< 6.9.  Nuked from Admin Section 27 Jul 03 through 11 Aug 03
---
> 6.6.  Nuked from Admin Section 27 Jul 03 through 11 Aug 03
1458c385
< `List Admins' and `Users' commands in the `Admin' menu.  Figure 343 shows a
---
> `List Admins' and `Users' commands in the `Admin' menu.  Figure 316 shows a
1484c411
< Figure 343:  User requesting calendar tool information changes.
---
> Figure 316:  User requesting calendar tool information changes.
1514c441
< IWe need to remove the ID and Passwd columns, which were recently added,
---
> <em>We need to remove the ID and Passwd columns, which were recently added,
1517c444
< leaving the <tt>Password</tt> command in the regular-user <tt>Admin</tt> menu is
---
> leaving the <tt>Password</em> command in the regular-user Admin</tt> menu is
1547c474
< Describe that `<tt>List Admins</tt>' shows who all the admins are, Figure 344.
---
> Describe that `<tt>List Admins</tt>' shows who all the admins are, Figure 317.
1557c484
< Figure 344:  List of Calendar Tool administrators.
---
> Figure 317:  List of Calendar Tool administrators.
1598c525
< Section .
---
> Section 2.6.5.2.
1668c595
< 6.10.  Registered Users
---
> 6.7.  Registered Users
1737,1748d663
< </p><p>
< 7jul04 NEW CONCLUSION: Fuck the chicken-and-egg bullshit around the
< <tt>Admin</tt> menu.  Just leave it the fuck up all the time, with the DB
< commands and passwd command disabled unless the current calendar is connected.
< This means we move the <tt>Connect</tt> command back to the <tt>Admin</tt> menu
< where it belongs.  The fact that it belongs in the <tt>Admin</tt> as opposed to
< <tt>File</tt> menu was brought pretty clearly home when I tried to write a
< decent intro paragraph to the <strong>Flie</strong> section, whereupon it
< became pretty darn clear that <tt>Connect</tt> is only weakly related to file
< processing.  Furthermore, the fact that I've seen fit to explain the connect
< command fully in the <strong>Admin</strong> section makes it quite clear indeed
< that it should be an <tt>Admin</tt> as opposed to <tt>File</tt> menu command.
1752c667
< 6.11.  ``View ...'' versus ``Edit ...'' as Button and Menu Item Names
---
> 6.8.  ``View ...'' versus ``Edit ...'' as Button and Menu Item Names
1766c681
< 6.12.  The Explicit Delay Button in Meeting Notifications
---
> 6.9.  The Explicit Delay Button in Meeting Notifications
1777c692
< 6.13.  Group Explorer
---
> 6.10.  Group Explorer
1797c712
< system displays the dialog in Figure 345.
---
> system displays the dialog in Figure 318.
1806c721
< <p align=center> Figure 345:  Group database dialog with explorer.  </p>
---
> <p align=center> Figure 318:  Group database dialog with explorer.  </p>
1813c728
< Figure 200,
---
> Figure 201,
1820c735
< viewing window shown in Figure 346.
---
> viewing window shown in Figure 319.
1829c744
< <p align=center> Figure 346:  Group explorer.  </p>
---
> <p align=center> Figure 319:  Group explorer.  </p>
1843c758
< 6.14.  Nuked from Admin; Presumably to Go In Some Form in Installation
---
> 6.11.  Nuked from Admin; Presumably to Go In Some Form in Installation
1857c772
< user db records.</em>
---
> user db records.
1859c774
< <em>3jul02 Note: This section may go in favor of the higher-level installation
---
> 3jul02 Note: This section may go in favor of the higher-level installation
1868c783
< config'd.</em>
---
> config
1872c787
< 6.15.  Fodder from Wincow Viewing Section, Ca. Aug 02
---
> 6.12.  Fodder from Wincow Viewing Section, Ca. Aug 02
1876c791
< <em>NOTE prime:</em> OK, it looks like we're going (back) to the rule that a
---
> NOTE prime:</em> OK, it looks like we're going (back) to the rule that a
1924c839
< 6.16.  Meeting Notifications and Calendar-Host Association
---
> 6.13.  Meeting Notifications and Calendar-Host Association
1952c867
< 6.17.  Nuked from Options, Related to Overly-Complicated Home Dir Specs
---
> 6.14.  Nuked from Options, Related to Overly-Complicated Home Dir Specs
1965c880
< 6.18.  Decision about User Control Over Notifications
---
> 6.15.  Decision about User Control Over Notifications
1975c890
< 6.19.  Some Uncommonly To-The-Point Fodder from the Options Section
---
> 6.16.  Some Uncommonly To-The-Point Fodder from the Options Section
2006c921
< The idea is that each user can control who she accepts being bugged by for
---
> <em>The idea is that each user can control who she accepts being bugged by for
2019c934
< getting overly complicated, but hey so's the whole darn system.
---
> getting overly complicated, but hey so's the whole darn system.</em>
2033c948
< <em>Some question/details pursuant to the above dialog idea:</em>
---
> <em>Some question/details pursuant to the above dialog idea:
2053c968
< 6.20.  Nuked from Options Section
---
> 6.17.  Nuked from Options Section
2057,2065c972,980
< When the user presses `<tt>Save</tt>' the system first performs
< `<tt>Apply</tt>' (if it is enabled), then saves all option settings in the
< current calendar.  If no calendar is open, options are saved in the standard
< `<tt>Options</tt>' file.  As with the `<tt>Apply</tt>' button, `<tt>Save</tt>'
< is initially disabled, becoming enabled when the user changes the options
< settings in one or more tabs, makes current a calendar with unsaved changes, or
< loads a new options file.  While execution of `<tt>Save</tt>' performs
< `<tt>Apply</tt>', the converse is not true.  Therefore, the settings in the
< options dialog exist in one of three states:
---
> When the user presses `<tt>Save</em>' the system first performs `Apply</tt>'
> (if it is enabled), then saves all option settings in the current calendar.  If
> no calendar is open, options are saved in the standard `<tt>Options</tt>' file.
> As with the `<tt>Apply</tt>' button, `<tt>Save</tt>' is initially disabled,
> becoming enabled when the user changes the options settings in one or more
> tabs, makes current a calendar with unsaved changes, or loads a new options
> file.  While execution of `<tt>Save</tt>' performs `<tt>Apply</tt>', the
> converse is not true.  Therefore, the settings in the options dialog exist in
> one of three states:
2083c998
< Section .
---
> Section 2.8.2.
2088c1003
< 6.21.  Hopefully Final Nukes for Options
---
> 6.18.  Hopefully Final Nukes for Options
2099c1014
< 6.22.  Nice Simplification to User Records
---
> 6.19.  Nice Simplification to User Records
2134c1049
< 6.23.  Overly Complicated Font Options Removed
---
> 6.20.  Overly Complicated Font Options Removed
2194c1109
< `<tt>Style</tt>' shown in Figure 347.
---
> `<tt>Style</tt>' shown in Figure 320.
2198c1113
< menus and are shown in Figure 347.
---
> menus and are shown in Figure 320.
2207c1122
< <p align=center> Figure 347:  Font options menu.  </p>
---
> <p align=center> Figure 320:  Font options menu.  </p>
2216c1131
< example, Figure 348 shows the user having entered values for the monthly-level
---
> example, Figure 321 shows the user having entered values for the monthly-level
2226c1141
< <p align=center> Figure 348:  Font option values selected for month-level
---
> <p align=center> Figure 321:  Font option values selected for month-level
2233c1148
< headers and labels, 10-point Times-Roman bold font is selected.  Figure 349
---
> headers and labels, 10-point Times-Roman bold font is selected.  Figure 322
2237c1152
< Figure 21.
---
> Figure 22.
2247c1162
< <p align=center> Figure 349:  Monthly view with user-selected fonts.  </p>
---
> <p align=center> Figure 322:  Monthly view with user-selected fonts.  </p>
2253c1168
< <em>Sketch of the remainder:</em>
---
> <em>Sketch of the remainder:
2256c1171
< Describe that the `<tt>Restore Defaults</tt>' puts everything back to the
---
> Describe that the `<tt>Restore Defaults</em>' puts everything back to the
2258c1173
< was but not actually go back to it for all displays, she does `<tt>Restore
---
> was but not actually go back to it for all displays, she does `Restore
2271c1186
< 6.24.  Some Serious Rationale for Options
---
> 6.21.  Some Serious Rationale for Options
2308c1223
< 6.25.  More Potential Rationale Fodder Cleansed from Rapidly Maturing Options
---
> 6.22.  More Potential Rationale Fodder Cleansed from Rapidly Maturing Options
2320c1235
< <em>4jan01 thot about 14dec00 thot:</em> Hmm, with movement of prefs to options
---
> <em>4jan01 thot about 14dec00 thot: Hmm, with movement of prefs to options
2322,2325c1237,1240
< prefs menu back, with `<tt>Edit Prefs</tt>' being tool prefs versus the top-
< level `<tt>Options</tt>' menu being data prefs.  I'm not sure the distinction
< is worth making, so I guess we have to think about this some more. 24jul02
< update -- screw this. --
---
> prefs menu back, with </em>`<tt>Edit Prefs</tt>'<em> being </em>tool<em> prefs
> versus the top-level `<tt>Options</em>' menu being </tt>data<em> prefs.  I'm
> not sure the distinction is worth making, so I guess we have to think about
> this some more. 24jul02 update -- screw this. --</em>
2362c1277
< 6.26.  Here's an Important Bit that Finally Got Handled
---
> 6.23.  Here's an Important Bit that Finally Got Handled
2381c1296
< 6.27.  The Real Deal for Options
---
> 6.24.  The Real Deal for Options
2518c1433
< 6.28.  Thinking about Options and Defaults
---
> 6.25.  Thinking about Options and Defaults
2562,2570c1477,1485
< <strong><em>[NOTE:</em></strong> The preceding two refs need to be fixed, and
< we need to figure out exactly what scheduling options include, in particular if
< they allow default values to be entered for each and every field.  Perhaps the
< easiest and most general solution is simply to have a `<tt>Set Defaults
< ...</tt>' button in each schedule options subtab.  This button brings up a
< standard dialoag for each type of scheduled item, with "DEFAULTS" somewhere
< prominently in the banner or title.  I think this is pretty cool, actually,
< because it will illustrate a nice general and orthogonal way to allow the user
< to set defaults.]
---
> <strong><em>[NOTE: The preceding two refs need to be fixed, and we need to
> figure out exactly what scheduling options include, in particular if they allow
> default values to be entered for each and every field.  Perhaps the easiest and
> most general solution is simply to have a `<tt>Set Defaults ...</em></strong>'
> button in each schedule options subtab.  This button brings up a standard
> dialoag for each type of scheduled item, with "DEFAULTS" somewhere prominently
> in the banner or title.  I think this is pretty cool, actually, because it will
> illustrate a nice general and orthogonal way to allow the user to set
> defaults.]</tt>
2575c1490
< 6.29.  ScheduledItem Inheritance Structure
---
> 6.26.  ScheduledItem Inheritance Structure
2598c1513
< 6.30.  A Feature Removal (!)
---
> 6.27.  A Feature Removal (!)
2621c1536
< 6.31.  More on Admin Decisions
---
> 6.28.  More on Admin Decisions
2677c1592
< <p align=center> Figure 350:  New group leader confirmation.  </p>
---
> <p align=center> Figure 323:  New group leader confirmation.  </p>
2686c1601
< 6.32.  Fodder Nuked from Admin Section
---
> 6.29.  Fodder Nuked from Admin Section
2704c1619
< 6.33.  Detailed Explanation of Recurring Date Change Restrictions
---
> 6.30.  Detailed Explanation of Recurring Date Change Restrictions
2723c1638
< 6.34.  Rationale for Changing and Deleting Meetings
---
> 6.31.  Rationale for Changing and Deleting Meetings
2733c1648
< 6.34.1.  From the end of the change and delete section
---
> 6.31.1.  From the end of the change and delete section
2774c1689
< 6.35.  From the task scheduling section
---
> 6.32.  From the task scheduling section
2797c1712
< appears pretty clearly to belong here instead.</em>
---
> appears pretty clearly to belong here instead.
2812c1727
< won't be the default behavior)
---
> won't be the default behavior)</em>
2817c1732
< 6.36.  Possible fodder for schedule meeting
---
> 6.33.  Possible fodder for schedule meeting
2821c1736
< Of note in Figure 91 is the "<tt>[2]</tt>" suffix in the `<tt>On</tt>' date
---
> Of note in Figure 92 is the "<tt>[2]</tt>" suffix in the `<tt>On</tt>' date
2833c1748
< 6.37.  Possible fodder for meeting change/delete section rationale
---
> 6.34.  Possible fodder for meeting change/delete section rationale
2873c1788
< happen until acceptance of change/delete notification.</em>
---
> happen until acceptance of change/delete notification.
2879,2881c1794,1796
< <em>Deal with the issue of what happens when the user has changed one or more
< data fields when the notification arrives.  It probably needs to be some kind
< of diff3 deal.</em>
---
> Deal with the issue of what happens when the user has changed one or more data
> fields when the notification arrives.  It probably needs to be some kind of
> diff3 deal.</em>
2927c1842
< Recurring, Location, Minutes </tt></strong>
---
> Recurring, Location, Minutes</tt></strong>
2965c1880
< form shown in Figure 351 appears.
---
> form shown in Figure 324 appears.
2978c1893
< Figure 351:  Changing or deleting a meeting as leader.
---
> Figure 324:  Changing or deleting a meeting as leader.
3015c1930
< 6.38.  Possible fodder from appt changing section
---
> 6.35.  Possible fodder from appt changing section
3037c1952
< 6.39.  (Weakly) Possible fodder from meeting item viewing
---
> 6.36.  (Weakly) Possible fodder from meeting item viewing
3046c1961
< Figure 137
---
> Figure 138
3056c1971
< then excutes `<tt>View Item</tt>'.  For example, Figure 352 shows the user
---
> then excutes `<tt>View Item</tt>'.  For example, Figure 325 shows the user
3061c1976
< 6.40.  Possible fodder from task item viewing
---
> 6.37.  Possible fodder from task item viewing
3072c1987
< 6.41.  Possible fodder in the area of external file viewing
---
> 6.38.  Possible fodder in the area of external file viewing
3080,3081c1995,1996
< <a href="file.html#New and Open">
< Section 2.8.2
---
> <a href="file.html#New, Open, and Close">
> Section .
3094c2009
< viewing minutes, such as a web browser.  Selection of such an external viewing
---
> viewing minutes, such as a WWW browser.  Selection of such an external viewing
3097c2012
< Section .
---
> Section 2.7.5.
3106c2021
< 6.42.  2aug01 -- Nixing the notificaiton enabling stuff (then not)
---
> 6.39.  2aug01 -- Nixing the notificaiton enabling stuff (then not)
3213c2128
< 6.43.  30jul01
---
> 6.40.  30jul01
3237c2152
< 6.44.  Axed from Meeting Scheduling
---
> 6.41.  Axed from Meeting Scheduling
3289c2204
< 6.45.  A Bit on Task Scheduling
---
> 6.42.  A Bit on Task Scheduling
3307c2222
< 6.46.  Documentation Section Ordering
---
> 6.43.  Documentation Section Ordering
3336c2251
< 6.47.  Relative Importance of Actual Tool versus Pedagogical Exmaple Goals
---
> 6.44.  Relative Importance of Actual Tool versus Pedagogical Exmaple Goals
3344c2259
< 6.48.  Filter Dialog Layout
---
> 6.45.  Filter Dialog Layout
3371c2286
< 6.49.  Refinement Example
---
> 6.46.  Refinement Example
3383c2298
< 6.50.  Alternatives for Multi-Window Mode Behavior
---
> 6.47.  Alternatives for Multi-Window Mode Behavior
3422c2337
< 6.51.  Precise Behavior of Next and Previous at the Item Level
---
> 6.48.  Precise Behavior of Next and Previous at the Item Level
3487c2402
< 6.52.  Misc Ideas from Relatively Early On
---
> 6.49.  Misc Ideas from Relatively Early On
3543c2458
< 6.53.  Start/End versus Start/Duration, Revisited
---
> 6.50.  Start/End versus Start/Duration, Revisited
3594c2509
< 6.54.  Start/End versus Start/Duration (Older Ideas)
---
> 6.51.  Start/End versus Start/Duration (Older Ideas)
3614c2529
< 6.55.  Big Issue about Factoring Options
---
> 6.52.  Big Issue about Factoring Options
3629c2544
< 6.56.  Old Remarks from the List Viewing Section
---
> 6.53.  Old Remarks from the List Viewing Section
3648c2563
< 6.57.  Filtering Issues
---
> 6.54.  Filtering Issues
3684c2599
< 6.58.  Back and Forth with the Monthly Recurring Functionality
---
> 6.55.  Back and Forth with the Monthly Recurring Functionality
3719c2634
< 6.59.  Maximum Date Range
---
> 6.56.  Maximum Date Range
3739c2654
< 6.60.  Lists
---
> 6.57.  Lists
3752c2667
< 6.61.  Canonical Modeling Form
---
> 6.58.  Canonical Modeling Form