22,23c22 < * item collection. The operations in the View module are the ones that < * compute the these views. --- > * item collection. 31,32c30 < from Admin import UserDB, GroupDB, LocationDB, UserId, AdminPassword, < AdminEmailAddress; --- > from Admin import UserDB, GroupDB, LocationDB, UserId; 35,37c33 < from Options import Options, RegularUserOptions; < from MultiUserEnvir import Server; < --- > from Options import Options; 39c35 < PreviousState, CalendarSpecificSettings, AdminWorkSpace; --- > PreviousState; 58d53 < num_unnamed:integer and 68,72c63,65 < current, and the last element being the earliest visited. The third < integer component is the number of unnamed calendars, used by File->New < to give unnamed calendars unique names. The previous_state component < is used to support one level of command undo. The Clipboard is used < with the Edit cut, copy, and paste operations. --- > current, and the last element being the earliest visited. The > previous_state component is used to support one level of command undo. > The Clipboard is used with the Edit cut, copy, and paste operations. 106a100,103 > (* NOTE: We may need to separate a UserCalendar into a local and remote > versions, with only the latter having ther UID, the reason being that > locally, a calendar shouldn't have an ID, in case the user hooks it up to > more than one host. *) 108,116c105,114 < components: items:ScheduledItem* and settings:CalendarSpecificSettings and < uid:UserId and file:File and selected_date:Date and < requires_saving:RequiresSaving; < description: (* < The main data components of a user UserCalendar are a collection of < scheduled items and calendar-specific settings. Calendar bookkeeping < components are the ID of the user who owns the calendar, the file it's < stored on, the currently selected date, and a flag indicating if the < calendar requires saving. --- > components: items:ScheduledItem* and categories:Categories and > lists:CustomLists and filtering:Filtering and options:Options and > windowing_mode:WindowingMode and uid:UserId and file:File and > selected_date:Date and requires_saving:RequiresSaving; > description: (* > A UserCalendar has a list of scheduled items and the calendar-specific > information for categories, custom lists, filters, options, and > windowing mode. Calendar bookkeepting components are the ID of the > user who owns the calendar, the file it's stored on, the currently > selected date, and a flag indicating if the calendar requires saving. 124,127d121 < object CalendarName is string < description: (* The name of a user calendar. *); < end CalendarName; < 137,179d130 < object Settings is < components: CalendarSpecificSettings and SessionWideSettings; < description: (* < The stuff stored in a settings file. Need to figure out if we want to < cache a copy of this in the user (or tool-wide (if there is such a < thing)) workspace or just always get it from the file. It would seem < from the requirements that it does always come from the file, so < defining a cached version in the model may be crossing the boundary into < implementation. < *); < end Settings; < < object CalendarSpecificSettings is < components: Categories and CustomLists and FilterSettings and CustomFilters < and WindowsState and WindowingMode and options:RegularUserOptions; < description: (* < Calendar-specific settings consist of category definitions, custom < lists, custom filters, the current window state, the windowing mode, < and calendar-specific options. < *); < end CalendarSpecificSettings; < < object SessionWideSettings is < components: OpenCalendarNames and HostConnectionTable; < description: (* < < *); < end SessionWideSettings; < < (* TBD: *) < obj FilterSettings; < obj CustomFilters; < obj WindowsState; < obj OpenCalendarNames; < obj HostConnectionTable; < < object AdminWorkSpace is < components: server:Server, password:AdminPassword, email:AdminEmailAddress; < description: (* < The Server ... . < *); < end AdminWorkspace; <