;;;> ;;;> ***************************************************************************************** ;;;> ** (c) Copyright 1993 Symbolics, Inc. All rights reserved. ;;;> ** Portions of font library Copyright (c) 1984 Bitstream, Inc. All Rights Reserved. ;;;> ;;;> The software, data, and information contained herein are proprietary ;;;> to, and comprise valuable trade secrets of, Symbolics, Inc., which intends ;;;> to keep such software, data, and information confidential and to preserve ;;;> them as trade secrets. They are given in confidence by Symbolics pursuant ;;;> to a written license agreement, and may be used, copied, transmitted, and ;;;> stored only in accordance with the terms of such license. ;;;> ;;;> Symbolics, Symbolics 3600, Symbolics 3670 (R), Symbolics 3675 (R), Symbolics ;;;> 3630, Symbolics 3640, Symbolics 3645 (R), Symbolics 3650 (R), Symbolics 3653, ;;;> Symbolics 3620 (R), Symbolics 3610 (R), Symbolics Common Lisp (R), ;;;> Symbolics-Lisp (R), Zetalisp (R), Genera (R), Wheels (R), Dynamic Windows (R), ;;;> SmartStore (R), Semanticue (R), Frame-Up (R), Firewall (R), Document Examiner (R), ;;;> Delivery Document Examiner, "Your Next Step in Computing" (R), Ivory, MacIvory, ;;;> MacIvory model 1, MacIvory model 2, MacIvory model 3, XL400, XL1200, XL1201, ;;;> Symbolics UX400S, Symbolics UX1200S, NXP1000, Symbolics C, Symbolics Pascal (R), ;;;> Symbolics Prolog, Symbolics Fortran (R), CLOE (R), CLOE Application Generator, ;;;> CLOE Developer, CLOE Runtime, Common Lisp Developer, Symbolics Concordia, Joshua, ;;;> Statice (R), and Minima are trademarks of Symbolics, Inc. ;;;> ;;;> RESTRICTED RIGHTS LEGEND ;;;> Use, duplication, and disclosure by the Government are subject to restrictions ;;;> as set forth in subdivision (c)(1)(ii) of the Rights in Technical Data and Computer ;;;> Software Clause at DFAR 52.227-7013. ;;;> ;;;> Symbolics, Inc. ;;;> 6 Concord Farms ;;;> 555 Virginia Road ;;;> Concord, Massachusetts 01742-2727 ;;;> United States of America ;;;> 508-287-1000 ;;;> ;;;> ***************************************************************************************** ;;;> I think that we'll move all of the symbols specific to Firewall into a new package, called Firewall. This should not prove to be a problem for you, I assume. Chapter 3 Page 1: I'm still not happy with the phrase login procedure. "Login procedure" sounds to me like the application writer has to take responsibility for writing the LOGIN function. That's not true. All the AD has to do is decide where the system should prompt for logging in, if at all. I think that this reference to "login procedure" should be changed to "an easy way to log in" and that other references should be changed to other things as appropriate. "Should be defined" sounds like the terms won't be defined, but should be. How about "should be understood"? Under D,#TD1PsT[Begin using 006 escapes](1 0 (NIL 0) (NIL :ITALIC NIL) "CPTFONTI")application window0, "might be exposed by default" should be "will be exposed by default." -- For now, I will give you a copy of the Jabberwocky thing that you can use. Something better will be forthcoming. -- For now, I will give you a picture of my checkbook balancing program to use as the application. ---------------- Page 2: "Should I create a user login for the application?" See above. I think this should read something like "How do I wish my users to log in, if at all?" "Symbolics legal obligations" should be "Symbolics' legal obligations". This is an example of how to draw the copyright window. (define-copyright-window-drawer (stream) (dotimes (i 3) (terpri stream)) (dw:in-sub-window (stream 300 200 300 200) (dw:surrounding-output-with-border (stream :shape ':oval :thickness 2) (format stream "Balancing Your Checkbook"))) (dotimes (i 3) (terpri stream)) (indenting-output (stream 5) (filling-output (stream) (format stream "~%Welcome to the checkbook balancer.") (dotimes (i 300) (write-string " Blah." stream))))) (2 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB")DEFINE-COPYRIGHT-WINDOW-DRAWER0 1STREAM 0You use the define-copyright-window-drawer macro to define how the copyright window is exposed. It takes one argument, a stream variable. You should do all your input and output to this stream. Page 4: "Define a function that prompts ..." should be "Declare that the system should prompt on the copyright window for the end-user to log in, making the copyright window disappear when the end-user logs in." APPWINDOW  (defun firewall:select-initial-application () (cp:execute-command "Select Activity" "Checkbook")) However, there needs to be more description. Basically, you need to explain that a Lisp Listener will be exposed unless the function firewall:select-initial-application is defined. If it's defined, the system will run it (assuming that this function will create and select the application window). The above is an example of how to define this function in such a way that it creates and selects the application properly. In general, I recommend that (cp:execute-comand "Select Activity" ...) be the body of this function. I'd rewrite the Login Procedure stuff so it sounds more like: "Another item to consider while customizing your initial windows is how your end users should login. ... For instance, you might ... The bulletted items seem fine. ---------------- Page 5: In the 2Caution:0, I still think that "a Lisp Listener" should be changed to "Genera". It will not necessarily be a Lisp Listener that does the prompting. I am not reading the flowchart in any great detail. If you claim that it represents the one you showed me on paper, then I believe you. However, I think that Step 28 sounds funny, since I don't think that Firewall offers much "protection" in any case. I think that sentence should be scrapped in favor of something like "Will this be confusing to your end-users?" Chapter 4 Page 1: I believe that for the final release of the documentation, this first page will need to be fleshed out. I do not believe that it will be enough for us to simply say "read the documentation on error handling." I will try to write something about error handling to give you an example of what I'd like to see. As far as today's deadline is concerned, however, I don't care about this. ---------------- Page 2: The argument list for WITH-FRIENDLY ABORTING (which will be in the firewall package) should look like WITH-FRIENDLY-ABORTING 1((&key (debugger t) (bug-report t)) &body body) 0Point out that, even though OK is equivalent to hitting "Abort", existing error-system tools (condition-bind, etc.) allow the AD to assign Abort to anything he or she wishes. So this isn't really that restrictive. Point out a nice positive thing, too. The friendly menu can be typed at! The user will be able to type c-N and c-P to move up and down it, and hitting the "Abort" key is equivalent to clicking on "OK". Also, if the user begins to type the characters in one of the choices, as in "Sen" (short for Send a Bug Report), that item will become highlighted in such a way that hitting the "End" key will select it. (This is true, by the way, of all dynamic window menus.) Change the example description to read more like: For example, consider the following simple application, defined using DW:DEFINE-PROGRAM-FRAMEWORK. (Show the code, minus the italic part.) This application has one command, "This Is A Test", which prompts for an integer and then prints out the results of dividing 45 by that integer. Naturally, executing this command and passing in 0 as the argument will signal an error, which typically invokes the Debugger. However, you can change this behavior by using the :TOP-LEVEL option to define-program-framework to customize the default command loop by wrapping WITH-FRIENDLY-ABORTING around it, as in the example below. (Include the d-p-f form again, with the italic code this time.) Now, when the command encounters the error, the friendly menu pops up instead. Chapter 5 Page 1: [I feel uncomfortable about the use of "unfriendly" and such terms when describing the standard Genera environment. Perhaps "less friendly" would be more palatable?] "... or they flash inside the input ..." should be rephrased something like: "... or they are printed somewhere on your application, typically in an interaction area (a pane of type :INTERACTOR in Frame-Up). For example, notifications that come while Zmacs is exposed are printed in the minibuffer. You should say "interactor" wherever you currently say minibuffer. Perhaps "interactor" should be a defined term early on in this chapter. Page 2: One doesn't "insert variables into programs." One "sets" variables. You should say something like "Just have your application set the variable ..." A pointer should be given to the section that explains how the system decides how to deliver notifications. That's important for people to understand. Page 4: The example should be (send window :set-notification-mode :friendly) Page 5: Unless the description of :POP-UP, etc. is the physical record from the other part of the documentation, I think it should have :FRIENDLY in it as well. If it's the existing record inserted in place, I guess we're stuck. No big deal.