Points to include:

• Init file only invoked one time at start-up, not at each file open
• Prev rule means no init file happens when other user's calendars are open.

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

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, oet'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.

Note that File Close and Window Close are different commands. The former closes a fill and all windows containing views of that file's data. The latter closes only the current window and does not close any file.

2.8.3. Save, Save As, Save All

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

2.8.4. 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 default-initi-view- level that specifies the default viewing level from item to year. The value of this option cannot be empty. If there is no init file in the user's home dir (per OS-specific definition of "home dir"), then the Cal Tool comes up a la described in the initial screen config in the ui-overview. Viz., there's a menubar and one view window at the level specified by the setting of default-init-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:

1. 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 ...
2. 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, 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.5. Printing

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

• start date
• end date
• apply active filter?

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.

Interestingly, it looks as if the cannonical simple-print form may shed some good light on the canonical modelling form, with respect in particular to how to model recurring instances. Gee wiz.