14,42c14
< The scenarios in this section cover full details of file-related commands, some
< of which have been introduced in preceding sections.  There are two file
< command menus to be covered, one in the regular-user Calendar Tool and the
< other in the Calendar Tool Administration program.  Regular-user file commands
< are covered in Sections
< <a href="file.html#Files Used by the Calendar Tool">
< 2.8.1
< </a>
< through
< <a href="file.html#Exit">
< 2.8.7.
< </a>
< Administrator file commands are covered in
< <a href="file.html#Files Used by Calendar Tool Administration">
< 2.8.8
< </a>
< through
< <a href="file.html#Administrative Exit">
< 2.8.11.
< </a>
< The concluding Sections
< <a href="file.html#External Changes to Calendar Tool Files">
< 2.8.12
< </a>
< and
< <a href="file.html#Operating Environment Conventions">
< 2.8.13,
< </a>
< cover general topics relevant to both regular-user and administrative files.
---
> <em>Explain the deal with calendars, files, and their names up here.</em>
44c16
< <a name="Files Used by the Calendar Tool">
---
> <a name="New, Open, Close, and Close All">
46c18
< 2.8.1.  Files Used by the Calendar Tool
---
> 2.8.1.  New, Open, Close, and Close All
50,57c22
< There are two types of files used by the regular-user Calendar Tool -- calendar
< files and settings files.  Calendar files contain the following information:
< </p><p>
< <ul>
< <li>
< Scheduled items, i.e, appointments, meetings, tasks, and events
< <li>
< Calendar-specific settings, consisting of:
---
> Points to cover:
60,68c25,47
< categories (
< <a href="category-editing.html#cal-specific">
< Section 2.5.5
< </a>
< )
< <li>
< custom lists (
< <a href="list-viewing.html#cal-specific">
< Section 2.3.3.6
---
> Calendar file name <em>is</em> its name, hence what appears in the banner is
> the name of the file on which the Calendar is (to be) saved.  The "to be" part
> is for new calendars named "unnamed*" that have not yet been saved.  There's no
> direct way for the user to change the calendar name independent of its file
> name.  So the deal is that when the user Saves (with Save or Save-As) a new
> unnamed calendar, its "unnamed*" name appears as the default (highlighted) name
> for the file in the file-save dialog.
> <li>
> Each successive application of <tt>New</tt> with no intervening <tt>Save</tt>
> or <tt>Save As</tt> creates a calendar named "unnamed<em>N</em>" for
> <em>N</em> = 2 ... .
> <li>
> As seems to be the defacto standard, <tt>Save</tt> and <tt>Save As</tt> behave
> the same for a unnamed calendar, both putting up a Save-As dialog with the
> "unnamed*" name as the default highlighted name in the Save-As dialog.  I think
> AppleWorks (in contrast to Word) has the most consisten Save/Save-As behavior,
> so check it out before finalizing these requirements.
> </ul><font color=black>
> </p><p>
> <em>OK, OK -- </em> it looks like we've covered a lot of the ground about
> "current" in the new(ish)
> <a href="window-viewing.html#The Calendars List">
> Section 2.3.6.4.
70c49,51
< )
---
> </p><p>
> <em>Also need firm definition of "current", to whit:</em>
> <ol type=a>
72,76c53,54
< filter settings and custom filters (
< <a href="filtered-viewing.html#cal-specific">
< Section 2.3.4.3
< </a>
< )
---
> current "calendar" is the listed at the top of the `<tt>View Calendars</tt>'
> list, as determined ... fell the fuck off.
78,82c56,60
< options (
< <a href="options.html#cal-specific">
< Section 2.7
< </a>
< )
---
> Question: If the current window is not a calendar, then is there still a
> current calendar?  If so, it is presumably the calendar, if any, who's window
> is the topmost in the windows list.  But what of the banner in the menubar in
> this case?  Does it, potentially confusingly, list the name of the calendar
> most recently open?  OK, the next item addresses these questions.
84,88c62,63
< page setup and print settings (
< <a href="file.html#Page Setup and Print">
< Section 2.8.6
< </a>
< )
---
> OK, here's the deal about banner labeling, I think:
> <ol type=i>
90,94c65,74
< windowing mode (
< <a href="window-viewing.html#Windowing Mode">
< Section 2.3.6.2
< </a>
< )
---
> The menubar banner always contains the name of the calendar with the active or
> most recently active window (as defined by the order of windows in the
> `<tt>Windows</tt>' menu.
> <li>
> When calendar has been saved to a file, the calendar name is the same as its
> file name.
> <li>
> When a (new) calendar has not been saved to a file, its name is "<tt>no
> name</tt>" or "<tt>no name </tt>[<em>i</em>]" for <em>i</em> = 2 to the number
> of unsaved saved calendars.
96,119c76,77
< state of open windows (
< <a href="window-viewing.html#Viewing Multiple Windows and Multiple Calendars">
< Section 2.3.6
< </a>
< )
< </ul><font color=black>
< </ul><font color=black>
< All of this information is stored in a single calendar file for each calendar
< created by the user.  In this way, a single file encapsulates scheduled items
< and all other calendar-specific information that the user has defined for that
< calendar.  "For that calendar" means that each calendar has its own setting
< information, but no settings for other calendars that may be open at the same
< time.  In particular, the calendar-specific information for the state of open
< windows means the windows open for a particular calendar, not for  any other
< open calendars.  The calendar-specific nature of the different types of
< information is explained further in the sections cited parenthetically in the
< immediately preceding list.
< </p><p>
< The other type of Calendar Tool file contains settings that exist independent
< from any individual calendar.  These settings are used as the defaults when a
< new calendar is created and to record setting values that apply to a whole
< Calendar Tool session, not just an individual calendar.  The contents of a
< settings file are the following:
< <ul>
---
> When the
> </ol>
121c79,128
< Calendar-specific settings:
---
> Some more terminology: windows are "active"; calendars and files are "open".
> </ol>
> </p><p>
> Zero or more calendars may be open at any time.  <em>Need to be clear about the
> distinction between an open calendar versus an open calendar file.  I'm pretty
> sure it's pretty much the same distinction as a buffer and file in emacs,
> however it seems that with the requirments we've developed this far, a calendar
> doesn't get a name until it's stored to a file, i.e., the calendar's name is
> synonymous (and co-existent with) its file name.  This may actually point to a
> problem we've not yet (I don't think) adequately addressed, viz., having more
> than one unsaved calendar open at the same time, i.e., as the result of
> executing `File New' more than once without executing any saves for the new
> calendars.</em>
> </p><p>
> The name of the currently active file is listed in the banner of the command
> menubar.  When no calendar file is open, the file name in the banner is listed
> as "<tt>none</tt>" (or perhaps, per musing above, something like "no name" is
> better).  If the active calendar is that of another user, that user's name is
> displayed in place of the file name, in the form "<tt>OTHER USER:
> </tt><em><tt>user name</tt></em>".
> </p><p>
> When exactly one calendar file is open, its name is listed only in the banner
> of the command menubar, not in any other display window.  When two or more
> calendar files are open, the banner of every display window is augmented with
> the name of the file on which the displayed data are or will be stored.
> </p><p>
> The effect of multiple files on the windowing modes is as follows.  Every
> window says what file it's associated with.  The current file is defined as the
> file associated with the current window.  Whenever a different window becomes
> active, the current file is changed to the file of that window.  The banner of
> the menubar is changed as necessary dynamically.  The default per-level
> windowing mode applies separately to each
> </p><p>
> <em>22aug01 Note: The problem with every window having the file ID in the
> banner is that with the newish listing and filtering banner paraphenalia, the
> banners may get too crowded.  So, let's leave the filename out of the
> individual window banners and have it just be in the menubar banner, updating
> as noted in the preceding paragraph.</em>
> </p><p>
> <em>This paragraph is now WRONG.</em> Note that File Close and Window Close are
> different commands.  The former closes a file and all windows containing views
> of that file's data.  The latter closes only the current window and does not
> close the file (ever), even if the window is the last or only window open for
> (i.e., belonging to) a particular calendar.
> </p><p>
> <em>Mention that the solid/grey type deal applies to options loading, but
> instead of calendar file types shown in solid type, calendar option files are
> shown in solid type.</em>
> </p><p>
> Some `<tt>File Close</tt>' details:
124,128c131,132
< categories
< <li>
< custom lists
< <li>
< filter settings and custom filters
---
> closing a file-less calendar with unsaved changes (items or other) does offer-
> to-save-as
130,134c134,135
< options
< <li>
< page setup and print settings
< <li>
< windowing mode
---
> closing an filed calendar with unsaved changes (items or other) does offer-to-
> save
136c137,138
< state of open windows
---
> closing a calendar that is associated with a connected host warns that the
> connection will be terminated if the close proceeds.
138,149c140,147
< <li>
< Session-wide settings:
< <ul>
< <li>
< global options, described in
< <a href="options.html#Global Session-Wide Options">
< Section 2.7.6
< </a>
< <li>
< settings defined in the host-connection table, described in
< <a href="admin.html#Central Host Connections">
< Section 2.6.6.1.
---
> where "or other" is changes to categories, custom lists, custom filters,
> options, or in any pending scheduling dialog (maybe for the last of these, or
> maybe just have all pending scheduling quietly canceled).
> 
> <a name="Save, Save As, Save All">
> <h4>
> 2.8.2.  Save, Save As, Save All
> </h4>
150a149,151
> </p><p>
> 6aug03 Notes:
> <ul>
152,156c153,164
< the names of all open calendars, i.e., the names in the
< <tt>View-&gt;Calendars</tt> submenu described in
< <a href="window-viewing.html#The Calendars List">
< Section 2.3.6.4
< </a>
---
> If user sames when not connected, it obviously can't be written to the remote
> host.  When user reconnects, the writing to the host happens automatically as
> part of the connection process.
> <li>
> `<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.
> <li>
> Whether local-to-host copying is full or incremental is up to the implementors;
> the of the local-to-host copy operation is that the two calendars must be
> identical when the copy operation is complete, and some reasonable performance
> standards must be met, where we need to figure out what "reasonable" is.
158,172c166,209
< </ul><font color=black>
< The calendar-specific settings in a settings file are a separate version of the
< same information that is contained in each calendar.  Their existence in the
< settings file is for permanently recording settings used in new calendars, and
< to allow settings to be conveniently copied among different calendars.  The
< session-wide settings define information that applies across all calendars
< during a Calendar Tool execution session.
< <a href="file.html#Loading and Saving Settings">
< Section 2.8.5.
< </a>
< describes how settings files are saved and loaded.
< </p><p>
< Calendar and settings files may be stored in any file directory accessible to
< the user.  However, there is a specific directory called the <em>Calendar Tool
< user directory</em> used for the following purposes:
---
> </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"
> extenstion.
> </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.
> Operatioally, the user has her own local calendar as a file with a known name.
> On the remote host, the publically-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>
> When the user saves and the current calendar is connected to one or more
> (active) hosts the calendar is written to those hosts.
> </p><p>
> Note that `<tt>Save</tt>' and `<tt>Save As</tt>' are disabled when the current
> window is that of another user's or group's calendar.
> </p><p>
> <em>NOTE:</em> Given the new unified view of options as just another type of
> "other data", there should not be a speific offer-to-save for options that is
> fundamentally different that offer to save  other unsaved changes, such as
> categories or filters.  Therefore, as noted somewhere abouts, we can mention,
> but not really make special cases for, the kinds of unsaved changes that exist
> when the offer-to-save dialog comes up.
> </p><p>
> If the user exectues `<tt>File Save</tt>' for a calendar with unapplied aux
> data, the file-save dialog contains the message and radio buttons:
> <blockquote><pre>
>         "There are X changes for this calendar."
>          (x) Apply these changes before saving
>          ( ) Do not apply these changes before saving
> </pre></blockquote>
> If the user chooses the first radio option, the options are saved and the state
> of the otions for the saved calendar go from unsaved to saved, which will be
> reflected in the options dialog.  If the user chooses the secon radio option,
> </p><p>
> <em>Some `Save As' Details:</em>
175,180c212
< the location of the <tt>Settings</tt> file opened when the Calendar Tool starts
< up
< <li>
< the initial default directory for the `<tt>File->Open</tt>', <tt>File->Save
< As'</tt>, `<tt>File->Load Settings</tt>', and `<tt>File->Save Settings</tt>'
< dialogs
---
> dir names shown in regular black type
182,183c214
< the location of calendars named in the connection table, when the calendars
< have no leading pathname in the table
---
> all file names shown in grey, but still selectable
185,186c216
< the location where users presumably store their calendar files, though this is
< not required
---
> warning if OK pressed and extant fill would be overwritten
188,226d217
< </p><p>
< Whenever the Calendar Tool is invoked, it opens a single settings file to
< initialize the session-wide settings for the ensuing session.  The name of this
< file is "<tt>Settings</tt>", and it must be located in the Calendar Tool user
< directory at the time the `<tt>New</tt>' command is executed.  The user
< directory also has a default location, determined at installation time as
< described in
< <a href="installation.html#Installing the Calendar Tool">
< Section 2.15.1.
< </a>
< </p><p>
< The user can save additional copies of setting files, which are useful for
< copying settings from one calendar to another.  However, the user cannot change
< the name or location of the default file named "<tt>Settings</tt>" that the
< Calendar Tool opens initially at start up.  The user <em>can</em> change the
< location of her own Calendar Tool user directory, as an option.  Doing so is
< described in
< <a href="options.html#Global Session-Wide Options">
< Section 2.7.6.
< </a>
< </p><p>
< There are no naming requirements for calendar or settings files, other than the
< requirement for the fixed name and location of the "<tt>Settings</tt>" file.
< In particular, there are no requirements for filename extensions.  If the user
< chooses to give calendar files an extension, or if a particular operating
< environment recommends or requires that application files have known
< extensions, then the recommended extension for calendar and settings files is
< "<tt>.cal</tt>".  If this extension conflicts with that used by some other
< application, then the installation process can assign a particular extension to
< be used in a particular operating environment.
< </p><p>
< The internal data format of calendar and settings files is not specified in
< these requirements, and therefore left to the implementors.  In particular,
< there are no requirements that these files be editable as plain text or other
< external data format understandable to application programs other than the
< Calendar Tool.  It is required that the Calendar Tool be able to identify
< calendar and settings file as such, so they can be distinguished from each
< other and from other types of files.  The specific means to accomplish this
< identification is left to the implementors.
228c219
< <a name="New and Open">
---
> <a name="Save Config">
230c221
< 2.8.2.  New and Open
---
> 2.8.3.  Save Config
234,529c225,244
< When the user executes the `<tt>New</tt>' command in the `<tt>File</tt>' menu,
< the system responds by creating a new calendar and displaying its initial view.
< The default initial view is at the month level, with today's date highlighted.
< The user can change the default initial view for new calendars with the view
< option described in
< <a href="options.html#Global Session-Wide Options">
< Section 2.7.6.
< </a>
< </p><p>
< The name of a new calendar is "<tt>unnamed</tt>", until the user saves it with
< a different name.  Each successive application of <tt>New</tt>, with no
< intervening save, creates a calendar named "unnamed[<em>N</em>]", for
< <em>N</em> = 2 to the number of unnamed calendars.
< </p><p>
< A new calendar has no scheduled items except for system-defined events.  The
< user can change the visibility of system-defined events with the option setting
< described in
< <a href="options.html#Viewing Miscellaneous Options">
< Section 2.7.4.3.
< </a>
< The setting effects only whether system-defined events are visible in calendar
< displays, not their physical presence in the calendar.
< <a href="data-entry-details.html#System-Defined Events">
< Section 2.11.16
< </a>
< describes exactly what the system-defined events are.
< </p><p>
< The calendar-specific settings for each new calendar are those defined in the
< <tt>Settings</tt> file in the Calendar Tool user directory.  If there is no
< <tt>Settings</tt> file, settings have the built-in default values defined when
< the Calendar Tool is installed.  Table 15 shows the built-in default settings
< for all new calendars, in the absence of a <tt>Settings</tt> file.
< 
< <br>
< <br>
<                                      <hr>
< <br>
< 
< <a name="Table Built-in default settings for new calendars, absent a Settings file">
< <table align=center border=1 cellpadding=4>
<   <tr>
<     <td valign=top><strong>Type of setting</strong>
<     <td valign=top><strong>Initial value</strong>
<     <td valign=top><strong>Where illustrated</strong>
<   <tr>
<     <td valign=top>categories
<     <td valign=top>only holidays defined
<     <td valign=top>
< Figure
< <a href="appt-scheduling.html#Figure Initial categories menu">
< 7</a>
<   <tr>
<     <td valign=top>custom lists
<     <td valign=top>none defined
<     <td valign=top>
< Figures
< <a href="list-viewing.html#Figure Initial custom lists menu">
< 37</a>
< and
< <a href="list-viewing.html#Figure Custom list dialog">
< 38</a>
<   <tr>
<     <td valign=top>
< filter settings and
< <br>
< custom filters
<     <td valign=top>
< all items shown,
< <br>
< no custom filters defined
<     <td valign=top>
< Figures
< <a href="filtered-viewing.html#Figure Initial custom filters menu">
< 51</a>
< and
< <a href="filtered-viewing.html#Figure Filter definition dialog">
< 52</a>
<   <tr>
<     <td valign=top>options
<     <td valign=top>various
<     <td valign=top>
< figures in
< <a href="options.html#Options">
< Section 2.7</a>
< showing initial values in options-setting tabs
<   <tr>
<     <td valign=top>
< page setup and
< <br>
< print options
<     <td valign=top>
< platform-dependent defaults
<     <td valign=top>
< Figures
< <a href="file.html#Figure Page setup dialog">
< 303</a>
< and
< <a href="file.html#Figure Print dialog">
< 304</a>
<   <tr>
<     <td valign=top>
< windowing mode
<     <td valign=top>per-level
<     <td valign=top>
< Figure
< <a href="window-viewing.html#Figure Windowing mode submenu">
< 71</a>
<   <tr>
<     <td valign=top>
< state of open windows
<     <td valign=top>
< monthly view shown,
<     <td valign=top>
< Figure
< <a href="ui-overview.html#Figure Initial screen for a regular user">
< 1</a>
< </table>
< <p align=center> Table 15:  Built-in default settings for new calendars, absent
< a Settings file.
< <br>
< <hr>
< </p>
< 
< <br>
< 
< <p>
< </a>
< A new calendar becomes the current calendar, and the system performs all of the
< actions associated with making a calendar current.  These actions are described
< in
< <a href="window-viewing.html#making a calendar current">
< Section 2.3.6.4.
< </a>
< Before the user saves a new calendar, it has no associated file.  This affects
< the behavior of file-save operations, as discussed in
< <a href="file.html#Save, Save As, and Save All">
< Section 2.8.4.
< </a>
< </p><p>
< When the user selects the `<tt>Open</tt>' command in the `<tt>File</tt>' menu,
< the system displays a dialog of the form shown in Figure 287.
< 
< <br>
< <br>
< <hr>
< <a name="Figure File open dialog">
< <p align=center>
< <img src="images/file-open-dialog.gif">
< </p>
< <p align=center> Figure 287:  File open dialog.  </p>
< <hr>
< </a>
< <br>
< 
< The dialog reflects the state of the <tt>.CalendarTool</tt> directory after the
< user has saved two calendar files -- <tt>DepartmentCalendar</tt> and
< <tt>PersonalCalendar</tt>.  The `<tt>Directory</tt>' pulldown lists the
< components in the file path to the current working directory.  As explained in
< <a href="file.html#Files Used by the Calendar Tool">
< Section 2.8.1,
< </a>
< the default directory path for the file-open dialog is the Calendar Tool user
< directory for the current user.
< </p><p>
< The user may type the name of the file to open or select it from the scrollable
< list of file names.  When the user selects the pulldown arrow in the
< `<tt>Directory</tt>' field, the system displays the directory path, as shown in
< Figure 288.
< 
< <br>
< <br>
< <hr>
< <a name="Figure File open dialog with directory path displayed">
< <p align=center>
< <img src="images/file-open-dir-list.gif">
< </p>
< <p align=center> Figure 288:  File open dialog with directory path displayed.
< </p>
< <hr>
< </a>
< <br>
< 
< The user may select from the directory list to navigate to another directory,
< whereupon the system displays its files and subdirectories in the scrollable
< list.  The names of readable calendar files and readable subdirectories are
< shown in regular type in the file list.  The names of all other files are shown
< in grey type, indicating they are disabled for selection.  This means the user
< cannot open an unreadable calendar file, an unreadable directory, or any type
< of non-calendar file.  The user can load a settings file, but this is done with
< the `<tt>Load Settings</tt>' command, described in
< <a href="file.html#Loading and Saving Settings">
< Section 2.8.5
< </a>
< </p><p>
< The user may navigate into a subdirectory by selecting its name in the list and
< pressing `<tt>OK</tt>'.  The `<tt>OK</tt>' button is enabled when there are one
< or more subdirectories in the scrollable list.  When the user presses
< `<tt>OK</tt>' for a selected directory, the system displays its contents in the
< scrollable list.
< </p><p>
< When the user selects a specific file in the list, the system enters its name
< in the `<tt>File</tt>' field and enables the `<tt>OK</tt>' button, if it was
< not already.  When the user presses `<tt>OK</tt>', the system opens the
< selected file if it is not already open.  Once opened, the system displays the
< file's initial view, per its most recently saved settings, including in
< particular the option setting for its initial view window(s) (see
< <a href="options.html#Viewing Miscellaneous Options">
< Section 2.7.4.3
< </a>
< ).  The opened calendar becomes the current calendar, and the system performs
< all of the actions associated with making a calendar current, as described in
< <a href="window-viewing.html#making a calendar current">
< Section 2.3.6.4.
< </a>
< If the selected file is already open, pressing `<tt>OK</tt>' in the open dialog
< has the same effect as selecting the calendar's name in the
< `<tt>Calendars</tt>' list, described in
< <a href="window-viewing.html#The Calendars List">
< Section 2.3.6.4.
< </a>
< Double clicking on a calendar file name or directory name is a shortcut for
< selecting that name and pressing `<tt>OK</tt>'.
< </p><p>
< The user may type the name of a calendar file or directory in the
< `<tt>File</tt>' field.  As the user types, the scrollable list is scrolled to
< the alphabetic position in the list nearest but not after the place where the
< thus-far typed name appears or would appear in the list.  If the user types the
< complete name of an existing calendar file or readable directory, the effect is
< the same as when the user selects the name by clicking in the list.  If the
< user types the name of a non-existent file, the user may press `<tt>OK</tt>',
< whereupon the system creates a new file of the entered name.  This is
< effectively a short cut for executing `<tt>File->New</tt>' followed immediately
< by `<tt>File-Save</tt>'.
< </p><p>
< Since unreadable files, unreadable directories, and non-calendar files are
< disabled in the file-open dialog list, the user cannot select one of these.
< However, the user may type the name of an unreadable file, unreadable
< directory, or non-calendar file in the `<tt>File</tt>' field.  If the user does
< so, the system disables the `<tt>OK</tt>' button, since these files or
< directories cannot be opened.  If the user continues typing so that the name is
< not an unreadable calendar file, unreadable directory, or an existing non-
< calendar file, the system re-enables the `<tt>OK</tt>' button.
< </p><p>
< When a calendar is opened from a saved file, the name of the calendar is
< synonymous with its root filename.  The root filename is the name of the file,
< less any leading file path and less any filename extension.  For example, the
< name of the calendar stored in the file
< "<tt>/users/home/dcollins/.CalendarTool/DepartmentCalendar.cal</tt>" is
< "<tt>DepartmentCalendar</tt>".  The Calendar Tool provides no command to change
< the name of a calendar independent from its filename.  In particular, the only
< way the user can name an unnamed calendar is to save it to a file.
< </p><p>
< A new or just-opened calendar has today's date highlighted with a darkened
< border, as illustrated in
< <a href="structural-viewing.html#Viewing the Calendar at Different Levels">
< Section 2.3.1.
< </a>
< No date is selected as a viewing target, in the sense of selection defined in
< <a href="data-entry-details.html#Selecting Viewing Targets">
< Section 2.11.9.
< </a>
< </p><p>
< If an opened calendar is associated with one host in the host connection table
< and the `<tt>Auto-connect on file open</tt>' option is on, then the system
< initiates the host connection.  The connect operation proceeds as described in
< <a href="admin.html#Central Host Connections">
< Section 2.6.6.1,
< </a>
< as if the user had pressed the `<tt>Connect</tt>' button in the host connection
< table.  The auto-connect option is described in
< <a href="options.html#Administrative Options, for the Regular User">
< Section 2.7.5.
< </a>
< If an opened auto-connect calendar is associated with more than one host, the
< system displays the dialog shown in Figure 289.
< 
< <br>
< <br>
< <hr>
< <a name="Figure Select from multiple associated hosts">
< <p align=center>
< <img src="images/multiple-hosts-on-auto-connect.gif">
< </p>
< <p align=center> Figure 289:  Select from multiple associated hosts.  </p>
< <hr>
< </a>
< <br>
< 
< The <em><tt>name</tt></em> string is the name of calendar just opened.  The
< dialog informs the user that since the calendar is associated with more than
< one host, the user must run the `<tt>Admin->Connect</tt>' command in order to
< select the host to connect to.
< </p><p>
< The `<tt>New</tt>' and `<tt>Open</tt>' commands are always enabled in the file
< menu.  The following is a summary of the when the `<tt>OK</tt>' button is
< enabled in the file-open dialog:
---
> It's more than just the window config since it includes what files are open.  I
> think the easiest way to define exactly what save config does is as a script
> file.  This way we can deal with the tricky issue of having the dispaly 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 config that is absolute datewise,
> of 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.
> </p><p>
> 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:
532,539c247,268
< when the user has selected the name of a readable calendar file in the
< scrollable list
< <li>
< when the user has selected the name of a readable directory in the scrollable
< list
< <li>
< when the user has typed anything in the `<tt>File</tt>' field, except for the
< complete name of an unreadable calendar file or existing non-calendar file
---
> 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.
542,557c271,274
< As explained in
< <a href="window-viewing.html#Viewing Multiple Windows and Multiple Calendars">
< Section 2.3.6
< </a>
< zero or more new or existing calendars can be open at any time the Calendar
< Tool is running.  That section explains the way that the windows of multiply
< open calendars are managed and displayed.
< </p><p>
< Since `<tt>New</tt>' and `<tt>Open</tt>' are always enabled, the user may
< execute these commands at any time while the Calendar Tool is running.  This
< means that the user can have an unbounded number of calendars open.  If taken
< to an extreme, this could conceivably cause resource problems in some operating
< environments, as discussed in
< <a href="data-entry-details.html#Unbounded Limits on Calendar Size and Numbers">
< Section 2.11.31
< </a>
---
> This all seems pretty darn clean.  To be consistent, it seems with this scheme
> that the first like 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.
559c276
< <a name="Close and Close All">
---
> <a name="Print">
561c278
< 2.8.3.  Close and Close All
---
> 2.8.4.  Print
565,575c282,284
< The `<tt>Close</tt>' and `<tt>Close All</tt>' commands are enabled in the
< `<tt>File Menu</tt>' if there is at least one open calendar, disabled
< otherwise.  `<tt>Close</tt>' applies to the current calendar; `<tt>Close
< All</tt>' applies to all open calendars.
< </p><p>
< When the user selects the `<tt>Close</tt>' command, the system performs the
< following pre-close steps for the calendar to be closed, i.e., the current
< calendar:
< <ol type=a>
< <li>
< checks if the calendar has unsaved changes
---
> <em>Sketch of some ideas:  The print dialog should include at least the
> following options:
> <ul>
577c286
< checks if there are any pending edits in dialogs associated with the calendar
---
> start date
579,606c288
< checks if the calendar is connected to a central host computer
< </ol>
< Once these steps are completed satisfactorily, the system proceeds to perform
< the close operation.  Details follow.
< </p><p>
< For the first pre-close step, the system checks if the current calendar has any
< unsaved changes.  The precise definition of an unsaved change is given in
< <a href="file.html#Save, Save As, and Save All#unsaved-changes">
< Section 2.8.4.
< </a>
< If there are one or more unsaved changes, the system displays the dialog shown
< in Figure 290.
< 
< <br>
< <br>
< <hr>
< <a name="Figure Offer to save calendar before closing">
< <p align=center>
< <img src="images/offer-to-save-dialog.gif">
< </p>
< <p align=center> Figure 290:  Offer to save calendar before closing.  </p>
< <hr>
< </a>
< <br>
< 
< The <em><tt>name</tt></em> string is the name of the current calendar to be
< closed.  If the user presses `<tt>Yes</tt>', the system proceeds as follows:
< <ol type=a>
---
> end date
608,648c290,302
< If the calendar to be closed has not yet been saved to a file, the system
< displays the file save-as dialog shown in
< <a href="file.html#Figure Initial save dialog for a not-yet-saved calendar">
< Figure 293.
< </a>
< If the user confirms a legal save-as operation in that dialog, the system
< proceeds to the next pre-close step.  If the user presses `<tt>Cancel</tt>' in
< the save-as dialog, the system returns to the offer-to save dialog, where the
< user may press `<tt>No</tt>' or `<tt>Cancel</tt>' (or `<tt>Yes</tt>' if she
< wants to return again to the save-as dialog).
< <li>
< If the calendar to be closed has previously been saved to a file, the system
< performs the file save operation described in
< <a href="file.html#Save, Save As, and Save All">
< Section 2.8.4,
< </a>
< and proceeds to the next pre-close step.
< </ol>
< If the user presses `<tt>No</tt>' in the offer-to-save dialog, the system
< proceeds to the next pre-close step without saving the calendar, thereby losing
< any unsaved changes.  If the user presses `<tt>Cancel</tt>' in the offer-to-
< save dialog, the system cancels the close operation entirely, without saving,
< without performing further pre-close steps, and leaving the calendar open and
< unchanged.  The system also removes both the offer-to-save and file-close
< dialogs from the screen.
< </p><p>
< If the calendar to be closed has no unsaved changes, the system proceeds to the
< next pre-close step, without displaying the offer-to-save dialog.  Calendars
< with no unsaved changes are those that have been saved prior to close, as well
< as other-user and group calendars, since the latter two types of calendar
< cannot be changed.
< </p><p>
< For the second pre-close step, the system checks if there are any pending edits
< in calendar-specific, non-modal editing dialogs for the calendar to be closed.
< <a href="data-entry-details.html#Calendar Specificity and Modality of Dialog Windows">
< Section 2.11.32
< </a>
< defines which Calendar Tool dialogs are of this type.  A pending edit is any
< unconfirmed or unapplied change the user has made in one or more of these
< dialogs.  if there any such pending edits, the system displays the dialog shown
< in Figure 291.
---
> 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>
> <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>
650,659c304,307
< <br>
< <br>
< <hr>
< <a name="Figure Warning when there are unconfirmed or unapplied dialog edits">
< <p align=center>
< <img src="images/closing-calendar-with-dialog-edits.gif">
< </p>
< <p align=center> Figure 291:  Warning when there are unconfirmed or unapplied
< dialog edits.  </p>
< <hr>
---
> <a name="Exit">
> <h4>
> 2.8.5.  Exit
> </h4>
661,673d308
< <br>
< 
< If the user answers `<tt>Yes</tt>' in the pending-edits dialog, the system
< discards any pending edits, cancels all pending dialogs, and removes the
< dialogs from the screen.  When the system responds to the `<tt>Yes</tt>'
< response or if the pending-edits dialog was not displayed, the system proceeds
< to the last pre-close step.
< </p><p>
< If the user answers `<tt>No</tt>' in the pending-edits dialog, the system
< cancels the close operation without performing the last pre-close step, leaves
< the calendar open, and leaves all pending edit dialogs open and unchanged.  If
< the calendar had been saved as a result of the first pre-close step, it remains
< saved, i.e., the save operation is not undone.
675,680c310,322
< For the third and final pre-close step, the system checks if the calendar being
< closed is currently connected to a central host computer (see
< <a href="admin.html#Central Host Connections">
< Section 2.6.6.1
< </a>
< ).  If so, the system displays the dialog shown in Figure 292.
---
> 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 notiications?
682,693c324,330
< <br>
< <br>
< <hr>
< <a name="Figure Warning when closing calendar is connected to a central host">
< <p align=center>
< <img src="images/closing-connected-calendar.gif">
< </p>
< <p align=center> Figure 292:  Warning when closing calendar is connected to a
< central host.  </p>
< <hr>
< </a>
< <br>
---
>             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.
695,753d331
< If the user answers `<tt>Yes</tt>' in the connected-to-host dialog, the system
< disconnects the host and updates the host connection table accordingly, as
< described in
< <a href="admin.html#Central Host Connections">
< Section 2.6.6.1.
< </a>
< When the system responds to the `<tt>Yes</tt>' response, or if the connected-
< to-host dialog was not displayed, the system proceeds to complete the close.
< </p><p>
< If the user answers `<tt>No</tt>' in the connected-to-host dialog, the system
< cancels the close operation, leaving the calendar open and connected.  If the
< calendar had been saved as a result of the first pre-close step, it remains
< saved, i.e., the save operation is not undone.  If any pending-edit dialogs
< where canceled and closed as a result of the second pre-close step, the dialogs
< remain so.
< </p><p>
< When the pre-close steps have been completed without a cancellation, the system
< completes the close operation by closing the current calendar, removing its
< name from the <tt>Calendars</tt> list, and removing all windows associated with
< the calendar from the screen, including any remaining dialogs (those without
< pending edits).
< <a href="window-viewing.html#The Calendars List">
< Section 2.3.6.4
< </a>
< describes details of the <tt>Calendars</tt> list, calendar-to-window
< association, and changing the current calendar.  When the close operation has
< been completed or canceled, the system removes all close-related dialogs from
< the screen.
< </p><p>
< When the user selects `<tt>Close All</tt>' in the `<tt>File</tt>' menu, the
< system executes a close operation for all open calendars, in the same manner as
< described above for `<tt>Close</tt>'.  The offer-to-save dialog is displayed in
< turn, as necessary, prior to closing each calendar.  If the user presses
< `<tt>Cancel</tt>' in the offer-to-save dialog for any calendar, the system
< cancels the close operation for that calendar and all remaining open calendars.
< `<tt>Cancel</tt>' does not affect any already-closed calendars for which the
< user previously answered `<tt>Yes</tt>' or `<tt>No</tt>' in the offer-to-save
< dialog; these calendars remain closed.  The pending-edits and connected-to-host
< dialogs are also displayed in turn, as necessary.  Since there is no
< `<tt>Cancel</tt>' button in the pending-edits or connected-to-host dialogs, the
< '<tt>Close All</tt>' operation proceeds with the next calendar to be closed,
< whatever the user's decision is in either of these warning dialogs.  A calendar
< remains open if the user answers`<tt>No</tt>' in either the pending-edits or
< connected-to-host dialog.
< </p><p>
< When the system completes a `<tt>Close</tt>' or `<tt>Close All</tt>' for the
< last open calendar, it closes the `<tt>Find</tt>' dialog and `<tt>Goto
< Date</tt>' dialog, if either or both are open.  As described in
< <a href="data-entry-details.html#Calendar Specificity and Modality of Dialog Windows">
< Section 2.11.32,
< </a>
< these two dialogs can be open only when at least one calendar is open.
< </p><p>
< Closing the last open calendar does not automatically exit the Calendar Tool.
< As explained in
< <a href="window-viewing.html#The Calendars List">
< Section 2.3.6.4,
< </a>
< the Calendar Tool runs with zero or more calendar files open.
755c333
< <a name="Save, Save As, and Save All">
---
> <a name="Save As and Load in Editing Dialogs">
757c335
< 2.8.4.  Save, Save As, and Save All
---
> 2.8.6.  Save As and Load in Editing Dialogs
761,776c339,344
< A new calendar is not associated with a file until it is saved for the first
< time.  For new not-yet-saved calendars, the `<tt>Save</tt>' and `<tt>Save
< As</tt>' commands have exactly the same effect.  When the user selects either
< of these commands for a not-yet-saved calendar, the system displays the dialog
< shown in Figure 293.
< 
< <br>
< <br>
< <hr>
< <a name="Figure Initial save dialog for a not-yet-saved calendar">
< <p align=center>
< <img src="images/file-save-new-dialog.gif">
< </p>
< <p align=center> Figure 293:  Initial save dialog for a not-yet-saved calendar.
< </p>
< <hr>
---
> <em>NOTE:</em> Adjust the following fodder pulled from the options section to
> apply uniformly to all four types of aux data.  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#Non-Modal, Calendar-Specific Dialogs">
> Section 2.11.26.
778,818d345
< <br>
< 
< This dialog shows the initial state of the <tt>.CalendarTool</tt> directory
< before the user has saved any files.  The <tt>Settings</tt> file is shown in
< the scrollable list, since it is installed by default during the normal
< Calendar Tool installation process, described in
< <a href="installation.html#Installing the Calendar Tool">
< Section 2.15.1.
< </a>
< The system does not pre-enter "<tt>unnamed</tt>" in the `<tt>File</tt>' field,
< to discourage the user from naming a calendar "<tt>unnamed</tt>".  The system
< does not however prevent a recalcitrant user from doing so.
< </p><p>
< As in the file-open dialog, the user may navigate to another directory by
< selecting from the `<tt>Directory</tt>' pulldown list and by selecting
< directory names in the scrollable list.  To save to a file, the user types its
< name in the `<tt>File</tt>' field.  The system enables the `<tt>OK</tt>' button
< when the user begins typing, and it remains enabled unless the user does one of
< the following:
< <a name="save-disabled">
< <ul>
< </a>
< <li>
< erases all typing
< <li>
< enters the name of a currently open calendar file
< <li>
< enters the name of an unwritable calendar file
< <li>
< enters the name of an unreadable directory
< <li>
< enters the name of an existing non-calendar file
< </ul><font color=black>
< The system disallows saving in any of these circumstances (only the first of
< which happens to be possible in
< <a href="file.html#Figure Initial save dialog for a not-yet-saved calendar">
< Figure 293
< </a>
< ).  If the user continues typing to change these circumstances, the system
< re-enables the `<tt>OK</tt>' button.  The system does allow saving a calendar
< into an existing calendar file, which case is described shortly.
820,821c347,351
< Figure 294 shows the user having entered the name "<tt>DepartmentCalendar</tt>"
< for saving.
---
> 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 285.
826c356,360
< <a name="Figure Initial save dialog filled in">
---
> <a name="Figure Options save-as dialog">
> <p align=center>
> <img src="images/options-save-as-dialog.gif">
> </p>
> </pre>
828c362
< <img src="images/file-save-new-dialog-filled-in.gif">
---
> Figure 285:  Options save-as dialog.
830d363
< <p align=center> Figure 294:  Initial save dialog filled in.  </p>
835,853c368,372
< When the user presses `<tt>OK</tt>', the system saves the entire contents of
< the calendar onto the named file.  All scheduled items and all calendar-
< specific settings are saved.  After completing the save, the system removes the
< save dialog from the screen.  If the user enters the name of an existing
< calendar file and presses `<tt>OK</tt>', the system asks for overwrite
< confirmation, as described below.
< </p><p>
< When saving a new calendar onto a new file, it is not possible for the saved-to
< calendar to yet be connected to a central host computer, since to make such a
< connection the calendar must already have been open.  Hence in this case of
< saving, no copying to a central host is ever performed.  Such copying is
< performed when saving an existing connected calendar, as described shortly.
< </p><p>
< When the current calendar is already associated with a file, the
< `<tt>Save</tt>' and `<tt>Save As</tt>' commands differ.  The `<tt>Save</tt>'
< command is enabled whenever the current calendar is associated with a file, and
< the calendar has unsaved changes.
< <a name="unsaved-changes">
< A calendar has unsaved changes when the user has performed one or more of the
---
> 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 2.15.5.
855,904c374,375
< following actions since the file was opened or the last confirmed save
< operation, whichever has occurred most recently:
< <ol type=a>
< <li>
< confirmed any scheduling or category-changing command in the
< `<tt>Schedule</tt>' menu
< <li>
< confirmed any change to custom lists
< <li>
< confirmed any change to filter settings or custom filters
< <li>
< executed any command in the view menu that changes the state of the display
< screen
< <li>
< changed the windowing mode
< <li>
< moved, iconified, or closed any window associated with the calendar
< <li>
< applied any option changes
< <li>
< confirmed any change to page setup or print settings
< <li>
< loaded settings
< </ol>
< If the user undoes any of these actions such that the state of the calendar
< returns to the same state as most recently saved, then the calendar no longer
< has unsaved changes.  The "state" of the calendar is defined as the values of
< all scheduled items and calendar-specific settings.  It is noteworthy that the
< definition of unsaved change includes any and all actions that change scheduled
< items <em>or</em> calendar-specific settings.
< </p><p>
< When the user selects the enabled `<tt>Save</tt>' command in the
< `<tt>File</tt>' menu, the system saves the scheduled items and settings for the
< current calendar on the file associated with the calendar.  If the file is
< connected to a central host computer, the system also copies the calendar file
< to the central host, as explained in
< <a href="admin.html#copy to host on save">
< Section 2.6.6.1.
< </a>
< All scheduled items and calendar-specific settings are copied to the host.  If
< a calendar is associated with a central host but not connected to it, the save
< operation does perform the copy.
< </p><p>
< The `<tt>Save As</tt>' command is enabled in the `<tt>File</tt>' menu whenever
< the current calendar is not that of another user or group.  `<tt>Save As</tt>'
< is enabled whether or not the current calendar has unsaved changes.  When the
< user selects `<tt>Save As</tt>' for a new calendar, the system displays the
< dialog shown in
< <a href="file.html#Figure Initial save dialog for a not-yet-saved calendar">
< Figure 293,
---
> <a href="file.html#Save, Save As, Save All">
> Section 2.8.2.
906c377,379
< and the system actions are those described for that figure.
---
> 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.
908,909c381,384
< When the user executes `<tt>Save As</tt>' for a calendar that is associated
< with a file, the system displays the dialog shown in Figure 295.
---
> To save options to a file, the user enters the filename in the save-as dialog
> and presses `<tt>OK</tt>'.  For example, Figure 286 shows the user having
> entered the file name "<tt>PersonalOptions</tt>" as the location to which options
> are saved.
914c389
< <a name="Figure File save-as dialog">
---
> <a name="Figure Saving options to a PersonalOptions file">
916c391
< <img src="images/file-save-as-dialog.gif">
---
> <img src="images/options-save-as-dialog-filled-in.gif">
918,964d392
< <p align=center> Figure 295:  File save-as dialog.  </p>
< <hr>
< </a>
< <br>
< 
< This is the same dialog as shown in
< <a href="file.html#Figure Initial save dialog for a not-yet-saved calendar">
< Figure 293,
< </a>
< except the banner is "<tt>Save Calendar As</tt>" instead of "<tt>Save New
< Calendar</tt>".  Figure 295 shows the state of the <tt>.CalendarTool</tt>
< directory after the user has saved two calendars.  The names of writable
< unopened calendar files and readable subdirectories are shown in regular type
< in the list.  The names of all other files are shown in grey type, indicating
< they are disabled for selection.  This means that the user cannot save to an
< already open calendar file, an unwritable calendar file, or to any type of
< existing non-calendar file.  The user can navigate through directories as
< explained above.  The user can navigate to a readable but unwritable directory
< to see the files there.  The existence of a writable calendar file in an
< unreadable or unwritable directory renders the file itself unwritable.
< </p><p>
< For a calendar that has an associated file, the purpose of `<tt>Save As</tt>'
< is to save a copy of the calendar on a file other than the one with which the
< calendar is already associated.  To perform the save, the user types the name
< of the desired file in the `<tt>File</tt>' field, or selects the name of an
< existing calendar file in the scrollable list.  The system enables the
< `<tt>OK</tt>' button when the user begins typing, and it remains enabled except
< under the circumstances enumerated
< <a href="#save-disabled">
< above
< </a>
< after
< <a href="file.html#Figure Initial save dialog for a not-yet-saved calendar">
< Figure 293.
< </a>
< When the user selects an enabled name in the list, the system enters the name
< in the `<tt>File</tt>' field.
< </p><p>
< To save the calendar onto a new or existing calendar file, the user presses
< `<tt>OK</tt>'.  If the calendar to be saved is connected to a central host, the
< system displays warning shown in Figure 296 before completing the save-as
< operation.
< 
< <br>
< <br>
< <hr>
< <a name="Figure Save-as operation will cause disconnect">
966c394
< <img src="images/file-save-as-disconnect.gif">
---
> Figure 286:  Saving options to a PersonalOptions file.
968d395
< <p align=center> Figure 296:  Save-as operation will cause disconnect.  </p>
973,993c400,403
< The <em><tt>name</tt></em> string is the name of the host to which the current
< (pre-save-as) calendar is connected.  If the user presses `<tt>OK</tt>' in the
< disconnect warning dialog, the system disconnects the calendar under its
< current name and proceeds with the save-as.  As the dialog message explains,
< the user must run the `<tt>Admin->Connect</tt>' command to re-connect the
< calendar under its new name.  If the user presses `<tt>Cancel</tt>', the system
< cancels the save-as operation, leaving the current calendar connected and
< otherwise in its pre-save-as state.
< </p><p>
< To proceed with the save-as, the system checks if the file to be saved to
< exists.  If it does not exist, the system completes the operation by saving a
< complete copy of the current calendar to the new file.  If the saved calendar
< had unsaved changes, those changes are saved in the new saved-to file, but not
< in the original file.  The original file remains in the same state as it was
< prior to `<tt>Save As</tt>' being executed.  The saved calendar remains the
< current calendar, but with the new name instead of the old name.  The system
< changes the name of the calendar in all of the contexts in which the original
< name appears.  These contexts are described in
< <a href="window-viewing.html#Viewing Multiple Windows and Multiple Calendars">
< Section 2.3.6.
< </a>
---
> The `<tt>Save As</tt>' command does not execute `<tt>Apply</tt>' or `<tt>Save</tt>', it
> only saves a coy of the curent options settings on the selected file.  The
> applied and saved states of options are unchanged after execution of `<tt>Save
> As</tt>'.
995,996c405,408
< When the user executes `<tt>Save As</tt>' to an existing calendar file, the
< system displays the warning dialog shown in Figure 297.
---
> 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 287.
1001c413
< <a name="Figure Confirm overwrite of an existing calendar file">
---
> <a name="Figure Options load dialog">
1003c415
< <img src="images/file-save-as-overwrite.gif">
---
> <img src="images/options-load-dialog.gif">
1005c417,419
< <p align=center> Figure 297:  Confirm overwrite of an existing calendar file.
---
> </pre>
> <p align=center>
> Figure 287:  Options load dialog.
1011,1039c425,428
< If the user presses `<tt>OK</tt>', the system proceeds with the save, fully
< overwriting the previous contents of the file.  The states of the original and
< saved-to files are as described above for when `<tt>Save As</tt>' saves to a
< new file.  The system also changes the name of the current calendar in the same
< way as for `<tt>Save As</tt>' to a new file.  If the user presses
< `<tt>Cancel</tt>' the system does not perform the save, returning to the
< `<tt>Save As</tt>' dialog where the user can enter a different file name.  In
< either case, the system removes the overwrite warning dialog.
< </p><p>
< The user may save a new or existing calendar to a file that is listed in the
< host connection table (in the `<tt>Calendar</tt>' column).  In such a case, the
< system does not initiate a connection to the associated host as a result of the
< save.  This is the case even if the option `<tt>Auto-connect on file open</tt>'
< is on.  This option only applies to `<tt>File->Open</tt>', not to `<tt>Save
< As</tt>'.  To connect to a host of a saved-to calendar, the user must execute
< the `<tt>Admin->Connect</tt>' command.
< </p><p>
< The user can type or select the calendar's current name in the save-as dialog,
< although this defeats the ostensible purpose of the `<tt>Save As</tt>' command.
< If the user does so and presses `<tt>OK</tt>', the system saves the calendar
< onto the file with which is currently associated, in the same manner as if the
< user had executed the `<tt>Save</tt>' command.
< </p><p>
< When the user selects `<tt>Save All</tt>' in the `<tt>File</tt>' menu, the
< system executes a `<tt>Save</tt>' for all calendars with unsaved changes.  If
< any of the calendars is not yet saved to a file, and the user presses
< `<tt>Cancel</tt>' in the save-new-calendar dialog (
< <a href="file.html#Figure Initial save dialog for a not-yet-saved calendar">
< Figure 293
---
> 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, Open, Close, and Close All">
> Section 2.8.1
1041c430,431
< ), the system cancels the save for that calendar only.
---
> covers further details on the format and use of file opening (i.e., loading)
> dialogs, including the directory browsing list and file-type validation.
1043,1086c433,439
< The following is a summary of the enabled/disabled states of the save commands:
< <ol type=a>
< <li>
< `<tt>Save</tt>' is enabled when the current calendar is new and has no
< associated file, i.e., it has not yet been saved.  Save is enabled
< unconditionally for a new calendar, even if the user has performed no changes
< to it since it was created.  In this way, the user can save a completely empty
< new calendar.
< <li>
< `<tt>Save</tt>' is also enabled when the current calendar has an associated
< file which has unsaved changes.
< <li>
< `<tt>Save As</tt>' is enabled whenever at least one calendar is open, and the
< current calendar is not that of another user or group.  `<tt>Save As</tt>' is
< enabled whether or not the current calendar has unsaved changes.
< </ol>
< `<tt>Save</tt>' and `<tt>Save As</tt>' are disabled otherwise.
< </p><p>
< None of the save operations affects the state of pending edit dialogs.
< Unconfirmed or unapplied edits are not saved, and the states of all dialogs
< associated with a calendar are unchanged by a save of the calendar.
< </p><p>
< As described above, the system attempts to disallow saving to an unwritable
< calendar file.  However, if the user changes the permissions of a calendar file
< externally, before or during Calendar Tool execution, it is possible for the
< user to execute a `<tt>Save</tt>' or `<tt>Save As</tt>' to an unwritable file.
< The circumstances where this can happen are described in
< <a href="file.html#External Changes to Calendar Tool Files">
< Section 2.8.12.
< </a>
< When the user does execute a `<tt>Save</tt>' or `<tt>Save As</tt>' to an
< unwritable file, the system responds with an appropriate error message, as
< described in
< <a href="error-conditions.html#File Errors">
< Section 2.12.11.
< </a>
< If this error is reported for a file during a `<tt>Save All</tt>' sequence, the
< system continues with the `<tt>Save All</tt>' after the user dismisses the
< error message.
< 
< <a name="Loading and Saving Settings">
< <h4>
< 2.8.5.  Loading and Saving Settings
< </h4>
---
> 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
1088,1148c441,444
< </p><p>
< As outlined above, Calendar Tool settings are stored in the standard
< <tt>Settings</tt> file, as well as in other named files in which the user
< chooses to save them.  The commands to save and load settings allow the user to
< bundle different settings to be used in different types of calendars.  For
< example, the user can define a collection of work-related settings, save them
< in a settings file, and then load them for use in work-related calendars.
< Users or administrators can share such settings files with other users, so that
< a particular user community has a common collection of settings.
< Administrators can create useful settings files for inclusion when the Calendar
< Tool is installed, as described in
< <a href="installation.html#Installing the Calendar Tool">
< Section 2.15.1
< </a>
< </p><p>
< Since calendar files contain their own calendar-specific settings, the sharing
< functionality provided by settings files could be accomplished in part by
< sharing just calendar files themselves.  However, settings files provide the
< advantage of being able to copy settings from one calendar file to another,
< without adding or deleting scheduled items in either calendar.  Also, since
< calendar files do not contain session-wide settings, the only way to save and
< load these are through independent settings files.
< </p><p>
< The system loads the standard <tt>Settings</tt> file under the following
< circumstances:
< <ol type=a>
< <li>
< when the user starts up the Calendar Tool from the operating environment
< <li>
< when the user invokes the `<tt>File->Load Settings</tt>' command and selects
< the <tt>Settings</tt> file to be loaded
< </ol>
< When the system loads <tt>Settings</tt> at start up, it uses the session-wide
< component of the settings file to initialize global options, initialize the
< host connection table, and to determine which calendars to open at start-up.
< The initialized global options are those used in the ensuing session of the
< Calendar Tool, and those presented to the user when she executes the
< `<tt>Options->Global</tt>' command.  The initialized host connection table is
< that which is used during the ensuing session, and that which is presented to
< the user when she runs the `<tt>Admin->Connect</tt>' command.  The list of
< which calendars, if any, to open at start-up is in the `<tt>names of open
< calendars</tt>' component of the settings file.  Further discussion of the
< Calendar Tool start-up procedure is in
< <a href="installation.html#Invoking the Calendar Tool">
< Section 2.15.2.
< </a>
< </p><p>
< The system does not use the calendar-specific component of the
< <tt>Settings</tt> file at start-up.  Rather, for each calendar it opens at
< start-up, it uses the calendar-specific settings stored in that calendar's
< file.  This includes the calendar-specific settings for viewing options and the
< setting for the `<tt>state of open windows</tt>' for each calendar.  These
< settings determine which windows are opened for each start-up calendar.  The
< calendar-specific component of the <tt>Settings</tt> file is used when the user
< creates a new file, as described in
< <a href="file.html#New and Open">
< Section 2.8.2.
< </a>
< </p><p>
< When the user runs the `<tt>Load Settings</tt>' command in the `<tt>File</tt>'
< menu, the system displays the dialog shown in Figure 298.
---
> ).
> If the user is not so connected, the `<tt>Load from central host</tt>' checkbox is
> disabled.  Figure 288 shows the user having selected to load from the
> "<tt>Personal Options</tt>" file.
1153c449
< <a name="Figure Load-settings dialog">
---
> <a name="Figure Loading from the Personal Options file">
1155c451
< <img src="images/load-settings-dialog.gif">
---
> <img src="images/options-load-dialog-filled-in.gif">
1157,1196d452
< <p align=center> Figure 298:  Load-settings dialog.  </p>
< <hr>
< </a>
< <br>
< 
< The user may select via checkboxes which parts of a settings file to load, and
< from which file to perform the load.  All of the checkboxes are on by default.
< When the filter settings checkbox is on, the system automatically checks and
< disables the categories checkbox.  This is because custom filter definitions
< may be defined in terms of calendar-specific categories.  If the user unchecks
< the filters checkbox, the categories checkbox is enabled for independent
< checking or unchecking.
< </p><p>
< If the user invokes `<tt>Load Settings</tt>' when there is no current open
< calendar, the system unchecks and disables all of the calendar-specific
< checkboxes under `<tt>For the current calendar</tt>'.  In this case, only the
< settings for global options and the host connection table can be loaded.  If
< the user invokes `<tt>Load Settings</tt>' when one or more calendars is
< connected, the `<tt>host connection table</tt>' checkbox is unset and disabled.
< This means that the host connection table cannot be loaded from settings when
< there any active connections.
< </p><p>
< The default file in the load-settings dialog is the standard <tt>Settings</tt>,
< in the Calendar Tool user directory.  The dialog shown Figure 298 reflects the
< user having previously saved two settings files in addition to the pre-
< installed "<tt>Settings</tt>".  Only Calendar Tool settings files and
< directories are enabled in the scrollable file list.  The user can type,
< navigate, and select in the dialog in the same manner as described for the
< `<tt>Open</tt>' dialog in
< <a href="file.html#Figure File open dialog">
< Figure 287.
< </a>
< </p><p>
< Figure 299 shows the user having chosen to load a subset of the settings stored
< the file "<tt>OfficeSettings</tt>".
< 
< <br>
< <br>
< <hr>
< <a name="Figure Load-settings dialog filled in">
1198c454
< <img src="images/load-settings-dialog-filled-in.gif">
---
> Figure 288:  Loading from the Personal Options file.
1200d455
< <p align=center> Figure 299:  Load-settings dialog filled in.  </p>
1205,1206c460,461
< When the user presses `<tt>OK</tt>', the system displays the confirmation
< dialog shown in Figure 300.
---
> Figure 289 shows the case where the user selects to load from the central
> host.
1211c466
< <a name="Figure Confirm load settings">
---
> <a name="Figure Loading options from the Calendar Tool central host">
1213c468
< <img src="images/load-settings-confirm.gif">
---
> <img src="images/options-load-from-central.gif">
1215,1384d469
< <p align=center> Figure 300:  Confirm load settings.  </p>
< <hr>
< </a>
< <br>
< 
< The dialog explains that loading settings may cause changes to the calendar and
< its display windows, and that changes will be made without further
< confirmation.  The dialog further explains that any currently unconfirmed or
< unapplied settings edits will be canceled.  What this means precisely is that
< if the user has edited by not applied or confirmed changes to settings that are
< being loaded, the dialogs in which the edits have been performed are canceled.
< This cancellation applies only to dialogs for settings checked on in the load-
< settings dialog.  Edit dialogs for unchecked settings are not canceled.  For
< example, if the user has edited a category definition but not yet confirmed the
< edits, and the `<tt>categories</tt>' checkbox is on, the system cancels the
< categories editing dialog and loads the settings.  On the other hand, if the
< user has unapplied edits to calendar-specific options, but the
< `<tt>options</tt>' checkbox is off in the load-settings dialog, then the
< options dialog is unaffected by the settings load, and the dialog remains open
< with the still unapplied edits.
< </p><p>
< If the users answers `<tt>OK</tt>' in the load-settings dialog, the system
< performs the following actions:
< <ol type=a>
< <li>
< copies the values for calendar-specific settings from the settings file into
< the current calendar; this is done for the settings with the checkbox turned
< on; unchecked settings values are not copied, leaving them unchanged in the
< current calendar
< <li>
< confirms and applies all setting changes
< <li>
< performs all processing that results from changed, added, or deleted calendar-
< specific settings
< <li>
< re-initializes the session's global options and host table from the settings
< file; this is performed when the associated checkbox is on; if either or both
< checkbox is off, the global settings and/or connection table are left unchanged
< for the current session
< </ol>
< When the system performs copying of calendar-specific settings, the values from
< the settings file completely replace all of the calendar-specific settings
< values in the current calendar.  If values copied from the settings file are
< the same as those in the current calendar, then those values are effectively
< unchanged.
< </p><p>
< The effective change of values is particularly relevant to the definition of
< categories, custom lists, and custom filters.  If any of these definitions are
< exactly the same in the settings file and the current calendar, then these
< definitions remain effectively unchanged in the calendar.  Any definitions in
< the settings file that are not the same as the current calendar cause a change,
< addition, or deletion to the calendar.  Table 16 specifies precisely what
< constitutes the same definition, a changed definition, a definition to be
< added, and a definition to be deleted.
< 
< <br>
< <br>
<                                      <hr>
< <br>
< 
< <a name="Table Comparison of definitions in settings file versus current calendar">
< <table align=center border=1 cellpadding=4>
<   <tr>
<     <td valign=top><strong>Type of Definition</strong>
<     <td valign=top><strong>Same</strong>
<     <td valign=top><strong>Change</strong>
<     <td valign=top><strong>Addition</strong>
<     <td valign=top><strong>Deletion</strong>
<   <tr>
<     <td valign=top>category
<     <td valign=top>same name and color
<     <td valign=top>same name with different color
<     <td valign=top>
< new name in settings file that is not in calendar
<     <td valign=top>
< name in calendar that is not in settings
<   <tr>
<     <td valign=top>
< custom list&nbsp;and
< <br>
< custom filter
<     <td valign=top>same name and values
<     <td valign=top>
< same name with one or more different values
<     <td valign=top>
< new name in settings file that is not in calendar
<     <td valign=top>
< name in calendar that is not in settings
< </table>
< <p align=center> Table 16:  Comparison of definitions in settings file versus
< current calendar.
< <br>
< <hr>
< </p>
< 
< <br>
< 
< <p>
< </a>
< </p><p>
< Once calendar-specific settings values are loaded, the system confirms and
< applies all loaded values.  In particular,
< <ul>
< <li>
< categories, custom lists, and custom filter definitions are confirmed and
< applied
< <li>
< changed option settings are applied
< <li>
< page set up and print settings are confirmed
< <li>
< the effects of a change to the windowing mode takes effect when the user
< executes the next affected viewing command
< </ul><font color=black>
< The system then performs all processing that results from changed, added, or
< deleted settings values.  If this processing would require further user
< confirmation, the system proceeds as if the confirmation is affirmative
< (`<tt>OK</tt>' or `<tt>Yes</tt>').  The sections of the requirements that
< specify the processing associated with each type of calendar setting are those
< cited parenthetically in the list at the beginning of
< <a href="file.html#Files Used by the Calendar Tool">
< Section 2.8.1.
< </a>
< </p><p>
< Changes to category definitions and options are the only setting changes that
< may result in immediate changes to scheduled items in the current calendar.
< The category changes that have immediate effect are those described in
< <a href="category-editing.html#Editing Categories">
< Section 2.5.5
< </a>
< that result from color changes or deletions of category definitions.  Changes
< in meeting-scheduling options can have immediate effect if the current calendar
< is connected to a host and the loaded options change the setting of when
< pencil-ins are accepted to `<tt>whenever connected to the originating
< host</tt>`.
< </p><p>
< Changes to custom lists, filters, options, and windowing mode may result in
< changes to the appearance of scheduled items in display windows, but not in the
< items themselves.  Changes to page setup and print settings take effect only
< when the user executes the `<tt>Page Setup</tt>' and `<tt>Print</tt>' commands.
< </p><p>
< When the system re-initializes the host connection table, it completely
< replaces the contents of current the session-wide table with the entries in the
< settings file.  The "session-wide table" is that in use in the current Calendar
< Tool session, as it appears when the user runs the `<tt>Admin->Connect</tt>'
< command.  To avoid undue disruption, the checkbox to load host connection
< settings is unset and disabled when one or more hosts is connected in the
< current Calendar Tool session.  Changes to the host connection table may lead
< to changes in scheduled items being downloaded from the host.  However, these
< changes are not immediate when settings a loaded, because no hosts can be
< connected when the host connection table is loaded from a settings file.
< Complete discussion of the host connection table is in
< <a href="admin.html#Central Host Connections">
< Section 2.6.6.1.
< </a>
< </p><p>
< It is noteworthy that two parts of the settings file are missing from the
< load-settings dialog.  These are the the calendar-specific setting for the
< `<tt>state of open windows</tt>', and the session-wide setting for the
< `<tt>names of open calendars</tt>'.  These settings are used, and are only
< manageably meaningful, when the settings file is loaded at start-up, or in the
< case of open windows, when a calendar is opened.
< </p><p>
< When the user selects the `<tt>Save Settings</tt>' command, the system responds
< by displaying the dialog shown in Figure 301.
< 
< <br>
< <br>
< <hr>
< <a name="Figure Save-settings dialog">
1386c471
< <img src="images/save-settings-dialog.gif">
---
> Figure 289:  Loading options from the Calendar Tool central host.
1388d472
< <p align=center> Figure 301:  Save-settings dialog.  </p>
1393,1441c477,482
< The figure reflects the state of the Calendar Tool user directory before any
< settings files have been saved.  The dialog is very similar in content to that
< for loading settings, with the addition of the two settings noted just above as
< missing from the load dialog.  The user may select via checkboxes which parts
< of a settings file to save, and to which file to perform the save.  All of the
< checkboxes are on by default.  When the filter settings checkbox is on, the
< system automatically checks and disables the categories checkbox.  This is
< because custom filter definitions may be defined in terms of calendar-specific
< categories.  If the user unchecks the filters checkbox, the categories checkbox
< is enabled for independent checking or unchecking.
< </p><p>
< If the user invokes `<tt>Save Settings</tt>' when there is no current open
< calendar, the system unchecks and disables all of the calendar-specific
< checkboxes under `<tt>From the current calendar</tt>'.  In this case, only the
< session-wide settings can be saved.  If the user invokes `<tt>Save
< Settings</tt>' when one or more calendars is connected, the settings can still
< be saved, but the connected state is ignored.  That is, the host connection
< table is always saved with the `<tt>Connected?</tt>' column blank.
< </p><p>
< The default file in the save-settings dialog is the standard <tt>Settings</tt>,
< in the Calendar Tool user directory.  The values shown Figure
< <a href="file.html#Figure Save-settings dialog">
< Figure 301
< </a>
< reflect the initial state of the dialog, with the pre-installed
< "<tt>Settings</tt>" file, before the user has saved to any other settings
< files.  Only Calendar Tool settings files and directories are enabled in the
< scrollable file list.  The user can navigate and select in the dialog in the
< same manner as described for the `<tt>Save As</tt>' dialog in
< <a href="file.html#Figure File save-as dialog">
< Figure 295.
< </a>
< The `<tt>OK</tt>' button is enabled except when the user does one of the
< following:
< <a name="save-settings-disabled">
< <ul>
< </a>
< <li>
< erases all typing
< <li>
< enters the name of an unwritable settings file
< <li>
< enters the name of an unreadable directory
< <li>
< enters the name of an existing non-settings file
< </ul><font color=black>
< The system disallows saving in any of these circumstances.  If the user
< continues typing to change these circumstances, the system re-enables the
< `<tt>OK</tt>' button.
---
> 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 optins configuration, the user can save the
> options settings loaded from the central host to the local <tt>Options</tt> file.)
1443,1444c484,485
< Figure 302 shows the user having chosen to save a subset of the settings to the
< file "<tt>OfficeSettings</tt>".
---
> If there are unapplied or unsaved option changes when the user presses `<tt>Load
> ...</tt>', the system issues the warning shown in Figure 290,
1449c490
< <a name="Figure Save-settings dialog filled in">
---
> <a name="Figure ">
1451,1588c492
< <img src="images/save-settings-dialog-filled-in.gif">
< </p>
< <p align=center> Figure 302:  Save-settings dialog filled in.  </p>
< <hr>
< </a>
< <br>
< 
< When the user presses `<tt>OK</tt>', the system performs the following actions
< to complete the save:
< <ol type=a>
< <li>
< copies the checked calendar-specific settings from the current calendar to the
< selected settings file
< <li>
< copies the checked session-wide settings to the selected settings file
< <li>
< for the unchecked calendar-specific settings, the system does one of the
< following:
< <ol type=i>
< <li>
< if the saved-to settings file exists, the unchecked settings in the file are
< not changed
< <li>
< if the saved-to settings file does not exits, the system copies the built-in
< default values to the settings file;
< <a href="file.html#Table Built-in default settings for new calendars, absent a Settings file">
< Table 15
< </a>
< defines the values of built-in calendar-specific settings
< </ol>
< <li>
< for unchecked session-wide settings, the system copies the built in values,
< which are as shown in
< <a href="options.html#Figure Global options dialog">
< Figure 282
< </a>
< for global options, and are empty for both the host connection table and list
< of open calendars
< </ol>
< <a name="absolute dates">
< </p><p>
< </a>
< In saving the state of open windows, the system saves all physical details of
< all windows associated with the current calendar.  These details are the window
< content, size, position, and state of iconification.  In saving calendar view
< windows, the system uses the specific absolute dates in the display, not dates
< relative to today's date.  For example, if there is a month view for September
< in an active window, the system saves the state of that window as open for that
< specific month.  If the user subsequently opens the calendar with the saved
< settings in, say, October, the month view opened from the saved settings is
< still September.  The system always highlights today's date in any calendar
< view that contains today's date.  However, if a view saved in the settings
< contains today's date when it is saved, but not when the settings are later
< loaded, the view cannot and does not have today's date highlighted.  The point
< again is, views saved in the `<tt>state of open windows</tt>' setting are saved
< with the absolute dates displayed at the time of saving, and the dates are not
< adjusted relative to today's date when the settings are subsequently loaded.
< If the user wants the initial view of a calendar to be relative to today's
< date, she can use a viewing option other than `<tt>per most recently saved
< settings</tt>', as described in
< <a href="options.html#Viewing Miscellaneous Options">
< Section 2.7.4.3.
< </a>
< </p><p>
< The system does not display an overwrite warning if the user saves to an
< existing settings file.  This is because the user may frequently save settings
< to an existing file, in particular the <tt>Settings</tt> file in the Calendar
< Tool directory.  In this sense, overwriting an existing settings file is more a
< normal than exceptional activity.
< </p><p>
< When the user saves settings to the standard <tt>Settings</tt> file, the saved
< values become those that are used as the defaults when the Calendar Tool starts
< up, and as the defaults for new calendars.  In this way, the current calendar
< serves as the basis for the standard default settings.  If the user wants
< different values for the standard defaults, she can change the current calendar
< and save again to the standard <tt>Settings</tt> file.
< </p><p>
< Confirming the `<tt>Save Settings</tt>' command results in a change to the
< selected settings file, but not to the current calendar.  Hence, the system
< performs none of the change-related processing associated with loading settings
< shown in
< <a href="file.html#Table Comparison of definitions in settings file versus current calendar">
< Table 16.
< </a>
< </p><p>
< Table 17 summarizes all of the ways that the user can save settings to a
< calendar file or to a settings file.
< 
< <br>
< <br>
<                                      <hr>
< <br>
< 
< <a name="Table Summary of ways to save settings">
< <table align=center border=1 cellpadding=4>
<   <tr>
<     <td valign=top><strong>Command</strong>
<     <td valign=top><strong>Type of saving performed</strong>
<   <tr>
<     <td valign=top>
< `<tt>Save</tt>' command in the `<tt>File</tt>' menu
<     <td valign=top>
< All calendar-specific settings in the current calendar are saved to the file
< associated with current calendar; there is no change to any settings file, and
< in particular, session-wide settings are not saved anywhere.
<   <tr>
<     <td valign=top>
< `<tt>Save As</tt>' command in the `<tt>File</tt>' menu
<     <td valign=top>
< All calendar-specific settings in the current calendar are saved to the
< selected calendar file; there is no change to any settings file, and in
< particular, session-wide settings are not saved anywhere.
<   <tr>
<     <td valign=top>
< `<tt>Save Settings</tt>' command in the `<tt>File</tt>' menu
<     <td valign=top>
< Checked settings are saved to the selected settings file; unchecked settings
< are unchanged in an existing file, defaults in a new file; no calendar file is
< affected.
<   <tr>
<     <td valign=top>
< `<tt>Save</tt>' button in the global options dialog
<     <td valign=top>
< Global options are saved to the <tt>Settings</tt> file in the user's Calendar Tool
< directory; all other settings are unchanged in the <tt>Settings</tt> file; no
< calendar file is affected.
<   <tr>
<     <td valign=top>
< `<tt>Save</tt>' button in the host connection dialog
<     <td valign=top>
< The host connection table is saved to the <tt>Settings</tt> file in the user's
< Calendar Tool directory; the `<tt>Connected?</tt>' column is fully blank in the
< saved table; all other settings are unchanged in the <tt>Settings</tt> file; no
< calendar file is affected.
< </table>
< <p align=center> Table 17:  Summary of ways to save settings.
< <br>
< <hr>
---
> <img src="images/options-load-warning.gif">
1590,1618d493
< 
< <br>
< 
< <p>
< </a>
< 
< <a name="Page Setup and Print">
< <h4>
< 2.8.6.  Page Setup and Print
< </h4>
< </a>
< </p><p>
< Printing from the Calendar Tool is based strictly on the content visible in
< active Calendar Tool windows.  Window content appears on the printed page
< exactly as it appears on the screen.  "Exactly" means the content of the
< printed page is the same in appearance and absolute size as it appears on the
< screen.  Scrolling lists and other scrollable components of the display are not
< expanded in the printed output.  The printed content excludes the window
< banner, any bordering other than a single black line, and any content that is
< not visible within the window frame on the screen.  This means there is no page
< numbering, header, footer, or other page labeling.
< </p><p>
< When the user selects the `<tt>Page Setup</tt>' command in the `<tt>File</tt>'
< menu, the system displays the dialog in Figure 303.
< 
< <br>
< <br>
< <hr>
< <a name="Figure Page setup dialog">
1620c495
< <img src="images/page-setup-dialog.gif">
---
> Figure 290:  .
1622d496
< <p align=center> Figure 303:  Page setup dialog.  </p>
1626a501,504
> 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.
1628,1648c506,509
< The `<tt>Orientation</tt>' setting defines the width-by-height orientation of
< pages.  With the default selection of `<tt>portrait</tt>', pages are laid out
< with the <tt>width</tt> dimension running horizontally and the <tt>height</tt>
< dimension running vertically.  When `<tt>landscape</tt>' is on, the
< <tt>width</tt> dimension runs vertically and the <tt>height</tt> dimension
< horizontally.
< </p><p>
< The `<tt>Page Size</tt>' values define the size of a page in inches.  The
< `<tt>Margins</tt>' values define the unprintable area between the edge of the
< page and the edge of the printed content.  When possible, the Calendar Tool
< queries the underlying operating environment to determine page size and margin
< settings for the currently selected printer.  When such determination is made,
< the system inserts the values as the defaults in the page setup dialog.  If the
< system cannot make this determination, the default width and height values are
< 8.5 and 11 inches, the default margins are all .5 inch.
< </p><p>
< The user can manually adjust the page size and margin settings to accommodate
< the paper size and margin requirements of different printers.  In doing so, it
< is the user's responsibility to enter page size or margin values that can be
< accommodated on a particular printer, such that printed content is not cropped
< on the page.
---
> 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.
1650,1651c511,519
< The `<tt>Scale</tt>' setting defines the scale of the printed content relative
< to the printed page.  The default is 100%.
---
> <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 2.8.9
> </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>
1653,1664c521,527
< When the user selects the `<tt>Print</tt>' command in the `<tt>File</tt>' menu,
< the system displays the dialog in Figure 304.
< 
< <br>
< <br>
< <hr>
< <a name="Figure Print dialog">
< <p align=center>
< <img src="images/print-dialog.gif">
< </p>
< <p align=center> Figure 304:  Print dialog.  </p>
< <hr>
---
> 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 2.8.9
1666,1713c529,539
< <br>
< 
< The user selects the printer to which output is directed from a list of
< available printers.  When possible, the Calendar Tool queries the underlying
< operating environment to determine the identity of the user's preferred
< printer.  When such determination is made, the system inserts the name of the
< printer as the default value in the `<tt>Printer</tt>' field.  If the user's
< preferred printer cannot be determined, the field is blank.
< </p><p>
< The user can select to print the current window only, all windows of the
< current calendar, or all active windows.  Per
< <a href="window-viewing.html#Viewing Multiple Windows and Multiple Calendars">
< Section 2.3.6,
< </a>
< an active window is any that appears in the `<tt>View->Windows</tt>' submenu.
< Iconified (i.e., minimized) windows are considered active.  The successive
< print order of multiple windows is based on the top-to-bottom order of windows
< in the `<tt>View->Windows</tt>' submenu.
< </p><p>
< The user may select the number of copies of each window to print, the default
< being 1.  The `<tt>Collated</tt>' checkbox is enabled if the user selects more
< than 1 copy.  If `<tt>Collated</tt>' is off (the default), the system prints
< all copies of the same window in immediate succession, before printing the next
< window.  If the user turns `<tt>Collated</tt>' on, the system prints one copy
< of each window in succession before beginning the next copy of the each window.
< </p><p>
< When the user presses `<tt>OK</tt>' in the print dialog, the system proceeds
< with the printing.  If a window fits on a single page based on the page setup
< parameters, the system prints the window centered on the page.  The system does
< not print more than one window per page, even if more than one window could fit
< on a single page.  If a window is too large to fit on one page, the system
< prints as much per page as possible, printing the multiple pages of the same
< window in row-wise order.  The multiple pages of a single window are all left
< and top justified to the defined margins, not centered as for single-page
< windows.
< </p><p>
< There may well be additional functionality for page set up and printing in
< specific operating environments.  This includes the ability to set other
< printer parameters, preview printed pages, and define other forms of page
< layout.  Implementors must provide all such available functionality.
< Implementors are required to provide only generic page layout functionality,
< not content-specific layout.  Contentwise, layout is at most one window per
< page, as described above.
< 
< <a name="Exit">
< <h4>
< 2.8.7.  Exit
< </h4>
---
> ).  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, Open, Close, and Close All">
> 2.8.1
> </a>
> and
> <a href="file.html#Save, Save As, Save All">
> 2.8.2
1714a541,542
> describe how file dialogs display inapplicable file types and the details of
> overwriting extant files.
1716,1741c544,566
< When the user selects the `<tt>Exit</tt>' command in the `<tt>File</tt>' menu,
< the system begins the exiting process by executing the `<tt>Close All</tt>'
< command.  The associated processing for `<tt>Close All</tt>' ensues, including
< any necessary user interaction through the warning dialogs.  This is described
< in
< <a href="file.html#Close and Close All">
< Section 2.8.3.
< </a>
< If the user responds at any point such that the `<tt>Close All</tt>' is
< canceled for all remaining calendars, the `<tt>Exit</tt>' operation is also
< thereby canceled.
< </p><p>
< Once the `<tt>Close All</tt>' has run to completion, the system checks if there
< are unsaved session-wide settings.  If so, the system displays the dialog shown
< in Figure 305.
< 
< <br>
< <br>
< <hr>
< <a name="Figure Offer to save session-wide settings before exit">
< <p align=center>
< <img src="images/offer-to-save-settings-dialog.gif">
< </p>
< <p align=center> Figure 305:  Offer to save session-wide settings before exit.
< </p>
< <hr>
---
> 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.5.
1743,1756d567
< <br>
< 
< If the user answers `<tt>Yes</tt>', the system saves all session-wide settings
< to the <tt>Settings</tt> file in the user's Calendar Tool directory.  If the
< user answers `<tt>No</tt>', the system does not save session-wide settings,
< thereby losing any unsaved changes.  If the user presses `<tt>Cancel</tt>', the
< systems cancels the `<tt>Exit</tt>' command and removes the
< offer-to-save-settings dialog from the screen, leaving all calendars closed but
< the Calendar Tool still running.
< </p><p>
< When the user answers `<tt>Yes</tt>' or `<tt>No</tt>', or if the session-wide
< warning dialog was not displayed, the system proceeds with the `<tt>Exit</tt>'
< operation by terminating the current session of the Calendar Tool, thereby
< returning the user to the underlying operating environment.
1758c569
< <a name="Files Used by Calendar Tool Administration">
---
> <a name="Local Files">
1760c571
< 2.8.8.  Files Used by Calendar Tool Administration
---
> 2.8.7.  Local Files
1764,1774c575,579
< Sections
< <a href="admin.html#Administrative Functions">
< 2.6,
< </a>
< and
< <a href="multi-user-envir.html#Multi-User Operating Environment">
< 2.14,
< </a>
< contain general discussions about the data repositories on Calendar Tool
< central host computers.  This section presents specific details of the
< directory and file structure of the repositories.
---
> 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.
1776,1781c581,594
< A central host data repository consists of the following storage components:
< <ul>
< <li>
< a user database, holding Calendar Tool user records but no user calendars
< <li>
< a group database, holding Calendar Tool group records
---
> NOT to all of the following paragraph; coverage of `<tt>File->Local Files</tt>'
> since it's been nuked to a command and moved to Admin options; the priv admin
> `<tt>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.
> </p><p>
> <em>Need to cover `<tt>File->Local Files</em>' command here or elsewhere, as
> well as the privileged admin `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, admints can set the default
> value for the local files
> </p><p>
> There are four standard fixed-name files used by the CalendarTool:
> <ol type=a>
1783,1784c596,606
< a location database, holding meeting location records and other-usage booking
< records
---
> <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
1786c608,609
< a directory containing user and group calendars, one calendar per file
---
> "<tt>Intialization</tt>": the command file read in by the CalendarTool whenever
> it starts up
1788,1831c611,613
< a <tt>Settings</tt> file containing administrator password, email address, and
< options
< </ul><font color=black>
< The internal structure of repository directories and files is
< implementation-dependent.  The externally-visible names and organization of the
< files are shown in Table 18.
< 
< <br>
< <br>
<                                      <hr>
< <br>
< 
< <a name="Table Central Host Data Files">
< <table align=center border=1 cellpadding=4>
<   <tr>
<     <td valign=top><strong>File or Directory</strong>
<     <td valign=top><strong>Usage</strong>
<   <tr>
<     <td valign=top>Users
<     <td valign=top>user database file or directory
<   <tr>
<     <td valign=top>Groups
<     <td valign=top>group database file or directory
<   <tr>
<     <td valign=top>Locations
<     <td valign=top>location database file or directory
<   <tr>
<     <td valign=top>Calendars
<     <td valign=top>
< directory of user and group calendar files, with each root file name identical
< to the Calendar Tool user or group ID of its owner
<   <tr>
<     <td valign=top>Settings
<     <td valign=top>administrative settings
< </table>
< <p align=center> Table 18:  Central Host Data Files.
< <br>
< <hr>
< </p>
< 
< <br>
< 
< <p>
< </a>
---
> "<tt>FileInfo</tt>": file containing settings established with the
> `<tt>File->Connect</tt>' and `<tt>File->Local Files</tt>' commands.
> </ol>
1833,1852c615
< When the Calendar Tool Administration program is installed, initial versions of
< the repository files and directories are created, as described in
< <a href="installation.html#Installing the Calendar Tool Administration Program">
< Section 2.15.3
< </a>
< The file and directory names shown in
< <a href="admin.html#Figure Central Host Data Files">
< Table 18
< </a>
< are fixed.  The three databases are either single files or directories
< organized in some implementation-specific manner.  The Calendars directory must
< contain one file for each user and group calendar, with user and group ID as
< the root filename.  The internal structure of the files and possible filename
< extensions is left to the implementors.
< </p><p>
< The fact that the databases may be a file or a directory allows the
< implementors to use a database representation that is either in a single file
< or multiple files in a parent directory.  Independent of this level of
< implementation detail, the implementors must meet the following specific
< requirements:
---
> Here's the order in which files are handled on start up:
1855c618,619
< the three databases must be in three separate files or directories
---
> 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.
1857,1860c621,622
< the names of the files or directories must be those in Table
< <a href="file.html#Table Central Host Data Files">
< Table 18
< </a>
---
> 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.
1862c624,644
< user and group calendars must each be stored in a separate file
---
> Any command-line files that are not valid Calendar Tool files or not otherwise
> readable are ignorred, with a warning dialog to this effect displayed on the
> screen.
> <li>
> If there's a <tt>Configuration</tt> file and it requires openning 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 comamnd language, there's no way to duplicate the
> window-placement functionality of <tt>Configuration</tt> file.
1864,1890d645
< The purpose of these requirements is to allow the administrator readily to
< assess the size of databases and calendars using the normal file sizing
< functionality of the underlying operating environment.
< </p><p>
< The repository files and directories are themselves stored in a single
< directory, specified initially when the Calendar Tool Administration program is
< installed.  This superdirectory is the root of the entire central host
< repository.  If there are conventions in a particular operating environment for
< where such application-specific files should be stored within the file system,
< then such conventions can be followed during installation.  After installation,
< the administrator can change the location of the repository directory, if
< necessary.  This is done by changing the administrative option setting
< described in
< <a href="options.html#Options in the Calendar Tool Administration Program">
< Section 2.7.7.
< </a>
< The repository directory may contain other files at the discretion of the
< administrator.  In particular, an administrator may choose to create settings
< or sample calendar files, to be distributed to users as a convenience.  These
< files are created with the regular-user Calendar Tool, run by an administrator
< who has privileges to save files in the repository directory.
< 
< <a name="Administrative Save and Save Copy">
< <h4>
< 2.8.9.  Administrative Save and Save Copy
< </h4>
< </a>
1892,1912c647,665
< When the administrator executes the `<tt>Save</tt>' command in the
< administrative file menu, the system saves all changes made to any data since
< the last save.  Changes to "any data" mean any data added, changed, or deleted
< in any of the administrative dialogs discussed in Sections
< <a href="admin.html#User Database">
< 2.6.2
< </a>
< through
< <a href="admin.html#Other Privileged Admin Commands">
< 2.6.5
< </a>
< of the requirements.  As discussed in
< <a href="file.html#Files Used by Calendar Tool Administration">
< Section 2.8.8,
< </a>
< administrative data are stored in fixed files in a fixed location; these are
< the files to which data are saved.
< </p><p>
< To save a copy of all repository data, the administrator uses the `<tt>Save
< Copy</tt>' command.  In response, the system displays the dialog shown in
< Figure 306.
---
> Given the nixing of <tt>CommunityCalendar</tt> as <em>the</em> global calendar,
> the folloiwng 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 adminstrator(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.
> </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
> explan a bit more in due course].
1914,1968c667
< <br>
< <br>
< <hr>
< <a name="Figure Save-copy dialog">
< <p align=center>
< <img src="images/file-save-copy-dialog.gif">
< </p>
< <p align=center> Figure 306:  Save-copy dialog.  </p>
< <hr>
< </a>
< <br>
< 
< The administrator selects the parent directory into which a copy of all
< repository files is to be saved.  The administrator can navigate and select in
< the dialog in the same manner as described for the `<tt>Save As</tt>' dialog in
< <a href="file.html#Figure File save-as dialog">
< Figure 295.
< </a>
< The `<tt>OK</tt>' button is enabled whenever a writable directory is selected
< in the scrolling list.  For example, Figure 307 shows the administrator having
< selected to save a copy of the repository in the directory
< "<tt>/usr/local/caltool/Backup</tt>", which in his case is a subdirectory of
< the repository itself.
< 
< <br>
< <br>
< <hr>
< <a name="Figure Save-copy dialog filled in">
< <p align=center>
< <img src="images/file-save-copy-dialog-filled-in.gif">
< </p>
< <p align=center> Figure 307:  Save-copy dialog filled in.  </p>
< <hr>
< </a>
< <br>
< 
< </p><p>
< When the administrator presses `<tt>OK</tt>', the system saves a complete copy
< of all repository files in the selected directory.  A "complete copy" means
< that all directories and files listed in
< <a href="file.html#Table Central Host Data Files">
< Table 18
< </a>
< are fully copied.  No other files that happen to be within the repository
< superdirectory are copied.  If there are one or more files or directories
< within the destination directory of the same name as the copied files, the
< system provides no overwrite warning.  Existing directories are written into,
< existing files are fully overwritten.
< </p><p>
< The save-copy command does not affect the files in the fixed repository
< location, and does not change the location of the fixed repository.  When the
< administrator subsequently executes the `<tt>Save</tt>' command, data are saved
< to the fixed repository.
< 
< <a name="Administrative Page Setup and Print">
---
> <a name="File Connect and Local Files">
1970c669
< 2.8.10.  Administrative Page Setup and Print
---
> 2.8.8.  File Connect and Local Files
1974,1986c673,675
< Administrative page setup and print commands provide precisely the same
< functionality as in the regular-user Calendar Tool, described in
< <a href="file.html#Page Setup and Print">
< Section 2.8.6.
< </a>
< As with Calendar Tool printing, output is based strictly on the content visible
< in active administrative windows.  The page-setup and print dialogs are the
< same.
< 
< <a name="Administrative Exit">
< <h4>
< 2.8.11.  Administrative Exit
< </h4>
---
> The `<tt>Connect</tt>' command was described in
> <a href="admin.html#Central Host Connections">
> Section 2.6.6.1
1988,1992c677,678
< </p><p>
< When the administrator executes the `<tt>Exit</tt>' command, the system checks
< if there are any unsaved changes to repository files or pending dialog edits.
< If either or both of these conditions is true, the system displays the dialogs
< of Figures 308 and 309, respectively.
---
> on administrative commands.  When the user selects the `<tt>Local Files</tt>'
> command, the system displays the dialog shown in Figure 291.
1997c683
< <a name="Figure Offer to save repository data before closing">
---
> <a name="Figure Local files dialog">
1999,2007c685,686
< <img src="images/offer-to-save-admin-dialog.gif">
< </p>
< <p align=center> Figure 308:  Offer to save repository data before closing.
< </p>
< <hr>
< </a>
< <br>
< 
< 
---
> <strong><em>Stick in the</em></strong> <strong><em>`Default Calendar Tool
> Directory'</em></strong>
2009,2013c688
< <br>
< <hr>
< <a name="Figure Warning when there are pending edits in administrative dialogs">
< <p align=center>
< <img src="images/admin-exit-with-dialog-edits.gif">
---
> <strong><em>item from the Admin tab of the Options dialog.</em></strong>
2015,2016c690,692
< <p align=center> Figure 309:  Warning when there are pending edits in
< administrative dialogs.  </p>
---
> 
> Also add field for entering default calendar to open on fileless app launch.
> <p align=center> Figure 291:  Local files dialog.  </p>
2021,2031d696
< </p><p>
< If the administrator answers affirmatively in both cases, or if the dialogs
< were not displayed, the system proceeds with the `<tt>Exit</tt>' by terminating
< the current session of the Calendar Tool Administration program, thereby
< returning the administrator to the underlying operating environment.
< Termination of the administration program does not terminate the Calendar Tool
< server program.  The server remains running asynchronously until the
< administrator executes the `<tt>Stop Server</tt>' command, as described in
< <a href="admin.html#Administrative Control of the Central Host Server">
< Section 2.6.5.1.
< </a>
2033c698
< <a name="External Changes to Calendar Tool Files">
---
> <a name="File Types">
2035c700
< 2.8.12.  External Changes to Calendar Tool Files
---
> 2.8.9.  File Types
2039,2048c704,719
< As explained in the preceding scenarios of this section, both the Calendar Tool
< and Calendar Tool Administration program normally attempt to disallow opening
< and saving to ineligible files.  However, if a user changes or deletes files
< when the Calendar Tool or Calendar Tool Administration are running, normal
< operation may be disrupted.
< <a href="error-conditions.html#File Errors">
< Section 2.12.11
< </a>
< enumerates the conditions under which file-related errors can occur and the
< associated error messages.
---
> <em>Discuss the different file types and the ramifications thereof, including
> that filetypes 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-
> annoyiing 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 cateogories: (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.
2050c721
< <a name="Operating Environment Conventions">
---
> <a name="Calendar File Contents">
2052c723
< 2.8.13.  Operating Environment Conventions
---
> 2.8.10.  Calendar File Contents
2056,2071c727,740
< Different operating environments may have conventions for many aspects of file
< handling.  There may be conventions for file naming, including characters
< allowed in file names, the length of file names, and the designation of a users
< "home" directory.  There may be varying functionality for file-selection
< dialogs, filespace navigation, and other basic features of file management.
< Environments may also have conventions for the location of installed files and
< directories, such as a user's Calendar Tool directory.
< </p><p>
< Implementors may follow required or appropriate conventions, but must implement
< the features described in these requirements insofar as is possible.  In
< particular, the feature of the user being able to type a file name in the
< file-open dialog must be retained, even if it is not standard in a particular
< operating environment.  Also, the user must be able to change the location of
< the Calendar Tool user directory, even if the operating environment recommends
< the placement of such directories in a particular location.
< 
---
> <ol type=a>
> <li>
> scheduled items
> <li>
> categories
> <li>
> custom lists
> <li>
> filter settings and custom filters
> <li>
> windowing mode
> <li>
> options
> </ol>