Visual Thought User's Guide
[TOC] [Prev] [Next] [Index]

Appendix G

File Typing

Introduction

 Visual Thought provides the ability to associate an arbitrary file with any shape or connection. This association is made through the attachment mechanism, available with the Attachments panel of the Inspector.

You can activate an attachment either by clicking the Activate button in the Attachments panel or by clicking the Attachment button beside an object with an attached file.

Visual Thought then determines which program runs the attached file, if any, and runs the program with the file.

This chapter discusses how Visual Thought accomplishes the task of determining which program runs which files, or equivalently, how Visual Thought types files.

Uses for Attachments

Attachments are very flexible and are more useful than might be initially imagined. We can subdivide uses for attachments into three general categories:

The File Typing Process

 When you activate an attachment, you initiate a multi-step process that uses as input your attached file and any input arguments you specified:

Type Dictionaries

 A Type Dictionary stores the mapping between file types and the programs that run files of those types. It also provides facilities to "look up" the program that runs any given file. Visual Thought provides two Type Dictionaries, for the user and the system. The User Type Dictionary is stored in:

~/.vthought/TypeDictionary

Each user has his or her own User Type Dictionary. The System Type Dictionary, of which there is only one, is stored in:

INSTALLDIR/config/TypeDictionary

where INSTALLDIR is the Visual Thought installation directory for your site. Every Type Dictionary is a text file that you can edit. This feature may be particularly useful for systems administrators, who can configure the System Type Dictionary to recognize file types relevant to their sites.

Type Dictionary File Format

The format of each Type Dictionary is described as follows.

Any line starting with # is a comment.

The first non-comment line describes the shell window within which applications can run. Some applications must run inside a shell window, either because they don't create a window themselves, or they need to take input from or direct output to a window. Examples of shell window description lines are:

cmdtool
xterm -e

All other non-comment lines describe bindings of file name suffixes to executables. They are of the form:

<needs_shell> <suffix> <exec> <args>

where:

<needs_shell> = Y | N (determines whether the <exec> runs
inside a shell window or not)
<suffix> = file name suffix (e.g., txt)
<exec> = name of the executable that runs files with the given
suffix (e.g., emacs). A complete path to the executable
need not be given because the user's path is searched at
activation time.
<args> = arguments to <exec>

Examples of binding lines are:

Y txt emacs
N vthought vthought

In the first example, any attachment file whose name ended in .txt would be run by emacs under a shell window.

You can specify an empty suffix by writing (none) for the suffix. The associated executable will be run on any attachment file that does not have a suffix (i.e., the file name does not contain a `.'). For example, the line:

Y (none) emacs

would run emacs on any attachment file without a suffix.

Be careful when using empty suffixes. Because the Type Dictionaries only can recognize files by suffix type, and because they are searched before the Sun Classing Engine databases (the Sun Binder), the executable associated with a dictionary entry for empty suffixes will override any executable specified by the Sun databases.

For example, suppose the Sun Classing Engine recognizes, by content instead of suffix, files that can be run by a program called SuperApp, and suppose that those files adhere to no standard suffixing scheme. Now suppose that in an unrelated action, you made emacs run all files without suffixes, and you stored this information in a Type Dictionary. Then Visual Thought will run all your SuperApp files that do not have suffixes with emacs, because it searches the Type Dictionaries before the Sun Classing Engine.

Whereas Type Dictionaries only recognize files by their file names (i.e., by suffix), the Sun Classing Engine can recognize files according to file name as well as by content.

The Sun Classing Engine

Like Type Dictionaries, the Sun Classing Engine also stores mappings between file types and the programs that run them, and it provides a means for looking up the program that runs any particular file. It is not within the scope of this discussion to explain the Sun Classing Engine in any detail, but we provide a short description here. For more information, see the Solaris Desktop Integration Guide (ISBN 0-13-035726-X), or the Sun Binder manual page, binder(1).

The Sun Classing Engine recognizes files either by characteristics of the file names (such as suffixes) or by the contents of the files. It stores many more attributes of files, however, including the icon with which to display a file in the File Manager, and the command to print a file of an identified type.

Like the Type Dictionaries, the Classing Engine is hierarchical; an attempt to type a file goes through a multi-step process. The levels are:


Visual Thought User's Guide
[TOC] [Prev] [Next] [Index]

webmaster@confluent.com
¨ 1997 Confluent, Inc. All rights reserved.