top of page

Miscellaneous Features

Working with the Table View

The Display View displays the records in a standard timeline format. However there are instances where there is a need to view the records in a text format that can be sorted, compared and other editorial operations.

 

The Table View is one in which the filtered records are displayed is a table format. The columns of the table consists of the following record components:

  •  
  • Start date

  • End date

  • Type

  • Title

  • Parent

  • Tags

  • Level

 

You can sort the records in the table using any of the record components by clicking on the header cell of that component. For example if you want to sort the records by their End Date, click on the End Date header cell. Clicking a second time on the same header cell will change the sorting from ascending to descending or vice versa.

 

Note: At this point, the records cannot be edited in the Table View.

 

Finally, the Table View provides a mechanism to export the data displayed in the table to a CSV file. For that, click on the 'Export to CSV' button. You will be asked to select the type of separator you want to use (comma or semi-colon) and then to name the CSV file.

Note: The application offers other mechanism to export the timeline data. Please see the Exporting and Importing Databases section for more details.

Undo Operations

The application provides a mechanism to undo changes to records or filters definitions. The application will remember the last 5 transactions and allow you to undo those transactions starting from the last one.

To undo a transaction, select the Edit menu and then the 'Undo Database Change' submenu. You can also use the fast key combination of Opt-Cmd-Z. The application will automatically undo the last transaction and update the displayed records as required.

Note: The application has kept the 'Undo' and 'Redo' menu options that come with every Apple application. Those will continue to operate on the different fields (e.g., text fields) used by the application (e.g. you can undo and redo a text that you typed in the Description field of the record). However, these two options redo do to apply to the transactions made on the database itself.  To execute an undo on the database itself, you need to use the Undo Database Change submenu option.

If there are no transactions to undo, or if you have undone the last 5 already, the Undo Database Change menu option will be deactivated (displayed in light gray).

Note: An Undo Database Change is executed on the full transaction and not only an individual record. For example, if you have used the Editor to change the font color of multiple records in one action, then one call to the Undo Database Change will undo the font color change to all the records what were modified with that single Editor action.

Operating with the Sandbox constraints
What is a Sandbox 

 

All Mac applications distributed through the AppStore have to be sandboxed. What that means is that those applications can only access resources on the user computer that are part of the application sandbox, I.e., the folder created in the ~/Library folder that contains the different files required to operate the application. This folder is typically not one of the main visible folders on Apple’s desktop but is accessible to users through standard folder navigation.

 

If the application needs to use any other resource on the user platform, the user has to explicitly authorize the application and allow it to do so. It is mainly a security mechanism that restricts the application access to the users files and resources in the background without the knowledge or consent of the user.

Default access

 

Apple does provide a few standard mechanisms for an application to gain access to some resources without the explicit acknowledgement of the user. Out of those options, Istoriam uses the default “Network Access” (so HTTP URLs that were added to a record can be opened and displayed in a browser), as well as “Read-Only” access to your standard Picture folder. The application will request authorization to access any other resource when needed.

Accessing local files 

 

Sandboxing restricts the application access to files saved our you computer. When you want to add a reference to a local file to one of your record, a standard file panel will open that will allow you to select the file. A reference (URL) to your file is then saved in the record components. Apple operating system will remember that you allowed access to the file and every time you click on that saved reference, the file in question is opened. 

Note: Beside the Istoriam database itself, all other files are opened in their appropriate application, i.e., a PDF file will be opened in Adobe, a doc files will be opened in Pages, etc.

 

Authorizations to access a file are by default limited to the time when the application is active. If the application re-starts, that authorization is lost and new one is typically required. This behavior is somewhat counter-productive when you want to save a reference to a file in one of your records. Every time you re-start the application, you will have to re-authorize the access any time you want to re-open one of those files by clicking on the saved reference.

To address this issue, the application uses mechanisms provided by Apple to remember that aforementioned file access authorization between sessions. With that mechanism in place, authorization to access local files (which references are saved in your records) will remain active even if the application is re-started. I.e., if you re-start the application, you will continue to be able to open the file which reference is saved in the record's components.

However, if the record is deleted, or the reference to the file is deleted from that record, that authorization will now be lost and any future access to that file will have to be authorized again.

Note: The application manages the sandboxing access to individual file that you have authorized (using the standard file panel) transparently to the user. There is nothing at this point that you need to deal with. This section was just as an FYI.

 

Accessing local folders 

 

Occasionally there are situations where you might want to provide the application with access, that will remain active between sessions, to all the files in a given folder.

 

To do so, open the Sandbox Panel window (under the Window menu item). In the window that will open, click on the “+” button and then select the folder from the file panel that will open. Going forward, the application will have access to any file in that folder. The application will remember the list of folders that were authorized and any future use of the application will be provided with access to all the folders that were added.

 

If your access need to an authorized folder have changed, you can open again the Sandbox Panel, select the folder in question, then click on the “-“ button.

Note:  Access authorization to a folder that was deleted from the Sandbox will remain active until the application is re-started.

 

Impact to iCloud operation

 

If you are using iCloud, the application will copy to iCloud the local references saved in a record.

 

If you are using iCloud to sync between multiple devices, then the local authorization key used to access a local file on one platform will not be usable on another platform and authorized access to the local file on a given platform will not work on another one.

 

However, if you are using iCloud to backup your local database to the cloud, then the access authorization keys copied and, when retrieved from iCloud, should continue to work properly.

 

Note: The application does not backup to iCloud the reference to the local folders added with the Sandbox Panel (see 'Accessing local folders'). Only the local references added to a record are copied to iCloud.

Accessin local folders
Table View
Undo
Sandbox
bottom of page