Several options can now be set in a preferences file. This file is a text file, is must be called XLS Preferences, and it must be located in the same folder as the application. Each line in the file represents an option specification. The first word identifies the option, the remaining words make up the option data. The option names currently supported are
the Workspace entry specifies a default workspace to use. Unless specified separately, listener font properties are identical to editor font ones. As an example, a preferences file containing the entries
EditFontName Courier EditFontSize 12 Workspace Alliance Drive:MPW:Programs:New XLS:xlisp.wks Color offspecifies a 12-point bold italic Courier font for editor windows, an alternative workspace, and turns color off. Turning color off may be useful if the screen size and number of colors used would require too much memory for the background buffer.
The dashed line separating system apple menu items from application items is now supplied internally -- a dash item is now no longer necessary. This should result in a single dash under both System 6 and System 7.
Under Macintosh System 7 XLISP-STAT now continues to operate while in background. If the variable *use-notifier* is not nil , then notification occurs when a modal dialog is to be opened or when the system tries to read from the listener. The notification consists of a beep, a flashing icon on the system menu, and a diamond marking the application name in the system menu.
Minimal support for examining processes on the current computer and for sending local or remote apple events is now available. The function launch-application takes either a file name string argument or an application signature argument and launches the corresponding application. By default the application is launched in foreground; specifying an optional argument as non- nil causes the application to be launched in background. The value returned is a process information record if the launch succeeds, or nil if the launch fails. Process information is currently encoded as a list of the process name, process signature, process serial number, time of process start and run time of the process. This representation may change.
Currently applications can only be found by signature if they are located on the boot volume.Application signatures used by launch-application are integers representing four-character character constants. The function encode-signature converts strings with the corresponding string of characters to the signature code. For example,
> (encode-signature "X1St") 1479627636computes the signature code for X1St, the signature for XLISP-STAT .
A list of process information records for all running processes is returned by get-process-list , and get-front-process returns the process information for the current front process. The set-front-process function takes a process name string, signature code, or process information record and makes the corresponding process the front process. If the argument is a string or integer, then the first process, if any, with the corresponding name or signature is used.
XLISP-STAT now responds to the four required Apple events (Open Application, Open Documents, Print Documents, and Quit Application). The Print event is ignored. Currently new workspaces can only be opened at startup (i. e. as part of the initial high level event), but text files can be opened by double clicking them or dragging them onto the XLISP-STAT icon at any time. In addition, the Do Script event is supported (class 'misc', event 'dosc'). This event takes a direct parameter that is a string and interprets it as a lisp expression. The expression is evaluated, the result is printed to a string, and the string is returned as the direct parameter of the result. For example, if you have the Alpha shareware editor, then from a Tcl shell window you can send an apple event to a running XLISP-STAT process asking XLISP-STAT to make a system beep sound:
Alpha.5.55> dosc -c 'X1St' -s "(sysbeep)" NIL
You can also send Apple events to processes on the same or on remote computers using the function send-apple-event . At the moment this function allows you to send events that contain parameters that are strings, integers, or floating point numbers. If a result is expected it should contain no required parameters or a required direct parameter that can be coerced to a string. In particular, this allows Do Script events to be sent to other XLISP-STAT processes. The send-apple-event function has three required parameters, two four-character strings specifying the event class and type, and an address specifier for the event's receiver. The address can be
(send-apple-event "aevt" "abou" "Finder")sends the Finder an apple event asking it to present its About This Macintosh dialog box.
To locate a target on the local machine or a machine on the network you can use the interactive browse-apple-event-targets function. This function presents a dialog box that lists available processes for all Macintoshes on a local network; if the local network is connected to an internet the dialog also presents a list of AppleTalk zones to choose from. Several keyword arguments are available for controlling the appearance of the dialog:
As an example, suppose an XLISP-STAT process is running on another Macintosh named "Fred's Macintosh" and that all permissions are suitably set. We can send a sysbeep command to this Macintosh using the expression
(let* ((sig (encode-signature "X1St")) (target (get-apple-event-target :object "Fred's Macintosh"))) (when target (send-apple-event "misc" "dosc" target :data "(sysbeep)")))If successful, the expression returns the string "NIL".
The support included for Apple events is rather minimal. The main reason I have not yet made it more extensive is that I don't know what kinds of events will be most useful for communicating with other applications. If anyone has any ideas or would like to help extending this, please let me know.
One problem that comes up on the Macintosh is the need to account for the screen size. Currently a background bitmap the size and depth of the primary screen is allocated within the partition. The size of this bitmap is
For a monochrome display this is fairly trivial, and a 3M partition should be adequate for most purposes (though this of course depends on what is loaded). But for a display using 32-bit color, this is 4M. At the moment, this calculation needs to be done manually and you need to make adjustments to your partition accordingly. I will try to come up with a better solution in the future.
The open-file-dialog function now accepts a third optional parameter for specifying the file types to show. If this parameter is nil , all files are shown. If it is a string or a list of strings, only files of the corresponding types are shown.The sefault is "TEXT". At present,at most four types can be given; this limitation will be removed in the future.