\begindata{text822, 0} Return-path: X-Andrew-Authenticated-as: 0;andrew.cmu.edu;Network-Mail Received: from po2.andrew.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Thu, 2 Dec 1993 04:27:54 -0500 (EST) Received: from po3.andrew.cmu.edu via qmail ID ; Thu, 2 Dec 1993 04:27:20 -0500 (EST) Received: from animal.cs.chalmers.se (animal.cs.chalmers.se [129.16.225.30]) by po3.andrew.cmu.edu (8.6.4/8.6.4) with SMTP id EAA28110; Thu, 2 Dec 1993 04:27:12 -0500 Received: from mumrik.cs.chalmers.se by animal.cs.chalmers.se (5.60+IDA/3.14+gl) id AA05129; Thu, 2 Dec 93 10:27:07 +0100 Received: by mumrik (5.60+IDA/3.14+gl) id AA04194; Thu, 2 Dec 93 10:27:06 +0100 Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.mumrik.pmax.ul4 via MS.5.6.mumrik.pmax_ul4; Thu, 2 Dec 1993 10:27:04 +0100 (MET) Message-Id: Date: Thu, 2 Dec 1993 10:27:04 +0100 (MET) From: Christer Bernerus X-Andrew-Message-Size: 988+0 Content-Type: X-BE2; 12 If-Type-Unsupported: send To: info-andrew@andrew.cmu.edu, Gary Keim Subject: Future of AMS (Was: Batmail/Ezmail) In-Reply-To: References: Distribution: world \begindata{text,19550388} \textdsversion{12} \template{messages} \define{quotation menu:[Region~4,Quotation~10] attr:[LeftMargin LeftMargin Inch 32768] attr:[RightMargin RightMargin Inch 32768] attr:[FontFace Italic Int Set]} \define{excerptedcaption attr:[LeftMargin LeftMargin Inch 32768] attr:[RightMargin RightMargin Inch 32768] attr:[FontFace Bold Int Set] attr:[FontFace Italic Int Set]} \excerptedcaption{Excerpts from info-andrew: 1-Dec-93 Re: Batmail/Ezmail Gary Keim@andrew.cmu.edu (705+0)} \quotation{We had started an effort to build and test Ezail and Macmail, which comes from the CMU campus computing group, but I think that it got temporarily shelved. That's too bad, IMHO, because it would make AMS much more viable to large organizations. }I agree (of course), but I've heard that there's a new mail system coming at CMU. So the question is whether it's a good idea to push for AMS here or if one should stick with the old smtp/nntp for a while and the make a big leap later on. Is there any information available on that project? \quotation{Of course, VUI comes with the standard AUIS release and that's what I happen to use. }Well, I've tried this many times and found it too confusing, e.g. using arrows for selecting in the menus doesn't work. Btw, is Andrew dying ? At least the amount of postings to info-andrew seems to approach nil, or has the discussion moved elsewhere ? Cheers! \italic{Chris\ }\enddata{text,19550388} \enddata{text822, 0} \begindata{text822, 3086} Return-path: X-Andrew-Authenticated-as: 1447;andrew.cmu.edu;Gary Keim Received: from rascal.andrew.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Thu, 2 Dec 1993 14:21:21 -0500 (EST) Received: from rascal.andrew.cmu.edu via qmail ID ; Thu, 2 Dec 1993 14:20:07 -0500 (EST) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.rascal.andrew.cmu.edu.rs.aix32 via MS.5.6.rascal.andrew.cmu.edu.rs_aix3; Thu, 2 Dec 1993 14:20:07 -0500 (EST) Message-ID: Date: Thu, 2 Dec 1993 14:20:07 -0500 (EST) From: Gary Keim X-Andrew-Message-Size: 792+0 Content-Type: X-BE2; 12 If-Type-Unsupported: send To: Info-Andrew Subject: Re: Fed up with NFS-mounted mail directories In-Reply-To: References: \begindata{text,540107112} \textdsversion{12} \template{messages} \define{keyword } \excerptedcaption{Excerpts from netnews.comp.soft-sys.andrew: 2-Dec-93 Re: Fed up with NFS-mounted.. Anthony A. Datri@dvorak. (406)} \quotation{*If* it happens to recognize the particular flavor of MIME in the message. }\quotation{Half the ones I get cause messages to mumble that it can't handle them. } I believe that's the result of a stupid memory trasher in the metamail integration that I did. If anyone is interested in fixing the bug, the details follow. You need to remove a single line of code from ./overhead/mail/metamail/metamail/metamail.c. It's around line 568: \example{ andrewPath = (\keyword{char} *) AndrewDir(stdpaths[1]); \keyword{if} (!ProcessMailcapFile(andrewPath, SquirrelFile)) \{ \red{ free(andrewPath); } \keyword{return}(0); \} } Remove the free(andrewPath) line and re-install metamail with a \typewriter{make Install}. -Gary Keim Andrew Consortium \enddata{text,540107112} \enddata{text822, 3086} \begindata{text822, 5371} Return-path: X-Andrew-Authenticated-as: 1447;andrew.cmu.edu;Gary Keim Received: from rascal.andrew.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Thu, 2 Dec 1993 14:31:17 -0500 (EST) Received: from rascal.andrew.cmu.edu via qmail ID ; Thu, 2 Dec 1993 14:30:11 -0500 (EST) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.rascal.andrew.cmu.edu.rs.aix32 via MS.5.6.rascal.andrew.cmu.edu.rs_aix3; Thu, 2 Dec 1993 14:30:10 -0500 (EST) Message-ID: Date: Thu, 2 Dec 1993 14:30:10 -0500 (EST) From: Gary Keim X-Andrew-Message-Size: 1382+0 Content-Type: X-BE2; 12 If-Type-Unsupported: send To: Info-Andrew Subject: Re: Future of AUIS In-Reply-To: References: Distribution: world \begindata{text,540107112} \textdsversion{12} \template{messages} \excerptedcaption{Excerpts from misc: 2-Dec-93 Future of AMS (Was: Batmail.. Christer Bernerus@cs.cha (988+0)} \quotation{Is there any information available on that project? } If someone from CMU Computing Services is lurking here, could you post a pointer to the design document that was written? Thanks. I think that it will take a significant amount of time to implement their plans and even then I'm not so positive that the final product will be significantly better than AMS to warrant the effort. Just MHO. \excerptedcaption{Excerpts from misc: 2-Dec-93 Future of AMS (Was: Batmail.. Christer Bernerus@cs.cha (988+0)} \quotation{Well, I've tried this (vui) many times and found it too confusing, e.g. using arrows for selecting in the menus doesn't work. } Yes, the idea is to type the first character of the menu item to highlight it but I agree that the arrow keys should work. I'll send a bug report. \excerptedcaption{Excerpts from misc: 2-Dec-93 Future of AMS (Was: Batmail.. Christer Bernerus@cs.cha (988+0)} \quotation{Btw, is Andrew dying ? At least the amount of postings to info-andrew seems to approach nil, or has the discussion moved elsewhere ? } No, everyone is just fully contented with the current release. ;^) This is the one, true forum for AUIS-talk. It's been a while since our last release and I think people are just waiting around for X11R6 before they don their \red{\italic{fire}}-retardant flame gear again. -Gary Keim Andrew Consortium \enddata{text,540107112} \enddata{text822, 5371} \begindata{text822, 8247} Return-path: X-Andrew-Authenticated-as: 1447;andrew.cmu.edu;Gary Keim Received: from rascal.andrew.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Thu, 2 Dec 1993 15:17:41 -0500 (EST) Received: from rascal.andrew.cmu.edu via qmail ID ; Thu, 2 Dec 1993 15:17:06 -0500 (EST) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.rascal.andrew.cmu.edu.rs.aix32 via MS.5.6.rascal.andrew.cmu.edu.rs_aix3; Thu, 2 Dec 1993 15:17:05 -0500 (EST) Message-ID: <4gzYp1m00gj4BF2sUR@andrew.cmu.edu> Date: Thu, 2 Dec 1993 15:17:05 -0500 (EST) From: Gary Keim X-Andrew-Message-Size: 642+0 Content-Type: X-BE2; 12 If-Type-Unsupported: send To: Info-Andrew Subject: Re: different fonts ? In-Reply-To: <2dj1u2$lqh@rubb.rz.ruhr-uni-bochum.de> References: <2dj1u2$lqh@rubb.rz.ruhr-uni-bochum.de> Distribution: inet \begindata{text,540107112} \textdsversion{12} \template{messages} \excerptedcaption{Excerpts from netnews.comp.soft-sys.andrew: 1-Dec-93 different fonts ? Ruediger Berlich@tau.ep1 (331)} \quotation{And how can I get the gnu groff to work with the shell-script used for }\quotation{printing (Postscript) ? } You'll need to first make sure that the groff distribution on your machine is complete and contains the ps fonts. Look for /usr/lib/groff/fonts/ps. If they aren't there, pick up a complete version from you local ftp site. Then, add the following line to the file /usr/andrew/etc/AndrewSetup: FormatCommand: cat /tmp/%s.n | gpic|gtbl|geqn|gtroff -Tps | grops | PrintCommand: lpr -h PreviewCommand: ghostview - -Gary Keim Andrew Consortium \enddata{text,540107112} \enddata{text822, 8247} \begindata{text822, 10243} Return-path: X-Andrew-Authenticated-as: 1447;andrew.cmu.edu;Gary Keim Received: from rascal.andrew.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Thu, 2 Dec 1993 16:13:31 -0500 (EST) Received: from rascal.andrew.cmu.edu via qmail ID ; Thu, 2 Dec 1993 16:12:41 -0500 (EST) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.rascal.andrew.cmu.edu.rs.aix31 via MS.5.6.rascal.andrew.cmu.edu.rs_aix3; Thu, 2 Dec 1993 16:12:37 -0500 (EST) Message-ID: Date: Thu, 2 Dec 1993 16:12:37 -0500 (EST) From: Gary Keim X-Andrew-Message-Size: 353+0 Content-Type: X-BE2; 12 If-Type-Unsupported: send To: Info-Andrew Subject: Re: Future of AUIS In-Reply-To: References: Distribution: world \begindata{text,539669016} \textdsversion{12} \template{messages} \excerptedcaption{Excerpts from misc: 2-Dec-93 Re: Future of AUIS Todd Inglett@rchland.ibm (63)} \quotation{Hmm...arrow keys work just fine for me in vui. } Yes, they work fine via xterm on my RS/6000 too. I do remember recently trying to use them, probably at home on my RT, and it didn't work. I'll check tonite. If anyone can reproduce this failure please report here. -Gary \enddata{text,539669016} \enddata{text822, 10243} \begindata{text822, 12073} Return-path: X-Andrew-Authenticated-as: 2971;andrew.cmu.edu;John Gardiner Myers Received: from hogtown.andrew.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Thu, 2 Dec 1993 16:17:21 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 2 Dec 1993 16:15:48 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 2 Dec 1993 16:15:45 -0500 (EST) Message-ID: Date: Thu, 2 Dec 1993 16:15:45 -0500 (EST) From: John Gardiner Myers To: Info-Andrew Subject: Cyrus (Andrew II) design document Beak: Is Cyrus (Andrew II) Mail Design Overview * Introduction This document describes the basic design of the Cyrus (Andrew II Electronic Mail) project. The purpose of the project is to provide an electronic mail system for users who use the Andrew system and any other organizational computing facility on campus that desires to use it. The system is divided into several loosely coupled components, each handling a different facet of electronic mail. The components are intended to be as independent of each other as is reasonable. This document describes the components and how they interact, but does not describe in detail the design of the individual components. Each component should implement the appropriate features listed in the Andrew II Mail Functional Requirements document, subject to design, resource, and performance constraints and each feature's priority. * Organization The remainder of this document contains a diagram of the components, followed by a section describing each component. * Overview User directory service ^ ^ | | | Authenticated delivery service | ^ | | | V | | Filing mechanism --> Notification service | | | | | V | | IMAP server <--> IMSP server | | ^ ^ | | | | +-----+----------- Client program ---------+ * IMAP (Internet Message Access Protocol) server The IMAP server provides storage and access for both mail and bboards. There will be more than one machine used to provide this service, and the configuration or implementation of the server may differ slightly between those machines used to provide access to mail and those machines used to provide access to to bboards. The servers provide clients dynamic access to messages through the IMAP protocol. The messages are stored on the local disk of the server--the server does not depend on a distributed file system. Some administrative tasks are outside the scope of IMAP and will most likely require the use of an internal, non-standard, protocol. * IMSP (Internet Message Support Protocol) server This server provides mail-related services that are either outside the scope of mail access or pertain to environments which must run more than one IMAP server. Services to be provided include: - Find IMAP server which has a given folder - Find next subscribed folder that has new messages - Maintain user subscription information - Maintain mail-related user options (preferences) - Manipulate mail-related access control lists The service will most likely be replicated across multiple servers for reliability. The servers will provide clients access using a protocol to be designed by us and standardized through the IMAP working group. To simplify client implementations, the protocol will be similar to IMAP in design. The mail support servers will have to communicate with the IMAP servers to obtain some necessary information, most likely through extensions to IMAP or a non-standard protocol. * User directory service This server maintains a database of users, similar in function to the existing "White Pages" database. It includes full name, unique mail ID (userid), and forwarding at the minimum. The server is used to provide "fuzzy-name matching" for address validation and delivery. The service will most likely be replicated across multiple servers for reliability. Two possible protocols for providing this service are CSO/ph and LDAP. * Authenticated delivery service This service provides delivery of mail, with authentication of mail between local users. The service will most likely be replicated across multiple servers for reliability. The servers transfer mail with other sites using the SMTP protocol. For authenticated delivery of mail from local users, the most likely protocol is SMTP with a locally developed Kerberos extension. Local clients without Kerberos support may submit unauthenticated mail using standard SMTP. The delivery system will continue to accept the "userid+ignored" notation. The canonical form of this may change to "userid=ignored" to conform to the increasing use of "=" in the Internet community. The delivery system will consult the user directory service to perform "fuzzy-name matching". * Filing mechanism This component, which runs on the IMAP servers, accepts mail from the delivery service and places it into appropriate folders. If necessary, a delivery report is given to the notification service. The ability to configure this mechanism is primarily for support of bulletin boards, though it may be possible for a non-administrative user to specify how their incoming mail is to be handled. The details of how this component works have not been worked out. There are three possible approaches: 1) The filing mechanism looks at the part of the address to the right of the "+". If the delivered-to user owns a mailbox with that name and the sending user has "post" permission to that mailbox, the message is appended to the mailbox. Otherwise, the message is appended to INBOX. 2) The user stores a control file in either the user directory service or the IMSP server. The control file is in some table-based language, specifying for example "messages with a subject containing 'foo' get filed in the mailbox 'bar'" and so on. The language would not be powerful enough to infinite-loop, invoke programs, or do other general-purpose things. 3) Users/systems that require more power than can be provided by (1) and/or (2) above will need to provide their own filing mechanism or smart IMAP client running on their own machine. (1) and (3) will most likely be done. Whether or not to do (2) will not be decided until the implementation is close to completion. A possible mechanism for handling filing is the commercial product Z-mail. It can be used for (3), but it is too powerful to be directly used for (2). * Notification service This component notifies users of new mail. Both direct methods, such as Zephyr, and polling methods, such as Mailcheck and finger, will be supported. Users who wish a high amount of privacy will be able to specify that information about the existence of their new mail is not to be made public. * Client program Client programs for each of the Mac, PC, Unix terminal, and X Windows platforms provide users access to the mail system. Each of the clients needs to support the IMAP, mail management, user directory, and Kerberized SMTP protocols. Support of these protocols will also necessitate support of Kerberos. Users will be able to store some mail folders locally instead of on the IMAP server. If the local file system supports a distributed filesystem such as AFS or DFS, they will be able to store some mail folders there. On the PC and Mac platforms, it is desirable for access to the mail system to be available through the VIM or MAPI API. This would allow commercial products, such as MS Mail, to use the Andrew II Mail system directly. This work is being considered, but is not currently planned. * Backup Servers which keep persistent databases (the IMAP, IMSP, and user directory services) will have to be backed up, presumably through the Andrew II backup service. * Administration Most of the protocols used by the mail system components support administration functions. This protocol support is used where feasible and ad-hoc protocols are devised where necessary. Administrative clients provide the administrative user access to the appropriate protocol support. The account creation, suspension, and deletion system will use the administrative clients to make appropriate changes to the various mail databases. * Monitoring Monitoring clients and SNMP agents provide the operations staff with real-time monitoring of critical components of the system, with alarms set to notify operators of apparent problems. These monitored components include, but are not limited to: - up/down status of each server machine - disk usage of each server - queue lengths Some end-to-end checks of the various services may be done on a periodic basis. Should these checks fail to be done, operations staff is notified. Additional data is monitored on both a real-time and periodic basis. This assists administrators with troubleshooting and provides them an indication of possible long-term problems. It also provides usage and load information to management for long term resource planning. This additional data includes, but is not limited to: - number of users - number of requests handled - system load - transaction logs - resource usage by user \enddata{text822, 12073} \begindata{text822, 21905} Return-path: X-Andrew-Authenticated-as: 1447;andrew.cmu.edu;Gary Keim Received: from rascal.andrew.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Fri, 3 Dec 1993 14:19:59 -0500 (EST) Received: from rascal.andrew.cmu.edu via qmail ID ; Fri, 3 Dec 1993 14:18:21 -0500 (EST) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.rascal.andrew.cmu.edu.rs.aix31 via MS.5.6.rascal.andrew.cmu.edu.rs_aix3; Fri, 3 Dec 1993 14:18:21 -0500 (EST) Message-ID: Date: Fri, 3 Dec 1993 14:18:21 -0500 (EST) From: Gary Keim X-Andrew-Message-Size: 627+0 Content-Type: X-BE2; 12 If-Type-Unsupported: send To: Info-Andrew Subject: Re: Messages MIME question. In-Reply-To: <1993Dec2.234801.19722@adobe.com> References: <1993Dec2.234801.19722@adobe.com> \begindata{text,539727592} \textdsversion{12} \template{messages} \excerptedcaption{Excerpts from netnews.comp.soft-sys.andrew: 2-Dec-93 Re: Messages MIME question... Zalman Stern@adobe.com (761)} \quotation{Does the MIME support have plug-in content type readers? } Any dataobject that provides the WriteOtherFormat() or ReadOtherFormat() method can participate in MIME. Bodypart that don't have a corresponding ATK dataobject are \italic{viewed} with metamail. I guess it would be good to allow for some runtime binding of a dataobject to a MIME content-type. For our next release (X11R6) we have subclasses of image for jpeg, gif, and p\{b,n,p,g\}m. Raster does xwd. Text does simple & rich text. -Gary Keim Andrew Consortium \enddata{text,539727592} \enddata{text822, 21905} \begindata{text822, 23888} Return-path: X-Andrew-Authenticated-as: 0;andrew.cmu.edu;Network-Mail Received: from andrew.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Tue, 7 Dec 1993 16:42:35 -0500 (EST) Received: from po5.andrew.cmu.edu via qmail ID ; Tue, 7 Dec 1993 16:37:46 -0500 (EST) Received: from MIT.EDU (ATHENA-AS-WELL.MIT.EDU [18.72.1.1]) by po5.andrew.cmu.edu (8.6.4/8.6.4) with SMTP id QAA28923; Tue, 7 Dec 1993 16:37:29 -0500 Received: from HANTA-YO.MIT.EDU by MIT.EDU with SMTP id AA28817; Tue, 7 Dec 93 16:37:11 EST Received: by hanta-yo.MIT.EDU (5.0/4.7) id AA07133; Tue, 7 Dec 93 16:33:44 EST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.hanta.yo.sun4.51 via MS.5.6.hanta-yo.sun4_51; Tue, 7 Dec 1993 16:33:43 -0500 (EST) Message-Id: <0h1DOr0GgE6e0OB9E0@mit.edu> Date: Tue, 7 Dec 1993 16:33:43 -0500 (EST) From: Bill Cattey To: info-andrew@andrew.cmu.edu, Gary Keim , Christer Bernerus Subject: Re: Future of AMS (Was: Batmail/Ezmail) In-Reply-To: References: Distribution: world Content-Length: 0 I hope that the Batmail/Ezmail effort gets picked back up. I use vui too. Every time I do, I become more convinced that the User Interface was intended to be slow torture, not actually for reading one's mail. I mean, why allow a space to go forward a screenful of mail when you can make the user stretch one hand, or employ two hands for ^v. Why allow a user to go back with a delete key or backspace when you can make them type escape and v? I mean emacs compatibility is nice, but it should be an option rather than the only way, and emacs doesn't come up by default in overstrike mode. NOTHING ELSE in ATK does! And it still doesn't explain such design as: Why make it easier than "dn" to delete the current message and view the next one? Anyway, enough flammage. -wdc \enddata{text822, 23888} \begindata{text822, 26273} Return-path: X-Andrew-Authenticated-as: 0;andrew.cmu.edu;Network-Mail Received: from po5.andrew.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Fri, 10 Dec 1993 02:14:31 -0500 (EST) Received: from po2.andrew.cmu.edu via qmail ID ; Fri, 10 Dec 1993 02:10:44 -0500 (EST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by po2.andrew.cmu.edu (8.6.4/8.6.4) with SMTP id CAA04150; Fri, 10 Dec 1993 02:10:40 -0500 Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <14687(3)>; Thu, 9 Dec 1993 23:10:26 PST Received: by holmes.parc.xerox.com id <16134>; Thu, 9 Dec 1993 23:10:16 -0800 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41 via MS.5.6.holmes.parc.xerox.com.sun4_41; Thu, 9 Dec 1993 23:10:12 -0800 (PST) Message-ID: Date: Thu, 9 Dec 1993 23:10:12 PST Sender: Bill Janssen From: Bill Janssen To: info-andrew@andrew.cmu.edu, Gary Keim , Christer Bernerus , Bill Cattey Subject: Re: Future of AMS (Was: Batmail/Ezmail) In-Reply-To: <0h1DOr0GgE6e0OB9E0@mit.edu> References: <0h1DOr0GgE6e0OB9E0@mit.edu> Distribution: world Excerpts from ext.andrew: 7-Dec-93 Re: Future of AMS (Was: Bat.. Bill Cattey@mit.edu (813) > Every time I do, I become more convinced that the User Interface was > intended to be slow torture, not actually for reading one's mail. I'm afraid I'm with wdc on this one. I can't bring myself to use VUI. Bill \enddata{text822, 26273} \begindata{text822, 28318} Return-path: X-Andrew-Authenticated-as: 0;andrew.cmu.edu;Network-Mail Received: from andrew.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Fri, 10 Dec 1993 02:38:02 -0500 (EST) Received: from po5.andrew.cmu.edu via qmail ID ; Fri, 10 Dec 1993 02:36:07 -0500 (EST) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by po5.andrew.cmu.edu (8.6.4/8.6.4) with SMTP id CAA24709 for ; Fri, 10 Dec 1993 02:35:59 -0500 Received: from [192.48.200.95] by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for info-andrew@andrew.cmu.edu id AA02396; Thu, 9 Dec 93 23:35:55 -0800 Received: by shamu.csd.sgi.com (930416.SGI/911001.SGI) for @sgi.sgi.com:info-andrew@andrew.cmu.edu id AA05009; Thu, 9 Dec 93 23:35:50 -0800 Date: Thu, 9 Dec 93 23:35:50 -0800 From: krishna@shamu.csd.sgi.com (Krishna `Shamu' Sethuraman) Message-Id: <9312100735.AA05009@shamu.csd.sgi.com> To: info-andrew@andrew.cmu.edu Subject: cui.el Reply-To: krishna@sgi.com X-Face: (pBgAhf!8i+tk8#bm9mBS_ba=:f1qemMN3Zc>~TZ<13!BD:p*Ot_dRf+N$8GmBJOA4nc'2ZGt('o}ykqY>gQ4d`r8JBpL`#2jMr+jvg(61m:_(m"X)JdG"3^QTI1"CA\4_W#6i~vpL- I'm coming out of a fairly long dormancy to post my first attempt at an emacs interface to cui. This was before I knew enough about communicating asynchronously with processes to make it really robust code, but I don't have messages here (sniff), thusly am doomed to hacking emacs rmail. I can count on the fingers of one hand the number of gui's that I've chosen to use over the corresponding text/curses versions containing the same functionality, and `messages' was one of them. But alas, it is not to be at my site, he said, an imaginary tear flowing down his cheek. I can't do any testing/bugfixing on this, but I'll give what help I can to anyone who dares to grow/cannibalize this code. Krishna `Resigned to Rmail' Sethuraman krishna@sgi.com --- Disclaimer follows --- This is most assuredly a first pass. It's got a ways to go. Unfortunately, I don't have Andrew or messages where I work, so I doubt I'll be able to do any fixing up of this. Also, it's kind of asynchronous, but if you send it too much too fast, it'll bite it. Best of luck. --- Code follows --- ; cui.el - emacs front-end to Andrew messages common user interface (cui) ; Copyright (C) 1991 Krishna `Shamu' Sethuraman ; ; This program is free software; you can redistribute it and/or modify ; it under the terms of the GNU General Public License as published by ; the Free Software Foundation; either version 1, or (at your option) ; any later version. ; ; This program is distributed in the hope that it will be useful, ; but WITHOUT ANY WARRANTY; without even the implied warranty of ; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ; GNU General Public License for more details. ; ; You should have received a copy of the GNU General Public License ; along with this program; if not, write to the Free Software ; Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. (defvar cui-folders-table '(("AndrewNews" . "AndrewNews") ("BurmaShave" . "BurmaShave") ("CompactDisc" . "CompactDisc") ("ConsultingMail" . "ConsultingMail") ("Drafts" . "Drafts") ("Man" . "Man") ("Minicourses" . "Minicourses") ("MyDrafts" . "MyDrafts") ("Parents" . "Parents") ("QuarterSink" . "QuarterSink") ("SkiBums" . "SkiBums") ("Stories" . "Stories") ("mail" . "mail") ("staff" . "staff") )) (defvar cui-headers-buffer-name "*CUI Headers*") (defvar cui-show-buffer-name "*CUI Show*") (get-buffer-create cui-show-buffer-name) (defvar cui-output-buffer (get-buffer-create "CUI Crud")) (defvar cui-prompt "\C-k") (defvar cui-init-string nil) (defvar cui-current-folder nil) (setq cui-init-string (concat "set level wizard;set scriptmode on set terminal 0 " (screen-width) " set prompt \C-k set scriptmode off ")) (defvar cui-deleted-msgs nil "List of messages marked for removal, but not yet expunged.") (defvar cui-headers-mode-map (make-keymap)) (suppress-keymap cui-headers-mode-map) ; now all we need is cui-quit, cui-check, and cui-delete! (define-key cui-headers-mode-map "." 'cui-display-current-message) (define-key cui-headers-mode-map "n" 'next-line) (define-key cui-headers-mode-map "p" 'previous-line) (define-key cui-headers-mode-map " " 'cui-page-msg) (define-key cui-headers-mode-map "\177" 'cui-previous-page) (define-key cui-headers-mode-map "c" 'cui-command-default-proc) (define-key cui-headers-mode-map "v" 'cui-visit-folder) (define-key cui-headers-mode-map "d" 'cui-mark-delete-current-message) (define-key cui-headers-mode-map "u" 'cui-mark-undelete-current-message) (define-key cui-headers-mode-map "x" 'cui-expunge) (defun cui-command-default-proc (string) (interactive "sCui command: ") (cui-command cui-process string)) (defun cui-command (proc string) "Send the string to the cui process." ; for some reason, we need a filter here. Setting to nil causes segviol, ; and it won't output to a buffer anyways. (set-process-filter proc '(lambda (prc string) (save-window-excursion (switch-to-buffer cui-output-buffer) (goto-char (point-max)) (insert string) (set-marker (process-mark prc) (point-max)) ))) (process-send-string proc (concat string "\n"))) ; stolen from mh-e.el (defun cui-page-msg (&optional arg) "Page the displayed message forwards ARG lines or a full screen if no argument is supplied." (interactive "P") (scroll-other-window arg)) (defun cui-previous-page (&optional arg) "Page the displayed message backwards ARG lines or a full screen if no argument is supplied." (interactive "P") (save-excursion (other-window 1) (unwind-protect (scroll-down arg) (other-window -1)))) (defun cui-headers-mode () "Mode for cui headers." (interactive) (use-local-map cui-headers-mode-map) (setq mode-name "CUI HEADERS" major-mode 'cui-headers-mode) (run-hooks 'cui-headers-mode-hook) ) (defun cui () "Initialize CUI and start by visiting mail in buffer, with current date." (interactive) (cui-initialize) (delete-other-windows) (let ((tyme (current-time-string))) (cui-visit-folder "mail" (concat (substring tyme 8 10) "-" (substring tyme 4 7) "-" (substring tyme 20)))) (split-window) (other-window 1) (switch-to-buffer cui-show-buffer-name) (goto-char (point-min)) (other-window -1) ) (defun cui-initialize () "Starts CUI" (interactive) (set-default 'cui-current-folder nil) (make-variable-buffer-local 'cui-current-folder) (setq cui-process (start-process "Process CUI" cui-output-buffer "cui")) (set-process-filter cui-process nil) (send-string cui-process cui-init-string) (message "Starting CUI (Krishna's hack client :0)") (accept-process-output cui-process) ) (save-window-excursion (defvar nice (progn (split-window) (other-window 1) (switch-to-buffer cui-show-buffer-name) (current-window-configuration) )) ) (defun cui-mark-delete-current-message () "Deletes message on the current line. Note that this does not call the actual cui command `delete', only generates a list of message numbers. cui-expunge calls the cui command `delete' on this list of numbers, and then calls `purge'." (interactive) (save-excursion (beginning-of-line) (if (looking-at "^\\([0-9]+\\) *[^D] *[0-9]") (cui-delete-msg (string-to-int (buffer-substring (match-beginning 1) (match-end 1)))) (error "Not looking at non-deleted message.") ) (setq buffer-read-only nil) (forward-char 4) (insert "D") (delete-char 1) (setq buffer-read-only t) (message "Marked message %s for deletion." (buffer-substring (match-beginning 1) (match-end 1))) ) ) (defun cui-mark-undelete-current-message () "Undeletes message on the current line. Note that this does not call the actual cui command `undelete'. See documentation for cui-mark-delete-current-message." (interactive) (save-excursion (beginning-of-line) (if (looking-at "^\\([0-9]+\\) *D ") (cui-undelete-msg (string-to-int (buffer-substring (match-beginning 1) (match-end 1)))) (error "Not looking at deleted message.") ) (setq buffer-read-only nil) (forward-char 4) (delete-char 1) (insert " ") (setq buffer-read-only t) (message "Undeleted message %s." (buffer-substring (match-beginning 1) (match-end 1))) ) ) (defun cui-expunge () "Expunges deleted messages. Note that it calls the cui commands `delete' and then `purge', so anything marked for deletion not through emacs (i.e., messages, vui, cui text client) will not appear in the buffer, but will be purged nonetheless." (interactive) (let ((msg-string (mapconcat 'int-to-string cui-deleted-msgs " "))) (save-window-excursion (switch-to-buffer (get-buffer-create "*CUI deleted*")) (erase-buffer) (insert msg-string) (fill-region (point-min) (point)) (if (yes-or-no-p "Sure you want to permanently remove all deleted messages? ") (progn (cui-command cui-process (concat "delete " msg-string "; purge")) (setq cui-deleted-msgs nil)) (error "Messages not expunged.")) ) ) ) ; to undelete a message, given a list of messages already ; currently marked, keep nth'ing through the length of the list. Then ; when you get to that element, do the nthcdr of that same number, and ; tack it onto the original list section to the prior point. This is ; done by (append nthcdr'ing at the right point ; nthcdr'ing at (length - element-number) of reversedlist) ; or we can use delq :0| (defun cui-delete-msg (msg) "Marks message for deletion (by adding to list)." (if (memq msg cui-deleted-msgs) (error "Message %d already marked for removal." msg) (setq cui-deleted-msgs (cons msg cui-deleted-msgs)) ) ) (defun cui-undelete-msg (msg) "Unmarks message for deletion (by removing from to list)." (if (memq msg cui-deleted-msgs) (setq cui-deleted-msgs (delq msg cui-deleted-msgs)) (error "Message %d not marked for removal." msg) ) ) (defun cui-display-current-message () "Do window config stuff and extract number of current message, and then display it in a pleasing window configuration." (interactive) (beginning-of-line) (save-window-excursion (if (looking-at "^\\([0-9]+\\)") (cui-show-msg (string-to-int (buffer-substring (match-beginning 1) (match-end 1)))) (message "error, you naughty individual you")) (while cui-still-accepting-show-output (accept-process-output cui-process)) ) (save-window-excursion (other-window 1) (goto-char (point-min))) ) (defun cui-visit-folder (name date) ; make date optional by only adding the `since' if date is non-nil "Retrieves headers from folder NAME since DATE." (interactive (list (let ((completion-ignore-case t)) (completing-read "Folder Name: " cui-folders-table nil t)) (read-input "Date: "))) (switch-to-buffer (get-buffer-create (concat cui-headers-buffer-name ":" name))) (setq cui-current-folder name) (setq buffer-read-only nil) (cui-headers-mode) (erase-buffer) (set-process-filter cui-process 'cui-headers-filter) (send-string cui-process (concat "headers " name " since " date "\n")) (accept-process-output cui-process)) (defun cui-show-msg (number) "Dumps the numbered message into the default buffer." (interactive "NMessage number: ") (switch-to-buffer (get-buffer-create cui-show-buffer-name)) (erase-buffer) (set-process-filter cui-process 'cui-show-filter) (setq cui-still-accepting-show-output t) (send-string cui-process (format "type %d\n" number)) (message "Retrieving message %d" number) (accept-process-output cui-process)) (defun cui-headers-filter (proc output) "Output filter to be called when CUI spits out something during scans." (string-match cui-prompt output) (save-window-excursion (setq buffer-read-only nil) (goto-char (point-max)) (insert (substring output 0 (if (string-match cui-prompt output) (match-beginning 0) (length output)))) (set-marker (process-mark proc) (point-max)) (setq buffer-read-only t) )) (defun cui-show-filter (proc output) "Output filter to be called when CUI spits out something during shows." ; (string-match cui-prompt output) (save-window-excursion (goto-char (point-max)) (insert (substring output 0 (if (string-match cui-prompt output) (match-beginning 0) (length output)))) (set-marker (process-mark proc) (point-max)) (if (string-match cui-prompt output) (setq cui-still-accepting-show-output nil)) )) \enddata{text822, 28318} \begindata{text822, 41484} Return-path: X-Andrew-Authenticated-as: 38;andrew.cmu.edu;Susan Straub Received: from muffin.atk.cs.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Tue, 14 Dec 1993 15:52:47 -0500 (EST) If-Type-Unsupported: send Received: from muffin.atk.cs.cmu.edu via qmail ID ; Tue, 14 Dec 1993 15:40:59 -0500 (EST) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.muffin.atk.cs.cmu.edu.rs.aix31 via MS.5.6.muffin.atk.cs.cmu.edu.rs_aix3; Tue, 14 Dec 1993 15:40:58 -0500 (EST) Message-ID: Date: Tue, 14 Dec 1993 15:40:58 -0500 (EST) From: Susan Straub X-Andrew-Message-Size: 40516+1 Content-Type: X-BE2; 12 To: Info-Andrew Subject: The Andrew View V.2, 3 \begindata{text,539667488} \textdsversion{12} \template{default} \define{global } \define{itemize menu:[Region~4,Itemize~31] attr:[LeftMargin LeftMargin Inch 32768]} \define{enumerate menu:[Region~4,Enumerate~30] attr:[LeftMargin LeftMargin Inch 32768]} \define{programexample menu:[Region~4,ProgramExample~13] attr:[LeftMargin LeftMargin Inch 32768] attr:[Justification LeftJustified Point 0] attr:[FontFace FixedFace Int Set] attr:[FontFamily AndyType Int 0]} \define{excerptedcaption } \define{literal menu:[Region~4,Literal~62] attr:[Flags PassThru Int Set]} \define{black menu:[Color,Black] attr:['color' 'Black']} \define{red menu:[Color,Red] attr:['color' 'Red']} \define{green menu:[Color,Green] attr:['color' 'Green']} \define{blue menu:[Color,Blue] attr:['color' 'Blue']} \define{magenta menu:[Color,Magenta] attr:['color' 'Magenta']} \define{cyan menu:[Color,Cyan] attr:['color' 'Cyan']} \define{yellow menu:[Color,Yellow] attr:['color' 'Yellow']} \define{helv } \begindata{raster,539545192} 2 0 32768 32768 0 0 366 437 bits 539545192 366 437 r04zs | r04zs | r04zs | r06zs | r06zs | r06zs | r07zs | r0780zr | r07c0zr | r07e0zr | r0ff0zr | r0ff0zr | r0ff8zr | r0ff8zr | r0ffczr | r0ffczr | r1ffezr | r1fGzr | r1fGzr | r1fG80zq | r1fGc0zq | r1fGc0zq | r1fGe0zq | r1fGe0zq | r1fGf0zq | r1fGf0zq | r1fGf8zq | r1fGf8zq | r1fGfczq | r1fGfczq | r1fGfezq | r1fGfezq | r1fHzq | r1fHzq | r1fH80zp | r1fH80zp | r1fHc0zp | r1fHc0zp | r1fHe0zp | r1fHe0zp | r1fHf0zp | r1fHf0zp | r0fHf0zp | r0fHf8zp | r0fHf8zp | r0fHfczp | r0fHfczp | r0fHfczp | r07Hfezp | r07Hfezp | r07Hfezp | r07Izp | r07Izp | r07I80zo | r03I80zo | r03I80zo | r03Ic0zo | r03Ic0zo | r01Ie0zo | r01Ie0zo | r01If0zo | r01If0zo | sIf8zo | sIf8zo | sIfczo | sIfezo | s7fHfezo | s7fIzo | s3fI80zn | s3fI80zn | s1fIc0zn | s1fIe0zn | s0fIe0zn | s0fIf0zn | s07If0zn | s07If8zn | s03Ifczn | s01Ifezn | s01Ifezn | tJzn | t7fI80zm | t3fIc0zm | t3fIe0zm | t1fIf0zm | t0fIf8zm | t07Ifczm | t03Ifezm | t01J80zl | uJc0zl | u7fIe0zl | u3fIf8zl | u1fIfczl | u07Jzl | u03J80zk | u01Je0zk | v7fIf0zk | v3fIf8zk | v1fIfezk | v0fJ80zj | v03Je0zj | v01Jf0zj | w7fIfczj | w1fJzj | w07Jc0zi | w01Jf0zi | x7fIfczi | x1fJzi | x07Jc0zh | x01Jf0zh | y3fIfczh | y0fJzh | y03Jc0zg | zJf8zg | z3fJzg | z0fJe0n10q | z03Jfcn10q | zgK80m30q | zg1fJf0me0q | zg03Jfel3fc0q | zh7fJc0j1fG80 q | zh07Jfci1fGfe r | ziKc0g1fHfcr | zi1fOf0r | zi01Oc0r | zj07Ns | zk1fLfcs | zj07Mf0s | zi03Nc0s | ziOt | zh0fNfct | zhOf0t | zg0fOc0t | zgPu | z0fOfcu | zPf0u | y0fPc0u | yPfev | x0fPf0v | xQw | w0fPf8w | wQ80w | v0fPf8x | vQ80x | u0fPf8y | uQ80y | t0fPf8z | tQ80z | s0fPf8zg | r01Q80zg | r3fPf8zh | q03Q80zh | q3fPf8zi | p03Q80zi | p3fPf8zj | o03Q80zj | o7fPf8zk | n07Q80zk | nQf8zl | m0fQ80zl | m7fPf8zm | l07Q80zm | l7fPf8zn | k07Q80zn | k7fPf8zo | j07Q80zo | jQf8zp | i1fQ80zp | h0fQf8zq | c03fR80zq | 7fRf8zr | 1fR80zr | 0fQf8zs | 07Q80zs | 03Pf0zt | gPzu | g7fNf0zu | g1fMfezv | g07Mc0zv | hLfczw | h0fLc0zv | iLf8zv | i0fKfezv | jL80zu | j0fKe0zu | kKf8zu | k0fJfezu | l7fJ80zt | l07Je0zt | m7fIf8zt | m03Ifezt | n1fI80zs | n07Ie0zs | o7fHf8zs | o0fHfezs | o01I80zr | p3fHe0zr | p07Hf8zr | p01Hfezr | q3fH80zq | q0fHe0zq | q03Hf8zq | rHfezq | r3fH80zp | r1fHe0zp | r07Hf8zp | r03Hfezp | sI80zo | s7fHe0zo | s1fHf8zo | s07Hfezo | s03I80zn | tIc0zn | t3fHe0zn | t1fHf8zn | t07Hfczn | t03Hfezn | t01I80zm | uIc0zm | u7fHe0zm | u3fHf0zm | u1fHf8zm | u0fHfczm | u07Hfezm | u03Izm | u01I80zl | vIc0zl | v7fHe0zl | v3fHf0zl | v1fHf8zl | v1fHfczl | v0fHfezl | v07Izl | v03I80zk | v01Ic0zk | v01Ie0zk | wIf0zk | w7fHf8zk | w3fHf8zk | w1fHfczk | w1fHfezk | w0fIzk | w07Izk | w03I80zj | w01Ic0zj | w01Ie0zj | xIe0zj | x7fHf0zj | x3fHf0zj | x1fHf8zj | x1fHfczj | u7f80g0fHfcm10 v | u7f80g07Hfem30 v | u7f80g07Hfem70 v | uGc0g03Il01f0 v | uGc0g01I80kGf0 v | uGc0g01I80kGf0 v | t01Ge0hIc0kGf0 v | t01Ge0h7fHe0k 07f0v | t01Ge0h7fHe0k 07f0v | t03Gf0h3fHf0k 07f0v | t03Gf0h1fHf0k 07f0v | t03Gf0h1fHf8k 07f0v | t07Gf8h0fHfck 07f0v | t07Gf8h0fHfck 07f0v | t07Gf8h07Hfek 07f0v | t0fGfch03Gf7fe k07f0v | t0fGfch03Gc7G k07f0v | t0fGfch01G87e0 k07f0v | t1fGfeh01fe07 80k07f0v | t1fGfeif806l07 f0v | t1f8ffej04l07 f0v | t3f8fGq07f0v | t3f8fGq07f0v | t3f07Gq07f0v | t7f07G80p07f0 v | t7f07G80i20j01 G87f0h40s | t7e03G80i600f f8h07Ge7f0hc0 70g01feg0fGf9 He03ffc | tfe03Gc0ie03f feh1fGf7f0g01 c1f8g0fGc00fG f9He03ffc | tfe03Gc0h03e0 Hh3fHf0g07c3fc g3fGf00fGf9He0 3ffc | tfc01Gc0g01Ge1 H80g7f83Gf007 Gc7feg7f8ff801 Gc01ffcg07c0 | s01fc01Ge0g01 Ge3Hc0gGgGf007 Gc7fegfe03fcg Gc00ff8g03c0 | s01fc01Ge0g01 Ge7Hc001feg7f f007GcfG01fc01 fegGc00ff8g03 80 | s01f8gGe0g01G efHe003fcg3ff0 07GcfG03f8gGg Ge007f8g0380 | s03f8gGf0h0fG 01Ge003f8g1ff0 g3fdf0f07f0g7f g7fe007fcg0380 | s03f8gGf0h0ffc g7ff007f8g1ff0 g3fde070fe0g3f 807fe007fcg07 g | s03f0g7ff0h0f f8g3ff007f0g0f f0g3ffc030fe0 g3f807ff003fc g07g | s07f0g7ff8h0f f0g1ff00ff0g0f f0g3ff8031fc0 g1fc03ff003fe g0fg | s07f0g7ff8h0f e0g1ff00ff0g07 f0g3ff0011fc0 g1fc03ff003fe g0eg | s07e0g3ff8h0f e0g0ff01fe0g07 f0g3fe0g3f80g 0fe03ff001feg 0eg | s0fe0g3ffch0f e0g0ff01fe0g07 f0g3fe0g3f80g 0fe01ff801Gg1e g | s0fe0g3ffch0f e0g0ff01fe0g07 f0g3fc0g3fIe0 1ff801Gg1cg | s0fc0g1ffch0f e0g0ff01fe0g07 f0g3fc0g7fIf0 1ff801Gg1cg | s1fc0g1ffeh0f e0g0ff03fe0g07 f0g3fc0g7fIf0 0ff803G803cg | s1fc0g1ffeh0f e0g0ff03fe0g07 f0g3fc0g7fIf0 0ffc03G8038g | s1f80g0ffeh0f e0g0ff03fe0g07 f0g3fc0g7f80i 0ffc03G8038g | s3f80g0fGh0fe0 g0ff03fe0g07f0 g3fc0g7fj07fc 07Gc078g | s3f80g0fGh0fe0 g0ff03fe0g07f0 g3fc0g7fj07fe 07Gc070g | s3fJh0fe0g0ff0 3fe0g07f0g3fc0 g7fj07fe073fc0 70g | s7fJ80g0fe0g0f f03fe0g07f0g3f c0g7fj03fe0f3f e0f0g | s7fJ80g0fe0g0f f03fe0g07f0g3f c0g7fj03G0e3f !e0g | s7eh03G80g0fe0 g0ff03fe0g07f0 g3fc0g7fj03G0e 1f!e0g | sfeh03Gc0g0fe0 g0ff03fe0g07f0 g3fc0g7fj01G1e 1ff1e0g | sfeh03Gc0g0fe0 g0ff03fe0g07f0 g3fc0g7fj01G9c 1ff1c0g | sfch01Gc0g0fe0 g0ff03fe0g07f0 g3fc0g7fj01G9c 0ff1c0g | r01fch01Ge0g0f e0g0ff03fe0g07 f0g3fc0g7fkGbc 0ffbc0g | r01fch01Ge0g0f e0g0ff03fe0g07 f0g3fc0g3f80j Gf80ffb80g | r01f8iGe0g0fe0 g0ff03ff0g07f0 g3fc0g3f80g07 e0gGf807fb80g | r03f8iGf0g0fe0 g0ff01ff0g0ff0 g3fc0g3f80g07 e0g7ff807G80g | r03f8iGf0g0fe0 g0ff01ff0g1ff0 g3fc0g1fc0g0f e0g7ff007Gh | r03f0i7ff0g0f e0g0ff00ff8g3f f0g3fc0g1fc0g 0fc0g7ff003Gh | r07f0i7ff8g0f e0g0ff00ffcg7f f0g3fc0g1fe0g 1fc0g3ff003Gh | r07f0i7ff8g0f e0g0ff007fegG f0g3fc0g0fe0g 3f80g3fe003fe h | r07e0i3ff8g0f e0g0ff007G03G f0g3fc0g0ff0g 7f80g3fe001fe h | r0fe0i3ffcg0f e0g0ff003Gc7G f8g3fc0g07f8g Gh1fe001feh | r0fe0i3ffcg0f e0g0ff001Hf7G c03fc0g03fc01 feh1fc001fch | r0fc0i1ffcg0f e0g0ff001Hf7G c03fc0g01G07fc h1fc001fch | r1fe0i3ffeg1f f0g1ff8gHe7Gc0 7fe0hHf8h0fc0 gfch | q01Gfeh07He1H 81H803fGc7c007 Gfeh3fGf0h0f80 gf8h | q01Gfeh07He1H 81H801fG87g07 Gfeh1fGc0h0f80 gf8h | q01Gfeh07He1H 81H8003fc06g07 Gfeh03feo | zn04w | zzl | zzl | zzl | zzl | zg1fHfczg | zg1fHfczg | zg1fHfczg | zg0fHfezg | zg0fHfezg | zg0fHfezg | zg0fHfezg | zg07Izg | zg07Izg | zg07Izg | zg07Izg | zg03I80z | zg03I80z | zg03I80z | zg03I80z | zg01Ic0z | zg01Ic0z | zg01Ic0z | zg01Ic0z | zhIe0z | zhIe0z | zhIe0z | zhIe0z | zh7fHf0z | zh7fHf0z | zh7fHf0z | zh7fHf0z | zh3fHf8z | zh3fHf8z | zh3fHf8z | zh3fHf8z | zh1fHf8z | zh1fHfcz | zh1fHfcz | zh1fHfcz | zh0fHfcz | zh0fHfcz | zh0fHfez | zh0fHfez | zh07Hfez | zh07Hfez | zh07Iz | zh07Iz | zh03Iz | zh03Iz | zh03Iz | zh03I80y | zh01I80y | zh01I80y | zh01I80y | zh01Ic0y | ziIc0y | ziIc0y | ziIc0y | ziIe0y | zi7fHe0y | zi7fHe0y | zi7fHe0y | zi7fHf0y | zi3fHf0y | zi3fHf0y | zi3fHf0y | zi3fHf8y | zi1fHf8y | zi1fHf8y | zi1fHf8y | zi1fHfcy | zi0fHfcy | zi0fHfcy | zi0fHfcy | zi0fHfey | zi07Hfej80t | zi07Hfej80t | zi07Ii0180t | zi07Ii0180t | zi03Ii0380t | zi03Ii0780t | zi03Ii0f80t | zi03I80h1f80t | zi01I80h3f80t | zi01I80h7fu | zi01I80hGu | zi01I80g01Gu | zjI80g03Gu | zjIc0g07feu | zjIc0g0ffeu | zjIc0g1ffcu | zj7fHe0g3ff8u | zj7fHe0g7ff0u | zj7fHe0gGe0u | zj7fHf001Ge0u | zj3fHf803Gc0u | zj3fHf807G80u | zj1fHfc0fGv | zj1fI3ffev | zj0fJfev | zj0fJfcv | zj07Jf8v | zj07Jf0v | zj03Je0v | zj01Je0v | zkJc0v | zk7fI80v | zk3fIw | zk1fHfew | zk0fHfcw | zk07Hf8w | zk03Hf0w | zlHe0w | zl3fG80w | zl07fex | zzl | \enddata{raster, 539545192} \view{rasterview,539545192,0,0,0} \formatnote{.sp -1.0i} \helv{\bold{\flushright{Andrew Consortium School of Computer Science Carnegie Mellon }}} \bigger{\bigger{\leftindent{\leftindent{\leftindent{\bold{The Andrew View }}}}}}\ \flushright{Volume 2, Number 3 December, 1993 } This month finds the Andrew Consortium staff relocated to temporary quarters in "Building D" while our former offices are being renovated. We are finishing up the C++ conversion, porting the C version to new platforms, working on printing, and thinking hard about how to do widgets. All this despite a bit of travel. \subsection{IP Address Changes} As part of our move, our machines were allocated new IP addresses. In particular: \leftindent{emsworth.andrew.cmu.edu is now 128.2.203.197 atk.itc.cmu.edu is now 128.2.203.218} Please use these addresses if the machines are not accessible by name from your environment. \subsection{First individual release delivered} The annual meeting considered and accepted the proposal to allow individuals to purchase copies of the most up-to-date AUIS sources. We are proud to announce that the first such has been delivered. \ _____________________________________________ \ \section{My own View} Wilfred J. Hansen, Director I reported in the last issue that I was about to present a paper at the Visual Languages Symposium in Bergen. Entitled "Andrew as a Multiparadigm Environment for Visual Languages" the paper showed how Andrew can serve as a basis for implementing multiple languages in a cooperating environment. Drop me a note if you'd like a copy of this paper. The Visual Languages Symposium as a whole was very interesting. As usual there were both visual languages and language visualization. The most interesting papers reported actual experiments. R. K. Panday and M. Burnett showed that users found it easier to write matrix operations in their visual language than in Pascal or APL. A. Apte and T. Kimura showed that drawing graphics took half as long with a pen as with a mouse. The results in another pen vs. mouse experiment reported by V. Citrin were less clear, but the paper reported interesting observations about the number of erasures and the tendency to get into complex and time consuming copy schemes in MacDraw. After my return from Bergen, I was invited to a workshop on visual languages at Scottsdale, Arizona, under the aegis of the Jet Propulsion Laboratory. I presented my visual languages talk there and then extended the trip to present the talk at Stanford University, Lawrence Livermore Laboratories, and Silicon Graphics. At the latter, I learned more about the state of Fresco from Mark Linton. Fresco is the C++ successor to Interviews, one of Linton's earlier projects, and is being defined and developed in conjunction with an industry-wide group. Fresco will be a toolkit offering a collection of widgets in an environment that has some of the properties of AUIS and some new features. The coordinate space is screen independent, and there is support for color and multi-threading. Some of the basic elements of Fresco are defined and implemented, but most of the superstructure is still undefined. \ At SIGCHI (April 24-28, 1994, Boston, Massachusetts) I will present a tutorial entitled "Introduction to User Interface Systems for HCI Developers and Researchers". This will discuss the Human-Computer Interface challenges and opportunities of user interface systems like AUIS, Fresco, OLE from MicroSoft, and OpenDoc originally from Apple and now from the Component Integration Laboratory (see article below). These systems offer the challenge of defining user interface schemes that extend across a wide spread of applications; they offer the opportunity to conveniently capture user interactions in order to study user behavior. _____________________________________________ \ \section{Annual Meeting Priorities for the year ahead} Discussion at the annual meeting, 24 June, 1993, was lively and established valuable priorities for the year ahead. The first priority was recognized as "Robustness": ease of use, no crashes, no installation problems. The last C release will have some of these properties, and we are working to build on them in the C++ release. Platforms to be supported with C++ release: RS/6000, HP/PA, PMAX Ultrix, Solaris 2, Alpha, Telmat, Pmax/Mach, Sun4/Mach, SGI, Linux. We would like to consider Win32 and Windows/NT, but resources may not permit. Dynamic loading is considered below. Widgets / Application Builder: Regularize the widget suite by cleaning up the API and the user interfaces. Improve consistency and documentation. The meeting decided that we should plan for an application builder, but that it is not a high priority. See the discussion of widgets below. Printing. This is the year to bite the troff bullet and spit it out. The printing methods, especially text, will directly produce PostScript; every inset will have a printing method. See the discussion below. Mail. No consensus on a mail strategy emerged. We have the MAC and PC interfaces used by CMU, but do not have manpower to exploit them. Moreover, CMU is converting to an IMAP based mail server system, which will require, at least, extensive revision of the existing messages package. Note, however, that between the 1992 and 1993 meetings we made the commitment to convert to C++. This is requiring most of 1993, so it is likely that the projects described above will not all be complete until the end of 1994. _____________________________________________ \ \section{Release plans} Release 6.1 is available and has been picked up by most members, though under the name 6.0.1. This release supports these platforms IBM RS/6000 AIX 3.1 and 3.2 DEC PMAX UL4 and Mach Sun OS 4c, 411, and Mach HP UX for levels 80 and 90 on 300, 700, and 800 We are in the process of completing ports to Sun Solaris, Linux, and Telmat. Solaris is completed except for a bug in VUI; however, the messages package fails on AFS due to an AFS bug that is corrected in the next AFS release. Members may get the Solaris or Linux version by asking for it. The Telmat version will be completed later this year. When these ports are completed, the software will be version 6.2. If there are no problems, this version will go on the X V11R6 tape; however, if corrections are needed, the X version will be 6.3. (The sources have some support for SGI, SCO Unix, and the Dec Alpha; however, we have not tested these nor debugged them completely. The IBM RT is no longer supported.) The first C++ version will be version 7.1 and will be released in January. (Previously I said it would be version 8, but this no longer seems appropriate.) Version 7.0 has been delivered already to one member and could be released to others. The C++ version currently has been tested on IBM RS/6000 AIX 3.1 and 3.2, HP UX level 80 and 90, and DEC PMAX Ultrix 4. Version 7.1 will support the Sun and will likely support the other platforms supported by version 6.2. Version 7.1 will not have support for dynamic loading, but it will be added in the next version. See below for a discussion of the design. _____________________________________________ \ \section{New and Revised Features in Version 6.1} Release 6.1 is a beta version of that which will appear on the X11 tape Release 6, at which time it will be available for users everywhere. The list below of changes from version 5.2 is derived from the code-change log entries. A more complete, and less polished, listing of those entries is available on request. \ \subsection{User visible changes} Added \bold{CheckOwnerHome} preference description. This value determines whether a lookup is done in order to find the home directory of the owner of a file being viewed by EZ. The file-owner's home directory is used to \italic{fold} the full pathname down to something shorter, like ~foo/bar for displaying in the title-bar of the EZ window. Defaults to: yes. \bold{ }Fixed and expanded the \bold{XStyleSelection} support. Added the preference CopyOnSelect. When yes, selecting text will automatically put it in the cutbuffer. (When/if any other views support the concept of "selection" in the X sense it will happen for them too.) Get rid of annoying dialog box when you run with \bold{ispell} 3; Added code to check to make sure ispell allows you to accept words and add them to the private dictionary (in -a mode, which is what spell.c uses.) If it does not, print an error message when the 'a' or 'i' key is hit. \ Rewrote help files to encourage use of \bold{lookz} over troff format notes. \ Added documentation of the \bold{tmacgrofffile} preference. \ \bold{Figure} has been revised to include printing in landscape mode. Added FigureMatteColor preferences (default white) which overrides the BackgroundColor preference for figure insets. Added a preference, \bold{ReadOnlyTitle}, which lets you set the "(readonly)" marker in a window's title bar to some other string. \ Implemented import of \bold{ppm} images into the image inset. Renamed the program "prefs" to "\bold{prefed}" so that help on the name will get the right help file. Made the default file the preferences file currently in use. Fixed so that the global.prf file will be read if it exists, and it's values will update the default values. \ \bold{ }\bold{Tab} stops are now measured from the beginning of each line, instead of the left margin. Justification/discussion available upon request. \ In path.c, we added a quoting mechanism so that environment variable expansion can be suppressed. A $$ sequence in a \bold{path} is converted to a single $. The argument to visit-file is canonicalized twice at present, so the file name '$HOME' has to be referenced as '$$$$HOME'. \bold{ }Changed "\bold{Append to [Raw] File}" options in messages to use datacat. A few improvements have been made to \bold{zip}: De-coupled show-grid and constrain-to-grid so you can see the grid independently of being locked onto it. Or you could constrain your drawing to the grid without waiting for it to redisplay all the time. Changed the algorithm for redrawing the grid to display the grid points correctly more often. Added setting of a print size which was carefully chosen not to break reading by older versions of zip. Added commands to specify the print size in inches and points. Changed zip to come up in absolute mode by default so that what you see is much closer to what you get. Set the initial print size, by a heuristic: PrintSize overrides ViewWidth/ViewHeight overrides ObjectWidth/ObjectHeight. \ \subsection{System Maintainer visible changes} The code has been revised throughout to increase gcc and ANSI compatibility. \ Ports have been incorporated for\bold{ DEC Alpha, Sun Solaris, Linux, HP/UX 9.01, and System V.} Most of these still have some problems because we are unable to test them fully. \ \bold{ }Added compile and installation of \bold{genstatl} and associated files. These provide for building AUIS binaries that do not utilize dynamic loading. LINKINSTALL_ENV is no longer the default. Its use is being discouraged. \subsection{Programmer visible changes} Had to add \bold{super_LinkTree} as first line of LinkTree in several cases-- if you don't have this, an inherited colormap will be set improperly. \ \bold{ }Added \bold{SetPatternOrigin}() method to atk/basics/common/graphic; this allows programs to align their grey-stipples however they want. Added empty, override-able version of graphic__ReadImage. Added empty stubs for SetBGColorCell and SetFGColorCell. \ \bold{ }Added \bold{ResizeWindow and MoveWindow} methods to im class. Added \bold{IsObserver} method to the observable class. \ \bold{ }New documentation for the \bold{traced} class (traced.doc). Added documentation explaining how to write \bold{preference descriptions} for the preferences editor (writing.prs). Added a programmer's interface to \bold{datacat}. \ Added \bold{AlwaysWrapViewChar} to wrap a viewref environment with a particular type of view and a particular dataobject, around an already existing viewref char. \ \bold{ }Introduced two new methods for text: \{Always,\}\bold{CopyWithAllStyles}. This is Fred's version of CopyText which copies all the styles enclosing the region being copied. \ \bold{ }Fixed \bold{Ness} to use CopyWithAllStyles. Now a copy of text will look exactly like the original. Modified the class preprocessor to allow machine independent trampoline code (written in C). \bold{ }Renamed \bold{regexp} functions to reg_*. \ _____________________________________________ \ \section{Dynamic Loading and C++} One of the most useful features of AUIS in C code--at least for program development--has been dynamic loading. We are implementing dynamic loading for the C++ version, but there will be some restrictions. Here are some of our considerations. \subsection{Desired features} 0. No compiler modifications. 1. Automatically load class code on demand, and not before. 2. Quick compile-link cycle for development. 3. The ability to develop objects which can be used with a runapp which has no knowledge of them. 4. Minimal run-time overhead for calls to dynamically loaded code, and for calls from dynamically loaded code to statically loaded code. (After the first time through.) 4. Support for global object constructors/destructors. 5. Retainment of the "debug-ability" of the code. (As long as the debugger supports dynamic loading.) 6. Minimal dependence on the symbol name mangling technique. 7. Retainment of the C++ style of function calls. (this->Blah()) 8. Portability \subsection{Deficiencies of available options} The AUIS C code dynamic loader relies on a preprocessor for the header files to define a macro for each method and static member function. For the latter, these macros initially call a piece of assembly language trampoline code which saves the register state, loads and registers the class, replaces the function pointer with a pointer to the real function, and finally calls the actual function. For C code, this approach makes function calls look normal, but the C++ syntax is different and cannot be emulated with macros. One possible approach with C++ is to generate a stub function for each function to be dynamically loaded. This stub would load the function, if needed, and then call it. Several problems arise in contemplating this approach, beginning with the difficulty of parsing C++ header files to generate the appropriate stubs. The fact that function names are mangled in some implementations is another complication. In any case, there would be an extra overhead for the call through the stub function. \subsection{Design chosen: Inheritance} To avoid the many problems, we have chosen a design that relies on inheritance. For each class C which is to be dynamically loaded, there must be a base class, CBase, which declares all the methods of C as virtual methods. CBase must have a static member function for creating objects of class C; this latter function will call on the system mechanism that dynamically loads the class implementation. In practice, ATK's view and dataojbect classes serve as CBase for all views and data objects, so there is no additional coding effort to implement new, dynamically-loadable objects of these classes. Comments and questions on this approach are welcome. _____________________________________________ \ \section{Printing direct to PostScript} The new printing architecture will print directly through PostScript, instead of via troff. One major effort will be implementation of line- and page-break algorithms, but considerable effort must also go to general organization. \ A print will now be initiated through the print::GeneratePS function, \smaller{static boolean print::GeneratePS(FILE *outfile, view *viewtoprint) ,} which sends a complete PostScript document to \italic{outfile}. It initializes the printing process, and then calls \italic{viewtoprint}->PrintPSDoc(), which causes \italic{viewtoprint} to print as a top-level document. The print class maintains a set of variables which affect how the document will print: landscape / portrait mode, scaling, printing multiple copies, printing a range of pages, output to file or printer, printer name, and view-dependent options such as \italic{print-footnotes-as-endnotes and} \italic{print-table-of-contents}. With the exception of printer name, each view has its own copy of these variables. The PrintPSDoc method for a view is entitled to consider the entire page as its own and to generate PostScript for as many pages as it likes. When a parent view wishes to print an inset view, it first calls the inset's GetPrintInterface method to determine how it wants to be handled. At the moment, three printtypes are defined: \ \leftindent{"\bold{generic}": The inset is given a rectangle, and draws itself in that rectangle. "\bold{styledgeneric}": Like "generic", but the parent provides information about the current font and style. "\bold{text}": The inset adapts itself within the parent text. It may provide some particular text data which the parent textview will stitch into the text stream it is laying out (textref, link, and timestamp do this, for example.) It may call back some special methods of textview which change how the textview is laid out (pagebreak, header, footnote). It may do stranger things. \ } The low-level text printing mechanism must be given a "layout plan"--a list of how wide the page (or column) will be at each point, and where logical breaks occur. (Logical breaks are the points which kept-together segments must not cross. They also mark where footnotes are to be inserted.) The mechanism then generates a data structure which represents the formatted text. This low-level structure contains everything one needs to print the lines of text: words, word positions, inset positions, fonts, underline positions. \ The textview::PrintPSDoc method uses this low-level structure to lay out the text on pages. Its layout plan is a constant width (the page-width) with logical breaks at regular intervals (the page-height). If the textview is being printed as a "generic" inset, the low-level structure is drawn into the printing rectangle. The layout plan is the same constant width, but there are no logical breaks. If the textview is being printed as an inset with the "text" printtype, the low-level structure is not used at all; instead, the text object is laid out in the parent's data structure, as if the child view had been cut and pasted into the parent. (I think this capacity is important, but I don't know of any current application for it. Things like annotations usually want to be printed in rectangles, the way they appear on the screen.) The low-level structure encodes all the formatting information implied by current AUIS styles, including: \leftindent{multiple fonts, font styles, font sizes \ insets that produce rectangular images on the page insets that produce text which is inserted in the text stream being printed indentation, line spacing, paragraph spacing \ baseline adjustment (super/subscripts) \ justification, margins, tabs \ color foreign characters (ISO 8859)} The following features are implemented by generating appropriate entries in the low-level data stream: \leftindent{footnotes \ index, table of contents information page numbering, headers/footers \ page breaks, setting the page number at a page break \ blocks of text which should always be kept together} Several features are not yet planned for implementation: \leftindent{multiple-pages- per-physical-page multiple columns flowing text around insets texttag, textref (for cross-references by page number) leader dots embedded user-written PostScript code print-time computations local spacing control overlaying characters hyphenation blocks of text that must not begin near the bottom of the page} It may be that other organizations of the print machinery could make it more expressive. If you have a suggestion, please let us know. _____________________________________________ \ \section{Widgets} In the most general terms, a widget is an image component available for use as an element of the image for an application. Typical widgets are buttons and sliders, but text and drawings can serve as well. A widget presents an on-screen image and interacts in some way with the user. Currently the most well known and widely used toolkits are based on Xt so generally the term "widget" is used in relation to an Xt widget. However, the Xt concept of a widget is quite limited relative to Interviews or AUIS in that Xt provides no generalized protocols for maintaining widgets in relation to a set of data (ala the NotifyObservers and view/data separation in ATK.) Accordingly, AUIS widgets will have considerably more functionality than a typical Xt widget. ATK currently has at least 3 1/2 widget sets: ADEW, Apt, Prefed, and various assorted insets. All have deficiencies. Most offer few options to the C programmer and almost none to the extension language author. The prefed objects are parochial to the preferences editor. Apt provides the best interfaces, but lacks user customizability and is limited to character strings for the most part. ADEW is probably the most complete of the widget sets, but ADEW's interface is restricted to a long value, a string, and an index into an array of strings. All of the available insets lack the degree of customization which has been customary in Xt based widget sets. (The closest to Xt style is "sbutton", which offers controls for the shadow coloring and spacing, but in Xt it would also provide for setting the button label...) \subsection{Requirements - User apparent} \leftindent{Cut/paste/selections Search-able Persistent storage Mail-ability Printing Internationalization Attractive and intuitive default look and feel Optional Motif look and feel Keyboard control of all functions (in addition to mouse control) Continuous and clear feedback on application state} \subsection{Requirements - Author }(Constructing applications using widgets) \leftindent{Customization of look and feel \ Full access and control via a meta-x type interface and an extension language} \subsection{Requirements - Developer} (Extending widgets or building new ones) \leftindent{Extend NotifyObservers and WantUpdate to deal with partial modifications Multiple views on the same data Clean, consistent and easy-to-use programmatic interfaces Ease of writing new insets which support the standard protocols Generally applicable insets for most common application needs} \subsection{Requirements - Optional} \leftindent{Inter-operation with other X applications Drag and drop interfaces} \subsection{Widgets planned} High level widgets and substrates (existing and little changed): \ \leftindent{eq - equation inset fad - rudimentary animation editor figure - drawing editor layout - inset for arbitrary layout of enclosed insets lset - display two adjacent insets ness - extension and string processing language org - display and edit hierarchies page - allow flipping between pages raster - editor for monochrome bit-mapped images table - table / spreadsheet inset text - text, document, and program editor (the heart of ez and other applications) image - display images} Other existing widgets that will remain unchanged. These are seldom used as applications. \leftindent{ clock - analog clock header - specify document headers and footers link - hyper-text-like link month - display a one month calendar note - annotation timeoday - digital clock writestamp - time file was written} The following lists of widgets are adapted from the list of widgets available in Motif. Input widgets \leftindent{ArrowButton - arrow w/ drop shadow ColorChoice - select a color DateChoice - select a date and time DrawingArea - null widget DrawnButton - button with only an outline; application provides image FileSelectionBox - select a file FontList - list of fonts Integer- input an integer via scale and/or text entry Label - simple text label button List - choose from list of strings OptionMenu - menu which pops up from a button PathList - display a list of paths; allow editing PushButton - pushbutton Scale - select a value from a range. slider, text, thumb-wheel, ... ScrollBar - scrollbar SelectionBox - select from a list or type in text Separator - empty, but draws lines TextResponse - a small text entry area ToggleButton - on/off} Output widgets \leftindent{BarGraph -- display a value as a bar Dial -- display a value as hands on a dial EKGGraph -- scaled line graph Gauge -- dashboard gauge (half a dial) Indicator -- display text or icon} special-purpose, defined-format dialog boxes: \leftindent{ErrorDialog - box noting an error InformationDialog - box for displaying information QuestionDialog - box that asks a question WarningDialog - box for warning WorkingDialog - box explaining that action is in progress} compound widgets \leftindent{BulletinBoard - simple widget container. base widget for most dialog widgets (layout) Command - essentially a typescript for connection to an application (typescript) DialogShell - contains a widget and displays it as a dialog box () Form - tiled layout widget container (figure, augmented) Frame - decorations around single child (matte, sort of) MainWindow - standard main window: \ menubar, command window, work area, scrollbars (frame) PanedWindow - vertical tiled format (constrained, smart mono-dimensional lset) Pager - display multiple widgets in same space RadioBox - multiple buttons, only one of which may be pressed RowColumn - tiling for menus (lset) ScrolledList - List with Scrollbar ScrolledText - Text with Scrollbar ScrolledWindow - scrollbar(s) with work area (scrollbar)} In addition, it would be valuable to convert the existing pop-up and pull-down menus to widgets so they would behave like other insets. Before going on to an architecture for widgets, a short digression on resources is appropriate. Resources and resource management were adapted into X from the Macintosh software. They aid in nationalization of software and in otherwise generally making it easier to adapt to local and personal needs and taste. Thus one resource for a widget might be the contents of a message and another the color of the background. The resource architecture provides for both general and specific targeting of a resource specification; the color may be set for all instances of some widget class or only for instances within a certain application or subtree. For example the text might be set for the widget instance named "showResults" in the "Text" widget in the "Radiologist" application. Widgets can be tailored in so many ways by resource files that one is forced to ask whether a widget can be specified \italic{completely} in a resource file. I believe the answer is yes. What is needed is to add to the resource language the means to specify the image and the functions to be performed in response to user actions on that image. The nub of the argument is that \indent{images are specified with a language that is \ interpreted as images by the figure inset \ functions are specified in Ness, C++, or some other language } Note that this results in machine independent dynamic loading: the widget description is interpreted from an ASCII file. \subsection{Image Specification} This proposal hypothesizes that images can be described to the figure inset in four ways: drawing, C++ code, Ness code, or a display list notation. For example, consider a dialog box containing a text and two buttons. This would be drawn by selecting the text tool and placing text in the image; and then selecting the button (or object) tool and inserting the buttons at the desired location. If desired to tie sizes to the box size, the constraint tool would be used. In C++ code, the image is created by calling a series of functions which insert objects and set their size and position. The Ness code would be similar, although possibly simpler. Ideally, it could be as simple as: errorMessage: text(20, 20, 150, 30, "Fatal error") abortButton: button(30, 80, "Abort") okayButton: button(60, 80, "Okay") The integers in these expressions are coordinates and sizes of the image. Since the code is Ness, any arbitrary expression can be used to set the coordinates. The name before the colon is a name by which the object can be later modified; for instance, the message can be changed with setAttribute(errorMessage, msgfield, "Non-fatal error") The display list notation would be the same or similar, but would not appear in the context of a Ness script. Possibly the expressions allowed in attributes would be restricted, or possibly Ness could be used to evaluate them. \subsection{Event Handlers} The event handler attributes of a view can be expressed in C++ code or in Ness, or possibly in some other language. For instance, in Ness the handler resource for left mouse up might be \leftindent{on event "left mouse up" ... \ end event} The notion is that this text would appear as the value of an attribute in a resource file. To match resource file conventions (unfortunately) each line would end with a backslash. \subsection{Work Scope} Revisions are needed in many areas to realize this widget approach: system - arrange to get insets from resource files in addition to code files attribute lists - develop as an adjunct to views and data objects figure - modify to interpret display lists and to utilize resource manager ness - add notation for expressing images simply Once the basic changes are in place, the collection of widgets must still be implemented in terms of the new tools. It would be faster to simply implement the widget set in C++ code, but then the results would be far less flexible. Over the next two months, we will be evaluating whether the additional flexibility justifies the effort. Comments are welcome. _____________________________________________ \ \section{CIL and OpenDoc} A new group called the Component Integration Laboratories (CIL) has been formed by Apple, IBM, Novell, Oracle, Taligent, WordPerfect, Xerox, and others to "Speed Development of `Plug and Play' Software Interoperability Across Multiple Computer Platforms." The formation announcement goes on to say \leftindent{The purpose of CIL is to establish, promote, and certify specifications and reference implementations of key technologies that integrate information and media from many applications within a networked environment. It is intended to develop certification processes for software products that conform to CIL specifications and documentation, as well as training for developers who want to use CIL technologies. In addition, CIL will serve as a distribution center for contributed software, design discussions and technology definition and evolution.} \ CIL offers four components at the present time: \leftindent{o The OpenDoc software architecture for Windows, OS/2, Macintosh and UNIX to enable embedding of features from different applications into a single working document. \ o Bento for the storage and interchange of multi-media information. \ o The Open Scripting Architecture (OSA) for the coexistence of multiple scripting systems. \ o IBM's System Object Model (SOM) architecture, a highly efficient platform and language-independent runtime mechanism for dynamic object linking.} More information is available via anonymous ftp in directory pub on host cil.org or by calling the offices at (415) 750-8352. \ The OpenDoc proposal comes close to offering what AUIS has had for the past five years. Among the files at cil.org is a description of Open Doc from which the following description is adapted. - - - The OpenDoc architecture is designed to enable the construction of compound, collaborative, and customizable documents, which are interoperable across platforms and with other compound document architectures such as Microsoft's OLE 2.0. It will be an open architecture, with source code available to vendors who want to implement the architecture in their products. The OpenDoc architecture is also flexible, providing replaceable facilities so platform vendors can implement their desired feature set. Major concepts of the architecture include the following: Documents - OpenDoc fundamentally changes the meaning of the term document. In today's computing environment, a document has a type, which is tied to the application that will let the user view, edit, and print its content. With OpenDoc, a document is no longer a single block of content bound to a single application, but is instead composed of smaller blocks of content, or parts. \ Parts - Parts are the fundamental building blocks in OpenDoc, replacing today's monolithic applications with smaller units of content dynamically bound with related functionality. OpenDoc parts may be viewed in a number of ways: = Content containers - These correspond rough to ATK data objects. = Part editors - These correspond to ATK views. OpenDoc parts will allow developers to create new applications in a manner similar to that of constructing a document template in today's world. \ = Frames - Frames within OpenDoc are areas of the display that represents a part. Frames provide a handle onto parts, allowing them to be manipulated as a whole, as well as allowing the user to see and edit a part's contents. ... [A] frame can often show only a portion of the entire content of a part. Opening a large part into a window allows its the entire part to be viewed and edited. \ Part handlers - When a part is being displayed or edited, a part handler is invoked to perform those tasks. A part handler is responsible for the following things: =Displaying the part both on the screen and for printing purposes. \ =Editing the part. The part handler gives the user access to edit and script the part. =Storage management (both persistent and runtime) for the part. The part handler must be able to read the part from persistent storage into main memory, manage the runtime storage associated with the part, and write the part back out to persistent storage. Part handlers are dynamically linked into the runtime world of the document, based on the part types that appear in the document. Because any sort of part might appear in any document at any time, the part handlers must be dynamically linked to provide a smooth user experience. - - - The Andrew Consortium staff will continue to evaluate OpenDoc to determine what interfaces and opportunities it offers which may be of value to Andrew users and Consortium members. \smaller{_______________________________________ \subsection{The Andrew User Interface System} The Andrew User Interface System (AUIS) is a portable user-interface environment and toolkit that runs under X11. It provides a dynamically-loadable object-oriented environment wherein objects can be embedded in one-another. Thus, one could use our 'generic-object' editor (ez) to edit text that, in addition to containing multiple fonts, contains embedded raster images, spreadsheets, drawings, equations, simple animations, etc. These embedded objects may themselves contain other objects, including text. The release includes many objects, including those mentioned above, along with a help system, a system monitoring tool (console), an editor based shell interface (typescript). \ The underlying Andrew Toolkit architecture (ATK) supports not only screen display, but also file storage, cut/paste across windows, an application construction environment, an extension language, and printing. There is full support for programmers to create new objects and new applications. The Andrew Message System(AMS) is a component of AUIS and provides a multi-media interface to mail and bulletin-boards. AMS contains many advanced features including authentication, return receipts, automatic sorting of mail, vote collection and tabulation, enclosures, audit trails of related messages, and subscription management. It also provides a variety of interfaces that support character-based terminals and low-function personal computers in addition to high-function workstations. \ The following are components are available in version 5.2 and later versions. Some respond to frequently requested applications in X: word processor: ez, drawing editor: figure, mail and news reader: messages, font editor: bdffont, documentation presentation: help, directory browser: bush. \bold{ AUIS editors that are both applications and insets} eq - equation inset fad - animation editor figure - drawing editor layout - inset for arbitrary layout of enclosed insets lset - display two adjacent insets ness - extension and string processing language org - display and edit hierarchies page - allow flipping between pages raster - editor for monochrome bit-mapped images table - table / spreadsheet inset text - text, document, and program editor (the heart of ez and other applications) \bold{ AUIS applications} bush - directory browser chump - schedule maintainer console - shell interface / terminal replacement ez - word processor and program editor bdffont - font editor (for fonts in bdf format) help - documentation browser (includes all AUIS help files) launch - provides a menu of AUIS applications messages - mail and news reader, manager, and composer pipescript - viewer useful as stdout prefed - preferences editor sendmessage - application for sending a message or news posting typescript - shell interface (terminal substitute) \bold{ Commonly used non-interactive AUIS applications} datacat - concatenate ATK files ezprint - print an ATK document nessrun - runs a Ness script (the extension and string processing language) preview - preview an ATK document on screen \bold{ File format converters} from ATK to: RTF, ASCII, PostScript, troff to ATK from: ppm, Scribe, RTF, troff, X window dump convertraster - various raster formats \bold{ Embeddable insets not usually used as applications} clock - analog clock eq - equations fad - rudimentary animations header - specify document headers and footers image - display images link - hypertext-like link month - display one month calendar note - annotation text - the text object itself timeoday - digital clock writestamp - time file was written \bold{ Editing tools} compchar - type characters for European languages compile - support compilation and error review complete - filename completion for typescript dired - directory browser dsearch - dynamic search ezdiff - compare two ASCII files filter - process a region of a document through a shell command isearch - incremental search lookz - style table editor spell - spelling correction (uses ispell) \bold{ Source text editing tools for} assembler, C++, C, Lisp, man pages, Modula, Modula-3, Pascal \bold{ Tools for constructing insets and applications} arb - ADEW application builder interface bison - GNU parser generator (modified) class - preprocessor for ATK object system header files createcon - ADEW tool to generate C code for interface createinset - create a prototypical inset under a new name doindex - classC postprocessor genmake - Makefile generator for classC gentlex - lexical analyzer generator makedo - classC post processor to create objects runadew - ADEW application builder whichdo - find an inset on the CLASSPATH \bold{ Additional insets available for building applications} button, display text string, entry of labeled text string, four position switch, multiple buttons, multiple sliders, multiple string entry, on/off switch, slider, slider controlling array of strings, text list, thumb knob ______________________________________ \ \subsection{Consortium Services and Offerings} For information about services and offerings of the Andrew Toolkit Consortium please contact us at: \leftindent{Information Requests ATK Consortium School of Computer Science Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213 USA phone: +1-412-268-6710 info-andrew-request@andrew.cmu.edu} We offer: Memberships at three levels: Full, Contributing, and Associate Source tape CDrom with both source and executables Bibliography \ Copies of papers \ Videotapes Conference proceedings Sources and binaries are available online via anonymous ftp from \ \bold{emsworth.andrew.cmu.edu} (128.2.203.197) where the full CDrom release is in the ./cdrom directory. See the README there. Another ftp site is \bold{export.lcs.mit.edu} in directory ./contrib/andrew; this is cloned on many servers, world-wide. On the nationwide AFS file system, AUIS is available in \ \bold{/afs/cs.cmu.edu/project/atk-sm-X.V11R5/cdrom/ }\ Remote Andrew Demo service: \bold{ finger help@atk.itc.cmu.edu} (128.2.203.218) News groups: \bold{info-andrew+@andrew.cmu.edu} This is a distribution list offering the news with full AUIS formatting; send subscription requests to info-andrew-request@andrew.cmu.edu. For newsgroup in plain ASCII, see \bold{comp.soft-sys.andrew} Andrew has been successfully used on (at least) these platforms: \ \leftindent{\description{IBM: RT AOS 3.4, RT AIX 2.2.1, RS/6000 AIX3.1, PS/2 AIX1.2 SUN: Sun3 3.5, Sun3 4.0, Sun4 4.0, Sun3 4.1, Sun4 4.1, Sun4 Mach DEC: Vax Ultrix 3.1, Vax Ultrix 4.2, Vax BSD, DEC MIPS, Pmax Mach other: HP, SCO I386, SGI IRIX 4.0, Apollo, Macintosh II MacMach, 486 Mach}} } \bold{Send requests to \ info-andrew-requests@andrew.cmu.edu Send bug reports to info-andrew-bugs@andrew.cmu.edu} \enddata{text,539667488} \enddata{text822, 41484} \begindata{text822, 93293} Return-path: X-Andrew-Authenticated-as: 0;andrew.cmu.edu;Network-Mail Received: from po2.andrew.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Tue, 14 Dec 1993 18:42:05 -0500 (EST) Received: from po5.andrew.cmu.edu via qmail ID ; Tue, 14 Dec 1993 18:40:38 -0500 (EST) Received: from MIT.EDU (ATHENA-AS-WELL.MIT.EDU [18.72.1.1]) by po5.andrew.cmu.edu (8.6.4/8.6.4) with SMTP id SAA04297 for ; Tue, 14 Dec 1993 18:40:26 -0500 Received: from HANTA-YO.MIT.EDU by MIT.EDU with SMTP id AA18626; Tue, 14 Dec 93 18:40:15 EST Received: by hanta-yo.MIT.EDU (5.0/4.7) id AA26885; Tue, 14 Dec 93 18:40:09 EST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.hanta.yo.sun4.51 via MS.5.6.hanta-yo.sun4_51; Tue, 14 Dec 1993 18:40:08 -0500 (EST) Message-Id: <0h3YvM0GgE6e1cn6M0@mit.edu> Date: Tue, 14 Dec 1993 18:40:08 -0500 (EST) From: Bill Cattey X-Andrew-Message-Size: 1060+0 Content-Type: X-BE2; 12 If-Type-Unsupported: send To: info-andrew+@andrew.cmu.edu Subject: C++ dynamic objects via inheritance. Content-Length: 1178 \begindata{text,2073032} \textdsversion{12} \template{messages} From the newsletter: \quotation{To avoid the many problems, we have chosen a design that relies on inheritance. For each class C which is to be dynamically loaded, there must be a base class, CBase, which declares all the methods of C as virtual methods. CBase must have a static member function for creating objects of class C; this latter function will call on the system mechanism that dynamically loads the class implementation. In practice, ATK's view and dataojbect classes serve as CBase for all views and data objects, so there is no additional coding effort to implement new, dynamically-loadable objects of these classes. } What about those useless and unimportant things, packages? You know, the ones that enable us to add commands to ez? You know, the cornerstone of the GNU Emacs compatibility... Has there been some un-mentioned method by which one can add new proctable entries for an existing object through this new dynamic loading mechanism? Or do I have to subclass the text and textview objects every time I want to add a proctable entry? -wdc \enddata{text,2073032} \enddata{text822, 93293} \begindata{text822, 95888} Return-path: X-Andrew-Authenticated-as: 0;andrew.cmu.edu;Network-Mail Received: from andrew.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Tue, 14 Dec 1993 18:53:07 -0500 (EST) Received: from po5.andrew.cmu.edu via qmail ID ; Tue, 14 Dec 1993 18:49:41 -0500 (EST) Received: from MIT.EDU (ATHENA-AS-WELL.MIT.EDU [18.72.1.1]) by po5.andrew.cmu.edu (8.6.4/8.6.4) with SMTP id SAA04769 for ; Tue, 14 Dec 1993 18:49:30 -0500 Received: from HANTA-YO.MIT.EDU by MIT.EDU with SMTP id AA19120; Tue, 14 Dec 93 18:49:20 EST Received: by hanta-yo.MIT.EDU (5.0/4.7) id AA26889; Tue, 14 Dec 93 18:49:19 EST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.hanta.yo.sun4.51 via MS.5.6.hanta-yo.sun4_51; Tue, 14 Dec 1993 18:49:18 -0500 (EST) Message-Id: <0h3Z3y0GgE6e1cn6g0@mit.edu> Date: Tue, 14 Dec 1993 18:49:18 -0500 (EST) From: Bill Cattey To: info-andrew+@andrew.cmu.edu Subject: Printing Model Content-Length: 826 The printing model looks rich enough! Good job. I would like to question the decisions to eliminate the PostScript inset, and texttag/textref from the planned implementation. It seems that embedded user-written PostScript code is either trivial or impossible. It seems that the trivial case, of requiring the postscript inset to be confined to the generic rectangle imposed by the parent would be sufficient, and would not throw away existing functionality. The texttag/textref for cross referencing is clearly very hard. But I think it should go on the list of PLANNED implementations. Perhaps ostensibly planned NOT for version 1. Would I be out of line if I suggested that a print-time computations architecture should begin to be discussed with texttag/textref one of the first special cases of it. -wdc \enddata{text822, 95888} \begindata{text822, 98024} Return-path: X-Andrew-Authenticated-as: 5904;andrew.cmu.edu;Robert Andrew Ryan Received: from atk.itc.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Tue, 14 Dec 1993 21:57:07 -0500 (EST) Received: from atk.itc.cmu.edu via qmail ID ; Tue, 14 Dec 1993 21:53:00 -0500 (EST) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.atk.itc.cmu.edu.rs.aix31 via MS.5.6.atk.itc.cmu.edu.rs_aix3; Tue, 14 Dec 1993 21:52:59 -0500 (EST) Message-ID: Date: Tue, 14 Dec 1993 21:52:59 -0500 (EST) From: Robert Andrew Ryan X-Andrew-Message-Size: 1000+0 Content-Type: X-BE2; 12 If-Type-Unsupported: send To: Info-Andrew Subject: Re: C++ dynamic objects via inheritance. In-Reply-To: <0h3YvM0GgE6e1cn6M0@mit.edu> References: <0h3YvM0GgE6e1cn6M0@mit.edu> \begindata{text,539260756} \textdsversion{12} \template{messages} \excerptedcaption{Excerpts from internet.other.info-andrew: 14-Dec-93 C++ dynamic objects via inh.. Bill Cattey@MIT.EDU (1060+0)} \quotation{Has there been some un-mentioned method by which one can add new proctable entries for an existing object through this new dynamic loading mechanism? } Sorry about that. Packages which supply proctable functions are actually the easiest to do dynamic loading for. They will work just like they do now. (ie, the name is checked to find the class to load, it gets loaded and it's initializeclass function defines the proctable functions.) Likewise dynamic loading of insets via esc-tab will continue to work as before. The only real loss in the planned dynamic loading mechanism is the inability to simply #include and blythely use foo's methods and class procedures without ensuring that they will be linked in at compile time. The only way dynamically loaded code will be callable is via virtual functions or function pointers. (Particularly in the proctable entries.) -Rob \enddata{text,539260756} \enddata{text822, 98024} \begindata{text822, 100343} Return-path: X-Andrew-Authenticated-as: 8779;andrew.cmu.edu;Andrew C. Plotkin Received: from orac.andrew.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Wed, 15 Dec 1993 13:58:10 -0500 (EST) Received: from orac.andrew.cmu.edu via qmail ID ; Wed, 15 Dec 1993 13:54:20 -0500 (EST) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.orac.andrew.cmu.edu.pmax.ul4 via MS.5.6.orac.andrew.cmu.edu.pmax_ul4; Wed, 15 Dec 1993 13:54:13 -0500 (EST) Message-ID: Date: Wed, 15 Dec 1993 13:54:13 -0500 (EST) From: "Andrew C. Plotkin" To: Info-Andrew Subject: Re: Printing Model In-Reply-To: <0h3Z3y0GgE6e1cn6g0@mit.edu> References: <0h3Z3y0GgE6e1cn6g0@mit.edu> Excerpts from internet.other.info-andrew: 14-Dec-93 Printing Model Bill Cattey@MIT.EDU (826) > It seems that embedded user-written PostScript code is either trivial or > impossible. It seems that the trivial case, of requiring the postscript > inset to be confined to the generic rectangle imposed by the parent > would be sufficient, and would not throw away existing functionality. It is trivial, and will work like that. No problem. There may be other, more interesting PS insets, which do things like modify the appearance of text , or change their size or contents based on print-time computation. > The texttag/textref for cross referencing is clearly very hard. > But I think it should go on the list of PLANNED implementations. > Perhaps ostensibly planned NOT for version 1. > Would I be out of line if I suggested that a print-time computations > architecture should begin to be discussed with texttag/textref one of > the first special cases of it. Suggest all you like -- I've been ignoring suggestions with the best for years. :-) At this point, I'm considering a fairly ugly model, in which the text-printing module watches for texttag/textref, and if it sees any it flips a flag which tells it to do a second pass. This is not very general, although the code will probably be used to do indexes as well. --Z "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..." \enddata{text822, 100343} \begindata{text822, 102877} Return-path: X-Andrew-Authenticated-as: 0;andrew.cmu.edu;Network-Mail Received: from po4.andrew.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Wed, 15 Dec 1993 14:50:26 -0500 (EST) Received: from po3.andrew.cmu.edu via qmail ID ; Wed, 15 Dec 1993 14:45:20 -0500 (EST) Received: from vnet.IBM.COM (vnet.ibm.com [192.239.48.4]) by po3.andrew.cmu.edu (8.6.4/8.6.4) with SMTP id OAA18776 for ; Wed, 15 Dec 1993 14:45:09 -0500 Received: from RCHLAND by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 9243; Wed, 15 Dec 93 14:44:41 EST Reply-To: "Todd Inglett" Received: by po1 (AIX 3.2/UCB 5.64/4.7) id for info-andrew+@andrew.cmu.edu; Wed, 15 Dec 1993 13:43:27 -0600 Received: via switchmail; Wed, 15 Dec 1993 13:43:27 -0600 (CST) Received: from q.rchland.ibm.com via qmail ID ; Wed, 15 Dec 1993 13:43:15 -0600 (CST) Received: from q.rchland.ibm.com via qmail ID ; Wed, 15 Dec 1993 13:43:04 -0600 (CST) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.q.rchland.ibm.com.rs.aix32 via MS.5.6.q.rchland.ibm.com.rs_aix32; Wed, 15 Dec 1993 13:43:03 -0600 (CST) Message-Id: Date: Wed, 15 Dec 1993 13:43:03 -0600 (CST) From: Todd Inglett To: info-andrew+@andrew.cmu.edu Subject: Re: C++ dynamic objects via inheritance. In-Reply-To: <0h3YvM0GgE6e1cn6M0@mit.edu> References: <0h3YvM0GgE6e1cn6M0@mit.edu> I agree with Bill that this technique for dynamic loading will be ok, provided both packages, insets (direct subclass of dataobject&view) and applications are trivial. I don't understand all of the details here, but also subclasses of text/textview and srctext/srctextview might be useful as standard dynamically loadable interfaces. There may be one or two base classes for your widgets which would be commonly extended by developers, too. -todd inglett \enddata{text822, 102877} \begindata{text822, 105293} Return-path: X-Andrew-Authenticated-as: 0;andrew.cmu.edu;Network-Mail Received: from andrew.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Wed, 15 Dec 1993 15:01:28 -0500 (EST) Received: from po3.andrew.cmu.edu via qmail ID ; Wed, 15 Dec 1993 15:00:06 -0500 (EST) Received: from vnet.IBM.COM (vnet.ibm.com [192.239.48.4]) by po3.andrew.cmu.edu (8.6.4/8.6.4) with SMTP id OAA19646 for ; Wed, 15 Dec 1993 14:59:59 -0500 Received: from RCHLAND by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 9383; Wed, 15 Dec 93 14:59:38 EST Reply-To: "Todd Inglett" Received: by po1 (AIX 3.2/UCB 5.64/4.7) id for info-andrew+@andrew.cmu.edu; Wed, 15 Dec 1993 13:58:11 -0600 Received: via switchmail; Wed, 15 Dec 1993 13:58:11 -0600 (CST) Received: from q.rchland.ibm.com via qmail ID ; Wed, 15 Dec 1993 13:57:55 -0600 (CST) Received: from q.rchland.ibm.com via qmail ID ; Wed, 15 Dec 1993 13:57:51 -0600 (CST) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.q.rchland.ibm.com.rs.aix32 via MS.5.6.q.rchland.ibm.com.rs_aix32; Wed, 15 Dec 1993 13:57:51 -0600 (CST) Message-Id: Date: Wed, 15 Dec 1993 13:57:51 -0600 (CST) From: Todd Inglett X-Andrew-Message-Size: 2118+0 Content-Type: X-BE2; 12 If-Type-Unsupported: send To: info-andrew+@andrew.cmu.edu Subject: Re: Printing Model In-Reply-To: <0h3Z3y0GgE6e1cn6g0@mit.edu> References: <0h3Z3y0GgE6e1cn6g0@mit.edu> \begindata{text,539083512} \textdsversion{12} \template{messages} \excerptedcaption{Excerpts from ext.misc.info-andrew: 14-Dec-93 Printing Model Bill Cattey@MIT.EDU (815)} \quotation{I would like to question the decisions to eliminate the PostScript }\quotation{inset, and texttag/textref from the planned implementation. } I agree about texttag/textref. They should at least be at the back of your mind as you think this through (and I imagine they are even though you didn't mention it). Also consider that these are just as useful on screen as hypertext links as they are on paper. \excerptedcaption{Excerpts from ext.misc.info-andrew: 14-Dec-93 The Andrew View V.2, 3 Susan Straub@andrew.cmu. (40516+1)} \quotation{When a parent view wishes to print an inset view, it first calls the inset's GetPrintInterface method to determine how it wants to be handled. At the moment, three printtypes are defined: } Note that this idea also extends to on screen. Certain insets embedded in text should inherit the current text font at that point in the document (equations, hyperlinks, sbuttons). Some shouldn't. Some insets should flow into the text (footnotes, writestamps). You may want to consider if this can be done by extending the current view mechanism. Perhaps it should be implemented such that "on screen" can be different than on paper...but the default is for "on paper" to do the same as "on screen". Another comment has to do with user customization. How are my fonts mapped to paper fonts? I believe many of our users have chosen to use fonts that only exist under X. These of course don't print correctly. It would be real nice if these could be mapped both by an administrator and by users to printer fonts. This is also true of font size (rather than font family). For example, I like to read 12 point fonts on the screen, but prefer a 10 point font on paper. I see that templates have some residual code that controls definitions per device type. It seems that a template could control styles differently for printer vs. screen. This could be useful if finished. Also, what about plaintext printing? Perhaps this is simply a matter of sending the text through the MIME code and filtering it for printing? -todd inglett \enddata{text,539083512} \enddata{text822, 105293} \begindata{text822, 109597} Return-path: X-Andrew-Authenticated-as: 0;andrew.cmu.edu;Network-Mail Received: from po5.andrew.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Wed, 15 Dec 1993 16:04:01 -0500 (EST) Received: from po3.andrew.cmu.edu via qmail ID ; Wed, 15 Dec 1993 16:02:44 -0500 (EST) Received: from vnet.IBM.COM (vnet.ibm.com [192.239.48.4]) by po3.andrew.cmu.edu (8.6.4/8.6.4) with SMTP id QAA22630 for ; Wed, 15 Dec 1993 16:02:40 -0500 Received: from RCHLAND by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 9962; Wed, 15 Dec 93 16:02:13 EST Reply-To: "Todd Inglett" Received: by po1 (AIX 3.2/UCB 5.64/4.7) id for info-andrew@andrew.cmu.edu; Wed, 15 Dec 1993 14:57:04 -0600 Received: via switchmail; Wed, 15 Dec 1993 14:57:04 -0600 (CST) Received: from q.rchland.ibm.com via qmail ID ; Wed, 15 Dec 1993 14:57:01 -0600 (CST) Received: from q.rchland.ibm.com via qmail ID ; Wed, 15 Dec 1993 14:57:00 -0600 (CST) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.q.rchland.ibm.com.rs.aix32 via MS.5.6.q.rchland.ibm.com.rs_aix32; Wed, 15 Dec 1993 14:57:00 -0600 (CST) Message-Id: Date: Wed, 15 Dec 1993 14:57:00 -0600 (CST) From: Todd Inglett X-Andrew-Message-Size: 2648+0 Content-Type: X-BE2; 12 If-Type-Unsupported: send To: info-andrew@andrew.cmu.edu Subject: Widgets \begindata{text,539083512} \textdsversion{12} \template{messages} \define{subsection menu:[Title~3,Subsection~22] attr:[Justification LeftJustified Point 0] attr:[Flags KeepPriorNL Int Set] attr:[Flags KeepNextNL Int Set] attr:[FontFace Bold Int Set]} \define{leftindent menu:[Region~4,LeftIndent~21] attr:[LeftMargin LeftMargin Inch 32768] attr:[Flags KeepPriorNL Int Set] attr:[Flags KeepNextNL Int Set]} \excerptedcaption{Excerpts from ext.misc.info-andrew: 14-Dec-93 The Andrew View V.2, 3 Susan Straub@andrew.cmu. (40516+1)} \quotation{\subsection{Requirements - Author }(Constructing applications using widgets) }\leftindent{\quotation{Customization of look and feel }}\quotation{\leftindent{Full access and control via a meta-x type interface and an extension language} } Add to that the same requirement from the next section: "Clean, consistent and easy-to-use programmatic interfaces." I don't believe all developers will interactively build interfaces until that part of ATK develops into a very useable, professional, and stable system. Until then I would expect that a lot of C++ programmers will create and manipulate the widgets from within C++ code (this is also partly true if the system is built interactively, except the creation part will be already done). Perhaps this was obvious to you...but just for the record I thought I would mention it. Also, although it is nice that the widgets allow customization through additional menus, these menus are very annoying in a completed application. For example, if I piece two widgets together with an lset, I don't want users of the application to see lset's menu. I guess the widgets need an "authoring" mode. Here are some other widgets you may want to add to your list. They are probably trivial subclasses of widgets you have mentioned: \description{\bold{SpinButton} Click through a list of values. Probably a subclass of Scale or OptionMenu. The amiga shows this as a little button with a arrow arcing around in a circle and the current text value shows as a label on the button. \bold{NoteBook} A special case of Pager that shows a spiral edge on one side (representing a real notebook) and tabs along the other side. The tabs allow you to quickly find a page. }...and don't forget that 99.9% of the time a TextResponse widget needs a label (probably to the left). I'd make it part of the widget and not require a developer to piece a label next to the TextResponse widget. Some of your widgets are categorized oddly (probably accidental) such as \italic{label} being an input widget. You will want to slowly convert supported parts of ATK to actually \italic{use} these widgets. That will be the only way to make them better. The more used they are, the more stable they become. Now a big question is ``how are resources specified?'' Will you attempt to read and use X resources, use preferences, create a new file format, or put them in a datastream? As far as customization is concerned I am a firm believer in "keep it simple." And that is from a user's point of view...not a programmer's point of view. X resources and even preferences, IMHO, fail miserably in this respect. -todd inglett \enddata{text,539083512} \enddata{text822, 109597} \begindata{text822, 114747} Return-path: X-Andrew-Authenticated-as: 0;andrew.cmu.edu;Network-Mail Received: from po2.andrew.cmu.edu via trymail for info-andrew+@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr0/ak99/dists/info-andrew-nostrip.dl) ID ; Wed, 15 Dec 1993 16:10:33 -0500 (EST) Received: from po4.andrew.cmu.edu via qmail ID ; Wed, 15 Dec 1993 16:09:59 -0500 (EST) If-Type-Unsupported: send Received: from po3.andrew.cmu.edu via qmail ID ; Wed, 15 Dec 1993 16:03:16 -0500 (EST) Received: from barney.cs.city.ac.uk (barney.cs.city.ac.uk [138.40.91.8]) by po3.andrew.cmu.edu (8.6.4/8.6.4) with SMTP id QAA22685 for ; Wed, 15 Dec 1993 16:03:11 -0500 Received: from wilma.cs.city.ac.uk by barney.cs.city.ac.uk; Wed, 15 Dec 1993 21:06:16 GMT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.wilma.cs.city.ac.uk.sun4.41 via MS.5.6.wilma.cs.city.ac.uk.sun4_41; Wed, 15 Dec 1993 21:03:42 +0000 (GMT) Message-Id: Date: Wed, 15 Dec 1993 21:03:42 +0000 (GMT) From: Nick Williams Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: www-talk@www0.cern.ch, info-andrew@andrew.cmu.edu Subject: Re: HTML(+)-editor available? In-Reply-To: <199312151433.JAA15087@mitchell.cit.cornell.edu> References: <199312151433.JAA15087@mitchell.cit.cornell.edu> I wrote and alpha released a vanilla HTML editor a while back, using the Andrew Toolkit, giving it a wysiwyg feel. Works pretty well, however I haven't got around to implementing the http access (the editor was only for local files), as I decided that should be implemented at a different level. Since then, HTML+ has hit the scene, which my editor doesn't know about. No, it's not an SGML based thing, but a pure hack on HTML. I'd like to continue working on this: updating it for HTML+ and adding http support but I'm not sure if I have the time. If anyone else is interested (perhaps some of the people who picked up the htmltext might like to give me some feedback...?) in cooperating, I'd be happy to hear from you. The almost-wysiwyg aspect is very desirable. We now use the editor for almost all document creation here and not having to see the raw html entities is many orders of magnitude better than "vi", no matter how simple people claim html is. Nick Williams E-mail: njw@cs.city.ac.uk (MIME and ATK) Systems Architecture Research Centre, Tel: +44 71 477 8551 London, EC1V 0HB Fax: +44 71 477 8587 \enddata{text822, 114747}