2.8. Details of File Commands

Explain the deal with calendars, files, and their names up here.

2.8.1. New, Open, Close, and Close All

Points to cover:

Calendar file name is 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.
Each successive application of New with no intervening Save or Save As creates a calendar named "unnamedN" for N = 2 ... .
As seems to be the defacto standard, Save and Save As 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.

OK, OK -- it looks like we've covered a lot of the ground about "current" in the new(ish) Section 2.3.6.4.

Also need firm definition of "current", to whit:

current "calendar" is the listed at the top of the `View Calendars' list, as determined ... fell the fuck off.
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.
OK, here's the deal about banner labeling, I think:
1. 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 `Windows' menu.
2. When calendar has been saved to a file, the calendar name is the same as its file name.
3. When a (new) calendar has not been saved to a file, its name is "no name" or "no name [i]" for i = 2 to the number of unsaved saved calendars.
4. When the
Some more terminology: windows are "active"; calendars and files are "open".

Zero or more calendars may be open at any time. 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.

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 "none" (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 "OTHER USER:user name".

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.

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

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.

This paragraph is now WRONG. 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.

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.

Some `File Close' details:

closing a file-less calendar with unsaved changes (items or other) does offer- to-save-as
closing an filed calendar with unsaved changes (items or other) does offer-to- save
closing a calendar that is associated with a connected host warns that the connection will be terminated if the close proceeds.

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).

2.8.2. Save, Save As, Save All

6aug03 Notes:

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.
`Save As' 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.
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.

Another 4aug03 Note. 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.

4aug03 Note (if not mentioned elsewhere): 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 contents of 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.

When the user saves and the current calendar is connected to one or more (active) hosts the calendar is written to those hosts.

Note that `Save' and `Save As' are disabled when the current window is that of another user's or group's calendar.

NOTE: 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.

If the user exectues `File Save' for a calendar with unapplied aux data, the file-save dialog contains the message and radio buttons:

        "There are X changes for this calendar."
         (x) Apply these changes before saving
         ( ) Do not apply these changes before saving

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,

Some `Save As' Details:

dir names shown in regular black type
all file names shown in grey, but still selectable
warning if OK pressed and extant fill would be overwritten

2.8.3. Save Config

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 `Save Config', or of course write her own start-up script from scratch.

An issue we need to deal with is the relationship between the option setting of what we call "the standard default view" in the ui-overview. Here's what I think could work well: There is an option called `Start-Up View Level' 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 `Start-Up View Level', 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:

The system displays no windows automatically, thus ignoring entirely the setting of default-init-view-level; 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 ...
The system proceeds to put up the initial window per default-init-view- level, 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:
```
ViewWindows(1);
FileClose();
```
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 ViewWindows (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:
```
FileCloseAll();
```
which works for hopefully obvious reasons.

This all seems pretty darn clean. To be consistent, it seems with this scheme that the first like of the init file saved with `Save Config' will in fact be the preceding chunk of code to close the default window, so that the config file starts with a blank slate.

2.8.4. Print

Sketch of some ideas: The print dialog should include at least the following options:

start date
end date
apply active filter?

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.

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.

2.8.5. Exit

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.

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:

There are meeting notifications you have not yet processed.  Do you want to
review or discard the unprocessed notiications?

            Review    Discard

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.

2.8.6. Save As and Load in Editing Dialogs

NOTE: 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 Section 2.11.26.

The `Save As ...' 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 `Load' command. When the user presses `Save As ...', the system displays a dialog of the form shown in Figure 285.

Figure 285: Options save-as dialog.

The default save-as directory is the user's Calendar Tool directory, the default name of which is ".CalendarTool". The four listed files are the standard files created when the Calendar Tool is installed, as described in Section 2.15.5. Section 2.8.2. 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.

To save options to a file, the user enters the filename in the save-as dialog and presses `OK'. For example, Figure 286 shows the user having entered the file name "PersonalOptions" as the location to which options are saved.

Figure 286: Saving options to a PersonalOptions file.

The `Save As' command does not execute `Apply' or `Save', 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 `Save As'.

The `Load ...' button is used to load a previously-saved options file. When the user presses `Load ...', and there are no unapplied or unsaved options, the system displays the dialog in Figure 287.

Figure 287: Options load dialog.

The names of valid options files appear in normal typeface in the directory list; all other types of files appear in greyed typeface. Section 2.8.1 covers further details on the format and use of file opening (i.e., loading) dialogs, including the directory browsing list and file-type validation.

To load options from a local file, the user selects or enters a filename in the `File:' 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 Section ). If the user is not so connected, the `Load from central host' checkbox is disabled. Figure 288 shows the user having selected to load from the "Personal Options" file.

Figure 288: Loading from the Personal Options file.

Figure 289 shows the case where the user selects to load from the central host.

Figure 289: Loading options from the Calendar Tool central host.

When the central host checkbox is selected, the File and Directory data fields are cleared and disabled. The user confirms the load by pressing `OK', 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 Options file.)

If there are unapplied or unsaved option changes when the user presses `Load ...', the system issues the warning shown in Figure 290,

Figure 290: .

where affected is one of "unapplied" or "unsaved", as appropriate. Unapplied changes are also unsaved, given that saving automatically applies. The user presses `Yes' to proceed, `No' to cancel the `Load' command.

The `Load' command does not perform `Apply' or `Save'. 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.

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 Section 2.8.9 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).

Even though calendar-specific options are stored within calendar files, the `Save As' and `Load' 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 Section 2.8.9 ). When an extant calendar file is selected in the `Save As' 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 `Load' options command can only be used to load previously saved options files, not the options portion of a calendar file. Sections 2.8.1 and 2.8.2 describe how file dialogs display inapplicable file types and the details of overwriting extant files.

Since options are calendar-specific, the `Apply' and `Save' 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.

Any applied but unsaved changes are not saved by `Cancel'. If the options dialog is subsequently opened on a calendar with unsaved option settings, the unsaved state of the options is reflected by the `Save' 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 2.3.6.1 and 2.8.5.

2.8.7. Local Files

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.

NOT to all of the following paragraph; coverage of `File->Local Files' since it's been nuked to a command and moved to Admin options; the priv admin `File->Host Files' has been moved to the priv Admin 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.

Need to cover `File->Local Files' command here or elsewhere, as well as the privileged admin `File->Host Files' command. With `File->Local Files' 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

There are four standard fixed-name files used by the CalendarTool:

"CommunityCalendar": [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
"Options": the standard options file that is used to set the initial options for all new calendars
"Configuration": the file where the results of the `Save Config' command go, that says what windows are up initially and where they are
"Intialization": the command file read in by the CalendarTool whenever it starts up
"FileInfo": file containing settings established with the `File->Connect' and `File->Local Files' commands.

Here's the order in which files are handled on start up:

Any command-line files that do not exist are created as new Calendar Tool files, with the contents of the Options file copied into them.
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.
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.
If there's a Configuration 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 Configuration 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 Configuration file.
If there's an Initialization file, it is executed last. This means that the Initialization file can override any of the configuration performed as a result of command-line file specification and Configuration file processing. E.g., the initialization file could contain the command CloseAll to undo all of the command-line and Configuration 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 Configuration file.

Given the nixing of CommunityCalendar as the global calendar, the folloiwng paragraph is WRONG. If the CommunityCalendar file is deleted or corrupted, it's as if the user sets `Options.Meetings.When to Show Meeting Notifications' to `never', but otherwise things are as normal. Note that deleting (or renaming) CommunityCalendar on the user's local computer does not 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 CommunityCalendar file on the central host. It is up to the user to be prudent about saving backup copies of calendar files, including the CommunityCalendar. There is no Calendar Tool command to download the contents of a CommunityCalendar file from a Calendar Tool central host.

Note that the value of the local files directory path, user settable via the `File->Local Files' 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].

2.8.8. File Connect and Local Files

The `Connect' command was described in Section 2.6.6.1 on administrative commands. When the user selects the `Local Files' command, the system displays the dialog shown in Figure 291.

Stick in the `Default Calendar Tool Directory'
item from the Admin tab of the Options dialog.

Also add field for entering default calendar to open on fileless app launch.

Figure 291: Local files dialog.

2.8.9. File Types

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.

OK, try this: (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 Options from the options save-as dialog or an extant cal file from File->Save As) (2) overwriting an extant file of the wrong type (e.g., overwriting Categories the options save-as dialog or an extant file of some non- cal-tool type from the File->Save As dialog. It think is is all pretty farging sweet.

2.8.10. Calendar File Contents

scheduled items
categories
custom lists
filter settings and custom filters
windowing mode
options

Prev: options | Next: edit | Up: functional | Top: index