Received: from BBN.COM by LABS-N.BBN.COM id aa09528; 3 Jan 91 9:01 EST Received: from [129.217.64.60] by BBN.COM id aa27430; 3 Jan 91 8:55 EST Received: from itwdo by unido.informatik.uni-dortmund.de with UUCP (UNIDO-2.0.3.c) via EUnet for bbn.com id AA13544; Thu, 3 Jan 91 13:55:02 GMT Received: by iml.fhg.de with SMTP; Thu, 3 Jan 91 13:09:16 +0100 X-Mailer-Iml-Itwdo: ## IML.FHG.DE ## Thu, 3 Jan 91 13:09:16 +0100 Date: Thu, 3 Jan 91 13:08+0100 From: Stefan Bernemann Subject: Availability? To: clim@BBN.COM Message-Id: <19910103120843.4.STEFAN@ANNA.iml.fhg.de> Hello, First one remark: I hope to be on this mailing-list (I wrote to clim-request@bbn.com), but I got no postings up to now. So if I'm not, could that be arranged? Thanks. Now my question: We are planning to recode (and sell :-) a medium-sized software system (XPS for selection-typed problems, the current verion is written in prolog) in portable way. CLIM seems to be a very atractive solution for a portable implementation of the user inteface, so we might switch to lisp if there are CLIM-implementations available this year. Now my real question:-) Which vendors (with address) a supporting CLIM already - on UNIX* boxes (preferable SUNs), - on PCs (I only know of Symbolics CLOE which would be ok if the performance is ok as we have some Lispms), - on Apple Macintosh's (would be nice, but not too important right now) ? - on others??? I need a stable and efficient CLIM implementation second half of this year, whereas 100% functionality might not be so important. Thank you for any answers - Stefan. Mail: Stefan Bernemann ! Phone: +49-231-7549233 c/o FhG IML Dortmund ! Fax: +49-231-7549211 Emil-Figge-Str. 75 ! Email: berni@iml.fhg.de D-4600 Dortmund 50, FRG ! ...!{uunet|mcavx}!unido!itwdo!berni   Received: from BBN.COM by LABS-N.BBN.COM id aa13244; 3 Jan 91 13:55 EST Received: from FUJI.ILA.COM by BBN.COM id aa20370; 3 Jan 91 13:46 EST Date: Thu, 3 Jan 91 13:50 EST From: "Mark A. Son-Bell" Subject: Availability? To: berni@iml.fhg.de, clim@BBN.COM In-Reply-To: <19910103120843.4.STEFAN@ANNA.iml.fhg.de> Message-ID: <19910103185013.8.MAS-B@FUJI.ILA.COM> Date: Thu, 3 Jan 91 13:08+0100 From: Stefan Bernemann Hello, ... Now my question: We are planning to recode (and sell :-) a medium-sized software system (XPS for selection-typed problems, the current verion is written in prolog) in portable way. CLIM seems to be a very atractive solution for a portable implementation of the user inteface, so we might switch to lisp if there are CLIM-implementations available this year. Now my real question:-) Which vendors (with address) a supporting CLIM already - on UNIX* boxes (preferable SUNs), The following three vendors are supporting pre-release versions of CLIM for Unix workstations running X Windows: Lucid, Inc. Franz, Inc. Harlequin, Ltd 707 Laurel St. 1995 University Ave. Barrington Hall Menlo Park, CA 94025 Berkeley, CA 94704 Barrington USA USA Cambridge CB2 5RG England phone:+415-329-8400 phone:+415-548-3600 phone: +44-223-872522 fax:+415-329-8480 fax: +415-548-8253 fax: +44-223-872519 (I don't know how these companies handle distribution of their products in Germany.) (Siemens Nixdorf Informationssysteme AG, Munich, is also participating in the CLIM effort, but is not yet supporting a product.) - on PCs (I only know of Symbolics CLOE which would be ok if the performance is ok as we have some Lispms), CLOE is the only DOS/Windows Lisp supporting CLIM at present. One or more of the three vendors listed above may support CLIM under Unix on 386 machines. - on Apple Macintosh's (would be nice, but not too important right now) ? We (ILA) are working on a Macintosh version. It should be ready for beta test soon. - on others??? None committed to publicly at present. I need a stable and efficient CLIM implementation second half of this year, whereas 100% functionality might not be so important. There should be stable and efficient implementations available in final commercial release form during the first half of this year. Thank you for any answers - Stefan. Mail: Stefan Bernemann ! Phone: +49-231-7549233 c/o FhG IML Dortmund ! Fax: +49-231-7549211 Emil-Figge-Str. 75 ! Email: berni@iml.fhg.de D-4600 Dortmund 50, FRG ! ...!{uunet|mcavx}!unido!itwdo!berni Regards, Mark Son-Bell ILA 114 Mt. Auburn St 4th Floor Cambridge, MA 02138 phone:+617-576-1151 fax:+617-576-2806   Received: from BBN.COM by LABS-N.BBN.COM id aa04313; 9 Jan 91 3:33 EST Received: from [129.69.211.1] by BBN.COM id aa23402; 9 Jan 91 3:29 EST Received: from is.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Wed, 9 Jan 91 09:26:38 +0100 From: Rainer Koenig Date: Wed, 9 Jan 91 09:28:27 +0100 Message-Id: <9101090828.AA12461@is.informatik.uni-stuttgart.de> Received: by is.informatik.uni-stuttgart.de; Wed, 9 Jan 91 09:28:27 +0100 To: clim@BBN.COM Subject: problems Machine: Sun Sparcstation Operating System: SunOS4.1 X11R4 We have the following products (Packing Slip No. 3765): 1. Allegro CL, Allegro Common Windows & Allegro Composer Release 3.1.13.1 Serial Number 21-943-100 2. CLIM Serial Number 939F3704 Our problems are: 1. CLIM and the Allegro Composer can`t be loaded together. I have the impression that there are problems with the PCL. Please send us an installation description, so that we can use both packages together, that's why we bought them. 2. When we load our application into an image with Allegro CL and the PCL, all works well. When we load our application into a CLIM-image an error occurs: bus error number 10. Could you please help us Rainer Please add me to the CLIM mailing list ============================================================================== Rainer Koenig rkoenig@fzi.uka.de Forschungszentrum Informatik an der Universitaet Karlsruhe Abtl. Technische Expertensysteme und Robotik Haid-und-Neu-Strasse 10-14 D - 7500 Karlsruhe 1 Tel.: (+49 | 0) 721 / 6906-313 ==============================================================================   Received: from BBN.COM by LABS-N.BBN.COM id aa09868; 9 Jan 91 13:00 EST Received: from FUJI.ILA.COM by BBN.COM id aa13385; 9 Jan 91 12:58 EST Received: from MAX-FLEISCHER.SF.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 124301; 9 Jan 91 13:00:43 EST Date: Wed, 9 Jan 91 09:53 PST From: Richard Lamson Subject: problems To: Rainer Koenig , clim@BBN.COM, Bug-CLIM@f.ila.com cc: FYI , rsl@max-fleischer.sf.dialnet.ila.com In-Reply-To: <9101090828.AA12461@is.informatik.uni-stuttgart.de> Message-ID: <19910109175315.5.RSL@MAX-FLEISCHER.SF.Dialnet.ILA.COM> Reply-To: rsl@ila.com Date: Wed, 9 Jan 91 09:28:27 +0100 From: Rainer Koenig Machine: Sun Sparcstation Operating System: SunOS4.1 X11R4 We have the following products (Packing Slip No. 3765): 1. Allegro CL, Allegro Common Windows & Allegro Composer Release 3.1.13.1 Serial Number 21-943-100 2. CLIM Serial Number 939F3704 Our problems are: 1. CLIM and the Allegro Composer can`t be loaded together. I have the impression that there are problems with the PCL. Please send us an installation description, so that we can use both packages together, that's why we bought them. It may be the case that CLIM will work with the version of PCL which comes with Composer (the Franz people tell me that the difference between the two PCLs is that the CLIM version is more heavily optimized). You can try returning from the call to ERROR which happens during loading CLIM (saying that "CLIM requires New Caching PCL") to see whether it works, but it may be that we would need to compile CLIM using the old PCL in order to have it work. 2. When we load our application into an image with Allegro CL and the PCL, all works well. When we load our application into a CLIM-image an error occurs: bus error number 10. This is too hard to diagnose without a backtrace, and even then it might not be easy. Does this occur during loading or when you first try to run your application? Also, there is a patch to Allegro 3.1.13 which may be related, whose number I don't recall; it was supposed to fix certain errors of this form. Please send a copy of the transcript of a session in which this happens, including the output of ":ZOOM :COUNT 99999 :ALL T" to Bug-CLIM@ILA.COM and Bugs@Franz.COM. We may also need a copy of the relevant parts of your application.   Received: from BBN.COM by LABS-N.bbn.COM id aa20338; 10 Jan 91 8:25 EST Received: from chx400.switch.ch by BBN.COM id aa22575; 10 Jan 91 8:21 EST Received: by chx400.switch.ch (5.61/Ultrix2.4-C) id AA24615; Thu, 10 Jan 91 14:21:53 +0100 Date: 10 Jan 91 14:17 +0100 From: Schneider Daniel To: clim@BBN.COM MMDF-Warning: Parse error in original version of preceding line at BBN.COM Message-Id: <163*schneide@divsun.unige.ch> Subject: re:problems From: Richard Lamson To: Rainer Koenig , , Subject: problems 1. CLIM and the Allegro Composer can`t be loaded together. I have the impression that there are problems with the PCL. Please send us an installation description, so that we can use both packages together, that's why we bought them. It may be the case that CLIM will work with the version of PCL which comes with Composer (the Franz people tell me that the difference between the two PCLs is that the CLIM version is more heavily optimized). You can try returning from the call to ERROR which happens during loading CLIM (saying that "CLIM requires New Caching PCL") to see whether it works, but it may be that we would need to compile CLIM using the old PCL in order to have it work. Well, I'd prefer if you'd try to get out the CLOS version as fast as possible since Franz gives Allegro 4.0 to beta-sites (and maybe to other friendly people). I raised this problem before, and it seemed that one has indeed to do away with clim-pcl and recompile clim with franz-pcl. 2. When we load our application into an image with Allegro CL and the PCL, all works well. When we load our application into a CLIM-image an error occurs: bus error number 10. This is too hard to diagnose without a backtrace, and even then it might not be easy. Does this occur during loading or when you first try to run your application? Also, there is a patch to Allegro 3.1.13 which may be related, whose number I don't recall; it was supposed to fix certain errors of this form. Please send a copy of the transcript of a session in which this happens, including the output of ":ZOOM :COUNT 99999 :ALL T" to Bug-CLIM@ILA.COM and Bugs@Franz.COM. We may also need a copy of the relevant parts of your application. I had this error too, and (SORRY FOR THAT, I'm just a poor programmer) I got the impression that those errors are random, but they occur more frequently when one writes wrong clim Code. Nowadays I almost never get them anymore. So, the problem could be that PCL builds some very strange memory references under some some cricumstances. What I did then was to kill the lisp image and reload my code again. If that didn't help, I tried to locate and changed code which seemed to favor those errors (argl .....).   To: clim@BBN.COM Subject: Getting random Keysym/Keycodes in clim Date: Thu, 10 Jan 91 17:03:25 -0500 From: Mike Thome How does one recognize X keysyms and/or keycodes from CLIM? The goal is to make some of my special function keys act like symbolics END, ABORT, COMPLETE, etc. thanks, -mik (mthome@bbn.com)   Received: from BBN.COM by LABS-N.bbn.COM id aa13117; 18 Jan 91 14:27 EST Received: from astd-gw.jpl.nasa.gov by BBN.COM id aa14097; 18 Jan 91 14:19 EST Received: by granite.Jpl.Nasa.Gov (4.0/SMI-3.4+DXR+main) id AA23289; Fri, 18 Jan 91 11:19:10 PST Date: Fri, 18 Jan 91 11:19:10 PST From: Brian of ASTD-CP Message-Id: <9101181919.AA23289@granite.Jpl.Nasa.Gov> To: clim@BBN.COM Subject: Add me to mailing list please I hope I'm writing to the right place... I'm interested in CLIM and would like to be added to the mailing list. If you have any standard blurb for beginners that answers 1. what is CLIM? 2. how do I get it? etc. etc. please send that to me also. Thanks (if you are the right place) and apologies (if you are not) brian   Received: from BBN.COM by LABS-N.bbn.COM id aa16149; 18 Jan 91 19:03 EST Received: from hawaii2.bbn.com by BBN.COM id aa27358; 18 Jan 91 19:02 EST Date: Fri, 18 Jan 91 11:58:36 HST From: Jack Margerison To: clim@BBN.COM cc: amargerison@BBN.COM Subject: subscribe Message-ID: <9101181158.aa01700@HAWAII2.BBN.COM> Please add my name to the clim list. Thanks, Jack Margerison amargerison@bbn.com   Received: from BBN.COM by LABS-N.bbn.COM id aa22778; 19 Jan 91 17:18 EST Received: from flubber.cs.umd.edu by BBN.COM id aa21855; 19 Jan 91 17:15 EST Received: by flubber.cs.UMD.EDU (5.61/UMIACS-0.9/04-05-88) id AA21589; Sat, 19 Jan 91 17:15:52 -0500 Date: Sat, 19 Jan 91 17:15:52 -0500 From: Bill Anderson Message-Id: <9101192215.AA21589@flubber.cs.UMD.EDU> To: clim@BBN.COM Subject: Info... What can you tell me about CLIM on the Mac. Since I know nothing now, I would appreciate any information you can render. Thank You, Bill Andersen waander@cs.umd.edu   Received: from BBN.COM by LABS-N.bbn.COM id aa16267; 21 Jan 91 17:11 EST Received: from atc.boeing.com by BBN.COM id aa00632; 21 Jan 91 17:02 EST Received: by atc.boeing.com on Mon, 21 Jan 91 14:00:12 PST Received: by huntsai.boeing.com (1.2/Ultrix2.0-B) id AA12772; Mon, 21 Jan 91 16:08:54 cst Date: Mon, 21 Jan 91 16:08:54 cst From: Rodney Daughtrey Message-Id: <9101212208.AA12772@huntsai.boeing.com> To: clim@BBN.COM Subject: Re: CLIM on the Mac Date: Sat, 19 Jan 91 17:15:52 -0500 From: Bill Anderson Message-Id: <9101192215.AA21589@flubber.cs.UMD.EDU> To: clim@BBN.COM.ARPANET Subject: Info... Status: RO What can you tell me about CLIM on the Mac. Since I know nothing now, I would appreciate any information you can render. Thank You, Bill Andersen waander@cs.umd.edu I, too, and several others I know of would also appreciate more information concerning the Macintosh version of CLIM. Specifically: * What is the best estimate (realistically, please) for the release date of CLIM for the Mac? * How much will it cost? * What capabilities/level of programming will be available in the initial release? Will it be at the level of current ObjectLisp GUI programming on the Mac under MACL? A response from someone at ILA (official or not) would be greatly appreciated! Rodney Daughtrey E-mail: rodney@huntsai.boeing.com Huntsville AI Center {major site}!uw-beaver!bcsaic!huntsai!rodney Boeing Computer Services Voice: (205)-461-2352 Fax: (205)-461-2933   Received: from BBN.COM by LABS-N.bbn.COM id aa17402; 21 Jan 91 19:08 EST Received: from FUJI.ILA.COM by BBN.COM id aa04464; 21 Jan 91 19:04 EST Date: Mon, 21 Jan 91 19:07 EST From: "Mark A. Son-Bell" Subject: Re: CLIM on the Mac To: rodney@huntsai.boeing.com, clim@BBN.COM In-Reply-To: <9101212208.AA12772@huntsai.boeing.com> Message-ID: <19910122000745.5.MAS-B@FUJI.ILA.COM> Date: Mon, 21 Jan 91 16:08:54 cst From: Rodney Daughtrey Date: Sat, 19 Jan 91 17:15:52 -0500 From: Bill Anderson What can you tell me about CLIM on the Mac. Since I know nothing now, I would appreciate any information you can render. Thank You, Bill Andersen waander@cs.umd.edu I, too, and several others I know of would also appreciate more information concerning the Macintosh version of CLIM. Specifically: * What is the best estimate (realistically, please) for the release date of CLIM for the Mac? * How much will it cost? * What capabilities/level of programming will be available in the initial release? Will it be at the level of current ObjectLisp GUI programming on the Mac under MACL? A response from someone at ILA (official or not) would be greatly appreciated! Rodney Daughtrey E-mail: rodney@huntsai.boeing.com Huntsville AI Center {major site}!uw-beaver!bcsaic!huntsai!rodney Boeing Computer Services Voice: (205)-461-2352 Fax: (205)-461-2933 (Allow me to respond to both of these at once, no slight intended to Bill.) CLIM for the Mac is now available from ILA for very limited external test and evaluation. The only hitch is that you have to have access to the alpha version of Macintosh Allegro Common Lisp 2.0 from Apple, which is not yet generally available. If you have MACL 2.0.something, and want to take part in the evaluation, contact us directly at the addresses listed at the end of this message. The full commercial release date is somewhat more problematic, since it is tied to Apple's release of MACL 2, which (we are told) is tied to MacOS 7, which has been slipping for over a year now. I think a realistic timetable is Mac CLIM beta sometime in late Q1, FCS late Q3/early Q4. Pricing will be somewhere between that for MACL and that for, say, Flavors or PCL from APDA, or some number of hundreds of dollars. (In other words, pricing and distribution are not set yet.) As for the capabilities of CLIM, that's a very long story. CLIM on the Mac uses the underlying MACL GUI toolkit to implement the generic UI features specified by the CLIM API, and available in all complete implementations of CLIM, which fall roughly into the following layers (bottom to top): * basic geometry * graphics and other basic output * basic input (keyboard and pointer handling) * window management (exposure, stacking, sizing, etc...) * output recording * presentations * context-sensitive input * formatted output * application-building tools (commands, frames) * generic gadget toolkit The reasons-for-being of CLIM are portability and high-level constructs for UI programming in Common Lisp (which includes CLOS). Regards, Mark Son-Bell ILA 114 Mt. Auburn St. 4th Floor Cambridge, MA 02138 phone: +617/576-1151 fax: +617/576-2806 e-mail: clim-ila@ila.com   Received: from BBN.COM by LABS-N.bbn.COM id aa25091; 22 Jan 91 12:26 EST Received: from SLUG-EAST.SCRC.Symbolics.COM by BBN.COM id aa29057; 22 Jan 91 12:23 EST Received: from CASSIOPEIA.Mystech.DialNet.Symbolics.com (DIAL|17039312032) by SLUG-EAST.SCRC.Symbolics.COM via DIAL with SMTP id 11515; 22 Jan 1991 11:37:35-0500 Date: Tue, 22 Jan 91 10:04 EST From: Myriam Subject: output recording To: clim@BBN.COM Message-ID: <19910122150452.2.MYRIAM@CASSIOPEIA.Mystech.DialNet.Symbolics.com> Character-Type-Mappings: (1 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB") Fonts: CPTFONT, CPTFONTCB I was not able to get output-recording capability upon scrolling on a CLIM window pane with any graphics functions. Here is a simple example reproducing the problem. Upon scrolling, none of the lines drawn are preserved. I tried with-output-recording-options wrapped around clim:draw-line* with no success. What am I doing wrong? ;;; -*- Mode: LISP; Base: 10; Syntax: Common-Lisp; Package: USER -*- (defvar 1*root*0 (clim:open-root-window :SHEET)) (clim:define-application-frame1 TEST 0 () () (:PANES ((menu :COMMAND-MENU) (display :APPLICATION ))) (:LAYOUT ((main (:COLUMN :REST (MENU :COMPUTE) (DISPLAY :REST))))) (:COMMAND-DEFINER t) ) (define-test-command 1(com-Exit :MENU 0t1) 0 () (clim:frame-exit clim:*application-frame*) ) (define-test-command 1(com-test :MENU 0t1) 0 () (let ((display-pane (clim:get-frame-pane clim:*application-frame* 'DISPLAY))) (LOOP WITH line-height = (clim:stream-line-height display-pane) WITH y = 50 REPEAT 100 DO (clim:draw-line* display-pane 200 y 200 (+ y line-height) ) (terpri display-pane) (incf y line-height) ) ) ) (defun 1run-test0 () (clim:run-frame-top-level (clim:make-application-frame 'TEST :PARENT *root*)) )   Received: from BBN.COM by LABS-N.bbn.COM id aa25297; 22 Jan 91 12:44 EST Received: from FUJI.ILA.COM by BBN.COM id aa29628; 22 Jan 91 12:38 EST Received: from MAX-FLEISCHER.SF.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 138357; 22 Jan 91 12:40:32 EST Date: Tue, 22 Jan 91 09:26 PST From: Richard Lamson Subject: Did anybody ever respond to this message?? [just cleaning out old mail] To: "Mark A. Son-Bell" , Jim Veitch , bug-clim-ila@fuji.ila.com, Rainer Koenig , clim@BBN.COM, Bug-CLIM@fuji.ila.com cc: bugs@franz.com, rsl@max-fleischer.sf.dialnet.ila.com In-Reply-To: <19910121234217.4.MAS-B@FUJI.ILA.COM>, <9101090828.AA12461@is.informatik.uni-stuttgart.de>, <9101091955.AA15631@crisp.Franz.COM>, <19910109175315.5.RSL@MAX-FLEISCHER.SF.Dialnet.ILA.COM> Message-ID: <19910122172607.9.RSL@MAX-FLEISCHER.SF.Dialnet.ILA.COM> Reply-To: rsl@ila.com Yes, I did in the last referenced message. There is also a message from Jim Veitch in the second-to-last reference. I can send you the messages if you are interested.   Received: from BBN.COM by LABS-N.BBN.COM id aa11262; 23 Jan 91 17:33 EST Received: from FUJI.ILA.COM by BBN.COM id aa02043; 23 Jan 91 17:26 EST Date: Wed, 23 Jan 91 17:29 EST From: "Mark A. Son-Bell" Subject: Add me to mailing list please To: brian@granite.jpl.nasa.gov, clim@BBN.COM In-Reply-To: <9101181919.AA23289@granite.Jpl.Nasa.Gov> Message-ID: <19910123222920.3.MAS-B@FUJI.ILA.COM> Date: Fri, 18 Jan 91 11:19:10 PST From: Brian of ASTD-CP I hope I'm writing to the right place... I'm interested in CLIM and would like to be added to the mailing list. (Such requests should normally be sent to clim-requests@bbn.com. I've forwarded this for you.) If you have any standard blurb No standard (electronic) blurbs, but I'll try to answer your questions below. for beginners that answers 1. what is CLIM? The Common Lisp Interface Manager, a platform-independent CL UIMS. There are currently back-ends for X, MS-Windows, MacOS, and Genera. CLIM is the product of an informal coalition of Lisp companies: ILA, Symbolics, Xerox, Lucid, Franz, Siemens Nixdorf, and Harlequin. The goal of CLIM is to provide portability for complex interactive Common Lisp applications, and to provide high-level constructs and tools for user-interface building. 2. how do I get it? Contact your Common Lisp vendor or ILA (at the address shown below). etc. etc. please send that to me also. Thanks (if you are the right place) and apologies (if you are not) brian Mark Son-Bell ILA 114 Mt. Auburn St. 4th Floor Cambridge, MA 02138 e-mail: clim-ila@ila.com phone: +617/576-1151 fax: +617/576-2806   Received: from BBN.COM by LABS-N.BBN.COM id aa00477; 31 Jan 91 14:51 EST Received: from charon.arc.nasa.gov by BBN.COM id aa25258; 31 Jan 91 14:47 EST Received: from ROMAN-A-CLEF.arc.nasa.gov by CHARON.arc.nasa.gov via INTERNET with SMTP id 77828; 31 Jan 91 11:47:43 PST Date: Thu, 31 Jan 91 11:47 PST From: will taylor Subject: :label option to menu-choose To: clim@BBN.COM cc: taylor@charon.arc.nasa.gov Message-ID: <19910131194710.4.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov> I am using Franz Allegro 3.1.13 and CLIM 0.9 to begin converting a Symbolics dynamic windows user interface to CLIM. Apparently, the :label option to menu-choose does not produce a menu label under Allegro (ILA Reference Manual, 24 Aug 90: "Not all CLIM implementations may provide such a label"). What is the implementation independent way in CLIM to "pop-up" a menu to the user asking a question (which becomes the label) and having the user provide an answer with a mouse click, ala tv:menu-choose? ==> Will Taylor NASA Ames Research Center   Received: from BBN.COM by LABS-N.BBN.COM id aa15097; 1 Feb 91 16:01 EST Received: from charon.arc.nasa.gov by BBN.COM id aa19765; 1 Feb 91 15:51 EST Received: from ROMAN-A-CLEF.arc.nasa.gov by CHARON.arc.nasa.gov via INTERNET with SMTP id 77925; 1 Feb 91 12:40:46 PST Date: Fri, 1 Feb 91 12:40 PST From: will taylor Subject: :panes option to define-application-frame To: clim@BBN.COM Message-ID: <19910201204009.8.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov> In Franz Allegro 3.1.13, CLIM 0.9, I donot seem to be able to construct a frame of multiple layouts: I get #:frame declared special when I compile it, and unbound symbol #:frame when I try to create it. Code follows: Will Taylor NASA Ames Research Center ;;; #:FRAME DECLARED SPECIAL BUG (in-package 'clim-demo) (define-application-frame AC-BUG () ; No super classes ;; state variables ((banner-pane :initform nil :accessor banner-pane) (command-pane :initform nil :accessor command-pane) ) ;; frame layouts (:panes ((class-wts/all-classes-config :initform (let ((frame-mgr (find-frame-manager :server-path *default-server-path*))) (with-frame (frame) (with-style (frame-mgr frame) (with-frame-slots (banner-pane command-pane) (vertically (make-clim-pane (banner-pane :type 'clim-stream-pane :hs 600 :vs 40 :scroll-bars nil :label "NASA Ames Research Center - FIA") :default-text-style '(:fix :bold :very-large)) (make-clim-pane (command-pane :type 'command-pane-class :hs 600 :vs 30 :scroll-bars nil) :default-text-style '(:sans-serif :bold :large)))))))) (class-wts/all-attributes-config ()) (all-classes/all-attributes-config ()) (double=all-attributes-config ()) (double=all-classes-config ()) (metrics-config ()) (plot-config ()) (doc-config ()) )) (:command-definer t) (:top-level (clim-top-level)) ) (defun RUN-AC-BUG (&key (server-path *default-server-path*)) "start up autoclass results frame" (launch-frame 'ac-bug :title "AC Results UI" ; for icon :where server-path)) ;;; ;;;******************************************************* ;;; (defvar *ac-bug* nil) (defmethod RUN-FRAME-TOP-LEVEL :BEFORE ((frame AC-BUG)) "do user initialization of autoclass results frame" (setf *ac-bug* frame))   Received: from BBN.COM by LABS-N.BBN.COM id aa07826; 4 Feb 91 4:49 EST Received: from relay.cs.net by BBN.COM id aa29597; 4 Feb 91 4:45 EST Received: from iraun1.ira.uka.de by RELAY.CS.NET id aa10222; 4 Feb 91 4:45 EST Received: from [129.13.4.15] by iraun1.ira.uka.de id aa13831; 4 Feb 91 10:43 MET Received: from ossi by fs2.fzi.uka.de id aa21841; 4 Feb 91 9:34 GMT Date: Mon, 4 Feb 91 9:42:27 GMT From: Rainer Koenig To: clim@BBN.COM Subject: mailing-list Please add me to the mailing-list. Thanks Rainer ============================================================================== Rainer Koenig rkoenig@fzi.uka.de Forschungszentrum Informatik king@fzi.uka.de an der Universitaet Karlsruhe Abtl. Technische Expertensysteme und Robotik Haid-und-Neu-Strasse 10-14 D - 7500 Karlsruhe 1 Tel.: (+49 | 0) 721 / 6906-313 ==============================================================================   Received: from DINO.BBN.COM by LABS-N.BBN.COM id aa14191; 4 Feb 91 15:03 EST To: will taylor cc: clim@BBN.COM, clim-bug@ila.com Subject: Re: :label option to menu-choose In-reply-to: Your message of Thu, 31 Jan 91 11:47:00 -0800. <19910131194710.4.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov> Date: Mon, 04 Feb 91 14:54:12 -0500 From: kanderso@dino.bbn.com Date: Thu, 31 Jan 91 11:47 PST From: will taylor Subject: :label option to menu-choose To: clim@BBN.COM cc: taylor@charon.arc.nasa.gov I am using Franz Allegro 3.1.13 and CLIM 0.9 to begin converting a Symbolics dynamic windows user interface to CLIM. Apparently, the :label option to menu-choose does not produce a menu label under Allegro (ILA Reference Manual, 24 Aug 90: "Not all CLIM implementations may provide such a label"). What is the implementation independent way in CLIM to "pop-up" a menu to the user asking a question (which becomes the label) and having the user provide an answer with a mouse click, ala tv:menu-choose? ==> Will Taylor NASA Ames Research Center Unfortunately the label is quitely ignored in a Silica based CLIM. Perhaps menu choose from drawer would help. Here are some other problems: 1. It would also be nice if you could have label items in the menu that were not selectable as in dw:menu-choose. 2. There is no way to not select an item in the menu somehow as you can with application-frame menu's by clicking outside the window. 3. If you click right on a menu item such as the [1] in: (menu-choose '(1 2 3) :associated-window (ci::get-menu)) You get the presentation-menu. If you click right on that you get another menu recursively, and if you click left you get an error. This commonly screws our users. k   Received: from BBN.COM by LABS-N.BBN.COM id aa19079; 5 Feb 91 0:39 EST Received: from FUJI.ILA.COM by BBN.COM id aa04876; 5 Feb 91 0:37 EST Received: from MAX-FLEISCHER.SF.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 231336; 5 Feb 91 00:39:14 EST Date: Mon, 4 Feb 91 16:29 PST From: Richard Lamson Subject: :panes option to define-application-frame To: will taylor , Bug-CLIM@ila.com, clim@BBN.COM cc: rsl@max-fleischer.sf.dialnet.ila.com In-Reply-To: <19910201204009.8.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov> Message-ID: <19910205002956.5.RSL@MAX-FLEISCHER.SF.Dialnet.ILA.COM> Reply-To: rsl@ila.com Please send bug reports for CLIM 0.9 to Bug-CLIM@ILA.COM in the future. Thanks. Date: Fri, 1 Feb 91 12:40 PST From: will taylor In Franz Allegro 3.1.13, CLIM 0.9, I donot seem to be able to construct a frame of multiple layouts: I get #:frame declared special when I compile it, and unbound symbol #:frame when I try to create it. Code follows: The :PANES option to DEFINE-APPLICATION-FRAME is, unfortunately, difficult to use without an example. I don't think we publish any examples of its use. I believe this section of the documentation will be substantially rewritten for the next release. Also, I believe there is a bug in the implementation of SELECT-FRAME-LAYOUT which was shipped with 0.9. There is a patch numbered 37 which is supposed to fix this, but it has a bug in it. I will ask one of the ILA folks in Cambridge to fix this for real, but I will include the source of the fixed fix below. If you had patch 37 loaded, you would at least have been warned that your :PANES option had a syntax error in it, by the way. Here is approximately what it says now: Warning: A layout name must be a symbol, not (CLASS-WTS/ALL-CLASSES-CONFIG :INITFORM ...). The documentation says of the :PANES option: Its format is a list of two-element lists. The first element of each sublist is a symbol naming the layout; the second element is a form what evaluates to a pane. So, your frame should say: (define-application-frame AC-BUG () ; No super classes ;; state variables ((banner-pane :initform nil :accessor banner-pane) (command-pane :initform nil :accessor command-pane) ) ;; frame layouts (:panes ;;; Note no extra set of parentheses, and no :INITFORM keyword (class-wts/all-classes-config (let ((frame-mgr (find-frame-manager :server-path *default-server-path*))) (with-frame (frame) (with-style (frame-mgr frame) (with-frame-slots (banner-pane command-pane) (vertically (make-clim-pane (banner-pane :type 'clim-stream-pane :hs 600 :vs 40 :scroll-bars nil :label "NASA Ames Research Center - FIA") :default-text-style '(:fix :bold :very-large)) (make-clim-pane (command-pane :type 'command-pane-class :hs 600 :vs 30 :scroll-bars nil) :default-text-style '(:sans-serif :bold :large)))))))) ;;; Selecting one of the following configurations would cause an error, ;;; of course, since the second element of the list does not evaluate to ;;; a pane. (class-wts/all-attributes-config ()) (all-classes/all-attributes-config ()) (double=all-attributes-config ()) (double=all-classes-config ()) (metrics-config ()) (plot-config ()) (doc-config ()) )) (:command-definer t) (:top-level (clim-top-level)) ) By the way, here is a cliche you may want to use with the :PANES option. Remember that if you want to reuse already-created panes in different configurations, you need to write them down someplace: (define-application-frame two-configurations () ((pane-a :initform nil) (pane-b :initform nil)) (:panes (configuration-1 (with-frame-slots (pane-a pane-b) (vertically (or pane-a (make-clim-pane (pane-a ...) ...)) (or pane-b (make-clim-pane (pane-b ...) ...))))) (configuration-2 (with-frame-slots (pane-a pane-b) (horizontally (or pane-a (make-clim-pane (pane-a ...) ...)) (or pane-b (make-clim-pane (pane-b ...) ...))))))) ----------------------------------------------------------------- Here is the fixed version of SELECT-FRAME-LAYOUT: ----------------------------------------------------------------- (in-package :windshield) (defmethod select-frame-layout ((frame frame) layout &optional how) (let ((manager (frame-manager frame)) (*old-layout* (frame-pane frame)) *new-layout*) (declare (special *new-layout* *old-layout*)) (assert manager () "A frame must be adopted before a layout can be changed") ;; slot-unbound takes care of building the layout if necessary. (setq *new-layout* (slot-value frame layout)) ;; Need to be able to do (pane-frame ) soon. (register-pane-frame *new-layout* frame) (selecting-frame-layout manager frame *new-layout* how) (setf (frame-pane frame) *new-layout*) ;; Don't need to do (pame-frame ) any more. (unregister-pane-frame *old-layout*)))   Received: from DINO.BBN.COM by LABS-N.BBN.COM id aa24174; 7 Feb 91 12:11 EST To: clim@BBN.COM Cc: kanderson@BBN.COM Subject: presentation actions Date: Thu, 07 Feb 91 12:03:28 -0500 From: kanderso@dino.bbn.com We were suprised to find that CLIM 0.9 did not have define-presentation-action, so Jeff Morrill wrote one: (defmacro define-action (name (from-type to-type &key command-table gesture tester documentation (menu t)) arglist &body body) ;; This is similar to define-presentation-translator, except that the body of the ;; action is not intended to return a value, but should instead side-effect some ;; sort of application state. (progn (pushnew 'window arglist) (pushnew 'gesture arglist) ;; To prevent the body from getting evaluated in the process of testing the ;; applicability of the translator, the tester should return T as the second ;; value. (cond ((not tester) (setq tester `((presentation) (values (ci::presentation-matches-type-p presentation ',from-type) t)))) (t (setq tester `(,(first tester) (values (progn ,@(rest tester)) t))))) (when (and command-table (eql to-type 'command)) (setq to-type `(command :command-table ,(eval command-table)))) `(clim:define-presentation-translator ,name (,from-type ,to-type :tester ,tester :gesture ,gesture :menu ,menu :documentation ((stream) (format stream "~A" ,documentation))) ,arglist (when (not (eq gesture :for-menu)) ,@body ;; pretty big hammer, but we need to get blips etc out of the input buffer. (clim:stream-clear-input window) '(ignore)))))   Received: from BBN.COM by LABS-N.BBN.COM id aa25946; 7 Feb 91 14:21 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa04319; 7 Feb 91 14:19 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 395843; 7 Feb 1991 14:15:12-0500 Date: Thu, 7 Feb 1991 14:05-0500 From: Scott McKay Subject: presentation actions To: kanderso@dino.bbn.com, clim@BBN.COM cc: kanderson@BBN.COM In-Reply-To: The message of 7 Feb 1991 12:03 EST from kanderso@dino.bbn.com Message-ID: <19910207190517.7.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Thu, 7 Feb 1991 12:03 EST From: kanderso@dino.bbn.com We were suprised to find that CLIM 0.9 did not have define-presentation-action, so Jeff Morrill wrote one: If you think you want presentation actions, you are probably wrong. They are used for one thing only: performing some sort of action inside of the context of the input editor. The only sorts of things that are appropriate to do inside the input editor are (1) displaying menus, (2) displaying additional information that will be helpful in constructing commands, and (3) simple reformatting of displayed data (for example, the expansion of ellipses in a list of possibilities). Any use of a presentation action to do something application specific is incorrect, and should be recast as an application command plus an ordinary translator. I just surveyed all of Genera and all of our layered products, and looked at 565 translators. Of these, 165 were actions. When I looked at that list, I found that Symbolics hackers are as guilty as anyone in misusing them. Of these 165 actions, only about 30 are legitimately actions. If you plan to write actions that do fundamentally different sorts of things than these, then you are probably misusing them. Here is the list: Menus: MENU and BLANK-AREA-MENU -- the Mouse-Right menu WINDOW-OPERATION-MENU and WINDOW-OPERATION-MENU-BLANK-AREA SYSTEM-MENU and SYSTEM-MENU-BLANK-AREA -- the shift-Mouse-Right menu MARKING-AND-YANKING-MENU and MARKING-AND-YANKING-MENU-BLANK-AREA -- control-Mouse-Right PRESENTATION-DEBUGGING-MENU -- super-Mouse-Right Displaying additional information: EXPAND-ELLIPSIS and ELLIPSIS-MENU -- for expanding ellipses in completion lists COM-SHOW-DOCUMENTATION-FOR-COMMAND-NAME-DURING-HELP -- displays documentation about a command while you are typing the command in EDIT-VIEWSPECS and REPRESENT-DIFFERENTLY -- change just the visual appearance of something, but not its semantics, during command input. DISPLAY-REST-OF-HISTORY, EDITOR-YANK, and DISPLAY-REST-OF-CHANGE-HISTORY Application independent tools for building up input sentences: YANK-WORD, MARK-WORD, YANK-MARKED-TEXT, YANK-FROM-KILL-RING, SAVE-MARKED-TEXT, UNMARK-MARKED-TEXT, CLEAR-MARKED-TEXT, CLICK-AND-HOLD-MARK-REGION, CLICK-AND-HOLD-MARK-REGION-MENU, and EXTEND-MARKED-TEXT are actions because they need to operate in any context and are used for building up command lines, rather than for asking an application to do something. REGION-TO-SEQUENCE cannot be done as a translator for reasons I cannot articulate very well Window management: SELECT-WINDOW -- so that mousing another window selects it Executive summary: don't use actions. Use translators. (defmacro define-action (name (from-type to-type &key command-table gesture tester documentation (menu t)) arglist &body body) ...)   Received: from BBN.COM by LABS-N.BBN.COM id aa26879; 7 Feb 91 15:30 EST Received: from MCC.COM by BBN.COM id aa07190; 7 Feb 91 15:22 EST Received: from phoenix.aca.mcc.com by MCC.COM with TCP/SMTP; Thu 7 Feb 91 14:22:06-CST Posted-Date: Thu, 7 Feb 91 14:22 CST Received: from KISIN.ACA.MCC.COM by phoenix.aca.mcc.com (4.0/ACAv4.1i) id AA08950; Thu, 7 Feb 91 14:22:03 CST Date: Thu, 7 Feb 91 14:22 CST From: David Gadbois Subject: presentation actions To: Scott McKay Cc: clim@BBN.COM In-Reply-To: <19910207190517.7.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Message-Id: <19910207202202.1.GADBOIS@KISIN.ACA.MCC.COM> Reply-To: gadbois@cs.utexas.edu Date: Thu, 7 Feb 1991 14:05-0500 From: Scott McKay Date: Thu, 7 Feb 1991 12:03 EST From: kanderso@dino.bbn.com We were suprised to find that CLIM 0.9 did not have define-presentation-action, so Jeff Morrill wrote one: If you think you want presentation actions, you are probably wrong. They are used for one thing only: performing some sort of action inside of the context of the input editor. The only sorts of things that are appropriate to do inside the input editor are (1) displaying menus, (2) displaying additional information that will be helpful in constructing commands, and (3) simple reformatting of displayed data (for example, the expansion of ellipses in a list of possibilities). Any use of a presentation action to do something application specific is incorrect, and should be recast as an application command plus an ordinary translator. OK, but then what is the canonical way of doing some side effect without going through a command? For example, suppose I wanted to have some mosue-sensitive buttons that control what is being displayed like those little triangle things in Mac OS 7 directory listings. I though that presentation actions would be the way to implement these. Or is this kind of usage considered to be OK? Furthermore, I can think of reasonable interfaces where one would prefer not to have command lines appearing at all. For these, I would do all the work with actions. (I just realized you might be able to access application commands via command translators without having some king of echo area -- is this possible?) And why is it a bad thing to use actions for other than the uses you mention? --David Gadbois   Received: from BBN.COM by LABS-N.BBN.COM id aa26973; 7 Feb 91 15:37 EST Received: from brazil.cambridge.apple.com by BBN.COM id aa07673; 7 Feb 91 15:32 EST Received: from [90.223.0.23] by brazil.cambridge.apple.com with SMTP (5.64/25-eef) id AA12038; Thu, 7 Feb 91 12:41:31 -0800 for kanderson@BBN.COM Message-Id: <9102072041.AA12038@brazil.cambridge.apple.com> Date: Thu, 07 Feb 91 15:10:22 From: "David A. Moon" To: Scott McKay Subject: Re: presentation actions Cc: kanderso@dino.bbn.com, clim@BBN.COM, kanderson@BBN.COM It might be instructive to see a list of the 135 examples of abuse, also. By the way, I believe that now and then there are legitimate application-specific presentation actions. The key test for whether something should be an action, I believe, is that it makes sense to do it in the middle of entering a command sentence and doing it will not interfere with the input of a command sentence. For example, an application framework might have an action that changes what information one of its panes displays. This makes sense to do in the middle of entering a command because information displayed in that pane might be used in formulating the arguments to the command. This needn't interfere with the input of the command since a pane can be redisplayed without throwing away the pending partial command.   Received: from BBN.COM by LABS-N.BBN.COM id aa28209; 7 Feb 91 17:08 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa11862; 7 Feb 91 17:03 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 395895; 7 Feb 1991 17:07:43-0500 Date: Thu, 7 Feb 1991 16:57-0500 From: Scott McKay Subject: presentation actions To: gadbois@cs.utexas.edu, SWM@sapsucker.scrc.symbolics.com cc: clim@BBN.COM In-Reply-To: <19910207202202.1.GADBOIS@KISIN.ACA.MCC.COM> Message-ID: <19910207215755.2.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Thu, 7 Feb 1991 15:22 EST From: David Gadbois Date: Thu, 7 Feb 1991 14:05-0500 From: Scott McKay Date: Thu, 7 Feb 1991 12:03 EST From: kanderso@dino.bbn.com We were suprised to find that CLIM 0.9 did not have define-presentation-action, so Jeff Morrill wrote one: If you think you want presentation actions, you are probably wrong. They are used for one thing only: performing some sort of action inside of the context of the input editor. The only sorts of things that are appropriate to do inside the input editor are (1) displaying menus, (2) displaying additional information that will be helpful in constructing commands, and (3) simple reformatting of displayed data (for example, the expansion of ellipses in a list of possibilities). Any use of a presentation action to do something application specific is incorrect, and should be recast as an application command plus an ordinary translator. OK, but then what is the canonical way of doing some side effect without going through a command? For example, suppose I wanted to have some mosue-sensitive buttons that control what is being displayed like those little triangle things in Mac OS 7 directory listings. I though that presentation actions would be the way to implement these. Or is this kind of usage considered to be OK? I haven't yet seen MacOS 7, so I don't know what it is you are referring to. If it is just redisplay of data that can take place independent of changing application state, then it might be OK. However, if those triangles are only active at some sort of conceptual top-level state, then they should be done with translators. I also don't really understand what the resistance is to "going through a command", since it is no more or no less expensive than an action. The only difference is that actions get run deep in the guts of the input editor. Furthermore, I can think of reasonable interfaces where one would prefer not to have command lines appearing at all. For these, I would do all the work with actions. (I just realized you might be able to access application commands via command translators without having some king of echo area -- is this possible?) "Commands" and "having command lines appear" are separate things. You need not specify an interactor pane in a CLIM application frame. Furthermore, we plan to make CLIM have the DW feature of not echoing commands if you ask it not to. And why is it a bad thing to use actions for other than the uses you mention? If I could show you some of the ways people have misused actions, you would understand why I am trying to tilt the pendulum the other way. But I can't, because they're not mine to show. The problem with actions is that you can get subtle problems from doing stuff inside the input editor. For instance, your interactive streams may not be what you think, or you might end up recursively invoking your applications command parsing loop without knowing it. (Right now, we are helping to straighten out a large program with some subtle, hard-to-fix problems that are exactly caused by using actions instead of translators.) The real point behind my message is that actions are the *exception*, not the rule. Use translators. Every so often, you will want to use an action because a translator will cause you to lose the state of a command you are trying to enter. But not very often. I realize this sounds a lot like "trust me", but really, please trust me on this one. Dave Moon's message on the subject is worth reading again.   Received: from BBN.COM by LABS-N.BBN.COM id aa28325; 7 Feb 91 17:17 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa12398; 7 Feb 91 17:15 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 395896; 7 Feb 1991 17:20:06-0500 Date: Thu, 7 Feb 1991 17:10-0500 From: Scott McKay Subject: Re: presentation actions To: moon@brazil.cambridge.apple.com, SWM@sapsucker.scrc.symbolics.com cc: kanderso@dino.bbn.com, clim@BBN.COM, kanderson@BBN.COM In-Reply-To: <9102072041.AA12038@brazil.cambridge.apple.com> Message-ID: <19910207221018.3.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Thu, 7 Feb 1991 15:10 EST From: moon@brazil.cambridge.apple.com (David A. Moon) It might be instructive to see a list of the 135 examples of abuse, also. Here are some of them. The Debugger ones are particularly insidious because the use of an action almost looks reasonable, since they do some amusing things to the stuff in the output history (such as leaving little tick marks to say something happened). Some of the ones I didn't include in the list are artifacts of how DW handles certain kinds of translators, so the programmer only erred once to get two mistakes :-). The following are could be replaced by simple commands. DBG:REPLACE-UNBOUND DBG:SET-BREAKPOINT-FROM-DISASSEMBLY DBG:COMPLEX-BREAKPOINT-FROM-DISASSEMBLY DBG:CLEAR-BREAKPOINT-FROM-DISASSEMBLY DBG:MONITOR-LOCATION DBG:UNMONITOR-LOCATION DBG:MONITOR-SPECIAL-VARIABLE DBG:UNMONITOR-SPECIAL-VARIABLE These also, except for some stupid Zwei problems. These constitute a pretty bad example of how we intended DW to be used. ZWEI:CLASS-SHOW-CLASS-SUPERCLASSES ZWEI:CLASS-SHOW-CLASS-SUBCLASSES ZWEI:CLASS-SHOW-CLASS-INITARGS ZWEI:CLASS-SHOW-CLASS-SLOTS ZWEI:CLASS-SHOW-CLASS-METHODS ZWEI:CLASS-SHOW-CLASS-GENERIC-FUNCTIONS ZWEI:CLOS-GENERIC-FUNCTION-SHOW FLAVOR::SHOW-FLAVOR-COMPONENTS FLAVOR::SHOW-FLAVOR-COMPONENTS-FOR-ZWEI FLAVOR::SHOW-FLAVOR-DEPENDENTS FLAVOR::SHOW-FLAVOR-DEPENDENTS-FOR-ZWEI FLAVOR::SHOW-FLAVOR-OPERATIONS FLAVOR::SHOW-FLAVOR-OPERATIONS-FOR-ZWEI FLAVOR::SHOW-FLAVOR-INSTANCE-VARIABLES FLAVOR::SHOW-FLAVOR-INSTANCE-VARIABLES-FOR-ZWEI FLAVOR::SHOW-FLAVOR-METHODS FLAVOR::SHOW-FLAVOR-METHODS-FOR-ZWEI FLAVOR::SHOW-FLAVOR-INITIALIZATIONS FLAVOR::SHOW-FLAVOR-INITIALIZATIONS-FOR-ZWEI FLAVOR::SHOW-FLAVOR-COMPONENTS-OF-FLAVOR FLAVOR::SHOW-FLAVOR-COMPONENTS-OF-FLAVOR-FOR-ZWEI FLAVOR::SHOW-FLAVOR-DEPENDENTS-OF-FLAVOR FLAVOR::SHOW-FLAVOR-DEPENDENTS-OF-FLAVOR-FOR-ZWEI FLAVOR::SHOW-FLAVOR-OPERATIONS-OF-FLAVOR FLAVOR::SHOW-FLAVOR-OPERATIONS-OF-FLAVOR-FOR-ZWEI FLAVOR::SHOW-FLAVOR-INSTANCE-VARIABLES-OF-FLAVOR FLAVOR::SHOW-FLAVOR-INSTANCE-VARIABLES-OF-FLAVOR-FOR-ZWEI FLAVOR::SHOW-FLAVOR-METHODS-OF-FLAVOR FLAVOR::SHOW-FLAVOR-METHODS-OF-FLAVOR-FOR-ZWEI FLAVOR::SHOW-FLAVOR-INITIALIZATIONS-OF-FLAVOR FLAVOR::SHOW-FLAVOR-INITIALIZATIONS-OF-FLAVOR-FOR-ZWEI FLAVOR::SHOW-FLAVOR-COMPONENTS-OF-FUNCTION-SPEC FLAVOR::SHOW-FLAVOR-COMPONENTS-OF-FUNCTION-SPEC-FOR-ZWEI FLAVOR::SHOW-FLAVOR-DEPENDENTS-OF-FUNCTION-SPEC FLAVOR::SHOW-FLAVOR-DEPENDENTS-OF-FUNCTION-SPEC-FOR-ZWEI FLAVOR::SHOW-FLAVOR-OPERATIONS-OF-FUNCTION-SPEC FLAVOR::SHOW-FLAVOR-OPERATIONS-OF-FUNCTION-SPEC-FOR-ZWEI FLAVOR::SHOW-FLAVOR-INSTANCE-VARIABLES-OF-FUNCTION-SPEC FLAVOR::SHOW-FLAVOR-INSTANCE-VARIABLES-OF-FUNCTION-SPEC-FOR-ZWEI FLAVOR::SHOW-FLAVOR-METHODS-OF-FUNCTION-SPEC FLAVOR::SHOW-FLAVOR-METHODS-OF-FUNCTION-SPEC-FOR-ZWEI FLAVOR::SHOW-FLAVOR-INITIALIZATIONS-OF-FUNCTION-SPEC FLAVOR::SHOW-FLAVOR-INITIALIZATIONS-OF-FUNCTION-SPEC-FOR-ZWEI FLAVOR::SHOW-FLAVOR-COMPONENTS-OF-INSTANCE-VARIABLE-ACCESSOR FLAVOR::SHOW-FLAVOR-COMPONENTS-OF-INSTANCE-VARIABLE-ACCESSOR-FOR-ZWEI FLAVOR::SHOW-FLAVOR-DEPENDENTS-OF-INSTANCE-VARIABLE-ACCESSOR FLAVOR::SHOW-FLAVOR-DEPENDENTS-OF-INSTANCE-VARIABLE-ACCESSOR-FOR-ZWEI FLAVOR::SHOW-FLAVOR-OPERATIONS-OF-INSTANCE-VARIABLE-ACCESSOR FLAVOR::SHOW-FLAVOR-OPERATIONS-OF-INSTANCE-VARIABLE-ACCESSOR-FOR-ZWEI FLAVOR::SHOW-FLAVOR-INSTANCE-VARIABLES-OF-INSTANCE-VARIABLE-ACCESSOR FLAVOR::SHOW-FLAVOR-INSTANCE-VARIABLES-OF-INSTANCE-VARIABLE-ACCESSOR-FOR-ZWEI FLAVOR::SHOW-FLAVOR-METHODS-OF-INSTANCE-VARIABLE-ACCESSOR FLAVOR::SHOW-FLAVOR-METHODS-OF-INSTANCE-VARIABLE-ACCESSOR-FOR-ZWEI FLAVOR::SHOW-FLAVOR-INITIALIZATIONS-OF-INSTANCE-VARIABLE-ACCESSOR FLAVOR::SHOW-FLAVOR-INITIALIZATIONS-OF-INSTANCE-VARIABLE-ACCESSOR-FOR-ZWEI FLAVOR::SHOW-FLAVOR-COMPONENTS-OF-INSTANCE FLAVOR::SHOW-FLAVOR-COMPONENTS-OF-INSTANCE-FOR-ZWEI FLAVOR::SHOW-FLAVOR-DEPENDENTS-OF-INSTANCE FLAVOR::SHOW-FLAVOR-DEPENDENTS-OF-INSTANCE-FOR-ZWEI FLAVOR::SHOW-FLAVOR-OPERATIONS-OF-INSTANCE FLAVOR::SHOW-FLAVOR-OPERATIONS-OF-INSTANCE-FOR-ZWEI FLAVOR::SHOW-FLAVOR-INSTANCE-VARIABLES-OF-INSTANCE FLAVOR::SHOW-FLAVOR-INSTANCE-VARIABLES-OF-INSTANCE-FOR-ZWEI FLAVOR::SHOW-FLAVOR-METHODS-OF-INSTANCE FLAVOR::SHOW-FLAVOR-METHODS-OF-INSTANCE-FOR-ZWEI FLAVOR::SHOW-FLAVOR-INITIALIZATIONS-OF-INSTANCE FLAVOR::SHOW-FLAVOR-INITIALIZATIONS-OF-INSTANCE-FOR-ZWEI FLAVOR::SHOW-GENERIC-FUNCTION FLAVOR::SHOW-GENERIC-FUNCTION-FOR-ZWEI FLAVOR::SHOW-GENERIC-FUNCTION-OF-GENERIC-FUNCTION FLAVOR::SHOW-GENERIC-FUNCTION-OF-GENERIC-FUNCTION-FOR-ZWEI FLAVOR::SHOW-GENERIC-FUNCTION-OF-FUNCTION-SPEC-1 FLAVOR::SHOW-GENERIC-FUNCTION-OF-FUNCTION-SPEC-1-FOR-ZWEI FLAVOR::SHOW-GENERIC-FUNCTION-OF-INSTANCE-VARIABLE-ACCESSOR FLAVOR::SHOW-GENERIC-FUNCTION-OF-INSTANCE-VARIABLE-ACCESSOR-FOR-ZWEI These should all simply be translators, too. SAGE::RECORD-GROUP-NAME-TO-COM-SHOW-DOCUMENTATION-TRANSLATOR DDEX::RECORD-GROUP-NAME-TO-COM-SHOW-DOCUMENTATION-OVERVIEW-TRANSLATOR DDEX::RECORD-GROUP-TO-COM-HARDCOPY-DOCUMENTATION-TRANSLATOR DDEX::RECORD-GROUP-NAME-TO-COM-HARDCOPY-DOCUMENTATION-TRANSLATOR DDEX::BOOKMARK-TO-COM-HARDCOPY-DOCUMENTATION-TRANSLATOR DDEX::RECORD-GROUP-NAME-TO-COM-SHOW-DOCUMENTATION-TRANSLATOR DDEX::RECORD-GROUP-NAME-TO-COM-SHOW-OVERVIEW-TRANSLATOR DDEX::RECORD-GROUP-NAME-TO-COM-ADD-BOOKMARK-TRANSLATOR DDEX::RECORD-GROUP-NAME-TO-COM-SHOW-TABLE-OF-CONTENTS-TRANSLATOR ZWEI:RECORD-GROUP-NAME-TO-SHOW-DOCUMENTATION-TRANSLATOR ZWEI:EXPRESSION-TO-SHOW-DOCUMENTATION-TRANSLATOR MAC-APPLICATIONS:RECORD-GROUP-NAME-TO-COM-SHOW-DOC-TRANSLATOR MAC-APPLICATIONS:RECORD-GROUP-NAME-TO-COM-SHOW-OVERVIEW-TRANSLATOR   Received: from COOPER.BBN.COM by LABS-N.BBN.COM id aa28954; 7 Feb 91 18:47 EST Date: Thu, 7 Feb 91 18:36 EDT From: JMORRILL@cooper.bbn.com Subject: missing OR ptype To: CLIM@labs-n.bbn.com X-VMS-To: CLIM What would it take to get an OR presentation type in clim? (and for that matter, AND seems to be missing as well). I have a hard time writing a reasonably interesting presentation type without using disjunction. Or perhaps someone wants to tell me that I don't really want to do that either... I have looked in the sources, and I think I could write it myself if INPUT-NOT-OF-REQUIRED-TYPE did something like signal a condition or did a throw to some tag. An OR parser seems simply to iterate down the disjunction of types, doing ACCEPT, until no failure is signalled. jeff morrill   Received: from BBN.COM by LABS-N.BBN.COM id aa29267; 7 Feb 91 19:42 EST Received: from brazil.cambridge.apple.com by BBN.COM id aa16860; 7 Feb 91 19:40 EST Received: from [90.223.0.23] by brazil.cambridge.apple.com with SMTP (5.64/25-eef) id AA12479; Thu, 7 Feb 91 19:49:52 -0500 for clim@BBN.COM Message-Id: <9102080049.AA12479@brazil.cambridge.apple.com> Date: Thu, 07 Feb 91 19:38:47 From: "David A. Moon" To: Scott McKay Subject: Re: presentation actions Cc: gadbois@cs.utexas.edu, SWM@sapsucker.scrc.symbolics.com, clim@BBN.COM > Date: Thu, 7 Feb 1991 16:57-0500 > From: Scott McKay > > Date: Thu, 7 Feb 1991 12:03 EST > From: kanderso@dino.bbn.com > > OK, but then what is the canonical way of doing some side effect without > going through a command? For example, suppose I wanted to have some > mosue-sensitive buttons that control what is being displayed like those > little triangle things in Mac OS 7 directory listings. I though that > presentation actions would be the way to implement these. Or is this > kind of usage considered to be OK? > > I haven't yet seen MacOS 7, so I don't know what it is you are referring > to. If it is just redisplay of data that can take place independent of > changing application state, then it might be OK. That's what it is. It's enabling or disabling showing the next level of structure in a tree, and doesn't change any state aside from the display, let alone interfering with commands.   Received: from BBN.COM by LABS-N.BBN.COM id aa05438; 8 Feb 91 10:23 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa16335; 8 Feb 91 10:19 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 396018; 8 Feb 1991 10:02:49-0500 Date: Fri, 8 Feb 1991 10:02-0500 From: Scott McKay Subject: Re: presentation actions To: moon@brazil.cambridge.apple.com, SWM@sapsucker.scrc.symbolics.com cc: gadbois@cs.utexas.edu, clim@BBN.COM In-Reply-To: <9102080049.AA12479@brazil.cambridge.apple.com> Message-ID: <19910208150236.6.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Thu, 7 Feb 1991 19:38 EST From: "David A. Moon" > Date: Thu, 7 Feb 1991 16:57-0500 > From: Scott McKay > > Date: Thu, 7 Feb 1991 12:03 EST > From: kanderso@dino.bbn.com > > OK, but then what is the canonical way of doing some side effect without > going through a command? For example, suppose I wanted to have some > mosue-sensitive buttons that control what is being displayed like those > little triangle things in Mac OS 7 directory listings. I though that > presentation actions would be the way to implement these. Or is this > kind of usage considered to be OK? > > I haven't yet seen MacOS 7, so I don't know what it is you are referring > to. If it is just redisplay of data that can take place independent of > changing application state, then it might be OK. That's what it is. It's enabling or disabling showing the next level of structure in a tree, and doesn't change any state aside from the display, let alone interfering with commands. Since Moon didn't say so explicitly: "In that case, it is appropriate to use a presentation action for this."   Received: from ALDERAAN.SCRC.Symbolics.COM by LABS-N.BBN.COM id aa06499; 8 Feb 91 11:41 EST Received: from JUBJUB.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via INTERNET with SMTP id 458606; 8 Feb 1991 10:47:06-0500 Date: Fri, 8 Feb 1991 10:47-0500 From: "John G. Aspinall" Subject: missing OR ptype To: CLIM@labs-n.bbn.com In-Reply-To: The message of 7 Feb 1991 17:36 EST from JMORRILL@cooper.bbn.com Message-ID: <19910208154701.6.JGA@JUBJUB.SCRC.Symbolics.COM> Let me repeat a plea that was issued a couple of days ago. This is an Internet-wide list, and there are several releases of CLIM out there. Please include some version/release information in your mail if you are discussing a specific problem. Date: Thu, 7 Feb 1991 17:36 EST From: JMORRILL@cooper.bbn.com What would it take to get an OR presentation type in clim? (and for that matter, AND seems to be missing as well). CLIM 1.0 has OR and AND presentation types.   From: Dan Cerys Sender: cerys@BBN.COM Organization: Bolt Beranek and Newman Inc. To: JGA@alderaan.scrc.symbolics.com CC: CLIM@labs-n.bbn.com In-reply-to: "John G. Aspinall"'s message of Fri, 8 Feb 1991 10:47-0500 <19910208154701.6.JGA@JUBJUB.SCRC.Symbolics.COM> Subject: missing OR ptype Date: Fri, 8 Feb 91 12:04:23 EST Date: Fri, 8 Feb 1991 10:47-0500 From: "John G. Aspinall" Let me repeat a plea that was issued a couple of days ago. This is an Internet-wide list, and there are several releases of CLIM out there. Please include some version/release information in your mail if you are discussing a specific problem. Date: Thu, 7 Feb 1991 17:36 EST From: JMORRILL@cooper.bbn.com What would it take to get an OR presentation type in clim? (and for that matter, AND seems to be missing as well). CLIM 1.0 has OR and AND presentation types. Just to clarify, we are using CLIM 0.9 on a variety of platforms. The excellent presentation system done by Symbolics for CLIM 1.0 is unfortunately not in 0.9. (Sigh).   Received: from BBN.COM by LABS-N.BBN.COM id aa11067; 8 Feb 91 16:39 EST Received: from ptolemy-arclan.arc.nasa.gov by BBN.COM id aa13357; 8 Feb 91 16:36 EST Received: by ptolemy.arc.nasa.gov (4.1/) id ; Fri, 8 Feb 91 13:39:57 PST To: clim@BBN.COM Path: ptolemy!kthompso From: Kevin Thompson Newsgroups: ri.clim Subject: Re: missing OR ptype Message-Id: <10387@ptolemy-ri.ptolemy.arc.nasa.gov> Date: 8 Feb 91 21:39:55 GMT References: <10371@ptolemy-ri.ptolemy.arc.nasa.gov> Sender: usenet@ptolemy.arc.nasa.gov Organization: NASA-Ames Research Center, Moffett Field, CA Lines: 15 In article <10371@ptolemy-ri.ptolemy.arc.nasa.gov> Dan Cerys writes: >Just to clarify, we are using CLIM 0.9 on a variety of platforms. The >excellent presentation system done by Symbolics for CLIM 1.0 is >unfortunately not in 0.9. (Sigh). Aieeeeeeee. Could someone explain why the various versions of CLIM appear to be diverging? I've heard rumours of this from several different parties, and it *does* after all seem to defeat the main purpose (in my mind at least) of CLIM -- platform independence. Is there a single person (at ILA I assume) who can assuage fears that platform independence is far, far off? Kevin Thompson -- kthompso@ptolemy.arc.nasa.gov NASA-Ames Research Center, Moffett Field, CA   Received: from BBN.COM by LABS-N.BBN.COM id aa12146; 8 Feb 91 18:05 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa17783; 8 Feb 91 18:01 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 396099; 8 Feb 1991 17:56:54-0500 Date: Fri, 8 Feb 1991 17:56-0500 From: Scott McKay Subject: Re: missing OR ptype To: kthompso@ptolemy.arc.nasa.gov, clim@BBN.COM In-Reply-To: <10387@ptolemy-ri.ptolemy.arc.nasa.gov> Message-ID: <19910208225634.3.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Fri, 8 Feb 1991 16:39 EST From: Kevin Thompson In article <10371@ptolemy-ri.ptolemy.arc.nasa.gov> Dan Cerys writes: >Just to clarify, we are using CLIM 0.9 on a variety of platforms. The >excellent presentation system done by Symbolics for CLIM 1.0 is >unfortunately not in 0.9. (Sigh). Aieeeeeeee. Could someone explain why the various versions of CLIM appear to be diverging? I've heard rumours of this from several different parties, and it *does* after all seem to defeat the main purpose (in my mind at least) of CLIM -- platform independence. Is there a single person (at ILA I assume) who can assuage fears that platform independence is far, far off? They aren't diverging. They already diverged, more than six months ago, for a number of reasons. Now they are converging again. CLIM Release 1 is essentially the Symbolics implementation. I do not know the exact details of how Release 1 will be distributed under Franz and Lucid, but in house at Symbolics, we do have Release 1 running under Genera, CLOE, and Lucid, and we expect Franz to be a straight shoot. I believe that ILA will be making it work under MacL (or whatever Lisp is called these days on Macintoshes). So please rest assured that platform independence is very, very close. CLIM Release 2 will be based on the merging of the Symbolics implementation with the ILA implementation. It is planned the Release 2 will include support for more sophisticated window toolkits, such as Motif or SunView. Disclaimer: I hope that I did not mis-represent any of the vendors in this reply. If I did, the fault is entirely mine and I apologize.   Received: from BBN.COM by LABS-N.BBN.COM id aa12490; 8 Feb 91 18:42 EST Received: from CRDGW1.GE.COM by BBN.COM id aa20017; 8 Feb 91 18:40 EST Received: by crdgw1.ge.com (5.57/GE 1.80) id AA28648; Fri, 8 Feb 91 18:40:19 EST Received: from caesar.crd.Ge.Com by alydar.crd.Ge.Com (4.1/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA28493; Fri, 8 Feb 91 18:41:05 EST Date: Fri, 8 Feb 91 18:41:05 EST From: Don Hamilton Message-Id: <9102082341.AA28493@alydar.crd.Ge.Com> Received: by caesar.crd.Ge.Com (4.1/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA14515; Fri, 8 Feb 91 18:41:03 EST To: clim@BBN.COM Subject: clim mail archive? Hi, We have just started receiving posting from the clim mailing list. Does anyone have an archive for all of the clim related messages that have been posted to the mailing list to date? Thanks. -- Don Hamilton   Received: from bbn.com by LABS-N.bbn.COM id aa08578; 10 Feb 91 17:53 EST Received: from uunet.UU.NET by BBN.COM id aa02576; 10 Feb 91 17:50 EST Received: from arris.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA03194; Sun, 10 Feb 91 17:49:59 -0500 Received: by arris.com (4.1/SMI-4.0) id AA05069; Sun, 10 Feb 91 17:44:50 EST Date: Sun, 10 Feb 91 17:44:50 EST From: Richard Shapiro Message-Id: <9102102244.AA05069@arris.com> To: clim@BBN.COM Cc: kanderso@dino.bbn.com In-Reply-To: Scott McKay's message of Thu, 7 Feb 1991 14:05-0500 <19910207190517.7.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Subject: presentation actions >If you think you want presentation actions, you are probably wrong. Like the textbook claim that "if you're calling EVAL, you're probably making a mistake," this considerably overstates the case. There are plenty of situations in which a presentation action is precisely the right thing. Here are a few I've used that don't seem to me to be peculiar in any way: 1. Adding a presentation menu to a mouse button. Since I often write interfaces for naive users, I regularly redefined the mouse-right menu. The default mouse-right menu has too many puzzling entries on it for naive users. 2. Altering a display in the midst of entering a commmand or filling out an accepting-values template. 3. Expanding or contracting a dynamic display (eg, a tree display). >They are used for one thing only: performing some sort of action >inside of the context of the input editor. Not true; see (2) above. Our primary use for this is to allow the user to alter what's on the screen while s/he's filling out an accepting-values (for instance, to expose some presentations that the user wants to select). In short, there are perfectly good reasons for using presentation actions instead of presentation translators (of whatever sort); if CLIM is missing this facility, that oversight should be corrected. rs   Received: from bbn.com by LABS-N.bbn.COM id aa08768; 10 Feb 91 18:30 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa03107; 10 Feb 91 18:28 EST Received: from PORTER.ASL.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 552096; 10 Feb 1991 18:24:14-0500 Date: Sat, 9 Feb 91 07:58-0000 From: Peter Paine Reply-To: p3%Porter.ASL.dialnet.symbolics.com@riverside.scrc.symbolics.com Subject: clim mail archive? To: clim%BBN.COM@riverside.scrc.symbolics.com, hamilton%alydar.crd.ge.com@riverside.scrc.symbolics.com In-Reply-To: <9102082341.AA28493@alydar.crd.Ge.Com> Message-ID: <19910209075827.6.P2@porter.asl.dialnet.symbolics.com> Date: Fri, 8 Feb 91 18:41:05 EST From: Don Hamilton Hi, We have just started receiving posting from the clim mailing list. Does anyone have an archive for all of the clim related messages that have been posted to the mailing list to date? Thanks. -- Don Hamilton Yes, though being in the UK, maybe you'd rather get a copy from closer to home. If no luck, I happy to obligue. Currently BBN's CLIM mailbox stands at 214,072 bytes.   From: cerys@BBN.COM Sender: cerys@BBN.COM Organization: Bolt Beranek and Newman Inc. To: hamilton@alydar.crd.ge.com CC: clim@BBN.COM In-reply-to: Don Hamilton's message of Fri, 8 Feb 91 18:41:05 EST <9102082341.AA28493@alydar.crd.Ge.Com> Subject: clim mail archive? Date: Mon, 11 Feb 91 13:55:50 EST Source-Info: From (or Sender) name not authenticated. The CLIM mailing list automatically maintains an archive, containing all messages ever sent to it. I'll post a message detailing how to get it via anoymous FTP, as soon as our system administrator tells me how to do it. Dan   Received: from bbn.com by LABS-N.BBN.COM id aa25923; 11 Feb 91 20:49 EST Received: from FUJI.ILA.COM by BBN.COM id aa08934; 11 Feb 91 20:47 EST Date: Mon, 11 Feb 91 20:49 EST From: "Mark A. Son-Bell" Subject: Re: missing OR ptype To: clim@BBN.COM In-Reply-To: <10387@ptolemy-ri.ptolemy.arc.nasa.gov> Message-ID: <19910212014959.7.MAS-B@FUJI.ILA.COM> [This is the second attempt to send this message - apologies to anyone who has already received it. No changes from the first attempt.] ******************************************************************************** Date: 8 Feb 91 21:39:55 GMT From: Kevin Thompson In article <10371@ptolemy-ri.ptolemy.arc.nasa.gov> Dan Cerys writes: >Just to clarify, we are using CLIM 0.9 on a variety of platforms. The >excellent presentation system done by Symbolics for CLIM 1.0 is >unfortunately not in 0.9. (Sigh). Aieeeeeeee. Could someone explain why the various versions of CLIM appear to be diverging? (Actually, they're converging.) I've heard rumours of this from several different parties, and it *does* after all seem to defeat the main purpose (in my mind at least) of CLIM -- platform independence. Is there a single person (at ILA I assume) who can assuage fears that platform independence is far, far off? I'll try. Kevin Thompson -- kthompso@ptolemy.arc.nasa.gov NASA-Ames Research Center, Moffett Field, CA [The companies that are cooperating on CLIM are still trying to refine this new game plan of which you've heard, and to produce a clear and comprehensive public statement setting it forth. I hope you will understand my hesitation in being drawn into a dialogue prematurely. With that said, I think some of these rumours need to be cleared up.] As most of the readership of this list will know, there have been two dialects of CLIM during its two-and-two-thirds-years of life, the second coming into being roughly at the one-year mark. These dialects have always been largely - but not 100% - compatible at the API level. They are different, though, in a few important ways at the architecture/ internal-superstructure level, most significantly with respect to the "porting technology," which is to say, how the generic API is connected to a specific underlying Window System or UI Toolkit (like X, Motif, OPEN LOOK, MS-Windows, QuickDraw, PostScript, and so on). Much time and energy has been expended by all of the parties involved with the CLIM effort in balancing the various collective and company- specific interests that are embodied in CLIM. Most recently (and relevantly to Kevin's message) we have been faced with an almost classic tradeoff between quality and functionality: The reference implementation of the older dialect (which goes by the name of "CLIM 1.0") is now far more mature, and therefore of higher quality, than the reference implementation of the newer dialect (which goes by the name of "CLIM 0.9"). [Yes, we know this numbering scheme is confusing: it's a remnant of a period where the sequencing of product releases was much less clear than it is now. We're going to be dropping the designation "0.9".] The newer dialect, though, has design features that are thought to be important for some of the intermediate-to-long-term requirements for anything purporting, as CLIM does, to serve as a true platform- independent UIMS for Common Lisp. Most importantly, it has a rational scheme for connecting up to Toolkits (like Motif and OPEN LOOK), rather than "bare" Window Systems (like Xlib/CLX). (I should note that it is an over-simplification to use the designations "older" and "newer." There are many isolated functions and a few entire modules in "CLIM 1.0" - of which the "excellent 1.0 presentation system" is one - that were developed more recently than the corresponding functions/modules in "CLIM 0.9.") The collective plan is to try to bring to market a family of ~100% API-compatible CLIM 1.0 products as soon as possible. The Genera version is now shipping, and we expect that versions for the other interesting Lisp/OS/WS combinations will follow shortly (within a quarter). In parallel to the CLIM 1.0 product(s) roll-out, we will be finalizing the CLIM 2.0 specification, which we believe fuses the best of the "0.9" and "1.0" dialects (including the latter's presentation subsystem, for those who were wondering). The collective plan is to bring (~100% API-compatible) products based on that 2.0 specification to market within the year on the same Lisp/OS/WS platforms as will be covered by 1.0, and one or two significant new ones. There is one very important class of user for whom the preceding scheme is "less than optimal." These are the people who have already made investments in and/or commitments to the "0.9" dialect, not a few of whom actually got involved with CLIM long enough ago that they began with the first dialect and subsequently migrated to the newer one. All of the CLIM vendor companies have committed themselves to "doing the right thing" for these users. In some cases, this will mean helping them move sideways to the 1.0 dialect. In others, it will mean supporting them as they stay with 0.9 through the 2.0 unification period. It is ILA's belief that the prospects for CLIM have never been better. The first true commercial quality product (CLIM 1.0 for Genera) is shipping. The loose coalition of vendors participating in the CLIM effort is more unified and focused than it has ever been. The resources being devoted to CLIM are increasing, and increasingly concentrated. A hardening of the two-dialect condition into a permanent state of affairs has been avoided. I will be happy to address any further concerns that may be floating around out there, but I would like to ask that vendor-specific questions be directed to the individual vendors themselves. Mark Son-Bell ILA 114 Mt. Auburn St., 4th Floor Cambridge, MA 02138 mas-b@ila.com   Received: from bbn.com by LABS-N.BBN.COM id aa08526; 12 Feb 91 16:15 EST Received: from atc.boeing.com by BBN.COM id aa21019; 12 Feb 91 15:52 EST Received: by atc.boeing.com on Tue, 12 Feb 91 12:51:11 PST Received: by huntsai.boeing.com (1.2/Ultrix2.0-B) id AA02405; Tue, 12 Feb 91 14:58:46 cst Date: Tue, 12 Feb 91 14:58:46 cst From: George Williams Message-Id: <9102122058.AA02405@huntsai.boeing.com> To: clim@BBN.COM Subject: CLIM for Sparc Allegro withdrawn from market? I am trying to purchase CLIM for Allegro CL on Sun-4 architectures. The Boeing purchasing agents have been told that the product can't be bought, and that it has been withdrawn from the market due to bugs. Is this for real?? or are our procurement people not operating with a full charge?? What's going on??? George Williams Boeing Computer Services Internet: george@hsvaic.boeing.com [preferred] POBox 240002, M/S JY-58 UUCP: ...!uunet!uw-beaver!bcsaic!hsvaic!george Huntsville AL 35824-6402 Phone: 205+464-4968 FAX: 205+464-4930 BTN: 464-4968   Received: from bbn.com by LABS-N.BBN.COM id aa11195; 12 Feb 91 20:27 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa04044; 12 Feb 91 20:22 EST Received: from SAMSON.CADR.AMIS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 552883; 12 Feb 1991 20:18:11-0500 Date: Tue, 12 Feb 91 17:19 PST From: "K. Mark Alexander" Subject: CLIM for Sparc Allegro withdrawn from market? To: george@huntsai.boeing.com, clim@BBN.COM In-Reply-To: <9102122058.AA02405@huntsai.boeing.com> Message-ID: <19910213011949.8.KMA@SAMSON.cadr.amis.com> Date: Tue, 12 Feb 91 14:58:46 cst From: George Williams I am trying to purchase CLIM for Allegro CL on Sun-4 architectures. The Boeing purchasing agents have been told that the product can't be bought, and that it has been withdrawn from the market due to bugs. Is this for real?? or are our procurement people not operating with a full charge?? What's going on??? George Williams Boeing Computer Services Internet: george@hsvaic.boeing.com [preferred] POBox 240002, M/S JY-58 UUCP: ...!uunet!uw-beaver!bcsaic!hsvaic!george Huntsville AL 35824-6402 Phone: 205+464-4968 FAX: 205+464-4930 BTN: 464-4968 I don't know about franz. The lucid version of CLIM is still in beta test and we were able to become a beta site in order to get the software. Perhaps you could cut a similar deal with franz.   Received: from bbn.com by LABS-N.BBN.COM id aa11935; 12 Feb 91 22:26 EST Received: from FUJI.ILA.COM by BBN.COM id aa08285; 12 Feb 91 22:21 EST Date: Tue, 12 Feb 91 22:25 EST From: "Mark A. Son-Bell" Subject: CLIM for Sparc Allegro withdrawn from market? To: george@huntsai.boeing.com, clim@BBN.COM In-Reply-To: <9102122058.AA02405@huntsai.boeing.com> Message-ID: <19910213032506.8.MAS-B@FUJI.ILA.COM> Date: Tue, 12 Feb 91 14:58:46 cst From: George Williams I am trying to purchase CLIM for Allegro CL on Sun-4 architectures. The Boeing purchasing agents have been told that the product can't be bought, and that it has been withdrawn from the market due to bugs. Is this for real?? or are our procurement people not operating with a full charge?? What's going on??? George Williams Boeing Computer Services Internet: george@hsvaic.boeing.com [preferred] POBox 240002, M/S JY-58 UUCP: ...!uunet!uw-beaver!bcsaic!hsvaic!george Huntsville AL 35824-6402 Phone: 205+464-4968 FAX: 205+464-4930 BTN: 464-4968 As I said in my last long message to this list, we (ie all of the companies involved in the CLIM effort) are in the middle of a transition right at the moment. I think what your purchasing people were told is that Franz is no longer taking orders for the "CLIM 0.9 for Allegro" product that they had been distributing. This would be consistent with the plan to shift short-term productization efforts to the CLIM 1.0 dialect (which I outlined in the previous message). Beyond that, I think it would be best if I let Franz speak to their specific product plans. You should contact their marketing people at 415-548-3600. Remember that we are still trying to sort out all of the details of the CLIM 1.0 release plan for the Lisps other than Genera and CLOE. Mark Son-Bell ILA mas-b@ila.com   Received: from bbn.com by LABS-N.BBN.COM id aa17783; 13 Feb 91 10:24 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa25593; 13 Feb 91 10:17 EST Received: from PORTER.ASL.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 553021; 13 Feb 1991 10:12:29-0500 Date: Wed, 13 Feb 91 12:20-0000 From: Peter Paine Reply-To: p3%Porter.ASL.dialnet.symbolics.com@riverside.scrc.symbolics.com Subject: presentation actions - how can I live without them? To: clim%BBN.COM@riverside.scrc.symbolics.com In-Reply-To: <9102102244.AA05069@arris.com> Message-ID: <19910213122010.1.P2@porter.asl.dialnet.symbolics.com> Date: Sun, 10 Feb 91 17:44:50 EST From: Richard Shapiro >If you think you want presentation actions, you are probably wrong. [...] I am rather lost. We continue to develop a GUI substrate (called the Jin system) which provides a variety of buttons, switches, thumb wheels, dials, sliders etc. as the kernel of reusable utilities. All interaction is through the mouse. The logic of presentation actions seems to be appropriate. Indeed, the intrusion of any form of interactor dependencies is both an overhead and very unwelcome. Being a believer in staying with the common-denominator philosophies of software use and development, I am at a loss to see where I have parted company with CLIM - our great hope for the delivery of the sort of lisp applications that customers want and will buy. Any explanations would be gratefully received.   Received: from bbn.com by LABS-N.BBN.COM id aa02825; 13 Feb 91 14:12 EST Received: from uunet.UU.NET by BBN.COM id aa09769; 13 Feb 91 14:05 EST Received: from arris.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA15925; Wed, 13 Feb 91 14:05:47 -0500 Received: from dorcas.arris.com by arris.com (4.1/SMI-4.0) id AA17758; Wed, 13 Feb 91 13:54:20 EST Date: Wed, 13 Feb 91 13:54:20 EST From: Richard Shapiro Message-Id: <9102131854.AA17758@arris.com> Received: by dorcas.arris.com (4.1/SMI-4.0) id AA01126; Wed, 13 Feb 91 13:54:07 EST To: clim@BBN.COM In-Reply-To: Peter Paine's message of Wed, 13 Feb 91 12:20-0000 <19910213122010.1.P2@porter.asl.dialnet.symbolics.com> Subject: presentation actions - how can I live without them? >>If you think you want presentation actions, you are probably wrong. > >I am rather lost. > >We continue to develop a GUI substrate (called the Jin system) which >provides a variety of buttons, switches, thumb wheels, dials, sliders >etc. as the kernel of reusable utilities. > >All interaction is through the mouse. >The logic of presentation actions seems to be appropriate. In Symbolics mouse handling, which provided the basic ideas for CLIM mouse handling, there's a distinction between presentation handlers which translate objects into other objects (presentation translators) and presentation handlers which immediately perform an action on an object (presentation actions). In most circumstances, if you want a mouse click on an object to perform some action on that object, you should write a command (rather than a handler) that peforms the action and then write a presentation-to-command-translator which will result in an invocation of that command on the moused-upon object. Presentation actions are only appropriate for a few special purposes, though they're quite necessary for those purposes. So it's not the idea of actions invoked by the mouse that's "probably wrong" (an unfortunate choice of words in any case); it's the specific use of presentation translators vs presentation actions. Also at issue was whether CLIM should provide presentation actions at all, given their limited appropriateness. rs/rshapiro@arris.com   Received: from bbn.com by LABS-N.BBN.COM id aa02893; 13 Feb 91 14:14 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa10037; 13 Feb 91 14:11 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 396520; 13 Feb 1991 14:08:21-0500 Date: Wed, 13 Feb 1991 14:06-0500 From: Scott McKay Subject: presentation actions - how can I live without them? To: p3@porter.asl.dialnet.symbolics.com, clim@BBN.COM In-Reply-To: <19910213122010.1.P2@porter.asl.dialnet.symbolics.com> Message-ID: <19910213190651.6.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Wed, 13 Feb 1991 07:20 EST From: Peter Paine Date: Sun, 10 Feb 91 17:44:50 EST From: Richard Shapiro >If you think you want presentation actions, you are probably wrong. [...] I am rather lost. We continue to develop a GUI substrate (called the Jin system) which provides a variety of buttons, switches, thumb wheels, dials, sliders etc. as the kernel of reusable utilities. Let's call these "gadgets"... All interaction is through the mouse. The logic of presentation actions seems to be appropriate. Indeed, the intrusion of any form of interactor dependencies is both an overhead and very unwelcome. Being a believer in staying with the common-denominator philosophies of software use and development, I am at a loss to see where I have parted company with CLIM - our great hope for the delivery of the sort of lisp applications that customers want and will buy. Any explanations would be gratefully received. Gadgets are a very special case that I should have mentioned. I failed to mention them because I believe that management of gadgets properly falls *below* the level of CLIM applications proper, and belongs in a part of CLIM the manages gadgets. Where you have "parted" with CLIM is that CLIM does not currently support gadgets adequately; this is being worked on now by people at ILA, and forms the conceptual nucleus of CLIM Release 2. In the absence of CLIM support for gadgets, it is a reasonable strategy to use presentation actions to implement the controls for gadgets. This is because the control of the gadgets need not be mediated by the command loop of the application.   Received: from bbn.com by LABS-N.BBN.COM id aa03605; 13 Feb 91 15:09 EST Received: from charon.arc.nasa.gov by BBN.COM id aa12543; 13 Feb 91 15:05 EST Received: from ROMAN-A-CLEF.arc.nasa.gov by CHARON.arc.nasa.gov via INTERNET with SMTP id 78559; 13 Feb 91 12:05:22 PST Date: Wed, 13 Feb 91 12:04 PST From: will taylor Subject: Reverse video CLIM Frames To: clim@BBN.COM Message-ID: <19910213200435.8.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov> In Symbolics CLIM 1.0, the default frames and menus come up with white backgrounds. I prefer black backgrounds, so I do Function-C on my Symbolics -- however, this does not effect CLIM. How do I effect CLIM's window substrate to produce black backgrounds for frames and menus? ==> Will Taylor   Received: from bbn.com by LABS-N.BBN.COM id aa04983; 13 Feb 91 17:09 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa20499; 13 Feb 91 17:04 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 396539; 13 Feb 1991 17:00:56-0500 Date: Wed, 13 Feb 1991 16:59-0500 From: Scott McKay Subject: Reverse video CLIM Frames To: taylor@charon.arc.nasa.gov, clim@BBN.COM In-Reply-To: <19910213200435.8.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov> Message-ID: <19910213215925.9.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Wed, 13 Feb 1991 15:04 EST From: will taylor In Symbolics CLIM 1.0, the default frames and menus come up with white backgrounds. I prefer black backgrounds, so I do Function-C on my Symbolics -- however, this does not effect CLIM. How do I effect CLIM's window substrate to produce black backgrounds for frames and menus? (rotatef (clim:medium-foreground stream) (clim:medium-background stream))   Received: from bbn.com by LABS-N.BBN.COM id aa06653; 13 Feb 91 21:13 EST Received: from charon.arc.nasa.gov by BBN.COM id aa27767; 13 Feb 91 21:10 EST Received: from ROMAN-A-CLEF.arc.nasa.gov by CHARON.arc.nasa.gov via INTERNET with SMTP id 78603; 13 Feb 91 18:11:01 PST Date: Wed, 13 Feb 91 18:10 PST From: will taylor Subject: "Roll-your-own" Pane Types To: clim@BBN.COM cc: taylor@charon.arc.nasa.gov Message-ID: <19910214021013.0.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov> Character-Type-Mappings: (1 0 (NIL 0) (:FIX :BOLD :NORMAL) "CPTFONTCB") (2 0 (NIL 0) (:FIX :ITALIC :NORMAL) "CPTFONTI") Fonts: CPTFONT, CPTFONTCB, CPTFONTI In Symbolics CLIM 1.0, I would like to create pane instances of (pcl:define-class COMMAND-PANE-CLASS (clim::sheet-window-stream) ((command-list :initform () :documentation "list of cmd-definition structures") (enabled-style :initform '(:sans-serif :bold :large) :documentation "enabled character style") (disabled-style :initform '(:sans-serif :roman :normal) :documentation "disabled character style")) (:accessor-prefix cmd-pane-) (:initargs :slot-names) (:documentation "Command pane class for enabled/disabled command fonts")) (defmethod DISPLAY-COMMAND-PANE ((frame-object application-frame) (self COMMAND-PANE-CLASS)) ...) so I define it as a pane type -- (defmethod CLIM::PANE-TYPE-OPTIONS ((type (eql 'COMMAND-PANE-CLASS))) '(:default-text-style (:sans-serif :bold :large) :incremental-redisplay nil :display-function display-command-pane :display-after-commands nil :scroll-bars nil)) then -- (define-application-frame AUTOCLASS-RESULTS-FRAME () ; No super classes ((global-pane :initform nil :accessor global-pane) (global-header-pane :initform nil :accessor global-header-pane) (banner-pane :initform nil :accessor banner-pane) (command-pane :initform nil :accessor command-pane)) (:panes ( ... (command command-pane-class))) ...) but when I try to bring this up --> 1Error: No applicable method for # with arguments 0 1(# #) 0The following specials have been rebound; use 2:Show Standard Value Warnings0 for details: *PRINT-CIRCLE* and *PACKAGE* 1CLIM::CALL-DISPLAY-FUNCTION 0 Arg 0 (CLIM::DISPLAY-FUNCTION): DISPLAY-COMMAND-PANE Arg 1 (CLIM::FRAME): # Arg 2 (CLIM::PANE): # Rest arg (CLIM::ARGS): NIL because the (CLIM::PANE) is not my type: 'COMMAND-PANE-CLASS. I want to do it this way to "attach" instance variables and methods to my pane types. Is there a different approach to doing this? ==> Will Taylor taylor@charon.arc.nasa.gov   Received: from bbn.com by LABS-N.BBN.COM id aa13160; 14 Feb 91 11:49 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa03216; 14 Feb 91 11:46 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 396588; 14 Feb 1991 11:43:33-0500 Date: Thu, 14 Feb 1991 11:41-0500 From: Scott McKay Subject: "Roll-your-own" Pane Types To: taylor@charon.arc.nasa.gov, clim@BBN.COM In-Reply-To: <19910214021013.0.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov> Message-ID: <19910214164147.2.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Character-Type-Mappings: (1 0 (NIL 0) (:FIX :BOLD :NORMAL) "CPTFONTCB") (2 0 (NIL 0) (:FIX :ITALIC :NORMAL) "CPTFONTI") Fonts: CPTFONT, CPTFONTCB, CPTFONTI Date: Wed, 13 Feb 1991 21:10 EST From: will taylor In Symbolics CLIM 1.0, I would like to create pane instances of It is preferable if we all get in the habit of callinf this "CLIM Release 1.0", just so that we are all speaking the exact same language. Also, please be specific about exactly what software you are running, such as what operating system you are using (it looks like Genera here). In order to diagnose anything, we really need complete information about all of the software, not just which version of CLIM you are running. (pcl:define-class COMMAND-PANE-CLASS (clim::sheet-window-stream) ((command-list :initform () :documentation "list of cmd-definition structures") (enabled-style :initform '(:sans-serif :bold :large) :documentation "enabled character style") (disabled-style :initform '(:sans-serif :roman :normal) :documentation "disabled character style")) (:accessor-prefix cmd-pane-) (:initargs :slot-names) (:documentation "Command pane class for enabled/disabled command fonts")) Why PCL:define-class? Why not [CLOS:]defclass? If that is really defining a PCL class, and since CLIM is written using "the real [Symbolics implementation of] CLOS", there could be some coexistance problems between CLOS and PCL. There is also a future portability problem here, namely, you are specializing CLIM::SHEET-WINDOW-STREAM, which is a Genera-only class. CLIM Release 1 has no provision for specializing window classes and having DEFINE-APPLICATION-FRAME create them. All CLIM windows in CLIM Release 1 are the same class. I believe that CLIM Release 2 addresses this sort of issue better. Is it *really* important for CLIM Release 1 support having DEFINE-APPLICATION-FRAME be able to create different classes of windows in its panes (see the end of the message for a strawman proposal)? I mean **really** important? Lacking any broader context, the example you supply does not offer a compelling reason for providing this capability, since the state you are storing in the "command pane" could just as easily be maintained in state slots in the application frame itself. I suggest that, rather than digging into undocumented parts of CLIM, such as CLIM::PANE-TYPE-OPTIONS and CLIM::SHEET-WINDOW-STREAM (which being both undocumented and unexported are consequently subject to change without any notification), that you try to stay within CLIM's documented and exported features and maintain this state in the application frame. (defmethod DISPLAY-COMMAND-PANE ((frame-object application-frame) (self COMMAND-PANE-CLASS)) ...) so I define it as a pane type -- (defmethod CLIM::PANE-TYPE-OPTIONS ((type (eql 'COMMAND-PANE-CLASS))) '(:default-text-style (:sans-serif :bold :large) :incremental-redisplay nil :display-function display-command-pane :display-after-commands nil :scroll-bars nil)) then -- (define-application-frame AUTOCLASS-RESULTS-FRAME () ; No super classes ((global-pane :initform nil :accessor global-pane) (global-header-pane :initform nil :accessor global-header-pane) (banner-pane :initform nil :accessor banner-pane) (command-pane :initform nil :accessor command-pane)) (:panes ( ... (command command-pane-class))) ...) BTW, if those slots in the application frame are meant to store pane objects, why not just use the documented CLIM:GET-FRAME-PANE? but when I try to bring this up --> 1 Error: No applicable method for # with arguments 0 1(# #) 0 The following specials have been rebound; use 2:Show Standard Value Warnings0 for details: *PRINT-CIRCLE* and *PACKAGE* 1 CLIM::CALL-DISPLAY-FUNCTION 0 Arg 0 (CLIM::DISPLAY-FUNCTION): DISPLAY-COMMAND-PANE Arg 1 (CLIM::FRAME): # Arg 2 (CLIM::PANE): # Rest arg (CLIM::ARGS): NIL because the (CLIM::PANE) is not my type: 'COMMAND-PANE-CLASS. I want to do it this way to "attach" instance variables and methods to my pane types. Is there a different approach to doing this? ---------------- Here is how you would use the strawman I have in mind. It still has the bugs of being non-portable, since you have to specialize CLIM::SHEET-WINDOW-STREAM. Also, as I said above, I think we need more compelling examples for why doing this is much more important than doing other things, since we do not have unlimited resources. (defclass command-pane-class (clim::sheet-window-stream) ((command-list ...) (enabled-style ...) (disabled-style ...)) ...) (defmethod display-command-pane ((frame application-frame) (pane command-pane-class)) ...) (defmethod clim::pane-type-options ((type (eql ':autoclass-command-pane))) '(:default-text-style (:sans-serif :bold :large) :incremental-redisplay nil :display-function display-command-pane :display-after-commands nil :scroll-bars nil -> :WINDOW-CLASS COMMAND-PANE-CLASS)) (define-application-frame autoclass-results-frame () ((global-pane :initform nil :accessor global-pane) (global-header-pane :initform nil :accessor global-header-pane) (banner-pane :initform nil :accessor banner-pane) (command-pane :initform nil :accessor command-pane)) (:panes (... (command :autoclass-command-pane) ...)) ...)   Received: from bbn.com by LABS-N.BBN.COM id aa19159; 14 Feb 91 21:49 EST Received: from charon.arc.nasa.gov by BBN.COM id aa00352; 14 Feb 91 21:46 EST Received: from ROMAN-A-CLEF.arc.nasa.gov by CHARON.arc.nasa.gov via INTERNET with SMTP id 78730; 14 Feb 91 18:09:50 PST Date: Thu, 14 Feb 91 18:09 PST From: will taylor Subject: RE: "Roll-your-own" Pane Types To: SWM@sapsucker.scrc.symbolics.com, taylor@charon.arc.nasa.gov, clim@BBN.COM In-Reply-To: <19910214164147.2.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Message-ID: <19910215020946.4.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov> Date: Thu, 14 Feb 1991 11:41-0500 From: Scott McKay Date: Wed, 13 Feb 1991 21:10 EST From: will taylor In Symbolics CLIM 1.0, I would like to create pane instances of ... (define-class COMMAND-PANE-CLASS (clim::sheet-window-stream) ((command-list :initform () :documentation "list of cmd-definition structures") (enabled-style :initform '(:sans-serif :bold :large) :documentation "enabled character style") (disabled-style :initform '(:sans-serif :roman :normal) :documentation "disabled character style")) (:accessor-prefix cmd-pane-) (:initargs :slot-names) (:documentation "Command pane class for enabled/disabled command fonts")) ... There is also a future portability problem here, namely, you are specializing CLIM::SHEET-WINDOW-STREAM, which is a Genera-only class. I would like to be able to specialize on a portable CLIM stream class, in order to specialize methods and instance slots portably. CLIM Release 1 has no provision for specializing window classes and having DEFINE-APPLICATION-FRAME create them. All CLIM windows in CLIM Release 1 are the same class. I believe that CLIM Release 2 addresses this sort of issue better. Is it *really* important for CLIM Release 1 support having DEFINE-APPLICATION-FRAME be able to create different classes of windows in its panes (see the end of the message for a strawman proposal)? I mean **really** important? The two major user interfaces which I want to port to CLIM make extensive use of methods and instance slots specialized to my application panes. Lacking any broader context, the example you supply does not offer a compelling reason for providing this capability, since the state you are storing in the "command pane" could just as easily be maintained in state slots in the application frame itself. I suggest that, rather than digging into undocumented parts of CLIM, such as CLIM::PANE-TYPE-OPTIONS and CLIM::SHEET-WINDOW-STREAM (which being both undocumented and unexported are consequently subject to change without any notification), that you try to stay within CLIM's documented and exported features and maintain this state in the application frame. I would very much like to do that. I believe that CLIM 0.9 (Franz) allowed user defined pane type classes, and I guess you are saying (above) that CLIM 2.0 will probably have this feature. In the meantime (~ 6 months) I would like to get my user interfaces converted to CLIM 1.0. To do that I apparently will have to modify my method handling from being specialized on user defined pane classes to not being specialized, e.g. from (defmethod DISPLAY-COMMAND-PANE ((frame-object application-frame) (self COMMAND-PANE-CLASS)) ...) to (defmethod DISPLAY-COMMAND-PANE ((frame-object application-frame) self) ...) And instance slots which would have been associated with COMMAND-PANE-CLASS will have to be added to the frame state variables. It seems an awkward way to do it. .... ---------------- Here is how you would use the strawman I have in mind. It still has the bugs of being non-portable, since you have to specialize CLIM::SHEET-WINDOW-STREAM. Also, as I said above, I think we need more compelling examples for why doing this is much more important than doing other things, since we do not have unlimited resources. (defclass command-pane-class (clim::sheet-window-stream) ((command-list ...) (enabled-style ...) (disabled-style ...)) ...) (defmethod display-command-pane ((frame application-frame) (pane command-pane-class)) ...) (defmethod clim::pane-type-options ((type (eql ':autoclass-command-pane))) '(:default-text-style (:sans-serif :bold :large) :incremental-redisplay nil :display-function display-command-pane :display-after-commands nil :scroll-bars nil -> :WINDOW-CLASS COMMAND-PANE-CLASS)) (define-application-frame autoclass-results-frame () ((global-pane :initform nil :accessor global-pane) (global-header-pane :initform nil :accessor global-header-pane) (banner-pane :initform nil :accessor banner-pane) (command-pane :initform nil :accessor command-pane)) (:panes (... (command :autoclass-command-pane) ...)) ...) The "strawman" proposal looks good, assuming that a portable functionality will be available in CLIM 2.0. It would allow me to eliminate awkward code mashing and retain the object-oriented functionality of my user defined panes. It would allow user extension of CLIM which would be portable, and object-orented -- which I thought was an important goal. ==> Will Taylor   Received: from BBN.COM by LABS-N.bbn.COM id aa09575; 18 Feb 91 10:18 EST Received: from unido.Informatik.Uni-Dortmund.DE by BBN.COM id aa08480; 18 Feb 91 10:14 EST Received: from itwdo by unido.informatik.uni-dortmund.de with UUCP (5.65+/UNIDO-2.0.3.e) via EUnet for bbn.com id AA26000; Mon, 18 Feb 91 15:14:43 GMT Received: by iml.fhg.de with SMTP; Mon, 18 Feb 91 15:22:56 +0100 X-Mailer-Iml-Itwdo: ## IML.FHG.DE ## Mon, 18 Feb 91 15:22:56 +0100 Date: Mon, 18 Feb 91 15:21 EET From: stefan bernemann Subject: combining clim and another motif- (X-)application To: clim@BBN.COM Message-Id: <19910218132158.1.STEFAN@ANNA> Hi, please excuse me if this question is absurd, but I've not too much insight neither into X/motif nor clim. What I would like to have is a clim application (say Appl. A) on some Unix machine, using the motif look&feel. This application controls (say start/stop/interupt) some other, which a) are NOT written in lisp (but in C / pascal), b) have already an user interface, which is based on c) X-windows (using the motif toolkit). Ideally, these applications (say B, C, ...) should show up in some window pane of a clim application frame with not too much work in reimplementing the user interface. That is, application B should be easily configurable as running standalone or part of A. Can this be done? Or am I thinking in the wrong direction? Stefan. Mail: Stefan Bernemann ! Phone: +49-231-7549233 c/o FhG IML Dortmund ! Fax: +49-231-7549211 Emil-Figge-Str. 75 ! Email: berni@iml.fhg.de D-4600 Dortmund 50, FRG ! ...!{uunet|mcavx}!unido!itwdo!berni   Received: from BBN.COM by LABS-N.bbn.COM id aa21556; 19 Feb 91 12:28 EST Received: from charon.arc.nasa.gov by BBN.COM id aa19693; 19 Feb 91 12:21 EST Received: from ROMAN-A-CLEF.arc.nasa.gov by CHARON.arc.nasa.gov via INTERNET with SMTP id 78810; 19 Feb 91 09:21:06 PST Date: Tue, 19 Feb 91 09:21 PST From: will taylor Subject: CLIM:WINDOW-INSIDE-... Functions To: clim@BBN.COM Message-ID: <19910219172104.7.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov> In Genera CLIM 1.0, apropos shows several functions: CLIM:WINDOW-INSIDE-HEIGHT - Function (WINDOW) CLIM:WINDOW-INSIDE-BOTTOM - Function (WINDOW) CLIM:WINDOW-INSIDE-EDGES - Function (WINDOW) CLIM:WINDOW-INSIDE-SIZE - Function (WINDOW) CLIM:WINDOW-INSIDE-WIDTH - Function (WINDOW) CLIM:WINDOW-INSIDE-LEFT - Function (WINDOW) CLIM:WINDOW-INSIDE-TOP - Function (WINDOW) CLIM:WINDOW-INSIDE-RIGHT - Function (WINDOW) which are exported from the CLIM package, but are not documented in "Common Lisp Interface Manager (CLIM): Early Release 1.0". For a function to be assumed portable by users, does it have to be exported AND documented, or only exported? ==> Will Taylor   From: cerys@BBN.COM Sender: cerys@BBN.COM Organization: Bolt Beranek and Newman Inc. To: clim@BBN.COM Subject: Test 1 Reply-to: clim-request@BBN.COM Date: Tue, 19 Feb 91 13:49:18 EST Source-Info: From (or Sender) name not authenticated. This is a test message. Please ignore...   Received: from BBN.COM by LABS-N.BBN.COM id aa23487; 19 Feb 91 15:03 EST Received: from serc.cis.ufl.edu by BBN.COM id aa27535; 19 Feb 91 14:58 EST Received: by serc.cis.ufl.edu (5.61ufl/4.12) id AA10648; Tue, 19 Feb 91 14:58:07 -0500 Date: Tue, 19 Feb 91 14:58:07 -0500 From: Mark Interrante Message-Id: <9102191958.AA10648@serc.cis.ufl.edu> To: clim@BBN.COM Subject: remove me from mailing list Please remove me from the CLIM mailing list Mark mfi@serc.ufl.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa06255; 20 Feb 91 11:03 EST Received: from EDDIE.MIT.EDU by BBN.COM id aa03090; 20 Feb 91 10:56 EST Received: by EDDIE.MIT.EDU with UUCP (5.65/25-eef) id AA15095; Wed, 20 Feb 91 10:56:09 -0500 Received: by mck-csc.mckinsey.com (5.51/25-eef) id AA22711; Wed, 20 Feb 91 10:54:32 EST Date: Wed, 20 Feb 91 10:54:32 EST From: Peter Gaston Message-Id: <9102201554.AA22711@mck-csc.mckinsey.com> To: clim@BBN.COM Subject: remove me from mailing list Please remove me from the CLIM mailing list Pete pete@mckinsey.com   Received: from BBN.COM by LABS-N.BBN.COM id aa09417; 20 Feb 91 14:15 EST Received: from media-lab.media.mit.edu by BBN.COM id aa12786; 20 Feb 91 14:01 EST Received: by media-lab.media.mit.edu (5.57/DA1.0.2) id AA28259; Wed, 20 Feb 91 14:01:45 EST Date: Wed, 20 Feb 91 14:01:45 EST From: Steve Strassmann Message-Id: <9102201901.AA28259@media-lab.media.mit.edu> To: mck-csc!pete%eddie.mit.edu.uucp@BBN.COM Cc: clim@BBN.COM In-Reply-To: Peter Gaston's message of Wed, 20 Feb 91 10:54:32 EST <9102201554.AA22711@mck-csc.mckinsey.com> Subject: remove me from mailing list Date: Wed, 20 Feb 91 10:54:32 EST From: Peter Gaston Please remove me from the CLIM mailing list I guess it's time once again to remind people that administrivia like this should be sent to clim-request@bbn.com, not the whole list. In general, if you want to be removed from or added to any mailing list, proper net etiquette is to try the -request line first. Thanks. - Miss Manners   Received: from BBN.COM by LABS-N.BBN.COM id aa16266; 20 Feb 91 23:15 EST Received: from CS.BU.EDU by BBN.COM id aa12633; 20 Feb 91 23:11 EST Received: from BUCSD.BU.EDU by cs.bu.edu (5.61+++/SMI-4.0.3) id AA00767; Wed, 20 Feb 91 23:08:30 -0500 Received: by bucsd.bu.edu (5.61+++/SMI-4.0.3) id AA03735; Wed, 20 Feb 91 23:09:42 -0500 Date: Wed, 20 Feb 91 23:09:42 -0500 From: gasp@cs.bu.edu Message-Id: <9102210409.AA03735@bucsd.bu.edu> To: clim@BBN.COM Subject: remove Please remove me from the mailing list. Isaac Kohane gasp@zermatt.lcs.mit.edu gasp@bu-cs.bu.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa24393; 21 Feb 91 10:39 EST Received: from RHYTHM-AND-BLUES.BBN.COM by BBN.COM id aa00493; 21 Feb 91 10:36 EST Date: Thu, 21 Feb 91 10:36 EST From: Jeff Morrill Subject: Using DEFINE-COMMAND To: clim@BBN.COM cc: jmorrill@BBN.COM Message-ID: <19910221153647.2.JMORRILL@rhythm-and-blues.bbn.com> I am using CLIM 0.9.54 to define a system that is not an application per se, but rather a toolbox that gets embedded in other applications. One of the things that the applications inherit is of course a command table. What is the "canonical" way to define commands that are not associated with any single application? I started off doing something like (define-command com-print-number ((object 'number)) (print object)) (add-command-to-command-table "Print Number" 'com-print-number 'my-comtab) But one quickly discovers that EXECUTE-COMMAND funcalls the command using the application frame as a first, hidden argument. (WHY?) It would appear that I should be using DEFINE-FRAME-COMMAND instead, which adds the hidden frame argument invisibly: (define-frame-command my-comtab com-print-number ((object 'number)) (print object)) I suppose it makes sense to have the frame as a hidden argument, since there is no special binding such as dw:*program-frame*. So should user code ever invoke DEFINE-COMMAND? Thanks, jeff morrill jmorrill@bbn.com   Received: from BBN.COM by LABS-N.BBN.COM id aa15440; 22 Feb 91 18:10 EST Received: from [192.70.132.83] by BBN.COM id aa05214; 22 Feb 91 18:06 EST Received: by isx.com (4.0/SMI-3.2) id AA06845; Fri, 22 Feb 91 15:12:40 PST Date: Fri, 22 Feb 91 15:12:40 PST From: Jim Shoop Message-Id: <9102222312.AA06845@isx.com> To: clim@BBN.COM Subject: Soliciting for CLIM info I am currently involved in selecting an interface package to use in conjuction with Common Lisp. I would appreciate any information (product literature, comments, suggestions, ...). Please respond to: Jim Shoop ISX Corporation 501 Marin Street, Suite 214 Thousand Oaks, CA 91360 (805) 495-8265 jshoop@isx.com Thanks, Jim Shoop   Received: from BBN.COM by LABS-N.BBN.COM id aa11299; 25 Feb 91 13:24 EST Received: from YUKON.SCRC.Symbolics.COM by BBN.COM id aa12618; 25 Feb 91 13:20 EST Received: from LILIKOI.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via INTERNET with SMTP id 668096; 25 Feb 1991 12:36:26-0500 Date: Mon, 25 Feb 1991 12:42-0500 From: Mark Nahabedian Subject: Soliciting for CLIM info To: jshoop@haifa, clim@BBN.COM In-Reply-To: <9102222312.AA06845@isx.com> Message-ID: <19910225174251.7.NAHA@LILIKOI.SCRC.Symbolics.COM> Symbolics will soon be releasing CLIM 1.0 for Genera 8.1. CLIM 1.0 Early Release is currently available for Genera 8.0 and for CLOE (Common Lisp for MSDOS 80386 machines) and has been shipped to a small number of customers. For information about CLIM availability on other CommonLisp platforms, contact your LISP vendor or International LISP Associates: ILA 114 Mt. Auburn St 4th Floor Cambridge, MA 02138 phone:+617-576-1151 fax:+617-576-2806 Email to Mark A. Son-Bell: MAS-B@fuji.ila.com   From: cerys@BBN.COM Sender: cerys@BBN.COM Organization: Bolt Beranek and Newman Inc. To: clim-archive@BBN.COM Subject: test Date: Tue, 26 Feb 91 13:55:11 EST Source-Info: From (or Sender) name not authenticated. This is a test of the archive Dan   Received: from BBN.COM by LABS-N.BBN.COM id aa28077; 27 Feb 91 11:25 EST Received: from milton.u.washington.edu by BBN.COM id aa07324; 27 Feb 91 11:21 EST Received: from anchor.apl.washington.edu by milton.u.washington.edu (5.61/UW-NDC Revision: 2.1 ) id AA23851; Wed, 27 Feb 91 08:20:53 -0800 Received: by apl.washington.edu (4.1/SMI-4.1) id AA06369; Wed, 27 Feb 91 08:20:04 PST Date: Wed, 27 Feb 91 08:20:04 PST From: Keith Kerr Message-Id: <9102271620.AA06369@apl.washington.edu> To: clim@BBN.COM Subject: CLIM for MCL 2.0 I heard that ILA is working on CLIM for Macintosh Common Lisp/CLOS 2.0. Is this true, and is there any expected date??   Received: from BBN.COM by LABS-N.BBN.COM id aa00686; 27 Feb 91 14:38 EST Received: from FUJI.ILA.COM by BBN.COM id aa15177; 27 Feb 91 14:33 EST Date: Wed, 27 Feb 91 14:36 EST From: "Mark A. Son-Bell" Subject: CLIM for MCL 2.0 To: keith@apl.washington.edu, clim@BBN.COM In-Reply-To: <9102271620.AA06369@apl.washington.edu> Message-ID: <19910227193620.0.MAS-B@FUJI.ILA.COM> Date: Wed, 27 Feb 91 08:20:04 PST From: Keith Kerr I heard that ILA is working on CLIM for Macintosh Common Lisp/CLOS 2.0. Is this true, and is there any expected date?? Yes, we do have an alpha version of CLIM under MCL 2.0 available for limited external evaluation. Please contact us directly at the address below for more information: ILA 114 Mt. Auburn St. 4th Floor Cambridge, MA 02138 phone: 617/576-1151 fax: 617/576-2806 e-mail: clim-ila@ila.com   Received: from BBN.COM by LABS-N.BBN.COM id aa03298; 27 Feb 91 17:06 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa22714; 27 Feb 91 17:01 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 397459; 27 Feb 1991 16:26:12-0500 Date: Wed, 27 Feb 1991 16:25-0500 From: Scott McKay Subject: RE: "Roll-your-own" Pane Types To: taylor@charon.arc.nasa.gov, SWM@sapsucker.scrc.symbolics.com, clim@BBN.COM In-Reply-To: <19910215020946.4.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov> Message-ID: <19910227212547.3.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Thu, 14 Feb 1991 21:09 EST From: will taylor Just to finish this discussion... Date: Thu, 14 Feb 1991 11:41-0500 From: Scott McKay Date: Wed, 13 Feb 1991 21:10 EST From: will taylor In Symbolics CLIM 1.0, I would like to create pane instances of ... (define-class COMMAND-PANE-CLASS (clim::sheet-window-stream) ((command-list :initform () :documentation "list of cmd-definition structures") (enabled-style :initform '(:sans-serif :bold :large) :documentation "enabled character style") (disabled-style :initform '(:sans-serif :roman :normal) :documentation "disabled character style")) (:accessor-prefix cmd-pane-) (:initargs :slot-names) (:documentation "Command pane class for enabled/disabled command fonts")) ... There is also a future portability problem here, namely, you are specializing CLIM::SHEET-WINDOW-STREAM, which is a Genera-only class. I would like to be able to specialize on a portable CLIM stream class, in order to specialize methods and instance slots portably. Right now you can't specialize stream classes *portably*, because in CLIM Release 1.0 the stream classes that have instance instantiated are, by definition, platform-specific classes, for example, SHEET-WINDOW-STREAM or CLX-WINDOW. CLIM Release 1 has no provision for specializing window classes and having DEFINE-APPLICATION-FRAME create them. All CLIM windows in CLIM Release 1 are the same class. I believe that CLIM Release 2 addresses this sort of issue better. Is it *really* important for CLIM Release 1 support having DEFINE-APPLICATION-FRAME be able to create different classes of windows in its panes (see the end of the message for a strawman proposal)? I mean **really** important? The two major user interfaces which I want to port to CLIM make extensive use of methods and instance slots specialized to my application panes. I still think it is better to keep application state in a place besides in a window class. But it's up to you. Lacking any broader context, the example you supply does not offer a compelling reason for providing this capability, since the state you are storing in the "command pane" could just as easily be maintained in state slots in the application frame itself. I suggest that, rather than digging into undocumented parts of CLIM, such as CLIM::PANE-TYPE-OPTIONS and CLIM::SHEET-WINDOW-STREAM (which being both undocumented and unexported are consequently subject to change without any notification), that you try to stay within CLIM's documented and exported features and maintain this state in the application frame. I would very much like to do that. I believe that CLIM 0.9 (Franz) allowed user defined pane type classes, and I guess you are saying (above) that CLIM 2.0 will probably have this feature. In the meantime (~ 6 months) I would like to get my user interfaces converted to CLIM 1.0. To do that I apparently will have to modify my method handling from being specialized on user defined pane classes to not being specialized, e.g. from (defmethod DISPLAY-COMMAND-PANE ((frame-object application-frame) (self COMMAND-PANE-CLASS)) ...) to (defmethod DISPLAY-COMMAND-PANE ((frame-object application-frame) self) ...) And instance slots which would have been associated with COMMAND-PANE-CLASS will have to be added to the frame state variables. It seems an awkward way to do it. I've added :WINDOW-CLASS as one of the pane options to DEFINE-APPLICATION-FRAME, so people can do with it what they will. This may make it to the field before as a patch to the early release of CLIM 1.0, but then again it may not. .... ---------------- Here is how you would use the strawman I have in mind. It still has the bugs of being non-portable, since you have to specialize CLIM::SHEET-WINDOW-STREAM. Also, as I said above, I think we need more compelling examples for why doing this is much more important than doing other things, since we do not have unlimited resources. (defclass command-pane-class (clim::sheet-window-stream) ((command-list ...) (enabled-style ...) (disabled-style ...)) ...) (defmethod display-command-pane ((frame application-frame) (pane command-pane-class)) ...) (defmethod clim::pane-type-options ((type (eql ':autoclass-command-pane))) '(:default-text-style (:sans-serif :bold :large) :incremental-redisplay nil :display-function display-command-pane :display-after-commands nil :scroll-bars nil -> :WINDOW-CLASS COMMAND-PANE-CLASS)) (define-application-frame autoclass-results-frame () ((global-pane :initform nil :accessor global-pane) (global-header-pane :initform nil :accessor global-header-pane) (banner-pane :initform nil :accessor banner-pane) (command-pane :initform nil :accessor command-pane)) (:panes (... (command :autoclass-command-pane) ...)) ...) The "strawman" proposal looks good, assuming that a portable functionality will be available in CLIM 2.0. It would allow me to eliminate awkward code mashing and retain the object-oriented functionality of my user defined panes. It would allow user extension of CLIM which would be portable, and object-orented -- which I thought was an important goal. Implementing this strawman is utterly trivial, so I did it. I don't much like it, but you seem to think it will be useful.   From: cerys@BBN.COM Sender: cerys@BBN.COM Reply-To: CLIM-Request@BBN.COM Organization: Bolt Beranek and Newman Inc. To: clim@BBN.COM Subject: CLIM Mailing List archive available (finally) Date: Thu, 28 Feb 91 8:09:48 EST Source-Info: From (or Sender) name not authenticated. An archive file containing all past messages to the CLIM mailing list is now available via anonymous FTP on labs-n.bbn.com (address = 128.89.0.100). For folks who FTP with the username of 'anonymous', the file is clim-archive at the top-level directory. Someday, clim-archive will contain only the last few months of messages, and there will be some appropriately named files containing older stuff (e.g., clim-archive-910228). (Do an 'ls' to find out). Dan   Received: from BBN.COM by LABS-N.BBN.COM id aa01758; 1 Mar 91 15:52 EST Received: from YUKON.SCRC.Symbolics.COM by BBN.COM id aa15403; 1 Mar 91 15:43 EST Received: from LILIKOI.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via INTERNET with SMTP id 669881; 1 Mar 1991 15:39:14-0500 Date: Fri, 1 Mar 1991 15:47-0500 From: Mark Nahabedian Subject: CLIM:WINDOW-INSIDE-... Functions To: taylor@charon.arc.nasa.gov, clim@BBN.COM In-Reply-To: <19910219172104.7.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov> Message-ID: <19910301204757.4.NAHA@LILIKOI.SCRC.Symbolics.COM> Date: Tue, 19 Feb 1991 12:21 EST From: will taylor In Genera CLIM 1.0, apropos shows several functions: CLIM:WINDOW-INSIDE-HEIGHT - Function (WINDOW) CLIM:WINDOW-INSIDE-BOTTOM - Function (WINDOW) CLIM:WINDOW-INSIDE-EDGES - Function (WINDOW) CLIM:WINDOW-INSIDE-SIZE - Function (WINDOW) CLIM:WINDOW-INSIDE-WIDTH - Function (WINDOW) CLIM:WINDOW-INSIDE-LEFT - Function (WINDOW) CLIM:WINDOW-INSIDE-TOP - Function (WINDOW) CLIM:WINDOW-INSIDE-RIGHT - Function (WINDOW) which are exported from the CLIM package, but are not documented in "Common Lisp Interface Manager (CLIM): Early Release 1.0". For a function to be assumed portable by users, does it have to be exported AND documented, or only exported? ==> Will Taylor To be considered portable, the symbol must be exported and documented. Admittedly, the documentation has lagged behind the implementation. All documented symbols should be exported. It may not be the case that all exported symbols are documented. Occasionally, the documentation might indicate that a feature is Genera or CLOE specific, or is subject to change. Sorry for the delay.   Received: from BBN.COM by LABS-N.BBN.COM id aa03345; 1 Mar 91 18:25 EST Received: from charon.arc.nasa.gov by BBN.COM id aa25277; 1 Mar 91 18:20 EST Received: from ROMAN-A-CLEF.arc.nasa.gov by CHARON.arc.nasa.gov via INTERNET with SMTP id 79508; 1 Mar 91 15:19:49 PST Date: Fri, 1 Mar 91 15:19 PST From: will taylor Subject: [CLIM:WINDOW-INSIDE-... Functions] To: clim@BBN.COM Message-ID: <19910301231958.7.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov> Date: Tue, 26 Feb 1991 12:48-0500 From: Scott McKay Subject: [CLIM:WINDOW-INSIDE-... Functions] To: taylor@CHARON.arc.nasa.gov, SWM@SAPSUCKER.SCRC.Symbolics.COM In-Reply-To: <19910226173834.2.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov>, <19910215175521.5.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov>, The message of 15 Feb 1991 12:55 EST from taylor@CHARON.arc.nasa.gov, The message of 15 Feb 1991 12:55 EST from will taylor Message-ID: <19910226174856.4.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Tue, 26 Feb 1991 12:38 EST From: will taylor Date: Fri, 15 Feb 91 09:55 PST From: will taylor Subject: CLIM:WINDOW-INSIDE-... Functions To: clim@bbm.com cc: taylor@CHARON.arc.nasa.gov In Genera CLIM 1.0, apropos show several functions: CLIM:WINDOW-INSIDE-HEIGHT - Function (WINDOW) CLIM:WINDOW-INSIDE-BOTTOM - Function (WINDOW) CLIM:WINDOW-INSIDE-EDGES - Function (WINDOW) CLIM:WINDOW-INSIDE-SIZE - Function (WINDOW) CLIM:WINDOW-INSIDE-WIDTH - Function (WINDOW) CLIM:WINDOW-INSIDE-LEFT - Function (WINDOW) CLIM:WINDOW-INSIDE-TOP - Function (WINDOW) CLIM:WINDOW-INSIDE-RIGHT - Function (WINDOW) which are exported from the CLIM package, but are not documented in "Common Lisp Interface Manager (CLIM): Early Release 1.0". For a function to be assumed portable by users, does it have to be exported AND documented, or only exported? ==> Will Taylor This was sent to the CLIM newgroup, but no answer was forthcoming at the time. Can you give me an answer? I guess nobody forwarded my answer. The answer supplied did not answer the small question -- Scott McKay answered it in this response to me. The answer to the small question, "can I used WINDOW-INSIDE-xxx?", is "yes, you can, and they will be documented in CLIM Release 1.0". Then answer to the more general question is that you should really only use things that are both exported and documented. Some of the things in the export list are still subject to change.   Received: from BBN.COM by LABS-N.BBN.COM id aa04038; 1 Mar 91 19:50 EST Received: from Muir.AI.SRI.COM by BBN.COM id aa28227; 1 Mar 91 19:47 EST Received: from Sunset.AI.SRI.COM by muir.ai.sri.com (4.1/4.16) id AA10411 for clim@BBN.COM; Fri, 1 Mar 91 16:48:13 PST Received: from ELCAPITAN.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/4.16) id AA14415 for clim@BBN.COM; Fri, 1 Mar 91 16:48:12 PST Date: Fri, 1 Mar 91 16:50 PST From: Mabry Tyson Subject: Re: [CLIM:WINDOW-INSIDE-... Functions] To: clim@BBN.COM In-Reply-To: <19910301231958.7.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov> Message-Id: <19910302005036.9.TYSON@ELCAPITAN.AI.SRI.COM> With all the included mail it wasn't clear who exactly said: Then answer to the more general question is that you should really only use things that are both exported and documented. Some of the things in the export list are still subject to change. I would like to point out that that CLIM is still evolving and if we users need capabilities/functions that the designers of CLIM haven't anticipated, we (the users) should let them now. If we can make a case for it and the designers decide the need is generic then maybe it will be adapted and then become portable. My strategy is to do what I need to do and then try to make it as portable as possible. After all, I could make my code portable if I assumed only TTY-style I/O.   Received: from BBN.COM by LABS-N.BBN.COM id aa23327; 4 Mar 91 20:25 EST Received: from alpha.Xerox.COM by BBN.COM id aa05280; 4 Mar 91 20:19 EST Received: from layla.parc.xerox.com ([13.1.100.217]) by alpha.xerox.com with SMTP id <16304>; Mon, 4 Mar 1991 17:19:16 PST Received: by layla.parc.xerox.com id <13899>; Mon, 4 Mar 1991 17:08:07 -0800 From: Ramana Rao To: clim@BBN.COM Subject: Lisp Pointers Article on CLIM. Message-Id: <91Mar4.170807pst.13899@layla.parc.xerox.com> Date: Mon, 4 Mar 1991 17:07:53 PST A number of people have been asking for tutuorial material on CLIM. Bill York, Dennis Doughty, and I wrote an article which has just appeared in the first 1991 issue of Lisp Pointers. I have put a Unix-compressed postscript file on arisia in the pub directory under the name clim-lisp-pointers.ps.Z. You can retrieve it using anonymous ftp to arisia.parc.com. Enjoy, Ramana Rao (Internet: rao@parc.xerox.com) Xerox Palo Alto Research Center (PARC) 3333 Coyote Hill Road; Palo Alto, CA, USA 94304 TEL: 415-494-4716; FAX: 415-494-4334   Received: from IZAR.BBN.COM by LABS-N.BBN.COM id aa23838; 4 Mar 91 21:30 EST Received: by IZAR.BBN.COM id aa13987; 4 Mar 91 21:18 EST To: Ramana Rao cc: clim@BBN.COM Subject: Re: Lisp Pointers Article on CLIM. In-reply-to: Your message of Mon, 04 Mar 91 17:07:53 -0800. <91Mar4.170807pst.13899@layla.parc.xerox.com> Date: Mon, 04 Mar 91 21:05:02 -0500 From: kanderso@BBN.COM From: Ramana Rao To: clim@BBN.COM Subject: Lisp Pointers Article on CLIM. Date: Mon, 4 Mar 1991 17:07:53 PST A number of people have been asking for tutuorial material on CLIM. Bill York, Dennis Doughty, and I wrote an article which has just appeared in the first 1991 issue of Lisp Pointers. I have put a Unix-compressed postscript file on arisia in the pub directory under the name clim-lisp-pointers.ps.Z. You can retrieve it using anonymous ftp to arisia.parc.com. Enjoy, Ramana Rao (Internet: rao@parc.xerox.com) Xerox Palo Alto Research Center (PARC) 3333 Coyote Hill Road; Palo Alto, CA, USA 94304 TEL: 415-494-4716; FAX: 415-494-4334 We realy enjoyed this article, but some of us wonder which examples work in which CLIM's. k   Received: from BBN.COM by LABS-N.BBN.COM id aa08471; 5 Mar 91 19:09 EST Received: from alpha.Xerox.COM by BBN.COM id aa01004; 5 Mar 91 18:52 EST Received: from layla.parc.xerox.com ([13.1.100.217]) by alpha.xerox.com with SMTP id <16521>; Tue, 5 Mar 1991 15:50:38 PST Received: by layla.parc.xerox.com id <13898>; Tue, 5 Mar 1991 15:49:16 -0800 Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.layla.parc.xerox.com.sun4.40 via MS.5.6.layla.parc.xerox.com.sun4_40; Tue, 5 Mar 1991 15:49:15 -0800 (PST) Message-ID: Date: Tue, 5 Mar 1991 15:49:15 PST Sender: Ramana Rao From: Ramana Rao To: Ramana Rao , kanderso@BBN.COM Subject: Re: Lisp Pointers Article on CLIM. CC: clim@BBN.COM In-Reply-To: <91Mar4.191911pst.16294@alpha.xerox.com> References: <91Mar4.191911pst.16294@alpha.xerox.com> When we sat down to write these articles, we wrote these code examples in a development version of CLIM that closely resembles 0.9. We then translated the code to a virtual version of CLIM (our best guess at what now is being call 2.0 might look like). This code should be viewed as indicative of the functionality that at least three of us CLIM designers believe will be in CLIM in the long run (and is in some form in the 0.9 version). Feedback on the code at any level has a good chance of influencing what will be supported in 2.0. Please send comments to bug-clim@ila.com. I have a feeling that a lot of issues will be a lot easier to resolve at this stage because of the experiences of current CLIM users. Regards, Ramana   Received: from BBN.COM by LABS-N.BBN.COM id aa17824; 6 Mar 91 11:59 EST Received: from CRDGW1.GE.COM by BBN.COM id aa26082; 6 Mar 91 11:46 EST Received: by crdgw1.ge.com (5.57/GE 1.89) id AA15884; Wed, 6 Mar 91 11:45:05 EST Received: from caesar.crd.Ge.Com by alydar.crd.Ge.Com (4.1/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA16507; Wed, 6 Mar 91 11:46:13 EST Date: Wed, 6 Mar 91 11:46:13 EST From: Don Hamilton Message-Id: <9103061646.AA16507@alydar.crd.Ge.Com> Received: by caesar.crd.Ge.Com (4.1/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA04468; Wed, 6 Mar 91 11:46:10 EST To: clim@BBN.COM Subject: layout panes Does anybody have any detailed documentation describing the functionality of the layout pane macros outlined under section 9.10.3 of the CLIM Version I Release 0.9 Reference manual (dated September 27, 1990) from ILA. I am interested in what they are supposed to do, and options which are applicable to them. thanks, don hamilton   Received: from BBN.COM by LABS-N.BBN.COM id aa04403; 7 Mar 91 14:14 EST Received: from trantor.harris-atd.com by BBN.COM id aa27644; 7 Mar 91 14:09 EST Received: from altair.harris-atd.com by trantor.harris-atd.com (5.64+/1.14) id AA24821; Thu, 7 Mar 91 13:50:54 -0500 Message-Id: <9103071850.AA24821@trantor.harris-atd.com> Received: by altair.harris-atd.com (4.0/SMI-4.0) id AA27220; Thu, 7 Mar 91 13:50:44 EST To: clim@BBN.COM Subject: Re: Lisp Pointers Article on CLIM. Date: Thu, 07 Mar 91 13:50:38 -0500 From: mac@trantor.harris-atd.com From: Ramana Rao To: clim@BBN.COM Subject: Lisp Pointers Article on CLIM. Message-Id: <91Mar4.170807pst.13899@layla.parc.xerox.com> Date: Mon, 4 Mar 1991 17:07:53 PST A number of people have been asking for tutuorial material on CLIM. Bill York, Dennis Doughty, and I wrote an article which has just appeared in the first 1991 issue of Lisp Pointers. I have put a Unix-compressed postscript file on arisia in the pub directory under the name clim-lisp-pointers.ps.Z. You can retrieve it using anonymous ftp to arisia.parc.com. Enjoy, Ramana Rao (Internet: rao@parc.xerox.com) Xerox Palo Alto Research Center (PARC) 3333 Coyote Hill Road; Palo Alto, CA, USA 94304 TEL: 415-494-4716; FAX: 415-494-4334 Just how does one go about getting Lisp Pointers these days? Last time I knew was a couple of years ago when you were suppose to contact Mary VanDeusen (maida@ibm.com). All info would be appreciated. Mike McDonald mac@trantor.harris-atd.com (407) 727-5060 Advanced Technology Dept. Harris Corp. M.S. 3A-1912 P.O. Box 37 Melbourne, Florida 32902   Received: from BBN.COM by LABS-N.BBN.COM id aa06025; 7 Mar 91 16:21 EST Received: from LUCID.COM by BBN.COM id aa04872; 7 Mar 91 16:13 EST Received: from kolyma (kolyma.lucid.com) by heavens-gate.lucid.com id AA22060g; Thu, 7 Mar 91 13:11:07 PST Received: by kolyma id AA05922g; Thu, 7 Mar 91 13:14:06 PST Date: Thu, 7 Mar 91 13:14:06 PST From: Jon L White Message-Id: <9103072114.AA05922@kolyma> To: mac@trantor.harris-atd.com Cc: clim@BBN.COM In-Reply-To: mac@trantor.harris-atd.com's message of Thu, 07 Mar 91 13:50:38 -0500 <9103071850.AA24821@trantor.harris-atd.com> Subject: Lisp Pointers Article on CLIM. re: Just how does one go about getting Lisp Pointers these days? Last time I knew was a couple of years ago when you were suppose to contact Mary VanDeusen (maida@ibm.com). All info would be appreciated. Lisp Pointers is a now regular SIGPLAN publication now; I would suggest joining ACM -- if you aren't already a member -- and electing the SIGPLAN and LISP Pointers options. The ACM telephone number in New York City is 1-212-869-7440; at the time you join, they may send you the back issues of LP for this year (which should include the present one with the CLIM article in it). -- JonL --   Received: from BBN.COM by LABS-N.BBN.COM id aa16647; 8 Mar 91 11:49 EST Received: from FUJI.ILA.COM by BBN.COM id aa00486; 8 Mar 91 11:33 EST Received: from DIAMOND-HEAD.ILA.COM by FUJI.ILA.COM via CHAOS with CHAOS-MAIL id 235884; Fri 8-Mar-91 11:36:27 EST Date: Fri, 8 Mar 91 11:36 EST From: "David C. P. Linden" Subject: Using DEFINE-COMMAND To: Jeff Morrill , clim@BBN.COM In-Reply-To: <19910221153647.2.JMORRILL@rhythm-and-blues.bbn.com>, <19910307020440.0.MAS-B@FUJI.ILA.COM> Message-ID: <19910308163625.5.DCPL@DIAMOND-HEAD.ILA.COM> Date: Thu, 21 Feb 91 10:36 EST From: Jeff Morrill I am using CLIM 0.9.54 to define a system that is not an application per se, but rather a toolbox that gets embedded in other applications. One of the things that the applications inherit is of course a command table. What is the "canonical" way to define commands that are not associated with any single application? I started off doing something like (define-command com-print-number ((object 'number)) (print object)) (add-command-to-command-table "Print Number" 'com-print-number 'my-comtab) But one quickly discovers that EXECUTE-COMMAND funcalls the command using the application frame as a first, hidden argument. (WHY?) It would appear that I should be using DEFINE-FRAME-COMMAND instead, which adds the hidden frame argument invisibly: (define-frame-command my-comtab com-print-number ((object 'number)) (print object)) I suppose it makes sense to have the frame as a hidden argument, since there is no special binding such as dw:*program-frame*. So should user code ever invoke DEFINE-COMMAND? In 0.9, there are three things that D-F-C does over D-C: -- D-F-C can provide automatic ways of adding the command to the frame's command table. -- D-F-C gives the code access to the frame associated with this invocation of the command, whereas D-C should not assume anything about particular frames. -- D-F-C allows the same command to exist on several frames, e.g., COM-EXIT, and to write :before/:after/:around methods for the command. The first is a convenience. It is the interaction of the last two that is troubling you. The third is accomplished by defining the command as a method on the frame type, so the frame type is a CLOS specializer and thus must be present. That makes the second easy: since the frame is an argument the forms WITH-FRAME and WITH-FRAME-SLOTS simply reference that argument. That's the way it exists today. It is worth reviewing which of those semantic differences between D-F-C and D-C are desirable. Since the first is a convenience, it shouldn't have any implementation impact. There are other ways of accomplishing the second, e.g., with a concept similar to dw:*program-frame*. I don't know if the third has actually been exploited, and this is where customer feedback would help. If it was a "We can do this, let's try it" and nobody uses it, it might be flushable and we can then let users intermix usages of D-F-C and D-C. Until now, I didn't realize the third semantic difference existed, and for me the bookkeeping overhead to make sure I wasn't making mistakes would prevent me from trying to. Unfortunately, this may not be patchable into a world that has already done DEFINE-FRAME-COMMAND (and DEFINE-/frame-type/-COMMAND) without finding and redoing all those DEFINE-FRAME-COMMANDs. I.e., the changes would be compatable at the user source level, but not the user binary level. I'll make a note of this for consideration for CLIM 2.0 in the event it isn't reorganized for 0.9. (I don't know what 1.0 does.)   Received: from ALEXANDER.BBN.COM by LABS-N.BBN.COM id aa17985; 8 Mar 91 13:38 EST Received: from UNDERDOG.BBN.COM by ALEXANDER.BBN.COM id aa26709; 8 Mar 91 13:27 EST Received: from rhythm-and-blues.bbn.com by underdog.bbn.com id AA27508g; Fri, 8 Mar 91 13:28:50 EST Date: Fri, 8 Mar 91 13:26 EST From: Jeff Morrill Subject: Re: Using DEFINE-COMMAND To: dcpl@ila.com, clim@BBN.COM Message-Id: <19910308182656.3.JMORRILL@rhythm-and-blues.bbn.com> Date: Fri, 8 Mar 91 11:36 EST From: "David C. P. Linden" In 0.9, there are three things that D-F-C does over D-C: -- D-F-C can provide automatic ways of adding the command to the frame's command table. -- D-F-C gives the code access to the frame associated with this invocation of the command, whereas D-C should not assume anything about particular frames. -- D-F-C allows the same command to exist on several frames, e.g., COM-EXIT, and to write :before/:after/:around methods for the command. For the short term, I have defined my own DEFINE-COMMAND macro that offers for me a satisfying solution to these issues. Consider these random proposals: 1. Define-command should accept a command table as a keyword option, adding it to the table if provided but not caring too much either way. This is much more convenient than having to do it in a separate top level form every time. 2. Specializing commands on the application frame makes quite a bit of sense, particularly for the case of a toolbox that gets inherited by several applications at once. In that case, the ability to define :before/:after/:around methods could become a big advantage. I admit that I haven't yet taken advantage of this feature, but I think I'd be inclined if it seemed to be a stable feature of CLIM. 3. It doesn't make much sense, however, to have D-F-C define a method and D-C define a function. Define-command should accept a frame class as a keywork option, and it should define a method specialized on that class. The default frame class should be T. In other words, I like how define-frame-command exists today, but I want define-command to do those things as well. I hope you will consider redefining the responsibilities of define-command for 2.0. Thanks, jeff morrill   Received: from BBN.COM by LABS-N.BBN.COM id aa21025; 8 Mar 91 14:45 EST Received: from apple.com by BBN.COM id aa08365; 8 Mar 91 14:34 EST Received: from [90.1.0.10] by apple.com with SMTP (5.61/25-eef) id AA15602; Fri, 8 Mar 91 11:33:56 -0800 for clim@BBN.COM Received: from cambridge.apple.com (ministry.cambridge.apple.com) by goofy.apple.com with SMTP (5.61/25-eef) id AA29117; Fri, 8 Mar 91 11:33:49 -0800 for jmorrill@BBN.COM Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef) id AA24860; Fri, 8 Mar 91 14:20:42 -0500 Message-Id: <9103081920.AA24860@cambridge.apple.com> Date: Fri, 08 Mar 91 14:33:26 From: "David A. Moon" To: Jeff Morrill Subject: Re: Using DEFINE-COMMAND Cc: dcpl@ila.com, clim@BBN.COM I think you'll find the 1.0 version does what you want.   Received: from BBN.COM by LABS-N.BBN.COM id aa22934; 8 Mar 91 16:33 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa14008; 8 Mar 91 16:24 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 398289; 8 Mar 1991 16:21:36-0500 Date: Fri, 8 Mar 1991 16:23-0500 From: Scott McKay Subject: Re: Using DEFINE-COMMAND To: jmorrill@BBN.COM, DCPL@fuji.ila.com, clim@BBN.COM In-Reply-To: <19910308182656.3.JMORRILL@rhythm-and-blues.bbn.com>, The message of 8 Mar 1991 13:26 EST from Jeff Morrill Message-ID: <19910308212333.4.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Fri, 8 Mar 1991 13:26 EST From: Jeff Morrill Date: Fri, 8 Mar 91 11:36 EST From: "David C. P. Linden" In 0.9, there are three things that D-F-C does over D-C: -- D-F-C can provide automatic ways of adding the command to the frame's command table. -- D-F-C gives the code access to the frame associated with this invocation of the command, whereas D-C should not assume anything about particular frames. -- D-F-C allows the same command to exist on several frames, e.g., COM-EXIT, and to write :before/:after/:around methods for the command. For the short term, I have defined my own DEFINE-COMMAND macro that offers for me a satisfying solution to these issues. Consider these random proposals: 1. Define-command should accept a command table as a keyword option, adding it to the table if provided but not caring too much either way. This is much more convenient than having to do it in a separate top level form every time. CLIM Release 1.0 does this. 2. Specializing commands on the application frame makes quite a bit of sense, particularly for the case of a toolbox that gets inherited by several applications at once. In that case, the ability to define :before/:after/:around methods could become a big advantage. I admit that I haven't yet taken advantage of this feature, but I think I'd be inclined if it seemed to be a stable feature of CLIM. 3. It doesn't make much sense, however, to have D-F-C define a method and D-C define a function. Define-command should accept a frame class as a keywork option, and it should define a method specialized on that class. The default frame class should be T. CLIM Release 1.0 made the simpler decision: commands are implemented as vanilla functions. It may be that the simpler decision is the wrong one, and that in CLIM Release 2.0 commands should be generic functions whose first argument specializes on the frame. However, I think that it should be clearly demonstrated that being able to specialize commands is really needed, and is not just a "neat feature". If you were to look at all of the applications written using Dynamic Windows, I think that you would find only a few places where being able to specialize commands by adding :before/:after/:around methods turns out to be useful, and that the ability to import commands covers almost all of the common cases. (I just surveyed all of the applications in my world, and could find only one command that would conceivably benefit, and that was the various "exit" commands. However, they are typically so short that it doesn't really matter.) In other words, I like how define-frame-command exists today, but I want define-command to do those things as well. I hope you will consider redefining the responsibilities of define-command for 2.0.   Received: from BBN.COM by LABS-N.BBN.COM id aa23393; 8 Mar 91 17:06 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa15845; 8 Mar 91 16:58 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 398286; 8 Mar 1991 15:55:38-0500 Date: Fri, 8 Mar 1991 15:57-0500 From: Scott McKay Subject: Using DEFINE-COMMAND To: DCPL@fuji.ila.com, clim@BBN.COM In-Reply-To: <19910308163625.5.DCPL@DIAMOND-HEAD.ILA.COM>, The message of 8 Mar 1991 11:36 EST from David C. P. Linden Message-ID: <19910308205741.3.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Fri, 8 Mar 1991 11:36 EST From: David C. P. Linden Date: Thu, 21 Feb 91 10:36 EST From: Jeff Morrill I am using CLIM 0.9.54 to define a system that is not an application per se, but rather a toolbox that gets embedded in other applications. One of the things that the applications inherit is of course a command table. What is the "canonical" way to define commands that are not associated with any single application? I started off doing something like (define-command com-print-number ((object 'number)) (print object)) (add-command-to-command-table "Print Number" 'com-print-number 'my-comtab) But one quickly discovers that EXECUTE-COMMAND funcalls the command using the application frame as a first, hidden argument. (WHY?) It would appear that I should be using DEFINE-FRAME-COMMAND instead, which adds the hidden frame argument invisibly: (define-frame-command my-comtab com-print-number ((object 'number)) (print object)) I suppose it makes sense to have the frame as a hidden argument, since there is no special binding such as dw:*program-frame*. So should user code ever invoke DEFINE-COMMAND? In 0.9, there are three things that D-F-C does over D-C: -- D-F-C can provide automatic ways of adding the command to the frame's command table. -- D-F-C gives the code access to the frame associated with this invocation of the command, whereas D-C should not assume anything about particular frames. -- D-F-C allows the same command to exist on several frames, e.g., COM-EXIT, and to write :before/:after/:around methods for the command. The first is a convenience. It is the interaction of the last two that is troubling you. The third is accomplished by defining the command as a method on the frame type, so the frame type is a CLOS specializer and thus must be present. That makes the second easy: since the frame is an argument the forms WITH-FRAME and WITH-FRAME-SLOTS simply reference that argument. That's the way it exists today. It is worth reviewing which of those semantic differences between D-F-C and D-C are desirable. Since the first is a convenience, it shouldn't have any implementation impact. There are other ways of accomplishing the second, e.g., with a concept similar to dw:*program-frame*. I don't know if the third has actually been exploited, and this is where customer feedback would help. If it was a "We can do this, let's try it" and nobody uses it, it might be flushable and we can then let users intermix usages of D-F-C and D-C. Until now, I didn't realize the third semantic difference existed, and for me the bookkeeping overhead to make sure I wasn't making mistakes would prevent me from trying to. Unfortunately, this may not be patchable into a world that has already done DEFINE-FRAME-COMMAND (and DEFINE-/frame-type/-COMMAND) without finding and redoing all those DEFINE-FRAME-COMMANDs. I.e., the changes would be compatable at the user source level, but not the user binary level. I'll make a note of this for consideration for CLIM 2.0 in the event it isn't reorganized for 0.9. (I don't know what 1.0 does.) In CLIM Release 1.0, Moon and I (with Dennis reviewing) decided that having some commands that take a "hidden" frame argument while having others that did not was just a source for bugs and confusion. Therefore, in CLIM Release 1.0, commands do not take a hidden frame argument, and are implemented as ordinary functions. DEFINE-COMMAND takes a :COMMAND-TABLE option to allow you to insert a command into a command table. DEFINE-frame-name-COMMAND just supplies :COMMAND-TABLE frame-name for you; it is merely a convenience macro, and otherwise has exactly the same semantics as DEFINE-COMMAND. Furthermore, at all times, the variable *APPLICATION-FRAME* is guaranteed to be bound to the frame you are currently in. An around method on RUN-FRAME-TOP-LEVEL does this for you. As you can deduce, we decided to give up on specializing frame commands, but importing commands wholesale from one command table to another is very easily done. Moon and I both agreed that that would be adequate for most things.   Received: from BBN.COM by LABS-N.BBN.COM id aa01962; 9 Mar 91 17:19 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa08760; 9 Mar 91 17:16 EST Received: from SAMSON.CADR.AMIS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 561020; 9 Mar 1991 16:51:20-0500 Date: Sat, 9 Mar 91 13:52 PST From: "K. Mark Alexander" Subject: ACCEPTing input from the keyboard in CLIM 0.9 (Lucid). To: clim@samson.cadr.amis.com cc: kma@samson.cadr.amis.com Message-ID: <19910309215259.1.KMA@SAMSON.cadr.amis.com> I just got the beta version of CLIM (0.9) for our sun sparcstation2. I was dissapointed to find that (accept 'string :stream ) doesn't work. It prints the prompt to the application pane but when I start typeing I see the letters that I'm typeing appear in my main lisp window. It's like *query-io* or *standard-input* got bound to the incorrect stream somehow. I've noticed the same behavior while playing with the address-book demo. Any suggestions? Thanks, --Mark Alexander Gould AMI CAD Research Center (209)586-7422 kma@samson.cadr.amis.com   Received: from BBN.COM by LABS-N.BBN.COM id aa13899; 11 Mar 91 12:59 EST Received: from [128.81.41.21] by BBN.COM id aa22982; 11 Mar 91 12:52 EST Received: from SAMSON.CADR.AMIS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 561339; 11 Mar 1991 12:48:25-0500 Date: Mon, 11 Mar 91 09:31 PST From: "K. Mark Alexander" Subject: Converging on CLIM To: clim@samson.cadr.amis.com Message-ID: <19910311173156.8.KMA@SAMSON.cadr.amis.com> Does anyone have any inkling as to when the Symbolics version of CLIM and the ILA version of CLIM (more specifically, Lucid) will look and act enough like the same animal to deserve the name "*COMMON* Lisp Interface Manager"? Thanks, --Mark Alexander   Received: from BBN.COM by LABS-N.BBN.COM id aa17916; 11 Mar 91 18:09 EST Received: from charon.arc.nasa.gov by BBN.COM id aa08284; 11 Mar 91 18:05 EST Received: from ROMAN-A-CLEF.arc.nasa.gov by CHARON.arc.nasa.gov via INTERNET with SMTP id 80058; 11 Mar 91 15:04:03 PST Date: Mon, 11 Mar 91 15:03 PST From: will taylor Subject: CLIM command output To: clim@BBN.COM cc: taylor@charon.arc.nasa.gov Message-ID: <19910311230352.5.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov> In Genera CLIM early release 1.0, I would like to discard the output which is sent to the :interactor pane when I execute a command -- is there a portable way of doing this? Example code follows: => Will Taylor ------------------------------------------------------------- ;;; -*- Mode: LISP; Syntax: Common-lisp; Package: CLIM-DEMO; Base: 10 -*- (define-application-frame erase-bug () () (:panes ((title :title :display-string "erase-bug") (design-area-1 :application :incremental-redisplay t :display-after-commands t) (design-area-2 :application) (input :interactor) (documentation :pointer-documentation))) (:layout ((main (:column :rest (title :compute) (design-area-1 :rest) (input 1/4) (documentation :compute))) (other (:column :rest (title :compute) (design-area-2 :rest) (input 1/4) (documentation :compute))))) (:top-level (default-frame-top-level))) (define-genera-application erase-bug :pretty-name "erase-bug-bug" :select-key #\y :width 200 :height 200) (define-erase-bug-command (com-clear :name t) () (window-clear (get-frame-pane *application-frame* 'design-area-1))) (define-erase-bug-command (com-add-circle :name nil) ((window t) (x 'number) (y 'number)) (draw-circle* window x y 20)) (define-presentation-to-command-translator ADD-CIRCLE-HERE (clim:blank-area com-add-circle erase-bug :pointer-documentation "Add a circle here") (window x y) `(,window ,x ,y)) -------------------------------------------------------------------   Received: from BBN.COM by LABS-N.BBN.COM id aa29829; 12 Mar 91 14:51 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa15276; 12 Mar 91 14:43 EST Received: from SAMSON.CADR.AMIS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 561887; 12 Mar 1991 14:42:23-0500 Received: from RIVERSIDE.SCRC.SYMBOLICS.COM by SAMSON.cadr.amis.com via DIAL with SMTP id 9335; 12 Mar 91 11:41:12 PST Received: from FUJI.ILA.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 561885; 12 Mar 1991 14:41:17-0500 Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 236284; 12 Mar 91 14:26:05 EST Received: from TEX-AVERY.west.dialnet.ila.com by Chuck-Jones.West.Dialnet.ILA.COM via CHAOS with CHAOS-MAIL id 50303; Tue 12-Mar-91 10:39:00 PST Date: Tue, 12 Mar 91 10:45 PST From: "William M. York" Subject: Converging on CLIM To: kma@samson.cadr.amis.com, clim@samson.cadr.amis.com In-Reply-To: <19910311173156.8.KMA@SAMSON.cadr.amis.com> Message-ID: <19910312184506.2.YORK@TEX-AVERY.west.dialnet.ila.com> Date: Mon, 11 Mar 91 09:31 PST From: "K. Mark Alexander" Does anyone have any inkling as to when the Symbolics version of CLIM and the ILA version of CLIM (more specifically, Lucid) will look and act enough like the same animal to deserve the name "*COMMON* Lisp Interface Manager"? The goal is, as always, to ship a 100% compatible version of CLIM on all the vendors' Lisp platforms. Symbolics is currently shipping version 1.0 of CLIM on its two Lisp platforms, CLOE and Genera. The final development push is being put into the X Windows/Unix version of that same 1.0 software for use in the Franz, Lucid and Harlequin environments. After that is taken care of, we will turn our attention to a product version of CLIM for the Macintosh Lisp environment. CLIM 1.0 will support a single-source CLIM application portably across all the Lisp/hardware/window system platforms for which it is released.   Received: from BBN.COM by LABS-N.BBN.COM id aa12730; 13 Mar 91 14:03 EST Received: from FUJI.ILA.COM by BBN.COM id aa00786; 13 Mar 91 13:54 EST Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 237480; 13 Mar 91 13:58:41 EST Received: from TEX-AVERY.west.dialnet.ila.com by Chuck-Jones.West.Dialnet.ILA.COM via CHAOS with CHAOS-MAIL id 50387; Wed 13-Mar-91 10:23:03 PST Date: Wed, 13 Mar 91 10:30 PST From: "William M. York" Subject: Converging on CLIM To: CLIM@BBN.COM In-Reply-To: <19910311173156.8.KMA@SAMSON.cadr.amis.com> Supersedes: <19910312184506.2.YORK@TEX-AVERY.west.dialnet.ila.com> Comments: Retransmission of failed mail. Message-ID: <19910313183000.7.YORK@TEX-AVERY.west.dialnet.ila.com> [Apologies to those of you who have already seen this; I got tons of "failed mail" replies due to the weird address routing.] Date: Mon, 11 Mar 91 09:31 PST From: "K. Mark Alexander" Does anyone have any inkling as to when the Symbolics version of CLIM and the ILA version of CLIM (more specifically, Lucid) will look and act enough like the same animal to deserve the name "*COMMON* Lisp Interface Manager"? The goal is, as always, to ship a 100% compatible version of CLIM on all the vendors' Lisp platforms. Symbolics is currently shipping version 1.0 of CLIM on its two Lisp platforms, CLOE and Genera. The final development push is being put into the X Windows/Unix version of that same 1.0 software for use in the Franz, Lucid and Harlequin environments. After that is taken care of, we will turn our attention to a product version of CLIM for the Macintosh Lisp environment. CLIM 1.0 will support a single-source CLIM application portably across all the Lisp/hardware/window system platforms for which it is released.   Received: from BBN.COM by LABS-N.BBN.COM id aa28765; 14 Mar 91 19:35 EST Received: from carbon.elements.rpal.com by BBN.COM id aa08076; 14 Mar 91 19:31 EST Received: from neon.rpal.com (neon.elements.rpal.com) by rpal.com (4.1/rpal-4.1.0) id AA16630; Thu, 14 Mar 91 16:32:15 PST Date: Thu, 14 Mar 91 16:32:15 PST From: Mike Shaff Message-Id: <9103150032.AA16630@rpal.com> Received: by neon.rpal.com (4.1/rpal-4.1.0) id AA01936; Thu, 14 Mar 91 16:32:13 PST To: clim@BBN.COM Subject: A Kinder Gentler Event Loop Reply-To: shaff@rpal.rockwell.com ciao, I am attempting to construct a somewhat robust version of an extension to CLIM. The extension I wish to build will supply two things: - Periodic events (otherwise known as timer events) - Idle events This is in an ideal world, I recognize I am dealing with Common Lisp, CLOS, and CLIM and will therefore probably settle for something much less. Regarding periodic events the minimum functionality I need is to generate a timer event every clim-bogus-extensions:*timer-event-interval*. Idle events in this minimum functionality system would be generated after clim-bogus-extensions:*microseconds-till-idle* or some such nonsense. These variables are made global in the hope of having the settings apply to a given application frame process, rather than every application frame (using the special variable handling of processes in the somewhat common process interface). I am trying to do this in such as way as to avoid rewriting in a serious way the extensions after each CLIM release. This seems reasonable, right? The entire event methodology seems to evade any firm grasp by my humble understanding. One could even say that the more I work with CLIM code the less I understand, but that is another story. Simplistically, There is a layer of event metaphor in CLIM built upon a silica layer that supplies the underlying mechanics and event definition. I initially based my implementation on the Silica layer with mixed results. This seemed logical as it had such macros as sio2::define-event-type, which though an internal appeared to be a valid starting point. Now, for a while now I have been listening to talk about CLIM version x being based on the Symbolics' version and version x+y being the unification of ILA's version and Symbolics version. Suddenly this week I was struck with the realization that a Symbolics version implied the absence of a Silica layer. My already floundering spirits sank deeper into the murk. After spending a few days looking more intensively at the CLIM layer, I am completely baffled as to how it would be possible to implement my fondest desires using only this layer. Yet, it seems this is the only layer available until some unknown time in a calmer future. I turn, therefore, to this great band of information with my plight. Can you help us Obi-Wan Kenobi? mas The sun will shine in my back door someday. March winds will blow all my troubles away.   Received: from BBN.COM by LABS-N.BBN.COM id aa07225; 15 Mar 91 12:19 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa01663; 15 Mar 91 12:10 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 399011; 15 Mar 1991 11:35:06-0500 Date: Fri, 15 Mar 1991 11:30-0500 From: Scott McKay Subject: A Kinder Gentler Event Loop To: shaff@rpal.rockwell.com, CLIM@BBN.COM In-Reply-To: <9103150032.AA16630@rpal.com>, The message of 14 Mar 1991 19:32 EST from Mike Shaff Message-ID: <19910315163051.4.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Thu, 14 Mar 1991 19:32 EST From: Mike Shaff I am attempting to construct a somewhat robust version of an extension to CLIM. The extension I wish to build will supply two things: - Periodic events (otherwise known as timer events) - Idle events This is in an ideal world, I recognize I am dealing with Common Lisp, CLOS, and CLIM and will therefore probably settle for something much less. Common Lisp, CLOS, and CLIM have very little to do with what you want. Periodic timers are a service that either are, or are not, provided by the scheduler of whatever operating system you are using. Common Lisp, CLOS, and CLIM enter into the equation only when you wish to have them interface to the operating system. Your only other choice is to have the event loop run continuously, waiting for a period of time to elapse by watching the clock, since SLEEP provides granularity of one second. Regarding periodic events the minimum functionality I need is to generate a timer event every clim-bogus-extensions:*timer-event-interval*. Idle events in this minimum functionality system would be generated after clim-bogus-extensions:*microseconds-till-idle* or some such nonsense. These variables are made global in the hope of having the settings apply to a given application frame process, rather than every application frame (using the special variable handling of processes in the somewhat common process interface). I am trying to do this in such as way as to avoid rewriting in a serious way the extensions after each CLIM release. This seems reasonable, right? Frankly, no. The implementation of the event loop varies from platform to platform, and is an internal part of the CLIM implementation. You cannot depend on it not changing. The entire event methodology seems to evade any firm grasp by my humble understanding. One could even say that the more I work with CLIM code the less I understand, but that is another story. Simplistically, There is a layer of event metaphor in CLIM built upon a silica layer that supplies the underlying mechanics and event definition. I initially based my implementation on the Silica layer with mixed results. This seemed logical as it had such macros as sio2::define-event-type, which though an internal appeared to be a valid starting point. Now, for a while now I have been listening to talk about CLIM version x being based on the Symbolics' version and version x+y being the unification of ILA's version and Symbolics version. Suddenly this week I was struck with the realization that a Symbolics version implied the absence of a Silica layer. My already floundering spirits sank deeper into the murk. The event model in CLIM Release 1.0 is simpler (or more simple-minded, if you prefer) than the one provided by Silica. If anything, it is easier to understand because it does less. But, as you have deduced, the event layer will almost certainly change radically between CLIM Release 1 and CLIM Release 2. After spending a few days looking more intensively at the CLIM layer, I am completely baffled as to how it would be possible to implement my fondest desires using only this layer. Yet, it seems this is the only layer available until some unknown time in a calmer future. I turn, therefore, to this great band of information with my plight. Can you help us Obi-Wan Kenobi? This OWK is unable to provide you any good advice. It is much too late in the CLIM Release 1 development cycle to implement timers in the event loop. Perhaps the people designing Release 2 can be persuaded. You can help by being extremely specific about what it is you need.   Received: from BBN.COM by LABS-N.BBN.COM id aa08979; 15 Mar 91 14:42 EST Received: from FUJI.ILA.COM by BBN.COM id aa08406; 15 Mar 91 14:34 EST Received: from DIAMOND-HEAD.ILA.COM by FUJI.ILA.COM via CHAOS with CHAOS-MAIL id 237812; Fri 15-Mar-91 11:14:54 EST Date: Fri, 15 Mar 91 11:13 EST From: "David C. P. Linden" Subject: A Kinder Gentler Event Loop To: shaff@rpal.rockwell.com, clim@BBN.COM In-Reply-To: <9103150032.AA16630@rpal.com> Message-ID: <19910315161331.3.DCPL@DIAMOND-HEAD.ILA.COM> Date: Thu, 14 Mar 91 16:32:15 PST From: Mike Shaff Can you help us Obi-Wan Kenobi? Obi-Wan gone. Now only Yoda. Yoda help? There is no try. There is "do", and "not do". Two things: First, it's time to see RepoMan again, since a couple days ago the Silica camp started discussing rationalizing, documenting, etc, etc, the event subsystem. I'm not sure what to tell you for the short term using 0.9. Second, it is this type of thing (especially with customer feedback) that is part of the unification of the spec that will unify the Symbolics and the Silica versions of CLIM. In regards to the functionality you are trying to get: it took me a while to unite "events" with "input events." At first I thought you just wanted timers that ran little pieces of code at periodic intervals or when the clock stuck 2. Then I noticed you wanted "events" to be synthesized for a frame? Or do you want events to be synthesized for a port? I'm not sure what you are trying to do or what your higher level goal is.   Received: from BBN.COM by LABS-N.BBN.COM id aa09317; 15 Mar 91 14:56 EST Received: from MEILLET.ILA.COM by BBN.COM id aa09170; 15 Mar 91 14:51 EST Received: from chestnut.com (ALMOND.CHESTNUT.COM) by meillet.ila.com (4.1/ILA-4.10) id AA00256; Fri, 15 Mar 91 14:48:16 EST Received: by chestnut.com (4.1/SMI-4.1) id AA00246; Fri, 15 Mar 91 12:53:55 EST Date: Fri, 15 Mar 91 12:53:55 EST From: Kim Barrett Message-Id: <9103151753.AA00246@chestnut.com> To: SWM@sapsucker.scrc.symbolics.com Cc: shaff@rpal.rockwell.com, CLIM@BBN.COM Cc: kmp@symbolics.com In-Reply-To: Scott McKay's message of Fri, 15 Mar 1991 11:30-0500 <19910315163051.4.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Subject: A Kinder Gentler Event Loop [kmp added as x3j13 editor.] > Your only other choice is to have the event loop run continuously, > waiting for a period of time to elapse by watching the clock, since > SLEEP provides granularity of one second. I couldn't just let something like this go by. The definition of SLEEP says that the argument may be any non-negative non-complex number (probably this should be read as non-negative REAL now). This permits fractions of a second to be specified. The actual granularity is implementation specific.   Received: from BBN.COM by LABS-N.bbn.COM id aa09587; 15 Mar 91 15:16 EST Received: from FUJI.ILA.COM by BBN.COM id aa10097; 15 Mar 91 15:10 EST Received: from DIAMOND-HEAD.ILA.COM by FUJI.ILA.COM via CHAOS with CHAOS-MAIL id 237917; Fri 15-Mar-91 15:14:52 EST Date: Fri, 15 Mar 91 15:13 EST From: "David C. P. Linden" Subject: A Kinder Gentler Event Loop To: Scott McKay , shaff@rpal.rockwell.com, CLIM@BBN.COM In-Reply-To: <19910315163051.4.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Message-ID: <19910315201330.9.DCPL@DIAMOND-HEAD.ILA.COM> Date: Fri, 15 Mar 1991 11:30-0500 From: Scott McKay ... Your only other choice is to have the event loop run continuously, waiting for a period of time to elapse by watching the clock, since SLEEP provides granularity of one second. Nit: SLEEP's argument has the units of seconds, which says nothing of the granularity.   Received: from BBN.COM by LABS-N.bbn.COM id aa09917; 15 Mar 91 15:48 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa11867; 15 Mar 91 15:43 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 399076; 15 Mar 1991 15:44:09-0500 Date: Fri, 15 Mar 1991 15:40-0500 From: Scott McKay Subject: A Kinder Gentler Event Loop To: kab@chestnut.com, SWM@sapsucker.scrc.symbolics.com cc: shaff@rpal.rockwell.com, CLIM@BBN.COM, kmp@symbolics.com In-Reply-To: <9103151753.AA00246@chestnut.com> Message-ID: <19910315204026.2.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Fri, 15 Mar 1991 12:53 EST From: kab@chestnut.com (Kim Barrett) [kmp added as x3j13 editor.] > Your only other choice is to have the event loop run continuously, > waiting for a period of time to elapse by watching the clock, since > SLEEP provides granularity of one second. I couldn't just let something like this go by. The definition of SLEEP says that the argument may be any non-negative non-complex number (probably this should be read as non-negative REAL now). This permits fractions of a second to be specified. The actual granularity is implementation specific. Whatever. My point is that SLEEP is a lousy way to implement timers in an event loop. What shaff@rpal.rockwell.com needs is a primitive that blocks on a set of events (mouse motion, keyboard input, etc.), but will also becomes runnable when a timer expires. This primitive is rightly provided by the operating system, not CLIM.   Received: from BBN.COM by LABS-N.bbn.COM id aa09943; 15 Mar 91 15:50 EST Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa11911; 15 Mar 91 15:44 EST Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 919539; 15 Mar 1991 15:10:08-0500 Date: Fri, 15 Mar 1991 15:13-0500 From: Kent M Pitman Subject: A Kinder Gentler Event Loop To: kab@chestnut.com cc: kmp@stony-brook.scrc.symbolics.com, swm@sapsucker.scrc.symbolics.com, shaff@rpal.rockwell.com, clim@BBN.COM In-Reply-To: <9103151753.AA00246@chestnut.com> Message-ID: <19910315201302.6.KMP@BOBOLINK.SCRC.Symbolics.COM> Yes, SLEEP takes a real, not an integer. So fractions are ok. Unlike all the other time functions, which take only integers. Of course, the granularity is not specified, so saying 0.5 might not promise you a wakeup to that granularity. (And, frankly, saying 1 may not guarantee that you get woken up in one second either...) But at least you can say what you want and then quibble with your vendor if he doesn't interpret your semantically-well-defined request in a way that is adequate for your task. But the arg conventions leave me in a quandry editorially. I -really- want to define an absolute universal time as a positive real number of seconds since 1900, and to define a relative universal time as a positive real number of seconds (i.e., a "time interval"). But all the things which take absolute universal times insist on integers, so overgeneralizing the term might be confusing. And all the things which take relative universal times (which actually is only one -- SLEEP) take real numbers, so if I talk about SLEEP's argument as a relative universal time, everyone wonders why it can take fractions as arguments. I suppose I could say that an absolute universal time is an integer and a relative universal time is a real, but that seems silly and ties the hands of implementors who want to add other functions on absolute and relative times. I'm inclined to believe that the other time functions should take reals as arguments as well, and implementations could just coerce them to integers first thing if they weren't going to care about the fraction... What a mess.   Received: from BBN.COM by LABS-N.bbn.COM id aa10136; 15 Mar 91 15:56 EST Received: from carbon.elements.rpal.com by BBN.COM id aa12335; 15 Mar 91 15:53 EST Received: from neon.rpal.com (neon.elements.rpal.com) by rpal.com (4.1/rpal-4.1.0) id AA15133; Fri, 15 Mar 91 12:54:32 PST Date: Fri, 15 Mar 91 12:54:32 PST From: Mike Shaff Message-Id: <9103152054.AA15133@rpal.com> Received: by neon.rpal.com (4.1/rpal-4.1.0) id AA02596; Fri, 15 Mar 91 12:54:31 PST To: clim@BBN.COM Cc: DCPL@fuji.ila.com In-Reply-To: David C. P. Linden's message of Fri, 15 Mar 91 11:13 EST <19910315161331.3.DCPL@DIAMOND-HEAD.ILA.COM> Subject: A Kinder Gentler Event Loop Reply-To: shaff@rpal.rockwell.com ciao, David Linden opened with: There is no try. There is "do", and "not do". I love this quotation, it used to adorn my terminal. Thank-you for reminding me of its existence. David continued: In regards to the functionality you are trying to get: it took me a while to unite "events" with "input events." At first I thought you just wanted timers that ran little pieces of code at periodic intervals or when the clock stuck 2. Then I noticed you wanted "events" to be synthesized for a frame? Or do you want events to be synthesized for a port? I'm not sure what you are trying to do or what your higher level goal is. Let's start with, "I'm not sure what you are trying to do or what your higher level goal is." When I first encountered CLIM I actually took a few moments to look at the introduction, I have learned from experience that on occasion valuable insight can be garnered from it, and I read, "CLIM attempts to abstract out shared concepts in the host window systems." This is nice, but is it useful? Yes, most assuredly it is. Ah, but is it useful if there is no easy methodology for incorporating the rest of an application's event handling into the CLIM framework? I would argue the value of event handling in CLIM becomes tenuous. Application developers currently have hefty overheads to contend with in the development of their application (Common Lisp manuals that are 900+ pages, CLIM documentation that should be 900+ pages ;-) CLIM is involved with an ambitious and meritorious effort to aid the application developer. Is it wise to force the developer to maintain two or more event handling mechanisms? In looking at the documentation regarding basic input, we find that there exists a 'standard' event hierarchy: Nota Bene : "That this list is not intended to be exhaustive for all time, and may be (in fact, will likely be) expanded or otherwise modified in the future." event (Note, '...' refers to additional specific event types) device-event key-event ... button-event ... motion-event ... I do not have a solid proposal for the functionality I am seeking. But in order to continue the discussion I shall put forth an illustration: event (Note, '...' refers to additional event types) device-event key-event ... button-event ... motion-event ... OZONE-EVENT TIMER-EVENT PERIODIC-EVENT TIMED-EVENT IDLE-EVENT ... The ozone represents events which the application must deal with that are not related to a user accessible device. Nonetheless, these events have their role in the user's world. Timer events, I will acknowledge, more often than not are a means to an end. A powerful means, however, to a common end. Many a nasty code segment I have seen that was an attempt to achieve what a simple timer would supply. I know that we are all aware here of the nature of timers and their relation to application interface, so I will not belabor this issue. Idle events create an abstraction for timeouts and as such are not needed by all applications. Notice that I put forth the notion that timeout is, in fact, a specialization of a timed-event. A timed-event is a single shot timer-event (yes, ala Unix). My high level goal in all of this is to create an event layer that can be used as the application's mechanisms for handling events. This may require some extensions on their part for highly specialized events, but possible nonetheless. As it stands now, I see little possibility for the application developer to use the CLIM event metaphor as the unifying event handling mechanism I believe is needed. mas Please don't dominate the rap, Jack If you've got nothing new to say If you please, don't back up the track This train's got to run today   Received: from BBN.COM by LABS-N.bbn.COM id aa10991; 15 Mar 91 17:46 EST Received: from carbon.elements.rpal.com by BBN.COM id aa18480; 15 Mar 91 17:40 EST Received: from neon.rpal.com (neon.elements.rpal.com) by rpal.com (4.1/rpal-4.1.0) id AA17139; Fri, 15 Mar 91 14:41:44 PST Date: Fri, 15 Mar 91 14:41:44 PST From: Mike Shaff Message-Id: <9103152241.AA17139@rpal.com> Received: by neon.rpal.com (4.1/rpal-4.1.0) id AA02638; Fri, 15 Mar 91 14:41:43 PST To: CLIM@BBN.COM Cc: SWM@sapsucker.scrc.symbolics.com In-Reply-To: Scott McKay's message of Fri, 15 Mar 1991 11:30-0500 <19910315163051.4.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Subject: A Kinder Gentler Event Loop Reply-To: shaff@rpal.rockwell.com ciao, Scott McKay commented: Common Lisp, CLOS, and CLIM have very little to do with what you want. Periodic timers are a service that either are, or are not, provided by the scheduler of whatever operating system you are using. Common Lisp, CLOS, and CLIM enter into the equation only when you wish to have them interface to the operating system. Indeed, Common Lisp, CLOS, and CLIM only become important when interfacing one's application with the outside world, but Scott, what is CLIM's purpose if not for the interfacing of applications to the outside world? I think it is an error (nay, it should be a signalled error) to view mechanisms such as timer events as transient stray hacks that exist on some random operating systems and/or schedulers. Truth is a large number of operating systems in use today have such mechanisms and for good reason. Scott wrote: Your only other choice is to have the event loop run continuously, waiting for a period of time to elapse by watching the clock, since SLEEP provides granularity of one second. At some deep bowel in the implementation this is true, however this totally avoids the issue of event abstraction which was the thrust of my interest. I am fully aware of hacks that will allow me to have timer interrupts interact with my CLIM applications. I know ways of hacking into the timeout code to accomplish other goals. These limited solutions are not what is at issue. The question I put forth to the CLIM list relates to the event abstraction of CLIM. Is its model, albeit implicit, so rigid that extensions are quite insurmountable? Scott wrote: The implementation of the event loop varies from platform to platform, and is an internal part of the CLIM implementation. You cannot depend on it not changing. Event handling, I would argue, is the most important aspect of a user interface management system. I can get systems to render images on the screen, printer, or other output device with greater speed, flexibility, and clarity than CLIM. But then what? CLIM, like its mentor dynamic windows, allows me put semantics on said output. Wonderful! What is the capability? Event handling with a context. CLIM allows me to build a command abstraction which is independent of its input form. Again, what is this capability? Yes, once again an event handling abstraction. Most Applications, unlike politicians, must listen to the outside world. Few applications are given the luxury of surviving by spewing glorious output which is hereafter unusable. An application's usefulness is often determined on how easy interaction is accomplished. So, the question becomes, how does the event handling protocol of CLIM help the developer in meeting these goals? Scott wrote: The event model in CLIM Release 1.0 is simpler (or more simple-minded, if you prefer) than the one provided by Silica. If anything, it is easier to understand because it does less. This is not a question of quantity, rather one of the right parts. It is my contention that applications are not limited to interacting solely with mice and keyboards. This interaction is important and plays a critical role in the organization of the application. Scott wrote: It is much too late in the CLIM Release 1 development cycle to implement timers in the event loop. Perhaps the people designing Release 2 can be persuaded. You can help by being extremely specific about what it is you need. I recognize that CLIM Release 1 is frozen. I had hoped to raise the issue of generalized event handling in CLIM applications and make progress on my task of a somewhat robust event handling extension for CLIM for our application. CLIM has the start of a powerful mechanism for the developer to build upon, it is my belief that trying to understand where the current state of affairs interferes with progress is the highest form of compliment. It, however, does not serve the community well to merely post my specific needs. A far greater service is accomplished when issues are raised and specifics are understood in terms of the issue. mas Please don't dominate the rap, Jack If you've got nothing new to say If you please, don't back up the track This train's got to run today   Received: from BBN.COM by LABS-N.BBN.COM id aa11929; 18 Mar 91 11:14 EST Received: from FUJI.ILA.COM by BBN.COM id aa13197; 18 Mar 91 10:58 EST Received: from DIAMOND-HEAD.ILA.COM by FUJI.ILA.COM via CHAOS with CHAOS-MAIL id 238043; Mon 18-Mar-91 11:01:08 EST Date: Mon, 18 Mar 91 10:59 EST From: "David C. P. Linden" Subject: A Kinder Gentler Event Loop To: shaff@rpal.rockwell.com, clim@BBN.COM cc: DCPL@fuji.ila.com In-Reply-To: <9103152054.AA15133@rpal.com> Message-ID: <19910318155940.0.DCPL@DIAMOND-HEAD.ILA.COM> This helped. Let me bounce some issues off of you. I'm trying to neither give you a solution nor hinder its emergence. The term "event" in the documentation you quote pretty much does refer to keyboard and pointer events. It was designed to cover stuff from attached devices, and thus should be extensible to joy-sticks, Kanji tablets, motion detectors, etc. The theory is/was that these capture the abstration of "gesture" which is an action taken directly by the user, and that that action should be delivered to the application. It might be appropriate to splice "INPUT-EVENT" as a child to "EVENT" and a parent of all the other events types. This would distinguish it from ozone events and timer events, which are indeed events, but not input events. Thus, PROCESS-NEXT-EVENT might be renamed to PROCESS-NEXT-INPUT-EVENT or PROCESS-NEXT-GESTURE. I would argue that this is the wrong place for timer events, as timer events are not in general part of a window system (such as X), but rather a separate substrate. I think you want two things: a timer mechanism and a way to define&deliver events to applications. You would synthesize these two things into a mechanism to deliver timer events to applications. The design trick then, is to define -- the way to extend "events" so that you can define ozone events and timer events and expect it to work in CLIM, -- a standard way CLIM applications can connect to a timer mechanism, -- how applications receive/process/queue events so that your timer events are handled properly. I think this is the real trick, which I'll try to discuss if I'm on the mark in assessing your goals. Does all of this sound consistent with the goals you have and the direction you would like to see things heading, or have I misunderstood you completely?   Received: from BBN.COM by LABS-N.BBN.COM id aa16751; 18 Mar 91 17:37 EST Received: from carbon.elements.rpal.com by BBN.COM id aa02371; 18 Mar 91 17:34 EST Received: from neon.rpal.com (neon.elements.rpal.com) by rpal.com (4.1/rpal-4.1.0) id AA14650; Mon, 18 Mar 91 14:35:48 PST Date: Mon, 18 Mar 91 14:35:48 PST From: Mike Shaff Message-Id: <9103182235.AA14650@rpal.com> Received: by neon.rpal.com (4.1/rpal-4.1.0) id AA04819; Mon, 18 Mar 91 14:35:47 PST To: clim@BBN.COM Cc: DCPL@fuji.ila.com In-Reply-To: David C. P. Linden's message of Mon, 18 Mar 91 10:59 EST <19910318155940.0.DCPL@DIAMOND-HEAD.ILA.COM> Subject: A Kinder Gentler Event Loop Reply-To: shaff@rpal.rockwell.com ciao, David Linden wrote: I think you want two things: a timer mechanism and a way to define&deliver events to applications. You would synthesize these two things into a mechanism to deliver timer events to applications. The design trick then, is to define -- the way to extend "events" so that you can define ozone events and timer events and expect it to work in CLIM, -- a standard way CLIM applications can connect to a timer mechanism, -- how applications receive/process/queue events so that your timer events are handled properly. I think this is the real trick, which I'll try to discuss if I'm on the mark in assessing your goals. I think you wrap up my concerns quite nicely, certainly with less verbosity than I. My interest is really with the ability to define and deliver events to my application. Timers were a vehicle for motivating that discussion. My goal, again, is to have a single event handling mechanism. This gives me, the developer, the option of unifying computational control aspects of my application.   Received: from BBN.COM by LABS-N.BBN.COM id aa17213; 18 Mar 91 18:22 EST Received: from brazil.cambridge.apple.com by BBN.COM id aa03810; 18 Mar 91 18:19 EST Received: from [90.223.0.23] by brazil.cambridge.apple.com with SMTP (5.64/25-eef) id AA06483; Mon, 18 Mar 91 18:30:52 -0500 for clim@BBN.COM Message-Id: <9103182330.AA06483@brazil.cambridge.apple.com> Date: Mon, 18 Mar 91 18:19:14 From: "David A. Moon" To: shaff@rpal.rockwell.com, DCPL@fuji.ila.com Subject: Re: A Kinder Gentler Event Loop Cc: clim@BBN.COM Is there a reason why you want to do all this at the event level, or would you be happy if you could cause a timer to cause an application command to get executed? I should think that doing it at the command level rather than the event level would be a lot easier to make independent of the machine and operating system. One would need to decide whether these spontaneous commands are suppressed while in the middle of reading a command, or get inserted in front of the command currently being read. In any case execution of a spontaneous command would not happen simultaneous with execution of any other command (the same property your event-driven idea presumably has). Note that doing it as a command does not imply that anything echoes. One reason why you want to use timer events or commands might be that you need to work in a Lisp that doesn't have multiple processes, so you can't use the "obvious" implementation of having a background process that does the time-dependent operations and synchronizes with your main process in an application-dependent way. Are there other reasons? In other words, if all CLIM environments you use were in Lisps with multiple processes, would you still be asking for this?   Received: from BBN.COM by LABS-N.BBN.COM id aa26702; 19 Mar 91 13:29 EST Received: from carbon.elements.rpal.com by BBN.COM id aa01760; 19 Mar 91 13:08 EST Received: from neon.rpal.com (neon.elements.rpal.com) by rpal.com (4.1/rpal-4.1.0) id AA13031; Tue, 19 Mar 91 10:09:48 PST Date: Tue, 19 Mar 91 10:09:48 PST From: Mike Shaff Message-Id: <9103191809.AA13031@rpal.com> Received: by neon.rpal.com (4.1/rpal-4.1.0) id AA05436; Tue, 19 Mar 91 10:09:47 PST To: clim@BBN.COM Cc: moon@brazil.cambridge.apple.com, DCPL@fuji.ila.com In-Reply-To: David A. Moon's message of Mon, 18 Mar 91 18:19:14 <9103182330.AA06483@brazil.cambridge.apple.com> Subject: A Kinder Gentler Event Loop Reply-To: shaff@rpal.rockwell.com ciao, David Moon wrote: Is there a reason why you want to do all this at the event level, or would you be happy if you could cause a timer to cause an application command to get executed? Unfortunately, I was not very effective in conveying my primary interest to this group. David Linden in his last note accomplished in one note what I was unable to accomplish in three. My interest concerns the ability to define and deliver events to applications. Thus taking advantage of the event mechanism to achieve, amongst other things, non-local transfer of control. One can imagine the use of software in conjunction with CLIM that shares the concept of an 'event' (e.g., blackboard control software). The events defined by these other systems may not be fundamentally different from CLIM's, save they are not generated by a user device. For instance I, as a developer, may wish to implement an active values mechanism using CLIM's event mechanism and creating three new classes of events: CELL-EVENT, CELL-WRITE-EVENT, and CELL-READ-EVENT. This is obviously not a speed hack ;-), rather a method by which I can deliver services without additional conceptual overhead to my 'clients.' The developer of an application which uses both the illustration blackboard control software and CLIM should not have to wrap their head around differing concepts of events to accomplish the task at hand. Indeed, I would like to employ the command mechanism to achieve the same end at a higher abstraction layer, but I have not understood how to accomplish this. If I have an effective means of introducing events into the "event stream" I am free to implement the handling timers or other occurrences, which I view as events, in a unified fashion even in the face of implementation specific properties. mas Sometimes we walk alone Sometimes the songs that we hear are just songs of our own   Received: from BBN.COM by LABS-N.BBN.COM id aa18416; 21 Mar 91 4:01 EST Received: from chx400.switch.ch by BBN.COM id aa03854; 21 Mar 91 3:48 EST Received: from nchx400.switch.ch by chx400.switch.ch (5.61/Ultrix2.4-C) id AA25929; Thu, 21 Mar 91 09:49:28 +0100 X400-Received: by mta nchx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/; Relayed; Thu, 21 Mar 1991 09:48:15 +0100 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Thu, 21 Mar 1991 09:45:25 +0100 Date: Thu, 21 Mar 1991 09:45:25 +0100 X400-Originator: schneide@divsun.unige.ch X400-Mts-Identifier: [/PRMD=SWITCH/ADMD=ARCOM/C=CH/;910321094525] X400-Content-Type: P2-1984 (2) Content-Identifier: 240 Conversion: Prohibited From: Schneider Daniel Message-Id: <240*/S=schneide/OU=divsun/O=unige/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> To: clim@BBN.COM MMDF-Warning: Parse error in original version of preceding line at BBN.COM Subject: Announcement by Franz Lisp - Any Comments ? I got this via SLUG (the Symbolics Users Group). > [ ....] > Franz asked us to forward this to SLUG: > > Elizabeth Shook, Franz Inc. 1995 University Avenue, Suite 275 > eshook@Franz.COM (internet) Berkeley, CA 94704 > uunet!franz!eshook (uucp) Phone: (415) 548-3600; FAX: (415) 548-8253 > > ************** > PRESS RELEASE > For Immediate Release > Contact: Elizabeth Shook, (415) 548-3600 > > > Franz Inc. Announces CLIM(tm) 1.0 > The Portable Common LISP Interface Manager > > > (March 18, 1991 -- Berkeley, CA) Franz Inc. has signed an agreement > with Symbolics, Inc. to port Symbolics' CLIM 1.0 to Allegro CL(r) > Common LISP on standard Unix workstations. CLIM, the Common LISP > Interface Manager, is a portable, high-level set of facilities for the > development of graphical user interfaces for LISP-based applications. > > CLIM is the emerging standard for user interfaces in Common LISP. > Franz Inc.'s version of CLIM 1.0 is fully optimized for Allegro CL 4.0 > with CLOS (Common LISP Object System) and the Sun SPARC family. It is > source code compatible with Symbolics' CLIM 1.0. > > Franz' CLIM 1.0 will be available in the second quarter of 1991. > Customers who have purchased CLIM 0.9 through Franz will receive a > free upgrade to CLIM 1.0. > > "Franz Inc. will be the first Common LISP vendor to offer CLIM 1.0 on > Unix workstations," said Fritz Kunze, president of Franz Inc. "We are > committed to portability of LISP applications across platforms. We > feel that Allegro CL 4.0 with CLOS and CLIM 1.0 offer the power and > flexibility necessary to deliver complex applications on stock > hardware." (1) What does this mean for us ? Will the current line of development (clim 1.0 version 0.9) be given up in favor of the current Symbolics implementation (1.0) and do we have to adopt the symbolics clim syntax ? Is Symbolics 1.0 different from Symbolics Cloe Clim prelease? (2a) Will there be a portable widget set in this new Franz release containing things like radio buttons, one-of-panes, line-edit panes, highlighting menus or do we have to stay with the naked symbolics "dw-style" interaction paradigm? I WANT THOSE WIDGETS AND MORE OF 'EM !!! (2b) Will code be *really* source-compatible between Genera clim and other clims? I.e. If we get those widgets on Franz, will the Symbolics have them too ?? (In this case I'll go back to our 3620 for development work) (3) How about the native look and feel kit (is that still clim 2.0?) .... and ... and.... and ??? I'd welcome some comment by somebody who knows everything about this and more ..... :) ----------- Daniel K.Schneider, TECFA (Educational Technologies and Learning) Faculte de Psychologie et des Sciences de l'Education, University of Geneva, 1211 Geneva 4 (Switzerland), Tel.(..41)22 705 7652, Fax. (..41) 22 20 29 27. Internet: schneide@divsun.unige.ch (and various national nets) | if reply CSnet/ARPA: schneide%divsun.unige.ch@relay.cs.net (old style) | does not X400: S=schneide;OU=divsun;O=unige;PRMD=switch;ADMD=arcom;C=ch | work, uucp: mcvax!cui!divsun.unige.ch!shneider | try one BITNET: schneide@cgeuge51 | of DECNET: UGUN2A::SCHNEIDE (local Swiss) | these   Received: from BBN.COM by LABS-N.BBN.COM id aa24617; 21 Mar 91 13:32 EST Received: from uunet.UU.NET by BBN.COM id aa23960; 21 Mar 91 13:24 EST Received: by uunet.UU.NET with UUCP (5.61/UUNET-primary-gateway) id AA17205; Thu, 21 Mar 91 13:24:09 -0500 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA04745; Thu, 21 Mar 91 09:42:59 PST Received: by fridge.Franz.COM (4.0/FI-1.0) id AA13659; Thu, 21 Mar 91 09:42:45 PST Date: Thu, 21 Mar 91 09:42:45 PST From: Bill Carlson Message-Id: <9103211742.AA13659@fridge.Franz.COM> To: clim@BBN.COM Subject: CLIM 1.0. Franz and Symbolics For more information, call (415) 548-3600, or email info@franz.com Franz Inc. Announces CLIM(tm) 1.0 The Portable Interface Manager for Common LISP (March 18, 1991 -- Berkeley, CA) Franz Inc. has signed an agreement with Symbolics, Inc. to port Symbolics' CLIM 1.0 to Allegro CL(r) Common LISP on standard Unix workstations. CLIM, the Common LISP Interface Manager, is a portable, high-level set of facilities for the development of graphical user interfaces for LISP-based applications. CLIM is the emerging standard for user interfaces in Common LISP. Franz Inc.'s version of CLIM 1.0 is fully optimized for Allegro CL 4.0 with CLOS (Common LISP Object System) and the Sun SPARC family. It is source code compatible with Symbolics' CLIM 1.0. Franz' CLIM 1.0 will be available in the second quarter of 1991. Customers who have purchased CLIM 0.9 through Franz will receive a free upgrade to CLIM 1.0. "Franz Inc. will be the first Common LISP vendor to offer CLIM 1.0 on Unix workstations," said Fritz Kunze, president of Franz Inc. "We are committed to portability of LISP applications across platforms. We feel that Allegro CL 4.0 with CLOS and CLIM 1.0 offer the power and flexibility necessary to deliver complex applications on stock hardware." Franz' introduction of CLIM 1.0 provides a clear migration path for applications developed on Symbolics' dedicated LISP machines to be delivered on standard workstations with Allegro CL. To further simplify application ports, Symbolics can provide developers with tools for converting Dynamic Windows code to CLIM code. Sophisticated Graphical User Interface CLIM gives the developer the ability to build complex and portable graphical user interfaces, quickly and easily. CLIM incorporates the advanced features of Symbolics' Dynamic Windows, including: -- support for drawing of complex geometric shapes, -- support for different drawing options, inking, color, and full affine transformations, -- formatted output, including graphing and tables, -- specification of all aspects of the user interface, including interaction style and specific command menus, -- Symbolics-compatible presentation subsystem. The presentation subsystem automatically maintains links between graphics in the user interface and corresponding objects in the application. The system allows semantics to be associated with output, and provides for context-sensitive input. Applications can accept input in convenient new ways; for example, specific objects on screen can become mouse sensitive. Portable Across Environments CLIM is designed to make applications portable across a variety of windowing systems and platforms. CLIM achieves a portable user interface by providing a set of high-level programming tools that communicate with the low-level implementation language of the host system. From the application's perspective, the details of the host window system, host OS, and host computer are invisible: CLIM handles the interaction with the underlying window system. CLIM is compatible with most window standards, including the X Window System. Future releases of CLIM will provide access to foreign toolkits, such as OPEN LOOK and Motif, allowing the application to automatically adopt the local look and feel of the host environment. Other releases of CLIM in the future may provide access to a number of different window systems, including the Macintosh, Presentation Manager and Microsoft Windows. CLIM 1.0 is based on CLOS, a powerful object-oriented extension to Common LISP. Franz Inc.'s CLIM 1.0 uses Allegro CL's CLOS-based streams to integrate Common LISP I/O functions with CLIM graphics and windowing facilities. CLIM 1.0 will be released first for the Sun SPARC family, followed by other popular Unix workstations later this year. Discounts are available for volume orders and educational customers. Site licenses, which provide economical license pricing for multiple users, are also available. Franz Inc. is the leading vendor of Common LISP-based development environments for Unix workstations. Franz offers Allegro CL 4.0, which includes CLOS and Allegro Presto, an efficient application delivery system. Franz also offers Allegro Composer, an interactive, windows-based development environment with performance analysis tools, including graphical profilers. Franz Inc. was founded in 1984 by affiliates of the Computer Science Department at the University of California at Berkeley, including original developers of Franz Lisp and BSD Unix. Allegro CL, CLIM, and other products are sold and supported worldwide through Franz' direct sales force and distribution partners. Franz customers include universities, research institutions, government agencies, and Fortune 500 companies. For more information, contact Franz Inc., 1995 University Avenue, Berkeley, CA 94704, (415) 548-3600, fax (415) 548-8253. ### Allegro CL, Allegro Composer, and Allegro Presto are trademarks or registered trademarks of Franz Inc. CLIM is a trademark of International Lisp Associates. Unix is a trademark of UNIX Systems Laboratories, Inc. All other trademarks are the property of their respective owners.   Received: from BBN.COM by LABS-N.BBN.COM id aa26275; 21 Mar 91 15:39 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa29294; 21 Mar 91 15:33 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 399667; 21 Mar 1991 15:35:31-0500 Date: Thu, 21 Mar 1991 15:30-0500 From: Scott McKay Subject: Announcement by Franz Lisp - Any Comments ? To: schneide@divsun.unige.ch, clim@BBN.COM Message-ID: <19910321203005.5.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Thu, 21 Mar 1991 03:45 EST From: Schneider Daniel I got this via SLUG (the Symbolics Users Group). (1) What does this mean for us ? Will the current line of development (clim 1.0 version 0.9) be given up in favor of the current Symbolics implementation (1.0) and do we have to adopt the symbolics clim syntax ? Is Symbolics 1.0 different from Symbolics Cloe Clim prelease? CLIM Release 1.0 is the direct descendent of the Symbolics Cloe CLIM pre-release. I personally hope that CLIM Release 2 will have syntax that is as compatible as possible with CLIM Release 1. (2a) Will there be a portable widget set in this new Franz release containing things like radio buttons, one-of-panes, line-edit panes, highlighting menus or do we have to stay with the naked symbolics "dw-style" interaction paradigm? I WANT THOSE WIDGETS AND MORE OF 'EM !!! I cannot answer this question for the long term, but the short answer is that CLIM Release 1 probably will not have support for widget sets. My guess is that it is unlikely that CLIM will ever support a fully portable widget set (that is, one that looks the same on every platform), but will instead support native look and feel for a variety of platforms. This is partly a matter of the size of the job; there is little sense in writing a whole stack of widgets for CLIM when there are 10,000 C programmers already doing it for X-based platforms (and others). (2b) Will code be *really* source-compatible between Genera clim and other clims? I.e. If we get those widgets on Franz, will the Symbolics have them too ?? (In this case I'll go back to our 3620 for development work) It in unlikely that Symbolics will support widgets in a real way. This is part of the job of doing fully portable widgets. (3) How about the native look and feel kit (is that still clim 2.0?) .... and ... and.... and ??? This, like widgets in general, is the province of CLIM 2.0. I personally feel that native look and feel is more important than supporting a fully portable widget set. (Note well that the high-level language used to describe widgets will be platform independent (just like DRAW-LINE is now), but the exact appearance of the widgets will vary from platform to platform.)   Received: from BBN.COM by LABS-N.BBN.COM id aa12191; 22 Mar 91 20:31 EST Received: from charon.arc.nasa.gov by BBN.COM id aa17868; 22 Mar 91 20:28 EST Received: from ROMAN-A-CLEF.arc.nasa.gov by CHARON.arc.nasa.gov via INTERNET with SMTP id 80854; 22 Mar 91 17:27:33 PST Date: Fri, 22 Mar 91 17:27 PST From: will taylor Subject: Using Processes in CLIM To: clim@BBN.COM cc: taylor@charon.arc.nasa.gov Message-ID: <19910323012721.7.TAYLOR@ROMAN-A-CLEF.arc.nasa.gov> In Symbolics early release 1.0 CLIM the following functions/macros are in the clim-utils package: make-process processp destroy-process current-process all-processes show-processes process-yield process-wait process-wait-with-timeout They are not exported/documented. Will they be exported/documented for the released version of 1.0 CLIM? If not, how will CLIM handle processes in a portable way? ==> Will   Received: from BBN.COM by LABS-N.BBN.COM id aa10022; 25 Mar 91 7:08 EST Received: from chx400.switch.ch by BBN.COM id aa00761; 25 Mar 91 7:04 EST Received: from nchx400.switch.ch by chx400.switch.ch (5.61/Ultrix2.4-C) id AA09996; Mon, 25 Mar 91 14:05:21 +0200 X400-Received: by mta nchx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/; Relayed; Mon, 25 Mar 1991 13:04:09 +0100 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Mon, 25 Mar 1991 13:02:47 +0100 Date: Mon, 25 Mar 1991 13:02:47 +0100 X400-Originator: schneide@divsun.unige.ch X400-Mts-Identifier: [/PRMD=SWITCH/ADMD=ARCOM/C=CH/;910325130247] X400-Content-Type: P2-1984 (2) Content-Identifier: 247 Conversion: Prohibited From: Schneider Daniel Message-Id: <247*/S=schneide/OU=divsun/O=unige/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> To: clim@BBN.COM MMDF-Warning: Parse error in original version of preceding line at BBN.COM Subject: I want widgets (was: Announcement by Franz Lisp - Any Comments ?) After my posted "Announcement by Franz Lisp - Any Comments ?" of 21 March, I got some replies by people who were rather glad about that. Concerning my question whether we will get a widget set like the non-documented "ws:" abstract panes on page 86 of the 0.9 CLIM manual, the feeling was that we won't get them right now. The few person who replied also thought that we don't need them really so badly. I got some objections here: (1) A lot of people see CLIM as a device for porting things from the Symbolic to stock hardware. This is fine with me, since I also got this problem. But CLIM must be more than that. It really should give implementors a wider choice for user interaction. E.g. I have chosen CLIM for a larger AI and education projet. The 4 people who work with me have never programmed on a Symbolics or a Sun before. They are used to modern looks and feels. All the see on a Sun is things like Framemaker and they want to program that kind of interface! And me too actually. The Symbolics interaction paradigm is very sound. The idea of having a variety of interaction modes (comands, menus, highlighted objects) is great, Framemaker has it too :) ...The idea of using a relatively stable central window with several panes is very good, because it gives the user some cognitive anchor. I won't comment on the acceptation/presentation framework, since this is *the* reason for using CLIM. But accepting this philosophy does not mean that we should limit user-interaction to *just* those widgets which are currently available in Genera (and certainly not those *very* few in the Symbolics Cloe CLIM prerelease or even the dw package). (2) I think it is fine for Franz, ILA (and cooperating lisp vendors) to produce *first* a stable version, where things like scrolling, redisplay and such really work, and which has more presentation types, e.g. "or". But I need more features *now*, and I'm really hoping that I won't have to draw circles on the screen, accepting them and so on to get a checkbox. After all, CLIM is supposed to be highlevel too. * So here comes my suggestion: ILA could and SHOULD directly give out * relatively portable source code for a minimal set of widgets for those * people who do not just want to port symbolics software and who can't * wait for CLIM 2.0. This code does not need to be garantueed by company * lawyers, it could be declared unsafe and "proper risk involved" and * so forth ... This distribution could be organized via anonymous FTP. No * bureaucracy and tapes and such horrible things are needed. We don't * need printed documentation either. Good documented sample code will * do well enough. Such a server also could be used to redistribute donations by CLIM-programmers. Maybe ILA (or whoever) does not want to program a slider (I'm already happy if I can get highligthing, one-of checkboxes and line-editing ....) but somebody may want to give out his slider. Our group could give out some stuff too. Finally I also want to address the problem of patches. Ok, since I know that I got a "developpers prerelease" I'm not entitled to complain, but I *do* feel a bit frustrated about the fact that Franz (others I don't know, but it seems to be the same) and ILA never gave out patches. (multiple layouts, scrolling graphics, accept symbol really ought to work...!). I can very well understand that they don't have the ressources to mail around tapes, but again: why not using an ftp server. Even remote places lost in, behind and under the mountains can do ftp now... :) Well, here is an incomplete widget wish-list (not in a very smart order): (1) what we already got: - layout panes .... - user panes ..... - simple menus, accepting values (2) from the Abstract panes on page 86 of the 0.9 CLIM manual: - one-of-pane - list-pane - label-pane - line-editor-pane - label-button-pane - radio-button-pane (3) from the Symbolics: - menus with POP-UP windows (having the right size !) - multiple menu choose facility (*highlighting*) - multiple choice facility (boxes) - a TEXT EDITING pane - .... (4) from ?? - a slider - a gauges - icon panes ... and more and here are some other wishes: - the possibility to (semantically) connect other windows to an application frame (sharing commands and mouse-handlers) - enough flexibility for building CLIM applications in another language than English, i.e. being able to change the text of the "End" and "abort" buttons in a menu into something more understandable like "Ok" and "Cancel" or "Annullation or Sortir or ...". Don't forget that the European market is bigger than yours ! - cheers - Daniel And here is a last question, so that I know whom I have to call up to get heard. Is this new Franz 1.0 release built in cooperation with ILA. Or is it this time just Symbolics and Franz. What is Lucid and Harelequin and ... doing ? ---- Daniel K.Schneider, TECFA (Educational Technologies and Learning) Faculte de Psychologie et des Sciences de l'Education, University of Geneva, 1211 Geneva 4 (Switzerland), Tel.(..41)22 705 7652, Fax. (..41) 22 20 29 27.  Received: from BBN.COM by LABS-N.bbn.COM id aa25073; 2 Jan 92 9:14 EST Received: from Sunset.AI.SRI.COM by BBN.COM id aa04059; 1 Jan 92 14:05 EST Received: from Rockaway.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA27369 for SWM@sapsucker.scrc.symbolics.com; Wed, 1 Jan 92 08:55:45 PST Received: by Rockaway.AI.SRI.COM (4.1/SMI-4.1) id AA06609 for clim-support@lucid.com; Wed, 1 Jan 92 08:55:44 PST Date: Wed, 1 Jan 92 8:55:43 PST From: Peter Karp To: Scott McKay Subject: Re: Anybody else hitting completion errors on accept? In-Reply-To: Your message of Tue, 31 Dec 1991 13:28-0500 Cc: clim@BBN.COM, clim-support@lucid.com Message-Id: > In the command processor, hitting the Space key or the Input Editor's > history yank command (control-meta-Y, or is it Escape control-Y under > Allegro?) should yank the default into the input buffer. I recently > also fixed a bug that caused a blowout when you typed a completion > character to non-completing types such as INTEGER. I have yet to ever get defaults to work under Lucid CLIM on a Sparc. When, for example, I do clim:accept on a string with a default and a prompt supplied, both the default and the prompt appear, but neither space nor ESC ctl-Y nor ctl-meta-Y have any effect. That is, they do not cause the default that appears in the prompt to be placed in the input buffer. Peter   Received: from BBN.COM by LABS-N.BBN.COM id aa29268; 2 Jan 92 14:40 EST Received: from att.att.com by BBN.COM id aa22219; 2 Jan 92 14:36 EST From: lgm@iexist.att.com Received: from NSPP11.iexist.att.com by iexist.att.com (4.1/SMI-4.1) id AA08852; Thu, 2 Jan 92 13:30:05 CST Date: Thu, 2 Jan 1992 13:30-0600 Original-From: Lawrence G. Mayka Subject: Does ink affect non-drawn text? To: iexist!att!bbn.com!clim@iexist.att.com Message-Id: <19920102193055.7.LGM@NSPP11.iexist.att.com> Character-Type-Mappings: (1 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB") Fonts: CPTFONT, CPTFONTCB Consider the following function: (defun color-text1 0(ink) (clim:with-drawing-options (nil :ink ink) (write-line "hi there") (values))) Should "hi there" always print in the foreground color, or should its presence/absence/color depend in some way on the argument to COLOR-TEXT? On my monochrome Symbolics XL1200, passing COLOR-TEXT a sufficiently dark color such as CLIM:+GREEN+ causes "hi there" to print (in black on a white background, i.e. the foreground color); passing COLOR-TEXT a lighter color such as CLIM:+CYAN+ causes "hi there" not to show up at all. (Presumably, it is printing in the background color.) Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.   Received: from BBN.COM by LABS-N.BBN.COM id aa00628; 2 Jan 92 16:12 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa29638; 2 Jan 92 16:07 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 419919; 2 Jan 1992 16:07:04-0500 Date: Thu, 2 Jan 1992 16:06-0500 From: Scott McKay Subject: Does ink affect non-drawn text? To: lgm@iexist.att.com, clim@BBN.COM In-Reply-To: <19920102193055.7.LGM@NSPP11.iexist.att.com> Message-ID: <19920102210630.1.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Character-Type-Mappings: (1 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB") Fonts: CPTFONT, CPTFONTCB Date: Thu, 2 Jan 1992 14:30 EST From: lgm@iexist.att.com Consider the following function: (defun color-text1 0(ink) (clim:with-drawing-options (nil :ink ink) (write-line "hi there") (values))) Should "hi there" always print in the foreground color, or should its presence/absence/color depend in some way on the argument to COLOR-TEXT? All output functions observe the medium's drawing state. Therefore, the call to WRITE-LINE is affected by with-drawing-options, and hence by the argument to COLOR-TEXT. On my monochrome Symbolics XL1200, passing COLOR-TEXT a sufficiently dark color such as CLIM:+GREEN+ causes "hi there" to print (in black on a white background, i.e. the foreground color); passing COLOR-TEXT a lighter color such as CLIM:+CYAN+ causes "hi there" not to show up at all. (Presumably, it is printing in the background color.) On a monochrome display, colors are rendered by simulating their approximate luminosity with a stipple. My guess is that the stipple used to render green is dense enough to show some bits on the screen, whereas the stipple for cyan, by chance, does not have any bits that show up in the rendering of the text. I also think that the formula used to compute the luminosity is not correct in the released version of CLIM 1.0. I fixed this in the development version of CLIM a while back...   Received: from BBN.COM by LABS-N.BBN.COM id aa02424; 2 Jan 92 19:18 EST Received: from att.att.com by BBN.COM id aa08666; 2 Jan 92 19:15 EST From: att!YUKON.SCRC.Symbolics.COM!naha@iexist.att.com Received: from att.UUCP by iexist.att.com (4.1/SMI-4.1) id AA21385; Thu, 2 Jan 92 19:10:13 EST Received: from att by att.att.com; Thu, 2 Jan 1992 19:11 EST Received: by att.att.com; Thu Jan 2 19:10:02 EST 1992 Received: from RED-KNOT.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via INTERNET with SMTP id 758459; 2 Jan 1992 18:25:26-0500 Date: Thu, 2 Jan 1992 18:23-0500 Original-From: Mark Nahabedian Subject: Does ink affect non-drawn text? To: iexist!lgm@iexist.att.com, iexist!iexist!att!bbn.com!clim@iexist.att.com In-Reply-To: <19920102193055.7.LGM@NSPP11.iexist.att.com> Message-Id: <19920102232354.3.NAHA@RED-KNOT.SCRC.Symbolics.COM> Character-Type-Mappings: (1 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB") Fonts: CPTFONT, CPTFONTCB Content-Type: binary Content-Length: 1237 Date: Thu, 2 Jan 1992 14:30 EST From: lgm@iexist.att.com Consider the following function: (defun color-text1 0(ink) (clim:with-drawing-options (nil :ink ink) (write-line "hi there") (values))) Should "hi there" always print in the foreground color, or should its presence/absence/color depend in some way on the argument to COLOR-TEXT? On my monochrome Symbolics XL1200, passing COLOR-TEXT a sufficiently dark color such as CLIM:+GREEN+ causes "hi there" to print (in black on a white background, i.e. the foreground color); passing COLOR-TEXT a lighter color such as CLIM:+CYAN+ causes "hi there" not to show up at all. (Presumably, it is printing in the background color.) Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer. I think what's happening here is that CLIM is actually trying to draw the text in +cyan+. When Genera tries to render +cyan+ on a black and white screen, it figures out the intensity for that color and draws at the closest gray level that the display can handle. Since your monochrome display only supports two gray levels: 0% and 100%, and cyan is a light color, you wind up with nothing at all.   Received: from BBN.COM by LABS-N.BBN.COM id aa10372; 3 Jan 92 11:45 EST Received: from elroy.jpl.nasa.gov by BBN.COM id aa13546; 3 Jan 92 11:39 EST Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA04585; Fri, 3 Jan 92 08:38:56 PST Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA01635; Fri, 3 Jan 92 08:34:16 PST Date: Fri, 3 Jan 92 08:34:16 PST From: Curt Eggemeyer Message-Id: <9201031634.AA01635@eraserhead.Jpl.Nasa.Gov> To: clim@BBN.COM Subject: quickie clim question Cc: cl-bugs@franz.com Does clim 1.0 allow you to dynamically change the scroll bar attributes of a pane in an application frame from having just a vertical scroll bar in the margin to both vertical and horizontal scroll bars in the margins and then back to just a vertical scroll bar for that pane? If so, any examples. I need this capability for my interactor pane. Or, if you can't do that can you have application with multiple layouts in which you change from one interactor pane to another? If so, is there anything special I need to worry about besides binding my own stream variables?   Received: from BBN.COM by LABS-N.BBN.COM id aa10961; 3 Jan 92 12:20 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa16123; 3 Jan 92 12:18 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 419974; 3 Jan 1992 12:18:40-0500 Date: Fri, 3 Jan 1992 12:18-0500 From: Scott McKay Subject: quickie clim question To: curt@eraserhead.jpl.nasa.gov, clim@BBN.COM cc: cl-bugs@franz.com In-Reply-To: <9201031634.AA01635@eraserhead.Jpl.Nasa.Gov> Message-ID: <19920103171811.6.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Fri, 3 Jan 1992 11:34 EST From: Curt Eggemeyer Does clim 1.0 allow you to dynamically change the scroll bar attributes of a pane in an application frame from having just a vertical scroll bar in the margin to both vertical and horizontal scroll bars in the margins and then back to just a vertical scroll bar for that pane? If so, any examples. I need this capability for my interactor pane. Unfortunately, CLIM 1.0 is seriously weak in this area. If you are truly desperate, you could do it in a way that would vary from one platform to another, by frobbing the underlying host window yourself. Or, if you can't do that can you have application with multiple layouts in which you change from one interactor pane to another? If so, is there anything special I need to worry about besides binding my own stream variables? This alternative will work.   Received: from BBN.COM by LABS-N.BBN.COM id aa11275; 3 Jan 92 12:51 EST Received: from p.lanl.gov by BBN.COM id aa17588; 3 Jan 92 12:48 EST Received: from zaphod.lanl.gov by p.lanl.gov (5.65/1.14) id AA15678; Fri, 3 Jan 92 10:47:57 -0700 Received: by zaphod.lanl.gov.lanl.gov (4.1/SMI-4.1) id AA04750; Fri, 3 Jan 92 10:47:59 MST Date: Fri, 3 Jan 92 10:47:59 MST From: Skip Egdorf Message-Id: <9201031747.AA04750@zaphod.lanl.gov.lanl.gov> To: clim@BBN.COM Subject: CLIM training possibilities I have taken my CLOS application and started developing a CLIM interface. I have Lucid CLIM on my SparcStation, ILA CLIM (on the way) for my MAC-II, Genera 8.1 on my 3620 and XL400, and Symbolics CLOE for my PC. I should be well on my way to a truly portable application. However, I am finding that trying to learn how to design CLIM interfaces just by inhaling the Symbolics reference manual is a difficult job. I am spending a lot of time trying something, figuring out why it was brain dead, trying something else... The mailing list is a big help here; Someone asks a question, I say "It never occurred to me that you could even TRY that!" and I get a bit smarter. It would probably accelerate my education at this point to attempt to learn from the mistakes of others. I am fairly comfortable with CLIM's concepts now, but I feel that it would help to see what common idioms have been used by others. I have seen too many examples of learning a system or language in a vacuum to trust that what I am now developing is particularly good (for several definitions of the word "good"). Does anyone know of any training classes in CLIM? Commercial offers are acceptable. Any upcoming Conferences that have a CLIM tutorial? Is anyone working on a level introduction to CLIM? Any other suggestions, or is everyone else also just at the "Try things to see how they look" stage? Skip Egdorf hwe@lanl.gov   Received: from BBN.COM by LABS-N.BBN.COM id aa12582; 3 Jan 92 14:36 EST Received: from att.att.com by BBN.COM id aa23419; 3 Jan 92 14:31 EST From: lgm@iexist.att.com Received: from NSPP11.iexist.att.com by iexist.att.com (4.1/SMI-4.1) id AA17643; Fri, 3 Jan 92 13:26:32 CST Date: Fri, 3 Jan 1992 13:28-0600 Original-From: Lawrence G. Mayka Subject: Does ink affect non-drawn text? To: YUKON.SCRC.Symbolics.COM!naha@iexist.att.com Cc: sapsucker.scrc.symbolics.com!swm@iexist.att.com, iexist!att!bbn.com!clim@iexist.att.com In-Reply-To: <19920102232354.3.NAHA@RED-KNOT.SCRC.Symbolics.COM> Message-Id: <19920103192808.1.LGM@NSPP11.iexist.att.com> Character-Type-Mappings: (1 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB") Fonts: CPTFONT, CPTFONTCB Date: Thu, 2 Jan 1992 17:23 CST From: Mark Nahabedian Date: Thu, 2 Jan 1992 14:30 EST From: lgm@iexist.att.com (defun color-text1 0(ink) (clim:with-drawing-options (nil :ink ink) (write-line "hi there") (values))) On my monochrome Symbolics XL1200, passing COLOR-TEXT a sufficiently dark color such as CLIM:+GREEN+ causes "hi there" to print (in black on a white background, i.e. the foreground color); passing COLOR-TEXT a lighter color such as CLIM:+CYAN+ causes "hi there" not to show up at all. (Presumably, it is printing in the background color.) I think what's happening here is that CLIM is actually trying to draw the text in +cyan+. When Genera tries to render +cyan+ on a black and white screen, it figures out the intensity for that color and draws at the closest gray level that the display can handle. Since your monochrome display only supports two gray levels: 0% and 100%, and cyan is a light color, you wind up with nothing at all. Yes. Ironically, calling CLIM:DRAW-TEXT* instead of WRITE-LINE (still with the color CLIM:+CYAN+) produces a light stipple, as I expected. Apparently, the output of WRITE-LINE on a monochrome Genera screen can only be rendered as black or white--nothing in between. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.   Received: from BBN.COM by LABS-N.BBN.COM id aa13742; 3 Jan 92 16:16 EST Received: from YUKON.SCRC.Symbolics.COM by BBN.COM id aa00988; 3 Jan 92 16:09 EST Received: from JUICY-FRUIT.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 758706; 3 Jan 1992 16:10:42-0500 Date: Fri, 3 Jan 1992 16:17-0500 From: Gary Roberts Subject: CLIM training possibilities To: egdorf@zaphod.lanl.gov, clim@BBN.COM In-Reply-To: <9201031747.AA04750@zaphod.lanl.gov.lanl.gov> Message-ID: <19920103211744.8.GROBERTS@JUICY-FRUIT.SCRC.Symbolics.COM> Date: Fri, 3 Jan 1992 12:47 EST From: Skip Egdorf I have taken my CLOS application and started developing a CLIM interface. I have Lucid CLIM on my SparcStation, ILA CLIM (on the way) for my MAC-II, Genera 8.1 on my 3620 and XL400, and Symbolics CLOE for my PC. I should be well on my way to a truly portable application. However, I am finding that trying to learn how to design CLIM interfaces just by inhaling the Symbolics reference manual is a difficult job. I am spending a lot of time trying something, figuring out why it was brain dead, trying something else... The mailing list is a big help here; Someone asks a question, I say "It never occurred to me that you could even TRY that!" and I get a bit smarter. It would probably accelerate my education at this point to attempt to learn from the mistakes of others. I am fairly comfortable with CLIM's concepts now, but I feel that it would help to see what common idioms have been used by others. I have seen too many examples of learning a system or language in a vacuum to trust that what I am now developing is particularly good (for several definitions of the word "good"). Does anyone know of any training classes in CLIM? Commercial offers are acceptable. Any upcoming Conferences that have a CLIM tutorial? Is anyone working on a level introduction to CLIM? Any other suggestions, or is everyone else also just at the "Try things to see how they look" stage? Skip Egdorf hwe@lanl.gov Symbolics offers a training class in CLIM (contact avruch@symbolics.com for further information). Additionally, a CLIM tutorial is currently being planned for the LUV '92 conference, to be held in August in San Diego.   Received: from BBN.COM by LABS-N.BBN.COM id aa24190; 6 Jan 92 14:44 EST Received: from TYCHO.NCSC.MIL by BBN.COM id aa27294; 6 Jan 92 14:33 EST Received: by tycho.ncsc.mil (4.1/SMI-4.1) id AA11820; Mon, 6 Jan 92 14:31:25 EST Date: Mon, 6 Jan 92 14:31:25 EST From: "William (Bill" , "Arbaugh)"@BBN.COM MMDF-Warning: Parse error in original version of preceding line at BBN.COM Message-Id: <9201061931.AA11820@tycho.ncsc.mil> To: clim@BBN.COM Subject: Redisplay of a changing (and growing) list I'm using: (Genera 8.1.1, Clim 27.5) Does anyone know how to use incremental redisplay with a list that not only will be changing (items exchanging places) but is also growing inside an application frame? For example, this works in a CLIM window (modified example from documentation): (defun test (stream) (let* ((list (list 1 2 3 4 5)) (record (updating-output (stream) (do* ((elements list (cdr elements)) (count 0 (1+ count)) (element (first elements)(first elements))) ((null elements)) (updating-output (stream :unique-id count :cache-value element) (format stream "Element ~D" element) (terpri stream)))))) (sleep 3) (setq list (append list (list 6))) (redisplay record stream) (setq list (append list (list 7))) (sleep 3) (redisplay record stream))) However when I modify it to "work" with an application frame, each new item appears but the old ones disappear! Here's the jest of the code: (define-application-frame test () ((pane-list :initform (list 1 2 3 4 5) :accessor pane-list) (pane-rec :accessor pane-rec)) ... (:panes ((display-pane :application :display-after-commands T :display-function 'draw-display :scroll-bars :vertical :end-of-page-action :scroll) ...)) ... ) ;; initialize the output record for our pane (defmethod run-frame-top-level :before ((frame test)) (with-slots (pane-list) frame (let ((stream (get-frame-pane frame 'display-pane))) (setf (pane-rec frame) (updating-output (stream) (do* ((elements (pane-list frame)(cdr elements)) (count 0 (1+ count)) (element (first elements)(first elements))) ((null elements)) (updating-output (stream :unique-id count :cache-value element) (format stream "Element ~D" element) (terpri stream)))))))) ;; the redisplay method for the pane (defmethod draw-display ((frame test) stream) (redisplay (pane-rec frame) stream)) ;; define a command to add items to the list (define-test-command (com-test :menu "test") () (with-slots (pane-list) *application-frame* (setf pane-list (append pane-list (list (accept 'integer)))))) I've tried several different variations of this all pretty much with the same effect. I did get one version to work (unacceptably), but that redisplayed each integer every time (Kind of defeats the purpose of redisplay). In that version, I created the output record in the draw-display method which correctly redisplays each element. Thanks for any help, Bill waarbau@tycho.ncsc.mil   Received: from BBN.COM by LABS-N.BBN.COM id aa25436; 6 Jan 92 16:40 EST Received: from att.att.com by BBN.COM id aa05721; 6 Jan 92 16:32 EST Received: from NSPP11.iexist.att.com by iexist.att.com (4.1/SMI-4.1) id AA18883; Mon, 6 Jan 92 14:48:58 CST Date: Mon, 6 Jan 1992 14:50-0600 From: "Lawrence G. Mayka" Subject: Redisplay of a changing (and growing) list To: waarbau@tycho.ncsc.mil Cc: clim@BBN.COM In-Reply-To: <9201061931.AA11820@tycho.ncsc.mil> Message-Id: <19920106205039.5.LGM@NSPP11.iexist.att.com> Date: Mon, 6 Jan 1992 13:31 CST From: "William (Bill" , "Arbaugh)"@BBN.COM Does anyone know how to use incremental redisplay with a list that not only will be changing (items exchanging places) but is also growing inside an application frame? For example, this works in a CLIM window (modified example from documentation): ... However when I modify it to "work" with an application frame, each new item appears but the old ones disappear! Here's the jest of the code: Hmm. Your symptom sounds a lot like one I'm looking into (also on Genera). If I run the example below in a CLIM Listener, the initial output of NOW IS should change into NOW HI-THERE, but instead becomes simply HI-THERE. (defun show-column (&optional (lst '(now is)) (stream *standard-output*)) (let ((record (clim:updating-output (stream) (clim:with-output-as-presentation (:stream stream :object lst) (clim:formatting-item-list (stream) (dolist (elem lst) (clim:formatting-cell (stream) (princ elem stream)))))))) (sleep 3) (setf lst (copy-list lst)) (setf (second lst) 'hi-there) (clim:redisplay record stream)) (values)) Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.   Received: from BBN.COM by LABS-N.BBN.COM id aa25423; 6 Jan 92 16:40 EST Received: from elroy.jpl.nasa.gov by BBN.COM id aa05688; 6 Jan 92 16:31 EST Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA00980; Mon, 6 Jan 92 13:31:30 PST Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA02145; Mon, 6 Jan 92 13:26:45 PST Date: Mon, 6 Jan 92 13:26:45 PST From: Curt Eggemeyer Message-Id: <9201062126.AA02145@eraserhead.Jpl.Nasa.Gov> To: clim@BBN.COM Subject: weird top-level accept problem for application frames Cc: cl-bugs@franz.com In my application frame I somethings get caught in a weird recursive type accept problem. Unfortunately, I haven't been able to reproduce this problem with a small example so let me describe the symptom. It may be related to me trying to type ahead to another command before the command already executing is done. It seems that somehow the top-level accept loop in the application frame sometimes starts in a deeper recursive call on accept when you enter top level commands for the application. It shows up after some commands have already been entered and executed on the application. Afterwards when I try and type in another application command as you type in the characters (including trying to do completion via the space bar) the cursor all of a sudden moves to another line in my interactor pane and continues to echo out the characters of the command. Only the accept now thinks that those characters entered on the new line are the beginning of a new command (from this point on the top-level accept loop in the application frame is screwed for keyboard input). So, if I try and rubout those characters I randomly get beeped and it ignores the rubout. However, if I do positioning of the cursor ala control characters the cursor sometimes jumps up to the original line and starts editing on that character string. From that point on the cursor randomly jumps back and forth between the two lines and never lets me successfully remove all of the characters in both lines. If I abort out of entering the command, from that point on the top-level accept will continually fail to accept my commands via the keyboard. Menu commands are still available and will echo correctly in the interactor pane, but any keying in of commands will now fail as described above. The only way for me to recover is to blow out the application frame and re-instantiate a whole new one. Another weird symptom is sometimes my interactor pane will lose the ability to echo characters out (including the command prompt) (I think the ink has somehow been flipped because I notice the cursor moving). I am on a monochrome SPARC system with CLIM 1.0. I do to two things different from your normal execution of an application frame. First, I have a simple around method on execute-frame-command (below) that echos the command done out to another application pane for my own history if it is just a top level command, otherwise I massage the last form "evaled" from the command's execution (which may be a totally different command). This I check works and shouldn't impact the command accept loop. (defmethod execute-frame-command :around ((SELF Plan-IT-2) command) (with-slots (Action-Pane Scripts) SELF (let ((strg (call-next-method SELF command))) (when strg (add-output-record Action-Pane (with-output-as-presentation (:stream Action-Pane :object (cond ((listp strg) (car strg)) (t command)) :type 'command :single-box t :allow-sensitive-inferiors nil) (format Action-Pane "~&~d) ~a" (Scripts-Count Scripts)` (cond ((listp strg) (cdr strg)) (t strg))))) (incf (Scripts-Count Scripts)))))) The other unique thing I do is I start my application frame with a process-run-function call to a function that checks to see if the application is not up yet and if so execute a run-frame-top-level to the application instance. Could there be some weird synchronization problems if you start an application from a separate process? 1) Has anybody had a similar problem? 2) Is there a way I can force my top-level accept loop to clear its buffer (totally) or get it back to normal without having to restart my application frame from scratch?   Received: from BBN.COM by LABS-N.BBN.COM id aa05982; 7 Jan 92 12:18 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa29056; 7 Jan 92 12:07 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 420132; 7 Jan 1992 12:06:59-0500 Date: Tue, 7 Jan 1992 12:06-0500 From: Scott McKay Subject: Redisplay of a changing (and growing) list To: waarbau@tycho.ncsc.mil cc: CLIM@BBN.COM In-Reply-To: <9201071328.AA12821@tycho.ncsc.mil> Message-ID: <19920107170625.7.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Tue, 7 Jan 1992 08:28 EST From: waarbau@tycho.ncsc.mil (William (Bill) A. Arbaugh) Here is more on Bill Arbaugh's question. Here's some "working" code (minus any possible typos :-). I didn't include it all originally as I have to type the code in by hand as this (tycho) is standalone. What I think is happening. Elements 1 - 5 get displayed on the INITIAL display of the frame. They immediately disappear (probably because the call to redisplay in draw-display). I remember things similiar to this in dw, and if I remember correctly the problem was typically related to the stream. (define-application-frame test () ((pane-list :initform (list 1 2 3 4 5) :accessor pane-list) (pane-rec :accessor pane-rec)) (:panes ((display-pane :application :display-after-commands T :display-function 'draw-display :scroll-bars :vertical :end-of-page-action :scroll) (interactor :interactor) (menu :command-menu))) (:layout ((normal (:column :rest (display-pane .7) (menu :compute) (interactor :rest)))))) ;; initialize the output record for our pane (defmethod run-frame-top-level :before ((frame test)) (with-slots (pane-list) frame (let ((stream (get-frame-pane frame 'display-pane))) (setf (pane-rec frame) (updating-output (stream) (do* ((elements (pane-list frame)(cdr elements)) (count 0 (1+ count)) (element (first elements)(first elements))) ((null elements)) (updating-output (stream :unique-id count :cache-value element) (format stream "Element ~D" element) (terpri stream)))))))) ;; the redisplay method for the pane (defmethod draw-display ((frame test) stream) (redisplay (pane-rec frame) stream)) ;; define a command to add items to the list (define-test-command (com-test :menu "test") () (with-slots (pane-list) *application-frame* (setf pane-list (append pane-list (list (accept 'integer)))))) Here is a working version of the program. I made DISPLAY-PANE be a real incremental redisplay pane, got rid of the :BEFORE method (since the initial redisplay will happen before the first command is read), and got rid of any explicit call to REDISPLAY (because the default CLIM command loop will do that for incremental redisplay panes). I also got rid of the PANE-REC slot from the frame; if it is important to be able to get your hands on the redisplay output record for the pane, the following idiom will work: (let ((redisplay-record (let ((history (output-recording-stream-output-record stream))) (when history ;; There should be only one output record in a pane that ;; uses :INCREMENTAL-REDISPLAY T (unless (zerop (output-record-element-count history)) (output-record-element history 0)))))) ...) -------- (define-application-frame test () ((pane-list :initform (list 1 2 3 4 5) :accessor pane-list)) (:panes ((display-pane :application :incremental-redisplay t :display-function 'draw-display :scroll-bars :vertical :end-of-page-action :scroll) (interactor :interactor) (menu :command-menu))) (:layout ((normal (:column :rest (display-pane .7) (menu :compute) (interactor :rest)))))) (defmethod draw-display ((frame test) stream) (with-slots (pane-list) frame (do* ((elements (pane-list frame)(cdr elements)) (count 0 (1+ count)) (element (first elements)(first elements))) ((null elements)) (updating-output (stream :unique-id count :cache-value element) (format stream "Element ~D" element) (terpri stream))))) (define-test-command (com-test :menu "test") () (with-slots (pane-list) *application-frame* (setf pane-list (append pane-list (list (accept 'integer))))))   Received: from BBN.COM by LABS-N.BBN.COM id aa07541; 7 Jan 92 14:26 EST Received: from dino.ils.nwu.edu by BBN.COM id aa07175; 7 Jan 92 14:20 EST Received: by dino.ils.nwu.edu.ils.nwu.edu (AIX 3.1/UCB 5.61/4.03) id AA17775; Tue, 7 Jan 92 13:20:22 -0600 Date: Tue, 7 Jan 92 13:20:22 -0600 From: Daniel Edelson Message-Id: <9201071920.AA17775@dino.ils.nwu.edu.ils.nwu.edu> To: clim@BBN.COM Subject: CLIM 2.0 specs I have seen several requests on this mailing list for information about the CLIM 2.0 specs but have never seen any responses. I can only assume that someone is maintaining a policy of keeping those specifications under wraps. Assuming this is correct, at what point can we expect the specs for CLIM 2.0 to become available for public review? Thanks. --------- Danny Edelson Institute for the Learning Sciences edelson@ils.nwu.edu Northwestern University (708) 491-3500 Evanston, IL 60201   Received: from BBN.COM by LABS-N.BBN.COM id aa09040; 7 Jan 92 16:12 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa13424; 7 Jan 92 16:07 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 420151; 7 Jan 1992 16:07:04-0500 Date: Tue, 7 Jan 1992 16:06-0500 From: Scott McKay Subject: CLIM 2.0 specs To: edelson%dino.ils.nwu.edu.ils.nwu.edu@BBN.COM, edelson@dino.ils.nwu.edu, clim@BBN.COM In-Reply-To: <9201071920.AA17775@dino.ils.nwu.edu.ils.nwu.edu> Supersedes: <19920107210529.2.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Message-ID: <19920107210630.3.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Tue, 7 Jan 1992 14:20 EST From: Daniel Edelson I have seen several requests on this mailing list for information about the CLIM 2.0 specs but have never seen any responses. I can only assume that someone is maintaining a policy of keeping those specifications under wraps. There is no policy for keeping the spec under wraps. It has quite simply not been released, for mostly stupid reasons, which I will avoid elaborating on. Assuming this is correct, at what point can we expect the specs for CLIM 2.0 to become available for public review? I had hoped to see a public draft released on October 1, 1991. I hope to see a public draft released "soon". By the way, I suspect that "public review" of the spec may carry less weight for CLIM than some people might hope. That is, much of the design is complete and pretty much frozen (for schedule, manpower, and compatibility reasons). For CLIM 2.0, most feature requests will probably be turned down, suggestions for sweeping changes will be rejected, and even gratuitous minor changes will not be accepted. This does not mean that CLIM users will not be listened to - in fact, many of your bug reports, suggestions, etc., have already made important contributions to the CLIM 2.0 draft specification. The main issue is one of schedule: the vendors involved feel that we must get CLIM 2.0 into the field, and that the best possible feedback will come from people using it in conjunction with reading the spec. CLIM 2.1 (or whatever the successor to CLIM 2.0 is) incorporate a substantial amount of customer feedback.   Received: from BBN.COM by LABS-N.BBN.COM id aa09324; 7 Jan 92 16:44 EST Received: from FUJI.ILA.COM by BBN.COM id aa15732; 7 Jan 92 16:40 EST Received: from BUGS-BUNNY.ILA.COM by FUJI.ILA.COM via CHAOS with CHAOS-MAIL id 303377; Tue 7-Jan-92 16:45:32 EST Date: Tue, 7 Jan 1992 16:36-0500 From: mas-b@fuji.ila.com MMDF-Warning: Parse error in original version of preceding line at BBN.COM Subject: CLIM 2.0 specs To: edelson%dino.ils.nwu.edu.ils.nwu.edu@BBN.COM, clim@BBN.COM In-Reply-To: <9201071920.AA17775@dino.ils.nwu.edu.ils.nwu.edu> Message-ID: <"19920107213638.5.mas-b@FUJI"@BUGS-BUNNY.ILA.COM> Date: Tue, 7 Jan 1992 14:20 EST From: Daniel Edelson I have seen several requests on this mailing list for information about the CLIM 2.0 specs but have never seen any responses. I can only assume that someone is maintaining a policy of keeping those specifications under wraps. No - they're just not done yet. CLIM 2.0 is a fusion of the two existing CLIM dialects (CLIM 1.0 aka "Y-Windows" and CLIM 0.9 aka "Silica CLIM"). The fusion is being done by ILA (the original authors of both dialects) and Symbolics (the principal productizers of CLIM 1.0), and "should be ready soon." As soon as it is, it'll be made public. Assuming this is correct, at what point can we expect the specs for CLIM 2.0 to become available for public review? At LUV'91, we thought (and I said) that it would be out by the end of November last. Keeping that prognosticatorial track record in mind, we now think it'll be by the end of January. Thanks. --------- Danny Edelson Institute for the Learning Sciences edelson@ils.nwu.edu Northwestern University (708) 491-3500 Evanston, IL 60201 Mark Son-Bell ILA mas-b@ila.com 617/576-1151   Received: from BBN.COM by LABS-N.BBN.COM id aa09028; 7 Jan 92 16:11 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa13319; 7 Jan 92 16:06 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 420149; 7 Jan 1992 16:06:05-0500 Date: Tue, 7 Jan 1992 16:05-0500 From: Scott McKay Subject: CLIM 2.0 specs To: edelson%dino.ils.nwu.edu.ils.nwu.edu@BBN.COM, clim@BBN.COM In-Reply-To: <9201071920.AA17775@dino.ils.nwu.edu.ils.nwu.edu> Message-ID: <19920107210529.2.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Tue, 7 Jan 1992 14:20 EST From: Daniel Edelson I have seen several requests on this mailing list for information about the CLIM 2.0 specs but have never seen any responses. I can only assume that someone is maintaining a policy of keeping those specifications under wraps. There is no policy for keeping the spec under wraps. It has quite simply not been released, for mostly stupid reasons, which I will avoid elaborating on. Assuming this is correct, at what point can we expect the specs for CLIM 2.0 to become available for public review? I had hoped to see a public draft released on October 1, 1991. I hope to see a public draft released "soon". By the way, I suspect that "public review" of the spec may carry less weight for CLIM than some people might hope. That is, much of the design is complete and pretty much frozen (for schedule, manpower, and compatibility reasons). For CLIM 2.0, most feature requests will probably be turned down, suggestions for sweeping changes will be rejected, and even gratuitous minor changes will not be accepted. This does not mean that CLIM users will not be listened to - in fact, many of your bug reports, suggestions, etc., have already made important contributions to the CLIM 2.0 draft specification. The main issue is one of schedule: the vendors involved feel that we must get CLIM 2.0 into the field, and that the best possible feedback will come from people using it in conjunction with reading the spec. CLIM 2.1 (or whatever the successor to CLIM 2.0 is) incorporate a substantial amount of customer feedback.   Received: from BBN.COM by LABS-N.BBN.COM id aa10343; 7 Jan 92 18:13 EST Received: from TYCHO.NCSC.MIL by BBN.COM id aa20672; 7 Jan 92 18:10 EST Received: by tycho.ncsc.mil (4.1/SMI-4.1) id AA14304; Tue, 7 Jan 92 17:48:43 EST Date: Tue, 7 Jan 92 17:48:43 EST From: "William (Bill" , "Arbaugh)"@BBN.COM MMDF-Warning: Parse error in original version of preceding line at BBN.COM Message-Id: <9201072248.AA14304@tycho.ncsc.mil> To: SWM@sapsucker.scrc.symbolics.com Cc: CLIM@BBN.COM In-Reply-To: Scott McKay's message of Tue, 7 Jan 1992 12:06-0500 <19920107170625.7.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Subject: Redisplay of a changing (and growing) list Thanks Scott for straightening out my problem! I didn't realize that by setting :incremental-redisplay T automatically created my output record for me. Thanks again, Bill   Received: from BBN.COM by LABS-N.BBN.COM id aa17534; 8 Jan 92 9:11 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa24124; 8 Jan 92 9:06 EST Received: from FELDBERG.SGER.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 647756; 8 Jan 1992 09:04:38-0500 Received: from FUJI-SAN.SGER.Dialnet.Symbolics.COM by FELDBERG.SGER.Dialnet.Symbolics.COM via INTERNET with SMTP id 31224; 7 Jan 92 13:12:19+0200 Date: Tue, 7 Jan 1992 13:12+0200 From: Markus Fischer Subject: Redisplay of a changing (and growing) list To: lgm%iexist.att.com@riverside.scrc.symbolics.com, waarbau%tycho.ncsc.mil@riverside.scrc.symbolics.com cc: clim%BBN.COM@riverside.scrc.symbolics.com In-Reply-To: <19920106205039.5.LGM@NSPP11.iexist.att.com> Message-ID: <19920107111212.1.MF@FUJI-SAN.SGER.Dialnet.Symbolics.COM> Date: Mon, 6 Jan 1992 22:50+0200 From: "Lawrence G. Mayka" Date: Mon, 6 Jan 1992 13:31 CST From: "William (Bill" , "Arbaugh)"@BBN.COM Does anyone know how to use incremental redisplay with a list that not only will be changing (items exchanging places) but is also growing inside an application frame? For example, this works in a CLIM window (modified example from documentation): ... However when I modify it to "work" with an application frame, each new item appears but the old ones disappear! Here's the jest of the code: Hmm. Your symptom sounds a lot like one I'm looking into (also on Genera). If I run the example below in a CLIM Listener, the initial output of NOW IS should change into NOW HI-THERE, but instead becomes simply HI-THERE. (defun show-column (&optional (lst '(now is)) (stream *standard-output*)) (let ((record (clim:updating-output (stream) (clim:with-output-as-presentation (:stream stream :object lst) (clim:formatting-item-list (stream) (dolist (elem lst) (clim:formatting-cell (stream) (princ elem stream)))))))) (sleep 3) (setf lst (copy-list lst)) (setf (second lst) 'hi-there) (clim:redisplay record stream)) (values)) Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer. I will try to reply to William (Bill's mail separately, however here's the answer to the problematic code of Lawrence: You simply forgot to provide an updating-output with a cache value. The outermost clim:updating-output (stream) is only there to give you one output record to which you can send the clim:redisplay message. But every piece of output that should be separately redisplayed (because of the changes that might happened to the data structure that is visualized) must be surrounded by an explicit updating-output. The code that follows corrects this: (changes are in upper case) (defun show-column (&optional (lst '(now is)) (stream *standard-output*)) (let ((record (clim:updating-output (stream) (clim:with-output-as-presentation (:stream stream :object lst) (clim:formatting-item-list (stream) (dolist (elem lst) (UPDATING-OUTPUT (STREAM :CACHE-VALUE ELEM :CACHE-TEST #'EQUAL) (clim:formatting-cell (stream) (princ elem stream))))))))) (sleep 3) (setf lst (copy-list lst)) (setf (second lst) 'hi-there) (clim:redisplay record stream)) (values)) Unfortunately, the documentation about Incremental Redisplay is pretty incomplete. Markus Fischer Consulting Services Symbolics Systemhaus GmbH Mergenthaler Allee 77-81 6236 Eschborn West Germany Tel (from the US): 011-6196-47220   Received: from BBN.COM by LABS-N.BBN.COM id aa19900; 8 Jan 92 11:48 EST Received: from aristotle.ils.nwu.edu by BBN.COM id aa04139; 8 Jan 92 11:43 EST Received: by aristotle.ils.nwu.edu (4.0/SMI-ACNS-1.04) id AA26940; Wed, 8 Jan 92 10:41:19 CST Date: Wed, 8 Jan 92 10:41:19 CST From: Kenneth Forbus Message-Id: <9201081641.AA26940@aristotle.ils.nwu.edu> To: clim@BBN.COM Cc: forbus@aristotle.ils.nwu.edu Subject: Moral equivalent of clim::pprint needed Subject line says it all. I have some lisp expressions that need to be ground into a scroll window, respecting the width of the visible part so that I don't have to scroll to see the entire expression. I've tried the obvious, namely including the stream corresponding to the window as the stream argument to pprint, and in Lucid CL on the RS/6000, it blows out claiming that the object involved isn't a stream. Yet that is what our other routines print to. Any ideas? Ken ========================================== Prof. Kenneth D. Forbus Qualitative Reasoning Group The Institute for the Learning Sciences Northwestern University 1890 Maple Avenue Evanston, Illinois, 60201, USA email: forbus@ils.nwu.edu voice: (708) 491-7699 fax: (708) 491-5258 ==========================================   Received: from BBN.COM by LABS-N.BBN.COM id aa20664; 8 Jan 92 12:34 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa06830; 8 Jan 92 12:27 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 420202; 8 Jan 1992 12:27:24-0500 Date: Wed, 8 Jan 1992 12:26-0500 From: Scott McKay Subject: Formatting graphs. To: chee@isi.edu, SWM@sapsucker.scrc.symbolics.com cc: CLIM@BBN.COM In-Reply-To: <9201080803.AA11231@sunstruck.isi.edu> Message-ID: <19920108172651.1.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Wed, 8 Jan 1992 03:03 EST From: chee@ISI.EDU Hi, Got a couple of questions about the graphing functions in CLIM. o Is the current FORMATING-GRAPH-FROM-ROOT incapable of graphing lattice? Eg., in the provided eg., can the function produce a graph of the form; 2A / 1A< / \ 0< >2B \ / 1B< \ 2C CLIM 1.0 is not capable of graphing DAGs, only trees. I recently installed into CLIM 1.0 a new grapher based on some earlier work by John Aspinall that handles both trees and DAGs. It detects circularities to the extent that it does not go into an infinite loop, but does not correctly graph them. o What new functionality will be available in CLIM 2.0? I would like the functionality that came with Dynamic windows, ie., access to functions to control how edges are drawn (eg., dotted lines, using CONNECT-GRAPH-NODE (?)), different topology, etc. Any chance of making the edges mouse sensitive? The new grapher takes both :ARC-DRAWER and :ARC-DRAWING-OPTIONS keywords. The default arc drawer is effectively CLIM:DRAW-LINE*. You would specify :ARC-DRAWING-OPTIONS '(:DASHES T) to get a dashed arc. You can specify your own arc drawer that uses WITH-OUTPUT-AS-PRESENTATION to make the arcs mouse-sensitive. Another new option is :GRAPH-TYPE, which allows you to specify what kind of graph should be drawn. The new grapher supports :TREE (which is what the old grapher does), and :DIRECTED-GRAPH (or :DIGRAPH) and :DIRECTED-ACYCLIC-GRAPH (or :DAG). Currently :DIGRAPH and :DAG do the same thing. I think that the way the new grapher is designed obviates the need for an explicit CONNECT-GRAPH-NODE function. I have ported all of the previous programs I know of that use CONNECT-GRAPH-NODE to CLIM, and have not needed it yet. This new grapher will be part of CLIM 2.0, but will probably be no more sophisticated than I have described. For such high-level utilities as this, we feel that it is better to provide simple facilities that can be extended. The draft CLIM 2.0 spec exposes the graph formatting protocols so that you can extend the grapher to use your own layout algorithms.   Received: from BBN.COM by LABS-N.BBN.COM id aa21093; 8 Jan 92 13:09 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa08761; 8 Jan 92 13:04 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 420205; 8 Jan 1992 13:03:44-0500 Date: Wed, 8 Jan 1992 13:03-0500 From: Scott McKay Subject: Moral equivalent of clim::pprint needed To: forbus@aristotle.ils.nwu.edu, clim@BBN.COM In-Reply-To: <9201081641.AA26940@aristotle.ils.nwu.edu> Message-ID: <19920108180314.2.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Wed, 8 Jan 1992 11:41 EST From: Kenneth Forbus Subject line says it all. I have some lisp expressions that need to be ground into a scroll window, respecting the width of the visible part so that I don't have to scroll to see the entire expression. I've tried the obvious, namely including the stream corresponding to the window as the stream argument to pprint, and in Lucid CL on the RS/6000, it blows out claiming that the object involved isn't a stream. Yet that is what our other routines print to. Any ideas? I think you will have to bring it up directly with Lucid softare support. At the very least, Lucid's PPRINT should not blow out, even if it does not do as well as PPRINT does under Dynamic Windows on Genera. The best solution is to have CLIM:PPRINT shadow LISP:PPRINT and do something interesting involving creating EXPRESSION presentations, but I don't imagine that will happen any time in the near future unless some vendor volunteers to do that work. I myself can't volunteer to do it.   Received: from BBN.COM by LABS-N.BBN.COM id aa21521; 8 Jan 92 13:46 EST Received: from lucid.com by BBN.COM id aa10742; 8 Jan 92 13:38 EST Received: from edsel (edsel.lucid.com) by heavens-gate.lucid.com id AA10403g; Wed, 8 Jan 92 10:33:58 PST Received: from kuwait.lucid by edsel id AA04238g; Wed, 8 Jan 92 10:31:56 PST Received: by kuwait.lucid (4.1/SMI-4.1) id AA01733; Wed, 8 Jan 92 10:36:21 PST Date: Wed, 8 Jan 92 10:36:21 PST From: John Kern Message-Id: <9201081836.AA01733@kuwait.lucid> To: pkarp@ai.sri.com Cc: SWM@sapsucker.scrc.symbolics.com, clim@BBN.COM, clim-support@lucid.com In-Reply-To: Peter Karp's message of Wed, 1 Jan 92 8:55:43 PST Subject: Anybody else hitting completion errors on accept? Reply-To: clim-support@lucid.com Howdy Mr. Karp, Thanks for pointing this out. Indeed, there is a problem with the version of CLX we are using which prevents the meta key from functioning properly. I'll send you a patch. Sincerely, John S. Kern Lucid, Inc.   Received: from BBN.COM by LABS-N.BBN.COM id aa25159; 8 Jan 92 18:24 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa29686; 8 Jan 92 18:18 EST Received: from FELDBERG.SGER.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 647962; 8 Jan 1992 18:15:31-0500 Received: from FUJI-SAN.SGER.Dialnet.Symbolics.COM by FELDBERG.SGER.Dialnet.Symbolics.COM via INTERNET with SMTP id 31226; 7 Jan 92 13:57:24+0200 Date: Tue, 7 Jan 1992 13:57+0200 From: Markus Fischer Subject: Redisplay of a changing (and growing) list To: waarbau%tycho.ncsc.mil@riverside.scrc.symbolics.com, clim%BBN.COM@riverside.scrc.symbolics.com In-Reply-To: <9201061931.AA11820@tycho.ncsc.mil> Message-ID: <19920107115717.3.MF@FUJI-SAN.SGER.Dialnet.Symbolics.COM> Date: Mon, 6 Jan 1992 21:31+0200 From: "William (Bill" , "Arbaugh)"@BBN.COM I'm using: (Genera 8.1.1, Clim 27.5) Does anyone know how to use incremental redisplay with a list that not only will be changing (items exchanging places) but is also growing inside an application frame? For example, this works in a CLIM window (modified example from documentation): (defun test (stream) (let* ((list (list 1 2 3 4 5)) (record (updating-output (stream) (do* ((elements list (cdr elements)) (count 0 (1+ count)) (element (first elements)(first elements))) ((null elements)) (updating-output (stream :unique-id count :cache-value element) (format stream "Element ~D" element) (terpri stream)))))) (sleep 3) (setq list (append list (list 6))) (redisplay record stream) (setq list (append list (list 7))) (sleep 3) (redisplay record stream))) However when I modify it to "work" with an application frame, each new item appears but the old ones disappear! Here's the jest of the code: (define-application-frame test () ((pane-list :initform (list 1 2 3 4 5) :accessor pane-list) (pane-rec :accessor pane-rec)) ... (:panes ((display-pane :application :display-after-commands T :display-function 'draw-display :scroll-bars :vertical :end-of-page-action :scroll) ...)) ... ) ;; initialize the output record for our pane (defmethod run-frame-top-level :before ((frame test)) (with-slots (pane-list) frame (let ((stream (get-frame-pane frame 'display-pane))) (setf (pane-rec frame) (updating-output (stream) (do* ((elements (pane-list frame)(cdr elements)) (count 0 (1+ count)) (element (first elements)(first elements))) ((null elements)) e test) stream) (redisplay (pane-rec frame) stream)) ;; define a command to add items to the list (define-test-command (com-test :menu "test") () (with-slots (pane-list) *application-frame* (setf pane-list (append pane-list (list (accept 'integer)))))) I've tried several different variations of this all pretty much with the same effect. I did get one version to work (unacceptably), but that redisplayed each integer every time (Kind of defeats the purpose of redisplay). In that version, I created the output record in the draw-display method which correctly redisplays each element. Thanks for any help, Bill waarbau@tycho.ncsc.mil You have some understanding problems about Incremental Redisplay, like Lawrence does, possibly due to the not very good documentation about this topic. However, your code is not executable due to another problem, too: it is just incomplete yanked: I think quite a few lines of code are just omitted in the run-frame-top-level :before method! I took the time to reconstruct and correct it anyway: Here`s the result: (define-application-frame test () ((pane-list :initform (list 1 2 3 4 5) :accessor pane-list) (pane-rec :accessor pane-rec)) (:panes ((display-pane :application :display-after-commands T :DISPLAY-FUNCTION 'DRAW-DISPLAY :INCREMENTAL-REDISPLAY T :scroll-bars :vertical :end-of-page-action :scroll) (interactor :interactor))) (:layout ((one (:column 1 (display-pane :compute) (interactor :compute)))))) (define-genera-application test :select-key #\!) (defmethod draw-display ((frame test) stream) (do* ((elements (pane-list frame) (cdr elements)) (count 0 (1+ count)) (element (first elements)(first elements))) ((null elements)) (UPDATING-OUTPUT (STREAM :CACHE-VALUE ELEMENT :CACHE-TEST #'EQUAL :UNIQUE-ID COUNT :ID-TEST #'=) (FORMAT STREAM "~A" ELEMENT)))) ;; define a command to add items to the list (define-test-command (com-test :name T :menu "test") () (with-slots (pane-list) *application-frame* (setf pane-list (append pane-list (list (accept 'integer)))))) Several comments about that: 1) if you specify :INCREMENTAL-REDISPLAY T for a pane, CLIM automatically captures all output done to this stream within a top-level updating-output. You don't have to do this anymore. So to cope with run-frame-top-level is unnecessary for this purpose. 2) if you provide :display-after-commands T and :INCREMENTAL-REDISPLAY T a redisplay is done to that stream after every command. I guess that's the thing you want to do. 3) (style issue only) I find LOOP a very convenient tool to use instead of do, do*, dolist etc. 4) with define-genera-application you have also a quite convenient tool to automatically generate and run frames Markus Fischer Consulting Services Symbolics Systemhaus GmbH Mergenthaler Allee 77-81 6236 Eschborn West Germany Tel (from the US): 011-6196-47220   Received: from BBN.COM by LABS-N.BBN.COM id aa24980; 8 Jan 92 17:59 EST Received: from att.att.com by BBN.COM id aa28226; 8 Jan 92 17:52 EST From: lgm@iexist.att.com Received: from NSPP11.iexist.att.com by iexist.att.com (4.1/SMI-4.1) id AA22827; Wed, 8 Jan 92 16:42:37 CST Date: Wed, 8 Jan 1992 16:44-0600 Original-From: Lawrence G. Mayka Subject: Redisplay of a changing (and growing) list To: FELDBERG.SGER.Dialnet.Symbolics.COM!mf@iexist.att.com Cc: iexist!att!bbn.com!clim@iexist.att.com In-Reply-To: <19920107111212.1.MF@FUJI-SAN.SGER.Dialnet.Symbolics.COM> Message-Id: <19920108224437.6.LGM@NSPP11.iexist.att.com> Date: Tue, 7 Jan 1992 05:12 CST From: Markus Fischer You simply forgot to provide an updating-output with a cache value. The outermost clim:updating-output (stream) is only there to give you one output record to which you can send the clim:redisplay message. But every piece of output that should be separately redisplayed (because of the changes that might happened to the data structure that is visualized) must be surrounded by an explicit updating-output. The code that follows corrects this: (changes are in upper case) (defun show-column (&optional (lst '(now is)) (stream *standard-output*)) (let ((record (clim:updating-output (stream) (clim:with-output-as-presentation (:stream stream :object lst) (clim:formatting-item-list (stream) (dolist (elem lst) (UPDATING-OUTPUT (STREAM :CACHE-VALUE ELEM :CACHE-TEST #'EQUAL) (clim:formatting-cell (stream) (princ elem stream))))))))) (sleep 3) (setf lst (copy-list lst)) (setf (second lst) 'hi-there) (clim:redisplay record stream)) (values)) The good news is that with your modification, the code works perfectly. The bad news is that I don't understand your explanation. Omission of CLIM:UPDATING-OUTPUT, as I understand it, should not cause erasure of one (and not the other!) line of output; on the contrary, omission of CLIM:UPDATING-OUTPUT should force reprinting of all the lines of output. Perhaps a better example of my problem is the following: (defun show-column (&optional (lst '(now is)) (stream *standard-output*)) (let ((record (clim:updating-output (stream) (clim:with-output-as-presentation (:stream stream :object lst) (clim:formatting-item-list (stream) (dolist (elem lst) (clim:formatting-cell (stream) (clim:updating-output (stream :cache-value elem :cache-test #'equal) (princ elem stream))))))))) (sleep 3) (setf lst (copy-list lst)) (setf (second lst) 'hi-there) (clim:redisplay record stream)) (values)) This example, which exhibits the same problem I reported earlier, is identical to your correctly working version except that the order of CLIM:FORMATTING-CELL and CLIM:UPDATING-OUTPUT is reversed. Why does that make a difference? What are the ordering rules for CLIM constructs? Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.   Received: from BBN.COM by LABS-N.BBN.COM id aa25608; 8 Jan 92 19:06 EST Received: from att.att.com by BBN.COM id aa02267; 8 Jan 92 19:02 EST From: att!SAPSUCKER.SCRC.Symbolics.COM!SWM@iexist.att.com Received: from att.UUCP by iexist.att.com (4.1/SMI-4.1) id AA26539; Wed, 8 Jan 92 18:53:53 EST Received: by att.att.com; Wed Jan 8 18:52:30 EST 1992 Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 420243; 8 Jan 1992 18:52:35-0500 Date: Wed, 8 Jan 1992 18:51-0500 Original-From: Scott McKay Subject: Redisplay of a changing (and growing) list To: iexist!lgm@iexist.att.com, iexist!FELDBERG.SGER.Dialnet.Symbolics.COM!mf@iexist.att.com Cc: iexist!iexist!att!bbn.com!clim@iexist.att.com In-Reply-To: <19920108224437.6.LGM@NSPP11.iexist.att.com> Message-Id: <19920108235158.9.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Wed, 8 Jan 1992 17:44 EST From: lgm@iexist.att.com This example, which exhibits the same problem I reported earlier, is identical to your correctly working version except that the order of CLIM:FORMATTING-CELL and CLIM:UPDATING-OUTPUT is reversed. Why does that make a difference? What are the ordering rules for CLIM constructs? The ordering rule is that UPDATING-OUTPUT should go outside of the atomic thing you wish to update. In the current implementation of table formatting (and in DW, for that matter), you should think of FORMATTING-CELL as atomic. Thus, UPDATING-OUTPUT should go outside of it.   Received: from BBN.COM by LABS-N.bbn.COM id aa10274; 9 Jan 92 21:03 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa22059; 9 Jan 92 20:53 EST Received: from FELDBERG.SGER.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 648409; 9 Jan 1992 20:51:49-0500 Received: from FUJI-SAN.SGER.Dialnet.Symbolics.COM by FELDBERG.SGER.Dialnet.Symbolics.COM via INTERNET with SMTP id 31230; 8 Jan 92 12:52:28+0200 Date: Wed, 8 Jan 1992 12:52+0200 From: Markus Fischer Subject: Sorting Command Menus To: clim%bbn.com@riverside.scrc.symbolics.com Message-ID: <19920108105218.5.MF@FUJI-SAN.SGER.Dialnet.Symbolics.COM> I think that a few weeks ago someone asked for a facility to sort the menu items of command tables, and furthermore, I believe that SWM answered that there isn't any predefined CLIM function for this purpose. However, I now have an application where there are command tables with up to about 10 menu items in it. From the software ergonomics' point of view, it is absolutely necessary to have the possibility to group or sort items in a menu. So I decided to write one myself, which I publish here for everyone. Please note, though, that this code is NOT tested for all cases, but instead only for the specific case of my applications; just take it as a basis for your ideas. (defun sort-command-table-menu-items (command-table sorting-predicate &optional (sorting-key #'identity)) "removes all menu items and re-inserts them in a sorted way" (let ((menu-items NIL)) (map-over-command-table-menu-items #'(lambda (menu-item-name keystroke type-and-value) ;; create a list that can be used as argument list to add-menu-item-to-command-table (push (list menu-item-name (first type-and-value) (second type-and-value) :keystroke keystroke) menu-items)) command-table) (setq menu-items (sort menu-items sorting-predicate :key #'(lambda (menu-item-description) (funcall sorting-key (first menu-item-description))))) (dolist (menu-item-description menu-items) (remove-menu-item-from-command-table command-table (first menu-item-description)) (apply 'add-menu-item-to-command-table command-table menu-item-description)))) an example call: (sort-command-table-menu-items 'foo 'string-lessp) when foo is the name of a command table in the current package. The code only works, if CLIM ensures that the order of command menu item adding is also the order to appear in the menu. This behavior is not documented, but I think it is rather obvious. Markus Fischer Consulting Services Symbolics Systemhaus GmbH Mergenthaler Allee 77-81 6236 Eschborn West Germany Tel (from the US): 011-6196-47220   Received: from BBN.COM by LABS-N.bbn.COM id aa10962; 9 Jan 92 23:33 EST Received: from Sunset.AI.SRI.COM by BBN.COM id aa04523; 9 Jan 92 23:29 EST Received: from Rockaway.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA12512 for clim@bbn.com; Thu, 9 Jan 92 20:30:07 PST Received: by Rockaway.AI.SRI.COM (4.1/SMI-4.1) id AA15471 for clim@bbn.com; Thu, 9 Jan 92 20:30:07 PST Date: Thu, 9 Jan 92 20:30:07 PST From: Peter Karp To: clim@BBN.COM Subject: New version of CTV-MENU Message-Id: A new version of the CTV-MENU package is available for anonymous FTP from SRI. This package provides CLIM emulation of various Symbolics TV-package menu functions, such as choose-variable-values. This new version contains a number of small bug fixes and enhancements. The most significant enhancement is the addition of a new function that uses a choose-variable-values style dialog window to allow a user to change the slot values of an instance of any CLOS class. FTP all files from directory pub/pkarp/lisp/ctv-menu of host ai.sri.com. Peter   Received: from BBN.COM by LABS-N.BBN.COM id aa01171; 16 Jan 92 13:11 EST Received: from p.lanl.gov by BBN.COM id aa07552; 16 Jan 92 12:46 EST Received: from zaphod.lanl.gov by p.lanl.gov (5.65/1.14) id AA26823; Thu, 16 Jan 92 10:46:42 -0700 Received: by zaphod.lanl.gov.lanl.gov (4.1/SMI-4.1) id AA02811; Thu, 16 Jan 92 10:46:45 MST Date: Thu, 16 Jan 92 10:46:45 MST From: Skip Egdorf Message-Id: <9201161746.AA02811@zaphod.lanl.gov.lanl.gov> To: clim@BBN.COM Subject: Graceful shutdown and restart of CLIM For those of you who read usenet - comp.lang.lisp; I recently posted a request similar to this one there regarding doing the same thing with Lispview... --- I would like to have a developers interface in CLIM which includes a "save" function that does an image save. The saved image, when run, should recreate the CLIM interface. The CLIM interface is to be the only interface to the system. The documentation says little or nothing about how to gracefully shut down CLIM (e.g. disconnect from the X server on a Sun) and then, after an image is saved and then run, direct some restart function to restart the interface. I run Lisp and CLIM in several environments. While each has its own unique method for saving lisp images, (e.g. disksave on Lucid, save-application on MCL) I would like to insulate the user/developers who will be adding code to my base system from the system specifics of image saving. I would like to use CLIM to allow a user to load additional code into the system, and then save the new, extended application built from my base. When this new application is run, the CLIM interface should restart. The user will use CLIM rather than the base lisp listener. Thus, I would like to build a single environment that will handle the following. Any suggestions for graceful shutdown, image-save, and restart in the following environments (even those marked "not an issue") would be appreciated. 1. Sparc Lucid (development, delivery) - Disksave The "save" facility is particularly needed in this environment. 2. Mac MCL 2.0 (development, delivery) - save-application The "save" facility is particularly needed in this environment. 3. Sparc, Allegro (development, delivery) - ? Allegro is just being purchased. Now that Sun Common Lisp no longer exists, I want to be portable to both of the players on the now level playing field. The "save" facility will be used in this environment when it arrives. 4. Symbolics Genera (development) Not really an issue. The symbolics is used for base development by users who can handle the issues. The end-users and more casual developers for whom the "save" facility is desired do not operate in this environment. 5. Symbolics CLOE development (development) Not an issue. 6. MS-DOS CLOE (delivery) Not an issue. But it would be nice if it were... CLOE currently does not allow image saves from the CLIM/Windows environment. 7. MS-DOS Gold Hill GCLisp (development? delivery?) We have a GCLisp on order, but they do not yet have a CLIM. When they have a CLOS/CLIM I intend to port to this as well. 8. Any other Common Lisp / CLOS / CLIM environments out there I should be considering? Skip Egdorf hwe@lanl.gov   Received: from BBN.COM by LABS-N.BBN.COM id aa03343; 16 Jan 92 15:54 EST Received: from lucid.com by BBN.COM id aa17737; 16 Jan 92 15:46 EST Received: from edsel (edsel.lucid.com) by heavens-gate.lucid.com id AA10669g; Thu, 16 Jan 92 12:40:27 PST Received: from kuwait.lucid by edsel id AA29044g; Thu, 16 Jan 92 12:33:42 PST Received: by kuwait.lucid (4.1/SMI-4.1) id AA02338; Thu, 16 Jan 92 12:38:53 PST Date: Thu, 16 Jan 92 12:38:53 PST From: John Kern Message-Id: <9201162038.AA02338@kuwait.lucid> To: egdorf@zaphod.lanl.gov Cc: clim@BBN.COM, clim-support@lucid.com In-Reply-To: Skip Egdorf's message of Thu, 16 Jan 92 10:46:45 MST <9201161746.AA02811@zaphod.lanl.gov.lanl.gov> Subject: Graceful shutdown and restart of CLIM Reply-To: clim-suport@lucid.com Howdy Mr. Egdorf, >I would like to have a developers interface in CLIM which includes >a "save" function that does an image save. The saved image, when >run, should recreate the CLIM interface. The CLIM interface is to >be the only interface to the system. >1. Sparc Lucid (development, delivery) - Disksave > The "save" facility is particularly needed in this environment. To save an image that will restart an application using Lucid Common Lisp(LCL), use the :restart-function keyword to disksave. To quit out of LCL completely you might try something like: (define-to-do-command (com-quit-to-do :menu "Quit") () (let ((ftlw (frame-top-level-window *application-frame*))) (setf (window-visibility ftlw) nil) (force-output ftlw)) (frame-exit *application-frame*) (lcl:quit)) If the user clicks on this menu item, the lisp process will terminate and the user will be left at the unix prompt. Sincerely, John Kern Lucid, Inc. Customer Support PS If you have further questions that are specific to the Lucid implementation of CLIM, contact us at clim-support@lucid.com   Received: from BBN.COM by LABS-N.BBN.COM id aa16965; 17 Jan 92 16:37 EST Received: from YUKON.SCRC.Symbolics.COM by BBN.COM id aa05896; 17 Jan 92 16:28 EST Received: from BLUE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via INTERNET with SMTP id 763045; 17 Jan 1992 16:28:00-0500 Date: Fri, 17 Jan 1992 16:27-0500 From: Kyle Richards Subject: CLIM Course To: CLIM@BBN.COM cc: richards@yukon.scrc.symbolics.com Message-ID: <19920117212739.9.RICHARDS@BLUE-BIRD.SCRC.Symbolics.COM> Symbolics Education Services is thinking about offering an advanced CLIM course this spring. If you want to be on our mailing list for information please send your address to: Education-Services@Riverside.SCRC.Symbolics.COM   Received: from BBN.COM by LABS-N.BBN.COM id aa18481; 17 Jan 92 19:20 EST Received: from elroy.jpl.nasa.gov by BBN.COM id aa15616; 17 Jan 92 19:15 EST Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA29860; Fri, 17 Jan 92 16:15:03 PST Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA03739; Fri, 17 Jan 92 16:10:12 PST Date: Fri, 17 Jan 92 16:10:12 PST From: Curt Eggemeyer Message-Id: <9201180010.AA03739@eraserhead.Jpl.Nasa.Gov> To: clim@BBN.COM Subject: Accepting-values quickie question Can you call accepting-values within accepting-values? If so there anything special I have to worry about? ie: (accepting-values (stream) (accept ...) (terpri stream) (accepting-values (stream) (accept ...) ... more accepts )   Received: from BBN.COM by LABS-N.BBN.COM id aa03643; 19 Jan 92 16:32 EST Received: from iraun1.ira.uka.de by BBN.COM id aa16891; 18 Jan 92 12:50 EST Received: from gate.fzi.de by iraun1.ira.uka.de id aa00725; 18 Jan 92 13:43 MET Received: from ossi.fzi.de by gate.fzi.de.fzi.de id aa08230; 18 Jan 92 12:45 GMT Date: Sat, 18 Jan 92 12:46:47 GMT From: Ralf Nikolai To: jga@scrc.symbolics.com MMDF-Warning: Unable to confirm address in preceding line at iraun1.ira.uka.de cc: clim@bbn.com Subject: circle-segments Organization: Forschungszentrum Informatik FZI I have a private patch that does the full generality of circular and elliptical arcs under arbitrary transformations for Genera. I'll make it available to this list as soon as I can get it tested for the released version of CLIM (probably in a week or two, modulo the Xmas vacation). I'm still waiting for your patch. Doesn't it work? Please let me know, if you don't make the code available soon. Thanks, Ralf.   Received: from BBN.COM by LABS-N.BBN.COM id aa10181; 20 Jan 92 7:15 EST Received: from mcsun.EU.net by BBN.COM id aa19670; 20 Jan 92 7:10 EST Received: from ub4b.buug.be by mcsun.EU.net with SMTP; id AA24374 (5.65a/CWI-2.133); Mon, 20 Jan 1992 13:10:39 +0100 Received: by ub4b.buug.be (5.64+/ub4b_02) id AA28517; Mon, 20 Jan 92 13:10:15 +0100 Received: by nrb.be (DECUS UUCP ///1.3-1/2.5/); Mon, 20 Jan 92 11:18:21 +0100 Date: Mon, 20 Jan 92 11:18:21 +0100 Message-Id: <00954EA26B182260.00004F5E@nrb.be> From: "Vincent Keunen, NRB +32 41 407282" Subject: ELU (european lisp users) To: clim-support@lucid.com, clim@BBN.COM, commonloops-request@cis.ohio-state.edu, info-mcl@cambridge.apple.com, slug@ai.sri.com X-Vms-Mail-To: uucp%"slug@ai.sri.com", uucp%"info-mcl@cambridge.apple.com", uucp%"commonloops-request@cis.ohio-state.edu", uucp%"clim@bbn.com", uucp%"clim-support@lucid.com" X-Vms-Mail-Cc: keunen I recently had some interesting discussions with Symbolics Germany SystemHaus about lisp use in Europ, Europal stuff, european user groups, european activities... I have heard here and there about various activities. What I'd like to do is try and gather all this information in one central point and forward it to anyone who is interested (possibly establishing a european lisp users mailing list, if there isn't any yet). Warning: I do not want to create a closed group by rejecting other people (from the US or Japan, for example). For instance, this has nothing to do, a priori, with the EuroLisp dialect. The intention is not to create an alternate community (against others), but to help develop more the european lisp community by having more local activities (meetings,...). I think quite a few european lisp users don't have the resources to go to the US for those LUV meetings, unfortunately. This is not by any way linked to one vendor. First, Symbolics Germany, who has agreed to help me in this, now sells Franz and Lucid products in addition to Symbolics products. Moreover, I would urge other vendors to participate in this; all are welcome. Here are the things to do: 1) if there have already been other attemps in this direction (I'm thinking about Europal), I'd like to know about them. There is no use in reinventing the wheel. What were the problems encountered, what were the successes, what does really exist? 2) if you know of any resources related to european lisp users (mailing lists, code servers, user groups - even vendor based,...) please send me email describing it. 3) if you are interested in this subject, send me your email address and, possibly, the addresses of everyone you know that might be interested. The aim of this first message is to collect information. Please send everything to keunen@nrb.be. Thank you for your help, and sorry to use up the bandwidth of some mailing lists that might not have been appropriate for this mailing (where were I supposed to send this to contact all lisp users?). Vincent Keunen keunen@nrb.be PS: this message has been sent to (what did I forget?): slug@ai.sri.com, info-mcl@cambridge.apple.com, commonloops-request@cis.ohio-state.edu, clim@bbn.com, clim-support@lucid.com. (Unfortunately, I don't have access to the news system. Could someone forward the message to the appropriate places? Thanks)   Received: from BBN.COM by LABS-N.BBN.COM id aa10175; 20 Jan 92 7:15 EST Received: from mcsun.EU.net by BBN.COM id aa19668; 20 Jan 92 7:10 EST Received: from ub4b.buug.be by mcsun.EU.net with SMTP; id AA24347 (5.65a/CWI-2.133); Mon, 20 Jan 1992 13:10:20 +0100 Received: by ub4b.buug.be (5.64+/ub4b_02) id AA28480; Mon, 20 Jan 92 13:09:58 +0100 Received: by nrb.be (DECUS UUCP ///1.3-1/2.5/); Mon, 20 Jan 92 11:17:27 +0100 Date: Mon, 20 Jan 92 11:17:27 +0100 Message-Id: <00954EA24A7A8660.00004F5E@nrb.be> From: "Ghys Michel, NRB, 32 41 407271" Subject: ELU (european lisp users) To: clim-support@lucid.com, clim@BBN.COM, commonloops-request@cis.ohio-state.edu, info-mcl@cambridge.apple.com, slug@ai.sri.com X-Vms-Mail-To: uucp%"slug@ai.sri.com", uucp%"info-mcl@cambridge.apple.com", uucp%"commonloops-request@cis.ohio-state.edu", uucp%"clim@bbn.com", uucp%"clim-support@lucid.com" X-Vms-Mail-Cc: keunen I recently had some interesting discussions with Symbolics Germany SystemHaus about lisp use in Europ, Europal stuff, european user groups, european activities... I have heard here and there about various activities. What I'd like to do is try and gather all this information in one central point and forward it to anyone who is interested (possibly establishing a european lisp users mailing list, if there isn't any yet). Warning: I do not want to create a closed group by rejecting other people (from the US or Japan, for example). For instance, this has nothing to do, a priori, with the EuroLisp dialect. The intention is not to create an alternate community (against others), but to help develop more the european lisp community by having more local activities (meetings,...). I think quite a few european lisp users don't have the resources to go to the US for those LUV meetings, unfortunately. This is not by any way linked to one vendor. First, Symbolics Germany, who has agreed to help me in this, now sells Franz and Lucid products in addition to Symbolics products. Moreover, I would urge other vendors to participate in this; all are welcome. Here are the things to do: 1) if there have already been other attemps in this direction (I'm thinking about Europal), I'd like to know about them. There is no use in reinventing the wheel. What were the problems encountered, what were the successes, what does really exist? 2) if you know of any resources related to european lisp users (mailing lists, code servers, user groups - even vendor based,...) please send me email describing it. 3) if you are interested in this subject, send me your email address and, possibly, the addresses of everyone you know that might be interested. The aim of this first message is to collect information. Please send everything to keunen@nrb.be. Thank you for your help, and sorry to use up the bandwidth of some mailing lists that might not have been appropriate for this mailing (where were I supposed to send this to contact all lisp users?). Vincent Keunen keunen@nrb.be PS: this message has been sent to (what did I forget?): slug@ai.sri.com, info-mcl@cambridge.apple.com, commonloops-request@cis.ohio-state.edu, clim@bbn.com, clim-support@lucid.com. (Unfortunately, I don't have access to the news system. Could someone forward the message to the appropriate places? Thanks)   Received: from BBN.COM by LABS-N.BBN.COM id aa17668; 20 Jan 92 16:41 EST Received: from cse.uta.edu by BBN.COM id aa26421; 20 Jan 92 16:30 EST Received: by cse.uta.edu (5.57/Ultrix2.4-C) id AA04480; Mon, 20 Jan 92 15:29:26 -0600 Date: Mon, 20 Jan 92 15:29:26 -0600 From: Charlie Lindahl Message-Id: <9201202129.AA04480@cse.uta.edu> To: keunen@milou.nrb.be Cc: clim-support@lucid.com, clim@BBN.COM, commonloops-request@cis.ohio-state.edu, slug@ai.sri.com In-Reply-To: "Vincent Keunen, NRB +32 41 407282"'s message of Mon, 20 Jan 92 11:18:21 +0100 <00954EA26B182260.00004F5E@nrb.be> Subject: ELU (european lisp users) Please put me on whatever mailing lists you generate for this stuff. I'm interested, although I'm not sure how much I can contribute at this point ... Charlie S. Lindahl Automation and Robotics Research Institute University of Texas at Arlington Internet EMAIL: lindahl@cse.uta.edu A reminder: Watch where you sit, cracks grow up to be crevasses. Disclaimer: My opinions are not necessarily those of my employer.   Received: from BBN.COM by LABS-N.BBN.COM id aa18408; 20 Jan 92 17:40 EST Received: from Sunset.AI.SRI.COM by BBN.COM id aa02300; 20 Jan 92 17:37 EST Received: from Rockaway.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA10531 for clim@bbn.com; Mon, 20 Jan 92 14:36:58 PST Received: by Rockaway.AI.SRI.COM (4.1/SMI-4.1) id AA09024 for clim-support@lucid.com; Mon, 20 Jan 92 14:36:57 PST Date: Mon, 20 Jan 92 14:36:56 PST From: Peter Karp To: clim@BBN.COM Cc: clim-support@lucid.com Subject: type-ahead in CLIM Message-Id: CLIM does not seem to have particularly good type-ahead capabilities. Example: I've defined four application commands, each of which scrolls a pane of my application in a different direction. Each command is accessible through a different keystroke accelerator. CLIM is not able to queue up multiple such commands. If, for example, I hit #\control-meta-U (which means scroll up) twice in a row, and the second keystroke occurs during the first scrolling, the second keystroke is ignored, i.e., the screen is only scrolled once. This is pretty annoying, and is more annoying in some other contexts. Are you aware of this problem, and is a fix possible? Peter   Received: from BBN.COM by LABS-N.BBN.COM id aa25756; 21 Jan 92 8:11 EST Received: from unido.Germany.EU.net by BBN.COM id aa01989; 21 Jan 92 8:07 EST Received: from gmdzi.gmd.de by mail.Germany.EU.net with SMTP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA18970; Tue, 21 Jan 92 14:01:16 +0100 Received: from [129.26.128.252] (fc801a81) by gmdzi.gmd.de id AA19060; Tue, 21 Jan 92 13:38:12 -0100 Date: Tue, 21 Jan 92 13:38:17 +0100 From: Thomas Hemmann To: clim@BBN.COM Reply-To: hemmann@gmdzi.gmd.de Message-Id: <2778845897.hemmann@gmdzi> Subject: CLIM for Mac: any experience? Hi CLIMers! Does anybody work with ILA*s CLIM on the Mac? I am interested in your experiences concerning the following points: - How much RAM does it need (minimal, recommended) ? - Speed (development, runtime) ? - Robustness (development environment, application) ? - Application code portability to Franz/Symbolics CLIM on Sun ? Any comments are welcome, thank you in advance! Thomas Hemmann hemmann@gmdzi.gmd.de Phone +49-2241-14-1 Fax +49-2241-14-2889 German National Research Center * I think he bought his doublet in Italy, * for Computer Science (GMD) * his round hose in France, his bonnet in * P.O. Box 1316 * Germany, and his behaviour everywhere. * Germany D-5205 Sankt Augustin * Shakespeare, The Merchant of Venice *   Received: from BBN.COM by LABS-N.BBN.COM id aa27477; 21 Jan 92 10:52 EST Received: from atc.boeing.com by BBN.COM id aa13705; 21 Jan 92 10:44 EST Received: by atc.boeing.com on Tue, 21 Jan 92 07:43:01 PST Received: by hsvaic.boeing.com (4.1/SMI-4.1-hsvaic-s.2) id AA08848; Tue, 21 Jan 92 09:43:34 CST Date: Tue, 21 Jan 92 09:43:34 CST From: Rodney Daughtrey Message-Id: <9201211543.AA08848@hsvaic.boeing.com> To: bug-clim@ila.com Subject: Delete-output-record/coordinate-sorted-set bug fixed? Reply-To: rodney@hsvaic.boeing.com To: bug-clim@ila.com, clim@BBN.COM, curt@eraserhead.jpl.nasa.gov > Date: Mon, 28 Oct 91 06:33:04 PST > From: Curt Eggemeyer > > I'm converting my software into CLIM, but I only wish to use the presentation > aspects within the application frame construct. >[...] > > My problem is this. Whenever I invoke erase-output-record function on my own > presentations, output-records, etc. , I hit the debugger in the > delete-output-record-element in which CLIM thinks my presentations aren't > there when they are (I looked into the top-level-coordinate-sorted-set). > My presentations are overlapping and I know CLIM is > doing some of its own massaging of the display. My display pane has > incremental display off, but it seems CLIM is still massagging my presentation > stuff. How do I turn it off? I am maintaining my own pointers to what is > on the display and I wish to selectively erase and regenerate things on my > own. Is there some application-frame pane flag I need to set to tell CLIM > that I will handle the output-record history? > >I think that you may have found a bug in the "coordinate-sorted" >output record implementation. A normal, scrolling, text-oriented CLIM >window stores its output records sorted by their Y coordinates. This >makes for faster searching (e.g. during presentation highlighting), >since the search can be bounded. However, there is one exception to >the "always sort by Y coordinates" rule, namely that overlapping >output records are stored in the order in which they were drawn. This >is necessary in order to get replay to stack overlapping things >correctly. Unfortunately, this exception has been known to confuse >parts of the code that always expect the records to be sorted by >Y-coordinate. > >I can't find the bug just by looking at the code, and the simple cases >of overlapping records that I tried seemed to work OK. If you can >supply a test case I will see what I can do. > >Alternatively, you can try to work around this bug by bypassing the >coordinate-sorting feature. To do this, evaluate the following form >(where WIN is assumed to refer to your application pane): > >(setf (output-recording-stream-output-record win) > (make-instance 'clim::linear-output-record)) > >[..] Did this bug ever get fixed? I'm having the same problem Curt described above. I tried Bill York's suggested fix (using the linear output record code above), but I still get the same error. Curt, what did you do to get around this? Ideas, anyone? I need some resolution to this, as I have a very important demo two days from now... Thanks! -- Rodney Rodney Daughtrey E-mail: rodney@hsvaic.boeing.com Huntsville AI Center {major site}!uw-beaver!bcsaic!hsvaic!rodney Boeing Computer Services Voice: (205)-464-4931 Fax: (205)-464-4930   Received: from BBN.COM by LABS-N.BBN.COM id aa01730; 21 Jan 92 16:17 EST Received: from elroy.jpl.nasa.gov by BBN.COM id aa08584; 21 Jan 92 16:09 EST Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA28879; Tue, 21 Jan 92 13:09:31 PST Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA04657; Tue, 21 Jan 92 13:04:32 PST Date: Tue, 21 Jan 92 13:04:32 PST From: Curt Eggemeyer Message-Id: <9201212104.AA04657@eraserhead.Jpl.Nasa.Gov> To: clim@BBN.COM Subject: Quickie question on formatting-table Is it possible to use formatting-table, formatting-row, etc. within the context of accepting-values where each cell in the table would be an individual accept with its own prompt and default? I'm not sure this is allowed by what was illustrated in the docs. That would be extremely handy if it is allowed. Do I need to do anything special to implement this if it is possible?   Received: from BBN.COM by LABS-N.BBN.COM id aa02613; 21 Jan 92 17:22 EST Received: from ALDERAAN.SCRC.Symbolics.COM by BBN.COM id aa13925; 21 Jan 92 17:18 EST Received: from WATERMELON.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via INTERNET with SMTP id 495772; 21 Jan 1992 17:17:45-0500 Date: Tue, 21 Jan 1992 17:21-0500 From: "John G. Aspinall" Subject: Quickie question on formatting-table To: curt@eraserhead.jpl.nasa.gov, clim@BBN.COM In-Reply-To: <9201212104.AA04657@eraserhead.Jpl.Nasa.Gov> Message-ID: <19920121222131.7.JGA@WATERMELON.SCRC.Symbolics.COM> Date: Tue, 21 Jan 1992 16:04 EST From: Curt Eggemeyer Is it possible to use formatting-table, formatting-row, etc. within the context of accepting-values where each cell in the table would be an individual accept with its own prompt and default? I'm not sure this is allowed by what was illustrated in the docs. That would be extremely handy if it is allowed. Do I need to do anything special to implement this if it is possible? Quite possible. You need not do anything special, though do take care that all your accept-values-queries have UNIQUE query-identifiers, else you will see some pretty bizarre display bugs. Courtesy of SWM, with some influence from an earlier version of mine, here is a little hardwired spreadsheet with row and column totals implemented as a table inside accepting-values: ================================================================ ;;; -*- Mode: LISP; Syntax: Common-lisp; Package: CLIM; Base: 10; Lowercase: Yes -*- (defparameter *default-cell-width* '(6 :character)) ;; A spreadsheet consists of a bunch of rows, a row consisting of ;; column sums, and a total. (defclass spreadsheet () ((rows :reader spreadsheet-rows) (column-sums :reader spreadsheet-column-sums) (total :accessor spreadsheet-total :initform 0.0) (cell-width :reader spreadsheet-cell-width :initarg :cell-width :initform *default-cell-width*))) (defmethod initialize-instance :after ((spreadsheet spreadsheet) &key nrows ncells &allow-other-keys) (with-slots (rows column-sums) spreadsheet (setf rows (make-array nrows)) (dotimes (i nrows) (setf (aref rows i) (make-instance 'spreadsheet-row :ncells ncells))) (setf column-sums (make-instance 'spreadsheet-row :ncells ncells)))) ;; A row consists of a bunch of cells and a row sum. (defclass spreadsheet-row () ((cells :reader spreadsheet-row-cells) (row-sum :accessor spreadsheet-row-sum :initform 0.0))) (defmethod initialize-instance :after ((row spreadsheet-row) &key ncells &allow-other-keys) (with-slots (cells) row (setq cells (make-array ncells :element-type 'float :initial-element 0.0)))) ;; Formatting a spreadsheet row consists of getting as input a ;; value for each cell in the row, using as a default the value ;; that is there right now. (defun format-spreadsheet-row (row stream cell-width) (let ((cells (spreadsheet-row-cells row))) (formatting-row (stream) (dotimes (i (length cells)) (formatting-cell (stream :align-x :right :minimum-width cell-width) (setf (aref cells i) (accept 'float :default (aref cells i) :prompt nil :prompt-mode :raw :query-identifier (list cells i) :stream stream)))) (present-sum (spreadsheet-row-sum row) stream cell-width)) (setf (spreadsheet-row-sum row) (reduce #'+ cells)))) (defun present-sum (sum stream cell-width) (formatting-cell (stream :align-x :right :minimum-width cell-width) (with-text-face (:bold stream) (present sum 'float :stream stream)))) (defun spreadsheet (nrows ncells &key (cell-width *default-cell-width*) (stream *query-io*)) (let* ((spreadsheet (make-instance 'spreadsheet :nrows nrows :ncells ncells :cell-width cell-width)) (rows (spreadsheet-rows spreadsheet)) (column-totals (spreadsheet-row-cells (spreadsheet-column-sums spreadsheet)))) (accepting-values (stream :own-window nil :resynchronize-every-pass t) (formatting-table (stream :inter-column-spacing '(2 :character) :equalize-column-widths t) (map nil #'(lambda (row) (format-spreadsheet-row row stream cell-width)) rows) (formatting-row (stream) (map nil #'(lambda (cell) (present-sum cell stream cell-width)) column-totals) (present-sum (spreadsheet-total spreadsheet) stream cell-width))) (setf (spreadsheet-total spreadsheet) 0.0) (dotimes (i ncells) (setf (aref column-totals i) 0.0) (dotimes (j nrows) (incf (aref column-totals i) (aref (spreadsheet-row-cells (aref rows j)) i))) (incf (spreadsheet-total spreadsheet) (aref column-totals i)))) spreadsheet))   Received: from BBN.COM by LABS-N.BBN.COM id aa02289; 21 Jan 92 16:59 EST Received: from cutthroat.cs.washington.edu by BBN.COM id aa12121; 21 Jan 92 16:52 EST Received: from localhost by cutthroat.cs.washington.edu (5.64a/7.0cr) id AA29304; Tue, 21 Jan 92 13:52:27 -0800 Return-Path: Message-Id: <9201212152.AA29304@cutthroat.cs.washington.edu> To: Curt Eggemeyer Cc: clim@BBN.COM Subject: Re: Quickie question on formatting-table In-Reply-To: Your message of Tue, 21 Jan 92 13:04:32 -0800. Organization: U of W Date: Tue, 21 Jan 92 13:52:26 -0800 From: ddraper@cs.washington.edu Is it possible to use formatting-table, formatting-row, etc. within the context of accepting-values where each cell in the table would be an individual accept with its own prompt and default? I'm not sure this is allowed by what was illustrated in the docs. That would be extremely handy if it is allowed. Do I need to do anything special to implement this if it is possible? Yes, it works, and no, you don't need to do anything special: just make the pane an accepting-values pane, and put your accepts inside formatting-cells. I don't have a complete example handy, but below is the macro I used for all my different tables. denise ddraper@cs.washington.edu ;;;---------- ;;; The following macro captures the common pattern: it displays ;;; one editable value in the table. When the value is edited, ;;; the associated code ('body') is executed. ;;; note: it assumes the variable 'stream' is appropriately bound (defmacro accept-val (val type id &body body) `(formatting-cell (stream) (let (new-val new-type val-changed) (multiple-value-bind (new-val new-type val-changed) (accept ,type :stream stream :default ,val :prompt nil :query-identifier ,id) (declare (ignore new-type)) (when val-changed (handler-case (progn ,@body) (simple-error (c) (show-error "~a" c))))))))   Received: from BBN.COM by LABS-N.BBN.COM id aa03699; 21 Jan 92 19:07 EST Received: from gatech.edu by BBN.COM id aa18316; 21 Jan 92 19:04 EST Received: from cc.gatech.edu (hermes.cc.gatech.edu) by gatech.edu (4.1/Gatech-9.1) id AA19803 for clim@BBN.Com; Tue, 21 Jan 92 19:04:22 EST Received: from terminus.cc.gatech.edu by cc.gatech.edu (3.2/SMI-3.2) id AA07749; Tue, 21 Jan 92 19:02:53 EST Received: by terminus.cc.gatech.edu (4.1/SMI-4.1) id AA25661; Tue, 21 Jan 92 19:04:06 EST Date: Tue, 21 Jan 92 19:04:06 EST From: Andres Gomez De Silva Garza Message-Id: <9201220004.AA25661@terminus.cc.gatech.edu> To: clim@BBN.COM Subject: Request to be included in CLIM mailing list. I'd like to be included in the CLIM mailing list, as I will be working with it in the near future. Thank you very much. If you need any additional data about me, please ask. --Andres (andres@cc.gatech.edu)   Received: from BBN.COM by LABS-N.BBN.COM id aa17419; 22 Jan 92 17:44 EST Received: from noc.msc.edu by BBN.COM id aa28814; 22 Jan 92 17:35 EST Received: from uc.msc.edu by noc.msc.edu (5.65/MSC/v3.0(901107)) id AA25022; Wed, 22 Jan 92 16:34:57 -0600 Received: from apctrc.trc.amoco.com by uc.msc.edu (5.65/MSC/v3.0z(901212)) id AA11541; Wed, 22 Jan 92 16:34:55 -0600 Received: from spirit.trc.amoco.com by trc.amoco.com (4.1/SMI-4.1) id AA21297; Wed, 22 Jan 92 16:34:03 CST Received: from trc.amoco.com (skeptic) by spirit.trc.amoco.com (4.1/SMI-4.1) id AA05274; Wed, 22 Jan 92 16:34:07 CST Date: Wed, 22 Jan 1992 16:34-0600 From: "Donald H. Mitchell" Reply-To: dmitchell@trc.amoco.com Subject: Controlling an application frame's background stream To: slug@ai.sri.com, clim@BBN.COM Cc: jtompkins@apctrc.trc.amoco.com, bdavis@apctrc.trc.amoco.com Message-Id: <19920122223407.8.DON@trc.amoco.com> Using a Symbolics UX1200. When we get an application error, the background stream is not coming up on the same root window as the application but is coming up on the main console. I cannot see where to specify the superior for the background stream. Does anyone know? We also had a bit of a funny case where colors were coming out differently on different consoles as if affected by the consoles' color maps and not following our ink specifications. Does anyone know what could cause this? Don Mitchell dmitchell@trc.amoco.com Amoco Production Company (918) 660-4270 Tulsa Research Center P.O. Box 3385, Tulsa, OK 74102   Received: from BBN.COM by LABS-N.BBN.COM id aa24987; 23 Jan 92 8:42 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa02949; 23 Jan 92 8:37 EST Received: from rama.fct.symbolics.com (RAMA.FCT.DIALNET.SYMBOLICS.COM) by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 652344; 23 Jan 1992 08:37:09-0500 Date: Thu, 23 Jan 1992 07:33-0600 From: "Bruce J. Carter" Reply-To: bcarter%rama.fct.dialnet.symbolics.com@riverside.scrc.symbolics.com Subject: Icons for Clim-Windows To: rkoenig%gate.fzi.de@riverside.scrc.symbolics.com, clim%bbn.com@riverside.scrc.symbolics.com cc: slug%ai.sri.com@riverside.scrc.symbolics.com In-Reply-To: <9201231313.AA18894@Sunset.AI.SRI.COM> Message-ID: <19920123133342.7.BCARTER@rama.fct.symbolics.com> If I remember right there is a tool that comes with X, that will give you that information, but for the life of me I can not remember what that tool is called. It is used for differnt type things, but mostly it gives information about where the mouse is, what window it is over etc... It should be where all of the X tools are, which is proabably not in /usr/bin, if you have access to the source you might look there for it. I think it is in the client tool area. It could very well be in the contrib stuff too. I wish I could be of more help by providing you with the name of the tool but I don't have a unix box in front of me, or else I would look. Bruce...   Received: from BBN.COM by LABS-N.BBN.COM id aa24726; 23 Jan 92 8:02 EST Received: from iraun1.ira.uka.de by BBN.COM id aa00427; 23 Jan 92 7:57 EST Received: from gate.fzi.de by iraun1.ira.uka.de id aa05247; 23 Jan 92 12:58 MET Received: from goldfinger.fzi.de by gate.fzi.de.fzi.de id aa00309; 23 Jan 92 10:11 GMT Date: Thu, 23 Jan 92 10:11:50 GMT From: Rainer Koenig To: clim@BBN.COM cc: slug@ai.sri.com Subject: Icons for Clim-Windows At: Forschungszentrum Informatik an der Universitaet Karlsruhe Address: Haid-und-Neu-Strasse 10-14, 75 Karlsruhe 1, Germany I'm using clim1.0 on an ivory-board. The ivory-board is in a Sun Sparc using X11R5 and the mwm. I open my application with (make-application-frame 'application :parent (open-root-window :clx :host host) :width *initial-width* :height *initial-height*))) Now I want to know which is the name of the window exposed on the X-display, so that you could use special icons. (.mwmrc ... Mwm**iconImage: ) Rainer -- Rainer Koenig email: rkoenig@fzi.de Forschungszentrum Informatik king@fzi.de Abtl. Technische Expertensysteme und Robotik Haid-und-Neu-Strasse 10-14 Fax : +49-721-9654-309 D - 7500 Karlsruhe 1 Tel.: +49-721-9654-313   Received: from BBN.COM by LABS-N.BBN.COM id aa25554; 23 Jan 92 9:24 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa05940; 23 Jan 92 9:19 EST Received: from bunny.gte.com ([132.197.8.1]) by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 652365; 23 Jan 1992 09:19:24-0500 Received: from vega by bunny.gte.com (5.61/GTEL2.19) id AA00804; Thu, 23 Jan 92 09:19:15 -0500 Date: Thu, 23 Jan 1992 09:23-0500 From: Richard J Brandau Subject: Icons for Clim-Windows To: bcarter%rama.fct.dialnet.symbolics.com@riverside.scrc.symbolics.com, rkoenig%gate.fzi.de@riverside.scrc.symbolics.com, clim%bbn.com@riverside.scrc.symbolics.com Cc: slug%ai.sri.com@riverside.scrc.symbolics.com, Rjb1%vega@gte.com In-Reply-To: <19920123133342.7.BCARTER@rama.fct.symbolics.com> Message-Id: <19920123142351.8.RJB1@vega.gte.com> If I remember right there is a tool that comes with X, that will give you that information, but for the life of me I can not remember what that tool is called. It is used for differnt type things, but mostly it gives information about where the mouse is, what window it is over etc... Could you be refering to xev?   Received: from BBN.COM by LABS-N.BBN.COM id aa27927; 23 Jan 92 11:55 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa17319; 23 Jan 92 11:50 EST Received: from mail.think.com ([131.239.16.33]) by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 652453; 23 Jan 1992 11:47:39-0500 Return-Path: Received: from Think.COM by mail.think.com; Thu, 23 Jan 92 11:47:54 -0500 Received: from OCCAM.THINK.COM by Early-Bird.Think.COM; Thu, 23 Jan 92 11:47:45 EST Date: Thu, 23 Jan 1992 11:47-0500 From: Barry Margolin Subject: Icons for Clim-Windows To: Richard J Brandau Cc: bcarter%rama.fct.dialnet.symbolics.com@riverside.scrc.symbolics.com, rkoenig%gate.fzi.de@riverside.scrc.symbolics.com, clim%bbn.com@riverside.scrc.symbolics.com, slug%ai.sri.com@riverside.scrc.symbolics.com In-Reply-To: <19920123142351.8.RJB1@vega.gte.com> Message-Id: <19920123164723.8.BARMAR@occam.think.com> Date: Thu, 23 Jan 1992 09:23 EST From: rjb1%vega@gte.com (Richard J Brandau) If I remember right there is a tool that comes with X, that will give you that information, but for the life of me I can not remember what that tool is called. It is used for differnt type things, but mostly it gives information about where the mouse is, what window it is over etc... Could you be refering to xev? Sounds more like xwininfo. Xev is for viewing X events. barmar   Received: from BBN.COM by LABS-N.BBN.COM id aa27178; 23 Jan 92 11:08 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa13917; 23 Jan 92 11:03 EST Received: from trantor.harris-atd.com ([130.41.0.1]) by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 652423; 23 Jan 1992 11:02:13-0500 Received: from altair.harris-atd.com by trantor.harris-atd.com (5.64+/1.14) id AA00343; Thu, 23 Jan 92 11:01:45 -0500 Received: by altair.harris-atd.com (4.1/SMI-4.1) id AA04472; Thu, 23 Jan 92 11:00:46 EST Message-Id: <9201231600.AA04472@altair.harris-atd.com> To: Richard J Brandau Cc: bcarter%rama.fct.dialnet.symbolics.com@riverside.scrc.symbolics.com, rkoenig%gate.fzi.de@riverside.scrc.symbolics.com, clim%bbn.com@riverside.scrc.symbolics.com, slug%ai.sri.com@riverside.scrc.symbolics.com Subject: Re: Icons for Clim-Windows In-Reply-To: Your message of Thu, 23 Jan 92 09:23:00 -0500. <19920123142351.8.RJB1@vega.gte.com> Date: Thu, 23 Jan 92 11:00:43 -0500 From: mac%altair@trantor.harris-atd.com Date: Thu, 23 Jan 1992 09:23-0500 From: rjb1%vega@gte.com (Richard J Brandau) Subject: Icons for Clim-Windows To: bcarter%rama.fct.dialnet.symbolics.com@riverside.scrc.symbolics.com, rkoenig%gate.fzi.de@riverside.scrc.symbolics.com, clim%bbn.com@riverside.scrc.symbolics.com Cc: slug%ai.sri.com@riverside.scrc.symbolics.com, Rjb1%vega@gte.com In-Reply-To: <19920123133342.7.BCARTER@rama.fct.symbolics.com> Message-Id: <19920123142351.8.RJB1@vega.gte.com> If I remember right there is a tool that comes with X, that will give you that information, but for the life of me I can not remember what that tool is called. It is used for differnt type things, but mostly it gives information about where the mouse is, what window it is over etc... Could you be refering to xev? Try xwininfo. Here's example output: =>xwininfo xwininfo: Please select the window about which you would like information by clicking the mouse in that window. xwininfo: Window id: 0x1800027 "xmh: inbox" Absolute upper-left X: 192 Absolute upper-left Y: 73 Relative upper-left X: 0 Relative upper-left Y: 21 Width: 660 Height: 750 Depth: 1 Visual Class: StaticGray Border width: 0 Class: InputOutput Colormap: 0x21 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +192+73 -300+73 -300-77 +192-77 -geometry 660x750+190+50 Mike McDonald mac@trantor.harris-atd.com (407) 727-5060 Advanced Technology Dept. Harris Corp. M.S. 3A-1912 P.O. Box 37 Melbourne, Florida 32902   Received: from BBN.COM by LABS-N.BBN.COM id aa02063; 23 Jan 92 15:54 EST Received: from iraun1.ira.uka.de by BBN.COM id aa26922; 23 Jan 92 14:09 EST Received: from gate.fzi.de by iraun1.ira.uka.de id ab14423; 23 Jan 92 17:58 MET Received: from goldfinger.fzi.de by gate.fzi.de.fzi.de id aa07416; 23 Jan 92 16:39 GMT Date: Thu, 23 Jan 92 16:39:38 GMT From: Rainer Koenig To: mac%altair@trantor.harris-atd.com cc: slug@ai.sri.com, clim@BBN.COM, bcarter@rama.fct.symbolics.com MMDF-Warning: Unable to confirm address in preceding line at iraun1.ira.uka.de Subject: Re: Icons for Clim-Windows At: Forschungszentrum Informatik an der Universitaet Karlsruhe Address: Haid-und-Neu-Strasse 10-14, 75 Karlsruhe 1, Germany > > If I remember right there is a tool that comes with X, that > will give you that information, but for the life of me I can > not remember what that tool is called. It is used for differnt > type things, but mostly it gives information about where the mouse > is, what window it is over etc... > > Could you be refering to xev? > > Try xwininfo. Here's example output: > > =>xwininfo > ... > xwininfo: Window id: 0x1800027 "xmh: inbox" > ... > > Mike McDonald > > mac@trantor.harris-atd.com > (407) 727-5060 > > Advanced Technology Dept. > Harris Corp. > M.S. 3A-1912 > P.O. Box 37 > Melbourne, Florida > 32902 I tried xwininfo, xlsclients, xlsatoms when I use xwininfo I get xwininfo: Please select the window about which you would like information by clicking the mouse in that window. xwininfo: Window id: 0x3800002 "Proroad" Absolute upper-left X: 95 Absolute upper-left Y: 29 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 1000 Height: 700 Depth: 8 Visual Class: PseudoColor Border width: 0 Class: InputOutput Colormap: 0x27 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +95+29 -57+29 -57-171 +95-171 -geometry 1000x700-57+29 But Proroad is not the name of the window, its just the label. When I have an "xterm -n TEST" and use xwininfo I get TEST and not xterm. Rainer -- Rainer Koenig email: rkoenig@fzi.de Forschungszentrum Informatik king@fzi.de Abtl. Technische Expertensysteme und Robotik Haid-und-Neu-Strasse 10-14 Fax : +49-721-9654-309 D - 7500 Karlsruhe 1 Tel.: +49-721-9654-313   Received: from BBN.COM by LABS-N.BBN.COM id aa02327; 23 Jan 92 16:13 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa05200; 23 Jan 92 16:00 EST Received: from rama.fct.symbolics.com (RAMA.FCT.DIALNET.SYMBOLICS.COM) by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 652621; 23 Jan 1992 15:58:45-0500 Date: Thu, 23 Jan 1992 14:57-0600 From: "Bruce J. Carter" Reply-To: bcarter%rama.fct.dialnet.symbolics.com@riverside.scrc.symbolics.com Subject: Re: Icons for Clim-Windows To: mac%altair@trantor.harris-atd.com, rjb1%vega@gte.com cc: bcarter%rama.fct.dialnet.symbolics.com@riverside.scrc.symbolics.com, rkoenig%gate.fzi.de@riverside.scrc.symbolics.com, clim%bbn.com@riverside.scrc.symbolics.com, slug%ai.sri.com@riverside.scrc.symbolics.com In-Reply-To: <9201231600.AA04472@altair.harris-atd.com> Message-ID: <19920123205709.8.BCARTER@rama.fct.symbolics.com> I was thinking xev, but I meant xwininfo.   Received: from BBN.COM by LABS-N.BBN.COM id aa01996; 23 Jan 92 15:48 EST Received: from corton.inria.fr by BBN.COM id aa03264; 23 Jan 92 15:33 EST Received: from laas.laas.fr by corton.inria.fr (5.65c8d/91.12.15) via Fnet-EUnet id AA18205; Thu, 23 Jan 1992 20:22:44 +0100 (MET) Received: from castor.laas.fr by laas.laas.fr, Thu, 23 Jan 92 15:57:23 +0100,Sendmail 5.61+ Received: by castor.laas.fr, Thu, 23 Jan 92 15:59:35 +0100,Sendmail 5.61+ Date: Thu, 23 Jan 92 15:59:35 +0100 From: Francois Felix Ingrand Message-Id: <9201231459.AA00612@castor.laas.fr> To: rkoenig@gate.fzi.de Cc: slug@ai.sri.com, clim@BBN.COM Subject: Icons for Clim-Windows References: <9201231313.AA18894@Sunset.AI.SRI.COM> X-Organization: LAAS, Toulouse, France Return-Receipt-To: felix@vega.laas.fr >I'm using clim1.0 on an ivory-board. >The ivory-board is in a Sun Sparc using X11R5 and the mwm. > >I open my application with > > (make-application-frame > 'application > :parent > (open-root-window :clx :host host) > :width *initial-width* > :height *initial-height*))) > >Now I want to know which is the name of the window exposed on the X-display, >so that you could use special icons. > >(.mwmrc > ... > Mwm**iconImage: > ) the f.identify operation under twm would do. However, you seem to be using mwm (which does not seem to have such operation), in this case xwininfo and xprop will give you everything you ever wanted to know about your window. (see their respective man pages) -- Felix   Received: from BBN.COM by LABS-N.BBN.COM id aa06468; 23 Jan 92 18:38 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa17588; 23 Jan 92 18:31 EST Received: from rama.fct.symbolics.com (RAMA.FCT.DIALNET.SYMBOLICS.COM) by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 652717; 23 Jan 1992 18:29:20-0500 Date: Thu, 23 Jan 1992 17:28-0600 From: "Bruce J. Carter" Reply-To: bcarter%rama.fct.dialnet.symbolics.com@riverside.scrc.symbolics.com Subject: Re: Icons for Clim-Windows To: rkoenig%gate.fzi.de@riverside.scrc.symbolics.com, mac%altair%trantor.harris-atd.com@riverside.scrc.symbolics.com cc: slug%ai.sri.com@riverside.scrc.symbolics.com, clim%bbn.com@riverside.scrc.symbolics.com In-Reply-To: <9201231909.AA24432@Sunset.AI.SRI.COM> Message-ID: <19920123232804.2.BCARTER@rama.fct.symbolics.com> Question then. Do you have any entries in your .Xdefaults that refer to this application of the nature: * The is what you want to use. Also if the programmer of your application if it is not you did the right thing you should be able to specify the icon to use with the resource: *DefaultIcon ? or *iconImage The above say that the developer took to time to program the ability to specify those resources. If indeed there are any resources available for that particular application. After that you are on your own, I know of no other way to define a resource for an application that does not handle the setting of a particular resource. Unless of course you want all of you applicatrions to have the same icon except the ones where you can specifically set the icon, with the method you first mentioned. I had the same problem with setting the icon I wanted to use for gnuemacs. You either took the default icon, or you used the one provided with gnuemacs. I could also not set the focus for gnuemacs either, I could get all of my other windows to come into focus by placing the mouse over the window, but gnuemacs I had to click on the window. Good luck, Bruce...   Received: from BBN.COM by LABS-N.BBN.COM id aa13349; 24 Jan 92 9:54 EST Received: from iraun1.ira.uka.de by BBN.COM id aa14967; 24 Jan 92 8:00 EST Received: from gate.fzi.de by iraun1.ira.uka.de id aa14034; 24 Jan 92 11:51 MET Received: from goldfinger.fzi.de by gate.fzi.de.fzi.de id aa18540; 24 Jan 92 10:54 GMT Date: Fri, 24 Jan 92 10:54:17 GMT From: Rainer Koenig To: mac@trantor.harris-atd.com, felix@vega.laas.fr, saraiya@hpp.stanford.edu MMDF-Warning: Unable to confirm address in preceding line at iraun1.ira.uka.de cc: clim@BBN.COM, slug@ai.sri.com, bcarter@rama.fct.symbolics.com MMDF-Warning: Unable to confirm address in preceding line at iraun1.ira.uka.de Subject: Re: Icons for Clim-Windows At: Forschungszentrum Informatik an der Universitaet Karlsruhe Address: Haid-und-Neu-Strasse 10-14, 75 Karlsruhe 1, Germany Thank you all for answering the question. Up to this moment I failed in binding an Icon to my CLIM-Window. (except of setting the default icon-value) Here are the results of different functions I tried. XPROP ==> WM_STATE(WM_STATE): window state: Normal icon window: 0x18000b5 WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. WM_ICON_NAME(STRING) = "Proroad" WM_NAME(STRING) = "Proroad" There is no WM_CLASS like in XTerm WM_CLASS(STRING) = "xterm", "XTerm" XWININFO ==> xwininfo: Window id: 0x3400002 "Proroad" Absolute upper-left X: 42 Absolute upper-left Y: 73 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 1000 Height: 700 Depth: 8 Visual Class: PseudoColor Border width: 0 Class: InputOutput Colormap: 0x27 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +42+73 -110+73 -110-127 +42-127 -geometry 1000x700+42+73 XLSCLIENTS ==> did not list the windows started from the Ivory-Board Using the F.IDENTIFY function of twm ... Name = "Proroad" Class.res_name = "Untitled" Class.res_class = "Untitled" I think the Problem is that the res_name and the res_class is undefined. Perhaps there is a possibility to set this values from CLIM Rainer -- Rainer Koenig email: rkoenig@fzi.de Forschungszentrum Informatik king@fzi.de Abtl. Technische Expertensysteme und Robotik Haid-und-Neu-Strasse 10-14 Fax : +49-721-9654-309 D - 7500 Karlsruhe 1 Tel.: +49-721-9654-313   Received: from BBN.COM by LABS-N.BBN.COM id aa19149; 27 Jan 92 9:21 EST Received: from [128.149.1.100] by BBN.COM id aa26058; 27 Jan 92 9:02 EST Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA08021; Mon, 27 Jan 92 06:02:10 PST Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA05868; Mon, 27 Jan 92 05:57:12 PST Date: Mon, 27 Jan 92 05:57:12 PST From: Curt Eggemeyer Message-Id: <9201271357.AA05868@eraserhead.Jpl.Nasa.Gov> To: clim@BBN.COM Subject: Oversized Formatting-Tables in scrollable panes First, thanks for the help and hints on the use of formatting-tables within accepting-values. Now for my next question. This concerns the operation of scrollable panes within the application. In my particular case I have instances in which I generate a huge editor using accepting-values on my data objects. This sometimes includes such things as the formatting-tables. Assuming the pane for accepting-values operation is scrollable in both directions, how to I keep the pane positioned at its origin when my accepts within accepting values goes beyond the panes displayable dimensions? I know I can always reposition the viewport position, but it is a little tacky that the presentations force the scrolling to the extents of the tables and other accept operations. Is there a simple form or pane variable I can set to keep the pane positioned at its viewport origin even when the accepting-values goes beyond its viewable limits?   Received: from BBN.COM by LABS-N.BBN.COM id aa21916; 27 Jan 92 12:22 EST Received: from ALDERAAN.SCRC.Symbolics.COM by BBN.COM id aa09364; 27 Jan 92 12:17 EST Received: from WATERMELON.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via INTERNET with SMTP id 496016; 27 Jan 1992 12:15:41-0500 Date: Mon, 27 Jan 1992 12:20-0500 From: "John G. Aspinall" Subject: Oversized Formatting-Tables in scrollable panes To: curt@eraserhead.jpl.nasa.gov, clim@BBN.COM In-Reply-To: <9201271357.AA05868@eraserhead.Jpl.Nasa.Gov> Message-ID: <19920127172027.8.JGA@WATERMELON.SCRC.Symbolics.COM> Date: Mon, 27 Jan 1992 08:57 EST From: Curt Eggemeyer First, thanks for the help and hints on the use of formatting-tables within accepting-values. Now for my next question. This concerns the operation of scrollable panes within the application. In my particular case I have instances in which I generate a huge editor using accepting-values on my data objects. This sometimes includes such things as the formatting-tables. Assuming the pane for accepting-values operation is scrollable in both directions, how to I keep the pane positioned at its origin when my accepts within accepting values goes beyond the panes displayable dimensions? I know I can always reposition the viewport position, but it is a little tacky that the presentations force the scrolling to the extents of the tables and other accept operations. Is there a simple form or pane variable I can set to keep the pane positioned at its viewport origin even when the accepting-values goes beyond its viewable limits? Read the documentation on WITH-END-OF-LINE-ACTION and WITH-END-OF-PAGE-ACTION.   Received: from BBN.COM by LABS-N.BBN.COM id aa21140; 27 Jan 92 11:19 EST Received: from [192.76.144.65] by BBN.COM id aa05446; 27 Jan 92 11:10 EST Received: from gmdzi.gmd.de by mail.Germany.EU.net with SMTP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA25582; Mon, 27 Jan 92 17:04:40 +0100 Received: from [129.26.128.252] (fc801a81) by gmdzi.gmd.de id AA07277; Mon, 27 Jan 92 17:10:42 -0100 Date: Mon, 27 Jan 92 17:09:09 +0100 From: Thomas Hemmann To: clim@BBN.COM Reply-To: hemmann@gmdzi.gmd.de Message-Id: <2779376949.hemmann@gmdzi> Subject: Who wanted the summary on ILA*s CLIM for the Mac? Sorry, unfortunately I discarded the address of someone, who wanted my private summary of answers concerning ILA*s CLIM for the Mac? I remember one name: Mr. Bayles or so ... If you are still interested, please send me your address again! Regards, Thomas Hemmann hemmann@gmdzi.gmd.de Phone +49-2241-14-1 Fax +49-2241-14-2889 German National Research Center * I think he bought his doublet in Italy, * for Computer Science (GMD) * his round hose in France, his bonnet in * P.O. Box 1316 * Germany, and his behaviour everywhere. * Germany D-5205 Sankt Augustin * Shakespeare, The Merchant of Venice *   Received: from BBN.COM by LABS-N.BBN.COM id aa29952; 30 Jan 92 4:17 EST Received: from iraun1.ira.uka.de by BBN.COM id aa28265; 30 Jan 92 4:06 EST Received: by iraun1.ira.uka.de id an01643; 30 Jan 92 9:32 MET Received: from gate.fzi.de by iraun1.ira.uka.de id aa24153; 30 Jan 92 2:18 MET Received: from ossi.fzi.de by gate.fzi.de.fzi.de id aa13893; 30 Jan 92 1:20 GMT Date: Thu, 30 Jan 92 1:20:32 GMT From: Ralf Nikolai To: clim@BBN.COM Subject: delete-output-record-element - problems Organization: Forschungszentrum Informatik FZI Hello CLIMers, I have some troubles with the handling of overlapping output-records. Because I'm not able to reproduce the error (?) in a small program, I try to explain the circumstances just by words: I draw some (particulary filled) figures inside a with-new-output-record - macro. Just there I also draw a presentation-type with with-output-as-presentation. Some with-scaling - and with-translation -macros are needed. Now, if I want to hide my figure (= normal figures + presentation-type), I do it with delete-output-record-element (I did it with erase-output-record before, but got some troubles, too). After a window-refresh the figure disappears. But: if I want to show it again (from inside a command) and call the same methods (I even called the display-method, no success!) it appears, but sensitivity of my presentation is lost! A look in my output-recording- stream-output-record shows: there is my standard-presentation but coordinates have changed to negativ values! And in fact, I can find my presentation outside the viewport in the negative part of the coordinate-system. The other parts of the figure are still on there old place! Funny, eh? More facts: I work on a symbolics ux400s with CLIM1.0. Because of some other troubles with output-records I use a linear-output-record for the output-recording-stream-output-record. Is there anybody with simulary problems? Any hints, what I can do to solve them? With future thanks, Ralf. nicolai@fzi.de   Received: from BBN.COM by LABS-N.BBN.COM id aa05041; 30 Jan 92 11:40 EST Received: from [130.49.32.198] by BBN.COM id aa21805; 30 Jan 92 11:35 EST Received: from localhost by fen.lrdc.pitt.edu (5.65/Ultrix3.0-C) id AA01192; Thu, 30 Jan 92 11:35:09 -0500 Message-Id: <9201301635.AA01192@fen.lrdc.pitt.edu> To: Ralf Nikolai Cc: clim@BBN.COM, martin@fen.lrdc.pitt.edu Subject: Re: delete-output-record-element - problems In-Reply-To: Your message of Thu, 30 Jan 92 01:20:32 +0000. Date: Thu, 30 Jan 92 11:35:09 EST From: martin@fen.lrdc.pitt.edu I forgot to mention, My environment is: Xwindows, lucid, Dec 5000 Joel   Received: from BBN.COM by LABS-N.BBN.COM id aa05160; 30 Jan 92 11:52 EST Received: from [130.49.32.198] by BBN.COM id aa22493; 30 Jan 92 11:45 EST Received: from localhost by fen.lrdc.pitt.edu (5.65/Ultrix3.0-C) id AA01212; Thu, 30 Jan 92 11:46:25 -0500 Message-Id: <9201301646.AA01212@fen.lrdc.pitt.edu> To: clim@BBN.COM Subject: overlapping presentations in output records Date: Thu, 30 Jan 92 11:46:25 EST From: martin@fen.lrdc.pitt.edu I have a similar problem with output records. I put several presentations of multiple types on the output record using with-output-as-presentation. When they don't overlap I have no problem, but when they overlap I get an error about 25% of the time. The error I get looks like this: ======================================================================== >>Error: The element # UPPER-LEFT (78 102) LOWER-RIGHT (261 207)) /x 78:261 y 102:207/ 110BB87E> was not found in # (METHOD CLIM:DELETE-OUTPUT-RECORD-ELEMENT (CLIM::COORDINATE-SORTED-SET-OUTPUT-RECORD T)): Required arg 0 (RECORD): # Required arg 1 (ELEMENT): # UPPER-LEFT (78 102) LOWER-RIGHT (261 207)) /x 78:261 y 102:207/ 111ED7BE> ======================================================================== Even though it says it can't find the presentation, when I look through the presentation I can find it. Environment: Xwindows, lucid, DEC5000 Any help would be greatly appreciated. Joel Martin CS U Pitt   Received: from BBN.COM by LABS-N.BBN.COM id aa04690; 30 Jan 92 11:05 EST Received: from SLUG-EAST.SCRC.Symbolics.COM by BBN.COM id aa19080; 30 Jan 92 10:53 EST Received: from ATHENA.PANGARO.DIALNET.SYMBOLICS.COM by SLUG-EAST.SCRC.Symbolics.COM via DIAL with SMTP id 15012; 30 Jan 1992 10:08:26-0500 Received: from ATHENA.PANGARO.dialnet.symbolics.com by ATHENA.PANGARO.dialnet.symbolics.com via CHAOS with CHAOS-MAIL id 101146; 30 Jan 1992 10:13:48-0500 Date: Thu, 30 Jan 1992 10:10-0500 From: Paul Pangaro Subject: CLIM on MAC CL --- query To: clim%bbn.com@slug-east.scrc.symbolics.com Supersedes: <19920130150029.3.PAN@ATHENA.PANGARO.dialnet.symbolics.com> Comments: to CLIM list Message-ID: <19920130151024.6.PAN@ATHENA.PANGARO.dialnet.symbolics.com> We are thinking of porting an application is basically a WYSIWYG graphical editor that is tailored to flowcharts (specifically the ones they use in the nuclear industry for certain types of procedures ---- emergency ones). Now running on Symbolics, at least one customer is interested in it "on a PC" --- MAC would be all right, though IBM would be better (makes the site guys happier). Our Symbolics version relies heavily on DW and flavors at the moment. Converting to CLOS and CLIM is not the question (that shouldnt be bad, right?). The question is, does anyone have experience with CLIM on the MAC under MCL to tell us whether this is (a) easy (b) tough now because of the state of CLIM (c) requires XXX or YYYY ? many thanks - PAN   Received: from BBN.COM by LABS-N.BBN.COM id aa20781; 31 Jan 92 14:36 EST Received: from Sun.COM by BBN.COM id aa11703; 31 Jan 92 14:19 EST Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA14018; Fri, 31 Jan 92 11:19:10 PST Received: from East.Sun.COM by snail.Sun.COM (4.1/SMI-4.1) id AA02071; Fri, 31 Jan 92 11:19:09 PST Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA20420; Fri, 31 Jan 92 14:19:07 EST Received: from norvig.East.Sun.COM by suneast.East.Sun.COM (4.1/SMI-4.1) id AA08443; Fri, 31 Jan 92 14:12:06 EST Received: by norvig.East.Sun.COM (4.1/SMI-4.1) id AA03861; Fri, 31 Jan 92 14:23:34 EST Date: Fri, 31 Jan 92 14:23:34 EST From: Peter Norvig - Sun Labs East Message-Id: <9201311923.AA03861@norvig.East.Sun.COM> To: clim@BBN.COM Subject: Incremental updating-record? I have an application that requires scrolling through several thousand records. I could use clim:updating-output, but the startup time is too long. What I really want is an incrmental version of updating-output that generates and displays one screenful and stops, then generates and displays subsequent screenfuls as the user scrolls. Has anybody done something like this? -Peter Peter Norvig Tel: (508) 671-0508 Sun Microsystems Laboratories Fax: (508) 671-0624 Two Federal Street Net: Peter.Norvig@East.Sun.COM Billerica MA 01821   Received: from BBN.COM by LABS-N.BBN.COM id aa29724; 1 Feb 92 12:48 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa22403; 1 Feb 92 12:45 EST Received: from FELDBERG.SGER.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 655499; 1 Feb 1992 12:43:45-0500 Received: from FUJI-SAN.SGER.Dialnet.Symbolics.COM by FELDBERG.SGER.Dialnet.Symbolics.COM via INTERNET with SMTP id 34046; 31 Jan 92 13:13:55+0100 Date: Fri, 31 Jan 1992 14:13+0200 From: Markus Fischer Subject: overlapping presentations in output records To: martin%fen.lrdc.pitt.edu@riverside.scrc.symbolics.com, clim%BBN.COM@riverside.scrc.symbolics.com In-Reply-To: <9201301646.AA01212@fen.lrdc.pitt.edu> Message-ID: <19920131121329.1.MF@FUJI-SAN.SGER.Dialnet.Symbolics.COM> Date: Thu, 30 Jan 1992 18:46+0200 From: martin@fen.lrdc.pitt.edu I have a similar problem with output records. I put several presentations of multiple types on the output record using with-output-as-presentation. When they don't overlap I have no problem, but when they overlap I get an error about 25% of the time. The error I get looks like this: ======================================================================== >>Error: The element # UPPER-LEFT (78 102) LOWER-RIGHT (261 207)) /x 78:261 y 102:207/ 110BB87E> was not found in # (METHOD CLIM:DELETE-OUTPUT-RECORD-ELEMENT (CLIM::COORDINATE-SORTED-SET-OUTPUT-RECORD T)): Required arg 0 (RECORD): # Required arg 1 (ELEMENT): # UPPER-LEFT (78 102) LOWER-RIGHT (261 207)) /x 78:261 y 102:207/ 111ED7BE> ======================================================================== Even though it says it can't find the presentation, when I look through the presentation I can find it. Environment: Xwindows, lucid, DEC5000 Any help would be greatly appreciated. Joel Martin CS U Pitt I think your problem is somwhat different to that of Ralf`s. Your's is a known CLIM 1.0 bug. I'm not sure for Lucid, but on a Symbolics you can avoid this error by providing the option :output-record (make-instance 'clim::linear-output-record) to the call of open-window-stream. Markus Fischer Consulting Services Symbolics Systemhaus GmbH Mergenthaler Allee 77-81 6236 Eschborn West Germany   Received: from BBN.COM by LABS-N.BBN.COM id aa29732; 1 Feb 92 12:50 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa22499; 1 Feb 92 12:47 EST Received: from FELDBERG.SGER.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 655501; 1 Feb 1992 12:45:38-0500 Received: from FUJI-SAN.SGER.Dialnet.Symbolics.COM by FELDBERG.SGER.Dialnet.Symbolics.COM via INTERNET with SMTP id 34048; 31 Jan 92 13:48:16+0100 Date: Fri, 31 Jan 1992 14:47+0200 From: Markus Fischer Subject: delete-output-record-element - problems To: nicolai%gate.fzi.de@riverside.scrc.symbolics.com cc: clim%BBN.COM@riverside.scrc.symbolics.com In-Reply-To: The message of 30 Jan 1992 03:20+0200 from Ralf Nikolai Message-ID: <19920131124749.2.MF@FUJI-SAN.SGER.Dialnet.Symbolics.COM> Date: Thu, 30 Jan 1992 03:20+0200 From: Ralf Nikolai Hello CLIMers, I have some troubles with the handling of overlapping output-records. Because I'm not able to reproduce the error (?) in a small program, I try to explain the circumstances just by words: I draw some (particulary filled) figures inside a with-new-output-record - macro. Just there I also draw a presentation-type with with-output-as-presentation. Some with-scaling - and with-translation -macros are needed. Now, if I want to hide my figure (= normal figures + presentation-type), I do it with delete-output-record-element (I did it with erase-output-record before, but got some troubles, too). After a window-refresh the figure disappears. But: if I want to show it again (from inside a command) and call the same methods (I even called the display-method, no success!) it appears, but sensitivity of my presentation is lost! A look in my output-recording- stream-output-record shows: there is my standard-presentation but coordinates have changed to negativ values! And in fact, I can find my presentation outside the viewport in the negative part of the coordinate-system. The other parts of the figure are still on there old place! Funny, eh? More facts: I work on a symbolics ux400s with CLIM1.0. Because of some other troubles with output-records I use a linear-output-record for the output-recording-stream-output-record. Is there anybody with simulary problems? Any hints, what I can do to solve them? With future thanks, Ralf. nicolai@fzi.de I tried to reproduce the error situation you described, but I did not succeed. However, here's my code: ;;; -*- Mode: LISP; Syntax: ANSI-Common-Lisp; Package: clim-demo -*- (defvar *parent* (open-root-window :sheet)) (defvar *stream* (open-window-stream :parent *parent* :output-record (make-instance 'clim::linear-output-record))) (defun draw (stream) (flet ((new-presentation () (let (presentation) (with-translation (stream -10 -10) (with-scaling (stream 2 2) (setf presentation (with-output-as-presentation (:stream stream :object 'hi) (draw-rectangle* stream 100 100 200 200 :ink (make-gray-color .4)))))) presentation))) (window-clear stream) (window-expose stream) (dotimes (i 2) (declare (ignore i)) (let ((presentation (new-presentation))) (accept 'symbol :stream stream) (erase-output-record presentation stream) ;;(delete-output-record-element (output-record-parent presentation) presentation) (sleep 1) (window-refresh stream))))) (draw *stream*) The error doesnt't occur with erase-output-record nor with delete-output-record-element. Maybe you can change/extend the code's functionality until you get the error reproducable (outside your application). I think that's the only way to get the bug proved in the case that nobody else (especially Scott?) knows that this is really a CLIM bug. Sorry, that I could't help more. Markus Fischer Consulting Services Symbolics Systemhaus GmbH Mergenthaler Allee 77-81 6236 Eschborn West Germany   Received: from BBN.COM by LABS-N.BBN.COM id aa06675; 2 Feb 92 11:02 EST Received: from iraun1.ira.uka.de by BBN.COM id aa08396; 2 Feb 92 10:58 EST Received: from gate.fzi.de by iraun1.ira.uka.de id aa03093; 2 Feb 92 13:37 MET Received: from ossi.fzi.de by gate.fzi.de.fzi.de id aa14069; 2 Feb 92 12:42 GMT Date: Sun, 2 Feb 92 12:41:19 GMT From: Ralf Nikolai To: mf@feldberg.sger.dialnet.symbolics.com cc: clim@BBN.COM Subject: RE: delete-output-record-element - problems Organization: Forschungszentrum Informatik FZI >I tried to reproduce the error situation you described, but I did not succeed. >However, here's my code: >... Hello Markus, thanks for your mail. I think it's not longer necessary to reproduce the error, because I fixed my (!?) error: I gave the with-output-as-presentation a :parent keyword, e.g. the output-recording-stream-output-record of the pane. Without doing this, the program (and the delete-output-record-element command) works perfectly, don't know why. Thanks for help again, Ralf.   Received: from BBN.COM by LABS-N.BBN.COM id aa06545; 2 Feb 92 10:47 EST Received: from iraun1.ira.uka.de by BBN.COM id aa06908; 2 Feb 92 10:36 EST Received: from gate.fzi.de by iraun1.ira.uka.de id aa02731; 2 Feb 92 12:43 MET Received: from ossi.fzi.de by gate.fzi.de.fzi.de id aa13546; 2 Feb 92 11:47 GMT Date: Sun, 2 Feb 92 11:46:49 GMT From: Ralf Nikolai To: martin@fen.lrdc.pitt.edu cc: clim@BBN.COM Subject: output-records Organization: Forschungszentrum Informatik FZI >I have a similar problem with output records. >I put several presentations of multiple types on the output record >using with-output-as-presentation. When they don't overlap I have >no problem, but when they overlap I get an error about 25% of the >time. >The error I get looks like this: >======================================================================== >>Error: The element ##S(DRAW::BOX POSITION 10 COLOR # >UPPER-LEFT (78 102) LOWER-RIGHT (261 207)) /x 78:261 y 102:207/ 110BB87E> >was not found in ># >(METHOD CLIM:DELETE-OUTPUT-RECORD-ELEMENT >(CLIM::COORDINATE-SORTED-SET-OUTPUT-RECORD T)): > Required arg 0 (RECORD): > # > Required arg 1 (ELEMENT): ##S(DRAW::BOX POSITION 10 COLOR # >UPPER-LEFT (78 102) LOWER-RIGHT (261 207)) /x 78:261 y 102:207/ 111ED7BE> >======================================================================== >Even though it says it can't find the presentation, when I look >through the presentation I can find it. Hello Joel, try (setf (output-recording-stream-output-record (get-frame-pane *application-frame* ')) (make-instance 'clim::linear-output-record)) after your make-apllication-frame. There are some problems with non-linear-output-records. Your error-description sounds like a earlier in this box discussed problem. Ciao, Ralf.   Received: from BBN.COM by LABS-N.BBN.COM id aa15016; 3 Feb 92 8:08 EST Received: from inbit.ibt.unit.no by BBN.COM id aa00679; 3 Feb 92 8:04 EST Received: from safir.ibt.unit.no by inbit.ibt.unit.no with SMTP id AA29489 (5.65a/IDA-1.4.3.1 for CLIM@BBN.COM); Mon, 3 Feb 92 14:03:57 +0100 Received: by safir.ibt.unit.no (5.65a/ibt-C-1.0) id AA08986; Mon, 3 Feb 92 14:03:56 +0100 Date: Mon, 3 Feb 92 14:03:56 +0100 From: Hallvard.Traetteberg@ibt.unit.no Message-Id: <9202031303.AA08986@safir.ibt.unit.no> To: CLIM@BBN.COM Subject: get in touch with ILA Hi, We are thinking of bying CLIM for MCL, but would like to get a detailed decription of what it offers first. Since I dont't know of any ftp-able documentation I'll have to ask ILA directly. What is their address, fax number, does anybody know? I'm also wondering if delivering applications with CLIM and MCL is convenient (are the images small, do the customers need a special lisence, how stable is the product, etc.) The first application we're considering implementing using CLIM is a rubberband graph editor with fairly standard dialog popups and some more sophisticated ones. Is CLIM good at these things? Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.BBN.COM id aa14832; 3 Feb 92 7:48 EST Received: from fenrix.si.no by BBN.COM id aa29430; 3 Feb 92 7:43 EST Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.16) id AA09689; Mon, 3 Feb 92 13:42:52 +0100 Date: Mon, 3 Feb 92 13:42:52 +0100 From: haltraet@si.no Message-Id: <9202031242.AAmonsun02261@D> To: CLIM@BBN.COM Subject: get in touch with ILA Hi, We are thinking of bying CLIM for MCL, but would like to get a detailed decription of what it offers first. Since I dont't know of any ftp-able documentation I'll have to ask ILA directly. What is their address, fax number, does anybody know? I'm also wondering if delivering applications with CLIM and MCL is convenient (are the images small, do the customers need a special lisence, how stable is the product, etc.) The first application we're considering implementing using CLIM is a rubberband graph editor with fairly standard dialog popups and some more sophisticated ones. Is CLIM good at these things? Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.BBN.COM id ab19854; 3 Feb 92 14:05 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa23068; 3 Feb 92 13:59 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 421383; 3 Feb 1992 13:13:45-0500 Date: Mon, 3 Feb 1992 13:13-0500 From: Scott McKay Subject: Icons for Clim-Windows To: rkoenig@gate.fzi.de, clim@BBN.COM In-Reply-To: <9201231313.AA18894@Sunset.AI.SRI.COM> Message-ID: <19920203181353.9.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Thu, 23 Jan 1992 05:11 EST From: rkoenig@gate.fzi.de (Rainer Koenig) I'm using clim1.0 on an ivory-board. The ivory-board is in a Sun Sparc using X11R5 and the mwm. I open my application with (make-application-frame 'application :parent (open-root-window :clx :host host) :width *initial-width* :height *initial-height*))) Now I want to know which is the name of the window exposed on the X-display, so that you could use special icons. (.mwmrc ... Mwm**iconImage: ) I don't actually know! Try DESCRIBEing the window stream object to find the host window object contained in it. CLIM 2.0 will probably do a better job here.   Received: from BBN.COM by LABS-N.BBN.COM id aa19871; 3 Feb 92 14:07 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa23044; 3 Feb 92 13:58 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 421376; 3 Feb 1992 12:58:32-0500 Date: Mon, 3 Feb 1992 12:58-0500 From: Scott McKay Subject: type-ahead in CLIM To: pkarp@ai.sri.com, clim@BBN.COM cc: clim-support@lucid.com In-Reply-To: Message-ID: <19920203175838.5.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Mon, 20 Jan 1992 17:36 EST From: Peter Karp CLIM does not seem to have particularly good type-ahead capabilities. Example: I've defined four application commands, each of which scrolls a pane of my application in a different direction. Each command is accessible through a different keystroke accelerator. CLIM is not able to queue up multiple such commands. If, for example, I hit #\control-meta-U (which means scroll up) twice in a row, and the second keystroke occurs during the first scrolling, the second keystroke is ignored, i.e., the screen is only scrolled once. This is pretty annoying, and is more annoying in some other contexts. Are you aware of this problem, and is a fix possible? I cannot reproduce this problem. I see nothing in CLIM that would cause it to be a problem. I have no way of telling for sure since you did not say what platform(s) you are using.   Received: from BBN.COM by LABS-N.BBN.COM id aa19931; 3 Feb 92 14:10 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa23000; 3 Feb 92 13:58 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 421378; 3 Feb 1992 13:02:26-0500 Date: Mon, 3 Feb 1992 13:02-0500 From: Scott McKay Subject: CLIM for Mac: any experience? To: hemmann@gmdzi.gmd.de, clim@BBN.COM In-Reply-To: <2778845897.hemmann@gmdzi> Message-ID: <19920203180232.6.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Tue, 21 Jan 1992 07:38 EST From: Thomas Hemmann Hi CLIMers! Does anybody work with ILA*s CLIM on the Mac? I am interested in your experiences concerning the following points: - How much RAM does it need (minimal, recommended) ? - Speed (development, runtime) ? - Robustness (development environment, application) ? I can't answer definitively about any of these, especially since the performance of Macs varies so widely from one machine to another. - Application code portability to Franz/Symbolics CLIM on Sun ? CLIM is built from the exact same source code on every platform, except for a very small amount of platform-dependent code. The degree of portability from one platform to the next is very high.   Received: from BBN.COM by LABS-N.BBN.COM id aa20012; 3 Feb 92 14:17 EST Received: from Sunset.AI.SRI.COM by BBN.COM id aa23944; 3 Feb 92 14:12 EST Received: from Rockaway.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA28406 for clim@BBN.COM; Mon, 3 Feb 92 11:12:40 PST Received: by Rockaway.AI.SRI.COM (4.1/SMI-4.1) id AA22628 for clim-support@lucid.com; Mon, 3 Feb 92 11:12:39 PST Date: Mon, 3 Feb 92 11:12:38 PST From: Peter Karp To: Scott McKay Cc: clim@BBN.COM, clim-support@lucid.com Subject: Re: type-ahead in CLIM In-Reply-To: Your message of Mon, 3 Feb 1992 12:58-0500 Message-Id: I am using a Sparcstation. Did you actually try to code my scrolling example? Shall I send you a test case? Thanks for looking into it... Peter   Received: from BBN.COM by LABS-N.BBN.COM id aa19854; 3 Feb 92 14:05 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa23022; 3 Feb 92 13:58 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 421369; 3 Feb 1992 12:05:53-0500 Date: Mon, 3 Feb 1992 12:05-0500 From: Scott McKay Subject: Accepting-values quickie question To: curt@eraserhead.jpl.nasa.gov, clim@BBN.COM In-Reply-To: <9201180010.AA03739@eraserhead.Jpl.Nasa.Gov> Message-ID: <19920203170553.1.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Fri, 17 Jan 1992 19:10 EST From: Curt Eggemeyer Can you call accepting-values within accepting-values? If so there anything special I have to worry about? ie: (accepting-values (stream) (accept ...) (terpri stream) (accepting-values (stream) (accept ...) ... more accepts ) It works in later vintages of CLIM 1.0, but it might not work under the Genera version.   Received: from BBN.COM by LABS-N.BBN.COM id aa21903; 3 Feb 92 16:38 EST Received: from crdgw1.GE.COM by BBN.COM id aa02707; 3 Feb 92 16:29 EST Received: by crdgw1.ge.com (5.57/GE 1.122) id AA19245; Mon, 3 Feb 92 16:20:20 EST Received: from kona.crd.Ge.Com by easygoer.crd.Ge.Com (4.1/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA02348; Mon, 3 Feb 92 16:20:12 EST Date: Mon, 3 Feb 92 16:20:12 EST From: William D Smith Message-Id: <9202032120.AA02348@easygoer.crd.Ge.Com> Received: by kona.crd.Ge.Com (4.1/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA09105; Mon, 3 Feb 92 16:20:11 EST To: clim@BBN.COM Subject: available clim implementations ??? Reply-To: smithwd@kona.crd.ge.com Hi there - I am interested in collecting information about what Lisp implementations and hardware platforms currently (or soon will) have CLIM available on them. For example, I am aware that Lucid has CLIM 1.0 for Sun & HP workstations, ILA supports MACs, etc. - but I want a more complete summary of the available Lisp implementations (eg, Franz, Symbolics, Harlequin, etc.), hardware platforms (eg, Symbolics, IBM PC, etc.) supported, and CLIM pricing information for each platform. If you have access to such information (ie, most probably vendors), could you please email this information to me directly? If there is sufficient interest, I will generate a summary along the lines of Mark Kantrowitz's (from CMU) posting on various Lisp implementations (that he was aware of) to comp.lang.lisp -- which is excerpted below (I don't know how up-to-date this information is either): Summary Chart: ======================================================================= Name Price IBM PC MAC SPARC IBM RT RS/6000 PMAX ======================================================================= KCL Free yes yes yes yes ----------------------------------------------------------------------- XLISP Free yes yes ----------------------------------------------------------------------- CMU Common Lisp Free yes yes yes yes ----------------------------------------------------------------------- MCL $495 yes ----------------------------------------------------------------------- Procyon CL $2700 yes yes ----------------------------------------------------------------------- Franz Lisp $99/$199 yes ----------------------------------------------------------------------- Allegro CL $3750 yes yes yes ----------------------------------------------------------------------- Ibuki CL $2800 $700 yes yes yes yes ----------------------------------------------------------------------- Lucid CL $4400 $2500 yes yes yes yes ----------------------------------------------------------------------- GCLisp $2250 yes ----------------------------------------------------------------------- Star Saphire CL $100 yes ----------------------------------------------------------------------- Software Enginr $250 yes ----------------------------------------------------------------------- CLOE $625 yes ----------------------------------------------------------------------- Top Level CL $687 ----------------------------------------------------------------------- Thanks in advance .... - Bill   Received: from BBN.COM by LABS-N.BBN.COM id aa22449; 3 Feb 92 17:11 EST Received: from lucid.com by BBN.COM id aa05303; 3 Feb 92 17:05 EST Received: from kuwait.lucid ([192.31.212.118]) by heavens-gate.lucid.com id AA02416g; Mon, 3 Feb 92 14:01:01 PST Received: by kuwait.lucid (4.1/SMI-4.1) id AA02928; Mon, 3 Feb 92 14:05:09 PST Date: Mon, 3 Feb 92 14:05:09 PST From: John Kern Message-Id: <9202032205.AA02928@kuwait.lucid> To: pkarp@ai.sri.com Cc: SWM@sapsucker.scrc.symbolics.com, clim@BBN.COM, clim-support@lucid.com In-Reply-To: Peter Karp's message of Mon, 3 Feb 92 11:12:38 PST Subject: type-ahead in CLIM Reply-To: kern@lucid.com Howdy Mr. Karp, Can I get a copy of your testcase? Sincerely, John   Received: from BBN.COM by LABS-N.BBN.COM id aa24585; 3 Feb 92 21:45 EST Received: from munnari.OZ.AU by BBN.COM id aa22697; 3 Feb 92 21:40 EST Received: from orca1.nnmdmelb.telecom.oz (via bruce) by munnari.oz.au with SunIII (5.64+1.3.1+0.50) id AA23716; Tue, 4 Feb 1992 13:40:08 +1100 (from eden!chenny%babel@orca1.nnmdmelb.telecom.oz.au) Received: by orca1 (15.11.1.6/15.6) id AA07496; Tue, 4 Feb 92 13:31:30 +1100 Received: from eden with uucp; Tue, 4 Feb 92 13:27:46 Received: from babel by eden with SMTP (16.7/15.6) id AA00179; Tue, 4 Feb 92 13:27:46 +1100 Posted-Date: Tue, 4 Feb 92 13:28:00 DST Received-Date: Tue, 4 Feb 92 13:27:46 +1100 Received: by babel.nnmdmelb (4.1/SMI-4.1) id AA01142; Tue, 4 Feb 92 13:28:00 DST Date: Tue, 4 Feb 92 13:28:00 DST From: John Chenoweth Message-Id: <9202040228.AA01142@babel.nnmdmelb> To: orca1!clim <@munnari.oz.au:orca1!clim@BBN.COM> Subject: CLIM user group Cc: orca1!clim-request <@munnari.oz.au:orca1!clim-request@BBN.COM> I would like to be included on this mailing list/group along with two others. 1. chenny@nnmdmelb.telecom.oz.au 2. prototypers@nnmdmelb.telecom.oz.au regards jc _______________________________________________________________________ | John Chenoweth | | | Network Management Systems Development Melbourne | /-_|\ | | 4th. Floor, 20 Flinders lane | / \ | | Melbourne Australia 3000 | \_,-._/ | | Phone +613 657 2510 | v | | Fax +613 650 7726 |___________| | EMail j.chenoweth@nnmdmelb.telecom.oz.au | | |__________________________________________________________|___________|   Received: from BBN.COM by LABS-N.BBN.COM id ab01740; 4 Feb 92 10:53 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa23165; 4 Feb 92 10:48 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 421562; 4 Feb 1992 10:48:19-0500 Date: Tue, 4 Feb 1992 10:48-0500 From: Scott McKay Subject: Incremental updating-record? To: Peter.Norvig@east.sun.com, clim@BBN.COM In-Reply-To: <9201311923.AA03861@norvig.East.Sun.COM> Message-ID: <19920204154826.9.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Fri, 31 Jan 1992 14:23 EST From: Peter Norvig - Sun Labs East I have an application that requires scrolling through several thousand records. I could use clim:updating-output, but the startup time is too long. What I really want is an incrmental version of updating-output that generates and displays one screenful and stops, then generates and displays subsequent screenfuls as the user scrolls. Has anybody done something like this? I have a version of something like this that incrementally redisplay individual "lines", where a "line" is one horizontal unit of display. It works best when all of the lines have similar height (more accurate computation of scroll bars), but that is not a strict requirement. Is this the sort of thing you need? If this is important to other people, I will try to finish it up and get it into either CLIM itself or some sort of CLIM library.   Received: from BBN.COM by LABS-N.BBN.COM id aa02160; 4 Feb 92 11:25 EST Received: from ALDERAAN.SCRC.Symbolics.COM by BBN.COM id aa14865; 4 Feb 92 8:59 EST Received: from FIREBIRD.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via INTERNET with SMTP id 496514; 4 Feb 1992 08:58:41-0500 Date: Tue, 4 Feb 1992 08:52-0500 From: Bob Laddaga Subject: available clim implementations ??? To: smithwd@kona.crd.ge.com, clim@BBN.COM In-Reply-To: <9202032120.AA02348@easygoer.crd.Ge.Com> Message-ID: <19920204135220.9.LADDAGA@FIREBIRD.SCRC.Symbolics.COM> Symbolics offers CLIM 1.0 running under Genera, on its Ivory Based and 36xx workstations, as well as running under CLOE and MS-Windows 3.0 on 386 and 486 based PCs. In all cases CLIM 1.0 is bundled at no extra charge.   Received: from BBN.COM by LABS-N.BBN.COM id aa02534; 4 Feb 92 11:57 EST Received: from chx400.switch.ch by BBN.COM id aa26678; 4 Feb 92 11:54 EST X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/; Relayed; Tue, 4 Feb 1992 17:43:47 +0100 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Tue, 4 Feb 1992 17:38:12 +0100 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Tue, 4 Feb 1992 17:38:17 +0100 Date: Tue, 4 Feb 1992 16:38:12 +0000 X400-Originator: schneide@divsun.unige.ch X400-MTS-Identifier: [/PRMD=SWITCH/ADMD=ARCOM/C=CH/;920204173817] X400-Content-Type: P2-1984 (2) Content-Identifier: 419 Conversion: Prohibited From: Schneider Daniel Message-ID: <419*/S=schneide/OU=divsun/O=unige/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> To: clim Subject: Multiple frames under Genera Hi folks, In an AI&Ed application we are building, we use lots of frames which run under Allegro CL as independant processes. Those frames are indexed in some hierarchical structure in a state variable of a parent frame. (E.g. on the top of our application we have a global variable which holds an instance of the control frame holding several learner frames which can run on different displays. Each learner frame in turn has several children, and so on. This way frames can be created and/or exposed by the user or the program. How can I do that under Genera ? I got an old 3620 sitting around idle and I'd like to do the same thing, but frames block each other, i.e. once a frame is exposed, I can't use its parent frame anymore. Any hints what I'd have to do in order to get a clim program running with non-monolitic non-egoistic frames? Or do I need to be more precise? See the ugly thing I tried below with #genera Sorry if I'm wasting a bit of bandwith. But, as soon as we get a half-baked alpha version running (in a month or so), we'll make it available to the world via FTP. And in a year or so we'll distribute a nice beta version of this intelligent learning environment. Yeah. - thanx !!! - Daniel ;; --------------------------- bits of code ---------------------------- ;;; warning: this is incomplete, it's here to illustrate (defclass memolab-frame-mixin () ((name-string :initarg :name-string :initform "Unnamed Memolab Frame" :accessor frame-name-string) (symbolic-name :initarg :symbolic-name :initform 'unknown-frame :accessor frame-symbolic-name) ;; contains the process of a frame (Allegro, ?? under Genera) (process :initarg :process :initform nil :accessor frame-process) (associated-frames-defs :initarg :associated-frames-defs :initform nil :accessor frame-associated-frames-defs) ;; contains the various (sub and associated) frames ;; in an assoc list, (e.g. help hypertexts,) (associated-frames :initarg :associated-frames :initform nil :accessor frame-associated-frames) ;; contains ALL the various (sub) frames. ;; those are not used for access, but just to kill dependent stuff (sub-frames :initarg :sub-frames :initform nil :accessor frame-sub-frames) ;; contains eventual parent frames ;; -- do we need a list here $$??, for control?? (parent-frame :initarg :parent-frame :initform nil :accessor frame-parent-frame) ) (:documentation "A Memolab CLIM application frame")) ;; this is an example which shows how I associate child frames to a parent (DEFINE-application-FRAME learner (clim:application-frame memolab-frame-mixin) ( ;; ==== ==== system variables -- add intiargs when needed (oops-learner :initform nil :accessor learner-oops-learner) (control :initform 'total :accessor learner-control) ;; ---- ---- Note: all frames belonging to the learner ;; are put in the slot associated-frames (associated-frames-defs :initform '((memolab-coach :class memolab-coach :pretty-name "Memolab Coach" :parent parent :select-key #\k ;; koach ! :top 10 :left 300 :width 500 :height 300 ) (memolab :class memolab :pretty-name "Memolab Laboratory" :left 100 :select-key #\ ;; symbol-l :top 100 :width 700 :height 600) (methodology :class hyper :pretty-name "Handbook of Methodology" ;; #+genera :select-key #+genera #\circle :left 10 :top 10 :height 600 :width 600 :data-file "~/memolab/hyp/methodology.hypertext.com" ) ;;; lots of frames deleted here ..... ) )) (:PANES ;; the panes used in the hyper system, (multiple configurations) ( (random :application :scroll-bars nil :DEFAULT-TEXT-STYLE '(:SANS-SERIF :ROMAN :very-SMALL)) (menu :command-menu :DEFAULT-TEXT-STYLE '(:SANS-SERIF :ROMAN :very-SMALL) :vsp 0) )) (:layout ((default (:column 1 (menu 0.95) (random :rest) ))) ) ;layout ) (defmethod frame-instantiate-associated-frame ((frame clim:application-frame) definition-list &optional spec-server-path) "takes a definition list for an associated frame and instantiates it" (run-application (find-item :class definition-list) :symbolic-name (first definition-list) :pretty-name (find-item :pretty-name definition-list) :left (find-item :left definition-list) :top (find-item :top definition-list) :height (find-item :height definition-list) :width (find-item :width definition-list) :select-key (find-item :select-key definition-list) :slave-process (find-item :slave-process definition-list) :caller frame :data-file (find-item :data-file definition-list) :parent (if spec-server-path spec-server-path (window-parent (frame-top-level-window frame))) )) #+allegro (defun run-application (class &key (symbolic-name class) (pretty-name "random frame") (select-key nil) (parent (get-server-path)) (left 50) (top 50) (height 200) (width 200) (caller nil) (slave-process nil) (data-file nil) ) "launches an application with the right parameters" (declare (ignore select-key)) (let ((app (clim:make-application-frame class :pretty-name pretty-name :parent parent ; clim root window :left left :top top :height height :width width :parent-frame caller ; our parent frame :symbolic-name symbolic-name ))) ;; ---- launch the frame (if slave-process ;; for small dependent tasks where the user HAS to exit. ;; not used currently, DOESN't work this way (run-frame-top-level app) ;; each memolab application frame knows its own process (setf (frame-process app) (mp:process-run-function (format nil "~a" (gensym (format nil "~A-" (string-upcase pretty-name)))) #'clim:run-frame-top-level app))) ;; ---- we register the new frame as associated-frame of the caller ;; and we put it in the sub-frame-list of ALL its parents (if caller (progn (push (cons symbolic-name app) (frame-associated-frames caller)) (frame-register-sub-frame caller app) )) (if data-file (progn (sleep 2) (load-data-file app data-file))) app) ) #+genera (defun run-application (class &key (symbolic-name class) (pretty-name "random frame") (select-key nil) (parent (get-server-path)) (left 50) (top 50) (height 200) (width 200) (caller nil) ;; (exposed-p t) (data-file nil) ) "launches an application with the right parameters" (let ((app (clim:make-application-frame class :pretty-name pretty-name :parent parent ; clim root window :left left :top top :height height :width width :parent-frame caller ; our parent frame :symbolic-name symbolic-name ))) ;; ???????? (eval `(clim:define-genera-application ,class :pretty-name ,pretty-name :select-key ,select-key )) ;; ---- launch the frame ;; each memolab application frame knows its own process ;; (clim:run-frame-top-level app) ;; ---- we register the new frame as direct-sub-frame of the caller ;; and as sub-frame of ALL its parent (if caller (progn (push (cons symbolic-name app) (frame-associated-frames caller)) (frame-register-sub-frame caller app) )) (if data-file (load-data-file app data-file)) app) ) (defmethod frame-get-associated-frame ((frame clim:application-frame) symbolic-name &optional special-server-path) ;; --- 0 --- it is the frame itself (if (eq (frame-symbolic-name frame) symbolic-name) frame ;; --- 1 --- try to get an instantiated frame (let ((found-frame (cdr (assoc symbolic-name (frame-associated-frames frame))))) (if (and found-frame (not special-server-path)) ;; here we force a new frame in any case found-frame ;; --- 2 --- try to instantiate a frame (let ((frame-definition (assoc symbolic-name (frame-associated-frames-defs frame)))) (if frame-definition (frame-instantiate-associated-frame frame frame-definition special-server-path) ;; --- 3 --- try to see if the parent can help (if (frame-parent-frame frame) (frame-get-associated-frame (frame-parent-frame frame) symbolic-name special-server-path) ;; --- 4 --- means failure nil))))))) (defmethod expose-associated-frame ((frame clim:application-frame) symbolic-name &optional server-path) (let ((associated-frame (frame-get-associated-frame frame symbolic-name server-path))) (frame-expose associated-frame) ;; return the frame - important !! associated-frame )) ;#+genera ;(defmethod expose-associated-frame ((frame clim:application-frame) symbolic-name) ; (let ((associated-frame ; (frame-get-associated-frame frame symbolic-name))) ; (dw:find-and-select-program-window ; (frame-name associated-frame)) ; associated-frame)) ---------------------- Daniel K.Schneider, TECFA (Educational Technologies and Learning) Faculte de Psychologie et des Sciences de l'Education, University of Geneva, 1211 Geneva 4 (Switzerland), Tel.(..41)22 705 7652, Fax. (..41) 22 20 29 27. Internet: schneide@divsun.unige.ch (and various national nets) | if reply CSnet/ARPA: schneide%divsun.unige.ch@relay.cs.net (old style) | does not X400: S=schneide;OU=divsun;O=unige;PRMD=switch;ADMD=arcom;C=ch | work, uucp: mcvax!cui!divsun.unige.ch!shneider | try one BITNET: schneide@cgeuge51 | of DECNET: UGUN2A::SCHNEIDE (local Swiss) | these   Received: from BBN.COM by LABS-N.BBN.COM id aa11151; 5 Feb 92 1:55 EST Received: from phloem.uoregon.edu by BBN.COM id aa26190; 5 Feb 92 1:46 EST Received: from duff.uoregon.edu by phloem.uoregon.edu (4.1/UofO NetSvc-05/01/91) id AA03011; Tue, 4 Feb 92 22:23:06 PST Date: Tue, 4 Feb 92 22:23:06 PST From: Carl Gay Message-Id: <9202050623.AA03011@phloem.uoregon.edu> Received: by duff.uoregon.edu (4.1/UofO NetSvc-11/11/90) id AA00110; Tue, 4 Feb 92 22:24:01 PST To: clim@BBN.COM Subject: Archives and Mac CLIM Cc: cgay@ns.uoregon.edu Are the archives for this list available? They don't appear to be on BBN.COM. Since I'm already bothering the whole list I'll ask another question that I know has been asked before: I'm considering spending my tax refund on Mac CLIM. (Hey, after five months of Stupid Unix triX you would too.) I would appreciate opinions about the speed and quality of CLIM on a Mac IIsi or equivalent, esp. comparisons to Genera CLIM's speed. I have plenty of memory, so that's not an issue. Reply to me only, and I'll summarize if anyone expresses interest. Thanks. -Carl   Received: from BBN.COM by LABS-N.BBN.COM id aa14580; 5 Feb 92 9:10 EST Received: from elroy.jpl.nasa.gov by BBN.COM id aa20224; 5 Feb 92 9:04 EST Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA26017; Wed, 5 Feb 92 06:03:22 PST Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA08200; Wed, 5 Feb 92 05:58:16 PST Date: Wed, 5 Feb 92 05:58:16 PST From: Curt Eggemeyer Message-Id: <9202051358.AA08200@eraserhead.Jpl.Nasa.Gov> To: slug@warbucks.ai.sri.com Subject: Common-Lisp for Amiga Cc: clim@BBN.COM Does anybody know of a decent common-lisp for the Amiga? Is there a hope for a CLIM port?   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa15222; 5 Feb 92 10:11 EST Received: by KARIBA.BBN.COM id ac12419; 5 Feb 92 9:56 EST From: Dan Cerys Organization: Bolt Beranek and Newman Inc. To: cgay@phloem.uoregon.edu CC: clim@BBN.COM In-reply-to: Carl Gay's message of Tue, 4 Feb 92 22:23:06 PST <9202050623.AA03011@phloem.uoregon.edu> Subject: Archives and Mac CLIM Date: Wed, 5 Feb 92 9:54:33 EST Sender: cerys@BBN.COM Date: Tue, 4 Feb 92 22:23:06 PST From: Carl Gay Are the archives for this list available? They don't appear to be on BBN.COM. The CLIM list archive is on available via anonymous ftp from labs-n.bbn.com. (Forewarning: the location will change sometime soon, but a pointer will (manually) forward you to the new location).   Received: from BBN.COM by LABS-N.BBN.COM id aa15894; 5 Feb 92 11:00 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa27212; 5 Feb 92 10:56 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 421824; 5 Feb 1992 10:13:16-0500 Date: Wed, 5 Feb 1992 10:13-0500 From: Scott McKay Subject: Common-Lisp for Amiga To: curt@eraserhead.jpl.nasa.gov cc: clim@BBN.COM In-Reply-To: <9202051358.AA08200@eraserhead.Jpl.Nasa.Gov> Message-ID: <19920205151330.0.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Wed, 5 Feb 1992 08:58 EST From: Curt Eggemeyer Does anybody know of a decent common-lisp for the Amiga? I know of no such thing. Is there a hope for a CLIM port? Unless someone volunteers to do it for free, there is no hope. I can't imagine that any of the vendors in the consortium can justify the work.   Received: from BBN.COM by LABS-N.BBN.COM id aa22646; 5 Feb 92 21:03 EST Received: from hyper.franz.com by BBN.COM id aa01769; 5 Feb 92 20:59 EST Return-Path: Received: by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA26422; Wed, 5 Feb 92 17:54:00 PST Newsgroups: mail.clim Path: jdi From: "John D. Irwin" Subject: Re: Icons for Clim-Windows Message-Id: <1992Feb6.015354.26378@franz.com> Sender: news@franz.com Nntp-Posting-Host: sparky Organization: Franz Incorporated, Berkeley CA References: <19920203181353.9.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Thu, 6 Feb 1992 01:53:54 GMT Apparently-To: clim@bbn.com In article <19920203181353.9.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Scott McKay writes: > (make-application-frame > 'application > :parent > (open-root-window :clx :host host) > :width *initial-width* > :height *initial-height*))) > > Now I want to know which is the name of the window exposed on the X-display, > so that you could use special icons. > > (.mwmrc > ... > Mwm**iconImage: > ) I'm not sure about the implementation of CLIM you're using, but in general the name of the application (in the X11 sense) is the pretty-name of the application-frame. (More specifically it is the window-label of the application-frame's top level window, or "CLIM Window" if the window has no label). The easiest way to discover the actual name is with the X11 program 'xprop'. Just run it and click on the CLIM window to find out its WM_NAME property. This is what you should use to customize mwm. -- jdi   Received: from BBN.COM by LABS-N.BBN.COM id aa01592; 6 Feb 92 13:52 EST Received: from iraun1.ira.uka.de by BBN.COM id aa16707; 6 Feb 92 13:41 EST Received: from gate.fzi.de by iraun1.ira.uka.de id aa02725; 6 Feb 92 8:56 MET Received: from goldfinger.fzi.de by gate.fzi.de.fzi.de id aa25923; 6 Feb 92 8:01 GMT Date: Thu, 6 Feb 92 8:01:27 GMT From: Rainer Koenig To: jdi@franz.com cc: clim@BBN.COM Subject: Re: Icons for Clim-Windows At: Forschungszentrum Informatik an der Universitaet Karlsruhe Address: Haid-und-Neu-Strasse 10-14, 75 Karlsruhe 1, Germany > In article <19920203181353.9.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Scott McKay writes: > > (make-application-frame > > 'application > > :parent > > (open-root-window :clx :host host) > > :width *initial-width* > > :height *initial-height*))) > > > > Now I want to know which is the name of the window exposed on the X-display, > > so that you could use special icons. > > > > (.mwmrc > > ... > > Mwm**iconImage: > > ) > > I'm not sure about the implementation of CLIM you're using, but in general > the name of the application (in the X11 sense) is the pretty-name of > the application-frame. (More specifically it is the window-label of > the application-frame's top level window, or "CLIM Window" if the window > has no label). > > The easiest way to discover the actual name is with the X11 program 'xprop'. > Just run it and click on the CLIM window to find out its WM_NAME property. > This is what you should use to customize mwm. > > -- jdi To customize mwm you have to use the WM-CLASS of the X11 window. With the WM_NAME property you have no success. An example for this is the following: xterm -name XTermIV -n 'Fantomas' -T 'Fantomas' In this case WM_NAME is "Fantomas" but the WM-CLASS is "XTermIV" In the above case (window or application-frame) no WM-CLASS is specified. (I tried 'xprop', 'xlsclients', 'xwininfo'. Using twm and the F.IDENTIFY function supply Class.res_name = "Untitled" Class.res_class = "Untitled") Rainer P.S. I actually use CLIM 1.0 on an Ivory-board I haven't tried it on allegro up to now -- Rainer Koenig email: rkoenig@fzi.de Forschungszentrum Informatik king@fzi.de Abtl. Technische Expertensysteme und Robotik Haid-und-Neu-Strasse 10-14 Fax : +49-721-9654-309 D - 7500 Karlsruhe 1 Tel.: +49-721-9654-313   Received: from BBN.COM by LABS-N.BBN.COM id aa01596; 6 Feb 92 13:52 EST Received: from iraun1.ira.uka.de by BBN.COM id ab16707; 6 Feb 92 13:42 EST Received: from gate.fzi.de by iraun1.ira.uka.de id aa06077; 6 Feb 92 12:10 MET Received: from bonnie.fzi.de by gate.fzi.de.fzi.de id aa00659; 6 Feb 92 11:15 GMT Date: Thu, 6 Feb 92 11:13:45 GMT From: Ralf Nikolai To: clim@BBN.COM Subject: accept Organization: Forschungszentrum Informatik FZI Hello CLIMers, I have just another problem with accept inside an accepting value. It works fine, if you enter values from the wanted presentation-type, but it works not very fine, if you enter wrong-type values (e.g. 1/2 where CLIM expects an integer) CLIM writes: The input read, 1/2, was not an integer. Please edit your input. 1/2 O.K. But any other output (of other accepts in the same accepting-value-macro) is over-written. That doesn't look very nice. To get the feeling just start the test-code (from the CLIM-manual), click on 'Set Time' and enter 1/2 for month. Any hints to avoid this effect? Future thanks, Ralf. P.S.: The test-code ;;; -*- Package: CLIM-USER; Syntax: Common-Lisp; Base: 10 -*- (defun reset-clock (stream) (multiple-value-bind (second minute hour day month) (decode-universal-time (get-universal-time)) (declare (ignore second)) (format stream "Enter the time~%") (conditions:restart-case (progn (clim:accepting-values (stream) (setq month (clim:accept 'integer :stream stream :default month :prompt "Month")) (terpri stream) (setq day (clim:accept 'integer :stream stream :default day :prompt "Day")) (terpri stream) (setq hour (clim:accept 'integer :stream stream :default hour :prompt "Hour")) (terpri stream) (setq minute (clim:accept 'integer :stream stream :default minute :prompt "Minute"))) (format t "~%New values: Month: ~D, Day: ~D, Time: ~D:~2,'0D." month day hour minute)) (abort () (format t "~&Time not set"))))) (define-application-frame myapp () () (:panes ((menu :command-menu) (main :application :scroll-bars nil ; :vertical :display-function 'display-main :display-after-commands nil) (interactor :interactor))) (:layout ((main (:column :rest (menu :compute) (main 3/4) (interactor :rest)))))) (defmethod display-main ((frame myapp) stream) (declare (ignore stream))) (define-myapp-command (com-myapp-set-time :name t :menu "Set Time") () (reset-clock (get-frame-pane *application-frame* 'main))) (define-myapp-command (com-myapp-exit :name t :menu "Exit") () (let ((window (frame-top-level-window *application-frame*))) (window-clear window) (setf (window-visibility window) nil) (window-visibility window) (frame-exit *application-frame*))) (defvar *clim-root* (clim:open-root-window :sheet)) (defun run () (let ((tach (clim:make-application-frame 'MYAPP :parent *clim-root* :left 50 :right 850 :top 50 :bottom 700))) (setf (output-recording-stream-output-record (get-frame-pane tach 'main)) (make-instance 'clim::linear-output-record)) (process:process-run-function "task" #'clim:run-frame-top-level tach)))   Received: from BBN.COM by LABS-N.BBN.COM id aa02953; 6 Feb 92 15:48 EST Received: from elroy.jpl.nasa.gov by BBN.COM id aa23818; 6 Feb 92 15:42 EST Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA28804; Thu, 6 Feb 92 12:42:05 PST Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA08892; Thu, 6 Feb 92 12:36:58 PST Date: Thu, 6 Feb 92 12:36:58 PST From: Curt Eggemeyer Message-Id: <9202062036.AA08892@eraserhead.Jpl.Nasa.Gov> To: clim@BBN.COM Subject: Re: accept From: Ralf Nikolai To: clim@BBN.COM Subject: accept Organization: Forschungszentrum Informatik FZI Status: R Hello CLIMers, I have just another problem with accept inside an accepting value. It works fine, if you enter values from the wanted presentation-type, but it works not very fine, if you enter wrong-type values Yeah, I have that problem too. Hopefully, in the newer versions of CLIM they will pop up notification windows on accept parse-error situations and just leave the cursor where it is.   Received: from BBN.COM by LABS-N.BBN.COM id aa03402; 6 Feb 92 16:26 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa26022; 6 Feb 92 16:18 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 421973; 6 Feb 1992 15:31:02-0500 Date: Thu, 6 Feb 1992 15:31-0500 From: Scott McKay Subject: accept To: nicolai@gate.fzi.de, clim@BBN.COM In-Reply-To: The message of 6 Feb 1992 06:13 EST from Ralf Nikolai Message-ID: <19920206203117.6.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Thu, 6 Feb 1992 06:13 EST From: Ralf Nikolai Hello CLIMers, I have just another problem with accept inside an accepting value. It works fine, if you enter values from the wanted presentation-type, but it works not very fine, if you enter wrong-type values (e.g. 1/2 where CLIM expects an integer) CLIM writes: The input read, 1/2, was not an integer. Please edit your input. 1/2 O.K. But any other output (of other accepts in the same accepting-value-macro) is over-written. That doesn't look very nice. To get the feeling just start the test-code (from the CLIM-manual), click on 'Set Time' and enter 1/2 for month. Any hints to avoid this effect? There's nothing you can do. It needs to be fixed inside of CLIM, but on some losing hosts (like Genera, which I use), the fix is even worse than the cure. With any luck, we will think of something before CLIM 2.0 comes out.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa04199; 6 Feb 92 17:30 EST Received: by KARIBA.BBN.COM id aa26664; 6 Feb 92 17:12 EST From: Dan Cerys Organization: Bolt Beranek and Newman Inc. To: curt@eraserhead.jpl.nasa.gov CC: clim@BBN.COM, kanderson@BBN.COM In-reply-to: Curt Eggemeyer's message of Thu, 6 Feb 92 12:36:58 PST <9202062036.AA08892@eraserhead.Jpl.Nasa.Gov> Subject: accept Date: Thu, 6 Feb 92 17:06:59 EST Sender: cerys@BBN.COM Date: Thu, 6 Feb 92 12:36:58 PST From: Curt Eggemeyer From: Ralf Nikolai To: clim@BBN.COM Subject: accept Organization: Forschungszentrum Informatik FZI Status: R Hello CLIMers, I have just another problem with accept inside an accepting value. It works fine, if you enter values from the wanted presentation-type, but it works not very fine, if you enter wrong-type values Yeah, I have that problem too. Hopefully, in the newer versions of CLIM they will pop up notification windows on accept parse-error situations and just leave the cursor where it is. We've been bothered by this for a while. Coincidentally, Ken Anderson has just finished some CLIM 0.9 support for exactly what you've described (a popup notification window that goes away as soon as you press Delete/Rubout). We'll forward this patch to the CLIM development team, and post it here in a few days (if there are no legal problems with this). Dan   Received: from BBN.COM by LABS-N.bbn.COM id aa27462; 11 Feb 92 14:36 EST Received: from Mail.Think.COM by BBN.COM id aa12486; 11 Feb 92 14:23 EST Return-Path: Received: from Think.COM by mail.think.com; Tue, 11 Feb 92 14:22:20 -0500 Received: from OCCAM.THINK.COM by Early-Bird.Think.COM; Tue, 11 Feb 92 14:22:13 EST Date: Tue, 11 Feb 1992 14:22-0500 From: Barry Margolin Subject: [eshook@franz.com: Re: ALU/LIC formation press release ] To: allegro-cl@berkeley.edu, clim@BBN.COM, common-lisp@mcc.com, commonloops@xerox.com, slug@ai.sri.com, alu-board@ai.sri.com Included-Msgs: <9202110214.AA24181@fridge.Franz.COM>, The message of 10 Feb 1992 21:14 EST from eshook@franz.com, The message of 10 Feb 1992 21:14 EST from Elizabeth Shook Included-References: <19920207202017.5.BARMAR@occam.think.com> Message-Id: <19920211192203.4.BARMAR@occam.think.com> ------Begin Forwarded Message------ To: Barry Margolin cc: eshook@franz.com Subject: Re: ALU/LIC formation press release In-Reply-To: Your message of Fri, 07 Feb 92 15:20:00 -0500. <19920207202017.5.BARMAR@occam.think.com> Date: Mon, 10 Feb 1992 21:14 EST From: Elizabeth Shook Barry, I'm sorry for the delay. I would really appreciate it if you could forward this online. I sent a hardcopy version on mocked-up ALU letterhead to an international press list. I hope we start to see some mentions in the next few months. NEWS FOR IMMEDIATE RELEASE Contacts: Celia Wolf Richard Billington Member President Lisp Industry Council Association of Lisp Users Gold Hill, Inc. Georgia Institute of Technology (617) 621-3300 (404) 894-3227 COMMON LISP VENDORS AND USERS UNITE TO PROMOTE LISP Association Supports New Common Lisp Standard January 1, 1992 -- The attendees of the first international Lisp Users and Vendors Conference (LUV-91) voted to form the Association of Lisp Users (ALU). At the same conference, the major Common Lisp vendors formed the Lisp Industry Council (LIC). The ALU and the Lisp Industry Council will promote the use of Lisp for commercial, research, and academic applications. "The formation of these two organizations signals a maturation of the Lisp market," said Celia Wolf, a representative of the Lisp Industry Council. "Both vendors and users realize that cooperation among diverse organizations is essential to the continued growth of the Lisp community. Together, we will promote the benefits of Lisp as a powerful and cost-effective language for high-level programming." The Lisp Industry Council includes members of the following organizations: Apple Computer, College Park Software, Franz Inc., Gold Hill, Inc., Harlequin Ltd., Ibuki Inc., Lucid, Inc., Symbolics, Inc., and Venue Inc. The organization will manage joint public relations activities, promote the standardization process, and assist in organizing future Lisp conferences. The next Lisp User and Vendor (LUV-92) conference will be held in San Diego, CA, August 10-14, 1992. Both the ALU and the Lisp Industry Council will work to build ties to international Lisp organizations such as JEIDA (Japanese Electronic Industry Development Association), which sponsored the recent Japanese Practical Applications of Lisp (JPAL) conference, and EuroPAL (European Practical Applications of Lisp), an association of European Lisp users which produces a quarterly newsletter and technical seminars. Jim Aragones, ALU Board Vice President said, "This organization demonstrates the continued vibrancy of the Lisp community. Just as Usenix provides a user forum for Unix, the ALU does the same thing for Lisp." The ALU represents a broad-based user community in line with the current diversity of the Lisp market. The group provides users with a forum for sharing experiences, a clearinghouse of product and application information, and the ability to drive vendor priorities and standards. While many members of the ALU are users of Common Lisp, the organization is open to users of all dialects of Lisp. Special interest groups will be formed to meet the needs of specific dialect users, such as Scheme. The software development community is becoming more enlightened about the ability of Lisp to facilitate program development and maintenance. Lisp is used for such successful commercial applications as AutoCAD and Interleaf publishing software. Both products feature powerful extension languages based on Lisp, known respectively as AutoLisp and Interleaf Lisp. Fortune 500 companies continue to invest heavily in commercial applications ranging from credit approval and airport scheduling to logistics management for the U.S. Army. In one case, the system saves $2 per credit check; in another, the system ensured that the Desert Storm action had sufficient resources. In addition, several major universities have recently adopted Common Lisp and Scheme into their curriculum for introductory computer science courses. ANSI is expected to begin finalization of the Common Lisp standard in 1992. Most memmbers of the ALU and Lisp Industry Council fully support the new standard, which will permit increased interoperability and portability for Lisp applications. Lisp has a long history of successfully adopting new programming paradigms as they emerge from computer language research centers. The ALU and the Lisp Industry Council will continue to promote the incorporation of new programming technology into Lisp so that it is available for cutting edge commercial applications. Both organizations will release specific plans and programs over the next few months. Additional Contacts for further information: Jim Aragones LUV '92 Conference Chairman ALU Board Vice President GE Corporate R&D slug-vp@ai.sri.com (518)387-6967 Peter Van Sickel ALU Board Secretary Alcoa Technical Center pvs@al.alcoa.com (412)337-5926 Masayuki Ida ALU Board Member Vice President, Symbolics Lisp User Group - Japan Aoyama Gakuin University, JAPAN ida@csrl.aoyama.ac.jp Phone: +81-3-3400-1546 Fax: +81-3-3498-4870 ------End Forwarded Message------   Received: from BBN.COM by LABS-N.bbn.COM id aa27826; 11 Feb 92 15:13 EST Received: from corwin.ccs.northeastern.edu by BBN.COM id aa14132; 11 Feb 92 14:55 EST Received: by corwin.ccs.northeastern.edu (5.61+++/SMI-3.2+CCS-mx-2.9) id AA07540; Tue, 11 Feb 92 14:56:09 -0500 Date: Tue, 11 Feb 92 14:56:09 -0500 From: robert futrelle Message-Id: <9202111956.AA07540@corwin.ccs.northeastern.edu> To: clim@BBN.COM Subject: 3 button mouse in MCL CLIM? What is the status of 3-button mouse support in MCL and CLIM for MCL? Logitech makes the 3-button Mouseman now (primarily for Mac X applications). But for portability it would be nice to use 3 buttons on all CLIM applications, SMBLX, Suns, Macs, etc. bob futrelle   Received: from BBN.COM by LABS-N.bbn.COM id aa02998; 12 Feb 92 0:03 EST Received: from Sunset.AI.SRI.COM by BBN.COM id aa21716; 11 Feb 92 23:59 EST Received: from Dillon.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA19540 for clim@bbn.com; Tue, 11 Feb 92 21:00:28 PST Received: by Dillon.AI.SRI.COM (4.1/SMI-4.1) id AA22046 for clim@bbn.com; Tue, 11 Feb 92 21:00:26 PST Date: Tue 11 Feb 92 21:00:25-PST From: Mabry Tyson Subject: CLIM via X on 2 megapixel screens To: clim@BBN.COM Message-Id: <697870826.0.TYSON@AI.SRI.COM> Mail-System-Version: Maybe I can figure this out but it is sure easier to ask this list in case someone else has done it. We've just tried to run CLIM on a 2 megapixel (ie, high resolution) Sun screen and the fonts are inappropriately sized (tiny). This is under open windows and olwm. He has a .Xresources to handle his other programs that specifies *font. How can we get the CLIM fonts to be more reasonably sized on the machine for that user? P.S. While I'm on the subject, I would like to start up CLIM windows via the X server on my Symbolics (CLIM would be running on a Sun somewhere). The reponse is generally poor but the loading (and reloading and reloading) of fonts is quite intolerable. Anyone know some way to load those fonts once and for all? -------   Received: from BBN.COM by LABS-N.bbn.COM id aa08078; 12 Feb 92 9:21 EST Received: from elroy.jpl.nasa.gov by BBN.COM id aa10797; 12 Feb 92 9:10 EST Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA17876; Wed, 12 Feb 92 06:10:43 PST Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA09921; Wed, 12 Feb 92 06:05:30 PST Date: Wed, 12 Feb 92 06:05:30 PST From: Curt Eggemeyer Message-Id: <9202121405.AA09921@eraserhead.Jpl.Nasa.Gov> To: clim@BBN.COM Subject: Weird top-level accept symptom As per my earlier message. (I'm on a Sun using Clim 1.0 in Allegro CL) In my application frame I somethings get caught in a weird recursive type accept problem. It seems that somehow the top-level accept loop in the application frame sometimes starts in a deeper recursive call on accept when you enter top level commands for the application. It shows up after some commands have already been entered and executed on the application and at some point you hit the debugger (so you can either pop or abort out). Afterwards when I try and type in another application command as you type in the characters (including trying to do completion via the space bar) the cursor all of a sudden moves to another line in my interactor pane and continues to echo out the characters of the command. Only the accept now thinks that those characters entered on the new line are the beginning of a new command (from this point on the top-level accept loop in the application frame is screwed for keyboard input). So, if I try and rubout those characters I randomly get beeped and it ignores the rubout. However, if I do positioning of the cursor ala control characters the cursor sometimes jumps up to the original line and starts editing on that character string. From that point on the cursor randomly jumps back and forth between the two lines and never lets me successfully remove all of the characters in both lines. If I abort out of entering the command, from that point on the top-level accept will continually fail to accept my commands via the keyboard. Menu commands are still available and will echo correctly in the interactor pane, but any keying in of commands will now fail as described above. The only way for me to recover is to blow out the application frame and re-instantiate a whole new one. Another weird symptom is sometimes my interactor pane will lose the ability to echo characters out (including the command prompt) (I think the ink has somehow been flipped because I notice the cursor moving). Here's something I found. Does anybody have the same problem if they do the following? ;-------------------------------------------------------------------------- We'll I findly was able to find a way to reproduce the same symptom. If you are in X you can have fun blowing CLIM's command accept in your application frame by the following method. From the LISP listener invoke your application from a process-run-function, after you have instantiated it into some global, lets say *my-application*. Now start the application like so; (process-run-function (list :name "My application") 'run-frame-top-level *my-application*) Okay, your application is up on the display. Now go to the title bar for that application and bring up the x-menu and select "Close" from it. This will now close the application display into an icon. Go back into the lisp listener and reinvoke the same process-run-function form. At this point any attempt at invoking application commands in the top-level accept will exhibit the same symptoms I have indicated above. I think I only hit these problems after I hit the debugger, while I am working in some of my application commands. Apparently, there is a random chance that when you pop or abort out of the debugger while in your application you can screw your application command's top-level accept. The only recourse is to kill that application and resinstantiate a new one. Gee, if only there was a function in which you can totally flush out the top-level accept in your application when it loses its input buffer positioning.   Received: from BBN.COM by LABS-N.bbn.COM id aa09448; 12 Feb 92 11:13 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa17087; 12 Feb 92 11:03 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 422678; 12 Feb 1992 11:02:27-0500 Date: Wed, 12 Feb 1992 11:01-0500 From: Scott McKay Subject: Weird top-level accept symptom To: curt@eraserhead.jpl.nasa.gov, clim@BBN.COM In-Reply-To: <9202121405.AA09921@eraserhead.Jpl.Nasa.Gov> Message-ID: <19920212160138.9.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Wed, 12 Feb 1992 09:05 EST From: Curt Eggemeyer As per my earlier message. (I'm on a Sun using Clim 1.0 in Allegro CL) In my application frame I somethings get caught in a weird recursive type accept problem. It seems that somehow the top-level accept loop in the application frame sometimes starts in a deeper recursive call on accept when you enter top level commands for the application. It shows up after some commands have already been entered and executed on the application and at some point you hit the debugger (so you can either pop or abort out). Afterwards when I try and type in another application command as you type in the characters (including trying to do completion via the space bar) the cursor all of a sudden moves to another line in my interactor pane and continues to echo out the characters of the command. Only the accept now thinks that those characters entered on the new line are the beginning of a new command (from this point on the top-level accept loop in the application frame is screwed for keyboard input). So, if I try and rubout those characters I randomly get beeped and it ignores the rubout. However, if I do positioning of the cursor ala control characters the cursor sometimes jumps up to the original line and starts editing on that character string. From that point on the cursor randomly jumps back and forth between the two lines and never lets me successfully remove all of the characters in both lines. If I abort out of entering the command, from that point on the top-level accept will continually fail to accept my commands via the keyboard. Menu commands are still available and will echo correctly in the interactor pane, but any keying in of commands will now fail as described above. The only way for me to recover is to blow out the application frame and re-instantiate a whole new one. Another weird symptom is sometimes my interactor pane will lose the ability to echo characters out (including the command prompt) (I think the ink has somehow been flipped because I notice the cursor moving). It sounds to me like you might have executed some presentation action (not a translator, an action) that is going back to the application's command loop. If this is the case, the action is in error; actions should never terminate input. Here's something I found. Does anybody have the same problem if they do the following? ;-------------------------------------------------------------------------- We'll I findly was able to find a way to reproduce the same symptom. If you are in X you can have fun blowing CLIM's command accept in your application frame by the following method. From the LISP listener invoke your application from a process-run-function, after you have instantiated it into some global, lets say *my-application*. Now start the application like so; (process-run-function (list :name "My application") 'run-frame-top-level *my-application*) Okay, your application is up on the display. Now go to the title bar for that application and bring up the x-menu and select "Close" from it. This will now close the application display into an icon. Go back into the lisp listener and reinvoke the same process-run-function form. At this point any attempt at invoking application commands in the top-level accept will exhibit the same symptoms I have indicated above. I think I only hit these problems after I hit the debugger, while I am working in some of my application commands. Apparently, there is a random chance that when you pop or abort out of the debugger while in your application you can screw your application command's top-level accept. The only recourse is to kill that application and resinstantiate a new one. Gee, if only there was a function in which you can totally flush out the top-level accept in your application when it loses its input buffer positioning. If you can get into a debugger, CLIM does establish a restart handler that reinvokes the application from the top. Also, the so-called CLIM 1.1 (which a number of companies are about to release) will contain some improvements to the CLX port w.r.t. its interactions with screen managers. This should fix some other problems.   Received: from BBN.COM by LABS-N.bbn.COM id aa10560; 12 Feb 92 13:01 EST Received: from hyper.franz.com by BBN.COM id aa22310; 12 Feb 92 12:57 EST Return-Path: Received: from vapor.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA22568; Wed, 12 Feb 92 09:56:52 PST Received: by vapor.Franz.COM (4.1/FI-2.0) id AA06200; Wed, 12 Feb 92 09:57:07 PST Message-Id: <9202121757.AA06200@vapor.Franz.COM> To: Mabry Tyson Cc: clim@BBN.COM In-Reply-To: Your message of Wed, 12 Feb 92 09:28:48 PST. <9202121728.AA05518@vapor.Franz.COM> Date: Wed, 12 Feb 92 09:57:06 -0800 From: Chris Richardson I believe that the original CLX backend did not take into account the resolution of the display when selecting fonts. This has been changed in later versions. Also, in the latest CLX backend, the way the fonts are obtained has been changed and so opening a CLX root window is now substantially faster. I imagine that these changes should eventually be incorporated into the CLIM supplied by your particular vendor. ----- Chris Richardson, Franz Inc. 1995 University Avenue, Suite 275 cer@Franz.COM (internet) Berkeley, CA 94704 uunet!franz!cer (uucp) Phone: (510) 548-3600; FAX: (510) 548-8253   Received: from BBN.COM by LABS-N.bbn.COM id aa11222; 12 Feb 92 13:59 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa25167; 12 Feb 92 13:54 EST Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 422695; 12 Feb 1992 13:53:36-0500 Date: Wed, 12 Feb 1992 13:53-0500 From: Scott McKay Subject: CLIM 1.1 To: cer@franz.com, TYSON@ai.sri.com cc: clim@BBN.COM In-Reply-To: <9202121757.AA06200@vapor.Franz.COM> Message-ID: <19920212185300.0.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: Wed, 12 Feb 1992 12:57 EST From: Chris Richardson I believe that the original CLX backend did not take into account the resolution of the display when selecting fonts. This has been changed in later versions. Also, in the latest CLX backend, the way the fonts are obtained has been changed and so opening a CLX root window is now substantially faster. I imagine that these changes should eventually be incorporated into the CLIM supplied by your particular vendor. In fact, I have already redistributed these changes to ILA (who will be using them in MCL, and should be sending them to Harlequin) and to Lucid. I believe that Lucid is in the process of packaging up a new version of CLIM, and will be releasing it soon. I believe the Franz will also soon be releasing a CLIM 1.1. It is certainly true that Symbolics is now testing CLIM 1.1 (to run under Genera 8.1+) and will be releasing it soon. (By the way, I am not a spokesman, official or otherwise, for ILA, Franz, or Lucid, so take what I say with a grain of salt; apologies to them if I am making any mis-statements.) In addition to these CLX fixes, CLIM 1.1 also has probably about two hundred bugfixes and small enhancements beyond CLIM 1.0. Many of these improvements were made in response to mail on this mailing list.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa11413; 12 Feb 92 14:18 EST To: Mabry Tyson cc: clim@BBN.COM Subject: Re: CLIM via X on 2 megapixel screens In-reply-to: Your message of Tue, 11 Feb 92 21:00:25 -0800. <697870826.0.TYSON@AI.SRI.COM> Date: Wed, 12 Feb 92 14:01:57 -0500 From: kanderso@BBN.COM Date: Tue 11 Feb 92 21:00:25-PST From: Mabry Tyson Subject: CLIM via X on 2 megapixel screens To: clim@BBN.COM Mail-System-Version: Maybe I can figure this out but it is sure easier to ask this list in case someone else has done it. We've just tried to run CLIM on a 2 megapixel (ie, high resolution) Sun screen and the fonts are inappropriately sized (tiny). This is under open windows and olwm. He has a .Xresources to handle his other programs that specifies *font. How can we get the CLIM fonts to be more reasonably sized on the machine for that user? Dan Cerys had the following idea, which he didn't implement, because he didn't need to. CLIM parses the X logical font descriptions (see X Protocol Reference Manual, appendix M) using the pixel_size. He suggests it would be better to use point_size which is resolution independent. Of course, it is possible that Openwin does not have any fonts appropriate for your resolution. One problem we had when going from X11 to Openwin was that the way the fonts were being wildcarded produced a more squished together font in Openwin then in X11. We were able to get around this by only selecting adobe fonts, which works fine for us. k   Received: from BBN.COM by LABS-N.BBN.COM id aa13310; 12 Feb 92 16:35 EST Received: from iraun1.ira.uka.de by BBN.COM id aa03764; 12 Feb 92 16:21 EST Received: from gate.fzi.de by iraun1.ira.uka.de id aa27587; 12 Feb 92 22:18 MET Received: from ossi.fzi.de by gate.fzi.de.fzi.de id aa17770; 12 Feb 92 21:19 GMT Date: Wed, 12 Feb 92 21:22:06 GMT From: Ralf Nikolai To: clim@BBN.COM Subject: updating-error Organization: Forschungszentrum Informatik FZI Hello CLIMers, I found some amazing error (?) with updating-output. The update of the first pane (vehicle, see listing below) in my define-application-frame doesn't work correct, things aren't updated. If I insert some pane before the 'error'-pane in :panes - without doing anything with this additional pane, it stays invisible - the code works! You can compile the following example, type (init ) to get the initial window, then type (show-info-window '(1 2 3 4)) to get the error (not updated pane). Ralf Nikolai email: nicolai&fzi.de P.S.: My platform is a SYMBOLICS UX1200S with CLIM1.0. ;;; -*- Package: CLIM-USER; Mode: LISP; Syntax: Common-Lisp -*- (define-application-frame up () (;;ift-Element (done-sections :initform '(1 2 3) :accessor done-sections)) (:panes ( ; (why :application ;To avoid the ; :scroll-bars nil ;error ; :display-function 'display-why ;uncomment ; :incremental-redisplay t ;these 5 ; :display-after-commands nil) ;lines! (vehicle :application :scroll-bars nil :display-function 'display-vehicle-pane :incremental-redisplay t :display-after-commands nil) (time :application :scroll-bars nil :display-function 'display-why :display-after-commands nil) (fix-time :application :scroll-bars nil :display-function 'display-why :display-after-commands nil) (speed :application :scroll-bars nil :display-function 'display-why :display-after-commands nil) (done :application :scroll-bars nil :display-function 'display-why :incremental-redisplay t :display-after-commands nil) (to-do :application :scroll-bars nil :display-function 'display-why :incremental-redisplay t :display-after-commands nil) (message :application :scroll-bars nil :display-function 'display-why :incremental-redisplay t :display-after-commands nil) (reaction :application :scroll-bars nil :display-function 'display-why :incremental-redisplay t :display-after-commands nil) (menu :command-menu))) (:layout ((main (:column :rest (vehicle 1/10) (time 1/15) (:row :rest (:column :rest (fix-time 1/4) (done 3/8) (message :rest)) (:column :rest (speed 1/4) (to-do 3/8) (reaction :rest))) (menu :compute)))))) (defvar *up* nil) (defmethod display-why ((frame up) stream) (declare (ignore stream))) (defmethod display-vehicle-pane ((frame up) stream) (with-slots (done-sections) frame (updating-output (stream :unique-id ':done-title :cache-value 0 :cache-test #'=) (format stream "~% Sections: ")) (let ((i 1) (n-len (floor (/ (window-inside-width stream) (stream-string-width stream "12345 "))))) (with-end-of-line-action (:allow stream) (dolist (section done-sections) (updating-output (stream :unique-id section :cache-value section :cache-test #'eql) (format stream " ~A" section) (when (= (mod i n-len) 0) (format stream "~%")) (setf i (1+ i)))))))) (define-up-command (com-up-exit :name t :menu "EXIT") () (let ((window (frame-top-level-window *up*))) (window-clear window) (setf (window-visibility window) nil) (window-visibility window) (frame-exit *up*))) (defvar *my-clim-root* nil) (defun show-info-window (some-list) (let ((window (frame-top-level-window *up*))) (setf (done-sections *up*) some-list) (redisplay-frame-pane *up* 'vehicle) (redisplay-frame-pane *up* 'done) (redisplay-frame-pane *up* 'to-do) (redisplay-frame-pane *up* 'message) (redisplay-frame-pane *up* 'reaction) (setf (window-visibility window) t) (window-visibility window))) (defun init (&key (host "ossi")) (setf *my-clim-root* (clim:open-root-window :clx :host host) *up* (clim:make-application-frame 'up :parent *my-clim-root* :left 50 :right 900 :top 0 :bottom 700) (output-recording-stream-output-record (get-frame-pane *up* 'time)) (make-instance 'clim::linear-output-record) (output-recording-stream-output-record (get-frame-pane *up* 'fix-time)) (make-instance 'clim::linear-output-record) (output-recording-stream-output-record (get-frame-pane *up* 'speed)) (make-instance 'clim::linear-output-record)) (process:process-run-function "up" #'clim:run-frame-top-level *up*))   Received: from BBN.COM by LABS-N.BBN.COM id aa15560; 12 Feb 92 20:35 EST Received: from lucid.com by BBN.COM id aa12417; 12 Feb 92 20:29 EST Received: from kuwait.lucid ([192.31.212.118]) by heavens-gate.lucid.com id AA09201g; Wed, 12 Feb 92 17:25:13 PST Received: by kuwait.lucid (4.1/SMI-4.1) id AA10554; Wed, 12 Feb 92 17:29:40 PST Date: Wed, 12 Feb 92 17:29:40 PST From: John Kern Message-Id: <9202130129.AA10554@kuwait.lucid> To: TYSON@ai.sri.com Cc: clim@BBN.COM Subject: CLIM via X on 2 megapixel screens Reply-To: kern@lucid.com Howdy, The forthcoming release of Lucid CLIM 1.0 will have the fixes/enchancements Chris Richardson and Scott McKay mentioned. Sincerely, John S. Kern Lucid, Inc. Customer Support   Received: from BBN.COM by LABS-N.BBN.COM id aa27028; 13 Feb 92 17:15 EST Received: from [150.109.4.177] by BBN.COM id aa22507; 13 Feb 92 17:01 EST Received: by sauron (4.1/1.27) id AA00563; Thu, 13 Feb 92 14:02:09 PST Date: Thu, 13 Feb 92 14:02:09 PST From: Mike Meehan Message-Id: <9202132202.AA00563@sauron> To: clim@BBN.COM Subject: com menu align... I am trying to figure out how to left justify a command menu within the entire width of the current column... It defaults centered, i.e., ---------------------------------------------------------- | | | Exit | <-- CMD menu | | |---------------------------------------------------------| | | | | | | | | | | | | | | <-- App Pane | | | | | | | | | | | | | | | | | | |---------------------------------------------------------| What I have done is to use the following def for the command menu: (:panes ... (com-menu :command-menu :display-function `(clim:display-command-menu :max-width 40) . . . I get the max-width number from trial and error... Obviously this is a weak fix. Are there other layout tools/options that I have missed? Thanks in advance... -MM Mike Meehan Manager, Simulation Optimization Technology Group EEsof Inc., R&D Department 5601 Lindero Canyon Road Westlake Village CA. 91362 FAX/VOICE: 818.879.6374 mmeehan@eesof.com   Received: from BBN.COM by LABS-N.BBN.COM id aa03966; 14 Feb 92 10:21 EST Received: from [130.49.32.198] by BBN.COM id aa17461; 14 Feb 92 10:06 EST Received: from localhost by fen.lrdc.pitt.edu (5.65/Ultrix3.0-C) id AA10448; Fri, 14 Feb 92 10:06:54 -0500 Message-Id: <9202141506.AA10448@fen.lrdc.pitt.edu> To: clim@BBN.COM Subject: editing a string default Date: Fri, 14 Feb 92 10:06:51 EST From: martin@fen.lrdc.pitt.edu Hi, When in an (accept 'string . . ., I know it is possible for a user to type ctrl-meta-y to edit a default. However, I would like the default to automatically appear for editing with the cursor at the end (before the user does anything). Also, I don't want to show a prompt or display-default, only an editable default. Is that possible? Thanks, Joel Martin CS Pitt (LRDC)   Received: from BBN.COM by LABS-N.BBN.COM id aa05122; 14 Feb 92 12:10 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa23855; 14 Feb 92 11:56 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 422894; 14 Feb 1992 11:55:39-0500 Date: Fri, 14 Feb 1992 11:55-0500 From: Scott McKay Subject: editing a string default To: martin@fen.lrdc.pitt.edu, clim@BBN.COM In-Reply-To: <9202141506.AA10448@fen.lrdc.pitt.edu> Message-ID: <19920214165527.1.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 14 Feb 1992 10:06 EST From: martin@fen.lrdc.pitt.edu Hi, When in an (accept 'string . . ., I know it is possible for a user to type ctrl-meta-y to edit a default. However, I would like the default to automatically appear for editing with the cursor at the end (before the user does anything). Also, I don't want to show a prompt or display-default, only an editable default. Is that possible? CLIM 1.1 (and hence CLIM 2.0) will include a :INSERT-DEFAULT keyword that does what you want.   Received: from BBN.COM by LABS-N.BBN.COM id aa05124; 14 Feb 92 12:10 EST Received: from gatech.edu by BBN.COM id aa24073; 14 Feb 92 11:59 EST Received: from cc.gatech.edu (hermes.cc.gatech.edu) by gatech.edu (4.1/Gatech-9.1) id AA15626 for clim@bbn.com; Fri, 14 Feb 92 11:59:30 EST Received: from pravda.cc.gatech.edu by cc.gatech.edu (3.2/SMI-3.2) id AA01881; Fri, 14 Feb 92 11:57:45 EST Received: from kant.gatech.edu (kant.cc.gatech.edu) by pravda.cc.gatech.edu (4.1/SMI-4.1) id AA08143; Fri, 14 Feb 92 11:50:06 EST Date: Fri, 14 Feb 1992 11:59-0500 From: Richard Billington Subject: Implementation approach advice ... To: clim@BBN.COM Message-Id: <19920214165911.8.BUFF@kant.gatech.edu> I have a bunch of nitty-gritty questions about clim capablities, but I think its easier to give me a hand by knowing what I'm trying to do overall, and suggesting an approach. What follows is an informal spec of what I want, followed by a brief sketch of the approaches I've considered. If you have an idea for another approach, please pass it on to me. Any help, perspective, suggestions, etc, is GREATLY appreciated. Informal specification: A class of pane called an annotation-pane. It enables me to have a scrollable central window with margins (on 1 - 4 sides) which contain annotations. The annotations in the margin are connected (graphically, by a line) to points in the central window. (USE: Imagine a blueprint with annotations in the margins pointing to various features - on a computer screen the blueprint needs to be scrollable, and the annotations need to change to reflect the part of the blueprint you can see) This means that the scroll bars for the central window need to be on the outside of the annotations (on the outside of the pane) so that drawing the connecting lines doesn't try to draw over the scroll bars. I need to know when the central region is scrolled, because I'll need to change where the annotation pointers point to, which annotation should be dumped because what they point to is no longer visible, and which new ones to put up. The size of annotations would be specified initially (in terms of a char limit - which must be less than the absolute number of characters that fit to allow for additional whitespace needed for filling) and then be able to fill in the annotation box with the annotation text (number of character limit imposed to try to minimize truncation problems, but truncate anything that overflows and let the author note and fix it). Finally, it would be nice to have control over where the annotation for a particular point on the central display is positioned - make it as close as possible, and keep it that way when the window is scrolled. Implementation Approaches: Given that having lines providing a strong, visual connection between the annotation and the thing being annotated is necessary, I've come up with three approaches: make this an application frame, the central display and annotations all being seperate windows; make a special window which has a very wide inside margin I can put annotations in, but which is not (directly) effected by scrolling; within a normal window, implement my own scrolling for a sub-region, and implement annotation margins, display boxes, etc. The advantage of the first approach is that I can output annotations to their own windows, and use predefined filling, truncating, etc functions - i.e. each annotation gets its own window stream. The disadvantage is that I'd have to implement scrolling for the inner window with something other than scroll bars. Also, I'd like to put an annotated pane into a larger frame, I don't know how easy it is to include and application pane within another application frame. The advantage of the second approach would be to avoid introducing my own, non-standard scrolling mechanism. The disadvantage is mostly I can't figure out how to do it without reaching pretty deep into clim - and, of course, I don't know how (at this point) point to reach into clim to do it, or even if its possible. The third approach has no advantages, other than not having to delve deeply into clim. I've done a lot of it this way once under DW - it got ugly, so I wouldn't re-use what I did, but I know I can do it this way.   Received: from BBN.COM by LABS-N.BBN.COM id ab07325; 14 Feb 92 15:45 EST Received: from [150.109.4.177] by BBN.COM id aa04265; 14 Feb 92 15:10 EST Received: by sauron (4.1/1.27) id AA01004; Fri, 14 Feb 92 12:10:40 PST Date: Fri, 14 Feb 92 12:10:39 PST From: Mike Meehan Message-Id: <9202142010.AA01004@sauron> To: clim@BBN.COM Subject: com menu align... I am trying to figure out how to left justify a command menu within the entire width of the current column... It defaults centered, i.e., ---------------------------------------------------------- | | | Exit | <-- CMD menu | | |---------------------------------------------------------| | | | | | | | | | | | | | | <-- App Pane | | | | | | | | | | | | | | | | | | |---------------------------------------------------------| What I have done is to use the following def for the command menu: (:panes ... (com-menu :command-menu :display-function `(clim:display-command-menu :max-width 40) . . . I get the max-width number from trial and error... Obviously this is a weak fix. Are there other layout tools/options that I have missed? Thanks in advance... -MM Mike Meehan Manager, Simulation Optimization Technology Group EEsof Inc., R&D Department 5601 Lindero Canyon Road Westlake Village CA. 91362 FAX/VOICE: 818.879.6374 mmeehan@eesof.com   Received: from BBN.COM by LABS-N.BBN.COM id aa07325; 14 Feb 92 15:44 EST Received: from lucid.com by BBN.COM id aa00898; 14 Feb 92 14:09 EST Received: from kuwait.lucid ([192.31.212.118]) by heavens-gate.lucid.com id AA16149g; Fri, 14 Feb 92 11:03:40 PST Received: by kuwait.lucid (4.1/SMI-4.1) id AA19345; Fri, 14 Feb 92 11:08:09 PST Date: Fri, 14 Feb 92 11:08:09 PST From: John Kern Message-Id: <9202141908.AA19345@kuwait.lucid> To: clim@BBN.COM Cc: clim-support@lucid.com Subject: What's in a name? Reply-To: kern@lucid.com There is some confusion in the use of the terms CLIM 1.0 and CLIM 1.1. For Lucid CLIM users, the functionality commonly referred to as CLIM 1.0 on this mailing list refers to Lucid CLIM 1.0 BETA. References to CLIM 1.1 are analogous Lucid CLIM 1.0. For example, Scott McKay recently mentioned a CLIM 1.1 enchancement to accept (ie, the :insert-default keyword). This will be included in the forthcoming release of Lucid CLIM 1.0. Sincerely, John S. Kern Lucid, Inc. Customer Support   Received: from BBN.COM by LABS-N.BBN.COM id aa08457; 14 Feb 92 17:26 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa12899; 14 Feb 92 17:12 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 422941; 14 Feb 1992 17:11:47-0500 Date: Fri, 14 Feb 1992 17:11-0500 From: Scott McKay Subject: com menu align... To: mmeehan@eesof.com, clim@BBN.COM In-Reply-To: <9202142010.AA01004@sauron> Message-ID: <19920214221140.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 14 Feb 1992 15:10 EST From: Mike Meehan I am trying to figure out how to left justify a command menu within the entire width of the current column... It defaults centered, i.e., ---------------------------------------------------------- | | | Exit | <-- CMD menu | | |---------------------------------------------------------| | | | | | | | | | | | | | | <-- App Pane | | | | | | | | | | | | | | | | | | |---------------------------------------------------------| What I have done is to use the following def for the command menu: (:panes ... (com-menu :command-menu :display-function `(clim:display-command-menu :max-width 40) Does :NO-INITIAL-SPACING T do the trick? I get the max-width number from trial and error... Obviously this is a weak fix. Are there other layout tools/options that I have missed? Thanks in advance... -MM Mike Meehan Manager, Simulation Optimization Technology Group EEsof Inc., R&D Department 5601 Lindero Canyon Road Westlake Village CA. 91362 FAX/VOICE: 818.879.6374 mmeehan@eesof.com   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa08245; 14 Feb 92 17:01 EST Received: by KARIBA.BBN.COM id ab25591; 14 Feb 92 16:46 EST To: Scott McKay cc: martin@fen.lrdc.pitt.edu, clim@BBN.COM Subject: Re: editing a string default In-reply-to: Your message of Fri, 14 Feb 92 11:55:00 -0500. <19920214165527.1.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 14 Feb 92 16:41:01 -0500 From: kanderso@BBN.COM Date: Fri, 14 Feb 1992 11:55-0500 From: Scott McKay Subject: editing a string default To: martin@fen.lrdc.pitt.edu, clim@BBN.COM Date: Fri, 14 Feb 1992 10:06 EST From: martin@fen.lrdc.pitt.edu Hi, When in an (accept 'string . . ., I know it is possible for a user to type ctrl-meta-y to edit a default. However, I would like the default to automatically appear for editing with the cursor at the end (before the user does anything). Also, I don't want to show a prompt or display-default, only an editable default. Is that possible? CLIM 1.1 (and hence CLIM 2.0) will include a :INSERT-DEFAULT keyword that does what you want. Here is a presentation type that we defined for CLIM 0.9 which does what you want, though it might be worth waiting. k #|| ;;; KRA 14:35 15NOV91: An editable-string presentation type that takes a :DEFAULT value you can edit (Originally from MDean, with kludge from Gerard, Dan and Ken). When you accept something, ACCEPT-2 alls the appropriate presentation type :PARSER method inside a WITH-INPUT-EDITING environment which is basically a do-over loop that calls the :PARSER again if you type a :RUBOUT, or something, to cause a rescan. The rescan calls the :PARSER again. The following global variable is used to show the default to the user only the first time. ||# (defvar editable-string-rubout-default-kludge "") (define-presentation-type editable-string () ;; hopefully temporary presentation type, until accepting-values allows editing of the default value as well as replacement :parser ((stream &key default) (when (not (eq editable-string-rubout-default-kludge default)) (setf editable-string-rubout-default-kludge default) (let ((input-buffer (clim-internals::input-editor-buffer stream))) (when (zerop (fill-pointer input-buffer)) ;;I added the reverse, unread is pushing the characters so they ;;must go on in reverse order. Gerard 21mar91. (dolist (c (reverse (coerce default 'list))) (stream-unread-char stream c))))) ;; stream-read-line only stops on #\newline (let ((buf (make-array 20 :element-type 'string-char :fill-pointer 0 :adjustable t))) (loop (let ((ch (stream-read-char stream))) (case ch ((#\newline #\return) (setf editable-string-rubout-default-kludge "") (return buf)) (t (vector-push-extend ch buf))))))) :printer ((string stream &key &allow-other-keys) (write-string string stream)))   Received: from BBN.COM by LABS-N.BBN.COM id aa08689; 14 Feb 92 17:48 EST Received: from att.att.com by BBN.COM id aa13871; 14 Feb 92 17:40 EST From: lgm@iexist.att.com Received: from NSPP11.iexist.att.com by iexist.att.com (4.1/SMI-4.1) id AA17822; Fri, 14 Feb 92 16:35:22 CST Date: Fri, 14 Feb 1992 16:35-0600 Original-From: Lawrence G. Mayka Subject: Running CLIM on Garnet's Motif widgets To: iexist!att!bbn.com!clim@iexist.att.com Cc: iexist!att!ai.sri.com!slug@iexist.att.com, cs.cmu.edu!garnet@iexist.att.com Message-Id: <19920214223509.7.LGM@NSPP11.iexist.att.com> CLIM 2.0 will reportedly simplify the interface between CLIM and platform-dependent toolkits such as Motif's. The Garnet software available from CMU includes (among many other things) a Motif widget set written in Common Lisp on top of CLX. Has anyone, user or vendor, considered implementing a Motif back end for CLIM 2.0 using Garnet? My own personal interest is in writing a CLIM program on a Symbolics Lisp Machine that projects--onto a dumb X graphics server, such as an X terminal--a user interface with a Motif look and feel. (Symbolics CLIM currently projects a Symbolics Genera look and feel, using CLX directly.) Symbolics Genera already includes CLX, and I am presuming that porting Garnet to Symbolics would not be too difficult. Thus, what I would need is a connection between CLIM and Garnet. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.   Received: from BBN.COM by LABS-N.BBN.COM id aa10835; 15 Feb 92 0:10 EST Received: from corwin.ccs.northeastern.edu by BBN.COM id aa11414; 15 Feb 92 0:07 EST Received: by corwin.ccs.northeastern.edu (5.61+++/SMI-3.2+CCS-mx-2.9) id AA05134; Sat, 15 Feb 92 00:08:14 -0500 Date: Sat, 15 Feb 92 00:08:14 -0500 From: robert futrelle Message-Id: <9202150508.AA05134@corwin.ccs.northeastern.edu> To: clim@BBN.COM Subject: How to know when scrolling occurs? Richard Billington raised an issue that has also been a problem for us. In one application we have two panes that have related material, so that when one is scrolled we'd like to know, so we can keep the other in sync. It seems to me that many systems might have the same general design goal, so we need this. Does anyone know how to monitor and react to scrolling? Just how deeply into CLIM do we have to get and how different might this be on different platforms? What I'm suggesting is that it be a standardized and advertised capability of all CLIM implementations. bob futrelle   Received: from BBN.COM by LABS-N.BBN.COM id aa23832; 16 Feb 92 17:16 EST Received: from att.att.com by BBN.COM id aa10721; 16 Feb 92 17:05 EST Received: from NSPP11.iexist.att.com by iexist.att.com (4.1/SMI-4.1) id AA17244; Sun, 16 Feb 92 16:00:46 CST Date: Sun, 16 Feb 1992 16:00-0600 From: "Lawrence G. Mayka" Subject: Running CLIM on CLIO's Open Look widgets (was: Garnet's Motif) To: barmar@think.com Cc: clim@BBN.COM, slug@ai.sri.com In-Reply-To: <9202150424.AA25406@godot.think.com> Message-Id: <19920216220025.0.LGM@NSPP11.iexist.att.com> Date: Fri, 14 Feb 1992 22:24 CST From: Barry Margolin From: lgm@iexist.att.com Date: Fri, 14 Feb 1992 16:35-0600 My own personal interest is in writing a CLIM program on a Symbolics Lisp Machine that projects--onto a dumb X graphics server, such as an X terminal--a user interface with a Motif look and feel. (Symbolics CLIM currently projects a Symbolics Genera look and feel, using CLX directly.) Symbolics Genera already includes CLX, and I am presuming that porting Garnet to Symbolics would not be too difficult. Thus, what I would need is a connection between CLIM and Garnet. ... But if your goal is a Motif L&F for a CLIM application, I vaguely remember someone saying that they were developing a CLM driver for CLIM. The main problem with this is that CLM requires an intermediary Unix system to perform the Lisp/Motif translation. Yes, an intermediary UNIX System is unacceptable for my application. I have just read, though, that CLIO--built at TI on top of CLUE and included in the CLUE distribution--offers widgets with an Open Look L&F. Open Look would probably be almost as acceptable as Motif for my purposes. So...has anyone considered developing a CLIO driver for CLIM? Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.   Received: from BBN.COM by LABS-N.BBN.COM id aa29975; 17 Feb 92 11:07 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa04556; 17 Feb 92 11:03 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 423042; 17 Feb 1992 11:02:31-0500 Date: Mon, 17 Feb 1992 11:02-0500 From: Scott McKay Subject: Running CLIM on Garnet's Motif widgets To: lgm@iexist.att.com, clim@BBN.COM cc: slug@ai.sri.com, garnet@cs.cmu.edu In-Reply-To: <19920214223509.7.LGM@NSPP11.iexist.att.com> Message-ID: <19920217160221.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 14 Feb 1992 17:35 EST From: lgm@iexist.att.com CLIM 2.0 will reportedly simplify the interface between CLIM and platform-dependent toolkits such as Motif's. The Garnet software available from CMU includes (among many other things) a Motif widget set written in Common Lisp on top of CLX. Has anyone, user or vendor, considered implementing a Motif back end for CLIM 2.0 using Garnet? Not to my knowledge. I would guess that it is unlikely that any vendor will do this, since it is hard to justify economically. My own personal interest is in writing a CLIM program on a Symbolics Lisp Machine that projects--onto a dumb X graphics server, such as an X terminal--a user interface with a Motif look and feel. (Symbolics CLIM currently projects a Symbolics Genera look and feel, using CLX directly.) Symbolics Genera already includes CLX, and I am presuming that porting Garnet to Symbolics would not be too difficult. Thus, what I would need is a connection between CLIM and Garnet.   Received: from BBN.COM by LABS-N.BBN.COM id aa29987; 17 Feb 92 11:12 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa04685; 17 Feb 92 11:08 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 423045; 17 Feb 1992 11:07:59-0500 Date: Mon, 17 Feb 1992 11:07-0500 From: Scott McKay Subject: How to know when scrolling occurs? To: futrell@corwin.ccs.northeastern.edu, clim@BBN.COM In-Reply-To: <9202150508.AA05134@corwin.ccs.northeastern.edu> Message-ID: <19920217160751.6.SWM@SUMMER.SCRC.Symbolics.COM> Date: Sat, 15 Feb 1992 00:08 EST From: robert futrelle Richard Billington raised an issue that has also been a problem for us. In one application we have two panes that have related material, so that when one is scrolled we'd like to know, so we can keep the other in sync. It seems to me that many systems might have the same general design goal, so we need this. Does anyone know how to monitor and react to scrolling? Just how deeply into CLIM do we have to get and how different might this be on different platforms? What I'm suggesting is that it be a standardized and advertised capability of all CLIM implementations. For CLIM 1.0, you can create your own class of window and specialize WINDOW-SET-VIEWPORT-POSITION*. It is simple enough to do this that I don't think CLIM requires any special support. CLIM 2.0 will support some sort of similar trick, although I am not sure today exactly what it will look like.   Received: from BBN.COM by LABS-N.BBN.COM id aa02219; 17 Feb 92 17:06 EST Received: from att.att.com by BBN.COM id aa13221; 17 Feb 92 17:02 EST Received: from NSPP11.iexist.att.com by iexist.att.com (4.1/SMI-4.1) id AA23873; Mon, 17 Feb 92 15:42:05 CST Date: Mon, 17 Feb 1992 15:41-0600 From: "Lawrence G. Mayka" Subject: Running CLIM on Garnet's Motif widgets To: SWM@sapsucker.scrc.symbolics.com Cc: clim@BBN.COM, slug@ai.sri.com In-Reply-To: <19920217160221.3.SWM@SUMMER.SCRC.Symbolics.COM> Message-Id: <19920217214140.6.LGM@NSPP11.iexist.att.com> Date: Mon, 17 Feb 1992 10:02 CST From: Scott McKay Date: Fri, 14 Feb 1992 17:35 EST From: lgm@iexist.att.com CLIM 2.0 will reportedly simplify the interface between CLIM and platform-dependent toolkits such as Motif's. The Garnet software available from CMU includes (among many other things) a Motif widget set written in Common Lisp on top of CLX. Has anyone, user or vendor, considered implementing a Motif back end for CLIM 2.0 using Garnet? Not to my knowledge. I would guess that it is unlikely that any vendor will do this, since it is hard to justify economically. The advantages for a vendor or user (e.g., a university) to write a CLIO or Garnet driver for CLIM: - Easier construction, testing, and incorporation of innovative or customized widgets, since they would be writable in Common Lisp rather than C/C++. - Portability of the application's look-and-feel across platforms, with a dependence only on the X Window System rather than on a particular OS and programming language. Note that true L&F portability (instead of chameleon-like adaptation) is still desirable in some applications. Smalltalk/V offers L&F adaptation, Smalltalk-80 offers L&F portability; each apparently has found a viable market. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.   Received: from BBN.COM by LABS-N.BBN.COM id aa04169; 18 Feb 92 0:49 EST Received: from colossus.apple.com by BBN.COM id aa14029; 18 Feb 92 0:45 EST Received: from [90.20.0.222] by colossus.apple.com with SMTP (5.65/11-Dec-1991-eef) id AA03213; Mon, 17 Feb 92 21:40:31 -0800 for Received: by alink-gw.apple.com (5.65/27-Sep-1991-eef) id AA28869; Mon, 17 Feb 92 21:37:49 -0800 for Date: 18 Feb 92 05:28 GMT From: "TA Systems, Michael Maciag,APD" Subject: MCL CLIM Information Please To: CLIM@BBN.COM Message-Id: <698391482.5218392@AppleLink.Apple.COM> Can you send me some information on your CLIM implementation for MCL 2.0? Package contents, pricing, run-time licensing (if any), portability to other Common Lisp environments, etc...   Received: from BBN.COM by LABS-N.BBN.COM id aa10175; 19 Feb 92 17:58 EST Received: from sigi.cs.colorado.edu by BBN.COM id aa00121; 19 Feb 92 17:52 EST Received: by sigi.cs.colorado.edu id AA15963 (5.65c/IDA-1.4.4 for clim@bbn.com); Wed, 19 Feb 1992 15:52:24 -0700 Date: Wed, 19 Feb 1992 15:52:24 -0700 From: Brent Reeves Message-Id: <199202192252.AA15963@sigi.cs.colorado.edu> To: clim@bbn.com Subject: CLIM 1.0 Text Edit widgets anyone? Has anyone written a text-editor for CLIM? Seems like a "standard" kind of a widget, but I see no mention of text widgets beyond string presentation types in the documentation. Needs to run on a Symbolics, fwiw. -brentr ------------------------------------------------------------------------ Brent Neal Reeves brentr@cs.colorado.edu (303) 492-1218   Received: from BBN.COM by LABS-N.BBN.COM id aa12076; 19 Feb 92 23:36 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa19675; 19 Feb 92 23:30 EST Received: from FELDBERG.SGER.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 662225; 19 Feb 1992 23:28:25-0500 Received: from MONT-BLANC.SGER.Dialnet.Symbolics.COM by FELDBERG.SGER.Dialnet.Symbolics.COM via INTERNET with SMTP id 35016; 19 Feb 1992 15:37:37+0100 Date: Wed, 19 Feb 1992 15:37+0100 From: Markus Fischer Subject: How to know when scrolling occurs? To: futrell%corwin.ccs.northeastern.edu@riverside.scrc.symbolics.com, clim%BBN.COM@riverside.scrc.symbolics.com In-Reply-To: <19920217160751.6.SWM@SUMMER.SCRC.Symbolics.COM> Message-ID: <19920219143721.1.MF@MONT-BLANC.SGER.Dialnet.Symbolics.COM> Date: Mon, 17 Feb 1992 17:07+0100 From: Scott McKay Date: Sat, 15 Feb 1992 00:08 EST From: robert futrelle Richard Billington raised an issue that has also been a problem for us. In one application we have two panes that have related material, so that when one is scrolled we'd like to know, so we can keep the other in sync. It seems to me that many systems might have the same general design goal, so we need this. Does anyone know how to monitor and react to scrolling? Just how deeply into CLIM do we have to get and how different might this be on different platforms? What I'm suggesting is that it be a standardized and advertised capability of all CLIM implementations. For CLIM 1.0, you can create your own class of window and specialize WINDOW-SET-VIEWPORT-POSITION*. It is simple enough to do this that I don't think CLIM requires any special support. Given that WINDOW-SET-VIEWPORT-POSITION* is a generic function, you needn't even create your own class. I would just add an :after method including the control code you have in mind to keep things sync. CLIM 2.0 will support some sort of similar trick, although I am not sure today exactly what it will look like.   Received: from BBN.COM by LABS-N.BBN.COM id aa12088; 19 Feb 92 23:37 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa19807; 19 Feb 92 23:31 EST Received: from FELDBERG.SGER.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 662226; 19 Feb 1992 23:29:52-0500 Received: from MONT-BLANC.SGER.Dialnet.Symbolics.COM by FELDBERG.SGER.Dialnet.Symbolics.COM via INTERNET with SMTP id 35017; 19 Feb 1992 16:15:53+0100 Date: Wed, 19 Feb 1992 16:15+0100 From: Markus Fischer Subject: updating-error To: nicolai%gate.fzi.de@riverside.scrc.symbolics.com, clim%BBN.COM@riverside.scrc.symbolics.com In-Reply-To: The message of 12 Feb 1992 22:22+0100 from Ralf Nikolai Message-ID: <19920219151538.2.MF@MONT-BLANC.SGER.Dialnet.Symbolics.COM> Date: Wed, 12 Feb 1992 22:22+0100 From: Ralf Nikolai Hello CLIMers, I found some amazing error (?) with updating-output. The update of the first pane (vehicle, see listing below) in my define-application-frame doesn't work correct, things aren't updated. If I insert some pane before the 'error'-pane in :panes - without doing anything with this additional pane, it stays invisible - the code works! You can compile the following example, type (init ) to get the initial window, then type (show-info-window '(1 2 3 4)) to get the error (not updated pane). Ralf Nikolai email: nicolai&fzi.de P.S.: My platform is a SYMBOLICS UX1200S with CLIM1.0. First of all, I had to replace the :compute layout constraint for the command menu pane by :rest to avoid an error - I guess it only works for your site because you have a bigger screen than I do. Secondly, your code is still too complex to easily understand the point. HOWEVER, I OBSERVED THE BEHAVIOR YOU DESCRIBED, even in the developer's version of CLIM. It really seems to be something special about the first pane, (I just can't imagine what) because you only need to swap the descriptions of the first two panes (so that "vehicle" is not the first one anymore). But I found your code somewhat complicated for incremental redisplay. Instead of calling redisplay-frame-pane directly you should mark panes with :display-after-commands T and turn your functions into commands. I expect the problem to go away then. If it's still there, I suggest to send a detailed bug report to Symbolics Software Service (you may mention my name, if you wish). Markus Fischer Consulting Services Symbolics Systemhaus GmbH Mergenthaler Allee 77-81 W-6236 Eschborn Germany   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa03202; 21 Feb 92 13:09 EST Received: by KARIBA.BBN.COM id aa02502; 21 Feb 92 12:17 EST To: clim@BBN.COM cc: faes-dev@BBN.COM Subject: Clim windows and xlib resources Date: Fri, 21 Feb 92 12:15:28 -0500 Message-ID: <2456.698692528@bbn.com> From: Jeff Morrill I have noticed that clim 1.0 under xlib does not specify the WM_CLASS window property. That is, (xlib:get-wm-class (slot-value (clim:frame-top-level-window frame) 'clim::window)) => NIL As far as I can tell, if the window had a "class", such as "CLIM", then I could add things to my .Xdefaults file to control how the window manager decorates clim windows: olwm.MinimalDecor: clim I recall a discussion a couple of weeks ago trying to determine how such windows get named. That discussion did not seem to come to a successful conclusion. What I want to know is: Does someone out there know any other tricks for inhibiting decorations on a frame's top-level window? Obviously menu-choose menus have no decorations. Does someone out there know how CLIM prevents the window manager from decorating menus? jeff morrill jmorrill@bbn.com P.S. I'm not an expert in CLX, but shouldn't clim set the WM_CLASS (via xlib:set-wm-class)? Is this a bug?   Received: from BBN.COM by LABS-N.BBN.COM id aa05729; 21 Feb 92 16:59 EST Received: from p.lanl.gov by BBN.COM id aa06788; 21 Feb 92 16:33 EST Received: from zaphod.lanl.gov by p.lanl.gov (5.65/1.14) id AA01519; Fri, 21 Feb 92 14:33:09 -0700 Received: by zaphod.lanl.gov.lanl.gov (4.1/SMI-4.1) id AA05220; Fri, 21 Feb 92 14:02:17 MST Date: Fri, 21 Feb 92 14:02:17 MST From: devries@zaphod.lanl.gov (John deVries) Message-Id: <9202212102.AA05220@zaphod.lanl.gov.lanl.gov> To: clim@BBN.COM Subject: please remove ---- * ---- John Atwood   Received: from BBN.COM by LABS-N.BBN.COM id aa09117; 25 Feb 92 4:00 EST Received: from fhg1.fhg.de by BBN.COM id aa14985; 25 Feb 92 3:50 EST Received: by fhg.de (fhg1.fhg.de) with PRESMTP; Tue, 25 Feb 92 09:45:42 +0100 from FHG-GATEWAY Received: by fhg.de (fhg1.fhg.de) with UUCP; Tue, 25 Feb 92 09:43:33 +0100 from imldo Received: by iml.fhg.de with SMTP; Tue, 25 Feb 92 09:40:15 +0100 Date: Tue, 25 Feb 1992 09:39+0100 From: Stefan Bernemann Subject: STREAMP and CLOS To: York%Chuck-Jones.West.Dialnet.ILA.COM@iml.fhg.de Cc: clim@bbn.com, slug@ai.sri.com, bwild@azurro.fzi.de In-Reply-To: <19920224194907.5.YORK@Chuck-Jones.West.Dialnet.ILA.COM> Message-Id: <19920225083906.1.STEFAN@ANNA.iml.fhg.de> Date: Mon, 24 Feb 1992 20:49 MET From: York%Chuck-Jones.West.Dialnet.ILA.COM@fhg.de (William M. York) Date: Mon, 24 Feb 1992 08:25 PST From: barmar@think.com (Barry Margolin) Date: Mon, 24 Feb 1992 12:51 EST From: bwild@azurro.fzi.de (Bernd Wild) We got a surprising result when applying STREAMP to an arbitrary CLOS instance. It always returns T. This behavior has changed from Genera 8.0 to 8.1. While in 8.0 only "real" streams resulted in a T-value in 8.1 this can be observed for every instance. I can't reproduce this. I did (clos:defclass foo () ()) (setq a (clos:make-instance 'foo)) (streamp a) => NIL (send a :which-operations) => (:SEND-IF-HANDLES :WHICH-OPERATIONS :OPERATION-HANDLED-P :PRINT-SELF) I'm running Genera 8.1.1, in case you're running plain 8.1. I don't think it should make a difference, though; none of the CLOS patches in the ECO seem to relate to this. Gack! This surprising behavior can be obtained simply by loading CLIM! Bern, are you trying this in an environment with CLIM 1.0 loaded? This bug is caused by a team effort of several random Genera/CLIM facilities. 1) STREAMP is implemented in Genera by seeing if the object handles the :TYI or :TYI message (as opposed to, say, checking to see if it is a subclass of STREAM, or has a STREAMP method that returns T). This is due to the long and convoluted history of the Genera stream implementation. 2) The WHICH-OPERATIONS implementation for CLOS objects works by mapping over all the generic functions that are mapped to Flavor messages via the :SELECTOR option to DEFGENERIC. For each function, it maps over all the methods, looking at the class of the method's specialization argument. If that class is in the class precedence list of the class of the argument to WHICH-OPERATIONS, it adds that message to the operations list. 3) CLIM uses the :SELECTOR mechanism to map STREAM-WRITE-CHAR to :TYO, so STREAM-WRITE-CHAR is on the list of "selector" GF's checked by WHICH-OPERATIONS. 4) CLIM also defines a method for STREAM-WRITE-CHAR on the class T (so that STREAM-WRITE-CHAR method invocations on old Genera stream objects will forward to a call to WRITE-CHAR). So, the fact that STREAM-WRITE-CHAR is in the list of generic functions with selectors (in this case, to the associated message :TYO), and that it has a method defined on class T, and that class T is a superclass of your FOO class defined above, all means that WHICH-OPERATIONS thinks that FOO supports the :TYO message, and therefore STREAMP thinks that an instance of FOO is a stream. (Pant, pant) I am going to be pretty embarrassed if Mr. Wild is not using CLIM. I am open to suggestions for the right place to fix this. I'm running clim 1.0 under genera 8.1 No real suggestions for a fix, but the implementation of the method STREAM-WRITE-CHAR on the class T seems arguable: calling (clim:stream-write-char (clos:make-instance 'foo) #\x) runs into an infinte loop on the symbolics. Using clim on the Macintosh under MCL 2.0b4, calling STREAM-WRITE-CHAR with the same arguments results in a "reasonable" error message saying STREAM-TYO is not applicable. Guessing from the disassembled code of the method STREAM-WRITE-CHAR on the class T the method basically calls STREAM-TYO on the arguments, and there is no method for STREAM-TYO on class T (which is ok). Stefan. Mail: Stefan Bernemann ! Phone: +49-231-7549233 c/o FhG IML Dortmund ! Fax: +49-231-7549211 Emil-Figge-Str. 75 ! Email: berni@iml.fhg.de D-4600 Dortmund 50, FRG ! ...!{uunet|mcavx}!unido!itwdo!berni   Received: from BBN.COM by LABS-N.BBN.COM id aa13523; 25 Feb 92 11:16 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa03011; 25 Feb 92 11:05 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 423592; 25 Feb 1992 11:04:41-0500 Date: Tue, 25 Feb 1992 11:04-0500 From: Scott McKay Subject: STREAMP and CLOS To: berni@iml.fhg.de, York%Chuck-Jones.West.Dialnet.ILA.COM@iml.fhg.de cc: clim@BBN.COM, bwild@azurro.fzi.de In-Reply-To: <19920225083906.1.STEFAN@ANNA.iml.fhg.de> Message-ID: <19920225160435.0.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 25 Feb 1992 03:39 EST From: Stefan Bernemann Date: Mon, 24 Feb 1992 20:49 MET From: York%Chuck-Jones.West.Dialnet.ILA.COM@fhg.de (William M. York) Date: Mon, 24 Feb 1992 08:25 PST From: barmar@think.com (Barry Margolin) Date: Mon, 24 Feb 1992 12:51 EST From: bwild@azurro.fzi.de (Bernd Wild) We got a surprising result when applying STREAMP to an arbitrary CLOS instance. It always returns T. This behavior has changed from Genera 8.0 to 8.1. While in 8.0 only "real" streams resulted in a T-value in 8.1 this can be observed for every instance. I can't reproduce this. I did (clos:defclass foo () ()) (setq a (clos:make-instance 'foo)) (streamp a) => NIL (send a :which-operations) => (:SEND-IF-HANDLES :WHICH-OPERATIONS :OPERATION-HANDLED-P :PRINT-SELF) I'm running Genera 8.1.1, in case you're running plain 8.1. I don't think it should make a difference, though; none of the CLOS patches in the ECO seem to relate to this. Gack! This surprising behavior can be obtained simply by loading CLIM! Bern, are you trying this in an environment with CLIM 1.0 loaded? I'm running clim 1.0 under genera 8.1 No real suggestions for a fix, but the implementation of the method STREAM-WRITE-CHAR on the class T seems arguable: calling (clim:stream-write-char (clos:make-instance 'foo) #\x) runs into an infinte loop on the symbolics. Genera's stream implementation predates the rest of the stream implementations in the world by several years. I hesitate to call it a stream "system", because it really just accreted slowly over the years and does not implement any reliable protocol. With the advent of CLIM, Genera uses *four* different object systems to implement streams: structures, Old Flavor-like streams, New Flavor streams, and CLOS-based streams. What this means in real money is that CLIM has no choice but to write some stream methods on the class T, because there is no other place to hang them. What Moon proposed is probably the right fix: default methods shouldn't cause STREAMP to return T. Using clim on the Macintosh under MCL 2.0b4, calling STREAM-WRITE-CHAR with the same arguments results in a "reasonable" error message saying STREAM-TYO is not applicable. Guessing from the disassembled code of the method STREAM-WRITE-CHAR on the class T the method basically calls STREAM-TYO on the arguments, and there is no method for STREAM-TYO on class T (which is ok).   Received: from BBN.COM by LABS-N.BBN.COM id aa15040; 25 Feb 92 13:05 EST Received: from FUJI.ILA.COM by BBN.COM id aa10398; 25 Feb 92 12:58 EST Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 306346; 25 Feb 92 12:55:49 EST Date: Tue, 25 Feb 1992 09:36-0800 From: William M. York Subject: STREAMP and CLOS To: SWM@sapsucker.scrc.symbolics.com, berni@iml.fhg.de, York@Chuck-Jones.West.Dialnet.ILA.COM cc: clim@bbn.com, bwild@azurro.fzi.de In-Reply-To: <19920225160435.0.SWM@SUMMER.SCRC.Symbolics.COM> Message-ID: <19920225173624.9.YORK@Chuck-Jones.West.Dialnet.ILA.COM> Date: Tue, 25 Feb 1992 08:04 PST From: Scott McKay Date: Tue, 25 Feb 1992 03:39 EST From: Stefan Bernemann No real suggestions for a fix, but the implementation of the method STREAM-WRITE-CHAR on the class T seems arguable: calling (clim:stream-write-char (clos:make-instance 'foo) #\x) runs into an infinte loop on the symbolics. Genera's stream implementation predates the rest of the stream implementations in the world by several years. I hesitate to call it a stream "system", because it really just accreted slowly over the years and does not implement any reliable protocol. With the advent of CLIM, Genera uses *four* different object systems to implement streams: structures, Old Flavor-like streams, New Flavor streams, and CLOS-based streams. What this means in real money is that CLIM has no choice but to write some stream methods on the class T, because there is no other place to hang them. What Moon proposed is probably the right fix: default methods shouldn't cause STREAMP to return T. Yeah, but this has to be fixed in the CLOS WHICH-OPERATIONS mechanism, not in CLIM proper.   Received: from BBN.COM by LABS-N.BBN.COM id aa16824; 25 Feb 92 14:53 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa17495; 25 Feb 92 14:49 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 423623; 25 Feb 1992 14:47:25-0500 Date: Tue, 25 Feb 1992 14:47-0500 From: Scott McKay Subject: STREAMP and CLOS To: York@chuck-jones.west.dialnet.ila.com, SWM@SAPSUCKER.SCRC.Symbolics.COM, berni@iml.fhg.de cc: clim@BBN.COM, bwild@azurro.fzi.de In-Reply-To: <19920225173624.9.YORK@Chuck-Jones.West.Dialnet.ILA.COM> Message-ID: <19920225194722.1.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 25 Feb 1992 12:36 EST From: "William M. York" Date: Tue, 25 Feb 1992 08:04 PST From: Scott McKay Date: Tue, 25 Feb 1992 03:39 EST From: Stefan Bernemann No real suggestions for a fix, but the implementation of the method STREAM-WRITE-CHAR on the class T seems arguable: calling (clim:stream-write-char (clos:make-instance 'foo) #\x) runs into an infinte loop on the symbolics. Genera's stream implementation predates the rest of the stream implementations in the world by several years. I hesitate to call it a stream "system", because it really just accreted slowly over the years and does not implement any reliable protocol. With the advent of CLIM, Genera uses *four* different object systems to implement streams: structures, Old Flavor-like streams, New Flavor streams, and CLOS-based streams. What this means in real money is that CLIM has no choice but to write some stream methods on the class T, because there is no other place to hang them. What Moon proposed is probably the right fix: default methods shouldn't cause STREAMP to return T. Yeah, but this has to be fixed in the CLOS WHICH-OPERATIONS mechanism, not in CLIM proper. Yes, sorry I wasn't clear about that.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa28654; 26 Feb 92 11:06 EST To: clim@BBN.COM Subject: Turning on Backing Store in Lucid CLIM 1.0b Date: Wed, 26 Feb 92 10:54:25 -0500 From: mthome@BBN.COM In Lucid CLIM 1.0 beta on Sparc, SunOS 4.1... How does one turn on Backing Store on a X11-implemented CLIM frame/window? We've hacked up a solution for this specific question, but we'd still like a more general approach to specifiying window-system *specific* instantiation details to CLIM windows once we know how they'll be realized. ideas? thanks, -Michael Thome (mthome@bbn.com)   Received: from BBN.COM by LABS-N.BBN.COM id aa00584; 26 Feb 92 13:19 EST Received: from [150.109.4.177] by BBN.COM id aa10539; 26 Feb 92 13:14 EST Received: by sauron (4.1/1.27) id AA02300; Wed, 26 Feb 92 10:15:45 PST Date: Wed, 26 Feb 92 10:15:44 PST From: mmeehan@eesof.com (Mike Meehan) Message-Id: <9202261815.AA02300@sauron> To: clim@bbn.com Subject: PC clim... Can someone help us understand some jargon related to CLIM. Evidently Symbolics has a PC implementation of CLtl2. Is this CLOE? What is Genera? We are interested in finding out about any CLIM implementations on the PC... Thanks in advance, -MM Mike Meehan Manager, Simulation Optimization Technology Group EEsof Inc., R&D Department 5601 Lindero Canyon Road Westlake Village CA. 91362 FAX/VOICE: 818.879.6374 mmeehan@eesof.com   Received: from BBN.COM by LABS-N.BBN.COM id aa03612; 26 Feb 92 17:32 EST Received: from MCC.COM by BBN.COM id aa26698; 26 Feb 92 17:22 EST Received: from hippo.aca.mcc.com by MCC.COM with TCP; Wed, 26 Feb 92 16:22:03 CST Posted-Date: Wed, 26 Feb 1992 16:21-0600 Received: by hippo.aca.mcc.com (5.57/ACTv4.1i) id AA19700; Wed, 26 Feb 92 16:21:52 -0600 Date: Wed, 26 Feb 1992 16:21-0600 From: Dexter R. Pratt Subject: Keyboard Accellerators To: clim-support@lucid.com, clim@bbn.com Cc: AI.Dexter@MCC.COM, ext-cyc-port@MCC.COM Message-Id: <19920226222149.1.DEXTER@MAMMUTHUS.ACA.MCC.COM> Reply-To: AI.Dexter@MCC.COM Postal-Address: 3500 West Balcones Drive, Austin, Texas, 78759 Business-Phone: (512) 338-3650 I've been having some peculiar behavior in Lucid Clim 1.0 with keyboard accellerators for commands. If my command definer looks like: (define-cyc-listener-command (com-show-u :name t :keystroke #\control-g) () (accept-and-show-unit)) Then the keystroke I have to type is #\control-G, not #\control-g Has anyone else seen this? Its happened for me on both DEC 5000s and Sparc2s. The same code works ok on Genera. - Dexter Pratt   Received: from BBN.COM by LABS-N.BBN.COM id aa04062; 26 Feb 92 18:24 EST Received: from brazil.cambridge.apple.com by BBN.COM id aa29259; 26 Feb 92 18:18 EST Received: from ministry.cambridge.apple.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef) id AA05805; Wed, 26 Feb 92 18:20:34 -0500 for clim@BBN.COM Received: from [90.223.0.20] by cambridge.apple.com with SMTP (5.64/25-eef) id AA02666; Wed, 26 Feb 92 18:17:32 -0500 Message-Id: <9202262317.AA02666@cambridge.apple.com> Date: Wed, 26 Feb 92 18:19:40 EST From: kab@cambridge.apple.com (Kim Barrett) To: AI.Dexter@mcc.com Subject: Re: Keyboard Accellerators Cc: clim-support@lucid.com, clim@BBN.COM, ext-cyc-port@mcc.com > I've been having some peculiar behavior in Lucid Clim 1.0 with keyboard > accellerators for commands. If my command definer looks like: > > (define-cyc-listener-command (com-show-u :name t :keystroke #\control-g) > () > (accept-and-show-unit)) > > Then the keystroke I have to type is #\control-G, not #\control-g > > Has anyone else seen this? Its happened for me on both DEC 5000s and > Sparc2s. The same code works ok on Genera. > > - Dexter Pratt Try #\control-\g. I suspect you are getting screwed by the reader upcasing the token.   Received: from BBN.COM by LABS-N.BBN.COM id aa05007; 26 Feb 92 20:28 EST Received: from lucid.com by BBN.COM id aa02859; 26 Feb 92 20:25 EST Received: from kuwait.lucid ([192.31.212.118]) by heavens-gate.lucid.com id AA26513g; Wed, 26 Feb 92 17:20:23 PST Received: by kuwait.lucid (4.1/SMI-4.1) id AA05557; Wed, 26 Feb 92 17:25:18 PST Date: Wed, 26 Feb 92 17:25:18 PST From: kern%kuwait@lucid.com (John Kern) Message-Id: <9202270125.AA05557@kuwait.lucid> To: AI.Dexter@mcc.com Cc: clim-support@lucid.com, clim@BBN.COM, ext-cyc-port@mcc.com Subject: Keyboard Accellerators Reply-To: kern@lucid.com Howdy Dr. Pratt, Kim Barett is most correct. >Try #\control-\g. I suspect you are getting screwed by the reader >upcasing the token. Did this fix the problem you were encountering? Sincerely, John   Received: from BBN.COM by LABS-N.BBN.COM id aa06657; 27 Feb 92 0:58 EST Received: from FUJI.ILA.COM by BBN.COM id aa01310; 27 Feb 92 0:54 EST Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 306436; 27 Feb 92 00:52:27 EST Date: Wed, 26 Feb 1992 21:20-0800 From: William M. York Subject: PC clim... To: mmeehan@eesof.com, clim@bbn.com In-Reply-To: <9202261815.AA02300@sauron> Message-ID: <19920227052032.7.YORK@Chuck-Jones.West.Dialnet.ILA.COM> Date: Wed, 26 Feb 1992 10:15 PST From: Mike Meehan Can someone help us understand some jargon related to CLIM. Evidently Symbolics has a PC implementation of CLtl2. Is this CLOE? Right. CLOE is the DOS/386 Lisp environment product from Symbolics. It supports CLIM. What is Genera? Genera is the Symbolics Lisp-machine operating system. It also supports CLIM. We are interested in finding out about any CLIM implementations on the PC... I think that CLOE is the only DOS-based Lisp implementation currently supporting CLIM.   Received: from BBN.COM by LABS-N.BBN.COM id aa10835; 27 Feb 92 8:04 EST Received: from life.ai.mit.edu by BBN.COM id aa09748; 27 Feb 92 7:59 EST Received: from MORRISON.AI.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA10664; Thu, 27 Feb 92 07:59:44 EST Date: Thu, 27 Feb 1992 08:00-0500 From: John C. Mallery Subject: CLIM Documentation To: clim@bbn.com Message-Id: <19920227130022.0.JCMA@MORRISON.AI.MIT.EDU> Can some please provide with the citation that best describes CLIM for machine-independent, new users? I am think more of a book like the CLOS book. Is there such a thing? I need to mention it in a paper.   Received: from BBN.COM by LABS-N.BBN.COM id aa11397; 27 Feb 92 9:07 EST Received: from MCC.COM by BBN.COM id aa12219; 27 Feb 92 9:03 EST Received: from hippo.aca.mcc.com by MCC.COM with TCP; Thu, 27 Feb 92 08:03:45 CST Posted-Date: Thu, 27 Feb 1992 08:03-0600 Received: by hippo.aca.mcc.com (5.57/ACTv4.1i) id AA24244; Thu, 27 Feb 92 08:03:22 -0600 Date: Thu, 27 Feb 1992 08:03-0600 From: Dexter R. Pratt Subject: Re: Keyboard Accellerators To: Kim Barrett Cc: clim-support@lucid.com, clim@BBN.COM, ext-cyc-port@MCC.COM, AI.Dexter@MCC.COM In-Reply-To: <9202262317.AA02666@cambridge.apple.com> Message-Id: <19920227140321.4.DEXTER@MAMMUTHUS.ACA.MCC.COM> Reply-To: AI.Dexter@MCC.COM Postal-Address: 3500 West Balcones Drive, Austin, Texas, 78759 Business-Phone: (512) 338-3650 Try #\control-\g. I suspect you are getting screwed by the reader upcasing the token. This was indeed the problem. Thanks! - Dexter   Received: from BBN.COM by LABS-N.BBN.COM id aa12503; 27 Feb 92 10:44 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa17529; 27 Feb 92 10:40 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 423838; 27 Feb 1992 10:39:23-0500 Date: Thu, 27 Feb 1992 10:39-0500 From: SWM@SAPSUCKER.SCRC.Symbolics.COM, JGA@SAPSUCKER.SCRC.Symbolics.COM Sender: SWM@SAPSUCKER.SCRC.Symbolics.COM Subject: CLIM Documentation To: jcma@reagan.ai.mit.edu, clim@BBN.COM In-Reply-To: <19920227130022.0.JCMA@MORRISON.AI.MIT.EDU> Message-ID: <19920227153916.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 27 Feb 1992 08:00 EST From: "John C. Mallery" Can some please provide with the citation that best describes CLIM for machine-independent, new users? I am think more of a book like the CLOS book. Is there such a thing? I need to mention it in a paper. There is no such book, although there have been discussions here at `Bolics about writing such a book. The only published things are the CACM (September `91) side-bar that SWM wrote, and the Lisp Pointers paper on Silica/CLIM published last year sometime (Vol IV, number 1).   Received: from BBN.COM by LABS-N.BBN.COM id aa11930; 27 Feb 92 9:55 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa15102; 27 Feb 92 9:50 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 423821; 27 Feb 1992 09:49:12-0500 Date: Thu, 27 Feb 1992 09:49-0500 From: Scott McKay Subject: Keyboard Accellerators To: AI.Dexter@mcc.com, clim-support@lucid.com, clim@BBN.COM cc: ext-cyc-port@mcc.com In-Reply-To: <19920226222149.1.DEXTER@MAMMUTHUS.ACA.MCC.COM> Message-ID: <19920227144911.0.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 26 Feb 1992 17:21 EST From: "Dexter R. Pratt" I've been having some peculiar behavior in Lucid Clim 1.0 with keyboard accellerators for commands. If my command definer looks like: (define-cyc-listener-command (com-show-u :name t :keystroke #\control-g) () (accept-and-show-unit)) Then the keystroke I have to type is #\control-G, not #\control-g Has anyone else seen this? Its happened for me on both DEC 5000s and Sparc2s. The same code works ok on Genera. - Dexter Pratt On Genera the reader ignores case, so both #\control-G and #\control-g read as the same characters, which is the character that corresponds to typing G with the Control key held down. #\control-shift-G corresponds to typing G with both the Control and Shift keys held down. I believe that the Lucid reader pays attention to case inside of #\, so if you want to create an accelerator that corresponds to typing the G key with the Control key held down, you should specify #\control-\g (note the backslash before the "g").   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa13556; 27 Feb 92 12:16 EST Received: by KARIBA.BBN.COM id aa20998; 27 Feb 92 12:04 EST To: clim@BBN.COM, bug-clim@BBN.COM Subject: Bugs in clim:accepting-values window Date: Thu, 27 Feb 92 11:59:16 -0500 Message-ID: <6720.699209956@bbn.com> From: Jeff Morrill I am using CLIM 1.0 on Allegro CL 4.1.beta.0 [Sun4; R1] (2/24/92 12:57). 1. No horizontal scroll bar on AVV window. This is a little annoying if you have a big display (or a little screen). 2. " aborts, uses these values" is a most confusing thing to print on the AVV frame when those keys aren't on your keyboard. Indeed, as far as I can tell, there are no keyboard accellerators for those two operations when your keyboard doesn't have those two keys. How about " aborts, uses these values". As a further feature for clim 2.0 (3.0?), I'd like to see the exit message displayed using a method that can be customized by application code. Suppose I want my exit boxes to be graphical, like on the MacIntosh: ------- ---------- | Done | | Cancel | ------- ---------- Then I might define a subclass of the avv frame and pass it into accepting-values. (defclass my-avv-frame (clim:avv-frame) () ) (defmethod clim:avv-display-exit-boxes ((frame my-avv-frame) stream) ... my code ... ) (accepting-values (t :own-window t :frame-class 'my-avv-frame) ... more code... ) Just a suggestion. jeff morrill jmorrill@bbn.com   Received: from BBN.COM by LABS-N.BBN.COM id aa13546; 27 Feb 92 12:14 EST Received: from FUJI.ILA.COM by BBN.COM id aa21576; 27 Feb 92 12:10 EST Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 306477; 27 Feb 92 12:07:37 EST Date: Thu, 27 Feb 1992 09:03-0800 From: William M. York Subject: CLIM Documentation To: jcma@reagan.ai.mit.edu, clim@bbn.com In-Reply-To: <19920227153916.8.SWM@SUMMER.SCRC.Symbolics.COM> Message-ID: <19920227170311.0.YORK@Chuck-Jones.West.Dialnet.ILA.COM> Date: Thu, 27 Feb 1992 07:39 PST From: SWM@sapsucker.scrc.symbolics.com, JGA@sapsucker.scrc.symbolics.com Date: Thu, 27 Feb 1992 08:00 EST From: "John C. Mallery" Can some please provide with the citation that best describes CLIM for machine-independent, new users? I am think more of a book like the CLOS book. Is there such a thing? I need to mention it in a paper. There is no such book, although there have been discussions here at `Bolics about writing such a book. The only published things are the CACM (September `91) side-bar that SWM wrote, and the Lisp Pointers paper on Silica/CLIM published last year sometime (Vol IV, number 1). And the CLIM 1.0 reference/user's manual, of course. Since most of the vendors are shipping a manual derived from the same ancestor, they are all pretty similar and pretty machine-independent.   Received: from BBN.COM by LABS-N.BBN.COM id aa14913; 27 Feb 92 14:17 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa27362; 27 Feb 92 14:12 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 423894; 27 Feb 1992 14:11:27-0500 Date: Thu, 27 Feb 1992 14:11-0500 From: Scott McKay Subject: Bugs in clim:accepting-values window To: jmorrill@BBN.COM, clim@BBN.COM, bug-clim@BBN.COM In-Reply-To: <6720.699209956@bbn.com> Message-ID: <19920227191126.0.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 27 Feb 1992 11:59 EST From: Jeff Morrill I am using CLIM 1.0 on Allegro CL 4.1.beta.0 [Sun4; R1] (2/24/92 12:57). 1. No horizontal scroll bar on AVV window. This is a little annoying if you have a big display (or a little screen). Hmph. I look at this. 2. " aborts, uses these values" is a most confusing thing to print on the AVV frame when those keys aren't on your keyboard. Indeed, as far as I can tell, there are no keyboard accellerators for those two operations when your keyboard doesn't have those two keys. How about " aborts, uses these values". You can control this with the :EXIT-BOXES option to ACCEPTING-VALUES. As a further feature for clim 2.0 (3.0?), I'd like to see the exit message displayed using a method that can be customized by application code. Suppose I want my exit boxes to be graphical, like on the MacIntosh: ------- ---------- | Done | | Cancel | ------- ---------- You can do this, too, although I see the symbol is not exported. You can write CLIM::DISPLAY-EXIT-BOXES methods to do this. CLIM 2.0 will indeed do a better job of this. Then I might define a subclass of the avv frame and pass it into accepting-values. (defclass my-avv-frame (clim:avv-frame) () ) (defmethod clim:avv-display-exit-boxes ((frame my-avv-frame) stream) ... my code ... ) (accepting-values (t :own-window t :frame-class 'my-avv-frame) ... more code... )   Received: from BBN.COM by LABS-N.BBN.COM id aa16650; 27 Feb 92 16:27 EST Received: from aristotle.ils.nwu.edu by BBN.COM id aa05243; 27 Feb 92 16:20 EST Received: by aristotle.ils.nwu.edu (4.1/SMI-ILS-1.05) id AA08321; Thu, 27 Feb 92 15:11:15 CST Date: Thu, 27 Feb 92 15:11:15 CST From: siegle@aristotle.ils.nwu.edu (Greg Siegle) Message-Id: <9202272111.AA08321@aristotle.ils.nwu.edu> To: clim@BBN.COM Subject: keyboard accellerators within menu-choose Hi CLIMfolk, Is there any way choose menu items by a keyboard action within menu-choose? If not has anyone written a pretty general menu routine which will let me do this? Thanks in advance! -- Greg   Received: from BBN.COM by LABS-N.BBN.COM id aa26410; 2 Mar 92 15:08 EST Received: from icsia.Berkeley.EDU by BBN.COM id aa07999; 2 Mar 92 14:48 EST Received: from icsib21.ICSI.Berkeley.EDU by icsia.Berkeley.EDU (4.1/HUB$Revision: 1.11 $) id AA08733; Mon, 2 Mar 92 11:48:28 PST From: bachrach@ICSI.Berkeley.EDU (Jonathan Bachrach) Received: by icsib21.ICSI.Berkeley.EDU (Sun-4.1/CLIENT$Revision: 1.4 $) id AA01864; Mon, 2 Mar 92 11:48:27 PST Date: Mon, 2 Mar 92 11:48:27 PST Message-Id: <9203021948.AA01864@icsib21.ICSI.Berkeley.EDU> To: clim@bbn.com Subject: Image Processing in CLIM Cc: heeger@psych.stanford.edu We are thinking about porting OBVIUS (Object-Based Vision and Image Understanding System) to CLIM. In order to do this we need precise control over color rendering. It isn't clear in the CLIM 1.0 document whether CLIM supports the functionality we need. Here is what we need. 8-Bit Color Systems: We need to have enough control over the color table such that when we ask for a color, we either get it or get a condition. What we need to avoid is asking for a particular color and then getting the closest color already in the color table. What sort of support is there for this situation? It seems that (clim:draw-design (clim:make-pattern array colors) medium) ; p154 would work ok if (A) it were implemented (p154 says that this technique is not supported in the present implementation) and (B) it would use the colors you ask for and not closest approximations already in color-map. Is this implemented? If not, when or what other support is there for drawing 8-bit images? Also I'm concerned about efficiency here, it appears that this might be inefficient to have to load the color-map each time draw-design is called. 24-Bit Color Systems: We need to be able to draw 24-bit images using either a 2d array of 8-bit values for grey-scale images, or three 2d arrays of 8-bit values for color images. The draw-design is obviously unsuitable for 24-bit operations, since a large image could potentially have as many colors as pixels. Also, it isn't immediately obvious how to manipulate 24-bit images. It appears that a better approach would allow the user to specify color operations using three 2d arrays of real values. Please tell me what the thinking is for 24-bit images and what support is available for them in CLIM 1.0. -- jonathan   Received: from BBN.COM by LABS-N.BBN.COM id aa27900; 2 Mar 92 17:06 EST Received: from relay2.UU.NET by BBN.COM id aa17071; 2 Mar 92 17:01 EST Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA23294; Mon, 2 Mar 92 17:01:32 -0500 Received: from zion.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 170008.19173; Mon, 2 Mar 1992 17:00:08 EST Received: from nwd2sun1.analog.com by zion.dsp.analog.com (4.1/SMI-4.1.1) id AA02044; Mon, 2 Mar 92 17:01:09 EST Received: from spdn.spdnorth.analog.com by nwd2sun1.analog.com (4.1/SMI-4.1) id AA22111; Mon, 2 Mar 92 17:05:39 EST Received: from ARAGORN.spdnorth.analog.com by spdn.spdnorth.analog.com (4.1/SMI-4.1) id AA24143; Mon, 2 Mar 92 16:57:51 EST Received: from LITHIUM.spdnorth.analog.com by ARAGORN.spdnorth.analog.com via CHAOS with CHAOS-MAIL id 34048; 2 Mar 92 16:57:19 EST Date: Mon, 2 Mar 1992 16:56-0500 From: Timothy J. Blackman Subject: Image Processing in CLIM To: clim%bbn.com@SPDN.spdnorth.analog.com In-Reply-To: <9203021948.AA01864@icsib21.ICSI.Berkeley.EDU> Message-Id: <19920302215657.3.TJB@LITHIUM.spdnorth.analog.com> Date: Mon, 2 Mar 1992 14:48 EST From: Jonathan Bachrach We are thinking about porting OBVIUS (Object-Based Vision and Image Understanding System) to CLIM. In order to do this we need precise control over color rendering. It isn't clear in the CLIM 1.0 document whether CLIM supports the functionality we need. Here is what we need. 8-Bit Color Systems: We need to have enough control over the color table such that when we ask for a color, we either get it or get a condition. What we need to avoid is asking for a particular color and then getting the closest color already in the color table. What sort of support is there for this situation? It seems that (clim:draw-design (clim:make-pattern array colors) medium) ; p154 would work ok if (A) it were implemented (p154 says that this technique is not supported in the present implementation) and (B) it would use the colors you ask for and not closest approximations already in color-map. Is this implemented? If not, when or what other support is there for drawing 8-bit images? Also I'm concerned about efficiency here, it appears that this might be inefficient to have to load the color-map each time draw-design is called. ... -- jonathan We've been using CLIM 0.9 for porting Janus CL -- an electronic CAD tool -- to Symbolics and Sun SPARCstation platforms. This application requires explicit control over all 256 entries in the colormap for an 8 bit color system. Because I had access to the source code, I was able to get what I needed by implementing my own color objects and modifying several implementation specific graphics routines. Neither CLIM 0.9 or 1.0 seemed to provide explicit control over the assignment of colors to pixel values. I haven't gotten a look at the CLIM 2.0 specification as of yet, but it sounds to me that there too the control over the color map will not be sufficiently explicit. Just putting in my own two cents to see if other people have the same requirements. -tjb --------------------------------------------------- Tim Blackman Analog Devices Inc. tim.blackman@analog.com 181 Ballardvale St. (617) 937-1104 Wilmington, MA 01887 ---------------------------------------------------   Received: from BBN.COM by LABS-N.BBN.COM id aa28627; 2 Mar 92 18:20 EST Received: from brazil.cambridge.apple.com by BBN.COM id aa20231; 2 Mar 92 18:15 EST Received: from ministry.cambridge.apple.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef) id AA17106; Mon, 2 Mar 92 18:17:49 -0500 for clim@bbn.com Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef) id AA15436; Mon, 2 Mar 92 18:14:16 -0500 Message-Id: <9203022314.AA15436@cambridge.apple.com> Date: Mon, 02 Mar 92 18:17:03 EST From: moon@cambridge.apple.com (David A. Moon) To: "Timothy J. Blackman" , Jonathan Bachrach Subject: Re: Image Processing in CLIM Cc: clim@bbn.com Re: hacking the color map Not all platforms with color displays have color maps. I believe the design was intended to be that the standard CLIM entry points provide platform-independent graphics with the functionality that all platforms can support, and if you need to do something like control the color map or display 24-bit-color images, that's platform-dependent code that must use platform-specific interfaces, and will work on the subset of platforms that support those interfaces. I guess the problem with this is that these platform-specific interfaces didn't get documented by the vendors of the individual platform-specific versions of CLIM, and perhaps don't even exist in some cases where they could.   Received: from BBN.COM by LABS-N.BBN.COM id aa00195; 2 Mar 92 21:49 EST Received: from charon.arc.nasa.gov by BBN.COM id aa25875; 2 Mar 92 21:46 EST Received: from HALEAKALA.arc.nasa.gov by CHARON.arc.nasa.gov via INTERNET with SMTP id 111753; 2 Mar 1992 18:33:33-0800 Date: Mon, 2 Mar 1992 18:33-0800 From: will taylor Subject: Incremental Redisplay Performance To: clim@bbn.com cc: taylor@CHARON.arc.nasa.gov, chucko@CHARON.arc.nasa.gov, swanson@PTOLEMY.arc.nasa.gov, kthompso@PTOLEMY.arc.nasa.gov Message-ID: <19920303023334.7.TAYLOR@HALEAKALA.arc.nasa.gov> I am using CLIM 1.0 (Genera 8.1.1, CLIM 27.5) on a Symbolics 3653. In building a CLIM UI for a graph editing application, I found that the default incremental redisplay: (define-application-frame ... .. (editor :application :incremental-redisplay t :display-after-commands t :default-text-style (parse-text-style '(:sans-serif :bold :normal)) :scroll-bars :both :display-function 'display :borders t :window-class 'scaled-editor-pane-class) .. (:top-level (default-frame-top-level :prompt " ")) with - (defmethod DISPLAY-TREE-NODES ((current-tree TREE) (pane SCALED-EDITOR-PANE-CLASS)) "draw the tree of nodes from the root down to the leaves" (with-slots (time-factor root-node box-height box-width) current-tree (let ((half-box-height (/ box-height 2)) (half-box-width (/ box-width 2))) (labels ((go-down-tree (node) (updating-output (pane :unique-id node :cache-test #'= :cache-value (node-modification-cnt node)) (DRAW-NODE node current-tree pane half-box-width half-box-height) (let ((children (node-children node))) (dotimes (i (length children)) (go-down-tree (aref children i))))))) (go-down-tree root-node))))) for the case where I move a node and increment its node-modification-cnt from the root down to the effected nodes -- takes about TWICE AS LONG as drawing the entire graph from scratch. In poking thru the stack, I found that DEFAULT-FRAME-TOP-LEVEL calls REDISPLAY- FRAME-PANES and for each pane calls REDISPLAY with the keyword :CHECK-OVERLAPPING set to T, and that this overlap checking is what was taking all the time. I do not see any way to control that flag. So I decided to do redisplay myself: (define-application-frame ... .. (editor :application :incremental-redisplay nil :display-after-commands nil :default-text-style (parse-text-style '(:sans-serif :bold :normal)) :scroll-bars :both :borders t :window-class 'scaled-editor-pane-class) .. (:top-level (lisp-listener-top-level :prompt " ")) ; from CLIM demo stuff grab the pane output record: (setf pane-output-record (updating-output (pane) (DISPLAY-TREE-NODES current-tree pane))))))))) all my frame commands call my redisplay function: (defmethod REDISPLAY-PANE ((pane EDITOR-PANE-MIXIN)) "manual redisplay of pane & control viewport position" (with-slots (pane-frame pane-name pane-output-record redisplay-needed-p current-tree) pane (when redisplay-needed-p (let ((msg-pane (top-level-pane pane-frame))) (with-reverse-video (msg-pane) (write-string "Grinding ..." msg-pane) (cond ((null pane-output-record) (window-clear pane) (with-output-recording-options (pane :draw-p nil) (display pane-frame pane)) (window-set-viewport-position* pane 0 (- (root-y-position current-tree) (box-height current-tree))) (output-recording-stream-replay pane (window-viewport pane))) (t ;; :check-overlapping nil dramatically increases the speed of redisplay (REDISPLAY PANE-OUTPUT-RECORD PANE :CHECK-OVERLAPPING NIL)))) (setf redisplay-needed-p nil))))) A typical redisplay using this technique takes less than a second, while the default redisplay took about 8 seconds (for a 50 node graph). This experience reinforces my hope that CLIM 2.0's implementation and documentation will place more emphasis on incremental redisplay performance -- with the default redisplay functionality my UI was just about unusable. With my modificaitons the UI demonstrates the advertised claims of CLIM. ==> Will Taylor   Received: from BBN.COM by LABS-N.BBN.COM id aa00795; 3 Mar 92 0:00 EST Received: from Sunset.AI.SRI.COM by BBN.COM id aa17169; 2 Mar 92 23:57 EST Received: from Rockaway.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA01515 for clim@bbn.com; Mon, 2 Mar 92 20:58:15 PST Received: by Rockaway.AI.SRI.COM (4.1/SMI-4.1) id AA24108 for clim-support@lucid.com; Mon, 2 Mar 92 20:58:16 PST Date: Mon, 2 Mar 92 20:58:15 PST From: Peter Karp To: clim@bbn.com, clim-support@lucid.com Subject: bidirectional streams Message-Id: I can't get bidirectional streams to work in CLIM; I'm assuming they are not supported? That is, if I do: (clim:make-two-way-stream s1 s2) where s1 for example was returned by clim:open-window-stream, I get an error saying that s1 is not a stream. Are there any plans to support them? I would find them useful in conjunction with clim:accept so that I could give the function a stream argument that would let it read and write from different panes or windows that I specify. Peter   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa07547; 3 Mar 92 11:31 EST Received: by KARIBA.BBN.COM id aa04401; 3 Mar 92 11:17 EST To: clim@BBN.COM Subject: CLIM 1.0 bug Date: Tue, 03 Mar 92 11:07:54 -0500 From: mthome@BBN.COM In Lucid CLIM 1.0b (10-jun-91, patches through #6063) on Sparc, SunOS 4.1, X11R5 server... If a CLIM frame is manually reshaped (i.e. via twm window decorations), the frame (and subcomponents) reshape correctly, but the pointer highlighting but *not* the actual sensitivity gets shifted from the frame's origin to the parent screen's origin - i.e. if the frame is positioned at (50, 100) on the screen and output record A is at (200, 300) on the frame, reshaping the frame results in: 1. clicking at (200,300) in the frame does the right thing - activates a command associated with output record A. 2. But output record A only *highlights* when the pointer is at (200,300)-(50,100)=(150,200)! This is true for all window streams within the frame, and is fixed by *repositioning* the frame. -mik (mthome@bbn.com)   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa07890; 3 Mar 92 11:44 EST Received: by KARIBA.BBN.COM id aa04411; 3 Mar 92 11:31 EST To: clim@BBN.COM Subject: Speeding up CLIM startup time. Date: Tue, 03 Mar 92 11:15:12 -0500 From: mthome@BBN.COM In all versions of CLIM I've tried with an X11 implementation, the first window instantiation takes an extraordinarily log time, much of which is spent with the server frozen. With our locally-hacked version of CLIM 0.9, we wouldn't get worried unless the first window took longer than 30 seconds to appear... CLIM 1.0 seems to be doing a little better, but still takes a long time. How much of this startup time is NOT due to the compiling of CLOS dispatch functions? Has anyone looked into this? Has anyone found any ways to speed this up? thanks, -Michael Thome (mthome@bbn.com)   Received: from BBN.COM by LABS-N.BBN.COM id aa08697; 3 Mar 92 12:57 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa17094; 3 Mar 92 12:54 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 424226; 3 Mar 1992 11:21:59-0500 Date: Tue, 3 Mar 1992 11:21-0500 From: Scott McKay Subject: Incremental Redisplay Performance To: taylor@charon.arc.nasa.gov, clim@BBN.COM cc: chucko@charon.arc.nasa.gov, swanson@ptolemy.arc.nasa.gov, kthompso@ptolemy.arc.nasa.gov In-Reply-To: <19920303023334.7.TAYLOR@HALEAKALA.arc.nasa.gov> Message-ID: <19920303162143.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 2 Mar 1992 21:33 EST From: will taylor A typical redisplay using this technique takes less than a second, while the default redisplay took about 8 seconds (for a 50 node graph). This experience reinforces my hope that CLIM 2.0's implementation and documentation will place more emphasis on incremental redisplay performance -- with the default redisplay functionality my UI was just about unusable. With my modificaitons the UI demonstrates the advertised claims of CLIM. This reply is just meant to provide a few more bits of information. Please don't think that I am in any way trying to defend the terrible performance of CLIM's incremental redisplay. In general, any output record might overlap with some other output record. Therefore, when deciding what to redraw, CLIM must check to make sure that there are no "erased" output records that overlap any output records that have not changed. Due to the representation of output record coordinates (which are maintained relative to the coordinates of their parent), this augmentation of the "draw" set runs in O(m*n*d) time, where m is the number of output records in the entire tree, n is the number of output records in the erase set, and d is the depth of the tree. By changing the representation of output record coordinates, this algorithm could be reduced to O(m*n), but at the cost of slowing a few other less common operations down. So the :CHECK-OVERLAPPING argument was added to REDISPLAY is to tell incremental redisplay whether or not it should check for overlapping sibling output records. As you observed, in some cases, inhibiting this check can cause a dramatic performance improvement - it replaces an O(m*n*d) algorithm (or O(m*n) in the best case) with *nothing*. You can get away with this because you yourself know that nothing overlaps anything else. Unfortunately, CLIM does not know this and cannot make the same judgment. I confess that I agonized over what the default value for CHECK-OVERLAPPING should be. On the one hand, if I had made it be NIL, some cases of incremental redisplay would simply not behave correctly, and the programmer would have no way of knowing why it did not work. On the other hand, having decided to make the default be T, sometimes incremental redisplay is much too slow. One thing that is clear is that there should be a way to specify the value of CHECK-OVERLAPPING for incrementally redisplayed panes. Here is a kludgy patch that implements it. I have not tested this in CLIM 1.0, just in CLIM 1.1. Use :INCREMENTAL-REDISPLAY '(T :CHECK-OVERLAPPING NIL) in your pane. -------- (defun redisplay-frame-pane-internal (frame pane description &optional force-p) (let* ((options (pane-descriptor-options description)) (display-function (getf options :display-function)) (ir (getf options :incremental-redisplay)) (redisplay-p (if (listp ir) (first ir) ir)) (check-overlapping (and (listp ir) (getf (rest ir) :check-overlapping t))) (redisplay-record (and redisplay-p (let ((history (output-recording-stream-output-record pane))) (when history #+compulsive-redisplay (when (> (output-record-element-count history) 1) (cerror "Clear the output history and proceed" "Why is there more than one element in this redisplay pane?") (window-clear pane)) (unless (zerop (output-record-element-count history)) (output-record-element history 0))))))) ;; We're trying to get bits on the screen. (cond ((dummy-pane-p pane) ;; Give everyone a chance to update the title bar (when (eql (pane-descriptor-type description) :title) (display-title frame pane))) (t (when *frame-layout-changing-p* (setq force-p t)) (unless *sizing-application-frame* (unless (member pane (slot-value frame 'initialized-panes)) (setq force-p t) (push pane (slot-value frame 'initialized-panes)))) (with-simple-restart (nil "Skip redisplaying pane ~S" pane) (loop (with-simple-restart (nil "Retry displaying pane ~S" pane) (return (cond (display-function ;; If there's a display function, call it to generate new contents. (cond (redisplay-p (cond ((or (null redisplay-record) force-p) (when force-p (window-clear pane)) (call-redisplay-function display-function frame pane)) (t (redisplay redisplay-record pane :check-overlapping check-overlapping)))) ((or force-p (getf options :display-after-commands t)) (unless (and (not force-p) (eq (getf options :display-after-commands) ':no-clear)) (window-clear pane)) (call-display-function display-function frame pane))) (force-output pane)) (force-p ;; If refilling from scratch, give the application a chance ;; to draw stuff (frame-replay frame pane)) ;; Otherwise do nothing, the bits will still be on display ;; and will be refreshed properly if there's a damage event. )))))))))   Received: from BBN.COM by LABS-N.BBN.COM id aa08707; 3 Mar 92 12:57 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa17108; 3 Mar 92 12:54 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 424239; 3 Mar 1992 12:04:59-0500 Date: Tue, 3 Mar 1992 12:04-0500 From: Scott McKay Subject: CLIM 1.0 bug To: mthome@BBN.COM, clim@BBN.COM In-Reply-To: The message of 3 Mar 1992 11:07 EST from mthome@BBN.COM Message-ID: <19920303170445.7.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 3 Mar 1992 11:07 EST From: mthome@BBN.COM In Lucid CLIM 1.0b (10-jun-91, patches through #6063) on Sparc, SunOS 4.1, X11R5 server... If a CLIM frame is manually reshaped (i.e. via twm window decorations), the frame (and subcomponents) reshape correctly, but the pointer highlighting but *not* the actual sensitivity gets shifted from the frame's origin to the parent screen's origin - i.e. if the frame is positioned at (50, 100) on the screen and output record A is at (200, 300) on the frame, reshaping the frame results in: 1. clicking at (200,300) in the frame does the right thing - activates a command associated with output record A. 2. But output record A only *highlights* when the pointer is at (200,300)-(50,100)=(150,200)! This is true for all window streams within the frame, and is fixed by *repositioning* the frame. This works correctly in CLIM 1.1 -mik (mthome@bbn.com)   Received: from BBN.COM by LABS-N.BBN.COM id ab08909; 3 Mar 92 13:10 EST Received: from charon.arc.nasa.gov by BBN.COM id aa17857; 3 Mar 92 13:07 EST Received: from HALEAKALA.arc.nasa.gov by CHARON.arc.nasa.gov via INTERNET with SMTP id 111834; 3 Mar 1992 10:07:19-0800 Date: Tue, 3 Mar 1992 10:07-0800 From: will taylor Subject: Incremental Redisplay Performance To: SWM@SAPSUCKER.SCRC.Symbolics.COM, taylor@CHARON.arc.nasa.gov, clim@BBN.COM cc: chucko@CHARON.arc.nasa.gov, swanson@PTOLEMY.arc.nasa.gov, kthompso@PTOLEMY.arc.nasa.gov In-Reply-To: <19920303163353.4.SWM@SUMMER.SCRC.Symbolics.COM> Message-ID: <19920303180724.1.TAYLOR@HALEAKALA.arc.nasa.gov> Date: Tue, 3 Mar 1992 08:33 PST From: Scott McKay Date: Mon, 2 Mar 1992 21:33 EST From: will taylor A typical redisplay using this technique takes less than a second, while the default redisplay took about 8 seconds (for a 50 node graph). This experience reinforces my hope that CLIM 2.0's implementation and documentation will place more emphasis on incremental redisplay performance -- with the default redisplay functionality my UI was just about unusable. With my modificaitons the UI demonstrates the advertised claims of CLIM. ***New message. I made a mistake in the code I supplied. Sorry.*** This reply is just meant to provide a few more bits of information. Please don't think that I am in any way trying to defend the terrible performance of CLIM's incremental redisplay. Here is a kludgy patch that implements it. I have not tested this in CLIM 1.0, just in CLIM 1.1. Use :INCREMENTAL-REDISPLAY '(T :CHECK-OVERLAPPING NIL) in your pane. Thanks for your detailed response -- I hope that it will be typical of the future documentation of CLIM's incremental redisplay. Will CLIM 1.1 correct the extreme slowness of changing layouts in CLIM 1.0? I went to my own redisplay in that case as well, by creating multiple windows using (defmethod MAKE-OVERLAY-WINDOW-STREAM ((frame APPLICATION-FRAME) &key pane-to-overlay default-text-style window-class (scroll-bars :both) (borders t)) "return window stream located over pane-to-overlay -- not in frame layout" (let* ((parent (frame-top-level-window frame)) (input-buffer (stream-input-buffer parent))) (multiple-value-bind (left top right bottom) (bounding-rectangle* pane-to-overlay) (open-window-stream :parent parent :left left :top top :right right :bottom bottom :input-buffer input-buffer :default-text-style default-text-style :scroll-bars scroll-bars :borders borders :window-class window-class)))) which occupy the same frame coordinates and then using (window-expose pane) to expose the pane which belonged to the currently selected layout. Apparently there is a (REDISPLAY-FRAME-PANE frame pane :force-p t) done on each pane on a newly selected layout whether or not the pane is common to the previous layout and whether or not the pane has changed. When is CLIM 1.1 to be expected? ==> Will Taylor   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa09283; 3 Mar 92 13:40 EST To: mthome@BBN.COM cc: clim@BBN.COM Subject: Re: Speeding up CLIM startup time. In-reply-to: Your message of Tue, 03 Mar 92 11:15:12 -0500. Date: Tue, 03 Mar 92 13:31:53 -0500 From: kanderso@BBN.COM To: clim@BBN.COM Subject: Speeding up CLIM startup time. Date: Tue, 03 Mar 92 11:15:12 -0500 From: mthome@BBN.COM In all versions of CLIM I've tried with an X11 implementation, the first window instantiation takes an extraordinarily log time, much of which is spent with the server frozen. With our locally-hacked version of CLIM 0.9, we wouldn't get worried unless the first window took longer than 30 seconds to appear... CLIM 1.0 seems to be doing a little better, but still takes a long time. How much of this startup time is NOT due to the compiling of CLOS dispatch functions? Has anyone looked into this? Has anyone found any ways to speed this up? thanks, -Michael Thome (mthome@bbn.com) In CLIM 0.9 a lot of the time is spent getting font info from the X server. For some reason, accessing font info seems quite slow. One way to improve this is to ask for fewer fonts. However, you may have to ask for different sets of fonts depending on what server you are running. k   Received: from BBN.COM by LABS-N.BBN.COM id aa09502; 3 Mar 92 13:55 EST Received: from lucid.com by BBN.COM id aa19860; 3 Mar 92 13:50 EST Received: from kuwait.lucid ([192.31.212.118]) by heavens-gate.lucid.com id AA03380g; Tue, 3 Mar 92 10:45:30 PST Received: by kuwait.lucid (4.1/SMI-4.1) id AA23785; Tue, 3 Mar 92 10:50:33 PST Date: Tue, 3 Mar 92 10:50:33 PST From: kern%kuwait@lucid.com (John Kern) Message-Id: <9203031850.AA23785@kuwait.lucid> To: mthome@BBN.COM Cc: clim@BBN.COM, clim-support@lucid.com In-Reply-To: mthome@BBN.COM's message of Tue, 03 Mar 92 11:07:54 -0500 <9203031654.AA29576@lucid.com> Subject: CLIM 1.0 bug Reply-To: kern@lucid.com Howdy, I believe this is fixed in the forthcoming 1.0 release. If you provide me with a short reproducible testcase I can confirm it. Sincerely, John S. Kern Lucid, Inc. Customer Support ==== original message for easy of reference ====================== In Lucid CLIM 1.0b (10-jun-91, patches through #6063) on Sparc, SunOS 4.1, X11R5 server... If a CLIM frame is manually reshaped (i.e. via twm window decorations), the frame (and subcomponents) reshape correctly, but the pointer highlighting but *not* the actual sensitivity gets shifted from the frame's origin to the parent screen's origin - i.e. if the frame is positioned at (50, 100) on the screen and output record A is at (200, 300) on the frame, reshaping the frame results in: 1. clicking at (200,300) in the frame does the right thing - activates a command associated with output record A. 2. But output record A only *highlights* when the pointer is at (200,300)-(50,100)=(150,200)! This is true for all window streams within the frame, and is fixed by *repositioning* the frame. -mik (mthome@bbn.com)   Received: from BBN.COM by LABS-N.BBN.COM id aa08704; 3 Mar 92 12:57 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa17101; 3 Mar 92 12:54 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 424230; 3 Mar 1992 11:34:08-0500 Date: Tue, 3 Mar 1992 11:33-0500 From: Scott McKay Subject: Incremental Redisplay Performance To: taylor@charon.arc.nasa.gov, clim@BBN.COM cc: chucko@charon.arc.nasa.gov, swanson@ptolemy.arc.nasa.gov, kthompso@ptolemy.arc.nasa.gov In-Reply-To: <19920303023334.7.TAYLOR@HALEAKALA.arc.nasa.gov> Supersedes: <19920303162143.3.SWM@SUMMER.SCRC.Symbolics.COM> Comments: Correct the default for :CHECK-OVERLAPPING in the supplied code Message-ID: <19920303163353.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 2 Mar 1992 21:33 EST From: will taylor A typical redisplay using this technique takes less than a second, while the default redisplay took about 8 seconds (for a 50 node graph). This experience reinforces my hope that CLIM 2.0's implementation and documentation will place more emphasis on incremental redisplay performance -- with the default redisplay functionality my UI was just about unusable. With my modificaitons the UI demonstrates the advertised claims of CLIM. ***New message. I made a mistake in the code I supplied. Sorry.*** This reply is just meant to provide a few more bits of information. Please don't think that I am in any way trying to defend the terrible performance of CLIM's incremental redisplay. In general, any output record might overlap with some other output record. Therefore, when deciding what to redraw, CLIM must check to make sure that there are no "erased" output records that overlap any output records that have not changed. Due to the representation of output record coordinates (which are maintained relative to the coordinates of their parent), this augmentation of the "draw" set runs in O(m*n*d) time, where m is the number of output records in the entire tree, n is the number of output records in the erase set, and d is the depth of the tree. By changing the representation of output record coordinates, this algorithm could be reduced to O(m*n), but at the cost of slowing a few other less common operations down. So the :CHECK-OVERLAPPING argument was added to REDISPLAY is to tell incremental redisplay whether or not it should check for overlapping sibling output records. As you observed, in some cases, inhibiting this check can cause a dramatic performance improvement - it replaces an O(m*n*d) algorithm (or O(m*n) in the best case) with *nothing*. You can get away with this because you yourself know that nothing overlaps anything else. Unfortunately, CLIM does not know this and cannot make the same judgment. I confess that I agonized over what the default value for CHECK-OVERLAPPING should be. On the one hand, if I had made it be NIL, some cases of incremental redisplay would simply not behave correctly, and the programmer would have no way of knowing why it did not work. On the other hand, having decided to make the default be T, sometimes incremental redisplay is much too slow. One thing that is clear is that there should be a way to specify the value of CHECK-OVERLAPPING for incrementally redisplayed panes. Here is a kludgy patch that implements it. I have not tested this in CLIM 1.0, just in CLIM 1.1. Use :INCREMENTAL-REDISPLAY '(T :CHECK-OVERLAPPING NIL) in your pane. -------- (defun redisplay-frame-pane-internal (frame pane description &optional force-p) (let* ((options (pane-descriptor-options description)) (display-function (getf options :display-function)) (ir (getf options :incremental-redisplay)) (redisplay-p (if (listp ir) (first ir) ir)) (check-overlapping (or (atom ir) ;default is T (getf (rest ir) :check-overlapping t))) (redisplay-record (and redisplay-p (let ((history (output-recording-stream-output-record pane))) (when history #+compulsive-redisplay (when (> (output-record-element-count history) 1) (cerror "Clear the output history and proceed" "Why is there more than one element in this redisplay pane?") (window-clear pane)) (unless (zerop (output-record-element-count history)) (output-record-element history 0))))))) ;; We're trying to get bits on the screen. (cond ((dummy-pane-p pane) ;; Give everyone a chance to update the title bar (when (eql (pane-descriptor-type description) :title) (display-title frame pane))) (t (when *frame-layout-changing-p* (setq force-p t)) (unless *sizing-application-frame* (unless (member pane (slot-value frame 'initialized-panes)) (setq force-p t) (push pane (slot-value frame 'initialized-panes)))) (with-simple-restart (nil "Skip redisplaying pane ~S" pane) (loop (with-simple-restart (nil "Retry displaying pane ~S" pane) (return (cond (display-function ;; If there's a display function, call it to generate new contents. (cond (redisplay-p (cond ((or (null redisplay-record) force-p) (when force-p (window-clear pane)) (call-redisplay-function display-function frame pane)) (t (redisplay redisplay-record pane :check-overlapping check-overlapping)))) ((or force-p (getf options :display-after-commands t)) (unless (and (not force-p) (eq (getf options :display-after-commands) ':no-clear)) (window-clear pane)) (call-display-function display-function frame pane))) (force-output pane)) (force-p ;; If refilling from scratch, give the application a chance ;; to draw stuff (frame-replay frame pane)) ;; Otherwise do nothing, the bits will still be on display ;; and will be refreshed properly if there's a damage event. )))))))))   Received: from BBN.COM by LABS-N.BBN.COM id aa09592; 3 Mar 92 14:00 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa20097; 3 Mar 92 13:54 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 424252; 3 Mar 1992 13:44:59-0500 Date: Tue, 3 Mar 1992 13:44-0500 From: Scott McKay Subject: Speeding up CLIM startup time. To: mthome@BBN.COM, clim@BBN.COM In-Reply-To: The message of 3 Mar 1992 11:15 EST from mthome@BBN.COM Message-ID: <19920303184452.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 3 Mar 1992 11:15 EST From: mthome@BBN.COM In all versions of CLIM I've tried with an X11 implementation, the first window instantiation takes an extraordinarily log time, much of which is spent with the server frozen. With our locally-hacked version of CLIM 0.9, we wouldn't get worried unless the first window took longer than 30 seconds to appear... CLIM 1.0 seems to be doing a little better, but still takes a long time. How much of this startup time is NOT due to the compiling of CLOS dispatch functions? Has anyone looked into this? Has anyone found any ways to speed this up? The CLOS startup overhead varies greatly from one implementation to another, but that's not where most of the time is going. Most of the time is spent getting fonts. As it turns out, John Irwin at Franz, Inc. has fixed this for CLIM 1.1, and the startup time should be much better.   Received: from BBN.COM by LABS-N.BBN.COM id aa09680; 3 Mar 92 14:03 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa20339; 3 Mar 92 13:59 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 424253; 3 Mar 1992 13:49:35-0500 Date: Tue, 3 Mar 1992 13:49-0500 From: Scott McKay Subject: Incremental Redisplay Performance To: taylor@CHARON.arc.nasa.gov, SWM@SAPSUCKER.SCRC.Symbolics.COM, clim@BBN.COM cc: chucko@CHARON.arc.nasa.gov, swanson@PTOLEMY.arc.nasa.gov, kthompso@PTOLEMY.arc.nasa.gov In-Reply-To: <19920303180724.1.TAYLOR@HALEAKALA.arc.nasa.gov> Message-ID: <19920303184926.9.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 3 Mar 1992 13:07 EST From: will taylor Date: Tue, 3 Mar 1992 08:33 PST From: Scott McKay Date: Mon, 2 Mar 1992 21:33 EST From: will taylor A typical redisplay using this technique takes less than a second, while the default redisplay took about 8 seconds (for a 50 node graph). This experience reinforces my hope that CLIM 2.0's implementation and documentation will place more emphasis on incremental redisplay performance -- with the default redisplay functionality my UI was just about unusable. With my modificaitons the UI demonstrates the advertised claims of CLIM. ***New message. I made a mistake in the code I supplied. Sorry.*** This reply is just meant to provide a few more bits of information. Please don't think that I am in any way trying to defend the terrible performance of CLIM's incremental redisplay. Here is a kludgy patch that implements it. I have not tested this in CLIM 1.0, just in CLIM 1.1. Use :INCREMENTAL-REDISPLAY '(T :CHECK-OVERLAPPING NIL) in your pane. Thanks for your detailed response -- I hope that it will be typical of the future documentation of CLIM's incremental redisplay. Will CLIM 1.1 correct the extreme slowness of changing layouts in CLIM 1.0? I went to my own redisplay in that case as well, by creating multiple windows using You'll have to characterize this better. The layout changing in applications I have seen (or written) is quite speedy, at least on Genera, because "bit save" arrays are used. (defmethod MAKE-OVERLAY-WINDOW-STREAM ((frame APPLICATION-FRAME) &key pane-to-overlay default-text-style window-class (scroll-bars :both) (borders t)) "return window stream located over pane-to-overlay -- not in frame layout" (let* ((parent (frame-top-level-window frame)) (input-buffer (stream-input-buffer parent))) (multiple-value-bind (left top right bottom) (bounding-rectangle* pane-to-overlay) (open-window-stream :parent parent :left left :top top :right right :bottom bottom :input-buffer input-buffer :default-text-style default-text-style :scroll-bars scroll-bars :borders borders :window-class window-class)))) which occupy the same frame coordinates and then using (window-expose pane) to expose the pane which belonged to the currently selected layout. Apparently there is a (REDISPLAY-FRAME-PANE frame pane :force-p t) done on each pane on a newly selected layout whether or not the pane is common to the previous layout and whether or not the pane has changed. Hmm, I wonder if the speedups are later than pure CLIM 1.0. In the CLIM's I use (admittedly more recent than yours :-), the forced redisplay is not done on panes that are known to be "initialized". When is CLIM 1.1 to be expected? It varies from vendor to vendor, but all of Lucid, Franz, and Symbolics are presently doing QA on their CLIM 1.1 releases (although I think Lucid is calling it CLIM 1.0). ==> Will Taylor   Received: from BBN.COM by LABS-N.BBN.COM id aa09912; 3 Mar 92 14:29 EST Received: from icsia.Berkeley.EDU by BBN.COM id aa21380; 3 Mar 92 14:17 EST Received: from icsib21.ICSI.Berkeley.EDU by icsia.Berkeley.EDU (4.1/HUB$Revision: 1.11 $) id AA20208; Tue, 3 Mar 92 11:16:52 PST From: bachrach@ICSI.Berkeley.EDU (Jonathan Bachrach) Received: by icsib21.ICSI.Berkeley.EDU (Sun-4.1/CLIENT$Revision: 1.4 $) id AA03462; Tue, 3 Mar 92 11:16:51 PST Date: Tue, 3 Mar 92 11:16:51 PST Message-Id: <9203031916.AA03462@icsib21.ICSI.Berkeley.EDU> To: clim@bbn.com In-Reply-To: "David A. Moon"'s message of Mon, 02 Mar 92 18:17:03 EST <9203022314.AA15436@cambridge.apple.com> Subject: Image Processing in CLIM Cc: heeger@psych.stanford.edu Date: Mon, 02 Mar 92 18:17:03 EST From: "David A. Moon" Re: hacking the color map Not all platforms with color displays have color maps. I believe the design was intended to be that the standard CLIM entry points provide platform-independent graphics with the functionality that all platforms can support, and if you need to do something like control the color map or display 24-bit-color images, that's platform-dependent code that must use platform-specific interfaces, and will work on the subset of platforms that support those interfaces. I guess the problem with this is that these platform-specific interfaces didn't get documented by the vendors of the individual platform-specific versions of CLIM, and perhaps don't even exist in some cases where they could. It seems reasonable that ``usual'' CLIM entry points should provide platform-independent graphics. I think, though, that CLIM should specify a platform-dependent interface for dealing with color image processing. It seems unreasonable to preclude the use of these powerful mechanisms because not all machines support them. In fact, these mechanisms are universal and are implemented by all manufacturers. Therefore, it seems critical to provide a standard CLIM interface to these mechanisms. I would like to know from the implementors, what support they have provided for this platform-dependent case -- specifically, what support have they provided for 8-bit color tables and 24-bit color images? For example, if I want to run CLIM on a 24-bit color machine and use 24-bit color images in a reasonable fashion, am I out of luck? Jonathan Bachrach International Computer Science Institute Telephone: 510-642-4274 x182 1947 Center Street, Suite 633 Fax: 510-643-7684 Berkeley, CA 94704 Email: bachrach@icsi.berkeley.edu   Received: from PEBBLES.BBN.COM by LABS-N.BBN.COM id aa10652; 3 Mar 92 15:39 EST From: burstein@BBN.COM Sender: burstein@BBN.COM To: SWM@sapsucker.scrc.symbolics.com CC: mthome@BBN.COM, clim@BBN.COM In-reply-to: Scott McKay's message of Tue, 3 Mar 1992 12:04-0500 <19920303170445.7.SWM@SUMMER.SCRC.Symbolics.COM> Subject: CLIM 1.0 bug Date: Tue, 3 Mar 92 15:20:26 EST Source-Info: From (or Sender) name not authenticated. ... This works correctly in CLIM 1.1 Can someone please tell me what the official story is about when CLIM 1.1 will be available? Mark Burstein   Received: from BBN.COM by LABS-N.BBN.COM id aa11412; 3 Mar 92 16:42 EST Received: from relay.hp.com by BBN.COM id aa01143; 3 Mar 92 16:37 EST Received: from hpclmp.cup.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA19432; Tue, 3 Mar 92 13:37:37 -0800 Received: by hpclmp.cup.hp.com (15.11/15.5+IOS 3.20+cup+OMrelay) id AA04247; Tue, 3 Mar 92 13:36:56 pst Date: Tue, 3 Mar 92 13:36:56 pst From: Mohammad Pourheidari Message-Id: <9203032136.AA04247@hpclmp.cup.hp.com> To: clim@BBN.COM Subject: request Reply-To: mohammad@hpclmp.cup.hp.com Sorry for the Broadcast to everyone but, Could you please take my name off this list? Thanks, M.   Received: from BBN.COM by LABS-N.BBN.COM id aa11488; 3 Mar 92 16:46 EST Received: from lucid.com by BBN.COM id aa01360; 3 Mar 92 16:40 EST Received: from kuwait.lucid ([192.31.212.118]) by heavens-gate.lucid.com id AA04059g; Tue, 3 Mar 92 13:35:27 PST Received: by kuwait.lucid (4.1/SMI-4.1) id AA26723; Tue, 3 Mar 92 13:40:33 PST Date: Tue, 3 Mar 92 13:40:33 PST From: kern%kuwait@lucid.com (John Kern) Message-Id: <9203032140.AA26723@kuwait.lucid> To: pkarp@ai.sri.com Cc: clim@bbn.com, clim-support@lucid.com In-Reply-To: Peter Karp's message of Mon, 2 Mar 92 20:58:15 PST Subject: bidirectional streams Reply-To: kern@lucid.com Howdy Mr. Karp, This is fixed in the Lucid's forthcoming release of CLIM 1.0. ;;; Dribble file "/scratch/to.karp" started T > (setf root (open-root-window :CLX)) # > (setf ws (open-window-stream :parent root)) # > (setf ws1 (open-window-stream :parent root)) # > (make-two-way-stream ws ws1) # > (dribble) ;;; Dribble file "/scratch/to.karp" finished Sincerely, John Kern Lucid, Inc. Customer Support ================ original message for ease of reference === Return-Path: Date: Mon, 2 Mar 92 20:58:15 PST From: Peter Karp To: clim@bbn.com, clim-support@lucid.com Subject: bidirectional streams I can't get bidirectional streams to work in CLIM; I'm assuming they are not supported? That is, if I do: (clim:make-two-way-stream s1 s2) where s1 for example was returned by clim:open-window-stream, I get an error saying that s1 is not a stream. Are there any plans to support them? I would find them useful in conjunction with clim:accept so that I could give the function a stream argument that would let it read and write from different panes or windows that I specify. Peter   Received: from BBN.COM by LABS-N.BBN.COM id aa11828; 3 Mar 92 17:26 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa03201; 3 Mar 92 17:21 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 424307; 3 Mar 1992 17:11:14-0500 Date: Tue, 3 Mar 1992 17:11-0500 From: Scott McKay Subject: CLIM 1.0 bug To: burstein@BBN.COM, SWM@SAPSUCKER.SCRC.Symbolics.COM cc: mthome@BBN.COM, clim@BBN.COM In-Reply-To: The message of 3 Mar 1992 15:20 EST from burstein@BBN.COM Message-ID: <19920303221106.0.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 3 Mar 1992 15:20 EST From: burstein@BBN.COM ... This works correctly in CLIM 1.1 Can someone please tell me what the official story is about when CLIM 1.1 will be available? No one person can answer this question, since CLIM is independently sold by five different companies. Symbolics will be making CLIM 1.1 available to its customers in the next month or so. I cannot answer for Franz, Lucid, ILA, or Harlequin.   Received: from BBN.COM by LABS-N.BBN.COM id aa11964; 3 Mar 92 17:42 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa03747; 3 Mar 92 17:35 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 424312; 3 Mar 1992 17:25:43-0500 Date: Tue, 3 Mar 1992 17:25-0500 From: Scott McKay Subject: Image Processing in CLIM To: bachrach@icsi.berkeley.edu, clim@BBN.COM cc: heeger@psych.stanford.edu In-Reply-To: <9203031916.AA03462@icsib21.ICSI.Berkeley.EDU> Message-ID: <19920303222533.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 3 Mar 1992 14:16 EST From: Jonathan Bachrach Date: Mon, 02 Mar 92 18:17:03 EST From: "David A. Moon" Re: hacking the color map Not all platforms with color displays have color maps. I believe the design was intended to be that the standard CLIM entry points provide platform-independent graphics with the functionality that all platforms can support, and if you need to do something like control the color map or display 24-bit-color images, that's platform-dependent code that must use platform-specific interfaces, and will work on the subset of platforms that support those interfaces. I guess the problem with this is that these platform-specific interfaces didn't get documented by the vendors of the individual platform-specific versions of CLIM, and perhaps don't even exist in some cases where they could. It seems reasonable that ``usual'' CLIM entry points should provide platform-independent graphics. That is presently the case. I think, though, that CLIM should specify a platform-dependent interface for dealing with color image processing. It seems unreasonable to preclude the use of these powerful mechanisms because not all machines support them. I hardly think it is unreasonable for a product whose main goal is portability to leave unspecified those things that are inherently non-portable. The only suggestion I have heard has been for color "palettes" that are sort of like color maps, but are probably less flexible than you want. In fact, these mechanisms are universal and are implemented by all manufacturers. Therefore, it seems critical to provide a standard CLIM interface to these mechanisms. In what sense do you mean universal? A good analogy might be comparing bicycle wheels, car wheels, wagon wheels, and trains wheels. They're all wheels, but their "UI" is pretty different. What I mean by this analogy is that, sure, there are such mechanisms implemented by a bunch of vendors, but that they are really not very similar. I would like to know from the implementors, what support they have provided for this platform-dependent case -- specifically, what support have they provided for 8-bit color tables and 24-bit color images? None. Which of the several common formats for color maps and the dozen or so formats for 24-bit images should be done first? What sort of algorithm(s) should be used to convert from 24-bit images to 8-bit displays? Is there even the smallest chance that your requirements are not quite different from the requirements of other users? For example, if I want to run CLIM on a 24-bit color machine and use 24-bit color images in a reasonable fashion, am I out of luck? The area of stored color images is an appropriate one for user-written submissions to a public CLIM library. I firmly believe that having CLIM natively support toolkit-style programming is the most important goal for the near term, and that is certainly what we are spending our time on. The paths for accessing a display device directly is made more clear in CLIM 2.0, so it will be somewhat easier to "roll your own" in CLIM 2.0 than it is in CLIM 1.0.   Received: from BBN.COM by LABS-N.BBN.COM id aa12677; 3 Mar 92 18:57 EST Received: from brazil.cambridge.apple.com by BBN.COM id aa05899; 3 Mar 92 18:54 EST Received: from ministry.cambridge.apple.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef) id AA19484; Tue, 3 Mar 92 18:56:48 -0500 for clim@BBN.COM Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef) id AA25274; Tue, 3 Mar 92 18:53:06 -0500 Message-Id: <9203032353.AA25274@cambridge.apple.com> Date: Tue, 03 Mar 92 18:55:59 EST From: moon@cambridge.apple.com (David A. Moon) To: bachrach@icsi.berkeley.edu Subject: Re: Image Processing in CLIM Cc: clim@BBN.COM, heeger@psych.stanford.edu Since the vendors haven't been able to figure out a common interface for color image processing, I think this is an excellent opportunity for the users to get together and specify what they want. I imagine that if a significant number of users can agree on a specification, the vendors will pay a lot more attention, and also will have an easier time if they have a specification to implement from, rather than having to start by guessing what might appeal to users. Be specific. Just an opinion from a bystander, formerly a CLIM implementor.   Received: from BBN.COM by LABS-N.BBN.COM id aa19751; 4 Mar 92 10:16 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa22820; 4 Mar 92 10:11 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 424359; 4 Mar 1992 10:01:45-0500 Date: Wed, 4 Mar 1992 10:01-0500 From: Scott McKay Subject: Re: Image Processing in CLIM To: moon@cambridge.apple.com, bachrach@icsi.berkeley.edu cc: clim@BBN.COM, heeger@psych.stanford.edu In-Reply-To: <9203032353.AA25274@cambridge.apple.com> Message-ID: <19920304150133.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 3 Mar 1992 18:55 EST From: "David A. Moon" Since the vendors haven't been able to figure out a common interface for color image processing, I think this is an excellent opportunity for the users to get together and specify what they want. I imagine that if a significant number of users can agree on a specification, the vendors will pay a lot more attention, and also will have an easier time if they have a specification to implement from, rather than having to start by guessing what might appeal to users. Be specific. Dave is exactly right. The important point is that there must be *agreement* on something *specific*. A less important point is that it should be implementable on all of the important platforms. Just an opinion from a bystander, formerly a CLIM implementor.   Received: from BBN.COM by LABS-N.BBN.COM id aa19828; 4 Mar 92 10:22 EST Received: from gatech.edu by BBN.COM id aa23012; 4 Mar 92 10:16 EST Received: from cc.gatech.edu (hermes.cc.gatech.edu) by gatech.edu (4.1/Gatech-9.1) id AA14261 for clim@BBN.COM; Wed, 4 Mar 92 10:16:37 EST Received: from pravda.cc.gatech.edu by cc.gatech.edu (3.2/SMI-3.2) id AA04366; Wed, 4 Mar 92 10:14:37 EST Received: from sartre.gatech.edu (foucault.cc.gatech.edu) by pravda.cc.gatech.edu (4.1/SMI-4.1) id AA02251; Tue, 3 Mar 92 10:27:11 EST Date: Wed, 4 Mar 1992 10:15-0500 From: Terry Chandler Subject: CLIM To: clim@BBN.COM In-Reply-To: <9203032122.AA23220@cc.gatech.edu> Message-Id: <19920304151557.9.TNC@sartre.gatech.edu> Please Take me off the CLIM list Thanks Terry Chandler tnc@cc.gatech.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa07187; 5 Mar 92 17:24 EST Received: from sigi.cs.colorado.edu by BBN.COM id aa01668; 5 Mar 92 17:12 EST Received: from [128.138.204.81] (csgator11.cs.colorado.edu) by sigi.cs.colorado.edu with SMTP id AA04902 (5.65c/IDA-1.4.4 for ); Thu, 5 Mar 1992 15:11:25 -0700 Date: Thu, 5 Mar 1992 15:11:25 -0700 Message-Id: <199203052211.AA04902@sigi.cs.colorado.edu> To: clim@bbn.com From: stevens@cs.colorado.edu (Curt Stevens) Subject: L: <...> R: <...> in mouse doc line on Mac... Is there some way to change the mouse doc line on the Mac from advertising choices as being available on Left and Right mouse clicks? I would like it to say Single: <...>, Double <...> or something like that. Thanks in advance for any help. ======================================================================== |Curt Stevens (303) 492-1218 | / |arpa:stevens@sigi.cs.colorado.edu | |Univ. of Colorado, Boulder |o o|uucp:ncar!sigi.cs.colordo.edu!{...}| |Computer Sci. Dept. ECOT 7-7 | | |-----------------------------------| |Campus Box 430 |\_/| I contradict myself? Very well, I | |Boulder, Colorado 80309 USA | | contradict myself. - Walt Whitman | ========================================================================   Received: from BBN.COM by LABS-N.BBN.COM id aa08096; 5 Mar 92 19:15 EST Received: from life.ai.mit.edu by BBN.COM id aa05352; 5 Mar 92 19:09 EST Received: from kix (kix.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA03408; Thu, 5 Mar 92 19:09:54 EST From: jba@ai.mit.edu (Jonathan Amsterdam) Received: by kix (4.1/AI-4.10) id AA06774; Thu, 5 Mar 92 19:08:15 EST Date: Thu, 5 Mar 92 19:08:15 EST Message-Id: <9203060008.AA06774@kix> To: clim@bbn.com Subject: do geometry operations work? I'm spanking new (< 48 hrs) to CLIM, so please forgive me if I've missed some crucial documentation or disclaimer. I'm using CLIM 1.0 (I think--is the version number in the image somewhere?) in Lucid on a Sparc. It seems that various region operations don't work for certain classes, notably polygons. E.g. if p1 and p2 are overlapping polygons, then (region-intersection p1 p2) is +nowhere+. Region-difference gives the message >>Error: (:REGION1 :REGION2) is not a valid initialization argument list in this call to MAKE-INSTANCE (METHOD REGION-DIFFERENCE (REGION REGION)): Required arg 0 (REGION1): # Required arg 1 (REGION2): # So that's question 1. Question 2 is, when these things do eventually work, are they just going to create region-sets, or are they going to make some effort to create a drawable thing? If the intersection of two polygons is a polygon, I'd like to get my hands on that polygon, not on some object which says "this is the intersection of two polygons". Apologies in advance for my naivete--I was hoping to use this piece of CLIM as the substrate for some genuine 2D geometrical reasoning. Jonathan Amsterdam   Received: from BBN.COM by LABS-N.BBN.COM id aa09014; 5 Mar 92 22:25 EST Received: from FUJI.ILA.COM by BBN.COM id aa10491; 5 Mar 92 22:21 EST Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 306927; 5 Mar 92 22:20:52 EST Date: Thu, 5 Mar 1992 18:25-0800 From: William M. York Subject: do geometry operations work? To: jba@ai.mit.edu, clim@bbn.com In-Reply-To: <9203060008.AA06774@kix> Message-ID: <19920306022555.9.YORK@Chuck-Jones.West.Dialnet.ILA.COM> Date: Thu, 5 Mar 1992 16:08 PST From: Jonathan Amsterdam I'm spanking new (< 48 hrs) to CLIM, so please forgive me if I've missed some crucial documentation or disclaimer. I'm using CLIM 1.0 (I think--is the version number in the image somewhere?) in Lucid on a Sparc. It seems that various region operations don't work for certain classes, notably polygons. E.g. if p1 and p2 are overlapping polygons, then (region-intersection p1 p2) is +nowhere+. Region-difference gives the message >>Error: (:REGION1 :REGION2) is not a valid initialization argument list in this call to MAKE-INSTANCE (METHOD REGION-DIFFERENCE (REGION REGION)): Required arg 0 (REGION1): # Required arg 1 (REGION2): # So that's question 1. That is the result of a typo bug in CLIM. Evaluate this (in the CLIM-UTILS package) as a fix: (defclass standard-region-difference (region-set area) ((region1 :type region :initarg :region1) (region2 :type region :initarg :region2) (regions :type list))) Question 2 is, when these things do eventually work, are they just going to create region-sets, or are they going to make some effort to create a drawable thing? If the intersection of two polygons is a polygon, I'd like to get my hands on that polygon, not on some object which says "this is the intersection of two polygons". Apologies in advance for my naivete--I was hoping to use this piece of CLIM as the substrate for some genuine 2D geometrical reasoning. For now the non-rectangle cases are handled by the REGION-DIFFERENCE object fallback. This is just due to lack of any resources focused in this area. Apparently not much use is being made of polygon arithmetic, since the problem report above is somewhat of a show-stopper. If someone came up with some good polygon-intersection and -difference code, I'm sure that the right methods for REGION-XXX on polygon classes could be added to CLIM. Sorry. Jonathan Amsterdam   Date: Fri, 6 Mar 92 6:39:13 EST From: Nichael Cramer To: clim@bbn.com Subject: Making frames go away In Lucid CLIM 1.0 beta on Sparc, SunOS 4.1... I'm having trouble getting rid of frames on a simple exit. Two easy-to-get-at examples occur in the clim-1.0b/tutorial/ directory. Both the TIC-TAC-TOE.lisp and the PUZZLE-5.lisp use calls of the form: (clim:frame-exit *application-frame*) in their exit-commands. However, upon exit the frame is dead but still "exposed"; i.e. it's still visible on the screen. Am I missing something obvious? Thanks Nichael   Received: from BBN.COM by LABS-N.BBN.COM id aa14095; 6 Mar 92 10:28 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa25170; 6 Mar 92 10:21 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 424578; 6 Mar 1992 10:11:21-0500 Date: Fri, 6 Mar 1992 10:20-0500 From: Scott McKay Subject: Making frames go away To: ncramer@BBN.COM, clim@BBN.COM In-Reply-To: The message of 6 Mar 1992 06:39 EST from Nichael Cramer Message-ID: <19920306152059.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 6 Mar 1992 06:39 EST From: Nichael Cramer In Lucid CLIM 1.0 beta on Sparc, SunOS 4.1... I'm having trouble getting rid of frames on a simple exit. Two easy-to-get-at examples occur in the clim-1.0b/tutorial/ directory. Both the TIC-TAC-TOE.lisp and the PUZZLE-5.lisp use calls of the form: (clim:frame-exit *application-frame*) in their exit-commands. However, upon exit the frame is dead but still "exposed"; i.e. it's still visible on the screen. Am I missing something obvious? I recall this behavior, and I believe that later vintages of CLIM 1 do what you expect, i.e., bury the frame's window. My usual disclaimer about the availability of "later vintages of CLIM 1" still apply...   Received: from BBN.COM by LABS-N.BBN.COM id aa14191; 6 Mar 92 10:41 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa25780; 6 Mar 92 10:34 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 424580; 6 Mar 1992 10:24:36-0500 Date: Fri, 6 Mar 1992 10:34-0500 From: Scott McKay Subject: L: <...> R: <...> in mouse doc line on Mac... To: stevens@cs.colorado.edu, clim@BBN.COM In-Reply-To: <199203052211.AA04902@sigi.cs.colorado.edu> Message-ID: <19920306153413.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 5 Mar 1992 17:11 EST From: Curt Stevens Is there some way to change the mouse doc line on the Mac from advertising choices as being available on Left and Right mouse clicks? I would like it to say Single: <...>, Double <...> or something like that. Thanks in advance for any help. I guess I never really thought that this should be tailorable. Oh well. You can modify the following function if you would like. Please be aware that hacking this function won't work for CLIM 2.0. Perhaps we will come up with something that keeps you from having to do anything. (in-package :clim) (defun frame-document-highlighted-presentation-internal (frame presentation input-context window x y stream) (let ((shift-mask (window-shift-mask window))) (declare (fixnum shift-mask)) (multiple-value-bind (left left-context middle middle-context right right-context) (find-applicable-translators-for-documentation presentation input-context frame window x y shift-mask) (let* ((*print-length* 3) (*print-level* 2) (*print-circle* nil) (*print-array* nil) (*print-readably* nil) (*print-pretty* nil)) (flet ((document-translator (translator context-type button-name separator) ;; Assumes 5 shifts and the reverse ordering of *POINTER-SHIFTS* (let ((bit #o20) (shift-name '("h-" "s-" "m-" "c-" "sh-"))) (declare (fixnum bit)) (dotimes (i 5) #-excl (declare (ignore i)) (unless (zerop (logand bit shift-mask)) (write-string (car shift-name) stream)) (pop shift-name) (setq bit (the fixnum (ash bit -1))))) (write-string button-name stream) (document-presentation-translator translator presentation context-type frame nil window x y :stream stream :documentation-type :pointer) (write-string separator stream))) (declare (dynamic-extent #'document-translator)) (when left (let ((button-name (cond ((and (eql left middle) (eql left right)) (setq middle nil right nil) "L,M,R: ") ((eql left middle) (setq middle nil) "L,M: ") (t "L: ")))) (document-translator left left-context button-name (if (or middle right) "; " ".")))) (when middle (let ((button-name (cond ((eql middle right) (setq right nil) "M,R: ") (t "M: ")))) (document-translator middle middle-context button-name (if right "; " ".")))) (when right (document-translator right right-context "R: " ".")) ;; Return non-NIL if any pointer documentation was produced (or left middle right))))))   Received: from BBN.COM by LABS-N.BBN.COM id aa14457; 6 Mar 92 11:00 EST Received: from ALDERAAN.SCRC.Symbolics.COM by BBN.COM id aa27163; 6 Mar 92 10:53 EST Received: from JUBJUB.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via INTERNET with SMTP id 498993; 6 Mar 1992 10:13:30-0500 Date: Fri, 6 Mar 1992 10:13-0500 From: John G. Aspinall Subject: Making frames go away To: ncramer@BBN.COM, clim@BBN.COM In-Reply-To: The message of 6 Mar 1992 06:39 EST from Nichael Cramer Message-ID: <19920306151328.9.JGA@JUBJUB.SCRC.Symbolics.COM> Date: Fri, 6 Mar 1992 06:39 EST From: Nichael Cramer In Lucid CLIM 1.0 beta on Sparc, SunOS 4.1... I'm having trouble getting rid of frames on a simple exit. Two easy-to-get-at examples occur in the clim-1.0b/tutorial/ directory. Both the TIC-TAC-TOE.lisp and the PUZZLE-5.lisp use calls of the form: (clim:frame-exit *application-frame*) in their exit-commands. However, upon exit the frame is dead but still "exposed"; i.e. it's still visible on the screen. The frames are supposed to de-expose themselves upon exit, but remain around in the lisp environment so you can return to them. (This is what happens under Genera.) There's an unwind-protect in the :around method on run-frame-top-level that does (setf (window-visibility top-level-window) nil). Perhaps this doesn't do the right thing on some window systems. I imagine you'll get further comment from the Lucid folks.   Received: from BBN.COM by LABS-N.BBN.COM id aa14410; 6 Mar 92 10:57 EST Received: from lucid.com by BBN.COM id aa26992; 6 Mar 92 10:50 EST Received: from kuwait.lucid ([192.31.212.118]) by heavens-gate.lucid.com id AA15627g; Fri, 6 Mar 92 07:45:41 PST Received: by kuwait.lucid (4.1/SMI-4.1) id AA20352; Fri, 6 Mar 92 07:50:51 PST Date: Fri, 6 Mar 92 07:50:51 PST From: kern%kuwait@lucid.com (John Kern) Message-Id: <9203061550.AA20352@kuwait.lucid> To: ncramer@BBN.COM Cc: clim@BBN.COM, clim-support@lucid.com In-Reply-To: Nichael Cramer's message of Fri, 6 Mar 92 6:39:13 EST <9203061211.AA15103@lucid.com> Subject: Making frames go away Reply-To: kern@lucid.com Howdy, In Lucid CLIM 1.0 Beta, this form (clim:frame-exit *application-frame*) just terminates the top level loop. In the forthcoming release, the addition step of making the window invisible is also taken. To obtain the behavior in CLIM 1.0 Beta try: (define-to-do-command (com-quit-to-do :menu "Quit") () (let ((ftlw (frame-top-level-window *application-frame*))) (setf (window-visibility ftlw) nil) (force-output ftlw)) (frame-exit *application-frame*)) Hope this Helps. Sincerely, John S. Kern Lucid, Inc. Customer Support =========== original message =============== Return-Path: Date: Fri, 6 Mar 92 6:39:13 EST From: Nichael Cramer To: clim@BBN.COM Subject: Making frames go away In Lucid CLIM 1.0 beta on Sparc, SunOS 4.1... I'm having trouble getting rid of frames on a simple exit. Two easy-to-get-at examples occur in the clim-1.0b/tutorial/ directory. Both the TIC-TAC-TOE.lisp and the PUZZLE-5.lisp use calls of the form: (clim:frame-exit *application-frame*) in their exit-commands. However, upon exit the frame is dead but still "exposed"; i.e. it's still visible on the screen. Am I missing something obvious? Thanks Nichael   Received: from BBN.COM by LABS-N.BBN.COM id aa14069; 6 Mar 92 10:25 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa25055; 6 Mar 92 10:19 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 424575; 6 Mar 1992 10:09:08-0500 Date: Fri, 6 Mar 1992 10:18-0500 From: Scott McKay Subject: do geometry operations work? To: York@chuck-jones.west.dialnet.ila.com, jba@ai.mit.edu, clim@BBN.COM In-Reply-To: <19920306022555.9.YORK@Chuck-Jones.West.Dialnet.ILA.COM> Message-ID: <19920306151842.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 5 Mar 1992 21:25 EST From: "William M. York" Date: Thu, 5 Mar 1992 16:08 PST From: Jonathan Amsterdam Question 2 is, when these things do eventually work, are they just going to create region-sets, or are they going to make some effort to create a drawable thing? If the intersection of two polygons is a polygon, I'd like to get my hands on that polygon, not on some object which says "this is the intersection of two polygons". Apologies in advance for my naivete--I was hoping to use this piece of CLIM as the substrate for some genuine 2D geometrical reasoning. For now the non-rectangle cases are handled by the REGION-DIFFERENCE object fallback. This is just due to lack of any resources focused in this area. Apparently not much use is being made of polygon arithmetic, since the problem report above is somewhat of a show-stopper. If someone came up with some good polygon-intersection and -difference code, I'm sure that the right methods for REGION-XXX on polygon classes could be added to CLIM. Sorry. It is currently the intention that CLIM 2.0 will either relegate the more complex region code to PROVIDEd modules that can be requested via REQUIRE, or eliminated altogether. Unfortunately, as Bill points out, there has been insufficient attention focused on this area. There are a few questions that CLIM users need to answer on this subject: (1) How important is it that a full complement of region arithmetic be provided so that people can do 2D geometrical reasoning? (2) Is it sufficient to provide just enough functionality so that people can simply render these objects? (This is less work then providing support for doing reasoning.) (3) What things would you give up in order to support (1) or (2). That is, what is less important? Examples of things to trade off against include support for gadgets, support for fast low-level drawing optimizations, support for "color maps", and so forth.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa14647; 6 Mar 92 11:22 EST To: Scott McKay cc: York@chuck-jones.west.dialnet.ila.com, jba@ai.mit.edu, clim@BBN.COM Subject: Re: do geometry operations work? In-reply-to: Your message of Fri, 06 Mar 92 10:18:00 -0500. <19920306151842.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 06 Mar 92 11:10:22 -0500 From: kanderso@BBN.COM Date: Fri, 6 Mar 1992 10:18-0500 From: Scott McKay Subject: do geometry operations work? To: York@chuck-jones.west.dialnet.ila.com, jba@ai.mit.edu, clim@BBN.COM Date: Thu, 5 Mar 1992 21:25 EST From: "William M. York" Date: Thu, 5 Mar 1992 16:08 PST From: Jonathan Amsterdam It is currently the intention that CLIM 2.0 will either relegate the more complex region code to PROVIDEd modules that can be requested via REQUIRE, or eliminated altogether. Unfortunately, as Bill points out, there has been insufficient attention focused on this area. There are a few questions that CLIM users need to answer on this subject: (1) How important is it that a full complement of region arithmetic be provided so that people can do 2D geometrical reasoning? (2) Is it sufficient to provide just enough functionality so that people can simply render these objects? (This is less work then providing support for doing reasoning.) (3) What things would you give up in order to support (1) or (2). That is, what is less important? Examples of things to trade off against include support for gadgets, support for fast low-level drawing optimizations, support for "color maps", and so forth. When i read about region stuff a while back i had a strong gut reaction that it was way too much. My applications, so far, have much simpler requirements. I vote for concentrating on things that really matter to CLIM users as a whole, such as performance, and colors. k   Received: from BBN.COM by LABS-N.BBN.COM id aa14803; 6 Mar 92 11:35 EST Received: from aristotle.ils.nwu.edu by BBN.COM id aa00237; 6 Mar 92 11:31 EST Received: by aristotle.ils.nwu.edu (4.1/SMI-ILS-1.05) id AA03457; Fri, 6 Mar 92 10:18:15 CST Date: Fri, 6 Mar 92 10:18:15 CST From: forbus@aristotle.ils.nwu.edu (Kenneth Forbus) Message-Id: <9203061618.AA03457@aristotle.ils.nwu.edu> To: SWM@sapsucker.scrc.symbolics.com Cc: York@chuck-jones.west.dialnet.ila.com, jba@ai.mit.edu, clim@BBN.COM In-Reply-To: Scott McKay's message of Fri, 6 Mar 1992 10:18-0500 <19920306151842.8.SWM@SUMMER.SCRC.Symbolics.COM> Subject: Re: do geometry operations work? I love geometric reasoning as well as the next person, but I'd put color maps and SPEED, especially SPEED, as the highest priorities for what we're doing. CLIM shouldn't be painful with 32MB and 27MIPS, but it is. 64MB helps alot. But optimizing the low-level stuff would help even more..   Received: from BBN.COM by LABS-N.BBN.COM id aa14898; 6 Mar 92 11:40 EST Received: from PDESDS1.ATG.TRC.SCRA.ORG by BBN.COM id aa00539; 6 Mar 92 11:35 EST Received: by pdesds1.atg.trc.scra.org (5.57/Ultrix3.0-C) id AA00844; Fri, 6 Mar 92 11:34:44 -0500 Date: Fri, 6 Mar 1992 11:35-0500 From: Craig Lanning Subject: Making frames go away To: Scott McKay Cc: ncramer@bbn.com, clim@bbn.com In-Reply-To: <19920306152059.2.SWM@SUMMER.SCRC.Symbolics.COM> Message-Id: <19920306163541.8.CLANNING@PWA.AMRC-PWA.TRC.SCRA.ORG> Date: Fri, 6 Mar 1992 10:20 EST From: Scott McKay Date: Fri, 6 Mar 1992 06:39 EST From: Nichael Cramer In Lucid CLIM 1.0 beta on Sparc, SunOS 4.1... I'm having trouble getting rid of frames on a simple exit. Two easy-to-get-at examples occur in the clim-1.0b/tutorial/ directory. Both the TIC-TAC-TOE.lisp and the PUZZLE-5.lisp use calls of the form: (clim:frame-exit *application-frame*) in their exit-commands. However, upon exit the frame is dead but still "exposed"; i.e. it's still visible on the screen. Am I missing something obvious? I recall this behavior, and I believe that later vintages of CLIM 1 do what you expect, i.e., bury the frame's window. My usual disclaimer about the availability of "later vintages of CLIM 1" still apply... When will Symbolics' "later vintage of CLIM 1" be available? And, what can I do about it in the mean time? My application is running on a Symbolics 3620 and allows someone using an X11 server to request that the window be displayed on their screen. I need a solution NOW because in one week it will be nearly impossible for me to get permission to change the code. Craig Lanning   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa15228; 6 Mar 92 12:05 EST Received: by KARIBA.BBN.COM id ab00921; 6 Mar 92 11:53 EST To: Scott McKay CC: clim@BBN.COM Subject: Re: do geometry operations work? In-reply-to: Your message of Fri, 06 Mar 92 10:18:00 -0500. <19920306151842.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 06 Mar 92 11:50:37 -0500 Message-ID: <261.699900637@bbn.com> From: Jeff Morrill Date: Fri, 6 Mar 1992 10:18-0500 From: Scott McKay Subject: do geometry operations work? To: York@chuck-jones.west.dialnet.ila.com, jba@ai.mit.edu, clim@BBN.COM ... (3) What things would you give up in order to support (1) or (2). That is, what is less important? Examples of things to trade off against include support for gadgets, support for fast low-level drawing optimizations, support for "color maps", and so forth. I'd much rather have CLIM do a few things well than to try to do everything in a mediocre fashion. Complex region code is neat but the proportion of applications that would use it is (from my point of view) relatively small. I'd like to see: (1) Correctness. Symbolics (Scott McKay) seems to be doing the lion's share of this. Do any of the other vendors contribute manpower to this critical area? (2) Speed. Portable user interface code that is also fast will give Common Lisp a feature that most competing languages dont have. I have witnessed some pressure to abandon Lisp in favor of C and other "less exotic" languages that are fast. I personally believe that CLIM may be Lisp's salvation, if it can achieve speed and correctness. I would refer you all to the article by Dick Gabriel from AI Expert (June 91), "LISP: good news, bad news, how to win big." "The big complex system scenario goes like this. First, the right thing needs to be designed. Then its implementation needs to be designed. Finally, it is implemented. Because it is the right thing, it has nearly 100% of desired functionality, and implementation simplicity was never a concern so it takes a long time to implement. It is large and complex. It requires complex tools to use properly. The last 20% takes 80% of the effort, so the right thing takes a long time to get out, and it only runs satisfactorily on the most sophisticated hardware." Sound familiar? The bottom line is that we could spend forever adding various neat features. In the mean time, those of us who have a product to put out will be forced into taking Motif and C++ classes. Impatiently, jeff morrill jmorrill@bbn.com   Received: from BBN.COM by LABS-N.BBN.COM id aa15260; 6 Mar 92 12:09 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa03009; 6 Mar 92 12:06 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 424609; 6 Mar 1992 11:56:13-0500 Date: Fri, 6 Mar 1992 12:05-0500 From: Scott McKay Subject: Making frames go away To: CLanning@pdesds1.atg.trc.scra.org, SWM@SAPSUCKER.SCRC.Symbolics.COM cc: ncramer@bbn.com, clim@bbn.com In-Reply-To: <19920306163541.8.CLANNING@PWA.AMRC-PWA.TRC.SCRA.ORG> Message-ID: <19920306170542.6.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 6 Mar 1992 11:35 EST From: Craig Lanning Date: Fri, 6 Mar 1992 10:20 EST From: Scott McKay Date: Fri, 6 Mar 1992 06:39 EST From: Nichael Cramer In Lucid CLIM 1.0 beta on Sparc, SunOS 4.1... I'm having trouble getting rid of frames on a simple exit. Two easy-to-get-at examples occur in the clim-1.0b/tutorial/ directory. Both the TIC-TAC-TOE.lisp and the PUZZLE-5.lisp use calls of the form: (clim:frame-exit *application-frame*) in their exit-commands. However, upon exit the frame is dead but still "exposed"; i.e. it's still visible on the screen. Am I missing something obvious? I recall this behavior, and I believe that later vintages of CLIM 1 do what you expect, i.e., bury the frame's window. My usual disclaimer about the availability of "later vintages of CLIM 1" still apply... When will Symbolics' "later vintage of CLIM 1" be available? And, what can I do about it in the mean time? It will be available in the next few weeks. I don't know what the software distribution arrangements are; you should contact someone in software support at Symbolics to find out. My application is running on a Symbolics 3620 and allows someone using an X11 server to request that the window be displayed on their screen. I need a solution NOW because in one week it will be nearly impossible for me to get permission to change the code. You need a solution to what? If you need a solution to a frame still being visible on the screen, just click on the close box.   Received: from BBN.COM by LABS-N.BBN.COM id aa07983; 13 Mar 92 10:07 EST Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa20309; 13 Mar 92 9:48 EST Received: from FELDBERG.SGER.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 671556; 13 Mar 1992 09:48:05-0500 Received: from KILIMANJARO.SGER.Dialnet.Symbolics.COM by FELDBERG.SGER.Dialnet.Symbolics.COM via INTERNET with SMTP id 36429; 13 Mar 1992 15:38:59+0100 Date: Fri, 13 Mar 1992 15:38+0100 From: Markus Fischer Subject: CLIM Workshop To: clim%bbn.com@riverside.scrc.symbolics.com Message-ID: <19920313143858.1.MF@KILIMANJARO.SGER.Dialnet.Symbolics.COM> Dear CLIM users, Symbolics Germany is thinking about doing a 3-day CLIM workshop for experienced CLIM users(programmers). The workshop would be hosted by Scott McKay, one of the developers of CLIM. A possible time to do the workshop would be May, 11. to 13. If you find this idea of supporting the CLIM community interesting, please let me know, or alternatively, contact: Susanne Jacob, phone +49 6196 4722-125 Best regards, Markus Fischer Consulting Services Symbolics Systemhaus GmbH Mergenthaler Allee 77-81 W-6236 Eschborn Germany Phone +49 6196 4722-0   Received: from BBN.COM by LABS-N.BBN.COM id aa09991; 13 Mar 92 13:02 EST Received: from elroy.jpl.nasa.gov by BBN.COM id aa29306; 13 Mar 92 12:58 EST Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA26551; Fri, 13 Mar 92 09:57:50 PST Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA05852; Fri, 13 Mar 92 09:52:12 PST Date: Fri, 13 Mar 92 09:52:12 PST From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9203131752.AA05852@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: accepting-values recursively I'm hitting slow turnaround time in accepting-values with objects that can have over a thousand accepts for their parameters. I can break them down by doing recursive calls to accepting-values. This will require a bit of recoding on my part and before I try it I want to know if anybody has tried recursion on accepting-values. If so, is there any special undocumented gotcha's that I will have to worry about? Will I gain response speed by doing this way? I'm thinking of implementing this beast in the following manner: (accepting-values ... 1 2 (accepting-values ... The numbers are just separate 3 different accept forms!!!!!! 4 5 ) 6 (accepting-values ... 7 8 ) ....)   Received: from BBN.COM by LABS-N.BBN.COM id aa10045; 13 Mar 92 13:05 EST Received: from cs.utexas.edu by BBN.COM id aa29309; 13 Mar 92 12:59 EST Received: from sage.cs.utexas.edu by cs.utexas.edu (5.64/1.121) with SMTP id AA02467; Fri, 13 Mar 92 11:49:05 -0600 Received: by sage.cs.utexas.edu (5.64/Client) id AA03621; Fri, 13 Mar 92 11:40:52 -0600 Message-Id: <9203131740.AA03621@sage.cs.utexas.edu> From: eilerts@cs.utexas.edu (Erik Eilerts) Date: Fri, 13 Mar 1992 11:40:51 -0600 X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: clim@bbn.com Subject: Menus First, I'd like to be added to this mailing list. Secondly, I have a question about menu's. I'm currently using the following code segment to popup my menus: (clim:with-menu (menu parent) ; (setf (slot-value menu 'clim::vertical-scroll-bar) nil) (clim:menu-choose-from-drawer menu 'clim:menu-item #'setup-menu)))))) but the problem I have is that I don't want the scroll bar to appear on the menu. I tried deleting it, as you can see above, but this didn't work. So, does anybody know how I can get around this problem? Thanks, Erik Eilerts University of Texas at Austin eilerts@cs.utexas.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa10918; 13 Mar 92 14:37 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id ab05108; 13 Mar 92 14:24 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 425144; 13 Mar 1992 14:14:38-0500 Date: Fri, 13 Mar 1992 14:24-0500 From: Scott McKay Subject: accepting-values recursively To: curt@eraserhead.jpl.nasa.gov, clim@BBN.COM In-Reply-To: <9203131752.AA05852@eraserhead.Jpl.Nasa.Gov> Message-ID: <19920313192411.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 13 Mar 1992 12:52 EST From: Curt Eggemeyer I'm hitting slow turnaround time in accepting-values with objects that can have over a thousand accepts for their parameters. I can break them down by doing recursive calls to accepting-values. This will require a bit of recoding on my part and before I try it I want to know if anybody has tried recursion on accepting-values. If so, is there any special undocumented gotcha's that I will have to worry about? Will I gain response speed by doing this way? I'm thinking of implementing this beast in the following manner: Recursive calls to ACCEPTING-VALUES will work. I suggest that the recursive calls actually appear inside of calls to ACCEPT-VALUES-COMMAND-BUTTON. Actually, what I really suggest is that you decompose the attributes for your objects into multiple orthogonal subsets. Any dialog with a thousand items in it, no matter how speedy, will be a very difficult user interface. It's just too much data too display in a dialog to be easily understood by most humans I know. (accepting-values ... 1 2 (accepting-values ... The numbers are just separate 3 different accept forms!!!!!! 4 5 ) 6 (accepting-values ... 7 8 ) ....)   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa11059; 13 Mar 92 14:48 EST Received: by KARIBA.BBN.COM id aa02155; 13 Mar 92 14:35 EST To: Curt Eggemeyer cc: clim@BBN.COM Subject: Re: accepting-values recursively In-reply-to: Your message of Fri, 13 Mar 92 09:52:12 -0800. <9203131752.AA05852@eraserhead.Jpl.Nasa.Gov> Date: Fri, 13 Mar 92 14:21:53 -0500 From: kanderso@BBN.COM Date: Fri, 13 Mar 92 09:52:12 PST From: Curt Eggemeyer To: clim@BBN.COM Subject: accepting-values recursively I'm hitting slow turnaround time in accepting-values with objects that can have over a thousand accepts for their parameters. I can break them down by doing recursive calls to accepting-values. This will require a bit of recoding on my part and before I try it I want to know if anybody has tried recursion on accepting-values. If so, is there any special undocumented gotcha's that I will have to worry about? Will I gain response speed by doing this way? I'm thinking of implementing this beast in the following manner: I don't think using ACCEPTING-VALUES recursively will help. You should be using query identifiers, of course. The best way is to cut down on what you present to the user. For example, you might do (setq details? (accept 'boolean ...) ... accept the details. This way the user can open and close portions of the dialog. k   Received: from BBN.COM by LABS-N.BBN.COM id aa12207; 13 Mar 92 16:04 EST Received: from ALDERAAN.SCRC.Symbolics.COM by BBN.COM id aa09037; 13 Mar 92 15:59 EST Received: from JUBJUB.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via INTERNET with SMTP id 499451; 13 Mar 1992 15:59:43-0500 Date: Fri, 13 Mar 1992 15:59-0500 From: John G. Aspinall Subject: accepting-values recursively To: curt@eraserhead.jpl.nasa.gov cc: clim@BBN.COM In-Reply-To: <9203131752.AA05852@eraserhead.Jpl.Nasa.Gov> Message-ID: <19920313205937.3.JGA@JUBJUB.SCRC.Symbolics.COM> SWM and KAnderson each make good suggestions about breaking up large dialogs. There's another point that people are missing, I think. The semantics of nested accepting-values isn't defined. I'd like to see a description of the behaviour that is desired. (Practically speaking, accepting-values is a loop that runs repeatedly until you exit. User code specifies the appearance of the display. If you put anything in the display part of the loop *other than accepts and buttons* (which are treated specially) that asks for input, then you are asking the display phase to pause, unfinished, while you do something else. That, to my mind, breaks the contract of the (outer) accepting values.) Note: I'm referring to accepting-values simply nested within other accepting-values, not to accepting-values within buttons within accepting-values as SWM was proposing.   Received: from BBN.COM by LABS-N.BBN.COM id aa12243; 13 Mar 92 16:09 EST Received: from bunny.gte.com by BBN.COM id aa09334; 13 Mar 92 16:03 EST Received: from vega by bunny.gte.com (5.61/GTEL2.19) id AA22796; Fri, 13 Mar 92 16:03:45 -0500 Date: Fri, 13 Mar 1992 16:03-0500 From: Richard J Brandau Subject: Rotated Text? To: clim@BBN.COM Cc: Rjb1%vega@gte.com Message-Id: <19920313210339.7.RJB1@vega.gte.com> OK, I give up: How does one get rotated text in CLIM 1.0? So far I've been uniformly unsuccessful regardless of approach or platform (Genera 8.1, Allegro 4.0.1 on a Sun, or MCL 2.0). Either I'm really confused, or this is really tricky.   Received: from BBN.COM by LABS-N.BBN.COM id aa11991; 13 Mar 92 15:53 EST Received: from lucid.com by BBN.COM id aa08577; 13 Mar 92 15:49 EST Received: from campeau.lucid (campeau.lucid.com) by heavens-gate.lucid.com id AA08309g; Fri, 13 Mar 92 12:33:07 PST Site: Received: by campeau.lucid (4.1/SMI-4.1) id AA09222; Fri, 13 Mar 92 12:38:26 PST Date: Fri, 13 Mar 92 12:38:26 PST From: pw@lucid.com (Paul Wieneke) Message-Id: <9203132038.AA09222@campeau.lucid> To: clim@bbn.com Subject: CLIM 1.1 from Lucid I've been asked to send a blurb regarding Lucid forthcoming CLIM 1.1 release. My understanding is that I shouldn't use the internet for marketing information so at the risk of sounding like I'm hedging, I have to ask you to contact Lucid directly for information on product availability, pricing, and support.   Received: from BBN.COM by LABS-N.BBN.COM id aa12960; 13 Mar 92 17:08 EST Received: from Sunset.AI.SRI.COM by BBN.COM id aa12647; 13 Mar 92 17:05 EST Received: from Rockaway.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA19384 for clim@BBN.COM; Fri, 13 Mar 92 14:04:55 PST Received: by Rockaway.AI.SRI.COM (4.1/SMI-4.1) id AA12286 for Rjb1%vega@gte.com; Fri, 13 Mar 92 14:04:54 PST Date: Fri, 13 Mar 92 14:04:53 PST From: Peter Karp To: Richard J Brandau Cc: clim@BBN.COM, Rjb1%vega@gte.com Subject: Re: Rotated Text? In-Reply-To: Your message of Fri, 13 Mar 1992 16:03-0500 Message-Id: I've been told that rotating or scaling text is impossible in CLIM 1.0, but that such capability might be part of CLIM 2.0. For our application we would find this capability very useful, both for display graphics and for hardcopy. Particularly for hardcopy. Peter   Received: from BBN.COM by LABS-N.BBN.COM id aa13219; 13 Mar 92 17:29 EST Received: from YUKON.SCRC.Symbolics.COM by BBN.COM id aa13400; 13 Mar 92 17:24 EST Received: from LILIKOI.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via INTERNET with SMTP id 782398; 13 Mar 1992 17:26:18-0500 Date: Fri, 13 Mar 1992 17:33-0500 From: Mark Nahabedian Subject: Rotated Text? To: rjb1%vega@gte.com, clim@BBN.COM In-Reply-To: <19920313210339.7.RJB1@vega.gte.com> Message-ID: <19920313223309.1.NAHA@LILIKOI.SCRC.Symbolics.COM> Unfortunately, rotated text is not yet supported. Specifying a rotation (or any other transformation, for that matter) transforms the starting point for the string, but the direction of the string is not affected. If you just need to label vertical axes in a plot or something like that, you can use CLIM:DRAW-VERTICAL-STRING.   Received: from BBN.COM by LABS-N.BBN.COM id aa13237; 13 Mar 92 17:30 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa13404; 13 Mar 92 17:24 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 425180; 13 Mar 1992 17:12:36-0500 Date: Fri, 13 Mar 1992 17:22-0500 From: Scott McKay Subject: Rotated Text? To: rjb1%vega@gte.com, clim@BBN.COM In-Reply-To: <19920313210339.7.RJB1@vega.gte.com> Message-ID: <19920313222216.5.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 13 Mar 1992 16:03 EST From: Richard J Brandau OK, I give up: How does one get rotated text in CLIM 1.0? So far I've been uniformly unsuccessful regardless of approach or platform (Genera 8.1, Allegro 4.0.1 on a Sun, or MCL 2.0). Either I'm really confused, or this is really tricky. Unfortunately you don't. CLIM 1.0 doesn't support it.   Received: from BBN.COM by LABS-N.BBN.COM id aa13259; 13 Mar 92 17:31 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa13412; 13 Mar 92 17:24 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 425182; 13 Mar 1992 17:13:15-0500 Date: Fri, 13 Mar 1992 17:22-0500 From: Scott McKay Subject: Rotated Text? To: rjb1%vega@gte.com, clim@BBN.COM In-Reply-To: <19920313210339.7.RJB1@vega.gte.com> Supersedes: <19920313222216.5.SWM@SUMMER.SCRC.Symbolics.COM> Message-ID: <19920313222256.6.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 13 Mar 1992 16:03 EST From: Richard J Brandau OK, I give up: How does one get rotated text in CLIM 1.0? So far I've been uniformly unsuccessful regardless of approach or platform (Genera 8.1, Allegro 4.0.1 on a Sun, or MCL 2.0). Either I'm really confused, or this is really tricky. Unfortunately you don't. CLIM 1.0 doesn't support it. BTW, it is also tricky to get rotated text to look reasonable when the rotation is not rectilinear. That is one reason CLIM 1.0 abdicates.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa13589; 13 Mar 92 17:55 EST Received: by KARIBA.BBN.COM id aa02776; 13 Mar 92 17:43 EST To: Richard J Brandau CC: clim@BBN.COM Subject: Re: Rotated Text? In-reply-to: Your message of Fri, 13 Mar 92 16:03:00 -0500. <19920313210339.7.RJB1@vega.gte.com> Date: Fri, 13 Mar 92 17:36:44 -0500 Message-ID: <1756.700526204@bbn.com> From: Jeff Morrill Date: Fri, 13 Mar 1992 16:03-0500 From: Richard J Brandau Subject: Rotated Text? To: clim@BBN.COM Cc: Rjb1%vega@gte.com OK, I give up: How does one get rotated text in CLIM 1.0? So far I've been uniformly unsuccessful regardless of approach or platform (Genera 8.1, Allegro 4.0.1 on a Sun, or MCL 2.0). Either I'm really confused, or this is really tricky. As far as I know, that's not currently supported. It could be done rather easily if there existed something like bitblt on the Symbolics, which rotates arbitrary bit arrays. It might not be the fastest thing in the world, but usually speed is not critical when you are drawing things sideways. Most of us would be happy with rotation in increments of 90 degrees, which is not real hard. I have already asked for something like bitblt. I think many CLIM users out there could use it. Perhaps this would be a good time to ask the CLIM implementors if this feature is in the works. jeff   Received: from BBN.COM by LABS-N.BBN.COM id aa19741; 14 Mar 92 9:45 EST Received: from corwin.ccs.northeastern.edu by BBN.COM id aa26426; 14 Mar 92 9:41 EST Received: by corwin.ccs.northeastern.edu (5.61+++/SMI-3.2+CCS-mx-2.9) id AA01843; Sat, 14 Mar 92 09:44:01 -0500 Date: Sat, 14 Mar 92 09:44:01 -0500 From: futrell@corwin.CCS.Northeastern.EDU (robert futrelle) Message-Id: <9203141444.AA01843@corwin.ccs.northeastern.edu> To: clim@bbn.com Subject: Satisfying rotated text needs Cc: futrelle The most common technical graphic in the world is the x,y data graph. Labeling the vertical axis of such a plot needs +90 degree rotated text. Implementing that (soon!) would satisfy 98% of the people asking about rotated text. 90 degree rotated text looks excellent with bit-mapped fonts of course. Oblique (non-90-degree rotated) text is used to a much lesser extent, as in labeling of edges of arc-node graphs, though some like to label them with horizontal text. As far as Postscript output goes, PS doesn't care, as far as I know, what transformation you apply. I vote for getting 90 degree text done real soon. It is just a bit-remap, interchanging x and y (and getting the signs right). Should not be a big deal. We deal with the biomedical literature and screen versions of it. They only publish about 1,000,000 distinct data plots a year. Maybe we could start saving some trees if we could move their stuff to our silver screens. bob futrelle Prof. Robert P. Futrelle Biological Knowledge Laboratory College of Computer Science 161CN Northeastern University 360 Huntington Ave. Boston, MA 02115 (617)-437-2076 FAX: (617)-437-5121 Internet: futrelle@corwin.ccs.northeastern.edu   Received: from BBN.COM by LABS-N.BBN.COM id ab09333; 16 Mar 92 11:11 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa04425; 16 Mar 92 11:07 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 425256; 16 Mar 1992 10:57:08-0500 Date: Mon, 16 Mar 1992 11:06-0500 From: Scott McKay Subject: Satisfying rotated text needs To: futrell@corwin.ccs.northeastern.edu, clim@BBN.COM cc: futrelle@corwin.ccs.northeastern.edu In-Reply-To: <9203141444.AA01843@corwin.ccs.northeastern.edu> Message-ID: <19920316160632.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Sat, 14 Mar 1992 09:44 EST From: robert futrelle The most common technical graphic in the world is the x,y data graph. Labeling the vertical axis of such a plot needs +90 degree rotated text. Implementing that (soon!) would satisfy 98% of the people asking about rotated text. 90 degree rotated text looks excellent with bit-mapped fonts of course. Oblique (non-90-degree rotated) text is used to a much lesser extent, as in labeling of edges of arc-node graphs, though some like to label them with horizontal text. As far as Postscript output goes, PS doesn't care, as far as I know, what transformation you apply. Most PostScript devices have resolutions that are much higher than screen resolution (400 dpi is not uncommon), so arbitrarily rotated text is still quite readable, if not good looking. I vote for getting 90 degree text done real soon. It is just a bit-remap, interchanging x and y (and getting the signs right). Should not be a big deal. Somebody should take up the challenge. If I sound like I am personally resisting the idea of implementing it, you're right. That's because I would like to encourage CLIM users to write and publish things like this. We deal with the biomedical literature and screen versions of it. They only publish about 1,000,000 distinct data plots a year. Maybe we could start saving some trees if we could move their stuff to our silver screens.   Received: from BBN.COM by LABS-N.BBN.COM id aa09314; 16 Mar 92 11:09 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa04209; 16 Mar 92 11:02 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 425255; 16 Mar 1992 10:51:51-0500 Date: Mon, 16 Mar 1992 11:01-0500 From: Scott McKay Subject: Re: Rotated Text? To: jmorrill@BBN.COM, rjb1%vega@gte.com cc: clim@BBN.COM In-Reply-To: <1756.700526204@bbn.com> Message-ID: <19920316160131.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 13 Mar 1992 17:36 EST From: Jeff Morrill Date: Fri, 13 Mar 1992 16:03-0500 From: Richard J Brandau Subject: Rotated Text? To: clim@BBN.COM Cc: Rjb1%vega@gte.com OK, I give up: How does one get rotated text in CLIM 1.0? So far I've been uniformly unsuccessful regardless of approach or platform (Genera 8.1, Allegro 4.0.1 on a Sun, or MCL 2.0). Either I'm really confused, or this is really tricky. As far as I know, that's not currently supported. It could be done rather easily if there existed something like bitblt on the Symbolics, which rotates arbitrary bit arrays. It might not be the fastest thing in the world, but usually speed is not critical when you are drawing things sideways. Most of us would be happy with rotation in increments of 90 degrees, which is not real hard. I have already asked for something like bitblt. I think many CLIM users out there could use it. Perhaps this would be a good time to ask the CLIM implementors if this feature is in the works. It's not in the works. Perhaps this would be a good time to ask some good CLIM hacker out there to cobble something up? I would be glad to privately supply code as a starting point for handling 90 degree rotations. As Naha pointed out in another message, there is also a kludge function called CLIM:DRAW-VERTICAL-STRING[*].   Received: from BBN.COM by LABS-N.BBN.COM id aa09333; 16 Mar 92 11:11 EST Received: from YUKON.SCRC.Symbolics.COM by BBN.COM id aa03948; 16 Mar 92 10:58 EST Received: from LILIKOI.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via INTERNET with SMTP id 782722; 16 Mar 1992 10:54:11-0500 Date: Mon, 16 Mar 1992 11:00-0500 From: Mark Nahabedian Subject: Satisfying rotated text needs To: futrell@corwin.ccs.northeastern.edu, clim@bbn.com In-Reply-To: <9203141444.AA01843@corwin.ccs.northeastern.edu> Message-ID: <19920316160016.6.NAHA@LILIKOI.SCRC.Symbolics.COM> Date: Sat, 14 Mar 1992 09:44 EST From: robert futrelle The most common technical graphic in the world is the x,y data graph. Labeling the vertical axis of such a plot needs +90 degree rotated text. Implementing that (soon!) would satisfy 98% of the people asking about rotated text. 90 degree rotated text looks excellent with bit-mapped fonts of course. CLIM:DRAW-VERTICAL-STRING will at least get you part way to having a reasonably labelled vertical axis. Oblique (non-90-degree rotated) text is used to a much lesser extent, as in labeling of edges of arc-node graphs, though some like to label them with horizontal text. As far as Postscript output goes, PS doesn't care, as far as I know, what transformation you apply. PostScript allows arbitrary rotation of text. I vote for getting 90 degree text done real soon. It is just a bit-remap, interchanging x and y (and getting the signs right). Should not be a big deal. It would have to be done in each back-end. CLIM proper doesn't get to think about bits. In some cases the back-end doesn't even have access to the bits of the image for the character, it just tells the host window system what characters (in what font) to plunk down where. If the host can't rotate then the back end would have to draw bits itself, with little clue about how to maintain stylistic coherence with the unrotated text that was drawn. If the problem were easy it would have been solved by now. We deal with the biomedical literature and screen versions of it. They only publish about 1,000,000 distinct data plots a year. Maybe we could start saving some trees if we could move their stuff to our silver screens. bob futrelle Prof. Robert P. Futrelle Biological Knowledge Laboratory College of Computer Science 161CN Northeastern University 360 Huntington Ave. Boston, MA 02115 (617)-437-2076 FAX: (617)-437-5121 Internet: futrelle@corwin.ccs.northeastern.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa10585; 16 Mar 92 12:33 EST Received: from Sunset.AI.SRI.COM by BBN.COM id aa08087; 16 Mar 92 12:26 EST Received: from Rockaway.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA10172 for clim@BBN.COM; Mon, 16 Mar 92 09:26:37 PST Received: by Rockaway.AI.SRI.COM (4.1/SMI-4.1) id AA16419 for futrelle@corwin.ccs.northeastern.edu; Mon, 16 Mar 92 09:26:36 PST Date: Mon, 16 Mar 92 9:26:35 PST From: Peter Karp To: robert futrelle Cc: clim@BBN.COM, futrelle@corwin.ccs.northeastern.edu Subject: Re: Satisfying rotated text needs In-Reply-To: Your message of Sat, 14 Mar 92 09:44:01 -0500 Message-Id: I would say that the second-most common reason for wanting 90 degree rotation of text is for printing hardcopy output in landscape mode. Perhaps implementing that soon would satisfy 1.9999% of the people who didn't want rotated text for labeling x,y data graphs. Peter   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa12117; 16 Mar 92 14:10 EST Received: by KARIBA.BBN.COM id aa09924; 16 Mar 92 13:58 EST To: Mark Nahabedian CC: clim@BBN.COM Subject: Re: Satisfying rotated text needs In-reply-to: Your message of Mon, 16 Mar 92 11:00:00 -0500. <19920316160016.6.NAHA@LILIKOI.SCRC.Symbolics.COM> Date: Mon, 16 Mar 92 13:54:34 -0500 Message-ID: <1834.700772074@bbn.com> From: Jeff Morrill Date: Mon, 16 Mar 1992 11:00-0500 From: Mark Nahabedian Subject: Satisfying rotated text needs To: futrell@corwin.ccs.northeastern.edu, clim@BBN.COM CLIM:DRAW-VERTICAL-STRING will at least get you part way to having a reasonably labelled vertical axis. Well, that was a big disappointment. I drew a graph whose y-axis was "PSI" and I got: I S P It rotated the baseline +90 degrees rather than -90 degrees. And more importantly, the characters were not rotated. jeff morrill jmorrill@bbn.com   Received: from BBN.COM by LABS-N.BBN.COM id aa12085; 16 Mar 92 14:09 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa12480; 16 Mar 92 14:05 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 425280; 16 Mar 1992 13:55:23-0500 Date: Mon, 16 Mar 1992 14:04-0500 From: Scott McKay Subject: Re: Satisfying rotated text needs To: pkarp@ai.sri.com, futrell@corwin.ccs.northeastern.edu cc: clim@BBN.COM, futrelle@corwin.ccs.northeastern.edu In-Reply-To: Message-ID: <19920316190445.7.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 16 Mar 1992 12:26 EST From: Peter Karp I would say that the second-most common reason for wanting 90 degree rotation of text is for printing hardcopy output in landscape mode. Perhaps implementing that soon would satisfy 1.9999% of the people who didn't want rotated text for labeling x,y data graphs. WITH-OUTPUT-TO-POSTSCRIPT-STREAM takes a :ORIENTATION keyword in CLIM 1.1. But note that you are referring to rotation of *text graphics* (DRAW-TEXT), which is not the same thing as stream text output (WRITE-STRING). If you want landscape output for pure textual output, that is the function of your text formatter or print spooler.   Received: from BBN.COM by LABS-N.BBN.COM id aa13875; 16 Mar 92 16:35 EST Received: from ihb.compuserve.com by BBN.COM id aa21118; 16 Mar 92 16:29 EST Received: by ihb.compuserve.com (5.65/5.910516) id AA24587; Mon, 16 Mar 92 16:27:29 -0500 Date: 16 Mar 92 15:47:56 EST From: Bob Shore <71640.1010@CompuServe.COM> To: Subject: Drop me Message-Id: <920316204755_71640.1010_CHE50-2@CompuServe.COM> Please remove this address from the CLIM mailing list.   Received: from BBN.COM by LABS-N.BBN.COM id aa25233; 17 Mar 92 12:56 EST Received: from watson.ibm.com by BBN.COM id aa18831; 17 Mar 92 12:45 EST Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 8654; Tue, 17 Mar 92 12:45:41 EST Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0" id 7959; Tue, 17 Mar 1992 12:45:40 EST Received: from fiasco.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2) with TCP; Tue, 17 Mar 92 12:45:39 EST Received: by fiasco.watson.ibm.com (AIX 3.1/UCB 5.61/920123) id AA31314; Tue, 17 Mar 92 12:45:41 -0500 Message-Id: <9203171745.AA31314@fiasco.watson.ibm.com> To: clim@BBN.COM X-External-Networks: yes Reply-To: meir@watson.ibm.com Subject: reverse video in pop-up accepting values window Date: Tue, 17 Mar 92 12:45:40 -0500 From: "Meir Laker" The default pop-up accepting-values window (i.e., :own-window t) appears black on white on a monchrome screen. I have been unable to reverse the appearance. **************************************** Attempt #1 (on the Symbolics): (defmethod clim:run-frame-top-level :before ((frame accept-values)) (with-slots (own-window) frame (setf (clim:medium-foreground own-window) clim::+white (clim:mdeium-background own-window) clim::+black+))) and get an Output Hold that locks the display. If I precede the setf with (window-expose own-window), I am thrown in the debugger attempting to expose a TEMP-CLIM-SHEET outside of its superior. **************************************** Attempt #2 (on the Symbolics): (define-application-frame my-accept-values () () (:panes ((only-pane :application :stream-foreground clim::+white+ :stream-background clim::+black+)))) and calling it via: (accepting-values :frame-class 'my-accept-values) with no luck. The :stream-foreground/background pane options seem to be ignored. **************************************** Thank you for any help you can give me. Meir Laker IBM Thomas J. Watson Research Center P.O. Box 218, Yorktown Heights, NY 10598 Phone: 914-945-2699 Tieline: 862-2699 meir@watson.ibm.com   Received: from BBN.COM by LABS-N.BBN.COM id aa26200; 17 Mar 92 14:06 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa21701; 17 Mar 92 14:02 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 425398; 17 Mar 1992 13:52:54-0500 Date: Tue, 17 Mar 1992 14:02-0500 From: Scott McKay Subject: reverse video in pop-up accepting values window To: meir@watson.ibm.com, clim@BBN.COM In-Reply-To: <9203171745.AA31314@fiasco.watson.ibm.com> Message-ID: <19920317190236.6.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 17 Mar 1992 12:45 EST From: Meir Laker The default pop-up accepting-values window (i.e., :own-window t) appears black on white on a monchrome screen. I have been unable to reverse the appearance. I think that CLIM 1.1 fixes a bug in which changing the foreground and background of a frame propagate the changes to the inferior panes. By the way, in CLIM 1.1 on Genera, Function C will correctly "reverse the video" of a CLIM window. **************************************** Attempt #1 (on the Symbolics): (defmethod clim:run-frame-top-level :before ((frame accept-values)) (with-slots (own-window) frame (setf (clim:medium-foreground own-window) clim::+white+ (clim:mdeium-background own-window) clim::+black+))) and get an Output Hold that locks the display. If I precede the setf with (window-expose own-window), I am thrown in the debugger attempting to expose a TEMP-CLIM-SHEET outside of its superior. **************************************** Attempt #2 (on the Symbolics): (define-application-frame my-accept-values () () (:panes ((only-pane :application :stream-foreground clim::+white+ :stream-background clim::+black+)))) and calling it via: (accepting-values :frame-class 'my-accept-values) with no luck. The :stream-foreground/background pane options seem to be ignored. **************************************** Thank you for any help you can give me. Meir Laker IBM Thomas J. Watson Research Center P.O. Box 218, Yorktown Heights, NY 10598 Phone: 914-945-2699 Tieline: 862-2699 meir@watson.ibm.com   Received: from BBN.COM by LABS-N.BBN.COM id aa23657; 19 Mar 92 13:57 EST Received: from brazil.cambridge.apple.com by BBN.COM id aa00637; 19 Mar 92 13:48 EST Received: from ministry.cambridge.apple.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef) id AA20895; Thu, 19 Mar 92 13:51:16 -0500 for clim@BBN.COM Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef) id AA02769; Thu, 19 Mar 92 13:45:55 -0500 Message-Id: <9203191845.AA02769@cambridge.apple.com> Date: Thu, 19 Mar 92 13:50:02 EST From: moon@cambridge.apple.com (David A. Moon) To: scosysv!keunen@nrb.be Subject: Re: Clim commands - interleaving args and commands words Cc: clim@BBN.COM Isn't there a command presentation type? Try making the second argument to ask be of that type. Maybe it will work.   Received: from BBN.COM by LABS-N.bbn.COM id aa22950; 19 Mar 92 13:05 EST Received: from mcsun.EU.net by BBN.COM id aa28212; 19 Mar 92 12:52 EST Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA15747 (5.65a/CWI-2.153); Thu, 19 Mar 1992 18:51:48 +0100 Received: by ub4b.buug.be (5.64+/ub4b_02) id AA29532; Thu, 19 Mar 92 18:48:34 +0100 Received: from scosysv by nrb.be (DECUS UUCP ///1.3-1/2.5/); Thu, 19 Mar 92 18:39:37 +0100 Received: from milou.nrb.be by scosysv.nrb.be with SMTP (5.59/25-e-eef-ev@nrb) id AA22462; Thu, 19 Mar 92 15:36:56 CET Date: Thu, 19 Mar 1992 15:39+0100 From: Vincent Keunen Reply-To: scosysv!keunen@nrb.be Subject: Clim commands - interleaving args and commands words To: clim@bbn.com Message-Id: <19920319143942.4.KEUNEN@milou.nrb.be> Is there a way, in CLIM, to interleave command arguments and command words?... Here is what I want to do: Ask Show Decnet Route Where is the name of a host. Ideally, what is allowed to appear after should be dependent of the type of . For example, the preceding command is allowed because is of type "cisco-router", but "Ask Show Decnet Route" should not be allowed if is of type "vax-router". CLIM should not let the user type "show decnet route" after parsing a of type "vax-router". However, when the is of type "vax-router", other commands should be allowed. I want to be able to use: Ask Show Adjacent Nodes but not: Ask Show Adjacent Nodes for the same (type) reasons. Of course, "Ask" should only allow "vax-router" and "cisco-router" objects as arguments. Some command words are allowed for both types; it is ok to accept: Ask Show Directory and Ask Show Directory Moreover, some commands look like this: Ask Show Adjacent Nodes where is another argument to the command... I haven't found sufficient information in the manual. Is there a (easy) way to do this, or do I have to play with the command-parser myself? note: there are other examples (other than "ask") where this functionnality would be nice for my application. Thanks for any help, Vincent Keunen keunen@nrb.be   Received: from BBN.COM by LABS-N.BBN.COM id aa24891; 19 Mar 92 15:22 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa06346; 19 Mar 92 15:18 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 425693; 19 Mar 1992 15:08:27-0500 Date: Thu, 19 Mar 1992 15:18-0500 From: Scott McKay Subject: Clim commands - interleaving args and commands words To: scosysv!keunen@nrb.be, clim@BBN.COM In-Reply-To: <19920319143942.4.KEUNEN@milou.nrb.be> Message-ID: <19920319201810.5.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 19 Mar 1992 09:39 EST From: Vincent Keunen Is there a way, in CLIM, to interleave command arguments and command words?... The presentation type COMMAND is documented on page 280 of the CLIM documentation. You will need to distribute your command set across different command tables in order to get the specificity you need. I find it interesting that you did not discover this from the documentation. Can you figure out why the documentation was not helpful here? That might help us to improve it.   Received: from BBN.COM by LABS-N.BBN.COM id aa25329; 19 Mar 92 16:00 EST Received: from ALDERAAN.SCRC.Symbolics.COM by BBN.COM id aa08305; 19 Mar 92 15:56 EST Received: from JUBJUB.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via INTERNET with SMTP id 499802; 19 Mar 1992 15:00:51-0500 Date: Thu, 19 Mar 1992 15:00-0500 From: John G. Aspinall Subject: Re: Clim commands - interleaving args and commands words To: moon@cambridge.apple.com, scosysv!keunen@nrb.be cc: clim@BBN.COM In-Reply-To: <9203191845.AA02769@cambridge.apple.com> Message-ID: <19920319200055.0.JGA@JUBJUB.SCRC.Symbolics.COM> Date: Thu, 19 Mar 1992 13:50 EST From: "David A. Moon" Isn't there a command presentation type? Try making the second argument to ask be of that type. Maybe it will work. I haven't tried it yet, but that's exactly what I'd try, too. Probably you want to make subtypes of command, i.e. askable-command, askable-on-unix-host-command, ....   Received: from KARIBA.BBN.COM by LABS-N.bbn.COM id aa01101; 23 Mar 92 13:22 EST Received: by KARIBA.BBN.COM id ab25074; 23 Mar 92 12:35 EST To: clim@BBN.COM CC: jmorrill@BBN.COM, ncramer@BBN.COM, mthome@BBN.COM Subject: Re: Rotated Text? Date: Mon, 23 Mar 92 12:35:07 -0500 Message-ID: <2811.701372107@bbn.com> From: Jeff Morrill Date: Mon, 16 Mar 1992 11:01-0500 From: Scott McKay Subject: Re: Rotated Text? To: jmorrill@BBN.COM, rjb1%vega@gte.com cc: clim@BBN.COM Date: Fri, 13 Mar 1992 17:36 EST From: Jeff Morrill Date: Fri, 13 Mar 1992 16:03-0500 From: Richard J Brandau Subject: Rotated Text? To: clim@BBN.COM Cc: Rjb1%vega@gte.com OK, I give up: How does one get rotated text in CLIM 1.0? As far as I know, that's not currently supported. It could be done rather easily if there existed something like bitblt on the Symbolics, which rotates arbitrary bit arrays. It might not be the fastest thing in the world, but usually speed is not critical when you are drawing things sideways. Most of us would be happy with rotation in increments of 90 degrees, which is not real hard. I have already asked for something like bitblt. I think many CLIM users out there could use it. Perhaps this would be a good time to ask the CLIM implementors if this feature is in the works. It's not in the works. Perhaps this would be a good time to ask some good CLIM hacker out there to cobble something up? I would be glad to privately supply code as a starting point for handling 90 degree rotations. ----------------------- Folks, Here is some code that does exactly what I described. We have had to spend a few days pulling the pieces together and cleaning it all up. All of us clim hackers think that this functionality would be an excellent candidate for inclusion in CLIM 2.0. It requires access to a number of clim internal protocols, and it will be difficult for us to update and maintain as new clim releases appear. Send suggestions, bug fixes, and extensions to me (unless the clim implementors want the job). Enjoy! jeff morrill jmorrill@bbn.com ----------------------- ;;; -*- Syntax: Common-lisp; Mode: LISP; Package: clim; -*- (in-package :clim) #| --------------------------------------------- Written by: ncramer@bbn.com, jmorrill@bbn.com, mthome@bbn.com Bolt, Beranek, and Newman Written for: CLIM 1.0 (as an extension) Version: 0.0 (23 March, 1992) This code has been placed in the public domain by the authors. We encourage those fixing or extending this code to send a copy to the authors for inclusion in a future version. --------------------------------------------- ALLOCATE-PIXMAP width height &key (clear-p t) FREE-PIXMAP pixmap WITH-PIXMAP symbol width height &key (clear-p t) Allocates and frees a pixmap stream. This type of stream supports all graphics operations but is never displayed. The purpose of a pixmap is typically to perform offscreen drawing operations and then to use STREAM-BITBLT* to copy it (or a portion of it) onto a displayed stream. It may also be useful to copy from a displayed stream to a pixmap stream. STREAM-BITBLT stream point-1 from-stream from-x from-y width height &key STREAM-BITBLT* stream x y from-stream from-x from-y width height &key Copies a rectangular portion of from-stream onto a rectangular portion of to-stream. DRAW-STRING-IMAGE stream string point-1 &key angle DRAW-STRING-IMAGE* stream string x y &key angle Draws a rotated character string. The current implementation only supports angles in increments of pi/2. Positive angle = counterclockwise rotation. |# (defclass basic-pixmap () ()) (defmethod pixmap-clear ((pixmap basic-pixmap)) (window-clear pixmap) ;; For some reason doing a simple WINDOW-CLEAR doesn't seem to work by itself... (multiple-value-bind (LEFT TOP RIGHT BOTTOM) (rectangle-edges* (window-viewport pixmap)) (multiple-value-bind (xoff yoff) (window-margins pixmap) (with-output-recording-options (pixmap :record-p nil :draw-p t) (draw-rectangle* pixmap left top (- right xoff) (- bottom yoff) :ink +background+ :filled t))))) (defmethod pixmap-set-inside-size ((PIXMAP basic-pixmap) NEW-WIDTH NEW-HEIGHT) ;; Avoid unnecessary work, since this is done frequently. (multiple-value-bind (LEFT TOP RIGHT BOTTOM) (window-inside-edges PIXMAP) (unless (and (= (- RIGHT LEFT) NEW-WIDTH) (= (- BOTTOM TOP) NEW-HEIGHT)) (window-set-inside-edges PIXMAP LEFT TOP (+ LEFT NEW-WIDTH) (+ TOP NEW-HEIGHT))))) ;;;******************************************************************************** ;;; CLX specific classes and methods. ;;;**********************************************************************NLC02DEC91 #+(and :xlib (not :genera)) (progn (defclass clx-pixmap (clx-window basic-pixmap) ()) (defmethod initialize-instance :after ((SELF clx-pixmap) &key &allow-other-keys) ;; Turn on backing store, so the unexposed window remembers ;; what gets drawn to it. (setf (xlib:window-backing-store (slot-value SELF 'window)) :always)) ;;; Lie about these things, so the that we can draw to un-exposed windows. (defmethod window-drawing-possible ((SELF clx-pixmap)) t) (defmethod window-visibility ((SELF clx-pixmap)) t) ;;; The path seems to change (from platform to platform, release to release, ;;; sub-release to sub-release, phase o' the moon, etc...) so this may need ;;; massaging. (defvar *CLX-PIXMAP-ROOT* nil) (defun get-clx-pixmap-root () (or *CLX-PIXMAP-ROOT* (setq *CLX-PIXMAP-ROOT* (apply #'open-root-window #+lucid `(:clx :host ,(lcl:environment-variable "DISPLAY")) #-lucid `(:clx))))) (defmethod stream-bitblt-support ((FROM-STREAM clx-window) FROM-LEFT FROM-TOP (TO-STREAM clx-window) TO-LEFT TO-TOP WIDTH HEIGHT &key FUNCTION) ;; NOTE: This being rather primitive, does not concern itself with Margins, etc. ;; If it does, then it gets confused when inside a presentation (which also ;; worries about such things). (with-slots (COPY-GC) TO-stream ;; PROBABLY WANT TO CACHE COPIES OF THE GCONTEXTS (xlib:with-gcontext (COPY-GC :function (or FUNCTION boole-1)) (xlib:copy-area (slot-value FROM-STREAM 'window) COPY-GC FROM-LEFT FROM-TOP WIDTH HEIGHT (slot-value TO-STREAM 'window) TO-LEFT TO-TOP)) )) (defmethod stream-bitblt-internal ((TO-STREAM clx-window) X-OFFSET Y-OFFSET X Y (FROM-STREAM clx-window) FROM-X FROM-Y WIDTH HEIGHT INK FORCE-FROM-OUTPUT?) (stream-bitblt-internal-helper TO-STREAM X-OFFSET Y-OFFSET X Y FROM-STREAM FROM-X FROM-Y WIDTH HEIGHT INK FORCE-FROM-OUTPUT?)) (defmethod draw-string-image-internal ((stream clx-window) x-offset y-offset string x y ANGLE text-style) (draw-string-image-internal-helper stream x-offset y-offset string x y ANGLE text-style)) (defun make-clx-pixmap (&key (RIGHT 100) (BOTTOM 100) (LEFT 0) (TOP 0)) (let* ((PIXMAP-ROOT (get-clx-pixmap-root)) (PIXMAP (make-instance 'clx-pixmap :parent PIXMAP-ROOT :left LEFT :top TOP :right RIGHT :bottom BOTTOM :scroll-bars nil :borders nil ))) PIXMAP)) ) ; end of progn for (and :xlib (not :genera)) ;;;******************************************************************************** ;;; Genera specific classes and methods. ;;;**********************************************************************NLC08NOV91 #+genera (progn (scl:defflavor genera-pixmap-window () (tv:dont-select-with-mouse-mixin tv:window) (:default-init-plist :deexposed-typeout-action :permit :borders nil :save-bits t :blinker-p nil :label nil)) ;;; Make sure that it can't be exposed/selected/etc. (scl:defwhopper (:expose genera-pixmap-window) (&rest IGNORE)) (scl:defwhopper (:deexpose genera-pixmap-window) (&rest IGNORE)) (scl:defwhopper (:selected genera-pixmap-window) (&rest IGNORE)) ;;; (scl:defflavor b&w-genera-pixmap-window () (genera-pixmap-window)) (defun make-b&w-genera-pixmap-window () (tv:make-window 'b&w-genera-pixmap-window :borders nil)) (defclass genera-pixmap (sheet-window-stream basic-pixmap) ()) ;;; For now (maybe forever) INK/ALU is ignored; i.e. this just draws it in. ;;; I'm assuming that's not too awful. After all that's what COPY-AREA-INTERNAL ;;; does. In any case, it's the only way I can get it to work. (defmethod stream-bitblt-support ((FROM-STREAM sheet-window-stream) FROM-X FROM-Y (TO-STREAM sheet-window-stream) X Y WIDTH HEIGHT &key FUNCTION) (let ((ALU (or FUNCTION boole-1))) (scl::send (slot-value TO-STREAM 'WINDOW) :bitblt-from-sheet-to-sheet ALU WIDTH HEIGHT (slot-value FROM-STREAM 'WINDOW) FROM-X FROM-Y X Y))) (defmethod stream-bitblt-support :around (FROM-STREAM FROM-X FROM-Y (TO-STREAM genera-pixmap) TO-X TO-Y WIDTH HEIGHT &key FUNCTION) (with-output-recording-options (TO-STREAM :record-p nil :draw-p t) (call-next-method FROM-STREAM FROM-X FROM-Y TO-STREAM TO-X TO-Y WIDTH HEIGHT :function FUNCTION))) (defmethod stream-bitblt-internal ((TO-STREAM sheet-implementation-mixin) X-OFFSET Y-OFFSET X Y (FROM-STREAM sheet-implementation-mixin) FROM-X FROM-Y WIDTH HEIGHT INK FORCE-FROM-OUTPUT?) (stream-bitblt-internal-helper TO-STREAM X-OFFSET Y-OFFSET X Y FROM-STREAM FROM-X FROM-Y WIDTH HEIGHT INK FORCE-FROM-OUTPUT?)) (defmethod draw-string-image-internal ((stream sheet-implementation-mixin) x-offset y-offset string x y ANGLE text-style) (draw-string-image-internal-helper stream x-offset y-offset string x y ANGLE text-style)) (defun make-genera-pixmap (&key (WIDTH 100) (HEIGHT 100) (screen tv:main-screen)) ;; LIFTED FROM create-sheet-root-window (let ((PIXMAP (make-instance 'genera-pixmap :window (make-b&w-genera-pixmap-window) :display-device-type (let (#+IMach (device (scl:send screen :display-device-type))) (cond #+IMach ((and (find-package 'mtb) (typep device (intern "SMALL-SCREEN-GENERA-FONTS-MAC-DISPLAY-DEVICE" 'mtb))) *small-sheet-device*) (t *sheet-device*)))))) (pixmap-set-inside-size PIXMAP width height) PIXMAP)) ) ; end of progn for genera ;;;******************************************************************************** ;;; PIXMAPS and BITBLT ;;;**********************************************************************NLC13NOV91 (defun make-pixmap (&key (width 100) (height 100)) #+Genera (make-genera-pixmap :width width :height height) #+(and :xlib (not :genera)) (make-clx-pixmap :right width :bottom height)) (defvar *FREE-PIXMAPS-LIST* nil "Simple Resource for recyclable PIXMAPS.") (defun free-pixmap (PIXMAP) (pushnew PIXMAP *FREE-PIXMAPS-LIST*) nil) (defun allocate-pixmap (width height &optional (clear-p t)) (let ((pm (pop *FREE-PIXMAPS-LIST*))) (cond (pm (pixmap-set-inside-size pm width height) (if clear-p (pixmap-clear pm)) pm) (t (make-pixmap :width width :height height))))) (defmacro with-pixmap ((symbol WIDTH HEIGHT &key (CLEAR-P t)) &body BODY) `(let ((,symbol (allocate-pixmap ,WIDTH ,HEIGHT ,CLEAR-P))) (unwind-protect (progn ,@BODY) (free-pixmap ,symbol)))) (defun stream-bitblt-internal-helper (TO-STREAM X-OFFSET Y-OFFSET X Y FROM-STREAM FROM-X FROM-Y WIDTH HEIGHT INK FORCE-FROM-OUTPUT?) (declare (ignore INK)) (when (window-drawing-possible TO-STREAM) (setq X (round x) Y (round y)) (translate-positions x-offset y-offset X Y) (stream-bitblt-support FROM-STREAM FROM-X FROM-Y TO-STREAM X Y WIDTH HEIGHT) (and FORCE-FROM-OUTPUT? (force-output FROM-STREAM)))) ;;; NOTE: On CLX-based windows, the result of BITBLT-ing may not be displayed until ;;; a force-output is done on the FROM-STREAM (yes, that's what I said, the FROM-stream). ;;; However, force-output can be a very time consuming operation. Therefore, it ;;; only happens automatically (at most) in the call to STREAM-BITBLT ;;; itself. Lower level calls are responsible for doing it themselves. (define-graphics-operation stream-bitblt (TO-X TO-Y FROM-STREAM FROM-X FROM-Y WIDTH HEIGHT &key (FORCE-FROM-OUTPUT? t)) :arguments ((point TO-X TO-Y)) :drawing-options (:ink) :method-body (with-transformed-arguments (stream-bitblt-internal STREAM 0 0 TO-X TO-Y FROM-STREAM FROM-X FROM-Y WIDTH HEIGHT (medium-ink STREAM) FORCE-FROM-OUTPUT?))) (define-graphics-internal stream-bitblt-internal (TO-X TO-Y FROM-STREAM FROM-X FROM-Y WIDTH HEIGHT INK FORCE-FROM-OUTPUT?) :points-to-convert (TO-X TO-Y) :bounding-rectangle (let (vx vt vr vb) (setq vx TO-X vr (the fixnum (+ TO-X WIDTH))) (setq vt TO-Y vb (the fixnum (+ TO-Y HEIGHT))) (fix-rectangle vx vt vr vb))) ;;;******************************************************************************** ;;; DRAW-STRING-WITH-ROTATION (STREAM STRING X Y &key :ANGLE :TEXT-STYLE) ;;; Support for string rotation by first drawing the string onto a Pixmap and ;;; then rotating it (through increments of 90dgs). ;;;**********************************************************************NLC20MAR92 ;(defconstant *stor* boole-1) ; tv::alu-seta ;(defconstant *or* boole-ior) ;(defconstant *and* boole-and) ;(defconstant *xor* boole-xor) ;(defconstant *clr* boole-clr) ;(defconstant *set* boole-set) ;(defconstant *notand* boole-andc1) ;(defconstant *rotate-array-size* 256) (defun pixmap-rotate-90-worker (SOURCE-PIXMAP ARRAY-SIZE) ;; Original code was in smalltalk from april 1981 Byte magazine. ;; This code is mostly from a symbolics lispm hack: ;; Created 11/24/81 by CMB ;; Modified, 1/9/82 by DLW ;; Converted to CLIM, 19MAR92 by NLC. ;; The bit array must be square and a power of two bits on a side. (macrolet ((copy-all-to (from xoffset yoffset to alu) `(stream-bitblt-support ,from 0 0 ,to ,xoffset ,yoffset (- array-size ,xoffset) (- array-size ,yoffset) :function ,alu)) (copy-all-from (to xoffset yoffset from alu) `(stream-bitblt-support ,from ,xoffset ,yoffset ,to 0 0 (- array-size ,xoffset) (- array-size ,yoffset) :function ,alu))) (with-pixmap (MASK-PIXMAP array-size array-size) (with-output-recording-options (MASK-PIXMAP :record-p nil :draw-p t) (with-pixmap (TEMP-PIXMAP array-size array-size) (with-output-recording-options (TEMP-PIXMAP :record-p nil :draw-p t) (copy-all-to MASK-PIXMAP 0 0 MASK-PIXMAP boole-clr) (copy-all-from MASK-PIXMAP (/ array-size 2) (/ array-size 2) MASK-PIXMAP boole-set) (do ((quad (/ array-size 2) (/ quad 2))) ((< quad 1)) (copy-all-to MASK-PIXMAP 0 0 TEMP-PIXMAP boole-1); 1 (copy-all-to MASK-PIXMAP 0 quad TEMP-PIXMAP boole-ior); 2 (copy-all-to SOURCE-PIXMAP 0 0 TEMP-PIXMAP boole-and); 3 (copy-all-to TEMP-PIXMAP 0 0 SOURCE-PIXMAP boole-xor); 4 (copy-all-from TEMP-PIXMAP quad 0 SOURCE-PIXMAP boole-xor); 5 (copy-all-from SOURCE-PIXMAP quad 0 SOURCE-PIXMAP boole-ior); 6 (copy-all-to TEMP-PIXMAP quad 0 SOURCE-PIXMAP boole-xor); 7 (copy-all-to SOURCE-PIXMAP 0 0 TEMP-PIXMAP boole-1); 8 (copy-all-from TEMP-PIXMAP quad quad SOURCE-PIXMAP boole-xor); 9 (copy-all-to MASK-PIXMAP 0 0 TEMP-PIXMAP boole-and); 10 (copy-all-to TEMP-PIXMAP 0 0 SOURCE-PIXMAP boole-xor); 11 (copy-all-to TEMP-PIXMAP quad quad SOURCE-PIXMAP boole-xor); 12 (copy-all-from MASK-PIXMAP (floor quad 2) (floor quad 2) MASK-PIXMAP boole-and) ;13 (copy-all-to MASK-PIXMAP quad 0 MASK-PIXMAP boole-ior); 14 (copy-all-to MASK-PIXMAP 0 quad MASK-PIXMAP boole-ior); 15 ))) )))) (defun pixmap-rotate-90 (SOURCE-PIXMAP &key DEST-PIXMAP SOURCE-X SOURCE-Y WIDTH HEIGHT DEST-X DEST-Y) (or DEST-PIXMAP (setq DEST-PIXMAP source-pixmap)) (unless SOURCE-X (setq SOURCE-X 0)) (unless SOURCE-Y (setq SOURCE-Y 0)) (unless dest-x (setq dest-x 0)) (unless dest-y (setq dest-y 0)) (with-output-recording-options (source-pixmap :record-p nil :draw-p t) (with-output-recording-options (dest-pixmap :record-p nil :draw-p t) (unless (and width height) (multiple-value-bind (w h) (multiple-value-bind (left top right bottom) (rectangle-edges* (window-viewport source-pixmap)) (multiple-value-bind (xoff yoff) (window-margins source-pixmap) (values (- (- right xoff) left) (- (- bottom yoff) top)))) (unless width (setq width w)) (unless height (setq height h)))) (let ((csz (expt 2 (ceiling (log (max width height) 2))))) (with-pixmap (HOLD-PIXMAP CSZ CSZ) (with-output-recording-options (HOLD-PIXMAP :record-p nil :draw-p t) (stream-bitblt-support source-pixmap SOURCE-X SOURCE-Y HOLD-PIXMAP 0 0 WIDTH HEIGHT) (pixmap-rotate-90-worker HOLD-PIXMAP csz) (stream-bitblt-support HOLD-PIXMAP (- CSZ HEIGHT) 0 dest-pixmap DEST-X DEST-Y HEIGHT WIDTH)))))) dest-pixmap) (defun stream-bitblt-with-rotation (stream x y from-stream from-x from-y width height &key (angle 0)) (if (zerop angle) (stream-bitblt-support from-stream from-x from-y stream x y width height) (let ((rotation-count (mod (round (- ANGLE) #.(/ PI 2.0)) 4)) (size (max WIDTH HEIGHT)) (x0 0) (y0 0)) (with-pixmap (PM size size) (with-output-recording-options (PM :record-p nil :draw-p t) (stream-bitblt-support from-stream from-x from-y PM 0 0 width height) (dotimes (i rotation-count) (pixmap-rotate-90 PM :width size :height size)) (cond ((= rotation-count 1) (decf x0 (- size width)) (decf x width) (setq width (- size x0)) (setq height (- size y0)) ) ((= rotation-count 2) (incf y0 (- size height)) (decf x width) (decf y height) ) ((= rotation-count 3) (decf y width) (rotatef width height) )) (stream-bitblt-support PM x0 y0 STREAM x y width height ) (force-output pm) ; needed for CLX, but why???? ))))) (defun draw-string-with-rotation (STREAM STRING X Y &key (angle 0) TEXT-STYLE) (if (zerop angle) (with-output-recording-options (STREAM :record-p nil :draw-p t) (draw-string-internal STREAM 0 0 STRING X Y 0 (length string) :left :top TEXT-STYLE (medium-ink stream))) (let ((width (stream-string-width stream string :text-style text-style)) (height (stream-line-height stream text-style))) (with-pixmap (PM width height :clear-p nil) (setf (medium-foreground PM) (medium-foreground STREAM) (medium-background PM) (medium-background STREAM)) (pixmap-clear PM) (draw-string* PM STRING 0 0 :align-x :left :align-y :top :text-style TEXT-STYLE) (stream-bitblt-with-rotation stream x y PM 0 0 width height :angle angle))))) ;;;******************************************************************************** ;;; DRAW-STRING-IMAGE ;;;**********************************************************************NLC22MAR92 (defun draw-string-image-internal-helper (stream x-offset y-offset string x y ANGLE text-style) (when (window-drawing-possible stream) (setq X (round x) Y (round y)) (translate-positions x-offset y-offset X Y) (draw-string-with-rotation stream string x y :angle angle :text-style TEXT-STYLE))) (define-graphics-operation draw-string-image (string x y &key (ANGLE 0.0)) :arguments ((point x y)) :drawing-options :text :method-body (with-transformed-arguments (draw-string-image-internal stream 0 0 string x y ANGLE (stream-merged-text-style stream) #+Ignore (medium-ink stream)))) (defun rot-90-string-locations (STREAM STRING X Y ANGLE TEXT-STYLE) (declare (values IMAGE-LEFT IMAGE-TOP IMAGE-WIDTH IMAGE-HEIGHT REAL-WIDTH REAL-HEIGHT)) (let ((N-ROT-90 (mod (round (- ANGLE) #.(/ PI 2.0)) 4)) (STR-WID (stream-string-width stream string :text-style text-style)) (STR-HEI (stream-line-height stream text-style))) (case N-ROT-90 (3 (values X (- Y STR-WID) STR-HEI STR-WID STR-WID STR-HEI)) (2 (values (- X STR-WID) (- Y STR-HEI) STR-WID STR-HEI STR-WID STR-HEI)) (1 (values (- X STR-HEI) Y STR-HEI STR-WID STR-WID STR-HEI)) (otherwise (values X Y STR-WID STR-HEI STR-WID STR-HEI))))) (define-graphics-internal draw-string-image-internal (STRING X Y ANGLE TEXT-STYLE) :points-to-convert (x y) ;; Don't want temporary strings to make it into the history :output-recording-hook (setq string (evacuate-temporary-string string)) :bounding-rectangle (progn (multiple-value-bind (LLL TTT WWW HHH) (rot-90-string-locations stream string x y angle TEXT-STYLE) (declare (fixnum WWW HHH)) (let ((vx LLL) (vt TTT) (vr (the fixnum (+ LLL WWW))) (vb (the fixnum (+ TTT HHH)))) #+ig (fix-rectangle vx vt vr vb);; allegro gets an error with this (values vx vt vr vb) ))))   Received: from BBN.COM by LABS-N.bbn.COM id aa11281; 24 Mar 92 8:43 EST Received: from RA.RL.AF.MIL by BBN.COM id aa04020; 24 Mar 92 8:37 EST Received: from BEN.RL.AF.MIL by RA.RL.AF.MIL (5.65b/1.34) id AA11203; Tue, 24 Mar 92 08:37:11 -0500 Date: Tue, 24 Mar 1992 08:33-0500 From: James Lawton Subject: Variable value menus To: clim@bbn.com Message-Id: <19920324133322.3.LAWTON@BEN.rl.af.mil> Is there a CLIM equivalent of the Symbolics function "tv:choose-variable-values"? Or is this something that would have to be done with a lot of "accept" calls? James Lawton Rome Laboratory Griffiss AFB, NY 13441-5700 (315)330-2973 email: lawton@aivax.rl.af.mil Disclaimer: The opinions and views expressed here are MINE! They may not reflect those of the Rome Laboratory, the US Air Force, or most anyone else.   Received: from BBN.COM by LABS-N.bbn.COM id aa12056; 24 Mar 92 9:51 EST Received: from YUKON.SCRC.Symbolics.COM by BBN.COM id aa07878; 24 Mar 92 9:43 EST Received: from LILIKOI.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via INTERNET with SMTP id 785593; 24 Mar 1992 09:44:08-0500 Date: Tue, 24 Mar 1992 09:52-0500 From: Mark Nahabedian Subject: Variable value menus To: lawton@aivax.rl.af.mil, clim@BBN.COM In-Reply-To: <19920324133322.3.LAWTON@BEN.rl.af.mil> Message-ID: <19920324145206.9.NAHA@LILIKOI.SCRC.Symbolics.COM> Date: Tue, 24 Mar 1992 08:33 EST From: James Lawton Is there a CLIM equivalent of the Symbolics function "tv:choose-variable-values"? Or is this something that would have to be done with a lot of "accept" calls? [...] It's easy enough to do using ACCEPTING-VALUES and ACCEPT. The idiom is something like (accepting-values (...) ... (setq foo (accept ... :default foo ...)) ...) Or in words: Remember to supply the current value of the variable as a default to ACCEPT otherwise it will get replaced with some value that ACCEPT pulls out of thin air. Remember to save the value back into the variable.   Received: from BBN.COM by LABS-N.bbn.COM id aa12679; 24 Mar 92 10:41 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa10385; 24 Mar 92 10:33 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 426080; 24 Mar 1992 10:23:13-0500 Date: Tue, 24 Mar 1992 10:32-0500 From: Scott McKay Subject: Variable value menus To: lawton@aivax.rl.af.mil, clim@BBN.COM In-Reply-To: <19920324133322.3.LAWTON@BEN.rl.af.mil> Message-ID: <19920324153258.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 24 Mar 1992 08:33 EST From: James Lawton Is there a CLIM equivalent of the Symbolics function "tv:choose-variable-values"? Or is this something that would have to be done with a lot of "accept" calls? James Lawton Rome Laboratory Griffiss AFB, NY 13441-5700 (315)330-2973 I have such a function that I could be persuaded to post on this mailing list once CLIM 1.1 is in the field.   Received: from BBN.COM by LABS-N.bbn.COM id aa14723; 24 Mar 92 13:09 EST Received: from sask.usask.ca by BBN.COM id aa16560; 24 Mar 92 13:02 EST Received: from access.USask.Ca by SASK.USask.CA (PMDF #12333) id <01GI0S18Z1O0000QF1@SASK.USask.CA>; Tue, 24 Mar 1992 11:40 CST Received: by access.USask.Ca (5.57/GLH-1.0); Tue, 24 Mar 92 11:37:21 -0600 id AA20326 for clim@bbn.com Received: from skaries.USask.ca by skdad.USask.ca (4.1/SMI-4.1) id AA12288; Tue, 24 Mar 92 11:37:18 CST Date: Tue, 24 Mar 92 11:37:16 CST From: coulman@skdad.usask.ca (Randy Coulman) Subject: Accepting multi-line string input? To: clim@bbn.com (Clim Users Mailing List) Message-id: <9203241737.AA12288@skdad.USask.ca> X-Envelope-to: clim@bbn.com X-Mailer: ELM [version 2.3 PL11] I am not particularly familiar with CLIM, but I have been following the mailing list for a few months, since I will be using it in the very near future. However, a colleague is using it right now and has a question that he hasn't been able to answer from the documentation. He has a need to accept multi-line string input. He has a pane where he accepts about 5 different values, some of which can be strings of any length. Currently, if the user's input hits the end of the window, the window just increases in width. He would rather that the line would wrap and the other prompts be moved down a line. Is this possible? Thanks for any help. If this is documented in the user's guide, just tell me where. Randy -- Randy A. Coulman | Department of Computational Science | University of Saskatchewan | coulman@cs.Usask.ca Saskatoon, SK S7N 0W0 | coulman@skaries.Usask.ca   Received: from BBN.COM by LABS-N.BBN.COM id aa28480; 25 Mar 92 14:08 EST Received: from Sunset.AI.SRI.COM by BBN.COM id aa01476; 25 Mar 92 14:02 EST Received: from Rockaway.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA06543 for clim@bbn.com; Wed, 25 Mar 92 11:03:50 PST Received: by Rockaway.AI.SRI.COM (4.1/SMI-4.1) id AA03389 for clim@bbn.com; Wed, 25 Mar 92 11:03:50 PST Date: Wed, 25 Mar 92 11:03:49 PST From: Peter Karp To: clim@bbn.com Subject: choose-variable-values Message-Id: I'm reposting this message for the benefit of new members of this list who may be interested in emulation of choose-variable-values under CLIM, as was mentioned in a recent posting. --------------- Return-Path: <@BBN.COM,@sunset.ai.sri.com:pkarp@ai.sri.com> Received: from LABS-N.BBN.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA12542 for pkarp; Thu, 9 Jan 92 20:35:56 PST Received: from BBN.COM by LABS-N.bbn.COM id aa10962; 9 Jan 92 23:33 EST Received: from Sunset.AI.SRI.COM by BBN.COM id aa04523; 9 Jan 92 23:29 EST Received: from Rockaway.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA12512 for clim@bbn.com; Thu, 9 Jan 92 20:30:07 PST Received: by Rockaway.AI.SRI.COM (4.1/SMI-4.1) id AA15471 for clim@bbn.com; Thu, 9 Jan 92 20:30:07 PST Date: Thu, 9 Jan 92 20:30:07 PST From: Peter Karp To: clim@BBN.COM Subject: New version of CTV-MENU Message-Id: A new version of the CTV-MENU package is available for anonymous FTP from SRI. This package provides CLIM emulation of various Symbolics TV-package menu functions, such as choose-variable-values. This new version contains a number of small bug fixes and enhancements. The most significant enhancement is the addition of a new function that uses a choose-variable-values style dialog window to allow a user to change the slot values of an instance of any CLOS class. FTP all files from directory pub/pkarp/lisp/ctv-menu of host ai.sri.com. Peter   Received: from BBN.COM by LABS-N.BBN.COM id aa00195; 25 Mar 92 16:07 EST Received: from eola.cs.ucf.edu by BBN.COM id aa10251; 25 Mar 92 16:02 EST Received: by eola.cs.ucf.edu (5.61/1.34) id AA27666; Wed, 25 Mar 92 20:59:37 GMT Date: Wed, 25 Mar 92 20:59:37 GMT From: hull@eola.cs.ucf.edu (Richard Hull) Message-Id: <9203252059.AA27666@eola.cs.ucf.edu> To: clim@BBN.COM Subject: Terminal-IO Pain I am trying to convert a Symbolics application written in Dynamic Windows to run on a SUN running Allegro CL (this is my first experience with CLIM). The problem I'm having is that in the original application, output to window panes was accomplished by changing the globals *terminal-io* and *query-io* when a menu option was chosen. Is there a comparable global in CLIM? I would like to be able to call 'get-frame-pane for the pane where I'd like the I/O to occur, set the global variable, call the LISP function that will perform the I/O, and when the function returns set the I/O variable back to the original interactor pane. If anyone has any ideas on how this would be accomplished please let me know. Thank you. Richard Hull UCF AI Lab   Received: from BBN.COM by LABS-N.BBN.COM id aa01984; 25 Mar 92 19:16 EST Received: from charon.arc.nasa.gov by BBN.COM id aa17738; 25 Mar 92 19:14 EST Received: from HALEAKALA.arc.nasa.gov by CHARON.arc.nasa.gov via INTERNET with SMTP id 114382; 25 Mar 1992 16:04:50-0800 Date: Wed, 25 Mar 1992 16:04-0800 From: will taylor Subject: :feedback function in dragging-output-record To: clim@bbn.com cc: taylor@CHARON.arc.nasa.gov Message-ID: <19920326000439.7.TAYLOR@HALEAKALA.arc.nasa.gov> I am using CLIM 1.0 - Genera 8.1.1 and want to limit the movement of an output record as I drag it with the mouse. I want to constrain it to move only in the y-direction and between y-min and y-max values which bracket the initial y-position. DRAGGING-NODE causes the "node" to move only in the y-direction (between y-min & y-max), regardless of the mouse's x-location -- but the erasing of the output-record does not erase properly unless the mouse stays on the "y-axis" [its (- current-x initial-x) remaining 0]. ==> Will Taylor .. (dragging-output-record pane node-output-record :repaint nil :finish-on-release t :feedback #'DRAGGING-NODE) .. (defun DRAGGING-NODE (output-record stream initial-x initial-y current-x current-y mode) "feedback function of dragging-output-record for dragging a node between its parent and its children" (let* ((node *drag-node*) (delta-y nil) (editor-pane (editor-pane *evolutionary-tree-frame*)) (current-tree (current-tree editor-pane)) (time-factor (time-factor current-tree)) (y-min (- initial-y 20)) (y-max (+ initial-y 20)) (y-limit 0)) (case mode (:draw (setf (node-y node) current-y) (setf delta-y (- current-y *node-y-position*)) (incf (node-pixel-branch-length node) delta-y) (setf *branch-length* (truncate (node-pixel-branch-length node) time-factor)) (if (< current-y y-min) (setf y-limit (- y-min current-y))) (if (> current-y y-max) (setf y-limit (- y-max current-y))) (multiple-value-bind (x-offset y-offset) (convert-from-relative-to-absolute-coordinates stream output-record) ;; force node to move only in the y-direction (replay-1 output-record stream nil (- x-offset (- current-x initial-x)) (+ y-offset y-limit))) (setf *node-y-position* current-y)) (:erase (erase-output-record output-record stream)))))   Received: from BBN.COM by LABS-N.BBN.COM id aa10554; 26 Mar 92 11:30 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa13391; 26 Mar 92 11:03 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 426447; 26 Mar 1992 10:52:51-0500 Date: Thu, 26 Mar 1992 11:02-0500 From: Scott McKay Subject: :feedback function in dragging-output-record To: taylor@charon.arc.nasa.gov, clim@BBN.COM In-Reply-To: <19920326000439.7.TAYLOR@HALEAKALA.arc.nasa.gov> Message-ID: <19920326160235.6.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 25 Mar 1992 19:04 EST From: will taylor I am using CLIM 1.0 - Genera 8.1.1 and want to limit the movement of an output record as I drag it with the mouse. I want to constrain it to move only in the y-direction and between y-min and y-max values which bracket the initial y-position. DRAGGING-NODE causes the "node" to move only in the y-direction (between y-min & y-max), regardless of the mouse's x-location -- but the erasing of the output-record does not erase properly unless the mouse stays on the "y-axis" [its (- current-x initial-x) remaining 0]. A bunch of bugs were fixed in DRAGGING-OUTPUT for CLIM 1.1. I cannot say for sure that this will have been fixed, but you should check it out when you get CLIM 1.1 and send a bug report if it does not. ==> Will Taylor .. (dragging-output-record pane node-output-record :repaint nil :finish-on-release t :feedback #'DRAGGING-NODE) .. (defun DRAGGING-NODE (output-record stream initial-x initial-y current-x current-y mode) "feedback function of dragging-output-record for dragging a node between its parent and its children" (let* ((node *drag-node*) (delta-y nil) (editor-pane (editor-pane *evolutionary-tree-frame*)) (current-tree (current-tree editor-pane)) (time-factor (time-factor current-tree)) (y-min (- initial-y 20)) (y-max (+ initial-y 20)) (y-limit 0)) (case mode (:draw (setf (node-y node) current-y) (setf delta-y (- current-y *node-y-position*)) (incf (node-pixel-branch-length node) delta-y) (setf *branch-length* (truncate (node-pixel-branch-length node) time-factor)) (if (< current-y y-min) (setf y-limit (- y-min current-y))) (if (> current-y y-max) (setf y-limit (- y-max current-y))) (multiple-value-bind (x-offset y-offset) (convert-from-relative-to-absolute-coordinates stream output-record) ;; force node to move only in the y-direction (replay-1 output-record stream nil (- x-offset (- current-x initial-x)) (+ y-offset y-limit))) (setf *node-y-position* current-y)) (:erase (erase-output-record output-record stream)))))   Received: from BBN.COM by LABS-N.BBN.COM id aa16894; 26 Mar 92 22:24 EST Received: from FUJI.ILA.COM by BBN.COM id aa10499; 26 Mar 92 22:21 EST Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 308111; 26 Mar 92 22:21:09 EST Date: Thu, 26 Mar 1992 16:38-0800 From: William M. York Subject: Re: Clim commands - interleaving args and commands words To: JGA@alderaan.scrc.symbolics.com, scosysv!keunen@nrb.be cc: clim@bbn.com In-Reply-To: <19920319200055.0.JGA@JUBJUB.SCRC.Symbolics.COM> Message-ID: <19920327003807.7.YORK@CHUCK-JONES.west.dialnet.ila.com> Date: Thu, 19 Mar 1992 12:00 PST From: "John G. Aspinall" Date: Thu, 19 Mar 1992 13:50 EST From: "David A. Moon" Isn't there a command presentation type? Try making the second argument to ask be of that type. Maybe it will work. I haven't tried it yet, but that's exactly what I'd try, too. Probably you want to make subtypes of command, i.e. askable-command, askable-on-unix-host-command, .... Actually, rather than separate presentation types, just group related commands in separate command tables and then use a presentation-type spec like: '((command :command-table askable-on-unix-host-commands))   Received: from BBN.COM by LABS-N.BBN.COM id aa28324; 27 Mar 92 17:36 EST Received: from gatech.edu by BBN.COM id aa15076; 27 Mar 92 17:32 EST Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA22826 for clim@bbn.com; Fri, 27 Mar 92 17:31:56 EST Received: from pravda.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA29290; Fri, 27 Mar 92 17:31:53 EST Received: from kant.gatech.edu (kant.cc.gatech.edu) by pravda.cc.gatech.edu (4.1/SMI-4.1) id AA07362; Fri, 27 Mar 92 17:31:26 EST Date: Fri, 27 Mar 1992 17:31-0500 From: Richard Billington Subject: specializing CLIM windows ... To: clim@bbn.com Message-Id: <19920327223124.6.BUFF@kant.gatech.edu> The doc. for CLIM:open-window-stream option :window-type says: The name of the clas of window to create. The default is the class normally used by CLIM for the parent win- dow. This argument is provided so that you can special- ize CLIM window classes, but should be used sparingly. Ok. Now, if I look at what it opens without this parameter, it's CLIM::SHEET-WINDOW-STREAM, which looks like it is composed of CLIM::WINDOW STREAM and CLIM::SHEET-IMPLEMENTATION-MIXIN. I (apparently incorrectly) assumed that I needed to specialize the CLIM::WINDOW-STREAM class so I could remain device independent - I figured that the :PARENT option would make it clear that I needed to have the sheet stuff mixed in. Yea, it sounds like magic, but I was hoping that I could specialize a CLIM window class that was device independent. Is this doable in some way? PS When I created my window (or tried) the debugger told me I had to specify a value for :DISPLAY-DEVICE-TYPE, which the manual says is one of those "remaining keyword arguments" which "are internal and should not be used".   Received: from BBN.COM by LABS-N.BBN.COM id aa20361; 30 Mar 92 9:03 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa23045; 30 Mar 92 8:51 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 426608; 30 Mar 1992 08:41:32-0500 Date: Mon, 30 Mar 1992 08:50-0500 From: Scott McKay Subject: specializing CLIM windows ... To: buff@cc.gatech.edu, clim@BBN.COM In-Reply-To: <19920327223124.6.BUFF@kant.gatech.edu> Message-ID: <19920330135052.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 27 Mar 1992 17:31 EST From: Richard Billington The doc. for CLIM:open-window-stream option :window-type says: The name of the clas of window to create. The default is the class normally used by CLIM for the parent win- dow. This argument is provided so that you can special- ize CLIM window classes, but should be used sparingly. Ok. Now, if I look at what it opens without this parameter, it's CLIM::SHEET-WINDOW-STREAM, which looks like it is composed of CLIM::WINDOW STREAM and CLIM::SHEET-IMPLEMENTATION-MIXIN. I (apparently incorrectly) assumed that I needed to specialize the CLIM::WINDOW-STREAM class so I could remain device independent - I figured that the :PARENT option would make it clear that I needed to have the sheet stuff mixed in. Yea, it sounds like magic, but I was hoping that I could specialize a CLIM window class that was device independent. Is this doable in some way? No. CLIM 1.0 is entirely deficient in this area. CLIM 2.0 breaks up "window streams" into device-indepedent classes that support generic "window stream-ness" and device-dependent classes that support generic operations for each type of display device. The only thing you can do in CLIM 1.0 is to write a device-independent class, and then specialize CLIM::SHEET-WINDOW-STREAM for Genera sheets, CLIM::CLX-WINDOW for X windows, and CLIM::CLOE-WINDOW-STREAM for CLOE. Sorry this is so bad, it will get much better when CLIM 2.0 is out. PS When I created my window (or tried) the debugger told me I had to specify a value for :DISPLAY-DEVICE-TYPE, which the manual says is one of those "remaining keyword arguments" which "are internal and should not be used".   Received: from BBN.COM by LABS-N.BBN.COM id aa23114; 30 Mar 92 12:30 EST Received: from fenrix.si.no by BBN.COM id aa04945; 30 Mar 92 12:27 EST Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.22) id AA12822; Mon, 30 Mar 92 19:24:37 +0200 Date: Mon, 30 Mar 92 19:24:37 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9203301724.AAmonsun15436@D> To: clim@bbn.com Subject: scroll-bars Hi, I'm using CLIM 1.0 for MCL 2.0 (both beta) and wonder how to let the user operate the scroll-bars. The manual mentions scrolling in chapter 24.3.2. The Viewport and Scrolling in CLIM. It says clim:window-set-viewport-position can be used to scroll a window. The programmer can of course use this function, but how can the user operate the scroll-bar, to give the same effect? I have made an application frame and supplied the :scroll-bar option to several panes. The scroll-bars appear, but never seem to be active. Do I have to tell CLIM how big the drawing plane actually is (the manual says its infinite...)? Do I have to use platform specific functions and loose portability? Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.BBN.COM id aa25236; 30 Mar 92 15:07 EST Received: from FUJI.ILA.COM by BBN.COM id aa13714; 30 Mar 92 15:01 EST Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 308196; 30 Mar 92 15:00:58 EST Date: Sun, 29 Mar 1992 22:22-0800 From: William M. York Subject: specializing CLIM windows ... To: buff@cc.gatech.edu, clim@bbn.com In-Reply-To: <19920327223124.6.BUFF@kant.gatech.edu> Message-ID: <19920330062234.5.YORK@CHUCK-JONES.west.dialnet.ila.com> Date: Fri, 27 Mar 1992 14:31 PST From: Richard Billington The doc. for CLIM:open-window-stream option :window-type says: The name of the clas of window to create. The default is the class normally used by CLIM for the parent win- dow. This argument is provided so that you can special- ize CLIM window classes, but should be used sparingly. Ok. Now, if I look at what it opens without this parameter, it's CLIM::SHEET-WINDOW-STREAM, which looks like it is composed of CLIM::WINDOW STREAM and CLIM::SHEET-IMPLEMENTATION-MIXIN. I (apparently incorrectly) assumed that I needed to specialize the CLIM::WINDOW-STREAM class so I could remain device independent - I figured that the :PARENT option would make it clear that I needed to have the sheet stuff mixed in. Yea, it sounds like magic, but I was hoping that I could specialize a CLIM window class that was device independent. Is this doable in some way? This is one of the architectural limitations of CLIM 1. It is what led us to split out the device-dependent stuff into the "port" and "medium" components in the CLIM 2 design. That allows you to specialize the portable "window" object class, which then incorporates the correct device-dependent component (e.g. a medium that implements graphics via CLX or via Mac Toolbox calls). For now, you have to define SHEET-MY-CLASS and CLX-MY-CLASS and so on.   Received: from BBN.COM by LABS-N.BBN.COM id aa25952; 30 Mar 92 16:06 EST Received: from FUJI.ILA.COM by BBN.COM id aa16731; 30 Mar 92 16:00 EST Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 308202; 30 Mar 92 15:59:43 EST Date: Mon, 30 Mar 1992 12:50-0800 From: William M. York Subject: scroll-bars To: Hallvard.Tretteberg@si.no, clim@bbn.com In-Reply-To: <9203301724.AAmonsun15436@D> Message-ID: <19920330205046.6.YORK@CHUCK-JONES.west.dialnet.ila.com> Date: Mon, 30 Mar 1992 09:24 PST From: Hallvard.Tretteberg@si.no Hi, I'm using CLIM 1.0 for MCL 2.0 (both beta) and wonder how to let the user operate the scroll-bars. The manual mentions scrolling in chapter 24.3.2. The Viewport and Scrolling in CLIM. It says clim:window-set-viewport-position can be used to scroll a window. The programmer can of course use this function, but how can the user operate the scroll-bar, to give the same effect? I have made an application frame and supplied the :scroll-bar option to several panes. The scroll-bars appear, but never seem to be active. Do I have to tell CLIM how big the drawing plane actually is (the manual says its infinite...)? Do I have to use platform specific functions and loose portability? You have to be in the CLIM input loop for everything to work properly. So, after you have displayed the information, you could do READ-CHAR or STREAM-INPUT-WAIT on a CLIM window stream.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa11368; 31 Mar 92 17:44 EST Received: by KARIBA.BBN.COM id aa02508; 31 Mar 92 16:57 EST To: clim@BBN.COM cc: jmorrill@BBN.COM Subject: updating-output Date: Tue, 31 Mar 92 16:55:45 -0500 Message-ID: <3366.702078945@bbn.com> From: Jeff Morrill Is there any reason I should avoid nesting updating-output within the scope of with-output-as-presentation? I have a big presentation region that is recursively divided up into smaller regions that ultimately contain a mixture of text and graphics. I am having trouble making incremental redisplay work with this type of hierarchical display. (updating-output (...) (with-output-as-presentation (...) (updating-output (...) (with-output-as-presentation (...) body1) (with-output-as-presentation (...) body2)) ...)) It seems like the way things are nested makes a big difference. The documentation doesn't mention any nesting restrictions. Thanks for any advice, jeff morrill   Received: from BBN.COM by LABS-N.BBN.COM id aa18258; 1 Apr 92 8:10 EST Received: from relay.philips.nl by BBN.COM id aa01492; 1 Apr 92 8:06 EST Return-Path: Received: from prl.philips.nl ([130.144.1.112]) by relay.philips.nl with SMTP (5.65c/smail2.5/05-10-87); id AA17108; Wed, 1 Apr 1992 15:04:41 +0200 Received: by prl.philips.nl; Wed, 1 Apr 92 15:05:23 +0200 Received: by prles6o.prl.philips.nl; Wed, 1 Apr 92 15:02:38 +0200 Date: Wed, 1 Apr 92 15:02:38 +0200 From: terhorst@prl.philips.nl Message-Id: <9204011302.AA18931@prles6o.prl.philips.nl> To: clim@bbn.com Subject: subscription request Please add me to this mailing list on CLIM Thanks in advance, Herman ter Horst Philips Research Laboratories Eindhoven P.O. Box 80.000 5600 JA Eindhoven The Netherlands email: terhorst@prl.philips.nl   Received: from BBN.COM by LABS-N.BBN.COM id aa19190; 1 Apr 92 9:55 EST Received: from crdgw1.GE.COM by BBN.COM id aa06797; 1 Apr 92 9:48 EST Received: by crdgw1.ge.com (5.57/GE 1.123) id AA21500; Wed, 1 Apr 92 09:48:28 EST Received: from procyon.crd.Ge.Com by sol.crd.Ge.Com (4.0/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA15502; Wed, 1 Apr 92 09:48:42 EST Date: Wed, 1 Apr 92 09:48:42 EST From: halvers@sol.crd.ge.com (peter c halverson) Message-Id: <9204011448.AA15502@sol.crd.Ge.Com> Received: by procyon.crd.Ge.Com (4.1/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA00595; Wed, 1 Apr 92 09:48:40 EST To: clim@bbn.com Subject: formatting graphs in CLIM Reply-To: Pete Halverson Sun-Distance: 149536295 kilometers (1.000 AU) Has anyone come up with a more useful graphing facility for CLIM 1.[01] than FORMAT-GRAPH-FROM-ROOT? In particular, I need to be able to graph general (connected) lattices which may have more than one "root", shared nodes, etc. Ideally, I'd like something similar to Genera's FORMATTING-GRAPH, which provides a dynamic environment in which graphs are can be elaborated in arbitrary order using FORMATTING-GRAPH-NODE and CONNECT-GRAPH-NODE calls. Before I go off and do something silly like porting FORMATTING-GRAPH myself, has anyone done something similar? Thanks, Pete Halverson   Received: from BBN.COM by LABS-N.BBN.COM id aa19930; 1 Apr 92 10:55 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa11601; 1 Apr 92 10:46 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 426828; 1 Apr 1992 10:36:24-0500 Date: Wed, 1 Apr 1992 10:45-0500 From: Scott McKay Subject: formatting graphs in CLIM To: halverson@crd.ge.com, clim@BBN.COM In-Reply-To: <9204011448.AA15502@sol.crd.Ge.Com> Message-ID: <19920401154542.9.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 1 Apr 1992 09:48 EST From: peter c halverson Has anyone come up with a more useful graphing facility for CLIM 1.[01] than FORMAT-GRAPH-FROM-ROOT? In particular, I need to be able to graph general (connected) lattices which may have more than one "root", shared nodes, etc. Ideally, I'd like something similar to Genera's FORMATTING-GRAPH, which provides a dynamic environment in which graphs are can be elaborated in arbitrary order using FORMATTING-GRAPH-NODE and CONNECT-GRAPH-NODE calls. Before I go off and do something silly like porting FORMATTING-GRAPH myself, has anyone done something similar? I did <:-). It's called FORMATTING-GRAPH-FROM-ROOTS, and it's in CLIM 1.1. When I was working on it, I discovered that DW:FORMATTING-GRAPH, DW:FORMATTING-GRAPH-NODE, and DW:CONNECT-GRAPH-NODE turned out not to be necessary, since the new CLIM grapher seems to provide enough control to subsume them. I converted all of my old programs that used those DW functions to CLIM, and they all work. Bug notice: to my dismay FORMATTING-GRAPH-FROM-ROOTS works, um, less than perfectly when used with UPDATING-OUTPUT (surprise, surprise).   Received: from BBN.COM by LABS-N.BBN.COM id aa20747; 1 Apr 92 11:57 EST Received: from jupiter.risc.rockwell.com by BBN.COM id aa14201; 1 Apr 92 11:49 EST Received: from magrathea.risc.rockwell.com by jupiter.risc.rockwell.com (4.1/SMI-4.1) id AA08940; Wed, 1 Apr 92 08:49:14 PST Date: Wed, 1 Apr 92 08:49:14 PST From: bss@jupiter.risc.rockwell.com (Bruce Seely) Message-Id: <9204011649.AA08940@jupiter.risc.rockwell.com> Received: by magrathea.risc.rockwell.com (4.1/SMI-4.1) id AA05743; Wed, 1 Apr 92 08:50:37 PST To: SWM@sapsucker.scrc.symbolics.com Cc: clim@BBN.COM In-Reply-To: Scott McKay's message of Wed, 1 Apr 1992 10:45-0500 <19920401154542.9.SWM@SUMMER.SCRC.Symbolics.COM> Subject: formatting graphs in CLIM Date: Wed, 1 Apr 1992 10:45-0500 From: Scott McKay Date: Wed, 1 Apr 1992 09:48 EST From: peter c halverson Has anyone come up with a more useful graphing facility for CLIM 1.[01] than FORMAT-GRAPH-FROM-ROOT? In particular, I need to be able to graph general (connected) lattices which may have more than one "root", shared nodes, etc. Ideally, I'd like something similar to Genera's FORMATTING-GRAPH, which provides a dynamic environment in which graphs are can be elaborated in arbitrary order using FORMATTING-GRAPH-NODE and CONNECT-GRAPH-NODE calls. Before I go off and do something silly like porting FORMATTING-GRAPH myself, has anyone done something similar? I did <:-). It's called FORMATTING-GRAPH-FROM-ROOTS, and it's in CLIM 1.1. When I was working on it, I discovered that DW:FORMATTING-GRAPH, DW:FORMATTING-GRAPH-NODE, and DW:CONNECT-GRAPH-NODE turned out not to be necessary, since the new CLIM grapher seems to provide enough control to subsume them. I converted all of my old programs that used those DW functions to CLIM, and they all work. Does this actually draw graphs, or does it still convert graphs to trees by replicating nodes as was done in earlier versions of CLIM?   Received: from BBN.COM by LABS-N.BBN.COM id aa21088; 1 Apr 92 12:16 EST Received: from cs.utexas.edu by BBN.COM id aa15117; 1 Apr 92 12:08 EST Received: from sage.cs.utexas.edu by cs.utexas.edu (5.64/1.122) with SMTP id AA29102; Wed, 1 Apr 92 11:08:01 -0600 Received: by sage.cs.utexas.edu (5.64/Client) id AA00574; Wed, 1 Apr 92 11:08:45 -0600 Message-Id: <9204011708.AA00574@sage.cs.utexas.edu> From: eilerts@cs.utexas.edu (Erik Eilerts) Date: Wed, 1 Apr 1992 11:08:45 -0600 X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: clim@bbn.com Subject: Accepting-values Does anyone have some clim code they could send me that does the following: 1. pops up a window 2. makes a call to accepting-values using that window as the stream Thanks, Erik Eilerts University of Texas at Austin eilerts@cs.utexas.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa20832; 1 Apr 92 12:02 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa14336; 1 Apr 92 11:52 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 426846; 1 Apr 1992 11:41:58-0500 Date: Wed, 1 Apr 1992 11:51-0500 From: Scott McKay Subject: formatting graphs in CLIM Date: Wed, 1 Apr 1992 10:45-0500 From: Scott McKay To: bss@jupiter.risc.rockwell.com, SWM@SAPSUCKER.SCRC.Symbolics.COM cc: clim@BBN.COM In-Reply-To: <9204011649.AA08940@jupiter.risc.rockwell.com> Message-ID: <19920401165119.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 1 Apr 1992 11:49 EST From: bss@jupiter.risc.rockwell.com (Bruce Seely) Date: Wed, 1 Apr 1992 09:48 EST From: peter c halverson Has anyone come up with a more useful graphing facility for CLIM 1.[01] than FORMAT-GRAPH-FROM-ROOT? In particular, I need to be able to graph general (connected) lattices which may have more than one "root", shared nodes, etc. Ideally, I'd like something similar to Genera's FORMATTING-GRAPH, which provides a dynamic environment in which graphs are can be elaborated in arbitrary order using FORMATTING-GRAPH-NODE and CONNECT-GRAPH-NODE calls. Before I go off and do something silly like porting FORMATTING-GRAPH myself, has anyone done something similar? I did <:-). It's called FORMATTING-GRAPH-FROM-ROOTS, and it's in CLIM 1.1. When I was working on it, I discovered that DW:FORMATTING-GRAPH, DW:FORMATTING-GRAPH-NODE, and DW:CONNECT-GRAPH-NODE turned out not to be necessary, since the new CLIM grapher seems to provide enough control to subsume them. I converted all of my old programs that used those DW functions to CLIM, and they all work. Does this actually draw graphs, or does it still convert graphs to trees by replicating nodes as was done in earlier versions of CLIM? It draws directed acyclic graphs.   Received: from BBN.COM by LABS-N.BBN.COM id aa22438; 1 Apr 92 13:58 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa19519; 1 Apr 92 13:53 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 426883; 1 Apr 1992 13:42:32-0500 Date: Wed, 1 Apr 1992 13:51-0500 From: Scott McKay Subject: Accepting-values To: eilerts@cs.utexas.edu, clim@BBN.COM In-Reply-To: <9204011708.AA00574@sage.cs.utexas.edu> Message-ID: <19920401185155.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 1 Apr 1992 12:08 EST From: Erik Eilerts Does anyone have some clim code they could send me that does the following: 1. pops up a window 2. makes a call to accepting-values using that window as the stream Try the :OWN-WINDOW T option to ACCEPTING-VALUES.   Received: from BBN.COM by LABS-N.BBN.COM id aa24413; 1 Apr 92 16:11 EST Received: from ALDERAAN.SCRC.Symbolics.COM by BBN.COM id aa25314; 1 Apr 92 16:04 EST Received: from JUBJUB.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via INTERNET with SMTP id 500759; 1 Apr 1992 15:17:02-0500 Date: Wed, 1 Apr 1992 15:17-0500 From: John G. Aspinall Subject: Accepting-values To: eilerts@cs.utexas.edu, clim@BBN.COM In-Reply-To: <9204011708.AA00574@sage.cs.utexas.edu> Message-ID: <19920401201713.4.JGA@JUBJUB.SCRC.Symbolics.COM> Date: Wed, 1 Apr 1992 12:08 EST From: Erik Eilerts Does anyone have some clim code they could send me that does the following: 1. pops up a window 2. makes a call to accepting-values using that window as the stream This is exactly what the :own-window option to accepting-values is there for. Here's a toy example. Note the use of a simple restart so you can return nil when the dialog is aborted. (defun sandwich (&optional (stream *query-io*)) (with-simple-restart (abort "Forget the Sandwich") (let* ((s-type :steak) (steak-options (list :mustard :onions)) (italian-options (list :lettuce :tomatoes)) (options steak-options)) (accepting-values (stream :own-window t :exit-boxes '((:exit " Cool") (:abort " Forget It")) :label "Choose a Sandwich") (setq s-type (accept '(member :steak :italian) :stream stream :prompt "Type" :default s-type)) (terpri stream) (setq options (if (eql s-type :steak) (setq steak-options (accept '(subset :mustard :onions :cheese :peppers) :stream stream :prompt "With" :default steak-options)) (setq italian-options (accept '(subset :lettuce :tomatoes :pickles) :stream stream :prompt "With" :default italian-options))))) (return-from sandwich (cons s-type options)))) nil)   Received: from BBN.COM by LABS-N.bbn.COM id aa04123; 2 Apr 92 10:52 EST Received: from fenrix.si.no by BBN.COM id aa21077; 2 Apr 92 10:36 EST Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.22) id AA01026; Thu, 2 Apr 92 17:34:05 +0200 Date: Thu, 2 Apr 92 17:34:05 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9204021534.AAmonsun16372@D> To: clim@bbn.com Subject: presentation-replace-input Two questions: 1. When I use presentation-replace-input: (clim:presentation-replace-input stream chosen-object type view) inside an accept method, CLIM doesn't use the right presentation method. It seems as though it uses a default method that uses print-object instead. What is wrong? 2. The command line echoes the argument list when I type after entering the command name. How can I prevent that behaviour? Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.bbn.COM id aa07421; 2 Apr 92 14:24 EST Received: from watson.ibm.com by BBN.COM id aa02463; 2 Apr 92 14:20 EST Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 0059; Thu, 02 Apr 92 14:19:54 EST Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0" id 2297; Thu, 2 Apr 1992 14:19:48 EST Received: from fiasco.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2) with TCP; Thu, 02 Apr 92 14:19:46 EST Received: by fiasco.watson.ibm.com (AIX 3.1/UCB 5.61/920123) id AA32567; Thu, 2 Apr 92 14:19:51 -0500 Message-Id: <9204021919.AA32567@fiasco.watson.ibm.com> To: clim@BBN.COM X-External-Networks: yes Reply-To: meir@watson.ibm.com Subject: lack of :extend-width arg to clim:formatting-table Date: Thu, 02 Apr 92 14:19:51 -0500 From: "Meir Laker" dw:formatting-table had an :extend-width arg which (if specified with value t) caused dw to space the table columns evenly over the full horizontal space available. We used this for presenting dynamically growing tables (i.e., the number of columns changes) so that we didn't have to calculate the inter-column spacing on the fly as the table width grew and shrunk in order to keep the table spaced evenly across a window. This option seems to be missing from the clim version. Am I expected to manage the inter-column spacing myself? I would need to write my table to a helper stream, retrieve the size of its bounding rectangle apportion the remaining space amongst the current number of columns in the table, and finally write the table specifying a new inter-column spacing. This seems like duplication of work that clim is already doing. I notice that clim:formatting-item-list is documented with the above behavior by default (although I couldn't get it to work either with even the simple case: (clim:formatting-item-list (stream :n-rows 1 :stream-width (clim:stream-text-margin stream)) . . . . ) ). Nevertheless, I really need the behavior with a table of 2 rows as well. Meir Laker IBM Thomas J. Watson Research Center P.O. Box 218, Yorktown Heights, NY 10598 Phone: 914-945-2699 Tieline: 862-2699 meir@watson.ibm.com   Received: from BBN.COM by LABS-N.BBN.COM id ab09145; 2 Apr 92 17:07 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa13412; 2 Apr 92 17:02 EST Received: from CRAWLER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 427044; 2 Apr 1992 16:52:02-0500 Date: Thu, 2 Apr 1992 17:03-0500 From: Scott McKay Subject: Re: lack of :extend-width arg to clim:formatting-table To: meir@watson.ibm.com, SWM@SAPSUCKER.SCRC.Symbolics.COM cc: clim@BBN.COM In-Reply-To: <9204022147.AA28119@fiasco.watson.ibm.com> Message-ID: <19920402220311.1.SWM@CRAWLER.SCRC.Symbolics.COM> Date: Thu, 2 Apr 1992 16:47 EST From: "Meir Laker" 3 questions: 1. What about clim:formatting-item-list which IS documented as exhibiting the above behavior? Apparently there was thought invested in this behavior for clim as well! 2. In addition, clim:formatting-item-list DOESN'T WORK in the above case although it is documented to work. (I guess not enough thought was invested, after all!) This behavior was put into CLIM:FORMATTING-ITEM-LIST for the sole purpose of making command menus look nice. It does work, but you need to supply :NO-INITIAL-SPACING NIL (gee, that's obvious). 3. Is the method I specify above (using a helper stream and bounding rectangle) a reasonable approach if I don't want to hack the clim:formatting-table code at the moment? I would find it easier to extend CLIM:TABLE-FORMATTING, but of course I am familiar with the code. You might find it easier, too, but your approach is not unreasonable if you are willing to pay the performance penalty.   Received: from BBN.COM by LABS-N.bbn.COM id aa08556; 2 Apr 92 16:10 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa09971; 2 Apr 92 16:03 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 427037; 2 Apr 1992 15:53:10-0500 Date: Thu, 2 Apr 1992 16:02-0500 From: Scott McKay Subject: lack of :extend-width arg to clim:formatting-table To: meir@watson.ibm.com, clim@BBN.COM In-Reply-To: <9204021919.AA32567@fiasco.watson.ibm.com> Message-ID: <19920402210234.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 2 Apr 1992 14:19 EST From: Meir Laker dw:formatting-table had an :extend-width arg which (if specified with value t) caused dw to space the table columns evenly over the full horizontal space available. We used this for presenting dynamically growing tables (i.e., the number of columns changes) so that we didn't have to calculate the inter-column spacing on the fly as the table width grew and shrunk in order to keep the table spaced evenly across a window. This option seems to be missing from the clim version. Am I expected to manage the inter-column spacing myself? I would need to write my table to a helper stream, retrieve the size of its bounding rectangle apportion the remaining space amongst the current number of columns in the table, and finally write the table specifying a new inter-column spacing. This seems like duplication of work that clim is already doing. I notice that clim:formatting-item-list is documented with the above behavior by default (although I couldn't get it to work either with even the simple case: (clim:formatting-item-list (stream :n-rows 1 :stream-width (clim:stream-text-margin stream)) . . . . ) ). Nevertheless, I really need the behavior with a table of 2 rows as well. Historical background: one very important thing for Genera users to remember about CLIM is that CLIM is not, and is not intended to be, a portable implementation of Dynamic Windows. It is true that CLIM is the intellectual successor to DW, but CLIM was designed from the ground up based on our experiences with DW, but the DW code was not used as a "reference document" for CLIM's code. We explicitly avoided porting a lot of the less frequently used things from DW to CLIM in order to keep CLIM simpler than DW. (Those of you who have never used Dynamic Windows would probably be horrified at just how much more complicated DW is than CLIM, given the complexity of CLIM.) Anyway, :EXTEND-WIDTH is one of the many things that was thought to be of limited utility, and was therefore omitted from CLIM. If this is critically important to you or is somewhat important to a larger group of users, then it is probably worth doing. Otherwise, this will have to go on the back-burner for the time being until one of us has enough time to do this as a hack-attack. If you are interested in trying to extend FORMATTING-TABLE in this way yourself, I would be happy to send you the source code for it in exchange for whatever you come up with.   Received: from BBN.COM by LABS-N.BBN.COM id aa09474; 2 Apr 92 17:39 EST Received: from watson.ibm.com by BBN.COM id aa14501; 2 Apr 92 17:32 EST Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 4439; Thu, 02 Apr 92 17:32:12 EST Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0" id 4569; Thu, 2 Apr 1992 17:32:10 EST Received: from fiasco.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2) with TCP; Thu, 02 Apr 92 17:32:09 EST Received: by fiasco.watson.ibm.com (AIX 3.1/UCB 5.61/920123) id AA23462; Thu, 2 Apr 92 17:32:14 -0500 Message-Id: <9204022232.AA23462@fiasco.watson.ibm.com> To: Scott McKay Cc: clim@BBN.COM X-External-Networks: yes Reply-To: meir@watson.ibm.com Subject: Re: lack of :extend-width arg to clim:formatting-table Date: Thu, 02 Apr 92 17:32:13 -0500 From: "Meir Laker" Date: Thu, 2 Apr 1992 17:03-0500 From: Scott McKay Date: Thu, 2 Apr 1992 16:47 EST From: "Meir Laker" 2. In addition, clim:formatting-item-list DOESN'T WORK in the above case although it is documented to work. (I guess not enough thought was invested, after all!) This behavior was put into CLIM:FORMATTING-ITEM-LIST for the sole purpose of making command menus look nice. That's eactly how I'm using it, but my command menus are home-grown and have icons associated with the name of the command. So, I use a 2 row table: the first row is the icon, the second is the name; there is one column for each icon/name pair. Because of the dual rows, I need the behavior for formatting-table. It does work, but you need to supply :NO-INITIAL-SPACING NIL (gee, that's obvious). I have tried both :no-initial-spacing nil and :no-initial-spacing t and cannot get it to work either way. I am also specifying :n-rows 1 abd have tried specifying the :stream-widht with no luck. Meir Laker   Received: from BBN.COM by LABS-N.bbn.COM id aa08967; 2 Apr 92 16:53 EST Received: from watson.ibm.com by BBN.COM id aa12659; 2 Apr 92 16:47 EST Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 3469; Thu, 02 Apr 92 16:47:44 EST Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0" id 4066; Thu, 2 Apr 1992 16:47:42 EST Received: from fiasco.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2) with TCP; Thu, 02 Apr 92 16:47:40 EST Received: by fiasco.watson.ibm.com (AIX 3.1/UCB 5.61/920123) id AA28119; Thu, 2 Apr 92 16:47:45 -0500 Message-Id: <9204022147.AA28119@fiasco.watson.ibm.com> To: Scott McKay Cc: clim@BBN.COM X-External-Networks: yes Reply-To: meir@watson.ibm.com Subject: Re: lack of :extend-width arg to clim:formatting-table Date: Thu, 02 Apr 92 16:47:44 -0500 From: "Meir Laker" Date: Thu, 2 Apr 1992 16:02-0500 From: Scott McKay Date: Thu, 2 Apr 1992 14:19 EST From: Meir Laker dw:formatting-table had an :extend-width arg which (if specified with value t) caused dw to space the table columns evenly over the full horizontal space available. We used this for presenting dynamically growing tables (i.e., the number of columns changes) so that we didn't have to calculate the inter-column spacing on the fly as the table width grew and shrunk in order to keep the table spaced evenly across a window. This option seems to be missing from the clim version. Am I expected to manage the inter-column spacing myself? I would need to write my table to a helper stream, retrieve the size of its bounding rectangle apportion the remaining space amongst the current number of columns in the table, and finally write the table specifying a new inter-column spacing. This seems like duplication of work that clim is already doing. I notice that clim:formatting-item-list is documented with the above behavior by default (although I couldn't get it to work either with even the simple case: (clim:formatting-item-list (stream :n-rows 1 :stream-width (clim:stream-text-margin stream)) . . . . ) ). Nevertheless, I really need the behavior with a table of 2 rows as well. Historical background: one very important thing for Genera users to remember about CLIM is that CLIM is not, and is not intended to be, a portable implementation of Dynamic Windows. It is true that CLIM is the intellectual successor to DW, but CLIM was designed from the ground up based on our experiences with DW, but the DW code was not used as a "reference document" for CLIM's code. We explicitly avoided porting a lot of the less frequently used things from DW to CLIM in order to keep CLIM simpler than DW. (Those of you who have never used Dynamic Windows would probably be horrified at just how much more complicated DW is than CLIM, given the complexity of CLIM.) Anyway, :EXTEND-WIDTH is one of the many things that was thought to be of limited utility, and was therefore omitted from CLIM. If this is critically important to you or is somewhat important to a larger group of users, then it is probably worth doing. Otherwise, this will have to go on the back-burner for the time being until one of us has enough time to do this as a hack-attack. If you are interested in trying to extend FORMATTING-TABLE in this way yourself, I would be happy to send you the source code for it in exchange for whatever you come up with. 3 questions: 1. What about clim:formatting-item-list which IS documented as exhibiting the above behavior? Apparently there was thought invested in this behavior for clim as well! 2. In addition, clim:formatting-item-list DOESN'T WORK in the above case although it is documented to work. (I guess not enough thought was invested, after all!) 3. Is the method I specify above (using a helper stream and bounding rectangle) a reasonable approach if I don't want to hack the clim:formatting-table code at the moment? Meir Laker   Received: from BBN.COM by LABS-N.BBN.COM id aa13296; 3 Apr 92 3:21 EST Received: from fenrix.si.no by BBN.COM id aa23443; 3 Apr 92 3:16 EST Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.22) id AA09100; Fri, 3 Apr 92 10:14:40 +0200 Date: Fri, 3 Apr 92 10:14:40 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9204030814.AAmonsun16528@D> To: clim@bbn.com Subject: two questions revisited Two questions: > You haven't said what system you are using. I'll repeat my quarterly > request to everyone on this list to explicitly say something like "CLIM > 1.1 under Allegro Common Lisp 4.0.2". Thanks. So here I'm trying again. I'm using CLIM 1.0 and MCL 1.0 (both beta). First I define som presentation types and a present method: (clim:define-presentation-type model-&-label ()) ; (defclass node (model-&-label)) ; make node a subclass of model-&-label (clim:define-presentation-type node ()) (clim:define-presentation-method clim:present (obj (type model-&-label) stream (view clim:textual-view) &key) (print-without-type obj stream)) Then I make an accept method, which is supposed to get a value from a homemade cut-buffer: (clim:define-presentation-method clim:accept ((type model-&-label) stream (view clim:textual-view) &key) (let* ((view (frame-view clim:*application-frame*)) (graph (view-graph view))) (let ((chosen-object (get-chosen-object view type))) ; look in cut-buffer (if (and *use-objects-when-accepting-p* chosen-object) (progn (unchoose-object view chosen-object) (clim:presentation-replace-input stream chosen-object type view) ; ^^^^^^^^^^^^^^^^^^^^^^^^^^ does not use my present-method (values chosen-object)) (values ; if no value in cut-buffer use standard completion (clim:completing-from-suggestions (stream) (mapc #'(lambda (graph-object) (clim:suggest (ensure-label graph-object) graph-object)) (complete-from-graph-object graph type))))) ))) As state in the code, clim:presentation-replace-input does not use my own present method but one that calls print-object. Using present with the same argument works but then the output of course isn't put into the input-buffer. Help! 2. The command line echoes the argument list when I type after entering the command name. How can I prevent that behaviour? > What "argument list"? Please describe this more specifically. My second problem concerns the command line: When pressing after entering" Beep Object" CLIM outputs "(node-or-edge)", i.e. a kind of prompt for either *one* argument or the *whole* argument-list. The command line looks like this: Command: Beep Object (node-or-edge) This is the definition of the command: (define-view-frame-command (com-beep-object :name t) ((node-or-edge '(or node edge))) ; 'model-&-label)) Can I prevent the output of "(node-or-edge)"? Thanks! Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.BBN.COM id aa17010; 3 Apr 92 10:14 EST Received: from elroy.jpl.nasa.gov by BBN.COM id aa07302; 3 Apr 92 9:59 EST Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA03233; Fri, 3 Apr 92 06:59:20 PST Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA01248; Fri, 3 Apr 92 06:53:24 PST Date: Fri, 3 Apr 92 06:53:24 PST From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9204031453.AA01248@eraserhead.Jpl.Nasa.Gov> To: cl-bugs@franz.com Subject: X-Window interaction with CLIM Cc: clim@bbn.com I am using Allegro V. 4.01 w/ CLIM 1.0 on a SPARC2. I just have a question of CLIM interaction with X-windows. Below is some background. I'm no expert in X-Windows so maybe this a not! I have been playing around with my CLIM application and found some interesting quirks in its operation. My application has extensive graphics and text on the screen. I have noticed that if I successively close the application down into an icon and reopen it (without giving the display a chance to fully update itself - also during the course of a gc) that when I open the application icon and give it time, the application sort of redisplays itself the number of times that I had successively opened and closed the icon before even though it isn't necessary. NOTE: My application uses my own history mechanism and doesn't use any of CLIM's incremental type features (ie: updating-output and such)! Also, I am running Composer. When the debugger window comes up and I bring up additional inspector windows and flush them or I do restarts in the debugger resulting in successive appearance of the debugger window (ie: in a loop or such) the application display refills the same display area that the debugger/inspector windows came up in over and over again the same number of times (even if the display area was the same). What gives? Is this a funny X-window or CLIM quirk? A substantial amount of time in display update is lost by doing these display area restores (even when the areas are the same).   Received: from BBN.COM by LABS-N.BBN.COM id aa18061; 3 Apr 92 11:25 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa11285; 3 Apr 92 11:20 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 427115; 3 Apr 1992 11:09:40-0500 Date: Fri, 3 Apr 1992 11:19-0500 From: Scott McKay Subject: two questions revisited To: Hallvard.Tretteberg@si.no, clim@BBN.COM In-Reply-To: <9204030814.AAmonsun16528@D> Message-ID: <19920403161903.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 3 Apr 1992 03:14 EST From: Hallvard.Tretteberg@si.no Two questions: > You haven't said what system you are using. I'll repeat my quarterly > request to everyone on this list to explicitly say something like "CLIM > 1.1 under Allegro Common Lisp 4.0.2". Thanks. So here I'm trying again. I still don't have enough information to reproduce this. You'll really need to supply an entire, simplified, reproducible test-case. When I do things that look what you have supplied below, it works fine. This area of CLIM hasn't changed much from CLIM 1.0 to CLIM 1.1, either. I'm sorry that I haven't been more helpful so far. I'm using CLIM 1.0 and MCL 1.0 (both beta). First I define som presentation types and a present method: (clim:define-presentation-type model-&-label ()) ; (defclass node (model-&-label)) ; make node a subclass of model-&-label (clim:define-presentation-type node ()) (clim:define-presentation-method clim:present (obj (type model-&-label) stream (view clim:textual-view) &key) (print-without-type obj stream)) Then I make an accept method, which is supposed to get a value from a homemade cut-buffer: (clim:define-presentation-method clim:accept ((type model-&-label) stream (view clim:textual-view) &key) (let* ((view (frame-view clim:*application-frame*)) (graph (view-graph view))) (let ((chosen-object (get-chosen-object view type))) ; look in cut-buffer (if (and *use-objects-when-accepting-p* chosen-object) (progn (unchoose-object view chosen-object) (clim:presentation-replace-input stream chosen-object type view) ; ^^^^^^^^^^^^^^^^^^^^^^^^^^ does not use my present-method (values chosen-object)) (values ; if no value in cut-buffer use standard completion (clim:completing-from-suggestions (stream) (mapc #'(lambda (graph-object) (clim:suggest (ensure-label graph-object) graph-object)) (complete-from-graph-object graph type))))) ))) As state in the code, clim:presentation-replace-input does not use my own present method but one that calls print-object. Using present with the same argument works but then the output of course isn't put into the input-buffer. Help! 2. The command line echoes the argument list when I type after entering the command name. How can I prevent that behaviour? > What "argument list"? Please describe this more specifically. My second problem concerns the command line: When pressing after entering" Beep Object" CLIM outputs "(node-or-edge)", i.e. a kind of prompt for either *one* argument or the *whole* argument-list. The command line looks like this: Command: Beep Object (node-or-edge) This is the definition of the command: (define-view-frame-command (com-beep-object :name t) ((node-or-edge '(or node edge))) ; 'model-&-label)) Can I prevent the output of "(node-or-edge)"? That's what :PROMPT NIL is for: (define-view-frame-command (com-beep-object :name t) ((node-or-edge '(or node edge) :PROMPT NIL)) ...)   Received: from BBN.COM by LABS-N.BBN.COM id aa19825; 3 Apr 92 13:55 EST Received: from FUJI.ILA.COM by BBN.COM id aa18349; 3 Apr 92 13:51 EST Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 308410; 3 Apr 92 13:50:32 EST Date: Fri, 3 Apr 1992 10:08-0800 From: William M. York Subject: two questions revisited To: Hallvard.Tretteberg@si.no, clim@bbn.com In-Reply-To: <9204030814.AAmonsun16528@D> Message-ID: <19920403180857.9.YORK@CHUCK-JONES.west.dialnet.ila.com> Date: Fri, 3 Apr 1992 00:14 PST From: Hallvard.Tretteberg@si.no I'm using CLIM 1.0 and MCL 1.0 (both beta). First I define som presentation types and a present method: (clim:define-presentation-type model-&-label ()) ; (defclass node (model-&-label)) ; make node a subclass of model-&-label (clim:define-presentation-type node ()) (clim:define-presentation-method clim:present (obj (type model-&-label) stream (view clim:textual-view) &key) (print-without-type obj stream)) Then I make an accept method, which is supposed to get a value from a homemade cut-buffer: [method that calls presentation-replace-input] As state in the code, clim:presentation-replace-input does not use my own present method but one that calls print-object. Using present with the same argument works but then the output of course isn't put into the input-buffer. Help! Is there any chance that your PRESENT method (or your PRINT-WITHOUT-TYPE function) could be getting an error? Maybe when it is asked to write to a string? The PRESENTATION-REPLACE-INPUT function calls PRESENT-TO-STRING on your arguments inside a HANDLER-BIND that catches errors. If an error is detected, it falls back on PRINC-TO-STRING, which would give you the Lisp-object representation. You can check this pretty easily under Genera by enabling the condition-tracing mechanism around one of your calls: Enable Condition Tracing ERROR You may find that you trap other errors that you weren't looking for. Just hit Resume in those cases.   Received: from BBN.COM by LABS-N.BBN.COM id aa20060; 3 Apr 92 14:06 EST Received: from FUJI.ILA.COM by BBN.COM id aa18804; 3 Apr 92 14:01 EST Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 308412; 3 Apr 92 14:00:21 EST Date: Fri, 3 Apr 1992 10:50-0800 From: William M. York Subject: Re: lack of :extend-width arg to clim:formatting-table To: meir@watson.ibm.com cc: clim@bbn.com In-Reply-To: <19920402220311.1.SWM@CRAWLER.SCRC.Symbolics.COM> Message-ID: <19920403185008.1.YORK@CHUCK-JONES.west.dialnet.ila.com> Date: Thu, 2 Apr 1992 14:03 PST From: Scott McKay Date: Thu, 2 Apr 1992 16:47 EST From: "Meir Laker" 3. Is the method I specify above (using a helper stream and bounding rectangle) a reasonable approach if I don't want to hack the clim:formatting-table code at the moment? I would find it easier to extend CLIM:TABLE-FORMATTING, but of course I am familiar with the code. You might find it easier, too, but your approach is not unreasonable if you are willing to pay the performance penalty. You don't really have to modify or extend the table-formatting code to do this (although it would be more efficient if the capability was "built-in" to table formatting). In fact, you can (almost) do it without resorting to any magic CLIM internals at all. The following code shows how you can post-process a formatted table to extend the columns across the full width of the window. It only using one CLIM internal funciton, MAP-OVER-TABLE-COLUMNS. See if it does what you want. ;;; -*- Mode: LISP; Syntax: Common-Lisp; Base: 10; Package: CLIM-USER -*- ;;; Make the columns of a table span the width of the window. ;;; Only works for column-oriented tables. (defun column-extension (stream) (window-clear stream) ;; First, collect the table output record, containing the tree ;; of output records as formatted by the standard table-formtting ;; mechanism. :DRAW-P NIL means that the table will not be ;; made visible yet. (let ((table (with-output-recording-options (stream :draw-p nil) ;; A simple four-column, five-row table showing ;; integer powers. (formatting-table (stream) (dotimes (exponent 4) ;; Column-oriented. (formatting-column (stream) (dotimes (n 5) (formatting-cell (stream :align-x :right) (format stream "~D" (expt n (1+ exponent))))))))))) ;; Now call the column-shuffler (expand-table table stream) ;; Finally, show the re-aligned table. (replay table stream) )) ;;; Move the columns of a table so that they fill the full ;;; width of the window. (defun expand-table (table stream) (let ((column-count 0)) ;; Count the number of columns. (clim::map-over-table-columns table #'(lambda (column) (declare (ignore column)) (incf column-count))) ;; Now we know how much space to leave between columns. (let ((column-width (floor (window-inside-width stream) column-count)) (column-index 0)) ;; Go over the columns again, relocating them. (clim::map-over-table-columns table #'(lambda (column) ;; New X position, same Y (multiple-value-bind (x y) (output-record-position* column) (declare (ignore x)) (output-record-set-position* column (* column-index column-width) y)) (incf column-index)))))) ;;; A macro to wrap around table-formatting code that expands ;;; the columns to fit. (defmacro with-columns-extended ((stream) &body body) (let ((table-var (gensym))) `(let ((,table-var (with-output-recording-options (,stream :draw-p nil) ,@body))) (expand-table ,table-var ,stream) (replay ,table-var ,stream)))) ;;; An example, using the same table from the first example (defun column-extension-easy (stream) (with-columns-extended (stream) ;; A simple four-column, five-row table showing ;; integer powers. (formatting-table (stream) (dotimes (exponent 4) ;; Column-oriented. (formatting-column (stream) (dotimes (n 5) (formatting-cell (stream :align-x :right) (format stream "~D" (expt n (1+ exponent))))))))))   Received: from BBN.COM by LABS-N.BBN.COM id aa20565; 3 Apr 92 14:44 EST Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa22198; 3 Apr 92 14:40 EST Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 427152; 3 Apr 1992 14:29:27-0500 Date: Fri, 3 Apr 1992 14:38-0500 From: Scott McKay Subject: two questions revisited To: York@chuck-jones.west.dialnet.ila.com, Hallvard.Tretteberg@si.no, clim@BBN.COM In-Reply-To: <19920403180857.9.YORK@CHUCK-JONES.west.dialnet.ila.com> Message-ID: <19920403193846.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 3 Apr 1992 13:08 EST From: "William M. York" Date: Fri, 3 Apr 1992 00:14 PST From: Hallvard.Tretteberg@si.no I'm using CLIM 1.0 and MCL 1.0 (both beta). First I define som presentation types and a present method: (clim:define-presentation-type model-&-label ()) ; (defclass node (model-&-label)) ; make node a subclass of model-&-label (clim:define-presentation-type node ()) (clim:define-presentation-method clim:present (obj (type model-&-label) stream (view clim:textual-view) &key) (print-without-type obj stream)) Then I make an accept method, which is supposed to get a value from a homemade cut-buffer: [method that calls presentation-replace-input] As state in the code, clim:presentation-replace-input does not use my own present method but one that calls print-object. Using present with the same argument works but then the output of course isn't put into the input-buffer. Help! Is there any chance that your PRESENT method (or your PRINT-WITHOUT-TYPE function) could be getting an error? Maybe when it is asked to write to a string? The PRESENTATION-REPLACE-INPUT function calls PRESENT-TO-STRING on your arguments inside a HANDLER-BIND that catches errors. If an error is detected, it falls back on PRINC-TO-STRING, which would give you the Lisp-object representation. That's a good point. Note that CLIM will probably let you know that this happened by doing the output in italics. You can check this pretty easily under Genera by enabling the condition-tracing mechanism around one of your calls: Enable Condition Tracing ERROR You may find that you trap other errors that you weren't looking for. Just hit Resume in those cases.   Received: from BBN.COM by LABS-N.BBN.COM id aa11131; 6 Apr 92 4:50 EDT Received: from unido.Germany.EU.net by BBN.COM id aa08703; 6 Apr 92 4:46 EDT Received: from fbihh.informatik.uni-hamburg.de by mail.Germany.EU.net with SMTP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA19398; Mon, 6 Apr 92 10:46:29 +0200 Received: from ki6 by fbihh.informatik.uni-hamburg.de (5.65+/FBIHH-2.23) with SMTP; id AA28173; Mon, 6 Apr 92 10:44:46 +0200 Received: from ki9.informatik.uni-hamburg.de by ki6.informatik.uni-hamburg.de (4.1/SMI-4.1) id AA19274; Mon, 6 Apr 92 10:44:34 +0200 Date: Mon, 6 Apr 92 10:44:34 +0200 From: matthias@ki6.informatik.uni-hamburg.de (Matthias Schick) Message-Id: <9204060844.AA19274@ki6.informatik.uni-hamburg.de> Received: by ki9.informatik.uni-hamburg.de (4.1/SMI-4.1) id AA00701; Mon, 6 Apr 92 10:54:23 +0200 To: clim@BBN.COM Cc: matthias@ki6.informatik.uni-hamburg.de Sorry for posting this to the whole group, but please remove me from this list. +-----------------------------------------------------------------------------+ | Matthias Schick Phone : (+49) 40/4123-6535 | | University of Hamburg Fax : (+49) 40/4123-6530 | | Bodenstedtstrasse 16 | | D-2000 Hamburg 50 Net : schick@informatik.uni-hamburg.de | +-----------------------------------------------------------------------------+   Received: from BBN.COM by LABS-N.BBN.COM id aa10970; 6 Apr 92 4:11 EDT Received: from unido.Germany.EU.net by BBN.COM id aa07953; 6 Apr 92 3:56 EDT Received: from fbihh.informatik.uni-hamburg.de by mail.Germany.EU.net with SMTP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA12429; Mon, 6 Apr 92 09:56:30 +0200 Received: from ki6 by fbihh.informatik.uni-hamburg.de (5.65+/FBIHH-2.23) with SMTP; id AA28039; Mon, 6 Apr 92 09:54:55 +0200 Received: from ki9.informatik.uni-hamburg.de by ki6.informatik.uni-hamburg.de (4.1/SMI-4.1) id AA19162; Mon, 6 Apr 92 10:05:50 +0200 Date: Mon, 6 Apr 92 10:05:50 +0200 From: matthias@ki6.informatik.uni-hamburg.de (Matthias Schick) Message-Id: <9204060805.AA19162@ki6.informatik.uni-hamburg.de> Received: by ki9.informatik.uni-hamburg.de (4.1/SMI-4.1) id AA00689; Mon, 6 Apr 92 10:04:31 +0200 To: clim@BBN.COM Sorry for posting this to the whole group, but please remove me from this list. +-----------------------------------------------------------------------------+ | Matthias Schick Phone : (+49) 40/4123-6535 | | University of Hamburg Fax : (+49) 40/4123-6530 | | Bodenstedtstrasse 16 | | D-2000 Hamburg 50 Net : schick@informatik.uni-hamburg.de | +-----------------------------------------------------------------------------+   Received: from BBN.COM by LABS-N.BBN.COM id aa20688; 6 Apr 92 18:29 EDT Received: from hyper.franz.com by BBN.COM id aa17650; 6 Apr 92 18:18 EDT Return-Path: Received: from sparky.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA13462; Mon, 6 Apr 92 15:16:19 PDT Received: by sparky.Franz.COM (4.1/FI-2.0) id AA04431; Mon, 6 Apr 92 15:14:53 PDT Message-Id: <9204062214.AA04431@sparky.Franz.COM> To: curt@eraserhead.Jpl.Nasa.Gov Class: bh Bh-Id: spr5329 Bh: append spr5329 Cc: bugs@Franz.COM, clim@bbn.com Subject: Re: [spr5329] X-Window interaction with CLIM Date: Mon, 06 Apr 92 15:14:52 -0700 From: John Irwin > I have been playing around with my CLIM application and found some interesting > quirks in its operation. My application has extensive graphics and text on > the screen. I have noticed that if I successively close the application down > into an icon and reopen it (without giving the display a chance to fully > update itself - also during the course of a gc) that when I open the > application icon and give it time, the application sort of redisplays itself > the number of times that I had successively opened and closed the icon before > even though it isn't necessary. NOTE: My application uses my own history > mechanism and doesn't use any of CLIM's incremental type features > (ie: updating-output and such)! This is a hard-to-avoid consequence of the way X11 Exposure events work. Each deiconification of the CLIM window generates some number of Expose events. CLIM is a "smart" window system, so rather than simply waiting for the "last" Expose event (the one with a 'count' of 0), it goes ahead and repaints whatever region each Expose event describes. This is highly optimal in many cases, say when the user is dragging a smaller window over the CLIM window. It is also "optimal" in the case of de-iconification, since it redraws the whole window once, which is the same thing a dumb application would do. What would be nice is if there was a simple way of looking forward in the event queue, seeing if there are Expose events further ahead in time that "contain" (in the geometric sense) the Expose events you're currently processing. If so, ignore the current events. This approach is difficult implementationally, mostly for reasons that are too complicated to explain via email. I'll file an RFE anyway, so we consider the issues involved. Fortunately, the situation will be ameiliorated in CLIM 2.0, as the contents of the application frame are kept in the server's backing store. On most X servers (like Suns) this reduces the problem to near zero. (I'm speaking of our version of CLIM 2.0, I don't know what the other vendors' plans are). C applications have the same problem, although they don't usually have to fault in as many pages to repaint the window. > Also, I am running Composer. When the debugger window comes up and I > bring up additional inspector windows and flush them or I do restarts in > the debugger resulting in successive appearance of the debugger window (ie: > in a loop or such) the application display refills the same display area that > the debugger/inspector windows came up in over and over again the same number > of times (even if the display area was the same). Um, I'm not sure exactly what you're describing. If you are saying that CLIM tries to repaint the application frame each time the X server tells CLIM that the frame's contents are no longer valid, you're right -- this is the same problem detailed above. If that's not what you mean, perhaps you could restate your example? -- John   Received: from BBN.COM by LABS-N.BBN.COM id aa24031; 7 Apr 92 2:04 EDT Received: from alpha.Xerox.COM by BBN.COM id aa21047; 7 Apr 92 2:02 EDT Received: from aramis.parc.xerox.com ([13.2.18.4]) by alpha.xerox.com with SMTP id <11656>; Mon, 6 Apr 1992 23:02:11 PDT Received: by aramis.parc.xerox.com id <29192>; Mon, 6 Apr 1992 23:01:59 -0700 From: Mark Shirley To: clim@bbn.com Subject: Needed: clim 1.0 code for displaying bitmap files Message-Id: <92Apr6.230159pdt.29192@aramis.parc.xerox.com> Date: Mon, 6 Apr 1992 23:01:52 PDT Does anyone have clim 1.0 code for reading and displaying bitmap files (e.g., xbm files or any of the other standard formats)? Thanks, Mark Shirley   Received: from BBN.COM by LABS-N.BBN.COM id aa29153; 7 Apr 92 11:35 EDT Received: from ftp.ils.nwu.edu by BBN.COM id aa12163; 7 Apr 92 11:31 EDT Received: by aristotle.ils.nwu.edu (4.1/SMI-ILS-1.05) id AA15999; Tue, 7 Apr 92 10:28:22 CDT Date: Tue, 7 Apr 92 10:28:22 CDT From: siegle@aristotle.ils.nwu.edu (Greg Siegle) Message-Id: <9204071528.AA15999@aristotle.ils.nwu.edu> To: clim@BBN.COM, shirley@parc.xerox.com Subject: re: clim 1.0 code for displaying bitmap files Hi again... Let me revise that first function.... It had a spelling error... ; ****************************************************************** ;;; use this to create a lisp vector from an x bitmap file. ;;; Then cut and paste the result into an icon file. (defun load-bmap (fname &aux d) (with-open-file (file fname :direction :input) (dotimes (i 50) (push (read-line file nil 'eof) d)) (setf d (reverse (remove 'eof d)))) (list (third (read-from-string (format nil "(~A)" (string-trim '(#\#) (first d))))) (third (read-from-string (format nil "(~A)" (string-trim '(#\#) (second d))))) (mapcar #'(lambda (s) (read-from-string (format nil "#~A" (string-left-trim '(#\0) (format nil "~A" s))))) (read-from-string (remove #\} (remove #\; (remove #\, (format nil "~A" (cdddr d)))))))) ) ; ****************************************************************** Also, I never mentioned the calling format... Try something like (draw-bitmap *window* 20 20 (load-bmap "mybitmapfile")) -- Greg   Received: from BBN.COM by LABS-N.BBN.COM id aa29064; 7 Apr 92 11:27 EDT Received: from ftp.ils.nwu.edu by BBN.COM id aa11803; 7 Apr 92 11:23 EDT Received: by aristotle.ils.nwu.edu (4.1/SMI-ILS-1.05) id AA15823; Tue, 7 Apr 92 10:20:18 CDT Date: Tue, 7 Apr 92 10:20:18 CDT From: siegle@aristotle.ils.nwu.edu (Greg Siegle) Message-Id: <9204071520.AA15823@aristotle.ils.nwu.edu> To: clim@BBN.COM, shirley@parc.xerox.com Subject: re: clim 1.0 code for displaying bitmap files Hi Mark, Here's a start at some routines to display xbm bitmaps. "load-bmap" takes the filename of an xbm bitmap and spits back a list which draw-bitmap can deal with. Draw bitmap is slow but does the trick. -- Greg ; ****************************************************************** ;;; routines to use bitmap icons ; ****************************************************************** ;;; use this to create a lisp vector from an x bitmap file. ;;; Then cut and paste the result into an icon file. (defun load-bmap (&optional (filname nil) &aux d) (let ((fname filename)) (with-open-file (file fname :direction :input) (dotimes (i 50) (push (read-line file nil 'eof) d)) (setf d (reverse (remove 'eof d))))) (list (third (read-from-string (format nil "(~A)" (string-trim '(#\#) (first d))))) (third (read-from-string (format nil "(~A)" (string-trim '(#\#) (second d))))) (mapcar #'(lambda (s) (read-from-string (format nil "#~A" (string-left-trim '(#\0) (format nil "~A" s))))) (read-from-string (remove #\} (remove #\; (remove #\, (format nil "~A" (cdddr d)))))))) ) (defun draw-bitmap (stream x y2 btmap &optional (ink clim:+black+) (scale 1) &aux y xpos bmap bytes) (setf y y2) (decf y) (setf bmap (copy-tree btmap)) (setf bytes (round (+ 0.5 (/ (car bmap) 8)))) (dotimes (i (round (/ (* 8 (length (third bmap))) (car bmap)))) (incf y) (setf xpos x) (dotimes (j bytes) (let ((curpt (format nil "~8b" (pop (third bmap))))) (unless (or (equal "NIL" curpt) (null curpt)) (setf xpos (+ (* 8 scale) xpos)) (dotimes (k 8) (decf xpos scale) (when (equal #\1 (elt curpt k)) (clim:draw-rectangle* stream xpos (* y scale) (+ xpos scale) (+ scale (* y scale)) :ink ink))) (setf xpos (+ (* 8 scale) xpos)))))))   Received: from BBN.COM by LABS-N.BBN.COM id aa29740; 7 Apr 92 12:24 EDT Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa14416; 7 Apr 92 12:19 EDT Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 427404; 7 Apr 1992 12:09:19-0400 Date: Tue, 7 Apr 1992 12:18-0400 From: Scott McKay Subject: re: clim 1.0 code for displaying bitmap files To: siegle@aristotle.ils.nwu.edu, clim@BBN.COM, shirley@parc.xerox.com In-Reply-To: <9204071520.AA15823@aristotle.ils.nwu.edu> Message-ID: <19920407161838.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 7 Apr 1992 11:20 EDT From: Greg Siegle Hi Mark, Here's a start at some routines to display xbm bitmaps. "load-bmap" takes the filename of an xbm bitmap and spits back a list which draw-bitmap can deal with. Draw bitmap is slow but does the trick. -- Greg Better is to call MAKE-PATTERN on the bitmap to create an ink, using (LIST +BACKGROUND+ +FOREGROUND+) as the pattern's designs. Then just call DRAW-RECTANGLE using that ink. ; ****************************************************************** ;;; routines to use bitmap icons ; ****************************************************************** ;;; use this to create a lisp vector from an x bitmap file. ;;; Then cut and paste the result into an icon file. (defun load-bmap (&optional (filname nil) &aux d) (let ((fname filename)) (with-open-file (file fname :direction :input) (dotimes (i 50) (push (read-line file nil 'eof) d)) (setf d (reverse (remove 'eof d))))) (list (third (read-from-string (format nil "(~A)" (string-trim '(#\#) (first d))))) (third (read-from-string (format nil "(~A)" (string-trim '(#\#) (second d))))) (mapcar #'(lambda (s) (read-from-string (format nil "#~A" (string-left-trim '(#\0) (format nil "~A" s))))) (read-from-string (remove #\} (remove #\; (remove #\, (format nil "~A" (cdddr d)))))))) ) (defun draw-bitmap (stream x y2 btmap &optional (ink clim:+black+) (scale 1) &aux y xpos bmap bytes) (setf y y2) (decf y) (setf bmap (copy-tree btmap)) (setf bytes (round (+ 0.5 (/ (car bmap) 8)))) (dotimes (i (round (/ (* 8 (length (third bmap))) (car bmap)))) (incf y) (setf xpos x) (dotimes (j bytes) (let ((curpt (format nil "~8b" (pop (third bmap))))) (unless (or (equal "NIL" curpt) (null curpt)) (setf xpos (+ (* 8 scale) xpos)) (dotimes (k 8) (decf xpos scale) (when (equal #\1 (elt curpt k)) (clim:draw-rectangle* stream xpos (* y scale) (+ xpos scale) (+ scale (* y scale)) :ink ink))) (setf xpos (+ (* 8 scale) xpos)))))))   Received: from BBN.COM by LABS-N.BBN.COM id aa01939; 7 Apr 92 15:19 EDT Received: by harvard.harvard.edu (5.54/a0.25) (for clim) id AA14227; Tue, 7 Apr 92 14:15:57 EST Received: from gatech.UUCP by gatech.edu (4.1/Gatech-9.1) id AA28480 for bbn!clim; Tue, 7 Apr 92 15:15:28 EDT Received: from gatech.edu by gatech.UUCP (4.1/SMI-4.1) id AA11360; Tue, 7 Apr 92 04:00:51 EDT Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA28465 for clim@bbn; Tue, 7 Apr 92 15:15:00 EDT Received: from pravda.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA09178; Tue, 7 Apr 92 15:14:58 EDT Received: by pravda.cc.gatech.edu (4.1/SMI-4.1) id AA21930; Tue, 7 Apr 92 15:14:56 EDT Date: Tue, 7 Apr 92 15:14:56 EDT From: harvard!gatech!cc!domeshek Message-Id: <9204071914.AA21930@pravda.cc.gatech.edu> To: bbn!clim Subject: OPEN-WINDOW-STREAM + WINDOW-VISIBILITY Sender: harvard!gatech!cc!domeshek Source-Info: From (or Sender) name not authenticated. I am running CLIM on a MacIvory model 3 (Symbolics Genera 8.1) When I use OPEN-WINDOW-STREAM to create a window as a child of my main application-frame's top-level-window, I can use (setf (window-visibility ) t) to make it appear, but (setf (window-visibility ) nil) does not make it go away. However, if I hit after setting the visibility to NIL, then the window disappears. Is this a known bug? Am I using these functions in the wrong way? Any suggestions for a work-around? The reason I want to explicitly create/expose/de-expose my own little windows is to implement custom forms of interaction (for instance, a two-dimensional menu that higlights choices on the axis as you move around the plane). If there are more appropriate ways to establish contexts for such effects then I'd like to hear about them. Thanks, Eric (domeshek@cc.gatech.edu)   Received: from BBN.COM by LABS-N.BBN.COM id aa03036; 7 Apr 92 16:53 EDT Received: from watson.ibm.com by BBN.COM id aa28091; 7 Apr 92 16:45 EDT Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 8084; Tue, 07 Apr 92 16:45:23 EDT Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0" id 2247; Tue, 7 Apr 1992 16:45:21 EDT Received: from fiasco.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2) with TCP; Tue, 07 Apr 92 16:45:19 EDT Received: by fiasco.watson.ibm.com (AIX 3.1/UCB 5.61/920123) id AA42903; Tue, 7 Apr 92 16:45:20 -0400 Message-Id: <9204072045.AA42903@fiasco.watson.ibm.com> To: "William M. York" Cc: clim@BBN.COM X-External-Networks: yes Reply-To: meir@watson.ibm.com Subject: Re: lack of :extend-width arg to clim:formatting-table Date: Tue, 07 Apr 92 16:45:19 -0500 From: "Meir Laker" Date: Fri, 3 Apr 1992 10:50-0800 From: "William M. York" Date: Thu, 2 Apr 1992 14:03 PST From: Scott McKay Date: Thu, 2 Apr 1992 16:47 EST From: "Meir Laker" 3. Is the method I specify above (using a helper stream and bounding rectangle) a reasonable approach if I don't want to hack the clim:formatting-table code at the moment? I would find it easier to extend CLIM:TABLE-FORMATTING, but of course I am familiar with the code. You might find it easier, too, but your approach is not unreasonable if you are willing to pay the performance penalty. You don't really have to modify or extend the table-formatting code to do this (although it would be more efficient if the capability was "built-in" to table formatting). In fact, you can (almost) do it without resorting to any magic CLIM internals at all. The following code shows how you can post-process a formatted table to extend the columns across the full width of the window. It only using one CLIM internal funciton, MAP-OVER-TABLE-COLUMNS. See if it does what you want. [code omitted for brevity] The code extends the columns across the width of the window as advertised. Thank you. Unfortunately, only the first column retains mouseability. (This is true in the table-of-squares example in your code as well as in my own application frame. I tried your example in the CLIM Lisp Listener example code on Genera.) I assume that this is a CLIM bug. Any idea how to fix it? Meir laker   Received: from BBN.COM by LABS-N.BBN.COM id aa03475; 7 Apr 92 17:22 EDT Received: from gatech.edu by BBN.COM id aa29800; 7 Apr 92 17:17 EDT Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA00661 for bbn!clim@BBN.COM; Tue, 7 Apr 92 17:17:33 EDT Received: from pravda.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA12790; Tue, 7 Apr 92 17:17:27 EDT Received: by pravda.cc.gatech.edu (4.1/SMI-4.1) id AA22753; Tue, 7 Apr 92 17:17:25 EDT Date: Tue, 7 Apr 92 17:17:25 EDT From: domeshek@cc.gatech.edu (Eric Domeshek) Message-Id: <9204072117.AA22753@pravda.cc.gatech.edu> To: harvard!sapsucker.scrc.symbolics.com!SWM@gatech.edu Cc: bbn!clim@BBN.COM In-Reply-To: Scott McKay's message of Tue, 7 Apr 1992 16:54-0400 <19920407205409.0.SWM@SUMMER.SCRC.Symbolics.COM> Subject: OPEN-WINDOW-STREAM + WINDOW-VISIBILITY > Date: Tue, 7 Apr 1992 15:14 EDT > From: harvard!gatech!cc!domeshek@BBN.COM > > > I am running CLIM on a MacIvory model 3 (Symbolics Genera 8.1) > > When I use OPEN-WINDOW-STREAM to create a window as a child of my main > application-frame's top-level-window, I can use > > (setf (window-visibility ) t) > > to make it appear, but > > (setf (window-visibility ) nil) > > does not make it go away. However, if I hit after > setting the visibility to NIL, then the window disappears. Is this a known > bug? Am I using these functions in the wrong way? Any suggestions for a > work-around? > > As a workaround, try WINDOW-STACK-ON-BOTTOM to deexpose it. > > The reason I want to explicitly create/expose/de-expose my own little windows > is to implement custom forms of interaction (for instance, a two-dimensional > menu that higlights choices on the axis as you move around the plane). If > there are more appropriate ways to establish contexts for such effects then > I'd like to hear about them. > > Thanks, > > Eric (domeshek@cc.gatech.edu) I just tried WINDOW-STACK-ON-BOTTOM and got the same behavior. The window only disappears after you do .   Received: from BBN.COM by LABS-N.BBN.COM id aa03204; 7 Apr 92 17:00 EDT Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa28730; 7 Apr 92 16:54 EDT Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 427447; 7 Apr 1992 16:44:44-0400 Date: Tue, 7 Apr 1992 16:54-0400 From: Scott McKay Subject: OPEN-WINDOW-STREAM + WINDOW-VISIBILITY To: harvard!gatech!cc!domeshek@BBN.COM, bbn!clim@BBN.COM In-Reply-To: <9204071914.AA21930@pravda.cc.gatech.edu> Message-ID: <19920407205409.0.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 7 Apr 1992 15:14 EDT From: harvard!gatech!cc!domeshek@BBN.COM I am running CLIM on a MacIvory model 3 (Symbolics Genera 8.1) When I use OPEN-WINDOW-STREAM to create a window as a child of my main application-frame's top-level-window, I can use (setf (window-visibility ) t) to make it appear, but (setf (window-visibility ) nil) does not make it go away. However, if I hit after setting the visibility to NIL, then the window disappears. Is this a known bug? Am I using these functions in the wrong way? Any suggestions for a work-around? As a workaround, try WINDOW-STACK-ON-BOTTOM to deexpose it. The reason I want to explicitly create/expose/de-expose my own little windows is to implement custom forms of interaction (for instance, a two-dimensional menu that higlights choices on the axis as you move around the plane). If there are more appropriate ways to establish contexts for such effects then I'd like to hear about them. Thanks, Eric (domeshek@cc.gatech.edu)   Received: from BBN.COM by LABS-N.BBN.COM id aa04292; 7 Apr 92 18:31 EDT Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa01978; 7 Apr 92 18:26 EDT Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 427460; 7 Apr 1992 18:16:41-0400 Date: Tue, 7 Apr 1992 18:26-0400 From: Scott McKay Subject: OPEN-WINDOW-STREAM + WINDOW-VISIBILITY To: domeshek@cc.gatech.edu, harvard!sapsucker.scrc.symbolics.com!SWM@gatech.edu cc: bbn!clim@BBN.COM In-Reply-To: <9204072117.AA22753@pravda.cc.gatech.edu> Message-ID: <19920407222605.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 7 Apr 1992 17:17 EDT From: Eric Domeshek > Date: Tue, 7 Apr 1992 15:14 EDT > From: harvard!gatech!cc!domeshek@BBN.COM > > > I am running CLIM on a MacIvory model 3 (Symbolics Genera 8.1) > > When I use OPEN-WINDOW-STREAM to create a window as a child of my main > application-frame's top-level-window, I can use > > (setf (window-visibility ) t) > > to make it appear, but > > (setf (window-visibility ) nil) > > does not make it go away. However, if I hit after > setting the visibility to NIL, then the window disappears. Is this a known > bug? Am I using these functions in the wrong way? Any suggestions for a > work-around? > > As a workaround, try WINDOW-STACK-ON-BOTTOM to deexpose it. > > The reason I want to explicitly create/expose/de-expose my own little windows > is to implement custom forms of interaction (for instance, a two-dimensional > menu that higlights choices on the axis as you move around the plane). If > there are more appropriate ways to establish contexts for such effects then > I'd like to hear about them. > > Thanks, > > Eric (domeshek@cc.gatech.edu) I just tried WINDOW-STACK-ON-BOTTOM and got the same behavior. The window only disappears after you do . OK. In that case, create the window with :SAVE-UNDER T when you do the OPEN-WINDOW-STREAM.   Received: from BBN.COM by LABS-N.BBN.COM id aa13464; 8 Apr 92 12:13 EDT Received: from ALDERAAN.SCRC.Symbolics.COM by BBN.COM id aa29770; 8 Apr 92 12:08 EDT Received: from JUBJUB.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via INTERNET with SMTP id 501290; 8 Apr 1992 11:26:25-0400 Date: Wed, 8 Apr 1992 11:26-0400 From: John G. Aspinall Subject: Accepting-values To: jd05@gte.com, clim@bbn.com In-Reply-To: <19920408130151.2.JOHND@babar.gte.com> Supersedes: <19920408150446.2.JGA@JUBJUB.SCRC.Symbolics.COM> Comments: Had my coffee and more brain cells are working now. Message-ID: <19920408152638.4.JGA@JUBJUB.SCRC.Symbolics.COM> Date: Wed, 8 Apr 1992 09:01 EDT From: John Doleac [...] I tried John's sandwich example with a write-caption-pane in it. Write-caption-pane in an accepting-values works in MCL and Allegro, but causes a sheet lock on Symbolics: Forget my earlier explanation. I was confused about what you were trying to do. Basically, you are asking Genera's crufty old window system to do something that it isn't up to. Namely: write out on a partially obscured window. When you pop-up the a-v window, it pops up on top of your application frame. You can't do output to the application frame's panes until you've finished with the a-v pane. Younger, more sprightly, window systems can do this. Assuming this is an experiment and not a type of interaction you're actually trying to achieve, I'll leave it at that. If you're using pop-up a-v's to change application state, that's fine. Just don't try to reflect the new state in your application panes until the a-v dialog is finished. Even in a modern window system, remember that code inside the pop-up a-v runs again and again and again...   Received: from BBN.COM by LABS-N.BBN.COM id aa15132; 8 Apr 92 14:20 EDT Received: from hyper.franz.com by BBN.COM id aa05120; 8 Apr 92 14:15 EDT Return-Path: Received: from sparky.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA08287; Wed, 8 Apr 92 11:13:16 PDT Received: by sparky.Franz.COM (4.1/FI-2.0) id AA06917; Wed, 8 Apr 92 11:11:44 PDT Message-Id: <9204081811.AA06917@sparky.Franz.COM> To: curt@eraserhead.Jpl.Nasa.Gov Class: bh Bh-Id: spr5329 Bh: append spr5329 expire Cc: bugs@Franz.COM, clim@bbn.com Subject: Re: [spr5329] X-Window interaction with CLIM Date: Wed, 08 Apr 92 11:11:44 -0700 From: John Irwin > Your explanation makes enough sense that I understand what you are saying > (not being a X-Window "weenie"). I am looking forward to CLIM 2.0. As > a quickie side question, is your Composer product's display interface being > converted over to CLIM from Common-Windows for your new releases of Allegro? Yes, this is planned. However the next full release of Allegro is still some time away (4.1 just came out last month! :-), so we're not sure exactly when the new Composer will debut. -- jdi PS: I have discovered that it is quite easy to "compress" the Expose events in CLIM 2.0, so even in the absence of an X server that supports backing stores, CLIM 2.0 should have near-optimal Expose behaviour.   Received: from BBN.COM by LABS-N.BBN.COM id aa17388; 8 Apr 92 17:38 EDT Received: from gatech.edu by BBN.COM id aa15658; 8 Apr 92 17:33 EDT Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA16519 for bbn!clim@BBN.COM; Wed, 8 Apr 92 17:33:45 EDT Received: from pravda.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA29193; Wed, 8 Apr 92 17:33:38 EDT Received: by pravda.cc.gatech.edu (4.1/SMI-4.1) id AA28495; Wed, 8 Apr 92 17:33:36 EDT Date: Wed, 8 Apr 92 17:33:36 EDT From: domeshek@cc.gatech.edu (Eric Domeshek) Message-Id: <9204082133.AA28495@pravda.cc.gatech.edu> To: SWM@SAPSUCKER.SCRC.Symbolics.COM Cc: harvard!sapsucker.scrc.symbolics.com!SWM@gatech.edu, bbn!clim@BBN.COM In-Reply-To: Scott McKay's message of Tue, 7 Apr 1992 18:26-0400 <19920407222605.3.SWM@SUMMER.SCRC.Symbolics.COM> Subject: OPEN-WINDOW-STREAM + WINDOW-VISIBILITY For those who are interested in the solution to the problem I reported: On a MacIvory-3 (Genera 8.1) windows created by direct calls to OPEN-WINDOW-STREAM do not disappear until you hit the key sequence, even after you setf their WINDOW-VISIBILITY to nil (or after you try to WINDOW-STACK-ON-BOTTOM) Scott's second suggestion turned out to work. > OK. In that case, create the window with :SAVE-UNDER T when you do the > OPEN-WINDOW-STREAM. I've now got things working the way I want them. Thanks Scott. -Eric   Received: from BBN.COM by LABS-N.BBN.COM id aa25428; 9 Apr 92 9:42 EDT Received: from gatech.edu by BBN.COM id aa04895; 9 Apr 92 9:24 EDT Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA24361 for clim@bbn.com; Thu, 9 Apr 92 09:24:47 EDT Received: from pravda.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA03671; Thu, 9 Apr 92 09:24:45 EDT Received: from kant.gatech.edu (kant.cc.gatech.edu) by pravda.cc.gatech.edu (4.1/SMI-4.1) id AA29705; Thu, 9 Apr 92 09:24:42 EDT Date: Thu, 9 Apr 1992 09:24-0400 From: Richard Billington Subject: exposing windows ... To: clim@bbn.com Message-Id: <19920409132423.0.BUFF@kant.gatech.edu> There are two "idioms" for exposing a window: (window-expose ) and (setf (window-visibility ) t). I'm specializing a CLIM window, and one of the things I want to do is add some behaviour so that when the window is exposed that added behaviour happens. So, if I want to specialize window exposure behaviour (at least for exposures generated from within CLIM), there's no way of doing so that covers both idioms that's documented. If my CLIM window is exposed by a native window system operation (killing a covering window, or selecting it with a mouse click), is it possible to specialize the exposure behaviour for this type of event as well?   Received: from BBN.COM by LABS-N.BBN.COM id aa26267; 9 Apr 92 10:53 EDT Received: from fenrix.si.no by BBN.COM id aa08910; 9 Apr 92 10:48 EDT Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.22) id AA16052; Thu, 9 Apr 92 16:47:03 +0200 Date: Thu, 9 Apr 92 16:47:03 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9204091446.AAmonsun00956@D> To: clim@bbn.com Subject: commands & tracking pointers I have two problems (using CLIM 1.0 and MCL 2.0 (both beta) but the problems are of general nature): 1. I have an interaction pane for inputing commands. I also present several command-name in another pane, so the user has something to click on instead of always having to type command-names. When the user clicks on a command-name, the name is automatically put into the input buffer, which is good. But the name isn't accepted yet, the user has to type to be able to click on objects for the arguments. I may be because the same objects has command-translators. Anyway, I want the user to be able to enter arguments at once without having to type first. How? (Any methods I could write to get control at the right spot?) 2. I want to track the pointer with tracking-pointers in a window (pane). But this blocks the ordinary command-loop. How can I make the command loop use the other panes and function as normal and my tracking-pointer only get control when the cursor is inside my window? Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.BBN.COM id aa26139; 9 Apr 92 10:37 EDT Received: from SAPSUCKER.SCRC.Symbolics.COM by BBN.COM id aa08233; 9 Apr 92 10:34 EDT Received: from SUMMER.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 427600; 9 Apr 1992 10:23:57-0400 Date: Thu, 9 Apr 1992 10:33-0400 From: Scott McKay Subject: exposing windows ... To: buff@cc.gatech.edu, clim@BBN.COM In-Reply-To: <19920409132423.0.BUFF@kant.gatech.edu> Message-ID: <19920409143312.7.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 9 Apr 1992 09:24 EDT From: Richard Billington There are two "idioms" for exposing a window: (window-expose ) and (setf (window-visibility ) t). I'm specializing a CLIM window, and one of the things I want to do is add some behaviour so that when the window is exposed that added behaviour happens. So, if I want to specialize window exposure behaviour (at least for exposures generated from within CLIM), there's no way of doing so that covers both idioms that's documented. If my CLIM window is exposed by a native window system operation (killing a covering window, or selecting it with a mouse click), is it possible to specialize the exposure behaviour for this type of event as well? Specialize (SETF WINDOW-VISIBILITY). WINDOW-EXPOSE just calls it; WINDOW-EXPOSE should really have been flushed from CLIM a while back.   Received: from BBN.COM by LABS-N.BBN.COM id aa10649; 10 Apr 92 11:59 EDT Received: from cs.utexas.edu by BBN.COM id aa27555; 10 Apr 92 11:54 EDT Received: from sage.cs.utexas.edu by cs.utexas.edu (5.64/1.122) with SMTP id AA05576; Fri, 10 Apr 92 10:54:06 -0500 Received: by sage.cs.utexas.edu (5.64/Client) id AA14169; Fri, 10 Apr 92 10:54:02 -0500 Message-Id: <9204101554.AA14169@sage.cs.utexas.edu> From: eilerts@cs.utexas.edu (Erik Eilerts) Date: Fri, 10 Apr 1992 10:54:01 -0500 X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: clim@bbn.com Subject: More about OPEN-WINDOW-STREAM I'm using CLIM 1.0 beta on a Sun 4 and the problem that I've been having is that when I call the following code: (setf root-window (clim:open-window-stream :parent *clim-root* :save-under t :left 40 :top 80 :width 200 :height 200)) (clim:window-expose root-window) (clim:window-visibility root-window) is that the window appears in an outline and I have to click the mouse at the place that I want to put the window on the screen. What I'd rather have happen is that the window appears on the screen with its upper left corner appearing at the specified (left, top) coordinate. Does anyone know if this is possible, or is it because I have 1.0 beta? Also, I'm using Mit XR5 with the twm window manager. Thanks, Erik Eilerts University of Texas at Austin eilerts@cs.utexas.edu   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa12855; 10 Apr 92 14:50 EDT Received: by KARIBA.BBN.COM id ab15241; 10 Apr 92 14:37 EDT To: Erik Eilerts cc: clim@BBN.COM Subject: Re: More about OPEN-WINDOW-STREAM In-reply-to: Your message of Fri, 10 Apr 92 10:54:01 -0500. <9204101554.AA14169@sage.cs.utexas.edu> Date: Fri, 10 Apr 92 14:34:38 -0400 From: kanderso@BBN.COM From: Erik Eilerts Date: Fri, 10 Apr 1992 10:54:01 -0500 X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: clim@BBN.COM Subject: More about OPEN-WINDOW-STREAM I'm using CLIM 1.0 beta on a Sun 4 and the problem that I've been having is that when I call the following code: (setf root-window (clim:open-window-stream :parent *clim-root* :save-under t :left 40 :top 80 :width 200 :height 200)) (clim:window-expose root-window) (clim:window-visibility root-window) is that the window appears in an outline and I have to click the mouse at the place that I want to put the window on the screen. What I'd rather have happen is that the window appears on the screen with its upper left corner appearing at the specified (left, top) coordinate. Does anyone know if this is possible, or is it because I have 1.0 beta? Also, I'm using Mit XR5 with the twm window manager. I believe you can set up your .twmrc file to do this. Here is the relevant portion of my .twmrc file: # UsePPosition string # This variable specifies whether or not twm should # honor program-requested locations (given by the PPo- # sition flag in the WM_NORMAL_HINTS property) in the # absence of a user-specified position. The argument # string may have one of three values: "off" (the # default) indicating that twm should ignore the # program-supplied position, "on" indicating that the # position should be used, and "non-zero" indicating # that the position should used if it is other than # (0,0). The latter option is for working around a # bug in older toolkits. UsePPosition "on" # RandomPlacement # This variable indicates that windows with no speci- # fied geometry should should be placed in a pseudo- # random location instead of having the user drag out # an outline. RandomPlacement   Received: from BBN.COM by LABS-N.BBN.COM id aa13902; 10 Apr 92 15:49 EDT Received: from cs.utexas.edu by BBN.COM id aa09457; 10 Apr 92 15:42 EDT Received: from sage.cs.utexas.edu by cs.utexas.edu (5.64/1.122) with SMTP id AA29719; Fri, 10 Apr 92 14:42:20 -0500 Received: by sage.cs.utexas.edu (5.64/Client) id AA14676; Fri, 10 Apr 92 14:42:15 -0500 Message-Id: <9204101942.AA14676@sage.cs.utexas.edu> From: eilerts@cs.utexas.edu (Erik Eilerts) Date: Fri, 10 Apr 1992 14:42:14 -0500 X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: clim@bbn.com Subject: RE: More about OPEN-WINDOW-STREAM From: Erik Eilerts Subject: More about OPEN-WINDOW-STREAM I'm using CLIM 1.0 beta on a Sun 4 and the problem that I've been having is that when I call the following code: (setf root-window (clim:open-window-stream :parent *clim-root* :save-under t :left 40 :top 80 :width 200 :height 200)) (clim:window-expose root-window) (clim:window-visibility root-window) is that the window appears in an outline and I have to click the mouse at the place that I want to put the window on the screen. What I'd rather have happen is that the window appears on the screen with its upper left corner appearing at the specified (left, top) coordinate. Does anyone know if this is possible, or is it because I have 1.0 beta? Also, I'm using Mit XR5 with the twm window manager. From kanderso@BBN.COM Fri Apr 10 13:47:02 1992 I believe you can set up your .twmrc file to do this. Here is the relevant portion of my .twmrc file: # UsePPosition string # This variable specifies whether or not twm should # honor program-requested locations (given by the PPo- # sition flag in the WM_NORMAL_HINTS property) in the # absence of a user-specified position. The argument # string may have one of three values: "off" (the # default) indicating that twm should ignore the # program-supplied position, "on" indicating that the # position should be used, and "non-zero" indicating # that the position should used if it is other than # (0,0). The latter option is for working around a # bug in older toolkits. UsePPosition "on" # RandomPlacement # This variable indicates that windows with no speci- # fied geometry should should be placed in a pseudo- # random location instead of having the user drag out # an outline. RandomPlacement From: Erik Eilerts I've tried this, but it has the undesirable effect that the window appears in a random location. I will be using this window like a menu, so I'll need to be able to position the window under the current location of the mouse (I also don't what to have to move the mouse to the location that the window appeared at). Thanks, Erik Eilerts eilerts@cs.utexas.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa13583; 10 Apr 92 15:35 EDT Received: from MCC.COM by BBN.COM id aa08240; 10 Apr 92 15:23 EDT Received: from hippo.aca.mcc.com by MCC.COM with TCP; Fri, 10 Apr 92 14:23:25 CDT Posted-Date: Fri, 10 Apr 1992 14:23-0500 Received: by hippo.aca.mcc.com (5.57/ACTv4.1i) id AA01486; Fri, 10 Apr 92 14:23:16 -0500 Date: Fri, 10 Apr 1992 14:23-0500 From: David Gadbois Subject: More about OPEN-WINDOW-STREAM To: Erik Eilerts Cc: clim@BBN.COM In-Reply-To: <9204101554.AA14169@sage.cs.utexas.edu> Message-Id: <19920410192319.0.GADBOIS@CLIO.ACA.MCC.COM> Date: Fri, 10 Apr 1992 10:54 CDT From: Erik Eilerts I'm using CLIM 1.0 beta on a Sun 4 and the problem that I've been having is that when I call the following code: (setf root-window (clim:open-window-stream :parent *clim-root* :save-under t :left 40 :top 80 :width 200 :height 200)) (clim:window-expose root-window) (clim:window-visibility root-window) is that the window appears in an outline and I have to click the mouse at the place that I want to put the window on the screen. What I'd rather have happen is that the window appears on the screen with its upper left corner appearing at the specified (left, top) coordinate. Does anyone know if this is possible, or is it because I have 1.0 beta? Also, I'm using Mit XR5 with the twm window manager. The window manager has final say over where and the window is placed and sized. Fortunately, in twm you can set the variable RandomPlacement to get the behavior desired behavior. (Erik -- Take a look at /u/gadbois/.twmrc for an example of this.) We have had to learn the hard way what different window managers can get away with. It would be nice for the X ports of CLIM to have some documentation to explain the theory on window managers and their interaction with CLIM. Also, note you can (currently) get into trouble in Lucid if you use a single root window for multiple frames. X events for the root can be snagged by any frame's process without regard which frame should "own" the event. The workaround is to open a new root window for each frame. --David Gadbois   Received: from BBN.COM by LABS-N.BBN.COM id aa15441; 10 Apr 92 17:29 EDT Received: from Sunset.AI.SRI.COM by BBN.COM id aa17352; 10 Apr 92 17:25 EDT Received: from Rockaway.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA28858 for clim@bbn.com; Fri, 10 Apr 92 14:25:59 PDT Received: by Rockaway.AI.SRI.COM (4.1/SMI-4.1) id AA12036 for clim@bbn.com; Fri, 10 Apr 92 14:25:59 PDT Date: Fri, 10 Apr 92 14:25:58 PDT From: Peter Karp To: clim@bbn.com Subject: waterfall menus Message-Id: I also wonder if there are plans to implement waterfall menus in CLIM. Currently if you define nested menus in CLIM, the implementation simply gives you sequential popups rather than a waterfall that you can back out of. Peter   Received: from BBN.COM by LABS-N.BBN.COM id aa15365; 10 Apr 92 17:19 EDT Received: from Sunset.AI.SRI.COM by BBN.COM id aa16914; 10 Apr 92 17:14 EDT Received: from Rockaway.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA28434 for clim@BBN.COM; Fri, 10 Apr 92 14:14:38 PDT Received: by Rockaway.AI.SRI.COM (4.1/SMI-4.1) id AA12022 for clim@BBN.COM; Fri, 10 Apr 92 14:14:38 PDT Date: Fri, 10 Apr 92 14:14:37 PDT From: Peter Karp Cc: clim@BBN.COM Subject: Re: More about OPEN-WINDOW-STREAM In-Reply-To: Your message of Fri, 10 Apr 1992 14:23-0500 Message-Id: I for one wish that I did not have to deal with the window managers at all. I want to be able to specify at the CLIM level where and how a window appears, both for application windows and popup menus. CLIM should insulate us from the variability at the window manager level. If window placement can be set by the user interactively, randomly set, or determined by the application, these options should all exist at the CLIM level so the programmer can specify exactly what they want in one way that ensures that the behavior of the application does not change when it runs under a different window manager. For example, I use olwm and I cannot see any of its options that correspond to the suggested mod to .twmrc. I don't want to have to waste my time dealing with the window managers. Is this possible technically? How about adding this to CLIM? Peter   Received: from BBN.COM by LABS-N.BBN.COM id aa22056; 11 Apr 92 11:40 EDT Received: from crdgw1.GE.COM by BBN.COM id aa05991; 11 Apr 92 11:36 EDT Received: by crdgw1.ge.com (5.57/GE 1.137) id AA12995; Sat, 11 Apr 92 11:32:02 EDT Received: from procyon.crd.Ge.Com by sol.crd.Ge.Com (4.0/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA20184; Sat, 11 Apr 92 11:32:22 EDT Date: Sat, 11 Apr 92 11:32:22 EDT From: halvers@sol.crd.ge.com (peter c halverson) Message-Id: <9204111532.AA20184@sol.crd.Ge.Com> Received: by procyon.crd.Ge.Com (4.1/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA01028; Sat, 11 Apr 92 11:32:19 EDT To: clim@bbn.com In-Reply-To: Peter Karp's message of Fri, 10 Apr 92 14:14:37 PDT Subject: Re: More about OPEN-WINDOW-STREAM Reply-To: Pete Halverson Sun-Distance: 149966055 kilometers (1.002 AU) In , Peter Karp writes: > > I for one wish that I did not have to deal with the window managers at > all. I want to be able to specify at the CLIM level where and how a > window appears, both for application windows and popup menus. CLIM > should insulate us from the variability at the window manager level. > If window placement can be set by the user interactively, randomly > set, or determined by the application, these options should all exist > at the CLIM level so the programmer can specify exactly what they want > in one way that ensures that the behavior of the application does not > change when it runs under a different window manager. For example, I > use olwm and I cannot see any of its options that correspond to the > suggested mod to .twmrc. I don't want to have to waste my time > dealing with the window managers. > > Is this possible technically? How about adding this to CLIM? Conversely, I for one hope that I never have to deal with "rogue" X applications (like this would allow) at all. The whole purpose of a window manager is to handle screen real estate, insulating us from the variability of different applications by providing cross-application consistency about where and how windows appear, both application windows and popup menus. As a CLIM programmer, I shouldn't have to worry about whether window placement is to be set by the the user interactively, randomly set, or determined by my application. By not forcing this at the CLIM level, this ensures that the behavior of the application will change according to the user's preferences when it runs under a different window manager. In short, I don't want to have to waste my time dealing with issues that are the responsibility of window managers. Please don't add this to CLIM. Pete   Received: from BBN.COM by LABS-N.BBN.COM id aa28715; 12 Apr 92 9:00 EDT Received: from fenrix.si.no by BBN.COM id aa05391; 12 Apr 92 8:56 EDT Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.22) id AA24155; Sun, 12 Apr 92 14:54:47 +0200 Date: Sun, 12 Apr 92 14:54:47 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9204121254.AAmonsun01629@D> To: clim@bbn.com Subject: button-release Hi, I'm still using CLIM 1.0 with MCL 2.0 (both beta). I'm tracking the pointer with clim:tracking-pointer and don't seem to get the :pointer-button-release event, i.e. the :pointer-button-release clause is never run. Is this a known bug, is there a known way around or a bug-fix? Is there a trick I have forgotten or should I look again for a stupid bug in my own code? If there is a bug in CLIM so that I cant't get button-release events, I would *very* much appreciate a bug fix, by mail or an ftp-address. Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.BBN.COM id aa09575; 13 Apr 92 11:27 EDT Received: from ALDERAAN.SCRC.Symbolics.COM by BBN.COM id aa15013; 13 Apr 92 10:58 EDT Received: from SUMMER.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via INTERNET with SMTP id 501568; 13 Apr 1992 10:58:06-0400 Date: Mon, 13 Apr 1992 10:58-0400 From: Scott McKay Subject: waterfall menus To: pkarp@ai.sri.com, clim@BBN.COM In-Reply-To: Message-ID: <19920413145812.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 10 Apr 1992 17:25 EDT From: Peter Karp I also wonder if there are plans to implement waterfall menus in CLIM. Currently if you define nested menus in CLIM, the implementation simply gives you sequential popups rather than a waterfall that you can back out of. This type of menu is really a function of the host window system that CLIM is running on. As such, CLIM 2.0 will implement such menus if the host window system provides them, otherwise not. There is an undocumented function called CLIM:HIERARCHICAL-MENU-CHOOSE that may do what you want, but there is no guarantee that it will be in CLIM 2.0. The important thing to keep in mind is that, for the most part, CLIM is not in the business of implementing look and feel. CLIM is intended to integrate with the look and feel provided by the host. This goal will be much better met by CLIM 2.0 than it is by CLIM 1.0.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa10550; 13 Apr 92 12:34 EDT Received: by KARIBA.BBN.COM id aa00395; 13 Apr 92 12:21 EDT To: clim@BBN.COM Subject: Re: More about OPEN-WINDOW-STREAM In-reply-to: Your message of Sat, 11 Apr 92 11:32:22 -0400. <9204111532.AA20184@sol.crd.Ge.Com> Date: Mon, 13 Apr 92 12:16:10 -0400 Message-ID: <7659.703181770@bbn.com> From: Jeff Morrill Date: Sat, 11 Apr 92 11:32:22 EDT From: peter c halverson To: clim@BBN.COM Subject: Re: More about OPEN-WINDOW-STREAM Reply-To: Pete Halverson Sun-Distance: 149966055 kilometers (1.002 AU) In , Peter Karp writes: > > I for one wish that I did not have to deal with the window managers at > all. I want to be able to specify at the CLIM level where and how a > window appears, both for application windows and popup menus. ... I don't want to have to waste my time > dealing with the window managers. Conversely, I for one hope that I never have to deal with "rogue" X applications (like this would allow) at all. The whole purpose of a window manager is to handle screen real estate, insulating us from the variability of different applications by providing cross-application consistency about where and how windows appear, both application windows and popup menus. In short, I don't want to have to waste my time dealing with issues that are the responsibility of window managers. Please don't add this to CLIM. Pete I agree with the latter in the sense that CLIM is essentially a portable front-end to the myriad of window managers that are available. But the issue as stated above is between two religions in the software development community: 1. The look and feel of a program should not depend on the window manager underneath it. Microsoft Word, for example. 2. The look and feel of all programs should look the same for a particular window manager. Motif, for example. I think both goals must be satisfied to some degree. The one that is more important depends on whether your users stick to one application (but may use multiple platforms) or stick to one platform (but use multiple applications). I cannot say which is right, but in practice the latter goal comes almost for free, and the former at great expense. jeff morrill   Received: from BBN.COM by LABS-N.BBN.COM id aa10723; 13 Apr 92 12:50 EDT Received: from Sunset.AI.SRI.COM by BBN.COM id aa20018; 13 Apr 92 12:46 EDT Received: from Rockaway.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA28645 for clim@BBN.COM; Mon, 13 Apr 92 09:46:50 PDT Received: by Rockaway.AI.SRI.COM (4.1/SMI-4.1) id AA16630 for clim@BBN.COM; Mon, 13 Apr 92 09:46:49 PDT Date: Mon, 13 Apr 92 9:46:48 PDT From: Peter Karp Cc: clim@BBN.COM Subject: Re: More about OPEN-WINDOW-STREAM In-Reply-To: Your message of Mon, 13 Apr 92 12:16:10 -0400 Message-Id: Jeff Morrill defined the issue very clearly. Let me note that there is a compromise that may satisfy both Peters: By default a CLIM application should take on the behavior prescribed by the window manager. But in some cases the application programmer should be able to override those defaults. There are certainly going to be cases where the application programmer has more specific knowledge of the detailed needs of his application than did the person configuring the window manager for all applications. Another reason to allow control at the CLIM level is that some window managers apparently do not let the user control some of the behaviors we have been discussing. For example, I use OLWM, and I can find nothing in its documentation that allows me to configure the manner in which popup windows are positioned. Peter   Received: from BBN.COM by LABS-N.BBN.COM id aa20024; 14 Apr 92 4:08 EDT Received: from fenrix.si.no by BBN.COM id aa17203; 14 Apr 92 4:04 EDT Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.22) id AA24359; Tue, 14 Apr 92 10:03:30 +0200 Date: Tue, 14 Apr 92 10:03:30 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9204140802.AAmonsun02472@D> Sender: Hallvard.Tretteberg@si.no To: clim@bbn.com Subject: button-release Hi, I'm still using CLIM 1.0 with MCL 2.0 (both beta). I'm tracking the pointer with clim:tracking-pointer and don't seem to get the :pointer-button-release event, i.e. the :pointer-button-release clause is never run. Is this a known bug, is there a known way around or a bug-fix? Is there a trick I have forgotten or should I look again for a stupid bug in my own code? If there is a bug in CLIM so that I cant't get button-release events, I would *very* much appreciate a bug fix, by mail or an ftp-address. Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.BBN.COM id aa22130; 16 Apr 92 11:12 EDT Received: from jazz.al.alcoa.com by BBN.COM id aa10033; 16 Apr 92 11:07 EDT Received: from HUCKLEBERRY-HOUND.al.alcoa.com by jazz.al.alcoa.com via CHAOS with CHAOS-MAIL id 38947; 16 Apr 92 11:07:35 EDT Date: Thu, 16 Apr 1992 11:05-0400 From: Peter Van Sickel Subject: LUV '92 Update To: slug@ai.sri.com, common-lisp@mcc.com, clim@bbn.com Message-ID: <19920416150507.1.PVS@HUCKLEBERRY-HOUND.al.alcoa.com> LUV '92 Update Michael Stock, President and CEO of Artificial Intelligence Technologies (AIT) will be the keynote speaker at the the Second International Lisp Users and Vendors Conference (LUV-92), to be held August 10-14, 1992 in San Diego, CA. The theme of the conference will be "Delivering Business Success with Lisp", and Mr. Stock will explain why AIT is committed to using Common Lisp and not switching to C++. For a recent interview with Mr. Stock, see the March/April, 1992 issue of "PC AI", and for a brief desciption of AIT see the article "Lisp: The Great Contender" in the January issue of "AI Expert". Richard P. Gabriel, Chief Technical Officer of Lucid, Inc., will deliver the closing address at LUV-92. Mr. Gabriel is the author of the book "Performance and Evaluation of Lisp Systems," which publicized the well-known "Gabriel Benchmarks". More recently, he has been active on the ANSI and ISO Lisp standards committees, and was one of the designers of CLOS. Mr. Gabriel coauthored the article "CLOS: Integrating Object-Oriented and Functional Programming" in the September, 1991 special issue on Lisp of "Communications of the ACM" and he authored the controversial article "LISP: good news, bad news, how to win big." in the June 1991 issue of AI Expert. Patrick Kerpan of Swiss Bank O'Connor and Skip Egdorf of Los Alamos National Laboratories will also be speaking. Mr. Kerpan will speak on his experiences delivering Lisp based systems that support the financial industry. Mr. Egdorf will speak on delivering a portable discrete event simulation system using Common Lisp, CLOS and CLIM that is used in the nuclear power industry. If you would like to present a paper get a copy of the LUV-92 conference brochure from your favorite Lisp vendor and check out the call for papers there. Hurry, the deadline for papers is June 1. The first two days (August 10-11) of the conference will be tutorials offered by outstanding instructors: New Features of ANSI Standard Common Lisp (Lois Wolf, Franz, Inc.) CLOS I&II (Allan Wechsler, Symbolics, Inc.) Porting Lisp Applications to Stock Hardware (Jim Veitch, Franz, Inc., John Aspinall, Symbolics, Inc.) Interfacing Lisp with Other Languages (Charlie Cox, Franz, Inc.) Developing Applications for Business (Dean Scharnhorst, Symbolics, Inc.) Macrology (Robert Kerns, Digital Equipment Corp.) Advanced CLOS (Jon L. White, Lucid, Inc.) Instroduction to CLIM (Lois Wolf, Franz, Inc.) Advanced CLIM (John Aspinall and Scott McKay, Symbolics, Inc.) Interfacing Lisp to SQL Databases (Cris Kobryn, Harlequin, Ltd.) Elements of Good Lisp Programming Style (Peter Norvig, Sun Microsystems, Inc.) Ask your favorite Lisp vendor representative for a conference brochure that describes the conference in more detail and contains registration information. Or send your name and address via e-mail to Peter Van Sickel at pvs@al.alcoa.com. This will be forwarded to Laura Lotz of An Event to Remember and she will send you a registration form. Or you can contact Laura Lotz directly at (215)651-2990 Special Note to full-time students: We are searching for up to several full-time students to help at the registration desk, run errands, etc. in exchange for a waiver of all tutorial and conference fees (a $300 value). please contact the conference chairman at if you wish to apply. The deadline for applications is May 15th.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa07265; 17 Apr 92 11:36 EDT Received: by KARIBA.BBN.COM id aa06855; 17 Apr 92 10:49 EDT To: clim@BBN.COM cc: jmorrill@BBN.COM Subject: CLIM windows and xlib resources Date: Fri, 17 Apr 92 10:46:07 -0400 Message-ID: <10095.703521967@bbn.com> From: Jeff Morrill Those of you using CLIM 1.1 under X Windows may be interested in this. After making a frame but before calling clim:run-frame-top-level to expose it, it is useful to perform the following operation on the frame: #+xlib (let ((xwin (slot-value (clim:frame-top-level-window frame) 'clim::window))) (xlib:set-wm-class xwin "clim" "clim")) 1. The UNIX command xprop may finally be used to see that indeed it is a clim window. 2. One may add lines to a resources file (such as .Xdefaults) to control what the window manager does with clim windows: olwm.MinimalDecor: clim 3. Having a WM_CLASS attribute, it is easy to write standard XLIB calls in C that do interesting things to CLIM windows. We have one that changes the mouse cursor of clim windows to a wristwatch during GC operations. Enjoy. jeff morrill p.s. Can the CLIM developers add this in for the next release? Please?   Received: from BBN.COM by LABS-N.BBN.COM id aa04438; 22 Apr 92 12:47 EDT Received: from usc.edu by BBN.COM id aa07557; 22 Apr 92 12:36 EDT Received: from hto-d.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA07561; Wed, 22 Apr 92 09:36:36 PDT Received: by hto-d.usc.edu (4.1/SMI-3.0DEV3) id AA23737; Wed, 22 Apr 92 09:36:37 PDT Date: Wed, 22 Apr 92 09:36:37 PDT From: nicolas%hto-d.usc.edu@usc.edu (Nicolas Rouquette) Message-Id: <9204221636.AA23737@hto-d.usc.edu> To: clim@bbn.com Subject: Running CLIM on Lucid on Sparc system Can you send me some info about getting clim for a sparc machine? I run lucid 4.0.2 -- Nicolas.   Received: from BBN.COM by LABS-N.BBN.COM id aa05312; 22 Apr 92 13:43 EDT Received: from lucid.com by BBN.COM id aa10009; 22 Apr 92 13:36 EDT Received: from kuwait.lucid ([192.31.212.118]) by heavens-gate.lucid.com id AA09519g; Wed, 22 Apr 92 10:29:55 PDT Received: by kuwait.lucid (4.1/SMI-4.1) id AA03866; Wed, 22 Apr 92 10:36:38 PDT Date: Wed, 22 Apr 92 10:36:38 PDT From: kern%kuwait@lucid.com (John Kern) Message-Id: <9204221736.AA03866@kuwait.lucid> To: nicolas%hto-d.usc.edu@usc.edu Cc: clim@BBN.COM In-Reply-To: Nicolas Rouquette's message of Wed, 22 Apr 92 09:36:37 PDT <9204221636.AA23737@hto-d.usc.edu> Subject: Running CLIM on Lucid on Sparc system Reply-To: kern@lucid.com Howdy Mr. Rouquette, >Can you send me some info about getting clim for a sparc machine? >I run lucid 4.0.2 -- Nicolas. I have forwarded your message to a Lucid Sales Representative who will be contacting you. Sincerely, John S. Kern Lucid, Inc. Customer Support   Received: from BBN.COM by LABS-N.BBN.COM id aa10341; 22 Apr 92 18:25 EDT Received: from eola.cs.ucf.edu by BBN.COM id aa24890; 22 Apr 92 18:21 EDT Received: by eola.cs.ucf.edu (5.61/1.34) id AA06343; Wed, 22 Apr 92 18:18:11 EDT Date: Wed, 22 Apr 92 18:18:11 EDT From: hull@eola.cs.ucf.edu (Richard Hull) Message-Id: <9204222218.AA06343@eola.cs.ucf.edu> To: clim@BBN.COM Subject: FOR SALE: Reasonably Priced Symbolics 3653 We are selling a Symbolics 3653. The 3653 is a 3650 cabinet that contains 3 cpu cards and 3 harddrive cards. These cards are connected to three separate Symbolics terminals. So each terminal can be logically seen as its own machine, but there really is only one cabinet. Each of the three has 9 Mbytes of memory and a 380 Mbyte ESDI hard drive. The system also has an Ethernet card for attaching one of the three (which acts as the file server), to an Ethernet network. Through the server, each terminal may access the network. The terminals are the standard Symbolics grayscale large screen terminals with keyboard and mouse. We are currently running Genera 8.0 on two of the machines and 8.1.1 (with CLIM) on the other. The system also includes a Symbolics tape drive. This system is in excellent condition. We are looking for an offer in the mid to upper 30's, but price is negotiable. Anyone interested should direct inquiry to: Richard Hull Artificial Intelligence Lab University of Central Florida Orlando, FL 32816 (407) 823-3081 (407) 823-2341 hull@cs.ucf.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa17738; 23 Apr 92 3:43 EDT Received: from fenrix.si.no by BBN.COM id aa02750; 23 Apr 92 3:39 EDT Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.22) id AA04361; Thu, 23 Apr 92 09:38:17 +0200 Date: Thu, 23 Apr 92 09:38:17 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9204230736.AAmonsun04325@D> Sender: Hallvard.Tretteberg@si.no To: clim@bbn.com Subject: button-release Hi, I'm still using CLIM 1.0 with MCL 2.0 (both beta). I'm tracking the pointer with clim:tracking-pointer and don't seem to get the :pointer-button-release event, i.e. the :pointer-button-release clause is never run. Is this a known bug, is there a known way around or a bug-fix? Is there a trick I have forgotten or should I look again for a stupid bug in my own code? If there is a bug in CLIM so that I cant't get button-release events, I would *very* much appreciate a bug fix, by mail or an ftp-address. Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.BBN.COM id aa02948; 23 Apr 92 17:39 EDT Received: from FUJI.ILA.COM by BBN.COM id aa06558; 23 Apr 92 17:34 EDT Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 310026; 23 Apr 92 17:30:17 EDT Date: Thu, 23 Apr 1992 13:05-0700 From: William M. York Subject: button-release To: Hallvard.Tretteberg@si.no, clim@bbn.com In-Reply-To: <9204230736.AAmonsun04325@D> Message-ID: <19920423200548.8.YORK@CHUCK-JONES.west.dialnet.ila.com> Date: Thu, 23 Apr 1992 00:38 PDT From: Hallvard.Tretteberg@si.no Hi, I'm still using CLIM 1.0 with MCL 2.0 (both beta). I'm tracking the pointer with clim:tracking-pointer and don't seem to get the :pointer-button-release event, i.e. the :pointer-button-release clause is never run. Is this a known bug, is there a known way around or a bug-fix? Is there a trick I have forgotten or should I look again for a stupid bug in my own code? It is a bug in MCL CLIM. I have a fix, which I will send you under separate cover.   Received: from BBN.COM by LABS-N.BBN.COM id aa09912; 24 Apr 92 3:21 EDT Received: from fhg1.fhg.de by BBN.COM id aa14518; 24 Apr 92 3:16 EDT Received: by fhg.de (fhg1.fhg.de) with PRESMTP; Fri, 24 Apr 92 09:16:07 +0200 from FHG-GATEWAY Received: by fhg.de (fhg1.fhg.de) with UUCP; Fri, 24 Apr 92 09:08:50 +0200 from imldo Received: by iml.fhg.de with SMTP; Fri, 24 Apr 92 08:55:25 +0200 Date: Fri, 24 Apr 1992 09:53+0200 From: Stefan Bernemann Subject: button-release To: York@chuck-jones.west.dialnet.ila.com Cc: clim@BBN.COM In-Reply-To: <19920423200548.8.YORK@CHUCK-JONES.west.dialnet.ila.com> Message-Id: <19920424075309.2.STEFAN@ELISABETH.iml.fhg.de> Date: Thu, 23 Apr 1992 22:05 MEST From: "William M. York" Date: Thu, 23 Apr 1992 00:38 PDT From: Hallvard.Tretteberg@si.no Hi, I'm still using CLIM 1.0 with MCL 2.0 (both beta). I'm tracking the pointer with clim:tracking-pointer and don't seem to get the :pointer-button-release event, i.e. the :pointer-button-release clause is never run. Is this a known bug, is there a known way around or a bug-fix? Is there a trick I have forgotten or should I look again for a stupid bug in my own code? It is a bug in MCL CLIM. I have a fix, which I will send you under separate cover. We are also using CLIM 1.0 with MCL 2.0 (beta) and need a fix. My question concerning this CLIM Mailing list: We are using CLIM on the Symbolics, on Mac on SUN (under Lucid CL). I'm not aware of any patches sent around so far. Are there any procedures set up for distribution patches (vendor specific, public file servers, ...)? If not, could that be done or do I always have to wait for major / minor release updates for bug fixes? Mail: Stefan Bernemann ! Phone: +49-231-9743-139 c/o FhG IML Dortmund ! Fax: +49-231-9743-234 Emil-Figge-Str. 75 ! Email: berni@iml.fhg.de D-4600 Dortmund 50, FRG !   Received: from BBN.COM by LABS-N.BBN.COM id aa17151; 24 Apr 92 10:30 EDT Received: from sigi.cs.colorado.edu by BBN.COM id aa28793; 24 Apr 92 10:19 EDT Received: by sigi.cs.colorado.edu id AA04474 (5.65c/IDA-1.4.4 for clim@bbn.com); Fri, 24 Apr 1992 08:19:37 -0600 Date: Fri, 24 Apr 1992 08:19:37 -0600 From: Brent Reeves Message-Id: <199204241419.AA04474@sigi.cs.colorado.edu> To: clim@bbn.com Subject: Trouble with keyboard accelerator I'm running Genera 8.1 and CLIM version 27 and can't get keyboard accelerators to work. After the following command is defined, when I press control-r or control-shift-r, the machine just beeps. And the "recreate" command does not show up in the command table. (define-network-design-command (com-recreate :keystroke #\c-r :menu nil) () (when *most-recent-palette-item* (com-create-copy *most-recent-palette-item*))) -brent ---------------------------------------------------------------- Brent Neal Reeves brentr@cs.colorado.edu (303) 492-1218   Received: from BBN.COM by LABS-N.BBN.COM id aa18687; 24 Apr 92 12:06 EDT Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa03281; 24 Apr 92 12:02 EDT Received: from SUMMER.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 797527; 24 Apr 1992 12:01:37-0400 Date: Fri, 24 Apr 1992 12:01-0400 From: Scott McKay Subject: Trouble with keyboard accelerator To: brentr@sigi.cs.colorado.edu, clim@BBN.COM In-Reply-To: <199204241419.AA04474@sigi.cs.colorado.edu> Message-ID: <19920424160136.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 24 Apr 1992 10:19 EDT From: Brent Reeves I'm running Genera 8.1 and CLIM version 27 and can't get keyboard accelerators to work. After the following command is defined, when I press control-r or control-shift-r, the machine just beeps. And the "recreate" command does not show up in the command table. (define-network-design-command (com-recreate :keystroke #\c-r :menu nil) () (when *most-recent-palette-item* (com-create-copy *most-recent-palette-item*))) If you have an interactor pane in your frame, CLIM does not defaultly read keystroke accelerators. You need to tell it to do so explicitly. Specialize your READ-FRAME-COMMAND method to call READ-COMMAND, and supply :READ-KEYSTROKES T. The behavior is such because otherwise it would be too easy to have keytstroke accelerators clash with normal printing characters. -brent ---------------------------------------------------------------- Brent Neal Reeves brentr@cs.colorado.edu (303) 492-1218   Received: from BBN.COM by LABS-N.BBN.COM id aa18572; 24 Apr 92 11:59 EDT Received: from lucid.com by BBN.COM id aa03029; 24 Apr 92 11:56 EDT Received: from kuwait.lucid ([192.31.212.118]) by heavens-gate.lucid.com id AA15409g; Fri, 24 Apr 92 08:49:38 PDT Received: by kuwait.lucid (4.1/SMI-4.1) id AA05806; Fri, 24 Apr 92 08:56:24 PDT Date: Fri, 24 Apr 92 08:56:24 PDT From: kern%kuwait@lucid.com (John Kern) Message-Id: <9204241556.AA05806@kuwait.lucid> To: brentr@sigi.cs.colorado.edu Cc: clim@BBN.COM In-Reply-To: Brent Reeves's message of Fri, 24 Apr 1992 08:19:37 -0600 <199204241419.AA04474@sigi.cs.colorado.edu> Subject: Trouble with keyboard accelerator Reply-To: kern@lucid.com Howdy Mr. Reeves, I think you need to specialize clim:read-frame-command generic function. See page 227 of the Symbolics Users manual for more information. Sincerely, John S. Kern Lucid, Inc. Customer Support   Received: from BBN.COM by LABS-N.BBN.COM id aa19198; 24 Apr 92 12:51 EDT Received: from FUJI.ILA.COM by BBN.COM id aa04851; 24 Apr 92 12:48 EDT Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 310061; 24 Apr 92 12:44:03 EDT Date: Fri, 24 Apr 1992 09:35-0700 From: William M. York Subject: button-release To: berni@iml.fhg.de cc: clim@BBN.COM In-Reply-To: <19920424075309.2.STEFAN@ELISABETH.iml.fhg.de> Message-ID: <19920424163513.2.YORK@CHUCK-JONES.west.dialnet.ila.com> Date: Fri, 24 Apr 1992 00:53 PDT From: Stefan Bernemann Date: Thu, 23 Apr 1992 22:05 MEST From: "William M. York" Date: Thu, 23 Apr 1992 00:38 PDT From: Hallvard.Tretteberg@si.no Hi, I'm still using CLIM 1.0 with MCL 2.0 (both beta). I'm tracking the pointer with clim:tracking-pointer and don't seem to get the :pointer-button-release event, i.e. the :pointer-button-release clause is never run. Is this a known bug, is there a known way around or a bug-fix? Is there a trick I have forgotten or should I look again for a stupid bug in my own code? It is a bug in MCL CLIM. I have a fix, which I will send you under separate cover. We are also using CLIM 1.0 with MCL 2.0 (beta) and need a fix. I'll send it along. My question concerning this CLIM Mailing list: We are using CLIM on the Symbolics, on Mac on SUN (under Lucid CL). I'm not aware of any patches sent around so far. Are there any procedures set up for distribution patches (vendor specific, public file servers, ...)? If not, could that be done or do I always have to wait for major / minor release updates for bug fixes? Due to the different release schedules and software maintenance policies of the various CLIM vendors, you have to deal with each vendor in order to get updates and bug-fix patches. Most of vendors are either now shipping or about to ship CLIM 1.1, which contains many bug fixes generated due to customer feedback from the initial CLIM 1.0 release.   Received: from BBN.COM by LABS-N.BBN.COM id aa01110; 27 Apr 92 13:04 EDT Received: from fenrix.si.no by BBN.COM id aa12330; 27 Apr 92 12:48 EDT Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.22) id AA12360; Mon, 27 Apr 92 18:47:43 +0200 Date: Mon, 27 Apr 92 18:47:43 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9204271645.AAmonsun00806@D> To: clim@bbn.com Subject: drawing text I'm porting an editor from Gold-Hill CL to CLIM 1.0 on MCL 2.0 (both beta). When drawing in Gold Hill (MS-Windows) text can overwrite other text, instead of combining with it. How can I specify a boolean function over destination and source pixels or getting the same effect, in CLIM? I read about compose-in and -out but didn't understand it well enough to be able to use them. If I get the help I need I may release it for public use...so please help. Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.BBN.COM id ab01697; 27 Apr 92 13:53 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa15270; 27 Apr 92 13:47 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1070076; 27 Apr 1992 13:45:44-0400 Date: Mon, 27 Apr 1992 13:46-0400 From: Scott McKay Subject: drawing text To: Hallvard.Tretteberg@si.no, clim@BBN.COM In-Reply-To: <9204271645.AAmonsun00806@D> Message-ID: <19920427174616.5.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 27 Apr 1992 12:47 EDT From: Hallvard.Tretteberg@si.no I'm porting an editor from Gold-Hill CL to CLIM 1.0 on MCL 2.0 (both beta). When drawing in Gold Hill (MS-Windows) text can overwrite other text, instead of combining with it. How can I specify a boolean function over destination and source pixels or getting the same effect, in CLIM? I read about compose-in and -out but didn't understand it well enough to be able to use them. If I get the help I need I may release it for public use...so please help. This is a deficiency in CLIM. Right now, it does not provide a simple way to do this. You should explicitly erase the region you plan to overwrite before drawing on it; DRAW-RECTANGLE* will suffice for this.   Received: from BBN.COM by LABS-N.BBN.COM id aa02520; 28 Apr 92 10:40 EDT Received: from watson.ibm.com by BBN.COM id aa09873; 28 Apr 92 10:28 EDT Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 5484; Tue, 28 Apr 92 10:28:37 EDT Received: from YKTVMZ by watson.vnet.ibm.com with "VAGENT.V1.0" id 6101; Tue, 28 Apr 1992 10:28:36 EDT Received: from fiasco.watson.ibm.com by yktvmz.watson.ibm.com (IBM VM SMTP V2R2) with TCP; Tue, 28 Apr 92 10:28:34 EDT Received: by fiasco.watson.ibm.com (AIX 3.1/UCB 5.61/920123) id AA15580; Tue, 28 Apr 92 10:28:36 -0400 Message-Id: <9204281428.AA15580@fiasco.watson.ibm.com> To: clim@BBN.COM X-External-Networks: yes Reply-To: meir@watson.ibm.com Subject: incremental redisplay documentation example bug Date: Tue, 28 Apr 92 10:28:36 -0500 From: "Meir Laker" Although the example given in the CLIM documentation (section 22.6 of the Symbolics CLIM documentation, p. 254) works as documented on my Symbolics (in both its original form and the suggested modification with a sort on p. 255), the following slightly modified version of the code (interchanging the first and fifth element values) does not. Why not? (defun test (&optional (stream *standard-output*)) (let* ((list (list 1 2 3 4 5)) (record (clim:updating-output (stream) (do* ((elements list (cdr elements)) (count 0 (1+ count)) (element (first elements) (first elements))) ((null elements)) (clim:updating-output (stream :unique-id count :cache-value element) (format stream "Element ~D" element) (terpri stream)))))) (sleep 2) ; (setf (nth 2 list) 17) ; (setf list (sort list #'(lambda (&rest args) ; (zerop (random 2))))) (setf (nth 4 list) 1) (setf (nth 0 list) 5) (clim:redisplay record stream))) After the sleep, the final output is: 5 Element 2 Element 3 Element 4 1 The "Element" is missing from the first and last lines and the 1 is shifted somewhat to the left of being aligned in the column of numbers. What went wrong? Meir Laker   Received: from BBN.COM by LABS-N.BBN.COM id aa03953; 28 Apr 92 12:00 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa13809; 28 Apr 92 11:51 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1070665; 28 Apr 1992 11:50:21-0400 Date: Tue, 28 Apr 1992 11:50-0400 From: Scott McKay Subject: incremental redisplay documentation example bug To: meir@watson.ibm.com, clim@BBN.COM In-Reply-To: <9204281428.AA15580@fiasco.watson.ibm.com> Message-ID: <19920428155022.5.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 28 Apr 1992 11:28 EDT From: Meir Laker Although the example given in the CLIM documentation (section 22.6 of the Symbolics CLIM documentation, p. 254) works as documented on my Symbolics (in both its original form and the suggested modification with a sort on p. 255), the following slightly modified version of the code (interchanging the first and fifth element values) does not. Why not? (defun test (&optional (stream *standard-output*)) (let* ((list (list 1 2 3 4 5)) (record (clim:updating-output (stream) (do* ((elements list (cdr elements)) (count 0 (1+ count)) (element (first elements) (first elements))) ((null elements)) (clim:updating-output (stream :unique-id count :cache-value element) (format stream "Element ~D" element) (terpri stream)))))) (sleep 2) ; (setf (nth 2 list) 17) ; (setf list (sort list #'(lambda (&rest args) ; (zerop (random 2))))) (setf (nth 4 list) 1) (setf (nth 0 list) 5) (clim:redisplay record stream))) After the sleep, the final output is: 5 Element 2 Element 3 Element 4 1 The "Element" is missing from the first and last lines and the 1 is shifted somewhat to the left of being aligned in the column of numbers. What went wrong? This works in CLIM 1.1, which you should be receiving soon.   Received: from BBN.COM by LABS-N.BBN.COM id aa04354; 28 Apr 92 12:30 EDT Received: from lucid.com by BBN.COM id aa15205; 28 Apr 92 12:25 EDT Received: from kuwait.lucid ([192.31.212.118]) by heavens-gate.lucid.com id AA24348g; Tue, 28 Apr 92 09:18:31 PDT Received: by kuwait.lucid (4.1/SMI-4.1) id AA07877; Tue, 28 Apr 92 09:25:26 PDT Date: Tue, 28 Apr 92 09:25:26 PDT From: kern%kuwait@lucid.com (John Kern) Message-Id: <9204281625.AA07877@kuwait.lucid> To: meir@watson.ibm.com Cc: clim@BBN.COM In-Reply-To: Meir Laker's message of Tue, 28 Apr 92 10:28:36 -0500 <9204281428.AA15580@fiasco.watson.ibm.com> Subject: incremental redisplay documentation example bug Reply-To: kern@lucid.com Howdy, I ran the following testcase on an IBM RS/6000 displaying on a sun3 and wasn't able to reproduce your results. Note: force-output was added to get the first list to display. Does this work on your configuration? Hmm.. Maybe this is a server difference. What kind of display are you using? Sincerely, John S. Kern Lucid, Inc. Customer Support ========================================== (in-package :clim-user) (defun com-test (&optional (stream (get-frame-pane *application-frame* 'output))) (window-clear stream) (let* ((list (list 1 2 3 4 5)) (record (clim:updating-output (stream) (do* ((elements list (cdr elements)) (count 0 (1+ count)) (element (first elements) (first elements))) ((null elements)) (clim:updating-output (stream :unique-id count :cache-value element) (format stream "Element ~D" element) (terpri stream)))))) (force-output stream) (sleep 2) ; (setf (nth 2 list) 17) ; (setf list (sort list #'(lambda (&rest args) ; (zerop (random 2))))) (setf (nth 4 list) 1) (setf (nth 0 list) 5) (clim:redisplay record stream))) (define-application-frame test () () (:panes ((main :application :incremental-redisplay nil :default-size :rest :display-function 'display-main) (output :application :incremental-redisplay t) (test-menu :command-menu))) (:command-table (test-menu :inherit-from (user-command-table) :menu (("EXIT" :command com-exit) ("TEST-COM" :command com-test) ))) ) (defmethod display-main ((frame test) stream) (format stream "Hello World") ) (defun run (root) (let ((frame (make-application-frame 'test :parent root :left 0 :top 0 :right 500 :bottom 500))) (run-frame-top-level frame) )) (defun com-exit () (frame-exit *application-frame*) )   Received: from BBN.COM by LABS-N.BBN.COM id aa17648; 29 Apr 92 11:40 EDT Received: from OPUS.IARC.MCO.EDU by BBN.COM id aa26837; 29 Apr 92 11:35 EDT Received: from soleil.iarc.mco.edu. by opus.iarc.mco.edu with SMTP ; Wed, 29 Apr 92 11:30:04 EST Received: by soleil.iarc.mco.edu. (4.0/SMI-4.0) id AA24866; Wed, 29 Apr 92 11:32:50 EDT Date: Wed, 29 Apr 92 11:32:50 EDT From: habboub@soleil.iarc.mco.edu (Mahmoud Habboub) Message-Id: <9204291532.AA24866@soleil.iarc.mco.edu.> To: clim@bbn.com Subject: Status of CLIM 2.0. for MCL Does anybody know what is the status of clim 2.0 for MCL? Is there any where a description fo CLIM 2.0? What is the address and Tel of ILA? Thanks in advance. -------------------------------------------------------------------- Mahmoud K. Habboub (419)381-4597 Image Analysis Research Center habboub@soleil.iarc.mco.edu Medical College of Ohio 3000 Arlington Ave. Toledo, Ohio 43614 --------------------------------------------------------------------   Received: from BBN.COM by LABS-N.BBN.COM id aa17320; 29 Apr 92 11:13 EDT Received: from OPUS.IARC.MCO.EDU by BBN.COM id aa25366; 29 Apr 92 11:03 EDT Received: from soleil.iarc.mco.edu. by opus.iarc.mco.edu with SMTP ; Wed, 29 Apr 92 10:54:06 EST Received: by soleil.iarc.mco.edu. (4.0/SMI-4.0) id AA23709; Wed, 29 Apr 92 10:56:51 EDT Date: Wed, 29 Apr 92 10:56:51 EDT From: habboub@soleil.iarc.mco.edu (Mahmoud Habboub) Message-Id: <9204291456.AA23709@soleil.iarc.mco.edu.> To: clim@bbn.com Subject: Status of CLIM 2.0 for MCL Does anybody know what is the status of CLIM 2.0 for MCL? Is there any where a discription of CLIM 2.0? Thanks. -------------------------------------------------------------------- Mahmoud K. Habboub (419)381-4597 Image Analysis Research Center habboub@soleil.iarc.mco.edu Medical College of Ohio 3000 Arlington Ave. Toledo, Ohio 43614 --------------------------------------------------------------------   Received: from BBN.COM by LABS-N.BBN.COM id aa19214; 29 Apr 92 13:45 EDT Received: from FUJI.ILA.COM by BBN.COM id aa02282; 29 Apr 92 13:40 EDT Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 310405; 29 Apr 92 13:35:46 EDT Date: Wed, 29 Apr 1992 09:56-0700 From: William M. York Subject: Status of CLIM 2.0. for MCL To: habboub@soleil.iarc.mco.edu, clim@bbn.com In-Reply-To: <9204291532.AA24866@soleil.iarc.mco.edu.> Message-ID: <19920429165640.1.YORK@CHUCK-JONES.west.dialnet.ila.com> Date: Wed, 29 Apr 1992 08:32 PDT From: Mahmoud Habboub Does anybody know what is the status of clim 2.0 for MCL? Is there any where a description fo CLIM 2.0? What is the address and Tel of ILA? By way of answering both questions I am including below a copy of the recent press release regarding CLIM 2. Work on the MCL-specific parts of CLIM 2 will begin after the final version of CLIM 1 is shipped (concurrent with the final version of MCL 2.0). Contact: Gary Roberts, Symbolics, Inc. (617) 221-1356 Elizabeth Shook, Franz Inc. (510) 548-3600 Bill York, ILA (415) 968-3656 Jay Mellman, Lucid (415) 329-8400 Jo Marks, Harlequin Ltd. +44-223 872 522 FOR IMMEDIATE RELEASE LEADING LISP VENDORS SUPPORT SINGLE CLIM 2.0 STANDARD APRIL 23, 1992 -- The major CLIM(r) vendors, Franz, Harlequin, International Lisp Associates (ILA), Lucid, and Symbolics, agreed on a draft specification for the second generation of the graphics toolkit technology. In addition, Franz, Harlequin, ILA, Lucid, and Symbolics have signed a code-sharing agreement to share the cost of CLIM development conforming to the specification. CLIM is a portable, object-oriented set of facilities for developing graphical user interfaces to Lisp-based applications. The second generation CLIM 2.0 creates a truly platform-independent user interface management system in which applications automatically adopt the look and feel of the host environment. The draft specification will be made available for public review at the end of April 1992. Integration of public comments into a final version of the specification will be moderated by Mark Son-Bell of ILA, with the support of a committee of the Association of Lisp Users. According to Saiid Zarrabian, Symbolics Vice President, "the distribution of a CLIM 2.0 specification is a major step in establishing CLIM as a standard. It will enable the vendors to get critical feedback from end-users and other interested parties as well as spark the interest of organizations uninvolved in CLIM to date." Implementation code based on this CLIM 2.0 specification is being distributed by Symbolics. Scott McKay of Symbolics and Chris Richardson of Franz were the major contributors to the implementation, based on prior work by Bill York and others at ILA. Harlequin and Lucid are preparing to make further contributions. Product should be available to users during the second half of 1992. CLIM is a registered trademark of International Lisp Associates. Other brand or product names are trademarks of their respective holders.   Received: from BBN.COM by LABS-N.BBN.COM id aa28039; 1 May 92 13:43 EDT Received: from Sunset.AI.SRI.COM by BBN.COM id aa02391; 1 May 92 13:39 EDT Received: from Rockaway.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA09865 for clim@bbn.com; Fri, 1 May 92 10:39:02 PDT Received: by Rockaway.AI.SRI.COM (4.1/SMI-4.1) id AA19347 for clim@bbn.com; Fri, 1 May 92 10:39:01 PDT Date: Fri, 1 May 92 10:39:01 PDT From: Peter Karp To: clim@bbn.com Subject: Moving output records for fast translation Message-Id: Imagine that a program has drawn a very complex picture, and it must then translate some elements of that picture as quickly as possible. My theory is that it will be faster to get CLIM to redraw the output records associated with those picture elements, with a translation applied, than it will be to completely redraw those picture elements at the application level (particularly if much computation is required at the application level). Function shift-output-record below applies a translation to an output record. This implementation was quite difficult to figure out. I am posting this because it might be useful to others, and also to raise the question of whether this functionality should be more prominently documented in CLIM. The ability to perform operations such as this at the output-record level seems like it should be a major performance win for CLIM, but it is not sufficiently well documented for applications to take advantage of it. Peter (defun shift-output-record (stream record dx dy) (let (x y) (multiple-value-bind (x-offset y-offset) (clim:convert-from-relative-to-absolute-coordinates stream (clim:output-record-parent record)) (clim:with-output-recording-options (stream :record-p nil :draw-p t) (clos:with-slots (clim-utils:left clim-utils:top clim::parent) record (setq x clim-utils:left y clim-utils:top) (clim:erase-output-record record stream) (clim::output-record-set-position* record (+ x dx) (+ y dy)) (clim::tree-recompute-extent record) (clim:replay-1 record stream nil x-offset y-offset) (clim:add-output-record stream record) ) ) ) ) )   Received: from BBN.COM by LABS-N.BBN.COM id aa00267; 1 May 92 16:00 EDT Received: from Sunset.AI.SRI.COM by BBN.COM id aa10390; 1 May 92 15:56 EDT Received: from Rockaway.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA04196 for clim@BBN.COM; Fri, 1 May 92 12:56:18 PDT Received: by Rockaway.AI.SRI.COM (4.1/SMI-4.1) id AA19496 for clim@BBN.COM; Fri, 1 May 92 12:56:16 PDT Date: Fri, 1 May 92 12:56:15 PDT From: Peter Karp To: "John G. Aspinall" Cc: clim@BBN.COM Subject: Re: Moving output records for fast translation In-Reply-To: Your message of Fri, 1 May 1992 15:32-0400 Message-Id: The type of translation I had in mind is not interactive -- the application knows exactly where the output record should be moved -- therefore dragging-output is not useful for this task.   Received: from BBN.COM by LABS-N.BBN.COM id aa29485; 1 May 92 15:40 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa09424; 1 May 92 15:33 EDT Received: from JUBJUB.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1073050; 1 May 1992 15:31:50-0400 Date: Fri, 1 May 1992 15:32-0400 From: John G. Aspinall Subject: Moving output records for fast translation To: pkarp@ai.sri.com, clim@BBN.COM In-Reply-To: Message-ID: <19920501193205.1.JGA@JUBJUB.SCRC.Symbolics.COM> Date: Fri, 1 May 1992 13:39 EDT From: Peter Karp Imagine that a program has drawn a very complex picture, and it must then translate some elements of that picture as quickly as possible. My theory is that it will be faster to get CLIM to redraw the output records associated with those picture elements, with a translation applied, than it will be to completely redraw those picture elements at the application level (particularly if much computation is required at the application level). Certainly. This is what (e.g.) dragging-output does. Function shift-output-record below applies a translation to an output record. This implementation was quite difficult to figure out.... Part of the CLIM 2 spec is a clearer definition of things like -- exactly what *is* the "position" of an output record? Under the proposed CLIM 2 way-of-doing-things, you would not have to know about implementation-dependent things like clim:convert-from-relative-to-absolute-coordinates.   Received: from BBN.COM by LABS-N.BBN.COM id aa01128; 1 May 92 17:08 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa14314; 1 May 92 17:05 EDT Received: from JUBJUB.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1073095; 1 May 1992 17:04:10-0400 Date: Fri, 1 May 1992 17:04-0400 From: John G. Aspinall Subject: Re: Moving output records for fast translation To: pkarp@ai.sri.com cc: clim@BBN.COM In-Reply-To: Message-ID: <19920501210425.2.JGA@JUBJUB.SCRC.Symbolics.COM> Date: Fri, 1 May 1992 15:32 EDT From: "John G. Aspinall" Date: Fri, 1 May 1992 13:39 EDT From: Peter Karp [...] My theory is that it will be faster to get CLIM to redraw the output records associated with those picture elements, with a translation applied, than it will be to completely redraw those picture elements at the application level (particularly if much computation is required at the application level). Certainly. This is what (e.g.) dragging-output does. Date: Fri, 1 May 1992 15:56 EDT From: Peter Karp The type of translation I had in mind is not interactive -- the application knows exactly where the output record should be moved -- therefore dragging-output is not useful for this task. You misunderstand. I never suggested that you use dragging-output. I was saying that dragging-output has the same requirements as you do. In both cases, the requirement is to "redraw under translation as fast as possible". I should have said: Certainly. This is what (e.g.) dragging-output does to achieve the same goal.   Received: from BBN.COM by LABS-N.BBN.COM id aa13930; 4 May 92 11:01 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa26410; 4 May 92 10:41 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1073603; 4 May 1992 10:39:46-0400 Date: Mon, 4 May 1992 10:40-0400 From: Scott McKay Subject: Moving output records for fast translation To: pkarp@ai.sri.com, JGA@STONY-BROOK.SCRC.Symbolics.COM, clim@BBN.COM In-Reply-To: Message-ID: <19920504144019.5.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 1 May 1992 13:39 EDT From: Peter Karp Imagine that a program has drawn a very complex picture, and it must then translate some elements of that picture as quickly as possible. My theory is that it will be faster to get CLIM to redraw the output records associated with those picture elements, with a translation applied, than it will be to completely redraw those picture elements at the application level (particularly if much computation is required at the application level). Function shift-output-record below applies a translation to an output record. This implementation was quite difficult to figure out. I am posting this because it might be useful to others, and also to raise the question of whether this functionality should be more prominently documented in CLIM. The ability to perform operations such as this at the output-record level seems like it should be a major performance win for CLIM, but it is not sufficiently well documented for applications to take advantage of it. Peter (defun shift-output-record (stream record dx dy) (let (x y) (multiple-value-bind (x-offset y-offset) (clim:convert-from-relative-to-absolute-coordinates stream (clim:output-record-parent record)) (clim:with-output-recording-options (stream :record-p nil :draw-p t) (clos:with-slots (clim-utils:left clim-utils:top clim::parent) record (setq x clim-utils:left y clim-utils:top) (clim:erase-output-record record stream) (clim::output-record-set-position* record (+ x dx) (+ y dy)) (clim::tree-recompute-extent record) (clim:replay-1 record stream nil x-offset y-offset) (clim:add-output-record stream record) ) ) ) ) ) BTW, even this convoluted code is not enough due to some very poor designs decisions made early in the CLIM 1.0 process. Perhaps JGA will send you a hack he just wrote that needs something like this.   Received: from BBN.COM by LABS-N.BBN.COM id aa21712; 4 May 92 21:03 EDT Received: from cs.utexas.edu by BBN.COM id aa24129; 4 May 92 20:58 EDT Received: from sage.cs.utexas.edu by cs.utexas.edu (5.64/1.126) with SMTP id AA12746; Mon, 4 May 92 19:58:15 -0500 Received: by sage.cs.utexas.edu (5.64/Client) id AA28577; Mon, 4 May 92 19:58:07 -0500 Message-Id: <9205050058.AA28577@sage.cs.utexas.edu> From: eilerts@cs.utexas.edu (Erik Eilerts) Date: Mon, 4 May 1992 19:58:07 -0500 X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: clim@bbn.com Subject: Scroll-Bar Reset Cc: eilerts@cs.utexas.edu I'm using Clim 1.1 and am having problems with my scroll bars. I create an application frame that has a menu window and some application windows with scroll bars. It seems that after any update, the *first* window in the definition list has it's scroll bars reset to (0,0) while the other windows scroll bars are left alone. Is there an explanation for this? Here is my application frame definition: (clim:define-application-frame text-frame () ((kned :accessor kned :initform nil :initarg :kned) (active :initform nil :accessor active) (pane-list :initform nil :accessor pane-list)) (:panes ( (display1 :application :display-function 'draw-text-pane :incremental-redisplay nil :display-after-commands nil :scroll-bars :both) (display2 :application :display-function 'draw-text-pane :incremental-redisplay nil :display-after-commands nil :scroll-bars :both) (display3 :application :display-function 'draw-text-pane :incremental-redisplay nil :display-after-commands nil :scroll-bars :both) (display4 :application :display-function 'draw-text-pane :incremental-redisplay nil :display-after-commands nil :scroll-bars :both) (active-box :application :display-function 'draw-active-box :incremental-redisplay nil :display-after-commands nil :scroll-bars nil)) (:layout ( (4-text-panes (:column :rest (:row 1/30 (active-box 1/30) (menu :rest)) (:row :rest (display1 1/2) (display2 :rest)) (:row :rest (display3 1/2) (display4 :rest)) (documentation :compute))) ))) In this case, display1 resets it's scroll bars whenever the application is redrawn, but the scroll bars for the other display windows are left alone. As a cheap hack, I moved the window active-box to the top of the definition list, and, since it doesn't have any scroll bars, my problem seems to have technically been solved. Thanks, Erik Eilerts University of Texas at Austin eilerts@cs.utexas.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa25195; 5 May 92 5:11 EDT Received: from mcsun.EU.net by BBN.COM id aa00906; 5 May 92 4:58 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA29424 (5.65b/CWI-2.160); Tue, 5 May 1992 10:58:39 +0200 Received: by ub4b.buug.be (5.64+/ub4b_02) id AA16229; Tue, 5 May 92 10:53:30 +0200 Received: from scosysv by nrb.be (DECUS UUCP ///1.3-1/2.5/); Tue, 5 May 92 10:30:14 +0200 Received: from milou.nrb.be by scosysv.nrb.be with SMTP (5.59/25-e-eef-ev@nrb) id AA00265; Tue, 5 May 92 15:14:15 CET Received: from nrbmi1.nrb.be by milou.nrb.be via CHAOS with SMTP id 27616; 5 May 1992 10:11:54+0200 Date: Mon, 4 May 1992 18:11+0200 From: Vincent Keunen Reply-To: scosysv!keunen@nrb.be Subject: request for an ftp site for clim material To: clim@bbn.com Message-Id: <19920504161158.1.KEUNEN@nrbmi1.nrb.be> Bfcc: M:>keunen>courrier>envoye.babyl.newest Resent-To: clim@bbn.com Resent-From: Vincent Keunen Resent-Date: Tue, 5 May 1992 10:26+0200 Resent-Message-Id: <19920505082639.1.KEUNEN@nrbmi1.nrb.be> These two recent messages lead me to ask this question: 1- [...] This implementation was quite difficult to figure out. I am posting this because it might be useful to others, [...] 2- My question concerning this CLIM Mailing list: We are using CLIM on the Symbolics, on Mac on SUN (under Lucid CL). I'm not aware of any patches sent around so far. Are there any procedures set up for distribution patches (vendor specific, public file servers, ...)? If not, could that be done or do I always have to wait for major / minor release updates for bug fixes? The question/suggestion: Isn't there an ftp site with clim material (at BBN or other place)? If not, wouldn't it be a good idea to create one? It would be a good place for vendors to place minor patches, examples,... and for users to contribute code. There are some basic things in clim that could benefit a lot from some more examples. I could contribute some code it took me time to write, just because I didn't get the concepts right the first time (and I had to read the documentation in length and in many different places). The server could have basic directories like: /clim1/patches /clim1/examples /clim1/tools /clim1/contrib /clim1/contrib/examples /clim1/contrib/tools /clim1/vendor-specific /clim1/vendor-specific/symbolics /clim1/vendor-specific/ila /clim1/vendor-specific/franz /clim1/vendor-specific/lucid /clim1/vendor-specific/harlequin /clim2 etc... What do you climers think? Vincent Keunen keunen@nrb.be   Received: from BBN.COM by LABS-N.BBN.COM id aa25197; 5 May 92 5:11 EDT Received: from mcsun.EU.net by BBN.COM id aa00911; 5 May 92 4:59 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA29430 (5.65b/CWI-2.160); Tue, 5 May 1992 10:58:42 +0200 Received: by ub4b.buug.be (5.64+/ub4b_02) id AA16234; Tue, 5 May 92 10:53:39 +0200 Received: from scosysv by nrb.be (DECUS UUCP ///1.3-1/2.5/); Tue, 5 May 92 10:30:20 +0200 Received: from milou.nrb.be by scosysv.nrb.be with SMTP (5.59/25-e-eef-ev@nrb) id AA00285; Tue, 5 May 92 15:19:06 CET Received: from nrbmi1.nrb.be by milou.nrb.be via CHAOS with SMTP id 27617; 5 May 1992 10:16:52+0200 Date: Mon, 4 May 1992 18:11+0200 From: Vincent Keunen Reply-To: scosysv!keunen@nrb.be Subject: request for an ftp site for clim material To: clim@bbn.com Message-Id: <19920504161158.1.KEUNEN@nrbmi1.nrb.be> Bfcc: M:>keunen>courrier>envoye.babyl.newest Resent-To: clim@bbn.com Resent-From: Vincent Keunen Resent-Date: Tue, 5 May 1992 10:31+0200 Resent-Message-Id: <19920505083143.2.KEUNEN@nrbmi1.nrb.be> These two recent messages lead me to ask this question: 1- [...] This implementation was quite difficult to figure out. I am posting this because it might be useful to others, [...] 2- My question concerning this CLIM Mailing list: We are using CLIM on the Symbolics, on Mac on SUN (under Lucid CL). I'm not aware of any patches sent around so far. Are there any procedures set up for distribution patches (vendor specific, public file servers, ...)? If not, could that be done or do I always have to wait for major / minor release updates for bug fixes? The question/suggestion: Isn't there an ftp site with clim material (at BBN or other place)? If not, wouldn't it be a good idea to create one? It would be a good place for vendors to place minor patches, examples,... and for users to contribute code. There are some basic things in clim that could benefit a lot from some more examples. I could contribute some code it took me time to write, just because I didn't get the concepts right the first time (and I had to read the documentation in length and in many different places). The server could have basic directories like: /clim1/patches /clim1/examples /clim1/tools /clim1/contrib /clim1/contrib/examples /clim1/contrib/tools /clim1/vendor-specific /clim1/vendor-specific/symbolics /clim1/vendor-specific/ila /clim1/vendor-specific/franz /clim1/vendor-specific/lucid /clim1/vendor-specific/harlequin /clim2 etc... What do you climers think? Vincent Keunen keunen@nrb.be   Received: from BBN.COM by LABS-N.BBN.COM id aa27338; 5 May 92 8:58 EDT Received: from mcsun.EU.net by BBN.COM id aa05844; 5 May 92 8:40 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA11288 (5.65b/CWI-2.160); Tue, 5 May 1992 14:40:16 +0200 Received: by ub4b.buug.be (5.64+/ub4b_02) id AA24830; Tue, 5 May 92 14:35:15 +0200 Received: from scosysv by nrb.be (DECUS UUCP ///1.3-1/2.5/); Tue, 5 May 92 14:11:13 +0200 Received: from milou.nrb.be by scosysv.nrb.be with SMTP (5.59/25-e-eef-ev@nrb) id AA00346; Tue, 5 May 92 15:34:47 CET Received: from nrbmi1.nrb.be by milou.nrb.be via CHAOS with SMTP id 27701; 5 May 1992 10:32:32+0200 Date: Mon, 4 May 1992 18:11+0200 From: Vincent Keunen Reply-To: scosysv!keunen@nrb.be Subject: request for an ftp site for clim material To: clim@bbn.com Message-Id: <19920504161158.1.KEUNEN@nrbmi1.nrb.be> Bfcc: M:>keunen>courrier>envoye.babyl.newest Resent-To: clim@bbn.com Resent-From: Vincent Keunen Resent-Date: Tue, 5 May 1992 10:47+0200 Resent-Message-Id: <19920505084722.3.KEUNEN@nrbmi1.nrb.be> These two recent messages lead me to ask this question: 1- [...] This implementation was quite difficult to figure out. I am posting this because it might be useful to others, [...] 2- My question concerning this CLIM Mailing list: We are using CLIM on the Symbolics, on Mac on SUN (under Lucid CL). I'm not aware of any patches sent around so far. Are there any procedures set up for distribution patches (vendor specific, public file servers, ...)? If not, could that be done or do I always have to wait for major / minor release updates for bug fixes? The question/suggestion: Isn't there an ftp site with clim material (at BBN or other place)? If not, wouldn't it be a good idea to create one? It would be a good place for vendors to place minor patches, examples,... and for users to contribute code. There are some basic things in clim that could benefit a lot from some more examples. I could contribute some code it took me time to write, just because I didn't get the concepts right the first time (and I had to read the documentation in length and in many different places). The server could have basic directories like: /clim1/patches /clim1/examples /clim1/tools /clim1/contrib /clim1/contrib/examples /clim1/contrib/tools /clim1/vendor-specific /clim1/vendor-specific/symbolics /clim1/vendor-specific/ila /clim1/vendor-specific/franz /clim1/vendor-specific/lucid /clim1/vendor-specific/harlequin /clim2 etc... What do you climers think? Vincent Keunen keunen@nrb.be   Received: from BBN.COM by LABS-N.BBN.COM id aa29563; 5 May 92 11:37 EDT Received: from lucid.com by BBN.COM id aa14772; 5 May 92 11:25 EDT Received: from kuwait.lucid ([192.31.212.118]) by heavens-gate.lucid.com id AA11517g; Tue, 5 May 92 08:18:17 PDT Received: by kuwait.lucid (4.1/SMI-4.1) id AA14028; Tue, 5 May 92 08:25:25 PDT Date: Tue, 5 May 92 08:25:25 PDT From: kern%kuwait@lucid.com (John Kern) Message-Id: <9205051525.AA14028@kuwait.lucid> To: eilerts@cs.utexas.edu Cc: clim@BBN.COM, clim-support@lucid.com In-Reply-To: Erik Eilerts's message of Mon, 4 May 1992 19:58:07 -0500 <9205050058.AA28577@sage.cs.utexas.edu> Subject: Scroll-Bar Reset Reply-To: kern@lucid.com Howdy Mr. Eilerts, If you will provide me with short reproducible testcase, I'll look into the problem. Sincerely, John S. Kern Lucid, Inc. Customer Support   Received: from BBN.COM by LABS-N.BBN.COM id aa00556; 5 May 92 12:40 EDT Received: from Sunset.AI.SRI.COM by BBN.COM id aa17735; 5 May 92 12:36 EDT Received: from Rockaway.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA26847 for clim@bbn.com; Tue, 5 May 92 09:36:09 PDT Received: by Rockaway.AI.SRI.COM (4.1/SMI-4.1) id AA06460 for clim@bbn.com; Tue, 5 May 92 09:36:08 PDT Date: Tue, 5 May 92 9:36:08 PDT From: Peter Karp To: clim@bbn.com Subject: CLIM archives Message-Id: I second Vincent Keunen's call for a CLIM archive. I'm particularly interested in seeing it used for vendor patches, but user contributions would also be of interest. Anyone at BBN care to volunteer? Perhaps this could be considered part of the PE. Peter   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa02065; 5 May 92 14:40 EDT Received: by KARIBA.BBN.COM id aa18736; 5 May 92 14:29 EDT From: Dan Cerys Organization: Bolt Beranek and Newman Inc. To: scosysv!keunen@nrb.be CC: clim@BBN.COM In-reply-to: Vincent Keunen's message of Mon, 4 May 1992 18:11+0200 <19920504161158.1.KEUNEN@nrbmi1.nrb.be> Subject: request for an ftp site for clim material Date: Tue, 5 May 92 14:24:54 EDT Sender: cerys@BBN.COM Date: Mon, 4 May 1992 18:11+0200 From: Vincent Keunen Isn't there an ftp site with clim material (at BBN or other place)? If not, wouldn't it be a good idea to create one? There isn't such a beast now, but I agree that it would be a good thing to have. We can probably host this repository on a BBN machine. As Peter and Vincent mentioned, it would be useful to have a central place to obtain patches (both vendor and contributed) and to share CLIM extensions. The vendor contributions may be a problem, but maybe not (esp if the patches are just binaries). I'll check with each of the CLIM vendors to see what is feasible. Dan   Received: from BBN.COM by LABS-N.BBN.COM id aa04144; 5 May 92 17:10 EDT Received: from sigi.cs.colorado.edu by BBN.COM id aa02477; 5 May 92 17:04 EDT Received: by sigi.cs.colorado.edu id AA28112 (5.65c/IDA-1.4.4 for clim@bbn.com); Tue, 5 May 1992 15:04:51 -0600 Date: Tue, 5 May 1992 15:04:51 -0600 From: Brent Reeves Message-Id: <199205052104.AA28112@sigi.cs.colorado.edu> To: clim@bbn.com Subject: question about args to define-xxx-command Running Genera 8.1 and CLIM 1.0. Compiler tells me: For CLIM Presentation Translator pt-design-unit-to-com-connect-translator CLIM Presentation Translator pt-design-unit-to-com-connect-translator is defined twice in the file NETWORK-DESIGN-CLIM:NETWORK-DESIGN-CLIM;PROGRAM-FRAMEWORK. (define-network-design-command (com-connect :name "Connect" :menu nil) ((du1 'pt-design-unit :gesture :select) (du2 'pt-design-unit :gesture :select)) (pushnew (key du1) (connections du2)) (pushnew (key du2) (connections du1)) (audit "~&~a is now connected to ~a" (key du1) (key du2))) I suppose the two ":gesture :selects" are causing it ("causing" that is in the macro expansion where the translators get defined). How should this be defined instead? -brent ---------------------------------------------------------------------- Brent Neal Reeves brentr@cs.colorado.edu (303) 492-1218 "visualize whirled peas"   Received: from BBN.COM by LABS-N.BBN.COM id aa03854; 5 May 92 16:52 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa01752; 5 May 92 16:48 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA28503; Tue, 5 May 92 13:48:14 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA01487; Tue, 5 May 92 13:41:50 PDT Date: Tue, 5 May 92 13:41:50 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9205052041.AA01487@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: CLIM -> Postscript code file question This is a quick dumb question. I wish to produce multiple hardcopy pages of plots from my data objects within CLIM. I know where the pages are relative to my graphics output. How do I start a new page within the with-output-to-postscript-stream construct? Is it something as simple as this: (assume you're in a packaging using CLIM) (with-open-file (f-stream "a-postscript-code-file" :direction :output) (with-output-to-postscript-stream (stream f-stream) .... some graphics output (format stream "~|") ;begin a new hardcopy page? .... more graphics output on the next page ))   Received: from BBN.COM by LABS-N.BBN.COM id aa04895; 5 May 92 18:15 EDT Received: from cs.utexas.edu by BBN.COM id aa04644; 5 May 92 18:10 EDT Received: from sage.cs.utexas.edu by cs.utexas.edu (5.64/1.126) with SMTP id AA07111; Tue, 5 May 92 17:10:17 -0500 Received: by sage.cs.utexas.edu (5.64/Client) id AA00485; Tue, 5 May 92 17:10:08 -0500 Message-Id: <9205052210.AA00485@sage.cs.utexas.edu> From: eilerts@cs.utexas.edu (Erik Eilerts) Date: Tue, 5 May 1992 17:10:08 -0500 X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: clim@bbn.com Subject: Re: CLIM -> Postscript code file question From: Scott McKay Subject: CLIM -> Postscript code file question Date: Tue, 5 May 1992 16:41 EDT From: Curt Eggemeyer (format stream "~|") ;begin a new hardcopy page? There isn't any way to get CLIM to throw a new page. It doesn't have a model of pages. After checking some CLIM postscript output, it seems like the necessary command next-page. So you would do: (format stream "~% next-page ~%") Erik Eilerts eilerts@cs.utexas.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa05017; 5 May 92 18:28 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa04955; 5 May 92 18:24 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1074430; 5 May 1992 18:22:18-0400 Date: Tue, 5 May 1992 18:22-0400 From: Scott McKay Subject: question about args to define-xxx-command To: brentr@sigi.cs.colorado.edu, clim@BBN.COM In-Reply-To: <199205052104.AA28112@sigi.cs.colorado.edu> Message-ID: <19920505222259.5.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 5 May 1992 17:04 EDT From: Brent Reeves Running Genera 8.1 and CLIM 1.0. Compiler tells me: For CLIM Presentation Translator pt-design-unit-to-com-connect-translator CLIM Presentation Translator pt-design-unit-to-com-connect-translator is defined twice in the file NETWORK-DESIGN-CLIM:NETWORK-DESIGN-CLIM;PROGRAM-FRAMEWORK. (define-network-design-command (com-connect :name "Connect" :menu nil) ((du1 'pt-design-unit :gesture :select) (du2 'pt-design-unit :gesture :select)) (pushnew (key du1) (connections du2)) (pushnew (key du2) (connections du1)) (audit "~&~a is now connected to ~a" (key du1) (key du2))) I suppose the two ":gesture :selects" are causing it ("causing" that is in the macro expansion where the translators get defined). How should this be defined instead? Is the connection directional? If not, just remove the ":gesture :select" from one of the two command arguments. If, on the other hand, connections are directional, you will need to have different presentation types (which can share a common supertype) that represent "input" and "output" units. Macroexpand the DEFINE-NETWORK-DESIGN-COMMAND form for more detailed info on what is going on. -brent ---------------------------------------------------------------------- Brent Neal Reeves brentr@cs.colorado.edu (303) 492-1218 "visualize whirled peas"   Received: from BBN.COM by LABS-N.BBN.COM id aa04767; 5 May 92 17:56 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa04122; 5 May 92 17:51 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1074409; 5 May 1992 17:50:04-0400 Date: Tue, 5 May 1992 17:50-0400 From: Scott McKay Subject: CLIM -> Postscript code file question To: curt@eraserhead.jpl.nasa.gov, clim@BBN.COM In-Reply-To: <9205052041.AA01487@eraserhead.Jpl.Nasa.Gov> Message-ID: <19920505215044.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 5 May 1992 16:41 EDT From: Curt Eggemeyer This is a quick dumb question. I wish to produce multiple hardcopy pages of plots from my data objects within CLIM. I know where the pages are relative to my graphics output. How do I start a new page within the with-output-to-postscript-stream construct? Is it something as simple as this: (assume you're in a packaging using CLIM) (with-open-file (f-stream "a-postscript-code-file" :direction :output) (with-output-to-postscript-stream (stream f-stream) .... some graphics output (format stream "~|") ;begin a new hardcopy page? .... more graphics output on the next page )) There isn't any way to get CLIM to throw a new page. It doesn't have a model of pages.   Received: from BBN.COM by LABS-N.BBN.COM id aa09226; 6 May 92 3:24 EDT Received: from iraun1.ira.uka.de by BBN.COM id aa10248; 6 May 92 3:20 EDT Received: from gate.fzi.de by iraun1.ira.uka.de with SMTP (PP) id <01872-0@iraun1.ira.uka.de>; Wed, 6 May 1992 09:19:57 +0000 Received: from goldfinger.fzi.de by gate.fzi.de.fzi.de id aa15315; 6 May 92 7:19 GMT Date: Wed, 6 May 92 7:19:46 GMT From: Rainer Koenig To: clim-request@bbn.com cc: clim@bbn.com Subject: why were we deleted? At: Forschungszentrum Informatik an der Universitaet Karlsruhe Address: Haid-und-Neu-Strasse 10-14, 75 Karlsruhe 1, Germany Hi We haven't got any clim-mail since 1.4.92 (this is not an April fool's trick) Why were we deleted from the list? Could you please add Fzi-info-clim@fzi.de You could delete all other mail-adresses *@fzi.de. thanks Rainer -- Rainer Koenig email: rkoenig@fzi.de Forschungszentrum Informatik king@fzi.de Abtl. Technische Expertensysteme und Robotik Haid-und-Neu-Strasse 10-14 Fax : +49-721-9654-309 W - 7500 Karlsruhe 1 Tel.: +49-721-9654-313   Received: from BBN.COM by LABS-N.BBN.COM id aa13739; 6 May 92 10:49 EDT Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa23912; 6 May 92 10:43 EDT Received: from LILIKOI.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 806496; 6 May 1992 10:42:12-0400 Date: Wed, 6 May 1992 10:54-0400 From: Mark Nahabedian Subject: Re: CLIM -> Postscript code file question To: eilerts@cs.utexas.edu, clim@BBN.COM In-Reply-To: <9205052210.AA00485@sage.cs.utexas.edu> Message-ID: <19920506145421.1.NAHA@LILIKOI.SCRC.Symbolics.COM> Date: Tue, 5 May 1992 18:10 EDT From: Erik Eilerts From: Scott McKay Subject: CLIM -> Postscript code file question Date: Tue, 5 May 1992 16:41 EDT From: Curt Eggemeyer (format stream "~|") ;begin a new hardcopy page? There isn't any way to get CLIM to throw a new page. It doesn't have a model of pages. After checking some CLIM postscript output, it seems like the necessary command next-page. So you would do: (format stream "~% next-page ~%") The problem with this is that the "stream" for above is not the CLIM stream that you are drawing to but the file stream that CLIM's PostScript back end is writing a PostScript program to.   Received: from BBN.COM by LABS-N.BBN.COM id aa13760; 6 May 92 10:54 EDT Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa24115; 6 May 92 10:47 EDT Received: from LILIKOI.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 806503; 6 May 1992 10:46:30-0400 Date: Wed, 6 May 1992 10:58-0400 From: Mark Nahabedian Subject: CLIM -> Postscript code file question To: SWM@STONY-BROOK.SCRC.Symbolics.COM, curt@eraserhead.jpl.nasa.gov, clim@BBN.COM In-Reply-To: <19920505215044.3.SWM@SUMMER.SCRC.Symbolics.COM> Message-ID: <19920506145840.2.NAHA@LILIKOI.SCRC.Symbolics.COM> You might be able to get the behavior you want using the multiple page option of WITH-OUTPUT-TO-POSTSCRIPT-STREAM. Under this option, graphics on the drawing plane which don't fall on the current page get put on the next page. In effect, the drawing plane is carved up into page sized pieces and each piece is printed. To exploit it you would have to position the output of sucessive pages onto different parts of the drawing plane using a translation.   Received: from BBN.COM by LABS-N.BBN.COM id aa13473; 6 May 92 10:26 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa22596; 6 May 92 10:12 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1074697; 6 May 1992 10:10:22-0400 Date: Wed, 6 May 1992 10:11-0400 From: Scott McKay Subject: Re: CLIM -> Postscript code file question To: eilerts@cs.utexas.edu, clim@BBN.COM In-Reply-To: <9205052210.AA00485@sage.cs.utexas.edu> Message-ID: <19920506141104.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 5 May 1992 18:10 EDT From: Erik Eilerts From: Scott McKay Subject: CLIM -> Postscript code file question Date: Tue, 5 May 1992 16:41 EDT From: Curt Eggemeyer (format stream "~|") ;begin a new hardcopy page? There isn't any way to get CLIM to throw a new page. It doesn't have a model of pages. After checking some CLIM postscript output, it seems like the necessary command next-page. So you would do: (format stream "~% next-page ~%") CLIM's model for output is that you draw stuff on a bug plane. On PostScript display devices, the drawing plane is broken up into pages based on page-sized regions in the output history. Just randomly tossing in a newpage could break CLIM's assumptions. So, I wouldn't count on this doing what you want. It might, but if it does there is no guarantee that it will keep working. One thing to remember is that CLIM does not aspire to be a page formatter. Page formatters are fine things, but CLIM just isn't one. Erik Eilerts eilerts@cs.utexas.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa15492; 6 May 92 13:18 EDT Received: from breeze.bellcore.com by BBN.COM id aa00317; 6 May 92 13:10 EDT Received: from ALEX.ims.bellcore.com by breeze.bellcore.com (5.61/1.34) id AA02035; Wed, 6 May 92 13:10:53 -0400 Date: Wed, 6 May 1992 13:10-0400 From: Peter Clitherow Subject: silly presentation question To: clim@bbn.com Message-Id: <19920506171049.9.PC@ALEX.ims.bellcore.com> In dynamic windows, i could present an object with keyword values as: (present object `((type) :key1 ,value) :stream stream) but if i now define: (clim:define-presentation-method present (n (type group) stream view &key curr) ...code ) i can't seem to find the syntax that will allow me to specify the keyword :curr correctly. nor do there seem to be examples in the CLIM demos suite of doing this. the analagous: (clim:present object `((group) :curr T) :stream stream) fails with Error: The value of TYPE is (GROUP :curr T), which is not a presentation-type-specifier. can someone give me the quick fix? thanks pc   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa16655; 6 May 92 14:12 EDT Received: by KARIBA.BBN.COM id aa21741; 6 May 92 14:00 EDT To: clim@BBN.COM cc: jmorrill@BBN.COM Subject: Wanted: readline-no-echo Date: Wed, 06 May 92 13:59:39 -0400 Message-ID: <1856.705175179@bbn.com> From: Jeff Morrill I want a version of read-line that does not echo. I need it to read a password. The following code works in dynamic windows but not in CLIM 1.1 (Allegro 4.1). It does not work because read-char never returns #\rubout, it just beeps, therefore the typist had better not make a mistake. I can't tell if the fault is with CLIM or with Allegro underneath. This is used as the parser for a presentation-type and invoked from an accepting values dialog. What should I do? jeff morrill jmorrill@bbn.com ----------- (defun all-characters (&optional (n (1+ (char-code #\rubout)))) (let ((list nil)) (dotimes (i n) (push (code-char i) list)) list)) (defvar *all-characters* nil) (defun readline-no-echo (stream) ;; The trick to echo suppression is to define every character as an ;; activation character. (let ((all-characters (or *all-characters* (setq *all-characters* (all-characters)))) (return (elt (format nil "~%") 0))) ; implementation-dependent value (with-accept-activation-chars (all-characters :override t) (let ((line (make-array 1 :fill-pointer 0 :adjustable t :element-type 'character))) (loop (let ((char (read-char stream nil nil))) (cond ((eql char return) (return (values line char))) ((eql char #\rubout) (if (zerop (fill-pointer line)) (beep) (decf (fill-pointer line)))) ((not (characterp char)) (beep)) (t (vector-push-extend char line)))))))))   Received: from BBN.COM by LABS-N.BBN.COM id aa18381; 6 May 92 16:25 EDT Received: from PDESDS1.ATG.TRC.SCRA.ORG by BBN.COM id aa11307; 6 May 92 16:18 EDT Received: by pdesds1.atg.trc.scra.org (5.57/Ultrix3.0-C) id AA11188; Wed, 6 May 92 16:17:46 -0400 Date: Wed, 6 May 1992 16:17-0400 From: Craig Lanning Subject: accepting-values-command-pane To: clim@bbn.com Message-Id: <19920506201738.3.CLANNING@PWA.AMRC-PWA.TRC.SCRA.ORG> What is the intended use of CLIM:ACCEPTING-VALUES-COMMAND-PANE and how does one use it? I only found one example of an accepting-values-command-pane and it was a very simple one. Craig Lanning P.S. I am using CLIM 1.0 on a Symbolics (Genera 8.1).   Received: from BBN.COM by LABS-N.BBN.COM id aa18388; 6 May 92 16:26 EDT Received: from PDESDS1.ATG.TRC.SCRA.ORG by BBN.COM id aa11418; 6 May 92 16:20 EDT Received: by pdesds1.atg.trc.scra.org (5.57/Ultrix3.0-C) id AA11205; Wed, 6 May 92 16:20:13 -0400 Date: Wed, 6 May 1992 16:20-0400 From: Craig Lanning Subject: accept-values-command-button To: clim@bbn.com Supersedes: <19920506201738.3.CLANNING@PWA.AMRC-PWA.TRC.SCRA.ORG> Comments: Original message had wrong name Message-Id: <19920506202012.4.CLANNING@PWA.AMRC-PWA.TRC.SCRA.ORG> What is the intended use of CLIM:ACCEPT-VALUES-COMMAND-BUTTON and how does one use it? I only found one example of an accepting-values-command-pane and it was a very simple one. Craig Lanning P.S. I am using CLIM 1.0 on a Symbolics (Genera 8.1).   Received: from BBN.COM by LABS-N.BBN.COM id aa17950; 6 May 92 15:57 EDT Received: from sigi.cs.colorado.edu by BBN.COM id aa09652; 6 May 92 15:51 EDT Received: by sigi.cs.colorado.edu id AA02496 (5.65c/IDA-1.4.4 for clim@bbn.com); Wed, 6 May 1992 13:51:18 -0600 Date: Wed, 6 May 1992 13:51:18 -0600 From: Brent Reeves Message-Id: <199205061951.AA02496@sigi.cs.colorado.edu> To: clim@bbn.com Subject: CLIM 1.0 :gesture nil seems not to work The ":gesture nil" is supposed to allow access to the command "only from a menu" CLIM 1.0 page 198. But the following does not let me click right to get a menu: ;; (Running CLIM 1.0 on Genera 8.1) (define-network-design-command (com-hide-history :name "Hide History Group" :menu nil) ((history-group 'pt-history-group :gesture nil)) ...) My work around has been to write (define-network-design-command (com-hide-history :name "Hide History Group" :menu nil) ((history-group 'pt-history-group :gesture :select)) ...) and then just define the "real" select command first, i.e. if I have 5 commands for this object, and I want one of them to be accessible from the :select gesture, I define all of them to be :gesture :select. The mouse documentation line shows only the first one, the others are then accessible from the normal menu. Any advice on how one is supposed to allow access to a command only from a menu? -brent ---------------------------------------------------------------------- Brent Neal Reeves brentr@cs.colorado.edu (303) 492-1218 "visualize whirled peas"   Received: from BBN.COM by LABS-N.bbn.COM id aa18627; 6 May 92 16:45 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa12193; 6 May 92 16:35 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1074938; 6 May 1992 16:33:59-0400 Date: Wed, 6 May 1992 16:34-0400 From: Scott McKay Subject: Wanted: readline-no-echo To: jmorrill@BBN.COM, clim@BBN.COM In-Reply-To: <1856.705175179@bbn.com> Message-ID: <19920506203444.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 6 May 1992 13:59 EDT From: Jeff Morrill I want a version of read-line that does not echo. I need it to read a password. The following code works in dynamic windows but not in CLIM 1.1 (Allegro 4.1). It does not work because read-char never returns #\rubout, it just beeps, therefore the typist had better not make a mistake. Unfortunately, #\rubout isn't a standard character, and READ-CHAR is only supposed to returns it standard characters. It seems pretty clear that we need a way to disable echoing inside of the input editor... A kludge fix at the end follows at the end of the message. I can't tell if the fault is with CLIM or with Allegro underneath. This is used as the parser for a presentation-type and invoked from an accepting values dialog. What should I do? ---------------- (in-package :clim) ;; Bind this to T to disabled input editor echoing (defvar *disable-input-editor-echo* nil) (defmethod stream-write-char ((istream interactive-stream-mixin) char) (unless *disable-input-editor-echo* (stream-write-char (slot-value istream 'stream) char))) (defmethod stream-write-string ((istream interactive-stream-mixin) string &optional start end) (unless *disable-input-editor-echo* (stream-write-string (slot-value istream 'stream) string start end))) (defmethod redraw-input-buffer ((istream interactive-stream-mixin) &optional (start-position 0)) (with-slots (input-buffer insertion-pointer) istream (multiple-value-bind (x-pos y-pos) (input-buffer-input-position->cursor-position* istream start-position) (stream-set-cursor-position* istream x-pos y-pos)) (macrolet ((do-part (from &optional to) `(do-input-buffer-pieces (input-buffer :start ,from :end ,to) (start-index end-index noise-string) :normal (with-temp-substring (buf input-buffer start-index end-index) (replace buf input-buffer :start2 start-index :end2 end-index) (write-string buf istream)) :noise-string (with-text-style (*noise-string-style* istream) (write-string (noise-string-display-string noise-string) istream))))) (let ((ip (min insertion-pointer (fill-pointer input-buffer)))) (do-part start-position ip) ;; Remember where the cursor goes (at the insertion pointer!) (multiple-value-bind (x-pos y-pos) (stream-cursor-position* istream) (do-part ip) ;; And put it there. (stream-set-cursor-position* istream x-pos y-pos)))) (force-output istream))) ;; Here's an example of it's use. Note that you might need to bind ;; *DISABLE-INPUT-EDITOR-ECHO* around a higher level call to accept in ;; some cases, although I'm not sure of that. (define-presentation-type password () :inherit-from 'string :history nil) (define-presentation-method accept ((type password) stream (view textual-view) &key) (let ((*disable-input-editor-echo* t)) (accept 'string :stream stream :prompt nil :default nil)))   Received: from BBN.COM by LABS-N.BBN.COM id aa18649; 6 May 92 16:50 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa12501; 6 May 92 16:43 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1074943; 6 May 1992 16:41:03-0400 Date: Wed, 6 May 1992 16:41-0400 From: Scott McKay Subject: CLIM 1.0 :gesture nil seems not to work To: brentr@sigi.cs.colorado.edu, clim@BBN.COM In-Reply-To: <199205061951.AA02496@sigi.cs.colorado.edu> Message-ID: <19920506204148.5.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 6 May 1992 15:51 EDT From: Brent Reeves The ":gesture nil" is supposed to allow access to the command "only from a menu" CLIM 1.0 page 198. But the following does not let me click right to get a menu: This works correctly in CLIM 1.1. Depending on who you purchased CLIM from (you didn't say, shame on you :-), you may or may not already have it now. ;; (Running CLIM 1.0 on Genera 8.1) (define-network-design-command (com-hide-history :name "Hide History Group" :menu nil) ((history-group 'pt-history-group :gesture nil)) ...) My work around has been to write (define-network-design-command (com-hide-history :name "Hide History Group" :menu nil) ((history-group 'pt-history-group :gesture :select)) ...) and then just define the "real" select command first, i.e. if I have 5 commands for this object, and I want one of them to be accessible from the :select gesture, I define all of them to be :gesture :select. The mouse documentation line shows only the first one, the others are then accessible from the normal menu. Any advice on how one is supposed to allow access to a command only from a menu? You mean only from a presentation translator menu, right? -brent ---------------------------------------------------------------------- Brent Neal Reeves brentr@cs.colorado.edu (303) 492-1218 "visualize whirled peas"   Received: from BBN.COM by LABS-N.BBN.COM id aa19115; 6 May 92 17:22 EDT Received: from Sunset.AI.SRI.COM by BBN.COM id aa14196; 6 May 92 17:16 EDT Received: from Rockaway.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA00176 for clim@bbn.com; Wed, 6 May 92 14:16:40 PDT Received: by Rockaway.AI.SRI.COM (4.1/SMI-4.1) id AA08777 for clim-support@lucid.com; Wed, 6 May 92 14:16:39 PDT Date: Wed, 6 May 92 14:16:38 PDT From: Peter Karp To: clim@bbn.com Subject: gray levels are SLOW Cc: clim-support@lucid.com Message-Id: I have discovered some very odd behavior with regard to CLIM gray levels. The bottom line is: o Drawing with gray levels G where 1.0 < G < 0.0 is extremely slow. o If in a given session you draw with gray colors, later drawing of pure black-and-white pictures is much slower for the rest of the session. I am using Lucid CLIM 1.0-beta on a Sparc 1+ with a high-resolution monochrome monitor. I am working on a graph-drawing application. (a) When I draw a graph with nodes and edges black, it requires 12 seconds for 200 nodes plus 200 edges. (b) If I then draw nodes in gray level .5, the same graph requires 31 seconds to draw. (c) If I then draw edges in gray level .5, the same graph requires 135 seconds to draw! (d) Furthermore, if I now go back to drawing the same graph with both nodes and edges in black (gray level 1.0), the graph now takes 61 seconds to draw, rather than 12 seconds. In addition, the graph requires noticably more time to scroll. My guess is that (c) takes so long because edges have triangular arrowheads that are drawn using filled polygons. Although all these numbers are quite surprising to me, (d) is quite amazing. It suggests that CLIM has begun using some different type of drawing model. Comments? Will any of this be improved in CLIM 1.1 or 2.0? Use of gray levels is not crucial for us, but I thought I'd let people know about this. Peter   Received: from BBN.COM by LABS-N.BBN.COM id aa19230; 6 May 92 17:32 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa14537; 6 May 92 17:27 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1074963; 6 May 1992 17:25:04-0400 Date: Wed, 6 May 1992 17:25-0400 From: Scott McKay Subject: accepting-values-command-pane To: CLanning@pdesds1.atg.trc.scra.org, clim@BBN.COM In-Reply-To: <19920506201738.3.CLANNING@PWA.AMRC-PWA.TRC.SCRA.ORG> Message-ID: <19920506212549.7.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 6 May 1992 16:17 EDT From: Craig Lanning What is the intended use of CLIM:ACCEPTING-VALUES-COMMAND-PANE and how does one use it? I only found one example of an accepting-values-command-pane and it was a very simple one. Craig Lanning P.S. I am using CLIM 1.0 on a Symbolics (Genera 8.1). It provides the function of a "modeless dialog" embedded in the pane of an application. ---------------- ;;; -*- Mode: LISP; Syntax: ANSI-Common-lisp; Package: CLIM-USER; Base: 10; Lowercase: Yes -*- (in-package :clim-user) (define-application-frame sample () ((pathname :initform nil) (integer :initform 0) (boolean :initform nil)) (:command-table (browser :inherit-from (accept-values-pane))) (:panes ((display :application :display-function 'display-sample :display-after-commands ':no-clear) (interactor :interactor) (control-panel :accept-values :display-function '(accept-values-pane-displayer :displayer accept-sample-options)))) (:layout ((default (:column 1 (display :rest) (:row 1/2 (:row :rest (interactor 1/2 ) (control-panel :rest)))))))) (defmethod accept-sample-options ((frame sample) stream) (with-slots (pathname integer boolean) frame (flet ((accept (type default prompt) (fresh-line stream) (accept type :stream stream :default default :prompt prompt))) (setq pathname (accept '(null-or-type pathname) pathname "A pathname")) (setq integer (accept 'integer integer "An integer")) (setq boolean (accept 'boolean boolean "A boolean"))))) (defmethod display-sample ((frame sample) stream) (with-slots (pathname integer boolean) frame (format stream "~&~S ~S ~S~%" pathname integer boolean))) (run-frame-top-level (make-application-frame 'sample :width 600 :height 240 :parent (first clim::*sheet-roots*)))   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa19861; 6 May 92 18:48 EDT Received: by KARIBA.BBN.COM id aa22693; 6 May 92 18:37 EDT To: Scott McKay cc: clim@BBN.COM Subject: Re: Wanted: readline-no-echo In-reply-to: Your message of Wed, 06 May 92 16:34:00 -0400. <19920506203444.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 06 May 92 18:35:55 -0400 Message-ID: <2136.705191755@bbn.com> From: Jeff Morrill Thanks. It works real groovy. I can see a potential problem with XJ313's specification for echo streams here. Presumably a frame pane is (or will be) an echo stream, and yet there are times when you want to read a string from a frame pane without echoing (e.g. passwords). There might be a reason to add a new reader control variable, *read-echo*, for this case. Now, no one is going to want to turn off input echoing very often, but I think *read-echo* would be a far sight more useful than *read-base*. Just daydreaming... JeffM   Received: from BBN.COM by LABS-N.BBN.COM id aa20243; 6 May 92 19:39 EDT Received: from akbar.franz.com by BBN.COM id aa18204; 6 May 92 19:35 EDT Return-Path: Received: by akbar.Franz.COM (4.1/FI-2.0) id AA13260; Wed, 6 May 92 16:35:24 PDT Date: Wed, 6 May 92 16:35:24 PDT From: smh@Franz.COM (Steve Haflich) Message-Id: <9205062335.AA13260@akbar.Franz.COM> To: jmorrill@BBN.COM Cc: SWM@stony-brook.scrc.symbolics.com, clim@BBN.COM In-Reply-To: Jeff Morrill's message of Wed, 06 May 92 18:35:55 -0400 <2136.705191755@bbn.com> Subject: Wanted: readline-no-echo From: Jeff Morrill ... I can see a potential problem with XJ313's specification for echo streams here. Presumably a frame pane is (or will be) an echo stream, and yet there are times when you want to read a string from a frame pane without echoing (e.g. passwords). There might be a reason to add a new reader control variable, *read-echo*, for this case. X3J13 actually specifies accessors for the components of an echo stream: ECHO-STREAM-INPUT-STREAM and ECHO-STREAM-OUTPUT-STREAM. They are new, so not all implementations provide them yet. I really don't want to get sucked too deep into the issue whether a frame pane actually would be implemented as an echo stream, but in fact it seems unlikely. The original STREAM-DEFINITION-BY-USER proposal by David Gray pointed out that the compound stream of the original CLtL specification (echo-, broadcast-, two-way-, and concatentated-) are antithetical to the architecture of subclassable closified stream types. For instance, a generic function that needs to descriminate on stream class has an intractible problem with an echo stream. There is no automatic way for the gf to discriminate on either the input stream or output stream -- only the echo stream is available to the gf discrimination mechanism.   Received: from BBN.COM by LABS-N.BBN.COM id aa27976; 7 May 92 9:48 EDT Received: from mcsun.EU.net by BBN.COM id aa09583; 7 May 92 9:39 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA26255 (5.65b/CWI-2.160); Thu, 7 May 1992 15:39:21 +0200 Received: by ub4b.buug.be (5.64+/ub4b_02) id AA01317; Thu, 7 May 92 15:34:29 +0200 Received: from scosysv by nrb.be (DECUS UUCP ///1.3-1/2.5/); Thu, 7 May 92 15:20:29 +0200 Received: from milou.nrb.be by scosysv.nrb.be with SMTP (5.59/25-e-eef-ev@nrb) id AA04039; Thu, 7 May 92 20:03:05 CET Received: from nrbmi1.nrb.be by milou.nrb.be via CHAOS with SMTP id 27793; 7 May 1992 15:00:52+0200 Date: Thu, 7 May 1992 15:15+0200 From: Vincent Keunen Reply-To: scosysv!keunen@nrb.be Subject: [teskridg@NMSU.Edu: future MCL] To: clim@milou.nrb.be, mcl@milou.nrb.be Included-Msgs: <9204291947.AA25681@NMSU.Edu>, The message of 29 Apr 1992 21:47+0200 from teskridg@NMSU.Edu Included-References: <9204291206.AA20775@hsvaic.boeing.com>, The message of 29 Apr 1992 14:06+0200 from George Williams Message-Id: <19920507131543.3.KEUNEN@nrbmi1.nrb.be> I've seen the announcements, but have never seen what it can do. How does it compare to CLIM in terms of functionality? I don't have a copy of CLIM so I cant really comment on how they compare. I do know that GARNET has a great variety of features that are commonly used by application developers. I've used GARNET on a couple of projects and have had no complaints or missing features. I'm using CLIM and very satisfied. I am often surprised by how much it does. It's the kind of software that impresses me very much. Also, it's very deep. Some of its features are: - a very strong link between application objects and their visual appearance on the screen (you don't know how useful this is until you've used it, but after, you can't live without it) - presentation types for easy and modular input/output - abstractions for interfaces (text styles, inks,...) independant of the host but linked to what the programmer really wants (cf emphasizing rather than writing in bold, cf +flipping-ink+...) - good drawing capabilities (with COLOR) - AUTOMATIC INCREMENTAL REDISPLAY - command management (a good abstraction for all user actions, for all kinds of actions,... predefined input editor,...) - high level output capabilities (automatic table and graph generation) - integrated help system - low level features like pointer manipulation,... - output to postscript stream (means the postscript code is automatically generated if you write to these kinds of streams) Some of the things missing, to my point of view are "undo" capabilities (as in GINA), more close to the host look and feel (but I suppose it's the goal of CLIM 2, which I have not seen yet). More globally, CLIM seems pretty clean and well designed to me. Also, the specs for CLIM 2 clearly define the protocols to the differents layers of CLIM for easy programmer access and I like that. Vincent Keunen   Received: from BBN.COM by LABS-N.BBN.COM id ab27976; 7 May 92 9:48 EDT Received: from mcsun.EU.net by BBN.COM id aa09606; 7 May 92 9:40 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA26275 (5.65b/CWI-2.160); Thu, 7 May 1992 15:39:42 +0200 Received: by ub4b.buug.be (5.64+/ub4b_02) id AA01336; Thu, 7 May 92 15:34:50 +0200 Received: from scosysv by nrb.be (DECUS UUCP ///1.3-1/2.5/); Thu, 7 May 92 15:20:45 +0200 Received: from milou.nrb.be by scosysv.nrb.be with SMTP (5.59/25-e-eef-ev@nrb) id AA04062; Thu, 7 May 92 20:12:38 CET Received: from nrbmi1.nrb.be by milou.nrb.be via CHAOS with SMTP id 27794; 7 May 1992 15:10:26+0200 Date: Thu, 7 May 1992 15:25+0200 From: Vincent Keunen Reply-To: scosysv!keunen@nrb.be Subject: Mac icons in CLIM To: clim@milou.nrb.be, mcl@milou.nrb.be Message-Id: <19920507132522.4.KEUNEN@nrbmi1.nrb.be> I'd like to use mac icons in clim. I've read about the format of icons (patterns) in clim and was wondering if one of the mac icon editors would be able to generate the textual representation from the icons themselves. I must confess I don't know much about icons... The goal is to reuse some of the freeware icons already available on the mac in clim. Thanks Vincent   Received: from BBN.COM by LABS-N.BBN.COM id aa27510; 7 May 92 9:25 EDT Received: from mcsun.EU.net by BBN.COM id aa06950; 7 May 92 9:04 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA22417 (5.65b/CWI-2.160); Thu, 7 May 1992 15:04:05 +0200 Received: by ub4b.buug.be (5.64+/ub4b_02) id AA29418; Thu, 7 May 92 14:59:13 +0200 Received: from scosysv by nrb.be (DECUS UUCP ///1.3-1/2.5/); Thu, 7 May 92 15:06:41 +0200 Received: from milou.nrb.be by scosysv.nrb.be with SMTP (5.59/25-e-eef-ev@nrb) id AA04008; Thu, 7 May 92 19:45:13 CET Received: from nrbmi1.nrb.be by milou.nrb.be via CHAOS with SMTP id 27792; 7 May 1992 14:42:53+0200 Date: Thu, 7 May 1992 14:57+0200 From: Vincent Keunen Reply-To: scosysv!keunen@nrb.be Subject: Re: future MCL To: mcl@milou.nrb.be, clim@milou.nrb.be In-Reply-To: <9204291135.AA05849@sun.gte.com> Message-Id: <19920507125744.2.KEUNEN@nrbmi1.nrb.be> I really do agree with Rich Brandau on the following points and would like to stress what he said: Date: Wed, 29 Apr 1992 13:35+0200 From: Rich Brandau [...] Garnet may be OK, but it's not as "standard" as CLIM. And I wouldn't exactly call it "public domain," given the legal hurdles CMU's lawyers have set up for using it. It also seems less powerful than CLIM, though that's only based on my reading of the docs. As for CLIM 2.0, it's crucial to the survival of MCL. I hope ILA will supply it and make piles of money from it. They deserve it: Together with its Dynamic Windows predecessor, it represents the best user/program interface ideas I've seen, and showcases LISP's development and runtime capabilities. It provides a natural way to do valuable things that *cannot* be done in a non-LISP environment. Vincent Keunen   Received: from BBN.COM by LABS-N.BBN.COM id aa27623; 7 May 92 9:32 EDT Received: from unido.Germany.EU.net by BBN.COM id aa08200; 7 May 92 9:21 EDT Received: from sger by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA10441; Thu, 7 May 92 15:21:09 +0200 Received: from FUJI-SAN.SGER.UUCP ([192.1.2.67]) by sger.SGER.COM (4.1/SMI-4.1) id AA00471; Thu, 7 May 92 14:53:32 +0200 Date: Thu, 7 May 1992 15:01+0200 From: Markus Fischer Subject: (not so) silly presentation question To: pc@breeze.bellcore.com, clim@BBN.COM In-Reply-To: <19920506171049.9.PC@ALEX.ims.bellcore.com> Message-Id: <19920507130147.6.MF@FUJI-SAN.SGER.UUCP> Date: Wed, 6 May 1992 19:10+0200 From: Peter Clitherow In dynamic windows, i could present an object with keyword values as: (present object `((type) :key1 ,value) :stream stream) but if i now define: (clim:define-presentation-method present (n (type group) stream view &key curr) ...code ) In CLIM, :key1 is called a presentation type option. You have to explicitly declare them within define-presentation-type, e.g. (define-presentation-type group () :options (key1)) Within a present method, you have implicitly access to options of the presentation type. You may not set them in the lambda list of the present method. Just *use* the variable named key1. Please see the clim doc for more information about presentation type options and parameters. i can't seem to find the syntax that will allow me to specify the keyword :curr correctly. nor do there seem to be examples in the CLIM demos suite of doing this. the analagous: (clim:present object `((group) :curr T) :stream stream) fails with Error: The value of TYPE is (GROUP :curr T), which is not a presentation-type-specifier. can someone give me the quick fix? thanks pc Markus Fischer Consulting Services Symbolics Systemhaus GmbH Mergenthaler Allee 77-81 W-6236 Eschborn Germany Phone: +49 6196 47220 Fax: +49 6196 481116 e-mail: MF@sger.uucp   Received: from BBN.COM by LABS-N.BBN.COM id aa29136; 7 May 92 11:07 EDT Received: from brazil.cambridge.apple.com by BBN.COM id aa15103; 7 May 92 10:51 EDT Received: from ministry.cambridge.apple.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef) id AA24852; Thu, 7 May 92 10:56:35 -0400 for jmorrill@BBN.COM Received: from [90.223.0.20] by cambridge.apple.com with SMTP (5.64/25-eef) id AA03311; Thu, 7 May 92 10:45:58 -0400 Message-Id: <9205071445.AA03311@cambridge.apple.com> Date: Thu, 07 May 92 10:52:29 EST From: kab@cambridge.apple.com (Kim Barrett) To: Steve Haflich Subject: Re: Wanted: readline-no-echo Cc: jmorrill@BBN.COM, SWM@stony-brook.scrc.symbolics.com, clim@BBN.COM > The original STREAM-DEFINITION-BY-USER > proposal by David Gray pointed out that the compound stream of the > original CLtL specification (echo-, broadcast-, two-way-, and > concatentated-) are antithetical to the architecture of subclassable > closified stream types. For instance, a generic function that needs > to descriminate on stream class has an intractible problem with an > echo stream. There is no automatic way for the gf to discriminate on > either the input stream or output stream -- only the echo stream is > available to the gf discrimination mechanism. Its actually not as difficult as you think. You can get a lot of mileage out of delegation via no-applicable-method and friends. > I really don't want to get sucked too deep into the issue whether a > frame pane actually would be implemented as an echo stream, but in > fact it seems unlikely. I would not expect it to be an echo-stream either. Unfortunately, people have a tendency to read too much into the names of these compound stream classes, and end up believing them to have all sorts of magical behavior.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa00442; 7 May 92 12:44 EDT Received: by KARIBA.BBN.COM id ab24458; 7 May 92 12:32 EDT To: Kim Barrett cc: clim@BBN.COM Subject: Re: Wanted: readline-no-echo In-reply-to: Your message of Thu, 07 May 92 10:52:29 -0500. <9205071445.AA03311@cambridge.apple.com> Date: Thu, 07 May 92 12:27:40 -0400 Message-ID: <2251.705256060@bbn.com> From: Jeff Morrill Date: Thu, 07 May 92 10:52:29 EST From: Kim Barrett To: Steve Haflich Subject: Re: Wanted: readline-no-echo Cc: jmorrill@BBN.COM, SWM@stony-brook.scrc.symbolics.com, clim@BBN.COM > I really don't want to get sucked too deep into the issue whether a > frame pane actually would be implemented as an echo stream, but in > fact it seems unlikely. I would not expect it to be an echo-stream either. Unfortunately, people have a tendency to read too much into the names of these compound stream classes, and end up believing them to have all sorts of magical behavior. Ok, so its not an echo stream. I am just trying to apply the following passage to User Interfaces, from the Book of Steele, Verse 22.2.1: "XJ313 voted in January 1989 <138> to clarify the interaction of read-char with echo-streams (as created by make-echo-stream). A character is echoed from the input stream to the associated output stream the first time it is seen." If you want to implement (defun readline-no-echo (&optional (stream *standard-input*)) ...) then the problem I suggested for echo-streams can be legislated away in any number of ways: a) It is an error to use an echo-stream as the input to the function. I am willing to accept this solution if CLIM promises not to give me one as the binding of *standard-input*. b) encapsulate STREAM with a special stream that knows how not to echo c) tell STREAM how not to echo by temporarily setting the echo-stream output-stream to something that just dumps the echo output on the floor. JeffM   Received: from BBN.COM by LABS-N.BBN.COM id aa01463; 7 May 92 13:58 EDT Received: from brazil.cambridge.apple.com by BBN.COM id aa22625; 7 May 92 13:53 EDT Received: from ministry.cambridge.apple.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef) id AA25377; Thu, 7 May 92 13:58:57 -0400 for jmorrill@BBN.COM Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef) id AA07378; Thu, 7 May 92 13:48:20 -0400 Message-Id: <9205071748.AA07378@cambridge.apple.com> Date: Thu, 07 May 92 13:56:14 EDT From: moon@cambridge.apple.com (David A. Moon) To: Jeff Morrill Subject: Re: Wanted: readline-no-echo Cc: Scott McKay , clim@BBN.COM > Date: Wed, 06 May 92 18:35:55 -0400 > From: Jeff Morrill > .... Presumably a frame pane is (or will be) > an echo stream .... No I don't think those wacky stream classes defined by Common Lisp are generally used for anything, in or out of CLIM. It was probably a mistake to include them in the language.   Received: from BBN.COM by LABS-N.BBN.COM id aa05296; 7 May 92 17:45 EDT Received: from cs.utexas.edu by BBN.COM id aa07430; 7 May 92 17:34 EDT Received: from sage.cs.utexas.edu by cs.utexas.edu (5.64/1.129) with SMTP id AA01531; Thu, 7 May 92 16:34:06 -0500 Received: by sage.cs.utexas.edu (5.64/Client) id AA03803; Thu, 7 May 92 16:33:49 -0500 Message-Id: <9205072133.AA03803@sage.cs.utexas.edu> From: eilerts@cs.utexas.edu (Erik Eilerts) Date: Thu, 7 May 1992 16:33:49 -0500 X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: clim@bbn.com Subject: Multiple Application Frames I have tried the following: 1. make a clim-root using open-root-window 2. spawn a process that makes an application frame whose parent is the clim-root 3. spawn another process that makes an application frame whose parent is the clim-root At this point, I usually get an error message about not being able to grab a lock or something like that. I assume that the problem is that application frames that have the same parent cannot be run in separate processes because of the io locks used by the clim-root. Is this the case? Thanks, Erik Eilerts University of Texas at Austin eilerts@cs.utexas.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa10411; 8 May 92 4:49 EDT Received: from fenrix.si.no by BBN.COM id aa18801; 8 May 92 4:40 EDT Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.22) id AA04133; Fri, 8 May 92 09:44:42 +0200 Date: Fri, 8 May 92 09:44:42 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9205080741.AAmonsun03636@D> To: clim@bbn.com Subject: CLIM 2.0 In an announcement (perhaps not official) on the net recently it was stated that a draft specification of CLIM 2.0 was released for public review or something like that. Who is allowed to look at and comment on this specification? If all CLIM users (I mean all who have bought CLIM) can have one, how can I get hold of one? Is there and ftp site? If anyone at ILA reads this, can (s)he send me a copy? There are several things I would like to do that may need a little digging inside CLIM. If the 2.0 version documents the protocols between layers, then it might be done cleanly. I'm very much looking forward to reading the specification. Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.BBN.COM id aa11666; 8 May 92 6:46 EDT Received: from mcsun.EU.net by BBN.COM id aa20665; 8 May 92 6:41 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA24049 (5.65b/CWI-2.160); Fri, 8 May 1992 12:41:19 +0200 Received: by ub4b.buug.be (5.64+/ub4b_02) id AA23985; Fri, 8 May 92 12:36:21 +0200 Received: from scosysv by nrb.be (DECUS UUCP ///1.3-1/2.5/); Fri, 8 May 92 12:43:36 +0200 Received: from milou.nrb.be by scosysv.nrb.be with SMTP (5.59/25-e-eef-ev@nrb) id AA05466; Fri, 8 May 92 17:10:15 CET Received: from scosysv.nrb.be by milou.nrb.be via INTERNET with SMTP id 27823; 8 May 1992 12:08:04+0200 Received: from nrb.UUCP by scosysv.nrb.be with UUCP (5.59/25-e-eef-ev@nrb) id AA05460; Fri, 8 May 92 17:10:08 CET Received: from MIT.EDU by nrb.be (DECUS UUCP ///1.3-1/2.5/); Fri, 8 May 92 07:39:31 +0200 Received: from MIT.MIT.EDU by ub4b.buug.be (5.64+/ub4b_02) id AA11299; Thu, 7 May 92 23:10:12 +0200 Received: from KORUNA.MIT.EDU by MIT.EDU with SMTP id AA25047; Thu, 7 May 92 17:14:37 EDT Message-Id: <9205072114.AA25047@MIT.EDU> Date: Thu, 07 May 92 14:30:09 EST From: scosysv!cfry@MIT.EDU (Christopher Fry) To: keunen@nrb.be Subject: Re: [teskridg@NMSU.Edu: future MCL] Cc: clim@milou.nrb.be, info-mcl@cambridge.apple.com, York@chuck-jones.west.dialnet.ila.com > From: Vincent Keunen > I'm using CLIM and very satisfied. I am often surprised by how much it > does. It's the kind of software that impresses me very much. Also, > it's very deep. > > Some of its features are: > - a very strong link between application objects and their visual > appearance on the screen (you don't know how useful this is until you've > used it, but after, you can't live without it) > - presentation types for easy and modular input/output > - abstractions for interfaces (text styles, inks,...) independant of > the host but linked to what the programmer really wants (cf emphasizing > rather than writing in bold, cf +flipping-ink+...) > - good drawing capabilities (with COLOR) > - AUTOMATIC INCREMENTAL REDISPLAY > - command management (a good abstraction for all user actions, for all > kinds of actions,... predefined input editor,...) > - high level output capabilities (automatic table and graph generation) > - integrated help system > - low level features like pointer manipulation,... > - output to postscript stream (means the postscript code is > automatically generated if you write to these kinds of streams) > > > Some of the things missing, to my point of view are "undo" capabilities > (as in GINA), more close to the host look and feel (but I suppose it's > the goal of CLIM 2, which I have not seen yet). > > > More globally, CLIM seems pretty clean and well designed to me. Also, > the specs for CLIM 2 clearly define the protocols to the differents > layers of CLIM for easy programmer access and I like that. This is the best report on CLIM that I've seen yet. Permit me to probe a little deeper. You are speaking of CLIM1 running on MCL, right? Is all of the functionality that you describe in the Symbolics "CLIM Release 1.0" manual, March 1991? If there is significant additional documentation, please let me know what. Are you familiar with the MCL2 window system? Other than a Mac-look what other features are in MCL window system that are not easily done in CLIM 1? If you were NOT planning on porting your code to a non-mac, would you prefer CLIM 1 over MCL windows? & why. My appliction needs multiply nested views, each of which may be independently scrolled. Can CLIM 1 support this? Is CLIM1 on a Mac significantly slower than MCL windows? Reliability? Have you used Quicktime with CLIM1? I'm thinking of showing a videoclip inside a pane in a window and am wondering if this is going to be much harder in CLIM than MCL windows.   Received: from BBN.COM by LABS-N.BBN.COM id aa14173; 8 May 92 11:12 EDT Received: from sigi.cs.colorado.edu by BBN.COM id aa01679; 8 May 92 11:04 EDT Received: by sigi.cs.colorado.edu id AA09156 (5.65c/IDA-1.4.4 for clim@bbn.com); Fri, 8 May 1992 09:04:17 -0600 Date: Fri, 8 May 1992 09:04:17 -0600 From: Brent Reeves Message-Id: <199205081504.AA09156@sigi.cs.colorado.edu> To: clim@bbn.com Subject: Pointer-documentation line on blank-area translator Is there a way to get a pointer-documentation line on a blank-area translator? (CLIM 1.0 Genera 8.1) The following translator works, but the pointer-doc line does not get displayed. (define-presentation-to-command-translator select-objects (clim:blank-area com-select-objects network-design :gesture :select :pointer-documentation ((object stream) (declare (ignore object)) (format stream "Select Objects via Rubberbanded Rectangle"))) (x y) `(,x ,y)) -brent ---------------------------------------------------------------------- Brent Neal Reeves brentr@cs.colorado.edu (303) 492-1218 "visualize whirled peas"   Received: from BBN.COM by LABS-N.BBN.COM id aa15208; 8 May 92 12:32 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa05371; 8 May 92 12:27 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1075899; 8 May 1992 12:25:21-0400 Date: Fri, 8 May 1992 12:26-0400 From: Scott McKay Subject: Pointer-documentation line on blank-area translator To: brentr@sigi.cs.colorado.edu, clim@BBN.COM In-Reply-To: <199205081504.AA09156@sigi.cs.colorado.edu> Message-ID: <19920508162616.0.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 8 May 1992 11:04 EDT From: Brent Reeves Is there a way to get a pointer-documentation line on a blank-area translator? (CLIM 1.0 Genera 8.1) Fixed in CLIM 1.1 The following translator works, but the pointer-doc line does not get displayed. (define-presentation-to-command-translator select-objects (clim:blank-area com-select-objects network-design :gesture :select :pointer-documentation ((object stream) (declare (ignore object)) (format stream "Select Objects via Rubberbanded Rectangle"))) (x y) `(,x ,y)) -brent ---------------------------------------------------------------------- Brent Neal Reeves brentr@cs.colorado.edu (303) 492-1218 "visualize whirled peas"   Received: from BBN.COM by LABS-N.BBN.COM id aa19687; 11 May 92 18:23 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa02282; 11 May 92 18:12 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA09469; Mon, 11 May 92 14:30:50 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA00811; Mon, 11 May 92 14:24:23 PDT Date: Mon, 11 May 92 14:24:23 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9205112124.AA00811@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: Command tables/menus (CLIM 1.0) This is a quickie how to question. My situation is as follows: I want each of my command-tables to appear as a single item on my :command-menu pane. When I click on one of them then a sub-menu of a subset of the commands within that command-table to appear for selection. I also want every command within all of my commands invokable from an interactor pane. I know I can use add-menu-item-to-command-table or include the sub-command spec in the define-command-table :menu form, but that means I have my menu specification separate from my command which seems messy. Is there a way to get something like the example below to do what I want? Is there something trivial I am missing? (define-command-table one) ;it would be nice if there was a :menu t option (define-command-table two) (define-application-frame whatever () () (:panes (app :application) (active :interactor) (top-most-menu :command-menu)) (layout ((normal (column 1 (:row 1/50 (one 1/2) (two 1/2)) (:row 1/10) (:row :rest app))))) (:command-table (t :inherit-from (one two)))) (define-command (test1 :command-table one :menu t :name t) () ...) (define-command (test2 :command-table one :menu t :name t) () ...) (define-command (test3 :command-table one :menu t :name t) () ...) ;;Here we have 3 different commands in command-table two but their menu ;;items appear similar to those in command-table one's! (define-command (test4 :command-table two :menu "test1" :name t) () ...) (define-command (test5 :command-table two :menu "test2" :name t) () ...) (define-command (test6 :command-table two :menu "test3" :name t) () ...) ... etc.   Received: from BBN.COM by LABS-N.BBN.COM id aa24205; 12 May 92 6:18 EDT Received: from chx400.switch.ch by BBN.COM id aa00429; 12 May 92 6:12 EDT X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/; Relayed; Tue, 12 May 1992 12:03:13 +0200 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Tue, 12 May 1992 12:02:24 +0200 X400-Received: by /PRMD=ch/ADMD=/C=/; Relayed; Tue, 12 May 1992 12:02:20 +0200 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Tue, 12 May 1992 12:02:23 +0200 Date: Tue, 12 May 1992 12:02:23 +0200 X400-Originator: schneide@divsun.unige.ch X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=SWITCH/ADMD=ARCOM/C=CH/;920512120223] X400-Content-Type: P2-1984 (2) Content-Identifier: 478 Conversion: Prohibited From: Schneider Daniel Message-ID: <478*/S=schneide/OU=divsun/O=unige/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> To: clim , Curt Eggemeyer Subject: RE: Command tables/menus (CLIM 1.0) > From: Curt Eggemeyer > > This is a quickie how to question. My situation is as follows: > > I want each of my command-tables to appear as a single item on my > :command-menu pane. When I click on one of them then a sub-menu of a > subset of the commands within that command-table to appear for selection. > I also want every command within all of my commands invokable from an > interactor pane. I know I can use add-menu-item-to-command-table or include the sub-command spec in the define-command-table :menu form, but that > means I have my menu specification separate from my command which seems > messy. Is there a way to get something like the example below to do what > I want? Is there something trivial I am missing? > I use "menu-choose-command-from-command-table" and "execute-frame-command" quite often. Both are documented in the manual. Maybe you could use that too. There is some advantage in writing an extra command for popping up a menu. It will allow you to tie a menu also to a mouse gesture and every user gesture goes through a command (I never use "menu-choose" for selecting operations, but use commands instead). I don't know whether this is the right way to do things, any comments? cheers - Daniel (defmacro execute-command-from-menu (frame command-table &optional (label "Choose a command") (object nil)) "Pops up a menu of a command table and executes a selected command" `(let ((command (menu-choose-command-from-command-table ,command-table :cache t :default-style *pop-up-menu-font* :associated-window (frame-top-level-window ,frame) :label ,label))) (when command (if ,object (execute-frame-command ,frame ;; this builds a command object (cons of name + args) (list (car command) ,object)) (execute-frame-command ,frame command))) )) ;; Example using this macro ;; (define-memolab-command (com-lab-exit-load-save-menu :menu "Exit/Load/Save..") () (execute-command-from-menu *application-frame* 'lab-exit-load-save-menu "Exit/Load/Save Menu")) ;; A command in the command table ;; (define-command (com-save-memolab-laboratory :menu "SAVE Laboratory" :command-table lab-exit-load-save-menu) () (save-lab clim:*application-frame*) ) ;; ....... ;; ---------------- ;; Example of two different menus doing the same thing. In the first you can ;; click on an object and then select from the menu. In the second you first ;; select an object form a menu and then select a command. ;; pops up a menu of commands in a command-table ;; (define-memolab-command (com-direct-events-menu) ((obj 'lab-events :gesture :choice)) (execute-command-from-menu *application-frame* 'lab-events-table "Events Menu" obj)) (defun object-and-operation-menu (stream object-list command-or-function &optional (label "Make a Selection")) "takes a list of objects, lets the user select one and applies function" (let ((obj (menu-choose `(,@(mapcar #'(lambda (obj) (list (name-string obj) :value obj)) object-list)) ;; :cache t :n-columns 3 :cell-align-x :left :default-style *pop-up-menu-small-font* :associated-window stream :label label) )) (when obj (funcall command-or-function obj)))) ;; makes a call to the command above ;; (define-command (com-display-events-then-direct-events-menu :menu "DO something with an event" :command-table lab-event-menu-table) () (object-and-operation-menu (frame-top-level-window *application-frame*) (lab-database-events (memolab-laboratory *application-frame*)) #'com-direct-events-menu ;; <==== "Select an Event")) -------- Daniel K.Schneider, TECFA (Educational Technologies and Learning) Faculte de Psychologie et des Sciences de l'Education, University of Geneva, 1211 Geneva 4 (Switzerland), Tel.(..41)22 705 7652, Fax. (..41) 22 20 29 27. Internet: schneide@divsun.unige.ch (and various national nets) | if reply CSnet/ARPA: schneide%divsun.unige.ch@relay.cs.net (old style) | does not X400: S=schneide;OU=divsun;O=unige;PRMD=switch;ADMD=arcom;C=ch | work, uucp: mcvax!cui!divsun.unige.ch!shneider | try one BITNET: schneide@cgeuge51 | of DECNET: UGUN2A::SCHNEIDE (local Swiss) | these   Received: from BBN.COM by LABS-N.BBN.COM id aa26114; 12 May 92 8:53 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa04158; 12 May 92 8:48 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA14464; Tue, 12 May 92 05:47:56 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA00877; Tue, 12 May 92 05:41:29 PDT Date: Tue, 12 May 92 05:41:29 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9205121241.AA00877@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: Super quickie CLIM question I noticed in the CLIM manual that the size-specification in the application frame's layout form is only refered to being a real number between 0 & 1. As I recalled from the ole dynamic windows constraint layout form you were allowed to input that size-spec also in either pixel or character size notation. Has that capability been lost in CLIM? If not has it changed?   Received: from BBN.COM by LABS-N.BBN.COM id aa27268; 12 May 92 10:25 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa10112; 12 May 92 10:16 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1077171; 12 May 1992 10:14:23-0400 Date: Tue, 12 May 1992 10:15-0400 From: Scott McKay Subject: Command tables/menus (CLIM 1.0) To: curt@eraserhead.jpl.nasa.gov, clim@BBN.COM In-Reply-To: <9205112124.AA00811@eraserhead.Jpl.Nasa.Gov> Message-ID: <19920512141539.7.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 11 May 1992 17:24 EDT From: Curt Eggemeyer This is a quickie how to question. My situation is as follows: I want each of my command-tables to appear as a single item on my :command-menu pane. When I click on one of them then a sub-menu of a subset of the commands within that command-table to appear for selection. I also want every command within all of my commands invokable from an interactor pane. I know I can use add-menu-item-to-command-table or include the sub-command spec in the define-command-table :menu form, but that means I have my menu specification separate from my command which seems messy. Is there a way to get something like the example below to do what I want? Is there something trivial I am missing? (define-command-table one) ;it would be nice if there was a :menu t option (define-command-table two) (define-application-frame whatever () () (:panes (app :application) (active :interactor) (top-most-menu :command-menu)) (layout ((normal (column 1 (:row 1/50 (one 1/2) (two 1/2)) (:row 1/10) (:row :rest app))))) (:command-table (t :inherit-from (one two)))) (define-command (test1 :command-table one :menu t :name t) () ...) (define-command (test2 :command-table one :menu t :name t) () ...) (define-command (test3 :command-table one :menu t :name t) () ...) ;;Here we have 3 different commands in command-table two but their menu ;;items appear similar to those in command-table one's! (define-command (test4 :command-table two :menu "test1" :name t) () ...) (define-command (test5 :command-table two :menu "test2" :name t) () ...) (define-command (test6 :command-table two :menu "test3" :name t) () ...) ... etc. The CLIM test suites, the source of which is included with CLIM distributions in SYS:CLIM;TESTS;TEST-SUITE.LISP, does exactly this. (define-command-table graphics) (define-command (... :command-table graphics) ...) (define-command (... :command-table graphics) ...) (define-command-table output-recording) (define-command (... :command-table output-recording) ...) (define-command (... :command-table output-recording) ...) ... (define-application-frame clim-tests () () (:command-table (clim-tests :inherit-from (graphics output-recording formatted-output redisplay presentations menus-and-dialogs benchmarks) :menu (("Graphics" :menu graphics) ("Output Recording" :menu output-recording) ("Formatted Output" :menu formatted-output) ("Redisplay" :menu redisplay) ("Presentations" :menu presentations) ("Menus and Dialogs" :menu menus-and-dialogs) ("Benchmarks" :menu benchmarks) ("Exit" :command (exit-clim-tests))))) (:command-definer nil) (:panes ...) (:layout ...))   Received: from BBN.COM by LABS-N.BBN.COM id aa27167; 12 May 92 10:20 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa09998; 12 May 92 10:13 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1077170; 12 May 1992 10:10:59-0400 Date: Tue, 12 May 1992 10:12-0400 From: Scott McKay Subject: Super quickie CLIM question To: curt@eraserhead.jpl.nasa.gov, clim@BBN.COM In-Reply-To: <9205121241.AA00877@eraserhead.Jpl.Nasa.Gov> Message-ID: <19920512141211.6.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 12 May 1992 08:41 EDT From: Curt Eggemeyer I noticed in the CLIM manual that the size-specification in the application frame's layout form is only refered to being a real number between 0 & 1. As I recalled from the ole dynamic windows constraint layout form you were allowed to input that size-spec also in either pixel or character size notation. Has that capability been lost in CLIM? If not has it changed? That capability is essentially gone in CLIM 1.0 and 1.1 CLIM 2.0 has a richer layout language that incorporates both top-down layout (like CLIM 1 has) and a bottom-up layout (similar to the TeX "boxes and glue" model).   Received: from BBN.COM by LABS-N.BBN.COM id aa28025; 12 May 92 11:22 EDT Received: from sigi.cs.colorado.edu by BBN.COM id aa12781; 12 May 92 11:11 EDT Received: by sigi.cs.colorado.edu id AA24911 (5.65c/IDA-1.4.4 for CLIM Mailing List ); Tue, 12 May 1992 09:11:46 -0600 Date: Tue, 12 May 1992 09:11:46 -0600 From: Brent Reeves Message-Id: <199205121511.AA24911@sigi.cs.colorado.edu> To: CLIM Mailing List Subject: tracking-pointer :transformp has no effect In CLIM 1.0 & Genera 8.1 does the :transformp option to tracking-mouse work? The following code returns the same values for the pointer location, regardless of the :transformp option. (define-network-design-command (com-show-warped-mouse :name "Show Warped Mouse" :menu nil) () (let* ((frame *application-frame*) (window (get-frame-pane frame 'work-area)) (tf (compose-transformations (make-scaling-transformation 2 3) (compose-transformations (make-rotation-transformation .2) (make-translation-transformation 10 20))))) (catch 'up (tracking-pointer (window :multiple-window nil) (:pointer-button-press (event x y) (format window "~%Untransformed Pointer 2: ~D,~D" x y) (throw 'up nil)))) (catch 'up (tracking-pointer (window :multiple-window nil :transformp tf) (:pointer-button-press (event x y) (format window "~%Transformed Pointer 2: ~D,~D" x y) (throw 'up nil))))))   Received: from BBN.COM by LABS-N.BBN.COM id aa01466; 12 May 92 15:26 EDT Received: from everest.den.mmc.com by BBN.COM id aa23893; 12 May 92 15:13 EDT Received: from orion.den.mmc.com by everest.den.mmc.com (4.1/1.34.a) id AA17694; Tue, 12 May 92 13:13:13 MDT Received: by orion.den.mmc.com (orion# aliases for this host.mmc.generic.062090) Date: Tue, 12 May 92 13:09:42 MDT From: Robin Kladke (303) 977-9760 Message-Id: <9205121909.AA13748@orion> To: clim@bbn.com, robin@ciani.den.mmc.com Subject: Problems with getting windows to come up correctly on the Sun I am attempting to bring up a window-based graphical editor on the Sun. The application, originally written for use under Genera, comes up correctly on the Symbolics. The application is composed of 6 independent windows placed at absolute locations relative to the root window. On the Symbolics, the windows appear as a single, coherent application with multiple panes: title, 2 menus, a Lisp listener, and several graphical displays. On the Sun, the windows are of correct dimensions, but they are not placed correctly and there is no simple transformation that describes the difference between the displays. I suspect the OpenWindows is overriding the specified values for right, left, top, and bottom. This is supported by the fact that if i create a window within the Allegro interpreter, it also is offset. All windows, whether defined within the applicaiton or manually, appear to always come up in the same (wrong) place each time they are created and exposed. The windows are created by opening a root window using (clim:open-root-window :clx :host ":0") then creating the individual panes by issuing multiple (clim:open-window-stream :parent *root-window* :left left :right right :top top :bottom bottom). The application could be easily created using (clim:define-application-frame...) but, alas, too much legacy code would have to be rewritten and there is not enough time. Is the problem with the window manager? Are there any other possible culprits? If the problem is with the window manager, is there any way to tell the window manager that i want absolute placement of the windows with respect to the root and not to mess with this placement? How would i do this? I am not a X guru by any means, so please keep all comments simple in that regard. --Robin Kladke Software Engineer (AI applications) Martin Marietta Denver, CO   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa02646; 12 May 92 16:55 EDT Received: by KARIBA.BBN.COM id aa11256; 12 May 92 16:43 EDT To: Robin Kladke 977-9760 (303) cc: clim@BBN.COM Subject: Re: Problems with getting windows to come up correctly on the Sun In-reply-to: Your message of Tue, 12 May 92 13:09:42 -0600. <9205121909.AA13748@orion> Date: Tue, 12 May 92 16:45:39 -0400 Message-ID: <3251.705703539@bbn.com> From: Jeff Morrill Date: Tue, 12 May 92 13:09:42 MDT From: Robin Kladke (303)977-9760 To: clim@BBN.COM, robin@ciani.den.mmc.com Subject: Problems with getting windows to come up correctly on the Sun The application is composed of 6 independent windows placed at absolute locations relative to the root window. The application could be easily created using (clim:define-application-frame...) but, alas, too much legacy code would have to be rewritten and there is not enough time. The end of a legacy may be near. In the Sun world (X windows), specifying a window position is only a "hint" (WM_HINT), and it can be overridden by the window manager if it feels like it. Furthermore, if you move a window, the window manager doesn't know that the others should move with it. By making separate windows that are essentially unrelated, as you have done, you give the window manager permission to treat them separately and put them wherever it wants. The raison d'etre for define-application-frame is to group windows together and thereby solve exactly this problem. Not enough time? It shouldn't take more than an afternoon to lay out a reasonably complex application frame, and then you can throw away all that "legacy" code that probably breaks every time Symbolics releases a new version of Genera. (I've been there.) jeff morrill jmorrill@bbn.com   Received: from BBN.COM by LABS-N.BBN.COM id aa02748; 12 May 92 17:03 EDT Received: from sigi.cs.colorado.edu by BBN.COM id aa01400; 12 May 92 16:49 EDT Received: by sigi.cs.colorado.edu id AA27656 (5.65c/IDA-1.4.4 for CLIM Mailing List ); Tue, 12 May 1992 14:48:58 -0600 Date: Tue, 12 May 1992 14:48:58 -0600 From: Brent Reeves Message-Id: <199205122048.AA27656@sigi.cs.colorado.edu> To: CLIM Mailing List Subject: RE: tracking-pointer :transformp has no effect >>>>> Scott McKay writes: I had asked: In CLIM 1.0 & Genera 8.1 does the :transformp option to tracking-mouse work? The following code returns the same values for the pointer location, regardless of the :transformp option. Scott McKay replied: :TRANSFORMP is a predicate that says to transform the X,Y coordinates by the stream's current transformation. You are using it incorrectly. For the net: Wrapping a with-drawing-options around the code in question solved it as follows: (define-network-design-command (com-show-warped-mouse :name "Show Warped Mouse" :menu nil) () (let* ((frame *application-frame*) (window (get-frame-pane frame 'work-area)) (tf (compose-transformations (make-scaling-transformation 2 3) (compose-transformations (make-rotation-transformation .2) (make-translation-transformation 10 20))))) ;; ;; with-drawing-option allows the :transformp option to ;; work in tracking-pointer ;; (with-drawing-options (window :transformation tf) (catch 'up (tracking-pointer (window :multiple-window nil) (:pointer-button-press (event x y) (format window "~%Untransformed Pointer 2: ~D,~D" x y) (throw 'up nil)))) (catch 'up (tracking-pointer (window :multiple-window nil :transformp t) (:pointer-button-press (event x y) (format window "~%Transformed Pointer 2: ~D,~D" x y) (throw 'up nil))))))) thanks Scott, -brent ---------------------------------------------------------------------- Brent Neal Reeves brentr@cs.colorado.edu (303) 492-1218 "visualize whirled peas"   Received: from BBN.COM by LABS-N.BBN.COM id aa02633; 12 May 92 16:53 EDT Received: from crdgw1.GE.COM by BBN.COM id aa00638; 12 May 92 16:41 EDT Received: by crdgw1.ge.com (5.57/GE 1.139) id AA00109; Tue, 12 May 92 16:25:07 EDT Received: from procyon.crd.Ge.Com by sol.crd.Ge.Com (4.0/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA14210; Tue, 12 May 92 16:25:42 EDT Date: Tue, 12 May 92 16:25:42 EDT From: halvers@sol.crd.ge.com (peter c halverson) Message-Id: <9205122025.AA14210@sol.crd.Ge.Com> Received: by procyon.crd.Ge.Com (4.1/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA08715; Tue, 12 May 92 16:25:28 EDT To: robin@orion.den.mmc.com Cc: clim@bbn.com In-Reply-To: Robin Kladke (303)977-9760's message of Tue, 12 May 92 13:09:42 MDT <9205121909.AA13748@orion> Subject: Re: Problems with getting windows to come up correctly on the Sun Reply-To: Pete Halverson Sun-Distance: 151172546 kilometers (1.011 AU) Robin, > I suspect the OpenWindows is overriding the specified values for right, > left, top, and bottom. This is supported by the fact that if i create a > window within the Allegro interpreter, it also is offset. All windows, > whether defined within the applicaiton or manually, appear to always come > up in the same (wrong) place each time they are created and exposed. > > Is the problem with the window manager? Quite likely. A window manager, by definition, always has the last word as far as placement of windows with respect to the root. Any absolute positioning you may specify is only interpreted as a "hint"---the wm is free to ignore it, and many do. > If the problem is with the window manager, is there any way to > tell the window manager that i want absolute placement of the windows > with respect to the root and not to mess with this placement? No. There are certainly no portable (i.e. window-manager independent) methods, and unlikely to be even wm-specific approachs that you can access from CLIM. Those trying to maintain consistency for separate applications within a wm view this as a Good Thing, those trying to maintain a consistent user interface for a single application across wm's view it as a Bad Thing. One workaround may be to define a single top-level window large enough to encompass all your subwindows (which will get placed according to the wm's whims [*]), and then define all your subwindows as children of the top-level, specifying geometry and placement as needed. You'll have to provide your own titlebars (since the wm won't decorate them for you), but there may be other benefits (like being able to iconify the entire application with a single action). This is part of what DEFINE-APPLICATION-FRAMEWORK does for you automatically, but there's no reason you can't do the equivalent using explicit OPEN-WINDOW-STREAM calls. Pete Halverson INET: halverson@crd.ge.com GE Corporate R&D Center UUCP: uunet!crd.ge.com!halverson Schenectady, NY [*] Pronounced "wimz wimz", of course :-)   Received: from BBN.COM by LABS-N.BBN.COM id ab13080; 15 May 92 8:43 EDT Received: from unido.Germany.EU.net by BBN.COM id aa24006; 15 May 92 8:25 EDT Received: from zfe.extern.siemens.de by mail.Germany.EU.net with SMTP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA19841; Fri, 15 May 92 12:11:05 +0200 Received: from ztivax.zfe.siemens.de by zfe.siemens.de (4.1/SMI-4.0) id AA06097; Fri, 15 May 92 12:04:18 +0200 Received: by ztivax.zfe.siemens.de (5.57/Ultrix3.0-C) id AA08565; Fri, 15 May 92 12:09:57 +0200 Date: Fri, 15 May 1992 12:11+0200 From: Anton Beschta Reply-To: beschta@informatik.tu-muenchen.de Subject: Problem with format-graph-from-root within present To: clim@bbn.com Fcc: S2:/home/arms2/beschta/mail/fcc.babyl Message-Id: <19920515101110.1.TONI@l.zfe.siemens.de> Dear CLIMers, I'm having a problem using format-graph-from-root within a presentation method. Consider the following example: (clim:define-presentation-type mr ()) (clim:define-presentation-method clim:present (mr (type mr) stream view &key) (clim:format-graph-from-root mr #'(lambda (object stream) (print (car object) stream)) #'second :stream stream))) (clim:present '(a ((b) (c) (d))) 'mr) Evaluating the above in a Lisp Listener (Genera 8.1, CLIM 27.0, no ECOs) results in the node names being placed properly but the connecting lines always being drawn at the *top* of the listener's history. Evaluating (clim:format-graph-from-root '(a ((b) (c) (d))) #'(lambda (object stream) (print (car object) stream)) #'second :stream stream) results in the expected output. Any hints/workarounds appreciated, Toni Beschta   Received: from BBN.COM by LABS-N.BBN.COM id aa14546; 15 May 92 11:00 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa00563; 15 May 92 10:50 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1078975; 15 May 1992 10:49:10-0400 Date: Fri, 15 May 1992 10:49-0400 From: Scott McKay Subject: Problem with format-graph-from-root within present To: beschta@informatik.tu-muenchen.de, clim@BBN.COM In-Reply-To: <19920515101110.1.TONI@l.zfe.siemens.de> Message-ID: <19920515144938.9.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 15 May 1992 06:11 EDT From: Anton Beschta Dear CLIMers, I'm having a problem using format-graph-from-root within a presentation method. Consider the following example: (clim:define-presentation-type mr ()) (clim:define-presentation-method clim:present (mr (type mr) stream view &key) (clim:format-graph-from-root mr #'(lambda (object stream) (print (car object) stream)) #'second :stream stream))) (clim:present '(a ((b) (c) (d))) 'mr) Evaluating the above in a Lisp Listener (Genera 8.1, CLIM 27.0, no ECOs) results in the node names being placed properly but the connecting lines always being drawn at the *top* of the listener's history. Evaluating (clim:format-graph-from-root '(a ((b) (c) (d))) #'(lambda (object stream) (print (car object) stream)) #'second :stream stream) results in the expected output. Any hints/workarounds appreciated, This works correctly in CLIM 1.1. You should call Symbolics software support to find out how to get CLIM 1.1   Received: from BBN.COM by LABS-N.BBN.COM id aa18203; 15 May 92 15:47 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa13048; 15 May 92 15:39 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1079196; 15 May 1992 15:38:09-0400 Date: Fri, 15 May 1992 15:38-0400 From: Scott McKay Subject: Vacation To: clim@bbn.com Message-ID: <19920515193839.3.SWM@SUMMER.SCRC.Symbolics.COM> I wouldn't bother all of you with this message, except that I still seem to answer a large number of questions on this list. I'll be on vacation for the next two weeks and so won't be available to reply to anything during that time. Happy hacking, and see you in two weeks.   Received: from BBN.COM by LABS-N.BBN.COM id aa10905; 18 May 92 9:59 EDT Received: from mcsun.EU.net by BBN.COM id aa10963; 18 May 92 9:44 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA03368 (5.65b/CWI-2.161); Mon, 18 May 1992 15:44:20 +0200 Received: by ub4b.buug.be (5.64+/ub4b_02) id AA19625; Mon, 18 May 92 15:38:11 +0200 Received: from scosysv by nrb.be (DECUS UUCP ///1.3-1/2.5/); Mon, 18 May 92 15:34:12 +0200 Received: from milou.nrb.be by scosysv.nrb.be with SMTP (5.59/25-e-eef-ev@nrb) id AA19718; Mon, 18 May 92 19:59:28 CET Date: Mon, 18 May 1992 14:58+0200 From: Vincent Keunen Reply-To: scosysv!keunen@nrb.be Subject: Re: [teskridg@NMSU.Edu: future MCL] To: Christopher Fry Cc: mcl@milou.nrb.be, clim@milou.nrb.be In-Reply-To: <9205072114.AA25047@MIT.EDU> Message-Id: <19920518125813.0.KEUNEN@milou.nrb.be> Date: Thu, 7 May 1992 21:30+0200 From: Christopher Fry [...] > > More globally, CLIM seems pretty clean and well designed to me. Also, > the specs for CLIM 2 clearly define the protocols to the differents > layers of CLIM for easy programmer access and I like that. This is the best report on CLIM that I've seen yet. Permit me to probe a little deeper. You are speaking of CLIM1 running on MCL, right? Yes. CLIM2 is not out yet. Is all of the functionality that you describe in the Symbolics "CLIM Release 1.0" manual, March 1991? If there is significant additional documentation, please let me know what. Yes, the Symbolics doc is the one that comes with CLIM1 for MCL2. I don't know of other doc. I agree with you that a simpler tutorial would be nice (ala Sonya Keene for CLOS). I was able to get much more perspective from the CLIM courses I took at Symbolics GMBH (Germany) with Markus Fischer. Although a bit expensive, they were very good (few people and a machine for every student, some course notes, lots of exercices...). What's missing regarding docs is more descriptions of the general concepts of CLIM, sections ala "to have this behaviour, do this", and a more consistent vocabulary (I must admit I am not an expert in views, regions, areas, windows, dialogs,panes...) and it seems everybody uses its own terminology (mac <> unix <> clim...). A glossary would be nice. Are you familiar with the MCL2 window system? I am familiar with the Mac system, but have never really used the MCL2 interface system. I think (but I might be wrong) that it requires quite a bit of understanding of "Inside Mac" if you want to use more specific things (like pop-up menus, pointer tracking, dragging,...) while all this is very simple in CLIM. Other than a Mac-look what other features are in MCL window system that are not easily done in CLIM 1? I am not sure I can answer this since I don't know the MCL side that much. However, I believe that the Mac specific things would be harder in CLIM (like Quicktime movies, resources support,...). But then again, since these things are very specific, you could maybe use MCL's hooks to the toolbox inside CLIM. Also, CLIM2 is supposed to allow for machine specific gadgets. Maybe this would be the way. Scott McKay or Bill York will have to say that. If you were NOT planning on porting your code to a non-mac, would you prefer CLIM 1 over MCL windows? & why. I think CLIM is much more "high level" than MCL's interface system. It has much more (see the features I mentionned), but it's also much heavyer stuff (at least 1Mo above MCL I think). Same difference between CLIM and MCL's interfacing stuff than between Lisp and C (I hope the MCL developers won't kill me for this comparison - they know I love MCL!) My appliction needs nested multiply nested views, each of which may be independently scrolled. Can CLIM 1 support this? If I understand what "nested multiply nested views" are, yes you can do that with CLIM (scrolling support is automatic with output recording and you can also decide what to redisplay manually). Is CLIM1 on a Mac significantly slower than MCL windows? I have made no performance tests, but it probably is. There is more overhead, but you get much more too. However, CLIM is designed to give programmers access to its low level primitives for performance improvements (you need the CLIM2 specs for that). Reliability? Good and improving. See the mailing list clim-request@bbn.com. Have you used Quicktime with CLIM1? I'm thinking of showing a videoclip inside a pane in a window and am wondering if this is going to be much harder in CLIM than MCL windows. CLIM doesn't provide any support for that. You will probably use the same primitives in both cases (see the code of Daniel Ranson for QuickTime support under MCL). Vincent   Received: from BBN.COM by LABS-N.BBN.COM id aa16152; 18 May 92 16:10 EDT Received: from dryer.ecn.purdue.edu by BBN.COM id aa01185; 18 May 92 16:03 EDT Received: by dryer.ecn.purdue.edu (5.65/1.30jrs) id AA13217; Mon, 18 May 92 15:02:58 -0500 Date: Mon, 18 May 92 15:02:58 -0500 From: vaidhyan@ecn.purdue.edu (Ramesh Vaidhyanathan) Message-Id: <9205182002.AA13217@dryer.ecn.purdue.edu> To: CLIM@BBN.COM Subject: Request for Info on CLIM Hello: I am looking for a GUI development software (preferably based on CLOS or based on CL) in which I can draw graphical icons of different objects on the screen and attach a 'CLOS object' to the graphical icon. Similarly I should be able to specify the connectivity(i.e. specify some slots of the objects) between the graphical objects by drawing them as connected on the screen. I heard that I will be able to implement some of the above mentioned features using CLIM. I would like ot get more info. on CLIM. We have Sun Common Lisp available here. Does CLIM runs on SCL? Thanks in advance. -Ramesh Vaidhyanathan Laboratory for Intelligent Process Systems School of Chemical Engineering Purdue University.   Received: from BBN.COM by LABS-N.BBN.COM id aa22581; 19 May 92 5:52 EDT Received: from [192.44.1.1] by BBN.COM id aa17678; 19 May 92 5:47 EDT Received: by fhg.de (fhg1.fhg.de) with PRESMTP; Tue, 19 May 92 11:47:08 +0200 from FHG-GATEWAY Received: by fhg.de (fhg1.fhg.de) with UUCP; Tue, 19 May 92 11:47:03 +0200 from imldo Received: by iml.fhg.de with SMTP; Tue, 19 May 92 11:48:52 +0200 Date: Tue, 19 May 1992 11:48+0200 From: Stefan Bernemann Subject: Selecting Presentations To: clim@bbn.com Message-Id: <19920519094809.1.STEFAN@ANNA.iml.fhg.de> Hello, I want to implement a kind of user-interaction, where the user (or the system) "selects" some "objects" and where some operations can be performed on a set of objects commonly called "current selection". I have some problems as well on a technical as on a conceptual level. Let me start with the concetual part. What the user "wants" (as I understand) is selecting an object. What he "does" is selecting a presentation of the object. Things are easy as long as there is only one presentation of an object at any time. But what should happen (and in what terms should it be described / formalized / specified) if there are more than one? From the user perspective, it may make sense that several representations of one object are selected (i.e. marked as selected) if he selects one of them. I will use the term "selection context" to denote the set of presentations that should behave in this way. Example: Consider a hierarchy of objects, where in one pane (yes, I'm using CLIM) the hierarchy is presented graphically as a tree. In another pane, there is just displayed a list of the objects ordered alphabetically. The user wants to change the parent of object "foo" to it's brother. This can be done by selecting "it" and dragging it around in the graph-pane. However, finding and selecting "foo" is easier in the alphabetical list. After selecting it there, the graphcial view could scroll (automatically or after a separate command, not important in this question) to the selected object's presentation in the graph pane, where the user drags it around. (I know this task can be relalized with another UI, but that's not my point.) How can I specify such selection contexts? Is it sufficient to describe it in terms of panes? Or MUST they be described in terms of user intention? How are selection contexts "switched"? Furthermore, there are arguments to have different user feedback for selected presentations of the same object (drawing the select-mark of the presentation which the user selected in a different way than the other presentations of the associated object), i.e. presentations within one selection context should be differentiated. I don't want to dig deeper into this to keep this message short (?). However, as the "selecting" user interaction style is quite important, I want to get the concepts clear and then implement some kind of "selection-substrate" in CLIM (or is there already one in CLIM 2.0 ??). So: ANY INPUT AND DISCUSSION WELCOME! Now a more technical problem: The user feedback for selecting objects requires that seleted presentations are drawn in a different way. What is the most efficient way to do this in CLIM? My first approach uses incremental redisplay (updating-output) to replace a presentation with a "selected" one and vice versa. But I know what presentations have changed, so I don't need that unique-id- and chaching-stuff. Furthermore, as I understand, it could be more efficient if I associate with each presentation one (or serveral different) output record "selection mark(s)" which are visible or not (installed in the output history or not). How can I use output records on this low level? There are some documented functions, but the documentation seems quite "compact" to me... I find the possibilty to define my own border types and bordering the output quite suitable as selection markers. That's what I'm using at the moment together with updating output. How can I use the output record created by surrounding-output-with-border directly? Any help or example codes on playing with output records? Thanks - Stefan B. Mail: Stefan Bernemann ! Phone: +49-231-9743-139 c/o FhG IML Dortmund ! Fax: +49-231-9743-234 Emil-Figge-Str. 75 ! Email: berni@iml.fhg.de D-4600 Dortmund 50, FRG !   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa25445; 19 May 92 10:37 EDT Received: by KARIBA.BBN.COM id ab27684; 19 May 92 10:23 EDT To: Stefan Bernemann cc: clim@BBN.COM Subject: Re: Selecting Presentations In-reply-to: Your message of Tue, 19 May 92 11:48:00 +0200. <19920519094809.1.STEFAN@ANNA.iml.fhg.de> Date: Tue, 19 May 92 10:19:35 -0400 Message-ID: <6691.706285175@bbn.com> From: Jeff Morrill Date: Tue, 19 May 1992 11:48+0200 From: Stefan Bernemann Subject: Selecting Presentations To: clim@BBN.COM Hello, I want to implement a kind of user-interaction, where the user (or the system) "selects" some "objects" and where some operations can be performed on a set of objects commonly called "current selection". This is a common need in many types of user interfaces, and it ought to be easy but I don't know of anybody who's done it in CLIM. DataDesk, a Mac application for data analysis, is a good example of this. When you "select" a data point, all of its displayed representations get highlighted in all of the panes of the application. In addition, you can select more than one data point at a time. How can I specify such selection contexts? 1. Your application will need to keep track of the "current selection" itself. I suppose this would be a slot on the frame containing a list of objects. 2. For each displayed object, you need to know its output records. I have done this before by adding a slot to the object that contains a list of output records. Then a display method for the object manages the list. This could be hard, depending on the application. 3. Your application will need to keep track of all the objects that are selected. It seems like a method SELECT-OBJECT could be implemented for the object that informs *application-frame* and then highlights all of the object's output records. 4. You can highlight an output record by getting its bounding box and drawing a rectangle in the :flip ink. Or you can use the "real" highlighting method, which is apparently clim:highlight-output-record. This may all interfere with the frame's own protocol for highlighting presentations that are under the mouse. I dunno. Good luck. jeff morrill   Received: from BBN.COM by LABS-N.BBN.COM id aa25146; 19 May 92 10:13 EDT Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa13381; 19 May 92 10:08 EDT Received: from RED-KNOT.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 817570; 19 May 1992 10:06:33-0400 Date: Tue, 19 May 1992 10:06-0400 From: Mark Nahabedian Subject: Selecting Presentations To: berni@iml.fhg.de, clim@BBN.COM In-Reply-To: <19920519094809.1.STEFAN@ANNA.iml.fhg.de> Message-ID: <19920519140652.9.NAHA@RED-KNOT.SCRC.Symbolics.COM> This is in regard to your questions about a user interface for selected objects. Your program has some objects to be manipulated. These objects are represented on the screen by presentations. A given object may be represented by more than one presentation. The user selects objects which are to be manipulated by some program operation by selecting a presentation of that object. What visual feedback should the user receive for his selection choices? Should only the presentation that was selected be highlighted or should all presentations of the selected presentation's object be highlighted. The answer to this question depends on the nature of the operation being performed. For an operation on program objects, all presentations of the selected object should be highilghted. For an operation which is intended to apply only to the selected presentation, only the presentation should be highlighted. As an example, consider a program that displays a graph of related objects. Each object node is represented on the screen by a presentation. Lines drawn between presentations indicate relationships between objects. The application might provide several views (displayed in different panes) of the graph (perhaps because the graph is too large to be viewed all at once and the user wants windows into different pieces of it). It is possible for an objct to appear in more than one view. When the user selects an object whose relationships he intends to modify all presentations of that object should be highlighted. Suppose the user wanted to move the presentations of objects around to make the view easier to understand. The spacial arrangement of the presentations is a property of the presentations themselves, not the objects they represent. The only property of the objects is how they are interrelated. When the user is performing an operation on the presentation, only the selected presentation, and no others should be highlighted. The only thing the user gets to manipulate directly is the presentation. The application needs a way to disambiguate between the case when the user intends to manipulate the presentation, or the object which it represents. It's sort of a graphical version of the quoting problem in textual languages. In some cases contextual information can be used to resolve this ambiguity. If the program knows that the user intends to modify the relations among objects (perhaps by some sort of command selected from a menu) then it knows that objects and not their presentations are being selected. If the user has issued a command which operates on presentations, then the application knows that it is presentations which are being selected. In some cases the application doesn't know what's being operated on until the user's interaction is complete. On the Apple Macintosh, the Finder serves as a graphical interface to the file system. It allows the user to rename files, move them to a different part of the file system hierarchy or delete them. The contents of a directory are displayed in a window. Each file and subdirectory in that directory appears as an icon in that window. The user is free to rearrange these icons by dragging them around within the window. The icon is the presentation of a file and dragging it within the window is a manipulation of that icon. When an icon is dragged outside the window onto another window, the user is indicating that the file which the icon represents is to be moved from the directory represented by the window where the icon started to the directory represented by the window to which the user dragged the icon. Since any given file on the Macintosh is only represented by a single icon to be highlighted. The finder thus has the luxury of not needing to resolve the ambiguity between object and presentation until the interaction is complete. This is not the case for many applications (including the one you describe). For these applications the ambiguity must be resolved in some other way, either by knowing what the operation to be performed is prior to selection or by distinct gestures depending on whether the user means to indicate the presentation itself or the object it represents.   Received: from BBN.COM by LABS-N.BBN.COM id aa27255; 19 May 92 13:24 EDT Received: from harvard.harvard.edu by BBN.COM id aa21231; 19 May 92 13:07 EDT Received: by harvard.harvard.edu (5.54/a0.25) (for clim@BBN.COM) id AA12161; Tue, 19 May 92 13:07:03 EDT Received: by gensym.com (4.0/SMI-3.2) id AA05042; Tue, 19 May 92 10:26:27 EDT Date: Tue, 19 May 92 10:26:27 EDT From: gensym!bhyde@harvard.harvard.edu (Ben A. Hyde) Message-Id: <9205191426.AA05042@gensym.com> To: @harvard.harvard.edu:berni@iml.fhg.de Cc: clim@BBN.COM In-Reply-To: Stefan Bernemann's message of Tue, 19 May 1992 11:48+0200 <19920519094809.1.STEFAN@ANNA.iml.fhg.de> Subject: Selecting Presentations Thank you for raising one of the serious design problems that CLIM ignores! It will be fun to watch the discussion develop. - ben hyde, cambridge   Received: from BBN.COM by LABS-N.BBN.COM id aa27091; 19 May 92 13:10 EDT Received: from cs.rice.edu by BBN.COM id aa20277; 19 May 92 12:42 EDT Received: by cs.rice.edu (AA06318); Tue, 19 May 92 11:42:41 CDT Date: Tue, 19 May 92 11:42:41 CDT From: mcw@cs.rice.edu (Michael Wirth) Message-Id: <9205191642.AA06318@cs.rice.edu> To: clim@bbn.com Subject: Re: Selecting Presentations Cc: mcw@cs.rice.edu For a wonderful example of multiple "presentations" of the same objects and the usefullness of highlighting all of them when objects are selected, get a copy of Lisp-Stat, free (Mac, Unix/X-windows, etc. platforms) from Luke Tierney at the Univ. of Minnesota (luke@umnstat.stat.umn.edu). There's also a mailing list, stat-lisp-news (stat-lisp-news-request@umnstat.stat.umn.edu to subscribe). Besides, Lisp-Stat is just plain fun to play with. Tierney's use of "dynamic graphics" (his term) techniques such as multiple 2-parameter projections of multiple parameter data, rotation of 3-D views, etc., present many examples for the CLIM community to think about. Mike Wirth 713-370-2965 mcw@cs.rice.edu Houston, TX PS: I just checked Tierney's book, "Lisp-Stat: An Object-Oriented Environment for Statistical Computing and Dynamic Graphics," Wiley Interscience, 1990. Apndx. B says you can ftp lisp-stat from umnstat.stat.umn.edu (128.101.51.1). Or, if you don't have ftp access, send a mail msg containing the line: send index from xlispstat to statlib@temper.stat.cmu.edu Oh yes, it's written in XLISP.   Received: from BBN.COM by LABS-N.BBN.COM id aa28149; 19 May 92 14:31 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa24663; 19 May 92 14:20 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA09159; Tue, 19 May 92 11:20:09 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA00288; Tue, 19 May 92 11:13:36 PDT Date: Tue, 19 May 92 11:13:36 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9205191813.AA00288@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: Presentation Contexts (How does one create his own?) I'd like to create my own presentation contexts (besides textual, etc.) and would like to know if anybody out there on the net has any SIMPLE examples that they could send me that illustrates how you code your own. The CLIM 1.0 docs aren't much help to me. Thanks in advance!   Received: from BBN.COM by LABS-N.BBN.COM id aa07085; 20 May 92 7:17 EDT Received: from [192.44.1.1] by BBN.COM id aa20932; 20 May 92 7:12 EDT Received: by fhg.de (fhg1.fhg.de) with PRESMTP; Wed, 20 May 92 13:11:21 +0200 from FHG-GATEWAY Received: by fhg.de (fhg1.fhg.de) with UUCP; Wed, 20 May 92 13:11:19 +0200 from imldo Received: by iml.fhg.de with SMTP; Wed, 20 May 92 13:09:19 +0200 Date: Wed, 20 May 1992 13:08+0200 From: Stefan Bernemann Subject: Re: Selecting Presentations (technical) To: jmorrill@BBN.COM Cc: clim@BBN.COM In-Reply-To: <6691.706285175@bbn.com> Message-Id: <19920520110842.3.STEFAN@ANNA.iml.fhg.de> Date: Tue, 19 May 1992 16:19 MEST From: Jeff Morrill Thanks for answering. This is a common need in many types of user interfaces, and it ought to be easy but I don't know of anybody who's done it in CLIM. DataDesk, a Mac application for data analysis, is a good example of this. When you "select" a data point, all of its displayed representations get highlighted in all of the panes of the application. In addition, you can select more than one data point at a time. [...] 4. You can highlight an output record by getting its bounding box and drawing a rectangle in the :flip ink. Or you can use the "real" highlighting method, which is apparently clim:highlight-output-record. But I want the "selected highlight" to be associated with the presentation in the sense that e.g. if I drag it around (using dragging-outptu-record for example) the output-record of the rectangle drawn with the :flip ink follows. That would be the case if this output-record has as its parent the presentation of the object. But then, how do I switch highlighting on and off efficiently? Would it work to *replay* the output-record of the rectangle with the flipping ink? As far as I understand, replay is mainly for refreshing or screnn updating and not usable for changes in the visual output!? It would be nice to see how the default highlighting method is implemented. However, I observed some bugs some time ago when experimenting with dragging and transformations. The rectangle drawn by the highlight-method didn't follow the output-record of the presentation after it was dragged / moved around under some non-identity transformation in effect (as far as I remember). This may all interfere with the frame's own protocol for highlighting presentations that are under the mouse. I dunno. Good luck. jeff morrill Stefan B. Mail: Stefan Bernemann ! Phone: +49-231-9743-139 c/o FhG IML Dortmund ! Fax: +49-231-9743-234 Emil-Figge-Str. 75 ! Email: berni@iml.fhg.de D-4600 Dortmund 50, FRG !   Received: from BBN.COM by LABS-N.BBN.COM id aa07083; 20 May 92 7:17 EDT Received: from [192.44.1.1] by BBN.COM id aa20921; 20 May 92 7:11 EDT Received: by fhg.de (fhg1.fhg.de) with PRESMTP; Wed, 20 May 92 13:10:38 +0200 from FHG-GATEWAY Received: by fhg.de (fhg1.fhg.de) with UUCP; Wed, 20 May 92 13:09:34 +0200 from imldo Received: by iml.fhg.de with SMTP; Wed, 20 May 92 12:53:05 +0200 Date: Wed, 20 May 1992 12:52+0200 From: Stefan Bernemann Subject: Re: Selecting Presentations (coneptual) To: naha@RIVERSIDE.SCRC.Symbolics.COM Cc: clim@BBN.COM In-Reply-To: <19920519140652.9.NAHA@RED-KNOT.SCRC.Symbolics.COM> Message-Id: <19920520105228.1.STEFAN@ANNA.iml.fhg.de> Date: Tue, 19 May 1992 16:06 MEST From: Mark Nahabedian This is in regard to your questions about a user interface for selected objects. Thank you. Your program has some objects to be manipulated. These objects are represented on the screen by presentations. A given object may be represented by more than one presentation. The user selects objects which are to be manipulated by some program operation by selecting a presentation of that object. What visual feedback should the user receive for his selection choices? Should only the presentation that was selected be highlighted or should all presentations of the selected presentation's object be highlighted. The answer to this question depends on the nature of the operation being performed. For an operation on program objects, all presentations of the selected object should be highilghted. For an operation which is intended to apply only to the selected presentation, only the presentation should be highlighted. [...] The only thing the user gets to manipulate directly is the presentation. The application needs a way to disambiguate between the case when the user intends to manipulate the presentation, or the object which it represents. It's sort of a graphical version of the quoting problem in textual languages. An interesting analogy, I've never seen it that way! But I'd like to describe it in another way: An "object" may contain different aspects (or is it "made up" of these aspects?) from the user's point of view. Presentations of an object are to visualize these aspects, i.e. each presentation may visualize one or more of these. In that terms, the location of a file's icon in a Mac Finder window and it's position relative to other icons are such a user's aspect of the *file object* -- it's name andlocation in the directory hierarchy are other aspects. It's a *modelling issue*, whether you represent different user aspects (of one "user object" or better "user concept") as different program objects (in some sort, presentations are just as well program objects) or as one complex object with an "aspect operation". With your differentiation between program objects and presentations you take the first point, the notion as a (graphical) quoting problem takes the second -- the lisp interpreter gets the object "symbol" and can treat it as a symbol (quoted = symbol aspect) or as a variable (unquoted = variable aspect). All this doesn't make things easier. What happens when a user "selects an object"? Suppose he wants to perform an operation on the object. He will only be interested in those aspects of the object which are relevant to the operation. Note the plural of aspects -- there may be several. Accordingly, all presentations viualizing some of these apspects should be highlighted. That's what I called "selection context". Of course, this set of "relevant" presentations depends of the user has in mind, as you pointed out in the example of dragging a file's icon in the Mac Finder: In some cases contextual information can be used to resolve this ambiguity. [...] In some cases the application doesn't know what's being operated on until the user's interaction is complete. On the Apple Macintosh, the Finder serves as a graphical interface to the file system. It allows the user to rename files, move them to a different part of the file system hierarchy or delete them. The contents of a directory are displayed in a window. Each file and subdirectory in that directory appears as an icon in that window. The user is free to rearrange these icons by dragging them around within the window. The icon is the presentation of a file and dragging it within the window is a manipulation of that icon. When an icon is dragged outside the window onto another window, the user is indicating that the file which the icon represents is to be moved from the directory represented by the window where the icon started to the directory represented by the window to which the user dragged the icon. Since any given file on the Macintosh is only represented by a single icon to be highlighted. The finder thus has the luxury of not needing to resolve the ambiguity between object and presentation until the interaction is complete. Many other applications take all presentations in one *window* as one selection context -- that's technically easy and a reasonable "heuristic": with window-based applications, you have the concept of an "active" or "selected" window which somehow represents the "focus of interest" of the user. Switching windows then means switching selection contexts. However, CLIM supports windows subdivided into panes -- there is in general not "selected pane". And in CLIM it is (technically) quite easy to have more than one presentation of one object -- although CLIM does not support the programmer to keep track of the relation object --> presentation(s). I guess, these two facts are the root of all these questions about the selection metaphor. However, the root of the arising problems lie in modelling and representation issues of complex, multifacetted objects, where the metaphor "select an object" may sometimes be just inadequat!? Stefan B. Mail: Stefan Bernemann ! Phone: +49-231-9743-139 c/o FhG IML Dortmund ! Fax: +49-231-9743-234 Emil-Figge-Str. 75 ! Email: berni@iml.fhg.de D-4600 Dortmund 50, FRG !   Received: from BBN.COM by LABS-N.BBN.COM id aa08148; 20 May 92 9:15 EDT Received: from [192.44.1.1] by BBN.COM id aa25471; 20 May 92 9:10 EDT Received: by fhg.de (fhg1.fhg.de) with PRESMTP; Wed, 20 May 92 15:09:08 +0200 from FHG-GATEWAY Received: by fhg.de (fhg1.fhg.de) with UUCP; Wed, 20 May 92 15:08:58 +0200 from imldo Received: by iml.fhg.de with SMTP; Wed, 20 May 92 15:06:04 +0200 Date: Wed, 20 May 1992 15:05+0200 From: Stefan Bernemann Subject: "Grouping" of presentations To: clim@bbn.com Message-Id: <19920520130527.4.STEFAN@ANNA.iml.fhg.de> Hello, this time :-) I want to implement a feature of drawing applications or graph editors, namely the grouping of presentations. That means, I want to *replace* a set of presentations (no matter of what type) by ONE other presentation (e.g. of type "group"). That is, I don't want to keep the old presentations of the objects (at least I want to change their types), because otherwise there would be the same access to objects be they contained in a group or not -- but it makes not sense (in my application) e.g. to drag a single presentation "inside a group" -- only the group as a whole may be manipulated. However, I don't want to erase and readraw any graphical output done to the screen, for efficienc reasons but mostly to minimize unnecessary screen flicker. Can this be done with CLIM? How must I fiddle with the output record and the history? Or am I completely off the road and the CLIM approach is totally different? (parameterized presentations?) Regards - Stefan B. Mail: Stefan Bernemann ! Phone: +49-231-9743-139 c/o FhG IML Dortmund ! Fax: +49-231-9743-234 Emil-Figge-Str. 75 ! Email: berni@iml.fhg.de D-4600 Dortmund 50, FRG !   Received: from BBN.COM by LABS-N.BBN.COM id aa09912; 20 May 92 11:42 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa03724; 20 May 92 11:31 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA27418; Wed, 20 May 92 08:31:14 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA00295; Wed, 20 May 92 08:24:40 PDT Date: Wed, 20 May 92 08:24:40 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9205201524.AA00295@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: How to influence command line arguments help facility Hi, I'm in the CLIM 1.0 world. I've notice in my commands the following operation. It works fine but I wish to change the accept help on args within my application commands illustrated by the following example. Assuming that the argument(s) in the command are completion, member and other one-of and some-of presentation types. With the prompt for that argument displayed if you use control-? to get the possibilities in which you can select on. You get redundant information outputted as part of the help. (Example below) (define-application-command com-retrieve-list-member :name t) (ele '(member 1 2 3 4 5 6 7 8 9 10)) ele) In the interactor pane you do: COMMAND>Retrieve List Member (ele) ;you get the following You are being asked to enter one of 1, 2, 3, 4, 5, 6, 7, 8, 9 or 10. The possible completions are: 1 2 3 4 5 6 7 8 9 10 Retrieve List Member (ele) ;at this point either you enter or click on the above mouse sensitive items. This works fine, but my question is ... Is there a way to eliminate the sentence "You are being asked to enter one of ..." from the accept help for an argument within a command. The reason I ask this is some of my presentations of this type within my command line have many possibilities (upto 100) which the help obliging outputs them twice. I only one the help to output "The possible completions are: ..." part. Is there a way to influence this in command line arguments? I notice the with-accept-help form, but I'm not sure this will help in this particular case.   Received: from BBN.COM by LABS-N.BBN.COM id aa11117; 20 May 92 13:33 EDT Received: from lucid.com by BBN.COM id aa08886; 20 May 92 13:27 EDT Received: from kuwait.lucid ([192.31.212.118]) by heavens-gate.lucid.com id AA24282g; Wed, 20 May 92 10:19:14 PDT Received: by kuwait.lucid (4.1/SMI-4.1) id AA00122; Wed, 20 May 92 10:26:49 PDT Date: Wed, 20 May 92 10:26:49 PDT From: kern%kuwait@lucid.com (John Kern) Message-Id: <9205201726.AA00122@kuwait.lucid> To: curt@eraserhead.jpl.nasa.gov Cc: clim@BBN.COM In-Reply-To: Curt Eggemeyer's message of Wed, 20 May 92 08:24:40 PDT <9205201524.AA00295@eraserhead.Jpl.Nasa.Gov> Subject: How to influence command line arguments help facility Reply-To: kern@lucid.com Howdy Mr. Eggemeyer, Complete-input and Complete-from-suggestions both offer a :possibility-printer keyword. I ran the following example on Lucid's implementation of CLIM 1.1 and the type (ie, cardinal), not all the possibilities, was listed. I'm not sure this is what you're looking for, but thought it might be helpful. Sincerely, John S. Kern Lucid, Inc. Customer Support =========== (in-package :clim-user) ;;; I have slightly modified the dictionary entry for ;;; complete-from-possibilities with the :possibility-printer ;;; keyword and added supporting code. (define-presentation-type cardinal ()) (define-presentation-method accept ((type cardinal) stream (view clim:textual-view) &key) (values (let ((possibilities '(("One" 1) ("Two" 2) ("Three" 3)))) (clim:complete-input stream #'(lambda (string action) (clim:complete-from-possibilities string possibilities nil :action action)) :possibility-printer #'print-it)) )) (defun print-it (possibility cardinal stream) (format stream "howdy ~S " possibility )) (defun complete-it () (let ((stream (get-frame-pane *application-frame* 'main))) (accept 'cardinal :stream stream))) (define-application-frame experient () () (:panes ((main :application :incremental-redisplay nil :display-function 'draw-main :default-size :rest ) (doc :pointer-documentation) (test-menu :command-menu))) (:command-table (test-menu :inherit-from (user-command-table) :menu (("EXIT" :command cmd-exit) ("OK" :command complete-it) ))) ) (defmethod draw-main ((frame experient) stream) ()) (defun run (root) (let ((frame (make-application-frame 'experient :parent root :left 0 :top 0 :right 500 :bottom 500))) (run-frame-top-level frame) ) ) (defun cmd-exit () (frame-exit *application-frame*) )   Received: from BBN.COM by LABS-N.BBN.COM id aa10891; 20 May 92 13:13 EDT Received: from harvard.harvard.edu by BBN.COM id aa08113; 20 May 92 13:08 EDT Received: by harvard.harvard.edu (5.54/a0.25) (for clim@BBN.COM) id AA10027; Wed, 20 May 92 13:07:46 EDT Received: by gensym.com (4.0/SMI-3.2) id AA05606; Wed, 20 May 92 11:33:09 EDT Date: Wed, 20 May 92 11:33:09 EDT From: gensym!bhyde@harvard.harvard.edu (Ben A. Hyde) Message-Id: <9205201533.AA05606@gensym.com> To: @harvard.harvard.edu:berni@iml.fhg.de Cc: clim@BBN.COM In-Reply-To: Stefan Bernemann's message of Wed, 20 May 1992 13:08+0200 <19920520110842.3.STEFAN@ANNA.iml.fhg.de> Subject: Selection. The selection is a big complex data structure. Let me mention some of the design issues. The user has selected N heterogenous things. The application must enable/disable menus as approprate. When the user actually selects the menu it is mapped over the selection. The selection abstraction must provide tools to do that mapping. A fun example is found in Aston Tate's FullWrite, a word processor for the Mac. They highlight the Helvetica menu one way of three ways depending on if - the entire selection is in Helvetica - none of the selection is in Helvetica, or - all the selection is in Helvetica. When multiple users are working on the same data, i.e. the Macintosh finder working on a file server. The selection is clearly user specific. When a user is working on multiple documents, the selection is clearly document specific. Selections are what you move to and from the clipboard. If you want to defer the cost of moving/copying data, or any associated costs of normalizing representation then the selection becomes entangled in those issues. It is sometimes the case that undo is related to selection. At least you should restore the selection when you undo. View scrolling has lots of little interations with selection. Most applications allow the view to move away from the selection, and then move back to show some portion of the selection if the user starts changing the selection. The way that find dialogs move the document view to show the selection without putting it behind the find dialog is a particular fun example. The selection is usually drawn as an overlay after everything else is drawn. That helps to assure that the selection gives precedence to the selection's handles. The more powerful your find dialog is the more complex the resulting selection can become. For example "find all text in italic." The cancel button should revert the selection to what it was, that makes storing the selection in the document problematic. The selection can be extremely expensive in space costs. For example how do you represent a selection which started out as an entire illustration and then had all the objects in two arbitrary rectangles subtracted from it. These issues go on and on. It is my impression that CLIM has defered these issues to the application builder. - ben hyde, cambridge   Received: from BBN.COM by LABS-N.BBN.COM id aa12098; 20 May 92 14:57 EDT Received: from FUJI.ILA.COM by BBN.COM id aa13004; 20 May 92 14:51 EDT Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 312095; 20 May 92 14:40:19 EDT Date: Wed, 20 May 1992 11:28-0700 From: William M. York Subject: How to influence command line arguments help facility To: curt@eraserhead.jpl.nasa.gov, clim@bbn.com In-Reply-To: <9205201524.AA00295@eraserhead.Jpl.Nasa.Gov> Message-ID: <19920520182839.5.YORK@CHUCK-JONES.west.dialnet.ila.com> Date: Wed, 20 May 1992 08:24 PDT From: Curt Eggemeyer I've notice in my commands the following operation. It works fine but I wish to change the accept help on args within my application commands illustrated by the following example. Assuming that the argument(s) in the command are completion, member and other one-of and some-of presentation types. With the prompt for that argument displayed if you use control-? to get the possibilities in which you can select on. You get redundant information outputted as part of the help. (Example below) You want to use the :DESCRIPTION option in your presentation type specifications for the command arguments. Try: (accept '((member 1 2 4 8 16 32) :description "power of two") :stream win) for an example.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa22731; 21 May 92 11:00 EDT Received: by KARIBA.BBN.COM id aa06522; 21 May 92 10:07 EDT To: Stefan Bernemann cc: clim@BBN.COM Subject: Re: Selecting Presentations (technical) In-reply-to: Your message of Wed, 20 May 92 13:08:00 +0200. <19920520110842.3.STEFAN@ANNA.iml.fhg.de> Date: Thu, 21 May 92 10:00:10 -0400 Message-ID: <7421.706456810@bbn.com> From: Jeff Morrill Date: Wed, 20 May 1992 13:08+0200 From: Stefan Bernemann Subject: Re: Selecting Presentations (technical) To: jmorrill@BBN.COM Cc: clim@BBN.COM But I want the "selected highlight" to be associated with the presentation in the sense that e.g. if I drag it around (using dragging-outptu-record for example) the output-record of the rectangle drawn with the :flip ink follows. That would be the case if this output-record has as its parent the presentation of the object. But then, how do I switch highlighting on and off efficiently? Would it work to *replay* the output-record of the rectangle with the flipping ink? As far as I understand, replay is mainly for refreshing or screnn updating and not usable for changes in the visual output!? I haven't had much luck using flipping ink with replay and incremental redisplay. You're right, its a problem. The obvious solution would be to go to a lower level than dragging-output-record. Use tracking-mouse. Every time the mouse moves, 1. Unhighlight the record (draw rectangle in flip ink) 2. Erase the record (Erase works by drawing a rectangle in the background ink and then replaying the records that happened to be in the same area.) 3. Move the record 4. Draw ("replay") the record 5. Highlight the record (draw rectangle in flip ink) It would be nice to see how the default highlighting method is implemented. (with-bounding-rectangle* (ll tt rr bb) record (draw-rectangle* stream ll tt rr bb :filled nil :ink clim:+flipping-ink+))   Received: from BBN.COM by LABS-N.BBN.COM id aa09131; 22 May 92 16:26 EDT Received: from gatech.edu by BBN.COM id aa15672; 22 May 92 16:15 EDT Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA26588 for clim@bbn.com; Fri, 22 May 92 16:15:29 EDT Received: from pravda.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA10270; Fri, 22 May 92 16:15:22 EDT Received: from kant.gatech.edu (kant.cc.gatech.edu) by pravda.cc.gatech.edu (4.1/SMI-4.1) id AA09932; Fri, 22 May 92 16:15:24 EDT Date: Fri, 22 May 1992 16:14-0400 From: Richard Billington Subject: Loading CLIM 1.1 To: clim@bbn.com Included-Msgs: <19920521194330.3.BUFF@kant.gatech.edu>, The message of 21 May 1992 15:43 EDT from buff@cc.gatech.edu, The message of 21 May 1992 15:43 EDT from Richard Billington Message-Id: <19920522201452.3.BUFF@kant.gatech.edu> I'm loading CLIM 1.1 (v.28.5) on some Symbolics 36xx machines. After loading v.28, and starting to load the first patch (i.e. v.28.1), I get an error reported on evaluating (find-class 'clim::clx-window) - namely, it's undefined. Anyone else get this error? Got a way around this? Of course I've reported this to Symbolics, but I'd really like to get this new version loaded up and running NOW. Thanks   Received: from BBN.COM by LABS-N.BBN.COM id aa03472; 26 May 92 14:20 EDT Received: from unido.Germany.EU.net by BBN.COM id aa05447; 26 May 92 13:21 EDT Received: from sger by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA29217; Tue, 26 May 92 19:22:36 +0200 Received: from EVEREST.SGER.UUCP by sger.SGER.COM (4.1/SMI-4.1) id AA04469; Tue, 26 May 92 18:56:57 +0200 Date: Tue, 26 May 1992 19:08+0200 From: Markus Fischer Reply-To: mf@sger.uucp Subject: CLIM Course in UK To: clim@bbn.com Message-Id: <19920526170810.2.MF@EVEREST.SGER.UUCP> Dear CLIM Programmers, due to the very encouraging response to the CLIM course in Germany in April this year, Symbolics, Ltd in England will be doing a 4-day CLIM course from June, 8th to 11th. For details please contact Symbolics UK directly as soon as possible: Daphne Powers, Symbolics, Ltd. Phone: +44 494 443711 Fax: +44 494 523939 Markus Fischer, MF@SGER.UUCP Mergenthaler Allee 77-81 Consulting Services W-6236 Eschborn, Germany Symbolics Systemhaus GmbH Phone: +49 6196 47220, Fax 481116   Received: from BBN.COM by LABS-N.BBN.COM id aa12505; 27 May 92 4:38 EDT Received: from [192.44.1.1] by BBN.COM id aa14253; 27 May 92 4:31 EDT Received: by fhg.de (fhg1.fhg.de) with PRESMTP; Wed, 27 May 92 10:28:47 +0200 from FHG-GATEWAY Received: by fhg.de (fhg1.fhg.de) with UUCP; Wed, 27 May 92 10:28:39 +0200 from imldo Received: by iml.fhg.de with SMTP; Wed, 27 May 92 10:16:40 +0200 Date: Wed, 27 May 1992 10:15+0200 From: Stefan Bernemann Subject: Re: "Grouping" of presentations To: jmorrill@BBN.COM Cc: clim@bbn.com In-Reply-To: <7428.706458297@bbn.com> Message-Id: <19920527081546.2.STEFAN@ANNA.iml.fhg.de> Date: Thu, 21 May 1992 16:24 MEST From: Jeff Morrill Date: Wed, 20 May 1992 15:05+0200 From: Stefan Bernemann Subject: "Grouping" of presentations To: clim@BBN.COM Hello, this time :-) I want to implement a feature of drawing applications or graph editors, namely the grouping of presentations. That means, I want to *replace* a set of presentations (no matter of what type) by ONE other presentation (e.g. of type "group"). This is rather easy to do using incremental redisplay. I have something like this for displaying tree-structured groupings. A non-terminal node in the tree has a "display children" bit that is either on or off. The display method on a node checks the bit and recurses if indicated. However, I don't want to erase and readraw any graphical output done to the screen, for efficienc reasons but mostly to minimize unnecessary screen flicker. That's exactly what the :cache-value option to updating-output is for. Sorry, I wasn't specific enough. The forming of groups, i.e. determining which objects (presentations) belong to one group, is done by the user. There is no a priori group structure. Consider the following example: ________ | | | A B | | | | C | | | |________| This shows (phantasy required!) a window with presentations A, B and C. Now the user selects presentations A and C and wants them to be ONE GROUP - that means, the presentations must be replaced by one presentation of type group or such: ________ | ___ | | |A |B | | | | | | | C| | | --- | |________| However, I don't want A and B do be *redrawn*. I don't see how I can use incremental redisplay for this - I think I have to manipulate the output history, but don't know how. Stefan B. Mail: Stefan Bernemann ! Phone: +49-231-9743-139 c/o FhG IML Dortmund ! Fax: +49-231-9743-234 Emil-Figge-Str. 75 ! Email: berni@iml.fhg.de D-4600 Dortmund 50, FRG !   Received: from BBN.COM by LABS-N.BBN.COM id aa16457; 27 May 92 10:05 EDT Received: from [131.246.136.50] by BBN.COM id aa26872; 27 May 92 9:43 EDT Received: from mail.dfki.uni-kl.de by stepsun.uni-kl.de id aa09536; 27 May 92 15:38 MET DST Received: from arctecserv-1.dfki.uni-kl.de by mail.dfki.uni-kl.de id aa05867; 27 May 92 15:39 MET DST Date: Wed, 27 May 92 15:42:18 MET DST From: Bernd Bachmann To: clim@bbn.com cc: przy@dfki.uni-kl.de Subject: Missing Fonts in CLIM Organization: German Research Center for AI (DFKI) Message-ID: <9205271542.aa16993@arctecserv-1.dfki.uni-kl.de> Whenever I start a CLIM application the debugger returns with the message Error: The FONTS: could not be found for the device 1-bit STATIC-GRAY X Screen INTERNET| with 0 Genera fonts (MIT X Consortium R4) in the function SI:GET-FONT However, the "Show Font" command for the same font works correctly. The thing happens on a SPARCstation with a Symbolics board under Genera 8.1 and CLIM 1.1. My question: Is there a way to make the fonts available for CLIM, a special format, or a special directory where these fonts must be located ? - Bernd Bachmann   Received: from BBN.COM by LABS-N.BBN.COM id aa17811; 27 May 92 11:49 EDT Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa03962; 27 May 92 11:42 EDT Received: from LILIKOI.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 822726; 27 May 1992 11:42:28-0400 Date: Wed, 27 May 1992 11:54-0400 From: Mark Nahabedian Subject: Missing Fonts in CLIM To: bachmann@dfki.uni-kl.de, clim@BBN.COM cc: przy@dfki.uni-kl.de In-Reply-To: <9205271542.aa16993@arctecserv-1.dfki.uni-kl.de> Message-ID: <19920527155436.7.NAHA@LILIKOI.SCRC.Symbolics.COM> From: Bernd Bachmann Whenever I start a CLIM application the debugger returns with the message Error: The FONTS: could not be found for the device 1-bit STATIC-GRAY X Screen INTERNET| with 0 Genera fonts (MIT X Consortium R4) in the function SI:GET-FONT However, the "Show Font" command for the same font works correctly. The thing happens on a SPARCstation with a Symbolics board under Genera 8.1 and CLIM 1.1. My question: Is there a way to make the fonts available for CLIM, a special format, or a special directory where these fonts must be located ? - Bernd Bachmann This sounds line a bug which was fixed in CLIM 1.1. Did you load patches? The bug had to do with an inconsistency in font naming conventions.   Received: from BBN.COM by LABS-N.BBN.COM id aa17664; 27 May 92 11:37 EDT Received: from stepsun.uni-kl.de by BBN.COM id aa03370; 27 May 92 11:30 EDT Received: from mail.dfki.uni-kl.de by stepsun.uni-kl.de id aa23660; 27 May 92 17:26 MET DST Received: from arctecserv-2.dfki.uni-kl.de by mail.dfki.uni-kl.de id aa06310; 27 May 92 17:27 MET DST Date: Wed, 27 May 92 17:30:01 MET DST From: Bernd Bachmann To: clim@bbn.com Subject: drawing DAGs Organization: German Research Center for AI (DFKI) Message-ID: <9205271730.aa25944@arctecserv-2.dfki.uni-kl.de> I would like to draw DAGs in CLIM; that is: real DAGs where each node occurs only once. Though Genera's CLIM documentation describes "clim:format-graph-from-root" behaving such way, in the example in the User's Guide nodes are drawn two times though they are identical from the LISP point of view. I assume that the :key parameter of the function is not evaluated since an undefined function as argument does not cause any error. Hence, there is no function that tries to find identical nodes based on this parameter. Has anybody fixed this problem? - Bernd Bachmann   Received: from BBN.COM by LABS-N.BBN.COM id aa18698; 27 May 92 13:13 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa08361; 27 May 92 13:09 EDT Received: from WATERMELON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1083079; 27 May 1992 13:09:24-0400 Date: Wed, 27 May 1992 13:13-0400 From: John G. Aspinall Subject: drawing DAGs To: bachmann@dfki.uni-kl.de cc: clim@BBN.COM In-Reply-To: <9205271730.aa25944@arctecserv-2.dfki.uni-kl.de> Message-ID: <19920527171324.4.JGA@WATERMELON.SCRC.Symbolics.COM> From: Bernd Bachmann I would like to draw DAGs in CLIM; that is: real DAGs where each node occurs only once. [...] Has anybody fixed this problem? This is fixed in CLIM 1.1.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa18449; 27 May 92 12:50 EDT Received: by KARIBA.BBN.COM id aa06991; 27 May 92 12:38 EDT To: Bernd Bachmann cc: clim@BBN.COM Subject: Re: drawing DAGs In-reply-to: Bernd Bachmann's message of Wed, 27 May 92 17:30:01 +0700. <9205271730.aa25944@arctecserv-2.dfki.uni-kl.de> Reply-To: jmorrill@BBN.COM Date: Wed, 27 May 92 12:39:46 -0400 Message-ID: <332.706984786@bbn.com> From: Jeff Morrill Date: Wed, 27 May 92 17:30:01 MET DST From: Bernd Bachmann To: clim@BBN.COM Subject: drawing DAGs Organization: German Research Center for AI (DFKI) I would like to draw DAGs in CLIM; that is: real DAGs where each node occurs only once. Though Genera's CLIM documentation describes "clim:format-graph-from-root" behaving such way, in the example in the User's Guide nodes are drawn two times though they are identical from the LISP point of view. I assume that the :key parameter of the function is not evaluated since an undefined function as argument does not cause any error. Hence, there is no function that tries to find identical nodes based on this parameter. Has anybody fixed this problem? - Bernd Bachmann All you get is trees. DAGs not yet implemented. Wait for clim 2.0.   Received: from BBN.COM by LABS-N.BBN.COM id aa20426; 27 May 92 15:13 EDT Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa15555; 27 May 92 15:07 EDT Received: from LILIKOI.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 822965; 27 May 1992 15:06:32-0400 Date: Wed, 27 May 1992 15:18-0400 From: Mark Nahabedian Subject: drawing DAGs To: bachmann@dfki.uni-kl.de, clim@BBN.COM In-Reply-To: <9205271730.aa25944@arctecserv-2.dfki.uni-kl.de> Message-ID: <19920527191841.9.NAHA@LILIKOI.SCRC.Symbolics.COM> CLIM-FORMAT-GRAPH-FROM-ROOTS is like FORMAT-GRAPH-FROM-ROOT (which calls it) but can take several root nodes. It has a :MERGE-DUPLICATES keyword option which will do what you want.   Received: from BBN.COM by LABS-N.BBN.COM id aa19936; 27 May 92 14:50 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa12788; 27 May 92 14:46 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA09733; Wed, 27 May 92 11:46:12 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA02808; Wed, 27 May 92 11:39:32 PDT Date: Wed, 27 May 92 11:39:32 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9205271839.AA02808@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: CLIM handling of parse-errors in accept w/ meta-presentation types Cc: cl-bugs@franz.com This is a question on how I should handle parse errors in my own presentation- type accept method, when you inherit the presentation into multiple classes and those classes are part of a meta presentation type used in a command. How can I get a more complete parse error message for the following: ;define a presentation type w/ your own accept method! (defun get-object-from (strg) t) ;fake it for illustration! (define-presentation-type my-type ()) (define-presentation-method accept ((type my-type)) stream (view textual-view) &key) (let* ((token (read-token stream)) (obj (get-object-from token))) (when (null obj) (simple-parse-error (format nil "Invalid ~a type" type))) (return-from accept obj))) (defclass one (my-type) ()) (defclass two (my-type) ()) ;in your application you have a command (define-my-application-command (com-test :name t) (obj '(or one two) (other t)) t) ;In the application interactor pane you enter: Test ;And you get the following! Invalid two type Please edit your input. Test (obj) ;My question is how can I get this instead? Invalid one or two type Please edit your input. Test (obj) ;It seems there is no facility for reaching meta-presentations within your ;accept method for indicating an error for input. Is there something else ;I should use instead of simple-parse-error. How can one make his own ;accept method recognize the fact that is it being used in a meta-presentation ;context?   Received: from BBN.COM by LABS-N.BBN.COM id aa29551; 28 May 92 9:04 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa11925; 28 May 92 8:52 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA29508; Thu, 28 May 92 05:52:41 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA03087; Thu, 28 May 92 05:45:59 PDT Date: Thu, 28 May 92 05:45:59 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9205281245.AA03087@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: CLIM handling of parse-errors in accept w/ meta-presentation types Cc: cl-bugs@franz.com Slight correction on my prior message. The function should return nil to guarantee that you hit the parse error part of the accept method. (defun get-object-from (strg) nil)   Received: from BBN.COM by LABS-N.BBN.COM id aa00987; 28 May 92 10:30 EDT Received: from sigi.cs.colorado.edu by BBN.COM id aa17362; 28 May 92 10:25 EDT Received: by sigi.cs.colorado.edu id AA22954 (5.65c/IDA-1.4.4 for CLIM Mailing List ); Thu, 28 May 1992 08:25:12 -0600 Date: Thu, 28 May 1992 08:25:12 -0600 From: Brent Reeves Message-Id: <199205281425.AA22954@sigi.cs.colorado.edu> To: CLIM Mailing List Subject: highlighting bug in dash-patterns of draw-line ? (Genera 8.1, CLIM 1.0) It appears the highlighting box surrounding lines drawn with the :dash-pattern option are off vertically by 1 pixel. Anybody else had difficulty with this? Moving the object around on the screen leaves bits all over the place, which - then clears. -brentr ---------------------------------------------------------------------- Brent Neal Reeves brentr@cs.colorado.edu (303) 492-1218 "visualize whirled peas"   Received: from BBN.COM by LABS-N.BBN.COM id aa03943; 28 May 92 14:19 EDT Received: from FUJI.ILA.COM by BBN.COM id aa26951; 28 May 92 14:05 EDT Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 312828; 28 May 92 13:58:41 EDT Date: Thu, 28 May 1992 10:58-0700 From: William M. York Subject: "Grouping" of presentations To: berni@iml.fhg.de, clim@bbn.com In-Reply-To: <19920520130527.4.STEFAN@ANNA.iml.fhg.de> Message-ID: <19920528175859.3.YORK@CHUCK-JONES.west.dialnet.ila.com> Date: Wed, 20 May 1992 06:05 PDT From: Stefan Bernemann this time :-) I want to implement a feature of drawing applications or graph editors, namely the grouping of presentations. That means, I want to *replace* a set of presentations (no matter of what type) by ONE other presentation (e.g. of type "group"). That is, I don't want to keep the old presentations of the objects (at least I want to change their types), because otherwise there would be the same access to objects be they contained in a group or not -- but it makes not sense (in my application) e.g. to drag a single presentation "inside a group" -- only the group as a whole may be manipulated. However, I don't want to erase and readraw any graphical output done to the screen, for efficienc reasons but mostly to minimize unnecessary screen flicker. Can this be done with CLIM? How must I fiddle with the output record and the history? Or am I completely off the road and the CLIM approach is totally different? (parameterized presentations?) I have included some sample code below. It basically takes the existing presentations and makes them children of a new "group" presentation, and then splices that new presentation in to the output record tree. I would have specified :ALLOW-SENSITIVE-INFERIORS NIL when creating the parent presentation, but that is not yet supported. This means that the individual members of the group remain sensitive, even while the group as a whole is sensitive. If that isn't what you want, you can try suppressing inner sensitivity by either directly altering the presentation types of the inferiors when they are grouped (of course you will have to keep track of the old type so that it can be restored when they are ungrouped), or maybe by writing a presentation translator that tests to see whether a presentation is a child of a group before allowing sensitivity. Try this out and let me know if you have any questions. ;;; -*- Mode: LISP; Syntax: Common-Lisp; Base: 10; Package: CLIM-USER -*- (in-package :clim-user) ;;; Group the supplied output records in a new parent presentation. ;;; The type and object of the new parent are passed as arguments. (defun group-output-records (output-record-list presentation-type presentation-object) ;; All the output records must share the same parent. (assert (reduce #'(lambda (a b) (and (eql a b) a)) output-record-list :key #'output-record-parent) () "All output records must all have the same parent.") ;; Make a new presentation to hold the others. (let ((new-parent (make-instance 'standard-presentation :type presentation-type :object presentation-object ;; :SINGLE-BOX means to make one ;; box around the whole group. :single-box t)) (original-parent (output-record-parent (first output-record-list)))) (dolist (child output-record-list) ;; Remove the records from their old parent. (delete-output-record-element original-parent child) ;; Make them children of the new presentation. (add-output-record-element new-parent child)) ;; Add the new parent presentation as a child of the original parent. (add-output-record-element original-parent new-parent) new-parent)) ;;; This test function creates two presentations, asks the user to select one, ;;; then groups the presentations and asks the user to select again. (defun test (win) ;; Assumes that the window is ~200 pixels high. (window-clear win) (window-expose win) (let ((records nil)) (push (with-output-as-presentation (:stream win :object 2 :type 'integer) (draw-rectangle* win 10 100 20 110)) records) (push (with-output-as-presentation (:stream win :object 3 :type 'integer) (draw-rectangle* win 50 150 60 160)) records) (accept 'integer :stream win) (group-output-records records 'integer 1) (accept 'integer :stream win)))   Received: from BBN.COM by LABS-N.bbn.COM id aa10921; 29 May 92 5:10 EDT Received: from fenrix.si.no by BBN.COM id aa15929; 29 May 92 5:02 EDT Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.23) id AA18596; Fri, 29 May 92 11:03:43 +0200 Date: Fri, 29 May 92 11:03:43 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9205290858.AAmonsun08610@D> To: clim@bbn.com Subject: transformation & highlighting I'm using CLIM 1.0 and MCL 2.0 (both beta) (Oh am I tired of adding 'both beta', I hope the real release comes soon) I'm drawing a graph and have made a command to change the scaling factor. It accepts a number and then installes a scaling-transformation with this number in both dimensions, with (setf medium-transformation). The drawing is scaled all right, but the box that is drawn when highlighting is scaled wrong: In fact it is scaled two times, as if composing it wioth itself. So when the scaling is 2 the box appears too far down and to the right and is too big, if it is 1/2 it appears too high and to the left and is too small. Is this a known bug or a known (typical) programmer fault? If it is a bug, is there a bug fix anywhere? And another question: When using a big scaling the drawing usually extends beyond the viewport, i.e. a lot of the drawing is clipped. But the scroll-bars aren't activated so I cannot scroll to see the whole drawing. What can be the problem? Regards, Hallvard Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.bbn.COM id aa12825; 29 May 92 8:53 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa20481; 29 May 92 8:45 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA24946; Fri, 29 May 92 05:45:03 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA03300; Fri, 29 May 92 05:38:21 PDT Date: Fri, 29 May 92 05:38:21 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9205291238.AA03300@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: Dumb question on presentation options w/ completion presentation type How do I utilize presentation options with the completion presentation type? The doc. excels at providing nil example on this and the explanation leaves me scratching my head. I have instances of objects that have their own present & accept methods and I can't seem to get them to present themselves in a manner different from the standard lisp princ form of an instance for the completion presentation type. Ie: (accept (list 'completion A-LIST-OF-FIVE-INSTANCES) :stream *my-stream* :prompt "WHICH ONE") If you hit help key in the interactor pane invoking this accept you get something like: WHICH ONE: # # # # # If I have a function that does a present-to-string such as: (defun present-my-instance (a) (present-to-string a 'my-instance-type)) I tried: (accept (list (list 'completion A-LIST-OF-FIVE-INSTANCES) :name-key #'present-my-instance) :stream *my-stream* :prompt "WHICH ONE") And I get the same results@^&$%@&? What am I missing?   Received: from BBN.COM by LABS-N.BBN.COM id aa18168; 29 May 92 16:09 EDT Received: from atc.boeing.com by BBN.COM id aa12792; 29 May 92 15:54 EDT Received: by atc.boeing.com (5.57) id AA02416; Fri, 29 May 92 12:54:21 PDT Received: by moclips.boeing.com (4.1/SMI-3.0DEV3) id AA08922; Fri, 29 May 92 12:56:13 PDT Date: Fri, 29 May 92 12:56:13 PDT Message-Id: <9205291956.AA08922@moclips.boeing.com> Return-Path: From: Stephen L Nicoud To: slug@ai.sri.com, clim@bbn.com Subject: GENERA size? Reply-To: stephen@boeing.com A manager in our organization wanted to know of some large object-oriented applications that have been built. I chimed in with Genera, Dynamic Windows, & CLIM, as examples of very large object-oriented-based systems. I also noted that the object-orientedness is extremely pervasive in these systems. Now, I've been asked to provide some "numbers" on how large they are. So, can anyone provide any numbers for sizing Genera, Dynamic Windows or CLIM? Off the top of my head, numbers like lines-of-code (yes, I know the drawbacks to using such a number; I've been following the debate on comp.software-eng.), MB (MW) of source, MB (MW) of binary, would be useful. I'll take any numbers right now. I will summarize to the net, so just send your replies to me at "stephen@boeing.com". Thanks, Stephen -- Stephen L Nicoud uw-beaver!bcsaic!stephen Boeing Computer Services Research and Technology, Computer Science Bellevue, Washington USA "I ask unanimous consent to revise and extend my remarks."   Received: from BBN.COM by LABS-N.BBN.COM id aa18854; 29 May 92 17:15 EDT Received: from atc.boeing.com by BBN.COM id aa16485; 29 May 92 17:08 EDT Received: by atc.boeing.com (5.57) id AA08252; Fri, 29 May 92 14:08:23 PDT Received: by moclips.boeing.com (4.1/SMI-3.0DEV3) id AA09094; Fri, 29 May 92 14:10:15 PDT Date: Fri, 29 May 92 14:10:15 PDT Message-Id: <9205292110.AA09094@moclips.boeing.com> Return-Path: From: Stephen L Nicoud To: slug@ai.sri.com, clim@bbn.com In-Reply-To: Stephen L Nicoud's message of 29 May 92 20:13:15 GMT <74103@bcsaic.boeing.com> Subject: GENERA size? Reply-To: stephen@boeing.com From: Stephen L Nicoud Date: 29 May 92 20:13:15 GMT So, can anyone provide any numbers for sizing Genera, Dynamic Windows or CLIM? Note, I no longer have access to Symbolics machines nor to a CLIM implementation. Consequently, I can't go use or code up a "counting" program that might analyze Genera & CLIM. Rough numbers (even guesstimates) would be useful. I've been given a short time frame in which to respond, so I expect a commensurate accuracy of numbers. Thanks again, Stephen   Received: from BBN.COM by LABS-N.BBN.COM id aa19574; 29 May 92 18:41 EDT Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa18674; 29 May 92 18:36 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 825131; 29 May 1992 18:36:23-0400 Date: Fri, 29 May 1992 18:36-0400 From: Douglas Dodds Subject: GENERA size? To: stephen@boeing.com cc: clim@bbn.com, Slug@ai.sri.com In-Reply-To: <9205291956.AA08922@moclips.boeing.com> Message-ID: <19920529223622.2.DODDS@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 29 May 1992 15:56 EDT From: stephen@boeing.com (Stephen L Nicoud) A manager in our organization wanted to know of some large object-oriented applications that have been built. I chimed in with Genera, Dynamic Windows, & CLIM, as examples of very large object-oriented-based systems. I also noted that the object-orientedness is extremely pervasive in these systems. Now, I've been asked to provide some "numbers" on how large they are. So, can anyone provide any numbers for sizing Genera, Dynamic Windows or CLIM? Off the top of my head, numbers like lines-of-code (yes, I know the drawbacks to using such a number; I've been following the debate on comp.software-eng.), MB (MW) of source, MB (MW) of binary, would be useful. I'll take any numbers right now. I will summarize to the net, so just send your replies to me at "stephen@boeing.com". I'll send this to the lists, as they may be of general interest and might provoke more detailed data and discussion. Symbolics has made various measures of the size of its systems in the past, usually informal and pretty approximate. I was unable to locate, in a quick search, any files with detailed data; all I have now is from several people's memories. The size of Genera (all of it, including the core applications that are included in the development Genera world that we ship) is roughly a million (1,000,000) lines of source code. It contains about 3500 flavors/classes. I'll try to dig up some more meaningful and detailed data, like number of symbols, number of functions/methods, methods per flavor/class, and so on. CLIM is a mere 60,000 lines of source code. I have no other numbers for it now. I have no numbers for Dynamic Windows as a separate entity, partly because it is not too well demarcated from the rest of Genera. I can get some measures, if we agree on what it includes: I would suggest including the dynamic window substrate, the presentation substrate, and the Command Processor, but not things like the common presentation types, core DW clients, etc. At a guess, this would be close to the same size as CLIM. I hope this is helpful. Douglas Dodds (dodds@symbolics.com) Symbolics, Inc. Concord, Mass.   Received: from BBN.COM by LABS-N.BBN.COM id aa05375; 31 May 92 21:08 EDT Received: from eola.cs.ucf.edu by BBN.COM id aa06971; 31 May 92 21:04 EDT Received: by eola.cs.ucf.edu (5.61/1.34) id AA12486; Sun, 31 May 92 21:03:36 EDT Date: Sun, 31 May 92 21:03:36 EDT From: hull@eola.cs.ucf.edu (Richard Hull) Message-Id: <9206010103.AA12486@eola.cs.ucf.edu> To: clim@BBN.COM Subject: Merging Duplicate Nodes using Formet-Graph-From-Root I am in the process of converting an application written using Dynamic Windows to CLIM. One problem I have come across is that the CLIM version of format- graph-from-root does not support the :dont-draw-duplicates keyword or anything remotely like it. Is there a way to merge duplicate nodes? BTW, I have version 1.0 of CLIM. Thanks in advance, Richard Hull UCF AI Labs hull@cs.ucf.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa12368; 1 Jun 92 9:32 EDT Received: from unido.Germany.EU.net by BBN.COM id aa01439; 1 Jun 92 9:23 EDT Received: from sger by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA21897; Mon, 1 Jun 92 15:23:46 +0200 Received: from FUJI-SAN.SGER.UUCP ([192.1.2.67]) by sger.SGER.COM (4.1/SMI-4.1) id AA07543; Mon, 1 Jun 92 14:44:03 +0200 Date: Mon, 1 Jun 1992 15:50+0200 From: Markus Fischer Reply-To: mf@sger.uucp Subject: Dumb question on presentation options w/ completion presentation type To: curt@eraserhead.jpl.nasa.gov Cc: clim@BBN.COM In-Reply-To: <9205291238.AA03300@eraserhead.Jpl.Nasa.Gov> Message-Id: <19920601135018.2.MF@FUJI-SAN.SGER.UUCP> Date: Fri, 29 May 1992 14:38+0200 From: Curt Eggemeyer How do I utilize presentation options with the completion presentation type? The doc. excels at providing nil example on this and the explanation leaves me scratching my head. I have instances of objects that have their own present & accept methods and I can't seem to get them to present themselves in a manner different from the standard lisp princ form of an instance for the completion presentation type. Ie: (accept (list 'completion A-LIST-OF-FIVE-INSTANCES) :stream *my-stream* :prompt "WHICH ONE") If you hit help key in the interactor pane invoking this accept you get something like: WHICH ONE: # # # # # If I have a function that does a present-to-string such as: (defun present-my-instance (a) (present-to-string a 'my-instance-type)) I tried: (accept (list (list 'completion A-LIST-OF-FIVE-INSTANCES) :name-key #'present-my-instance) :stream *my-stream* :prompt "WHICH ONE") And I get the same results@^&$%@&? What am I missing? Maybe you forgot to provide a PRESENT method to your presentation type? Anyway, the following works for me (in CLIM 1.1, contact Symbolics Software Service how to get it if you don't have it already) ;;; -*- Mode: LISP; Package: CLIM-USER -*- (defclass foo () ((n :initarg :n))) (defvar *five-foos* (loop for n from 1 to 5 collect (make-instance 'foo :n n))) (define-presentation-method present (object (type foo) stream (view T) &key) (format stream "FOO ~A" (slot-value object 'n))) (accept `((completion ,*five-foos*) :name-key ,#'(lambda (object) (format NIL "FOO ~A" (slot-value object 'n))))) (accept `((completion ,*five-foos*) :name-key ,#'present-to-string)) Markus Fischer, MF@SGER.UUCP Mergenthaler Allee 77-81 Consulting Services W-6236 Eschborn, Germany Symbolics Systemhaus GmbH Phone: +49 6196 47220, Fax 481116   Received: from BBN.COM by LABS-N.BBN.COM id aa12382; 1 Jun 92 9:33 EDT Received: from unido.Germany.EU.net by BBN.COM id aa01505; 1 Jun 92 9:24 EDT Received: from sger by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA21947; Mon, 1 Jun 92 15:23:55 +0200 Received: from FUJI-SAN.SGER.UUCP ([192.1.2.67]) by sger.SGER.COM (4.1/SMI-4.1) id AA07548; Mon, 1 Jun 92 14:49:16 +0200 Date: Mon, 1 Jun 1992 15:55+0200 From: Markus Fischer Reply-To: mf@sger.uucp Subject: Merging Duplicate Nodes using Formet-Graph-From-Root To: hull@eola.cs.ucf.edu Cc: clim@BBN.COM In-Reply-To: <9206010103.AA12486@eola.cs.ucf.edu> Message-Id: <19920601135534.3.MF@FUJI-SAN.SGER.UUCP> Date: Mon, 1 Jun 1992 03:03+0200 From: Richard Hull I am in the process of converting an application written using Dynamic Windows to CLIM. One problem I have come across is that the CLIM version of format- graph-from-root does not support the :dont-draw-duplicates keyword or anything remotely like it. Is there a way to merge duplicate nodes? BTW, I have version 1.0 of CLIM. Thanks in advance, Richard Hull UCF AI Labs hull@cs.ucf.edu For CLIM 1.1. see the following message. (Contact Symbolics Software Support how to get Release 1.1) -------------------------------------------------------------------------------- Date: Wed, 27 May 1992 15:18-0400 From: Mark Nahabedian Subject: drawing DAGs To: bachmann@dfki.uni-kl.de, clim@BBN.COM In-Reply-To: <9205271730.aa25944@arctecserv-2.dfki.uni-kl.de> Message-Id: <19920527191841.9.NAHA@LILIKOI.SCRC.Symbolics.COM> CLIM-FORMAT-GRAPH-FROM-ROOTS is like FORMAT-GRAPH-FROM-ROOT (which calls it) but can take several root nodes. It has a :MERGE-DUPLICATES keyword option which will do what you want. -------------------------------------------------------------------------------- Markus Fischer, MF@SGER.UUCP Mergenthaler Allee 77-81 Consulting Services W-6236 Eschborn, Germany Symbolics Systemhaus GmbH Phone: +49 6196 47220, Fax 481116   Received: from BBN.COM by LABS-N.BBN.COM id aa13729; 1 Jun 92 10:55 EDT Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa05761; 1 Jun 92 10:41 EDT Received: from WATERMELON.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 826091; 1 Jun 1992 10:08:00-0400 Date: Mon, 1 Jun 1992 10:12-0400 From: John G. Aspinall Subject: Merging Duplicate Nodes using Formet-Graph-From-Root To: hull@eola.cs.ucf.edu cc: clim@BBN.COM In-Reply-To: <9206010103.AA12486@eola.cs.ucf.edu> Message-ID: <19920601141238.6.JGA@WATERMELON.SCRC.Symbolics.COM> Date: Sun, 31 May 1992 21:03 EDT From: Richard Hull I am in the process of converting an application written using Dynamic Windows to CLIM. One problem I have come across is that the CLIM version of format- graph-from-root does not support the :dont-draw-duplicates keyword or anything remotely like it. Is there a way to merge duplicate nodes? BTW, I have version 1.0 of CLIM. As SWM and I have mentioned previously on this list, the new grapher with CLIM 1.1 provides this functionality.   Received: from BBN.COM by LABS-N.BBN.COM id aa15718; 1 Jun 92 13:06 EDT Received: from fenrix.si.no by BBN.COM id aa11452; 1 Jun 92 12:59 EDT Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.23) id AA28798; Mon, 1 Jun 92 19:01:21 +0200 Date: Mon, 1 Jun 92 19:01:21 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9206011656.AAmonsun09335@D> To: clim@bbn.com Subject: make-rectangle CLIM 1.0, MCL 2.0 (both beta): ? (clim:make-rectangle (clim:make-point 1 1) (clim:make-point 2 2)) > Error: :POINTS is an invalid initarg to INITIALIZE-INSTANCE for #. > Valid initargs: #(:MAX-Y :MAX-X :MIN-Y :MIN-X). > While executing: CCL::CHECK-INITARGS > Type Command-. to abort. See the RestartsI menu item for further choices. 1 > Is this another bug? Is there a patch somewhere? Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.BBN.COM id aa16914; 1 Jun 92 14:32 EDT Received: from FUJI.ILA.COM by BBN.COM id aa15223; 1 Jun 92 14:20 EDT Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 312993; 1 Jun 92 14:14:09 EDT Date: Mon, 1 Jun 1992 11:13-0700 From: William M. York Subject: GENERA size? To: stephen@boeing.com, slug@ai.sri.com, clim@bbn.com In-Reply-To: <9205291956.AA08922@moclips.boeing.com> Message-ID: <19920601181346.9.YORK@CHUCK-JONES.west.dialnet.ila.com> Date: Fri, 29 May 1992 12:56 PDT From: Stephen L Nicoud A manager in our organization wanted to know of some large object-oriented applications that have been built. I chimed in with Genera, Dynamic Windows, & CLIM, as examples of very large object-oriented-based systems. I also noted that the object-orientedness is extremely pervasive in these systems. Now, I've been asked to provide some "numbers" on how large they are. So, can anyone provide any numbers for sizing Genera, Dynamic Windows or CLIM? Off the top of my head, numbers like lines-of-code (yes, I know the drawbacks to using such a number; I've been following the debate on comp.software-eng.), MB (MW) of source, MB (MW) of binary, would be useful. I'll take any numbers right now. CLIM has about 2.3MB of source code. That compiles into different amounts of binary code on various platforms. There are 253 CLOS classes in CLIM. Many of them are related (i.e. share super/subclass relationships). Some are internal (that is, not documented or exported to the CLIM user), but I think that they still count for your purposes.   Received: from BBN.COM by LABS-N.BBN.COM id aa17404; 1 Jun 92 15:07 EDT Received: from FUJI.ILA.COM by BBN.COM id aa18637; 1 Jun 92 14:59 EDT Received: from CHUCK-JONES.WEST.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 312997; 1 Jun 92 14:53:02 EDT Date: Mon, 1 Jun 1992 11:31-0700 From: William M. York Subject: make-rectangle To: Hallvard.Tretteberg@si.no, clim@bbn.com In-Reply-To: <9206011656.AAmonsun09335@D> Message-ID: <19920601183147.0.YORK@CHUCK-JONES.west.dialnet.ila.com> Date: Mon, 1 Jun 1992 10:01 PDT From: Hallvard.Tretteberg@si.no CLIM 1.0, MCL 2.0 (both beta): ? (clim:make-rectangle (clim:make-point 1 1) (clim:make-point 2 2)) > Error: :POINTS is an invalid initarg to INITIALIZE-INSTANCE for #. > Valid initargs: #(:MAX-Y :MAX-X :MIN-Y :MIN-X). > While executing: CCL::CHECK-INITARGS > Type Command-. to abort. See the RestartsI menu item for further choices. 1 > Is this another bug? Is there a patch somewhere? Yup, it is a bug. Try compiling the following: ;;; -*- Mode: LISP; Syntax: Common-lisp; Package: CLIM-UTILS; Base: 10; Lowercase: Yes -*- (in-package "CLIM-UTILS") (defclass standard-rectangle (rectangle) ((min-x :initarg :min-x :reader rectangle-min-x :type real) (min-y :initarg :min-y :reader rectangle-min-y :type real) (max-x :initarg :max-x :reader rectangle-max-x :type real) (max-y :initarg :max-y :reader rectangle-max-y :type real) (points :initarg :points :type simple-vector :reader polygon-points)))   Received: from BBN.COM by LABS-N.BBN.COM id aa12477; 3 Jun 92 9:28 EDT Received: from [129.233.11.11] by BBN.COM id aa21755; 3 Jun 92 9:14 EDT Received: by io.IPA.FhG.de (5.61+/IDA-1.2.8/gandalf.2) id AA13051; Wed, 3 Jun 92 15:15:48 +0200 Message-Id: <9206031315.AA13051@io.IPA.FhG.de> From: Michael Kempf Subject: CLIM standard ? To: clim@bbn.com Date: Wed, 3 Jun 92 15:15:47 MET DST X-Mailer: ELM [version 2.3 PL11] Is there any standard of CLIM and if so, does anybody know a book or paper, which describes the standard functionality of CLIM ? Thanx in advance, Mike   Received: from BBN.COM by LABS-N.BBN.COM id aa15202; 3 Jun 92 12:29 EDT Received: from unido.Germany.EU.net by BBN.COM id aa01081; 3 Jun 92 12:22 EDT Received: from sger by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA10085; Wed, 3 Jun 92 18:23:32 +0200 Received: from FUJI-SAN.SGER.UUCP ([192.1.2.67]) by sger.SGER.COM (4.1/SMI-4.1) id AA09090; Wed, 3 Jun 92 17:55:45 +0200 Date: Wed, 3 Jun 1992 19:02+0200 From: Markus Fischer Subject: transformation & highlighting To: Hallvard.Tretteberg@si.no, clim@BBN.COM In-Reply-To: <9205290858.AAmonsun08610@D> Message-Id: <19920603170202.4.MF@FUJI-SAN.SGER.UUCP> Date: Fri, 29 May 1992 11:03+0200 From: unido!si.no!Hallvard.Tretteberg I'm using CLIM 1.0 and MCL 2.0 (both beta) (Oh am I tired of adding 'both beta', I hope the real release comes soon) I'm drawing a graph and have made a command to change the scaling factor. It accepts a number and then installes a scaling-transformation with this number in both dimensions, with (setf medium-transformation). The drawing is scaled all right, but the box that is drawn when highlighting is scaled wrong: In fact it is scaled two times, as if composing it wioth itself. So when the scaling is 2 the box appears too far down and to the right and is too big, if it is 1/2 it appears too high and to the left and is too small. Is this a known bug or a known (typical) programmer fault? If it is a bug, is there a bug fix anywhere? That sounds like a bug, but I never saw a behavior like that on the Genera implementation of CLIM. And another question: When using a big scaling the drawing usually extends beyond the viewport, i.e. a lot of the drawing is clipped. But the scroll-bars aren't activated so I cannot scroll to see the whole drawing. What can be the problem? I don't know what you mean by "activated". The behavior is that drawing is clipped but the scroll bars aren't *redrawn*, that is, they don't reflect the new vieport/window relationship. However, you should be able to *use* the scroll bars, i.e. click on it to change the viewports position. If you want the behavior (what would be more accurate), that the scroll bars are redrawn you have to call CLIM:WINDOW-REFRESH. A faster solution - but NOT part of the documented CLIM function level - is CLIM::REDIISPLAY-DECORATIONS. Markus Fischer, MF@SGER.UUCP Mergenthaler Allee 77-81 Consulting Services W-6236 Eschborn, Germany Symbolics Systemhaus GmbH Phone: +49 6196 47220, Fax 481116   Received: from BBN.COM by LABS-N.BBN.COM id aa19800; 3 Jun 92 18:18 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa19126; 3 Jun 92 18:08 EDT Received: from DJINN.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1086844; 3 Jun 1992 17:29:56-0400 Date: Wed, 3 Jun 1992 17:30-0400 From: Scott McKay Subject: Selecting Presentations To: gensym!bhyde@harvard.harvard.edu cc: clim@BBN.COM In-Reply-To: <9205191426.AA05042@gensym.com> Message-ID: <19920603213002.2.SWM@DJINN.SCRC.Symbolics.COM> Date: Tue, 19 May 1992 10:26 EDT From: "Ben A. Hyde" Thank you for raising one of the serious design problems that CLIM ignores! It will be fun to watch the discussion develop. - ben hyde, cambridge Just to spoil everyone's fun, I will assert that this facility is not the province of CLIM, but is rather the province of a higher-level collection of application-building tools.   Received: from BBN.COM by LABS-N.BBN.COM id aa24621; 4 Jun 92 4:33 EDT Received: from unido.Germany.EU.net by BBN.COM id aa00392; 4 Jun 92 4:22 EDT Received: from sger by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA27021; Thu, 4 Jun 92 10:23:17 +0200 Received: from FUJI-SAN.SGER.UUCP ([192.1.2.67]) by sger.SGER.COM (4.1/SMI-4.1) id AA09463; Thu, 4 Jun 92 10:05:28 +0200 Date: Thu, 4 Jun 1992 11:11+0200 From: Markus Fischer Reply-To: mf@sger.uucp Subject: CLIM standard ? To: kempf@ipa.fhg.de, clim@BBN.COM In-Reply-To: <9206031315.AA13051@io.IPA.FhG.de> Message-Id: <19920604091159.7.MF@FUJI-SAN.SGER.UUCP> From: Michael Kempf Is there any standard of CLIM and if so, does anybody know a book or paper, which describes the standard functionality of CLIM ? Thanx in advance, Mike The Symbolics book "Common Lisp Interface Manager (CLIM): Release 1.0" that comes with practically all CLIM implementations, describes the current standard. There is a more formal and accurate specification for the release 2.0 of CLIM, which will be the base for all implementations of CLIM 2.0 to come. As far as I know, there is no CLIM book like the S.Keene's about CLOS, in case you have something like that in mind. Markus Fischer, MF@SGER.UUCP Mergenthaler Allee 77-81 Consulting Services W-6236 Eschborn, Germany Symbolics Systemhaus GmbH Phone: +49 6196 47220, Fax 481116   Received: from BBN.COM by LABS-N.BBN.COM id aa04603; 4 Jun 92 18:05 EDT Received: from sigi.cs.colorado.edu by BBN.COM id aa02745; 4 Jun 92 17:55 EDT Received: by sigi.cs.colorado.edu id AA10551 (5.65c/IDA-1.4.4 for CLIM Mailing List ); Thu, 4 Jun 1992 15:55:51 -0600 Date: Thu, 4 Jun 1992 15:55:51 -0600 From: Brent Reeves Message-Id: <199206042155.AA10551@sigi.cs.colorado.edu> To: CLIM Mailing List Subject: Access to Program Framework Layouts (Genera 8.1, CLIM 1.0) 1. How can I access the possible layouts of a program-framework? as in: (set-frame-layout *application-frame* (menu-choose (??possible-layouts?? *application-frame*)) 2. Any way to get at the pane configurations in each layout? This way the above could present a menu of miniature or iconized layouts rather than just the names. ---------------------------------------------------------------------- Brent Neal Reeves brentr@cs.colorado.edu (303) 492-1218 "visualize whirled peas"   Received: from BBN.COM by LABS-N.BBN.COM id aa14293; 5 Jun 92 12:01 EDT Received: from noc.BelWue.DE by BBN.COM id aa29083; 5 Jun 92 11:49 EDT Received: from adler.philosophie.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA00277 (5.65c/BelWue-M2.03 for ); Fri, 5 Jun 1992 17:49:22 +0200 Received: from greif.philosophie.uni-stuttgart.de by adler.philosophie.uni-stuttgart.de (4.1/BelWue-1.2SUN) id AA27694; Fri, 5 Jun 92 17:49:20 +0200 Date: Fri, 5 Jun 92 17:49:20 +0200 From: Oliver Christ Message-Id: <9206051549.AA27694@adler.philosophie.uni-stuttgart.de> Received: by greif.philosophie.uni-stuttgart.de (4.1/BelWue-1.2SUN) id AA01657; Fri, 5 Jun 92 17:49:20 +0200 To: clim@bbn.com Subject: Question concerning methods Reply-To: oli@adler.philosophie.uni-stuttgart.de Dear CLIMmers, I'm currently building an application interface with CLIM (1.0 & 1.1 on Lucid and Allegro). One way to detect whether the execution of some code affects the representation of interface objects is to provide :after-methods for those application functions which might affect the interface state. So, it is not necessary to change the application code itself. I don't know if I made this clear, so an example would be: in the application code: (defmethod create-new-application-object (arg1 arg2) ...) in the interface code: (defmethod create-new-application-object :after (a1 a2) ... (redisplay-pane ...)) My problem is now, that the interface code should be independent from the application code (and, of course, vice versa), that is, I don't want to "copy" the lambda-list of the application code into the after method of the interface myself. What I have in mind is a macro which dynamically defines the after method and gets the lambda-list from the generic function: (define-after-method-for-generic-function 'create-new-application-object ...body...) Now, I haven't found a legal way to get the lambda-list of a generic function. In Allegro4.1, it is in the slot "CLOS::PRETTY-ARGLIST", in Lucid, it is in the slot "CLOS::LAMBDA-LIST" of the generic function object. My question is whether anybody has found a legal (Ansi-Draft-Conforming...) way to get the lambda-list of a generic function object. Any hints are welcome, Oli ----------------------------------------------------- oli@adler.philosophie.uni-stuttgart.de christ@is.informatik.uni-stuttgart.de Oliver Christ, Student of Computer Science at the University of Stuttgart, Germany -----------------------------------------------------   Received: from BBN.COM by LABS-N.BBN.COM id aa14374; 5 Jun 92 12:09 EDT Received: from fenrix.si.no by BBN.COM id aa29784; 5 Jun 92 12:05 EDT Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.23) id AA04630; Fri, 5 Jun 92 18:06:53 +0200 Date: Fri, 5 Jun 92 18:06:53 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9206051601.AAmonsun10072@D> To: chris@starbase.mitre.org Cc: clim@BBN.COM In-Reply-To: Chris Elsaesser's message of Fri, 5 Jun 92 11:19:02 EDT <9206051519.AA28457@starbase.mitre.org> Subject: changing layouts Date: Fri, 5 Jun 92 11:19:02 EDT From: Chris Elsaesser Dear CLIM, In Genera 8.1 CLIM 1.0, every time I do a (clim::set-frame-layout ) from a command (e.g, com-foo), everything that follows the call to clim::set-frame-layout is ignored. What am I doing wrong? chris Quote from the manual: "clim::set-frame-layout throws out of the applications command loop, all the way back to clim:run-frame-top-level." Hallvard   Received: from BBN.COM by LABS-N.BBN.COM id aa13951; 5 Jun 92 11:34 EDT Received: from mwunix.mitre.org by BBN.COM id aa27898; 5 Jun 92 11:21 EDT Return-Path: Received: from starbase.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA15585; Fri, 5 Jun 92 11:19:15 -0400 Received: by starbase.mitre.org (4.1/SMI-4.1) id AA28457; Fri, 5 Jun 92 11:19:02 EDT Date: Fri, 5 Jun 92 11:19:02 EDT From: chris@starbase.MITRE.ORG (Chris Elsaesser) Message-Id: <9206051519.AA28457@starbase.mitre.org> To: clim@bbn.com Subject: changing layouts Dear CLIM, In Genera 8.1 CLIM 1.0, every time I do a (clim::set-frame-layout ) from a command (e.g, com-foo), everything that follows the call to clim::set-frame-layout is ignored. What am I doing wrong? chris   Received: from BBN.COM by LABS-N.BBN.COM id aa15220; 5 Jun 92 13:06 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa02236; 5 Jun 92 13:03 EDT Received: from WATERMELON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1087993; 5 Jun 1992 13:04:02-0400 Date: Fri, 5 Jun 1992 13:08-0400 From: John G. Aspinall Subject: changing layouts To: chris@starbase.mitre.org cc: clim@BBN.COM In-Reply-To: <9206051519.AA28457@starbase.mitre.org> Message-ID: <19920605170831.8.JGA@WATERMELON.SCRC.Symbolics.COM> Date: Fri, 5 Jun 1992 11:19 EDT From: Chris Elsaesser In Genera 8.1 CLIM 1.0, every time I do a (clim::set-frame-layout ) from a command (e.g, com-foo), everything that follows the call to clim::set-frame-layout is ignored. What am I doing wrong? set-frame-layout does a throw out to the command loop; and therefore the rest of your command is not executed. This is documented.   Received: from BBN.COM by LABS-N.BBN.COM id aa16279; 5 Jun 92 14:20 EDT Received: from gatech.edu by BBN.COM id aa06819; 5 Jun 92 14:16 EDT Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA23850 for clim@bbn.com; Fri, 5 Jun 92 14:16:02 EDT Received: from pravda.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA09860; Fri, 5 Jun 92 14:15:55 EDT Received: from kant.gatech.edu (kant.cc.gatech.edu) by pravda.cc.gatech.edu (4.1/SMI-4.1) id AA19003; Fri, 5 Jun 92 14:15:49 EDT Date: Fri, 5 Jun 1992 14:15-0400 From: Richard Billington Subject: changing layouts To: chris@starbase.mitre.org Cc: clim@bbn.com In-Reply-To: <9206051519.AA28457@starbase.mitre.org> Message-Id: <19920605181523.0.BUFF@kant.gatech.edu> Date: Fri, 5 Jun 1992 11:19 EDT From: Chris Elsaesser Dear CLIM, In Genera 8.1 CLIM 1.0, every time I do a (clim::set-frame-layout ) from a command (e.g, com-foo), everything that follows the call to clim::set-frame-layout is ignored. What am I doing wrong? chris The documentation even predicts this will happen: (p.375, Symbolics doc.) Note: clim:set-frame-layout throws out of the applications command loop ... you should only [call it] *after* you have done everything else in the sequence of operations.   Received: from BBN.COM by LABS-N.BBN.COM id aa17812; 5 Jun 92 16:31 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa15232; 5 Jun 92 16:25 EDT Received: from DJINN.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1088152; 5 Jun 1992 16:25:53-0400 Date: Fri, 5 Jun 1992 16:26-0400 From: Scott McKay Subject: Access to Program Framework Layouts To: brentr@sigi.cs.colorado.edu, clim@BBN.COM In-Reply-To: <199206042155.AA10551@sigi.cs.colorado.edu> Message-ID: <19920605202600.1.SWM@DJINN.SCRC.Symbolics.COM> Date: Thu, 4 Jun 1992 17:55 EDT From: Brent Reeves (Genera 8.1, CLIM 1.0) 1. How can I access the possible layouts of a program-framework? as in: (set-frame-layout *application-frame* (menu-choose (??possible-layouts?? *application-frame*)) Sad but true, this is the only way to do it. I don't think it occurred to anyone to do this in an obvious way. (loop for (name . layout) in (clim::frame-descriptor-layout (clim::find-frame-descriptor *application-frame*)) collect name) 2. Any way to get at the pane configurations in each layout? This way the above could present a menu of miniature or iconized layouts rather than just the names. No, besides decoding the layout yourself, there isn't any way to do this.   Received: from BBN.COM by LABS-N.BBN.COM id aa20798; 5 Jun 92 23:28 EDT Received: from uu.psi.com by BBN.COM id aa03064; 5 Jun 92 23:23 EDT Received: from aolsys.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) id AA04284; Fri, 5 Jun 92 23:10:15 -0400 From: trinkos@aol.com X-Mailer: America Online Mailer To: clim@bbn.com Subject: question about interface Date: Fri, 05 Jun 92 23:04:44 EDT Message-Id: <9206052304.tn10332@aol.com> I'm porting a large project from dw: to clim and I have some questions 1) Is there an easy way to alphabetize commands in menus 2) How do you attach mouse gestures to menu commands--ie have the menu item respond differently to mouse left, right, etc. Thanks for any help   Received: from BBN.COM by LABS-N.BBN.COM id aa02718; 7 Jun 92 10:47 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa04943; 7 Jun 92 10:42 EDT Received: from DJINN.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1086886; 3 Jun 1992 18:10:21-0400 Date: Wed, 3 Jun 1992 18:10-0400 From: Scott McKay Subject: CLIM standard ? To: kempf@ipa.fhg.de, clim@BBN.COM In-Reply-To: <9206031315.AA13051@io.IPA.FhG.de> Message-ID: <19920603221027.6.SWM@DJINN.SCRC.Symbolics.COM> From: Michael Kempf Is there any standard of CLIM and if so, does anybody know a book or paper, which describes the standard functionality of CLIM ? There is a CLIM 2.0 spec that is moving towards public review. It is long and involved, so I won't yet offer it to you. You might call a sales rep at a Lisp vendor (Symbolics, Lucid, Franz, Harlequin, ILA) to see if they can send you documentation. Thanx in advance, Mike   Received: from BBN.COM by LABS-N.BBN.COM id aa10542; 8 Jun 92 7:57 EDT Received: from unido.Germany.EU.net by BBN.COM id aa05770; 8 Jun 92 7:52 EDT Received: from sger by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA06359; Mon, 8 Jun 92 13:53:44 +0200 Received: from FUJI-SAN.SGER.UUCP ([192.1.2.67]) by sger.SGER.COM (4.1/SMI-4.1) id AA11628; Mon, 8 Jun 92 13:29:58 +0200 Date: Mon, 8 Jun 1992 14:36+0200 From: Markus Fischer Reply-To: mf@sger.uucp Subject: question about interface To: trinkos@aol.com, clim@BBN.COM In-Reply-To: <9206052304.tn10332@aol.com> Supersedes: <19920608123615.3.MF@FUJI-SAN.SGER.UUCP> Message-Id: <19920608123649.4.MF@FUJI-SAN.SGER.UUCP> Date: Sat, 6 Jun 1992 05:04+0200 From: unido!aol.com!trinkos I'm porting a large project from dw: to clim and I have some questions 1) Is there an easy way to alphabetize commands in menus If you mean "sorting in alphabetical order" by "alphabetize", have a look at the code below, it only uses documented CLIM features. I wrote it half a year ago or so, but I tink it still works (but beware: only tested for Symbolics' CLIM implementation). -------------------- (defun sort-command-table-menu-items (command-table sorting-predicate &optional (sorting-key #'identity)) "removes all menu items and re-inserts them in a sorted way" (let ((menu-items NIL)) (map-over-command-table-menu-items #'(lambda (menu-item-name keystroke type-and-value) ;; create a list that can be used as argument list to add-menu-item-to-command-table (push (list menu-item-name (first type-and-value) (second type-and-value) :keystroke keystroke) menu-items)) command-table) (setq menu-items (sort menu-items sorting-predicate :key #'(lambda (menu-item-description) (funcall sorting-key (first menu-item-description))))) (dolist (menu-item-description menu-items) (remove-menu-item-from-command-table command-table (first menu-item-description)) (apply 'add-menu-item-to-command-table command-table menu-item-description)))) -------------------- 2) How do you attach mouse gestures to menu commands--ie have the menu item respond differently to mouse left, right, etc. I suggest writing presentation-translators to the command presentation type. Keep in mind, that the command presentation type takes a command-table as parameter, i.e., a command ptype could look like (COMMAND :COMMAND-TABLE clim-demo::lisp-listener). In the translator you can specify a gesture. There are several predefine gesture names, e.g. :SELECT, :DESCRIBE. You can define new ones with DEFINE-GESTURE-NAME. See the doc for more info about that topic. Markus Fischer, MF@SGER.UUCP Mergenthaler Allee 77-81 Consulting Services W-6236 Eschborn, Germany Symbolics Systemhaus GmbH Phone: +49 6196 47220, Fax 481116   Received: from BBN.COM by LABS-N.BBN.COM id ab10831; 8 Jun 92 8:28 EDT Received: from unido.Germany.EU.net by BBN.COM id aa06667; 8 Jun 92 8:25 EDT Received: from sger by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA06352; Mon, 8 Jun 92 13:53:41 +0200 Received: from FUJI-SAN.SGER.UUCP ([192.1.2.67]) by sger.SGER.COM (4.1/SMI-4.1) id AA11622; Mon, 8 Jun 92 13:13:59 +0200 Date: Mon, 8 Jun 1992 14:20+0200 From: Markus Fischer Reply-To: mf@sger.uucp Subject: Question concerning methods To: oli@adler.philosophie.uni-stuttgart.de, clim@BBN.COM In-Reply-To: <9206051549.AA27694@adler.philosophie.uni-stuttgart.de> Message-Id: <19920608122049.2.MF@FUJI-SAN.SGER.UUCP> Date: Fri, 5 Jun 1992 17:49+0200 From: Oliver Christ Dear CLIMmers, I'm currently building an application interface with CLIM (1.0 & 1.1 on Lucid and Allegro). One way to detect whether the execution of some code affects the representation of interface objects is to provide :after-methods for those application functions which might affect the interface state. So, it is not necessary to change the application code itself. I don't know if I made this clear, so an example would be: in the application code: (defmethod create-new-application-object (arg1 arg2) ...) in the interface code: (defmethod create-new-application-object :after (a1 a2) ... (redisplay-pane ...)) My problem is now, that the interface code should be independent from the application code (and, of course, vice versa), that is, I don't want to "copy" the lambda-list of the application code into the after method of the interface myself. What I have in mind is a macro which dynamically defines the after method and gets the lambda-list from the generic function: (define-after-method-for-generic-function 'create-new-application-object ...body...) Now, I haven't found a legal way to get the lambda-list of a generic function. In Allegro4.1, it is in the slot "CLOS::PRETTY-ARGLIST", in Lucid, it is in the slot "CLOS::LAMBDA-LIST" of the generic function object. My question is whether anybody has found a legal (Ansi-Draft-Conforming...) way to get the lambda-list of a generic function object. Well, this question does not really belong to this mailing list, because it is really concerned about plain CLOS. Anyway, I propose the following: 1. There is a function called CLOS:GENERIC-FUNCTION-LAMBDA-LIST, which is implemented in the CLOS versions of Symbolics and Lucid (at least >=4.0 for SUNs). Allegro doesn't support it, I think. BUT if I understood you correctly, you need the lambda list of your methods, not generic functions, because in generic functions there are no specializers, which you do have in methods. So watch out for CLOS:METHOD-LAMBDA-LIST or something like that. 2. I would suggest another way of solving the problem. Write a macro named DEFINE-METHOD-FOR-INTERFACE or so, that takes a legal lambda list for CLOS methods and two bodies/forms. The macro then expands to both the normal method and the :after method you want to have for your UI stuff. In this solution you don't have to cope with any CLOS details or internals. Hope that helps a bit or gives you new ideas, Markus Fischer, MF@SGER.UUCP Mergenthaler Allee 77-81 Consulting Services W-6236 Eschborn, Germany Symbolics Systemhaus GmbH Phone: +49 6196 47220, Fax 481116   Received: from BBN.COM by LABS-N.BBN.COM id aa11390; 8 Jun 92 9:23 EDT Received: from liasun1.epfl.ch by BBN.COM id aa09123; 8 Jun 92 9:15 EDT Received: by liasun1.epfl.ch (/\==/\ Smail3.1.25.1 #25.42) id ; Mon, 8 Jun 92 15:14 MET DST Message-Id: Date: Mon, 8 Jun 92 15:14 MET DST From: simon@lia.di.epfl.ch (Simon Leinen) To: mf%sger.uucp@BBN.COM Cc: oli@adler.philosophie.uni-stuttgart.de, clim@BBN.COM Subject: Question concerning methods References: <9206051549.AA27694@adler.philosophie.uni-stuttgart.de> <19920608122049.2.MF@FUJI-SAN.SGER.UUCP> Full-Name: Simon Leinen > 1. There is a function called CLOS:GENERIC-FUNCTION-LAMBDA-LIST, > which is implemented in the CLOS versions of Symbolics and Lucid (at > least >=4.0 for SUNs). Allegro doesn't support it, I think. Allegro 4.1 beta/final has both CLOS:GENERIC-FUNCTION-LAMBDA-LIST and CLOS:METHOD-LAMBDA-LIST. > BUT if I understood you correctly, you need the lambda list of your > methods, not generic functions, because in generic functions there > are no specializers, which you do have in methods. So watch out for > CLOS:METHOD-LAMBDA-LIST or something like that. -- Simon.   Received: from BBN.COM by LABS-N.BBN.COM id aa12464; 8 Jun 92 10:43 EDT Received: from lucid.com by BBN.COM id aa14253; 8 Jun 92 10:33 EDT Received: from kuwait.lucid ([192.31.212.118]) by heavens-gate.lucid.com id AA11831g; Mon, 8 Jun 92 07:24:28 PDT Received: by kuwait.lucid (4.1/SMI-4.1) id AA07029; Mon, 8 Jun 92 07:32:43 PDT Date: Mon, 8 Jun 92 07:32:43 PDT From: kern%kuwait@lucid.com (John Kern) Message-Id: <9206081432.AA07029@kuwait.lucid> To: mf%sger.uucp@BBN.COM Cc: oli@adler.philosophie.uni-stuttgart.de, clim@BBN.COM In-Reply-To: Markus Fischer's message of Mon, 8 Jun 1992 14:20+0200 <19920608122049.2.MF@FUJI-SAN.SGER.UUCP> Subject: Question concerning methods Reply-To: kern@lucid.com Howdy, Now, I haven't found a legal way to get the lambda-list of a generic function. In Allegro4.1, it is in the slot "CLOS::PRETTY-ARGLIST", in Lucid, it is in the slot "CLOS::LAMBDA-LIST" of the generic function object. I believe most vendors are adhering to David Moon's Proposal for the MetaObject protocal for introspection. GENERIC-FUNCTION-LAMBDA-LIST is the equivalent of CLOS::LAMBDA-LIST and is part of Lucid's forthcoming 4.1 release. Sincerely, John S. Kern Lucid, Inc. Customer Support ================ copy of proposal ======================= Date: Sun, 4 Mar 90 18:28 EST From: David A. Moon Subject: Proposed de facto standard subset of metaobjects To: Common-Lisp-Object-System@MCC.COM . . . The full CLOS metaobject facility provides a model of the system that can be used both for introspection (a program examining its own structure) and for extension (changing the behavior of metaobjects and implementation of new object-oriented languages within the CLOS framework). What is being proposed here is only introspection. While extension is useful and needed, it is clearly more difficult and not as ready for standardization as introspection, so it will have to wait until later. . . . For now we are only proposing names, not precise definitions of what they do. The definitions will be necessary, but they are a lot of work so we'll do that later, after we see whether it is possible to agree on the names. At Symbolics we came up with three packages (COMMON-LISP, CLOS, and CLOS-INTERNALS). COMMON-LISP is the package whose contents is defined by ANSI Common Lisp. CLOS is the package that exports all the "standardized" symbols of CLOS, not only the ones defined by ANSI Common Lisp but also some others that make sense to standardize on in a de facto way. The idea is that a program can :USE CLOS in its DEFPACKAGE, or use CLOS: package prefixes throughout the program, to get the CLOS facilities that one would expect to be portable to other implementations. The name and existence of the CLOS package is part of the proposed de facto standard. CLOS-INTERNALS exports the things that we might want wizardly users and our own tools to use, but that are not being proposed for standardization. Things in CLOS-INTERNALS are not necessarily compatible even among Symbolics' own various implementations and are not being proposed as a standard. There's no need even to agree on the name of that package; indeed, Lucid does not use that particular package name. Exporting the ANSI Common Lisp standardized symbols of CLOS from the package named CLOS facilitates using CLOS in programs that are otherwise written using the CLtL dialect rather than the ANSI dialect. I believe the policy we're working from can be succinctly stated as "exports from the CLOS package are all and only those symbols which are the current (draft proposed) ANSI standard CLOS or seem likely to be recommended for future ANSI standardization." The remainder of this message lists the proposed external symbols of the CLOS package, in three parts. The first part is a list of the extensions to standardized CLOS being proposed at this time. The second part is a list of additional extensions that only apply to Common Lisps that support locatives. That list is being proposed at this time, but does not apply to most Common Lisp implementations; these symbols would only exist in implementations that actually have locatives. The third part is a list of the symbols in standardized CLOS, for completeness. NON-ANSI-STANDARD SYMBOLS EXPORTED BY THE CLOS PACKAGE: CLASS-DEFAULT-INITARGS CLOS generic function CLASS-DIRECT-DEFAULT-INITARGS CLOS generic function CLASS-DIRECT-SLOTS CLOS generic function CLASS-DIRECT-SUBCLASSES CLOS generic function CLASS-DIRECT-SUPERCLASSES CLOS generic function CLASS-PRECEDENCE-LIST CLOS generic function CLASS-PROTOTYPE CLOS generic function CLASS-SLOTS CLOS generic function COMPUTE-EFFECTIVE-METHOD CLOS generic function FORWARD-REFERENCED-CLASS class name FUNCALLABLE-STANDARD-CLASS class name GENERIC-FUNCTION-ARGUMENT-PRECEDENCE-ORDER CLOS generic function GENERIC-FUNCTION-DECLARATIONS CLOS generic function GENERIC-FUNCTION-INITIAL-METHODS CLOS generic function GENERIC-FUNCTION-LAMBDA-LIST CLOS generic function GENERIC-FUNCTION-METHOD-CLASS CLOS generic function GENERIC-FUNCTION-METHOD-COMBINATION CLOS generic function GENERIC-FUNCTION-METHODS CLOS generic function GENERIC-FUNCTION-NAME CLOS generic function METHOD-FUNCTION CLOS generic function METHOD-GENERIC-FUNCTION CLOS generic function METHOD-LAMBDA-LIST CLOS generic function METHOD-SLOT-NAME CLOS generic function METHOD-SPECIALIZERS CLOS generic function SLOT-BOUNDP-USING-CLASS CLOS generic function SLOT-DEFINITION class name SLOT-DEFINITION-ALLOCATION CLOS generic function SLOT-DEFINITION-INITARGS CLOS generic function SLOT-DEFINITION-INITFORM CLOS generic function SLOT-DEFINITION-INITFUNCTION CLOS generic function SLOT-DEFINITION-NAME CLOS generic function SLOT-DEFINITION-READERS CLOS generic function SLOT-DEFINITION-TYPE CLOS generic function SLOT-DEFINITION-WRITERS CLOS generic function SLOT-EXISTS-P-USING-CLASS CLOS generic function SLOT-MAKUNBOUND-USING-CLASS CLOS generic function SLOT-VALUE-USING-CLASS CLOS generic function, SETFable, LOCFable SPECIALIZER-DIRECT-GENERIC-FUNCTIONS CLOS generic function SPECIALIZER-DIRECT-METHODS CLOS generic function STANDARD-ACCESSOR-METHOD class name STANDARD-READER-METHOD class name STANDARD-SLOT-DEFINITION class name STANDARD-WRITER-METHOD class name Notes: The CLASS-xxx accessors always work, no explicit "finalize" is required. We're not sure whether this is a change from 89-003 or not. Using SETF with any of these names not indicated to be SETFable should signal an error. The following symbols are exported from the CLOS package by both Symbolics and Lucid, but are not being proposed for a standard at this time, for the reasons given: CLASS-DIRECT-METHODS use SPECIALIZER-DIRECT-METHODS CLASS-FINALIZED-P not needed for introspection COMPUTE-CLASS-PRECEDENCE-LIST use CLASS-PRECEDENCE-LIST SPECIALIZER-DIRECT-METHODS is more general than CLASS-DIRECT-METHODS. COMPUTE-CLASS-PRECEDENCE-LIST is needed for extension, where users define new methods for it to implement different CPL rules, but for introspection it is just a slower version of CLASS-PRECEDENCE-LIST. Lucid's CLOS package exports several additional symbols as well: LIST-ALL-CLASSES, TRACE-METHOD, UNDEFMETHOD, UNTRACE-METHOD. These are not being proposed for standardization right now. Symbolics' CLOS package exports several additional symbols as well: CLASS-DEFAULT-DIRECT-SUPERCLASSES, DIRECT-SLOT-DEFINITION, EFFECTIVE-SLOT-DEFINITION, STANDARD-DIRECT-CLASS-SLOT-DEFINITION, STANDARD-DIRECT-SLOT-DEFINITION, STANDARD-EFFECTIVE-SLOT-DEFINITION, STRUCTURE-DIRECT-SLOT-DEFINITION, STRUCTURE-EFFECTIVE-SLOT-DEFINITION, STRUCTURE-SLOT-DEFINITION. These are not being proposed for standardization right now. NON-ANSI-STANDARD SYMBOLS EXPORTED BY THE CLOS PACKAGE, ONLY IN COMMON LISP IMPLEMENTATIONS THAT HAVE LOCATIVES: SLOT-DEFINITION-LOCATORS CLOS generic function STANDARD-LOCATOR-METHOD class name Notes: These names are only meaningful in implementations that have the "locatives" extension, and would not exist in other implementations. They do not exist in Symbolics Cloe, nor in Lucid. Where a function is listed as "LOCFable", that attribute only applies in implementations that have the "locatives" extension. ANSI-STANDARD SYMBOLS EXPORTED BY THE CLOS PACKAGE: While we're at it, I might as well include this list of the symbols that Symbolics thinks are defined by the CLOS standard. These are all the symbols with pages in chapter 2 of 88-002R, plus other symbols that are mentioned in 88-002R with the apparent intention of being part of the standard, plus several symbols added by later X3J13 actions. Note that neither Symbolics or Lucid has implemented GENERIC-FLET, GENERIC-FUNCTION as a special form, GENERIC-LABELS, and WITH-ADDED-METHODS in their current implementations. Lucid also has not yet implemented DEFINE-METHOD-COMBINATION. The other missing global definitions are because the standard specifies only a local definition for those symbols. I think a careful reading will also show that the implementation from which this table was generated has not yet implemented a couple of specified condition types. Lucid exports all of the symbols listed here except for MAKE-LOAD-FORM and MAKE-LOAD-FORM-SAVING-SLOTS, which are not implemented yet. (A few others are only exported by a last-minute patch to the Lucid 4.0.0 Beta-1 version.) ADD-METHOD CLOS generic function ALLOCATE-INSTANCE CLOS generic function BUILT-IN-CLASS class name CALL-METHOD ***No global definition found*** CALL-NEXT-METHOD ***No global definition found*** CHANGE-CLASS CLOS generic function CLASS class name CLASS-NAME CLOS generic function, SETFable CLASS-OF function COMPUTE-APPLICABLE-METHODS CLOS generic function DEFCLASS macro DEFGENERIC macro DEFINE-METHOD-COMBINATION macro DEFMETHOD macro DESCRIBE-OBJECT CLOS generic function DOCUMENTATION CLOS generic function, SETFable ENSURE-GENERIC-FUNCTION function FIND-CLASS function, SETFable FIND-METHOD CLOS generic function FUNCTION-KEYWORDS CLOS generic function GENERIC-FLET ***No global definition found*** GENERIC-FUNCTION class name GENERIC-LABELS ***No global definition found*** INITIALIZE-INSTANCE CLOS generic function INVALID-METHOD-ERROR function MAKE-INSTANCE CLOS generic function MAKE-INSTANCES-OBSOLETE CLOS generic function MAKE-LOAD-FORM CLOS generic function MAKE-LOAD-FORM-SAVING-SLOTS function MAKE-METHOD ***No global definition found*** METHOD class name METHOD-COMBINATION class name, DOCUMENTATION type METHOD-COMBINATION-ERROR function METHOD-QUALIFIERS CLOS generic function NEXT-METHOD-P ***No global definition found*** NO-APPLICABLE-METHOD CLOS generic function NO-NEXT-METHOD CLOS generic function PRINT-OBJECT CLOS generic function REINITIALIZE-INSTANCE CLOS generic function REMOVE-METHOD CLOS generic function SETF macro, DOCUMENTATION type SHARED-INITIALIZE CLOS generic function SLOT-BOUNDP function SLOT-EXISTS-P function SLOT-MAKUNBOUND function SLOT-MISSING CLOS generic function SLOT-UNBOUND CLOS generic function SLOT-VALUE function, SETFable, LOCFable STANDARD CLOS method-combination STANDARD-CLASS class name STANDARD-GENERIC-FUNCTION class name STANDARD-METHOD class name STANDARD-OBJECT class name STRUCTURE-CLASS class name STRUCTURE-OBJECT class name SYMBOL-MACROLET special form UPDATE-INSTANCE-FOR-DIFFERENT-CLASS CLOS generic function UPDATE-INSTANCE-FOR-REDEFINED-CLASS CLOS generic function WITH-ACCESSORS macro WITH-ADDED-METHODS ***No global definition found*** WITH-SLOTS macro Notes: ALLOCATE-INSTANCE did not get its own page in 88-002R, but (some of) the authors of that document say that was simply a mistake. At this point there should probably be an X3J13 cleanup to clarify that ALLOCATE-INSTANCE is part of the language. Note that LOAD-OBJECTS:MAKE-LOAD-FORM assumes the existence of ALLOCATE-INSTANCE and that user-written MAKE-LOAD-FORM methods that return two values will typically use ALLOCATE-INSTANCE in the first value. The symbol ALLOCATE-INSTANCE is not exported from the CLOS package by Genera 8.0, but it is exported by Lucid. The lack of export in Genera is just a bug.   Received: from BBN.COM by LABS-N.BBN.COM id aa25871; 9 Jun 92 9:01 EDT Received: from [131.246.136.50] by BBN.COM id aa03741; 9 Jun 92 8:53 EDT Received: from mail.dfki.uni-kl.de by stepsun.uni-kl.de id aa18989; 9 Jun 92 14:46 MET DST Received: from arctecserv-1.dfki.uni-kl.de by mail.dfki.uni-kl.de id aa05260; 9 Jun 92 14:48 MET DST Date: Tue, 9 Jun 92 14:51:35 MET DST From: Bernd Bachmann To: clim@bbn.com cc: przy@dfki.uni-kl.de Subject: Patch-levels for CLIM on Symbolics Organization: German Research Center for AI (DFKI) Message-ID: <9206091451.aa03426@arctecserv-1.dfki.uni-kl.de> Does anybody know the patch-levels of CLIM 1.0 and 1.1 on the symbolics boards (also documentation!) ? - Bernd Bachmann   Received: from BBN.COM by LABS-N.BBN.COM id aa27483; 9 Jun 92 10:58 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa11115; 9 Jun 92 10:36 EDT Received: from DJINN.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1089469; 9 Jun 1992 10:37:03-0400 Date: Tue, 9 Jun 1992 10:37-0400 From: Scott McKay Subject: Patch-levels for CLIM on Symbolics To: bachmann@dfki.uni-kl.de, clim@BBN.COM cc: przy@dfki.uni-kl.de In-Reply-To: <9206091451.aa03426@arctecserv-1.dfki.uni-kl.de> Supersedes: <19920609143707.3.SWM@DJINN.SCRC.Symbolics.COM> Message-ID: <19920609143713.4.SWM@DJINN.SCRC.Symbolics.COM> From: Bernd Bachmann Does anybody know the patch-levels of CLIM 1.0 and 1.1 on the symbolics boards (also documentation!) ? CLIM 1.0 == CLIM 27.5 CLIM 1.1 == CLIM 28.5 I don't know what the documentation versions are, but I bet they're versions 30 and 31, respectively. Just out of curiosity, what prevented you from just looking at the patch directories yourself?   Received: from BBN.COM by LABS-N.BBN.COM id aa00952; 9 Jun 92 15:07 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa23936; 9 Jun 92 14:56 EDT Received: from DJINN.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1089468; 9 Jun 1992 10:36:56-0400 Date: Tue, 9 Jun 1992 10:37-0400 From: Scott McKay Subject: Patch-levels for CLIM on Symbolics To: bachmann@dfki.uni-kl.de, clim@BBN.COM cc: przy@dfki.uni-kl.de In-Reply-To: <9206091451.aa03426@arctecserv-1.dfki.uni-kl.de> Message-ID: <19920609143707.3.SWM@DJINN.SCRC.Symbolics.COM> From: Bernd Bachmann Does anybody know the patch-levels of CLIM 1.0 and 1.1 on the symbolics boards (also documentation!) ? CLIM 1.0 == CLIM 27.5 CLIM 1.1 == CLIM 28.5 I don't know what the documentation versions are, but I bet they're versions 30 and 31, respectively. Just ourt of curiosity, what prevented you from just looking at the patch directories yourself?   Received: from BBN.COM by LABS-N.BBN.COM id aa02379; 9 Jun 92 17:23 EDT Received: from MCC.COM by BBN.COM id aa03392; 9 Jun 92 17:19 EDT Received: from hippo by MCC.COM with TCP; Tue, 9 Jun 92 16:19:13 CDT Posted-Date: Tue, 9 Jun 1992 16:19-0500 Received: by hippo (5.57/ACTv4.1i) id AA19744; Tue, 9 Jun 92 16:19:10 -0500 Date: Tue, 9 Jun 1992 16:19-0500 From: Robert W. Kerns Subject: CLIM command-table bug To: clim@bbn.com Cc: rwk@crl.dec.com Message-Id: <19920609211900.4.RWK@MULESHOE.MCC.COM> Could someone please explain to me the logic of having keystrokes not be inherited by command tables?? It seems to me that this renders CLIM command tables completely useless if you care about inheritance, and you use keystrokes. How can it possibly be sane for the inheritance of keystrokes and other attributes to be different??? If keystrokes were inherited, and you wanted to use a different set of keystrokes in some situation, define the commands in one command table, the keystrokes in another, and use whichever you want, depending on whether or not you want the keystrokes. This is elementary object-oriented-programming modularity. No such modularity is possible if they follow different rules.   Received: from BBN.COM by LABS-N.BBN.COM id aa07972; 10 Jun 92 5:00 EDT Received: from unido.Germany.EU.net by BBN.COM id aa14160; 10 Jun 92 4:53 EDT Received: from sger by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA25241; Wed, 10 Jun 92 10:54:03 +0200 Received: from FUJI-SAN.SGER.UUCP ([192.1.2.67]) by sger.SGER.COM (4.1/SMI-4.1) id AA12705; Wed, 10 Jun 92 10:40:37 +0200 Date: Wed, 10 Jun 1992 11:47+0200 From: Markus Fischer Reply-To: mf@sger.uucp Subject: CLIM command-table bug To: clim@BBN.COM, rwk@crl.dec.com In-Reply-To: <19920609211900.4.RWK@MULESHOE.MCC.COM> Message-Id: <19920610094740.4.MF@FUJI-SAN.SGER.UUCP> Date: Tue, 9 Jun 1992 23:19+0200 From: "Robert W. Kerns" Could someone please explain to me the logic of having keystrokes not be inherited by command tables?? It seems to me that this renders CLIM command tables completely useless if you care about inheritance, and you use keystrokes. How can it possibly be sane for the inheritance of keystrokes and other attributes to be different??? If keystrokes were inherited, and you wanted to use a different set of keystrokes in some situation, define the commands in one command table, the keystrokes in another, and use whichever you want, depending on whether or not you want the keystrokes. This is elementary object-oriented-programming modularity. No such modularity is possible if they follow different rules. I don't know about keystrokes, because I don't use them, but I think menu items aren't inherited either, and I find that quite bad, too. Markus Fischer, MF@SGER.UUCP Mergenthaler Allee 77-81 Consulting Services W-6236 Eschborn, Germany Symbolics Systemhaus GmbH Phone: +49 6196 47220, Fax 481116   Received: from BBN.COM by LABS-N.BBN.COM id aa28627; 11 Jun 92 15:58 EDT Received: from eola.cs.ucf.edu by BBN.COM id aa23236; 11 Jun 92 15:53 EDT Received: by eola.cs.ucf.edu (5.61/1.34) id AA08891; Thu, 11 Jun 92 15:51:27 EDT Date: Thu, 11 Jun 92 15:51:27 EDT From: hull@eola.cs.ucf.edu (Richard Hull) Message-Id: <9206111951.AA08891@eola.cs.ucf.edu> To: clim@BBN.COM Subject: Duplicate Nodes in Graphs Thanks to the people who responded to my question about formatting graphs in CLIM version 1.0 (basically it was: get CLIM version 1.1 and use the :merge-duplicates keyword). But this still doesn't seem to work. The call I'm making looks like the following: (clim:format-graph-from-roots tree #'print-func #'(lambda( node ) (and (atom (first node)) (cdr node))) :merge-duplicates t :orientation ':vertical ) where tree is a list of the form ((a (b c d (e ...] and print-func is my function which uses clim:surrounding-output-with-border to display the node names in rectangles. For some reason the merge-duplicates keyword is not doing the job because I still have duplicate nodes. What is interesting is if I set the merge-duplicates keyword to NIL, I still get the duplicate nodes but they are farther apart, almost as if when :merge-duplicates is t it tries to merge them but can't quite make it. For example: :merge-duplicates t :merge-duplicates nil A A / \ / \ B C B C \ / | | D D D D Of course what I would like is: A / \ B C \ / D Do you have any ideas why this might be happening? Thanks. Richard Hull UCF AI Labs hull@cs.ucf.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa27540; 11 Jun 92 14:49 EDT Received: from fenrix.si.no by BBN.COM id aa17565; 11 Jun 92 14:36 EDT Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.23) id AA02377; Thu, 11 Jun 92 20:38:29 +0200 Date: Thu, 11 Jun 92 20:38:29 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9206111832.AAmonsun15572@D> To: clim@bbn.com Subject: presentation-replace-output & clim:*command-unparser* I'm using CLIM 1.0 and MCL 2.0b1p3 and have two questions. The first concerns presentation-replace-output. I have the following code: (clim:presentation-replace-input stream chosen-object type clim-view :buffer-start (1- (clim::input-position stream))) ; OBS! I'm using a undocumented clim function ^^^^^^^^^^^^^^^^^^^^ The function is documented to have a :buffer-start keyword which tells which part of the buffer to replace. The default is (clim::input-position stream), but I want to erase the last character, hence the use of 1-. The problem is that clim::input-position is undocumented, can I have the same effect using a documented function. It seems strange to document the keyword argument when there is no useful documented way of using it. The second question concerns unparsing commands. I read commands myself and want to echo them using the standard unparser: (funcall clim:*command-unparser* (clim:find-command-table (clim:frame-command-table frame)) stream command) However, I get an error: > Error: value NIL is not of the expected type CLIM::PRESENTATION-TYPE-SPECIFIER. > While executing: CLIM:EXPAND-PRESENTATION-TYPE-ABBREVIATION > Type Command-. to abort. See the RestartsI menu item for further choices. 1 > The backtrace reveals a call to clim:present that somehow gets nil as the type specifier. A have checked that the command given to the unparser is a legal command. Am I using the clim:*command-unparser* wrong? In case, what should I do? Bug? Where? Thanks for your attention, Hallvard Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.BBN.COM id aa28833; 11 Jun 92 16:13 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa24201; 11 Jun 92 16:08 EDT Received: from DJINN.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1091119; 11 Jun 1992 16:09:07-0400 Date: Thu, 11 Jun 1992 16:09-0400 From: Scott McKay Subject: presentation-replace-output & clim:*command-unparser* To: Hallvard.Tretteberg@si.no, clim@BBN.COM In-Reply-To: <9206111832.AAmonsun15572@D> Message-ID: <19920611200920.8.SWM@DJINN.SCRC.Symbolics.COM> Date: Thu, 11 Jun 1992 14:38 EDT From: Hallvard.Tretteberg@si.no I'm using CLIM 1.0 and MCL 2.0b1p3 and have two questions. The first concerns presentation-replace-output. I have the following code: (clim:presentation-replace-input stream chosen-object type clim-view :buffer-start (1- (clim::input-position stream))) ; OBS! I'm using a undocumented clim function ^^^^^^^^^^^^^^^^^^^^ The function is documented to have a :buffer-start keyword which tells which part of the buffer to replace. The default is (clim::input-position stream), but I want to erase the last character, hence the use of 1-. The problem is that clim::input-position is undocumented, can I have the same effect using a documented function. It seems strange to document the keyword argument when there is no useful documented way of using it. It's exported in CLIM II. The second question concerns unparsing commands. I read commands myself and want to echo them using the standard unparser: (funcall clim:*command-unparser* (clim:find-command-table (clim:frame-command-table frame)) stream command) However, I get an error: > Error: value NIL is not of the expected type CLIM::PRESENTATION-TYPE-SPECIFIER. > While executing: CLIM:EXPAND-PRESENTATION-TYPE-ABBREVIATION > Type Command-. to abort. See the RestartsI menu item for further choices. 1 > The backtrace reveals a call to clim:present that somehow gets nil as the type specifier. A have checked that the command given to the unparser is a legal command. Am I using the clim:*command-unparser* wrong? In case, what should I do? Bug? Where? Why not just use this: (present command `(command :command-table ,(frame-command-table frame)) :stream stream)   Received: from BBN.COM by LABS-N.BBN.COM id aa04482; 12 Jun 92 5:02 EDT Received: from unido.Germany.EU.net by BBN.COM id aa09056; 12 Jun 92 4:53 EDT Received: from sger by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA26616; Fri, 12 Jun 92 10:54:06 +0200 Received: from FUJI-SAN.SGER.UUCP ([192.1.2.67]) by sger.SGER.COM (4.1/SMI-4.1) id AA01482; Fri, 12 Jun 92 10:35:37 +0200 Date: Fri, 12 Jun 1992 11:42+0200 From: Markus Fischer Reply-To: mf@sger.uucp Subject: Duplicate Nodes in Graphs To: hull@eola.cs.ucf.edu, clim@BBN.COM In-Reply-To: <9206111951.AA08891@eola.cs.ucf.edu> Message-Id: <19920612094240.4.MF@FUJI-SAN.SGER.UUCP> Date: Thu, 11 Jun 1992 21:51+0200 From: Richard Hull Thanks to the people who responded to my question about formatting graphs in CLIM version 1.0 (basically it was: get CLIM version 1.1 and use the :merge-duplicates keyword). But this still doesn't seem to work. The call I'm making looks like the following: (clim:format-graph-from-roots tree #'print-func #'(lambda( node ) (and (atom (first node)) (cdr node))) :merge-duplicates t :orientation ':vertical ) where tree is a list of the form ((a (b c d (e ...] and print-func is my function which uses clim:surrounding-output-with-border to display the node names in rectangles. For some reason the merge-duplicates keyword is not doing the job because I still have duplicate nodes. What is interesting is if I set the merge-duplicates keyword to NIL, I still get the duplicate nodes but they are farther apart, almost as if when :merge-duplicates is t it tries to merge them but can't quite make it. For example: :merge-duplicates t :merge-duplicates nil A A / \ / \ B C B C \ / | | D D D D Of course what I would like is: A / \ B C \ / D Do you have any ideas why this might be happening? Thanks. First, I urge you to provide the mailing list with running examples when possible - like in this case. That makes it easier to reproduce the behavior you observed. However, I did not receive the behavior you described, instead the normal, two expected layouts. But maybe providing an appropriate :duplicates-test function could help (the default is #`EQL wich might be too strict in your case): (clim:format-graph-from-roots (list (cons 1 (list (cons 2 (list (cons 4 NIL))) (cons 3 (list (cons 4 NIL)))))) #'(lambda (node stream) (surrounding-output-with-border (stream) (print (car node) stream))) #'(lambda (node) (if (atom node) NIL (cdr node))) :stream *standard-output* :DUPLICATE-TEST #'EQUAL :merge-duplicates T :orientation :vertical) I observed two more odd/buggy things about clim:format-graph-from-roots you should consider in your work: 1) a blank character is added to any node - at least in my example 2) :cutoff-depth doesn't count the depth but instead the total number of nodes, which is of course incorrect in the general case Please note: All of my statements are valid for Symbolics CLIM 1.1 only. Markus Fischer, MF@SGER.UUCP Mergenthaler Allee 77-81 Consulting Services W-6236 Eschborn, Germany Symbolics Systemhaus GmbH Phone: +49 6196 47220, Fax 481116   Received: from BBN.COM by LABS-N.BBN.COM id aa09975; 12 Jun 92 14:09 EDT Received: from barracuda.arc.nasa.gov by BBN.COM id aa28073; 12 Jun 92 13:58 EDT Received: from SEASLUG.arc.nasa.gov by BARRACUDA.arc.nasa.gov via INTERNET with SMTP id 130809; 12 Jun 1992 10:15:28-0700 Date: Fri, 12 Jun 1992 10:15-0700 From: Subject: changing layouts To: chris@starbase.mitre.org, clim@BBN.COM In-Reply-To: <9206051519.AA28457@starbase.mitre.org> Message-ID: <19920612171523.5.LISP-MACHINE@SEASLUG.arc.nasa.gov> Date: Fri, 5 Jun 1992 08:19 PDT From: Chris Elsaesser Dear CLIM, In Genera 8.1 CLIM 1.0, every time I do a (clim::set-frame-layout ) from a command (e.g, com-foo), everything that follows the call to clim::set-frame-layout is ignored. What am I doing wrong? chris This came up before and Scott McKay gave a workaround (his message is included below). I've used his first workaround with success. I have not tried his second. David Bushnell bushnell@eos.arc.nasa.gov >From: Scott McKay >Newsgroups: ri.clim >Message-ID: <19346@ptolemy-arclan.ptolemy-ri.arc.nasa.gov> In article <19346@ptolemy-arclan.ptolemy-ri.arc.nasa.gov> Scott McKay writes: > > Date: Mon, 25 Nov 1991 10:51 EST > From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) > > I am on a SPARC in Allegro w/ CLIM 1.0. I have an application frame > with two layouts (Normal, and Editor). I have been doing some > experimentation with swapping layouts in an application via an > application command. The first problem I have notice is that if you > have a command like. > > The implementation for changing frame layouts in CLIM 1.0 is badly > designed. The issue is that, after the layout of a frame is changed, > CLIM needs to recompute the values for the standard stream bindings > (*STANDARD-INPUT*, *QUERY-IO*, etc.) When you call SET-FRAME-LAYOUT, > CLIM throws to the tag CLIM::RESYNCHRONIZE in order to recompute these > values. There are two workarounds: > (1) If you know that none of the standard stream bindings will change > or don't care, you can do this: > (CATCH 'CLIM::RESYNCHRONIZE > (SET-FRAME-LAYOUT )) > (2) Alternatively, you can try installing the following kludge fix to > SET-FRAME-LAYOUT, until I figure out a better fix: > > (in-package :clim) > (defmethod set-frame-layout ((frame application-frame) new-layout) > (setq *frame-layout-changing-p* t) > (with-slots (current-panes initialized-panes) frame > (setf (frame-current-layout frame) new-layout) > (layout-frame-panes frame (frame-top-level-window frame)) > ;; Forcibly display any panes that have not been displayed yet > (dolist (pane current-panes) > (unless (member pane initialized-panes) > ;; Display the pane and mark it initialized > (redisplay-frame-pane frame pane :force-p t)))) > (unless (eq *application-frame* *default-application*) > (setq *standard-output* (or (frame-standard-output frame) *standard-output*) > *query-io* (or (frame-query-io frame) *query-io*) > *standard-input* (or interactor *standard-output*) > *error-output* (or (frame-error-output frame) *error-output*)))) > > (define-my-application-command (swap-them-back-and-forth :name t) () > (set-frame-layout 'Different-Layout) > (sleep 10) ;plenty of time to swap them panes around! > (set-frame-layout 'Original-Layout)) > > The command will only do the first set-frame-layout. My interactor pane > that is included with both layouts is still active though. So if I use > a different command that just does (set-frame-layout 'Original-Layout), > I can get back to my original layout. Why can't I swap more than one > layout within the same command?????? > > The second problem I am having is that within the same application > command, when I swap layouts I cannot do output to the newly exposed > pane of my new layout (even with force-output). However, If I put the > same code in a different command and then invoke it after invoking the > command that swaps the layouts , the output will appear on the newly > exposed frame. Why can't I output within the same command when I swap > layouts? > > In my case I am trying to setup up a single command in which the person > invokes a multi-page editor on a presentation object that is in a > timeline like display. I would like to do this in a single step. But > right now the only way to get it to work is invoking three commands > (when I should be able to do it with only one)! Is there something > trivial that I am missing? > > Yes, but the trivial thing is not documented.   Date: Mon, 15 Jun 92 7:05:43 EDT From: Nichael Cramer To: clim@bbn.com cc: nichael@BBN Subject: Accept + Mouse-Actions?? [Working in: CLIM-1.1/Lucid/Sun] The problem: I would like to be in a state that allowed me to do either of the following simultaneously: 1] Accept a value (e.g. a number), or 2] Execute a frame command (specifically through a mouse action). In a little more detail, the standard state of the system should be that it is waiting for the user to enter a value of a specified --but arbitrary-- type (say, a number). However, at the same time the user should be able to click on one of some set of other objects (e.g. of type MY-PRESTYPE, which are _not_ of type number) and get the standard mouse actions associated with that type. The following gets me _some_ of what I want: (with-input-context ('MY-PRESTYPE :stream INPUT-STREAM) (OBJECT PRESTYPE GESTURE) (progn (setq NEW-VALUE (accept PRESTYPE :stream INPUT-STREAM)) (new-cell-value SELF NEW-VALUE)) (MY-PRESTYPE (handle-cell-click SELF OBJECT GESTURE))) However, the problem here is that all I really get is the information that a mouse-click has occured (on OBJECT). Moveover, only a left-click works, so I am limited to only one type of click (actually, mouse-right works also, but it just gets a menu with the single item in it). Also, no useful documentation-line information, etc. etc. BTW, inverting the above is also interesting (assuming that appropriate commands have been defined on MY-PRESTYPE): (with-input-context ('number :stream INPUT-STREAM) (OBJECT PRESTYPE GESTURE) (progn (setq COMMAND (clim::read-frame-command FRAME :stream INPUT-STREAM)) : ) (number (handle-new-value SELF OBJECT GESTURE))) In this case I can get mouse-actions, of course (because I am handling them myself) however I can only get numbers by clicking on them (i.e. no typing). So, my questions are: - Is there some more general way of doing this that allows the full mouse-actions while doing an accept? - If not, is there some way I can get more than one type of mouse-click to activate inside the WITH-INPUT-CONTEXT? Thanks Nichael   Date: Mon, 15 Jun 92 6:53:56 EDT From: Nichael Cramer To: clim@bbn.com cc: nichael@BBN Subject: Scroll-Bar on Right? [Working in: CLIM-1.0/Lucid/Sun] Is there some way to specify that a vertical scroll-bar be on the right? E.g. something like: (define-application-frame table-editor-frame () ((OUTPUT-PANE :accessor output-pane) : ) (:panes ((OUTPUT-PANE :application :scroll-bars (:vertical (:horizontal :right)) ) ... (Hoping this isn't a FAQ.) Thanks Nichael   Received: from BBN.COM by LABS-N.BBN.COM id aa06563; 15 Jun 92 12:00 EDT Received: from mail.Germany.EU.net by BBN.COM id aa28154; 15 Jun 92 11:55 EDT Received: from sger by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA18810; Mon, 15 Jun 92 17:54:08 +0200 Received: from FUJI-SAN.SGER.UUCP ([192.1.2.67]) by sger.SGER.COM (4.1/SMI-4.1) id AA03345; Mon, 15 Jun 92 17:33:22 +0200 Date: Mon, 15 Jun 1992 18:40+0200 From: Markus Fischer Reply-To: mf@sger.uucp Subject: Menu-choose, Scrolling To: hull@eola.cs.ucf.edu Cc: clim@bbn.com In-Reply-To: <9206122111.AA15355@eola.cs.ucf.edu> Message-Id: <19920615164031.5.MF@FUJI-SAN.SGER.UUCP> Date: Fri, 12 Jun 1992 23:11+0200 From: unido!eola.cs.ucf.edu!hull (Richard Hull) Markus, Thanks for the tip about using the :duplicate-test keyword. It worked with :duplicate-test #'equal. Why isn't there any documentation about this change? In the update I received from Symbolics I saw nothing about format-graph-from-roots. I did try :merge-duplicates #'equal but of course that didn't work. I have a couple of other problems taht I can't seem to figure out: (1) for some reason scrolling a graph produced by format-graph-from-roots in a pane seems to "chew up" the graph. When the pane is scrolled the graph loses several rows and columns of pixels when the pane is scrolled vertically or horizontally. Sometimes an entire character of the node name disappears. Any ideas? That bothered me too, so I looked up the bug. I mailed Scott McKay of Symbolics, Inc. the fix, it might be part of the next CLIM release. (2) Why are menus created with menu-choose given a vertical scroll bar? Is there any way to remove it (in the cases where I know there won't be more than say 5 items on the menu)? CLIM:MENU-CHOOSE uses a resource MENU, and those objects are all of the same kind, i.e. include always scroll-bars. You'll have to use CLIM:MENU-CHOOSE-FROM-DRAWER, which takes a window to draw the menu on. Markus Fischer, MF@SGER.UUCP Mergenthaler Allee 77-81 Consulting Services W-6236 Eschborn, Germany Symbolics Systemhaus GmbH Phone: +49 6196 47220, Fax 481116   Received: from BBN.COM by LABS-N.BBN.COM id aa07792; 15 Jun 92 13:48 EDT Received: from lucid.com by BBN.COM id aa02913; 15 Jun 92 13:36 EDT Received: from kuwait.lucid ([192.31.212.118]) by heavens-gate.lucid.com id AA04750g; Mon, 15 Jun 92 10:27:54 PDT Received: by kuwait.lucid (4.1/SMI-4.1) id AA04240; Mon, 15 Jun 92 10:36:23 PDT Date: Mon, 15 Jun 92 10:36:23 PDT From: kern%kuwait@lucid.com (John Kern) Message-Id: <9206151736.AA04240@kuwait.lucid> To: ncramer@BBN.COM Cc: clim@BBN.COM, nichael@BBN.COM In-Reply-To: Nichael Cramer's message of Mon, 15 Jun 92 6:53:56 EDT <9206151115.AA03917@lucid.com> Subject: Scroll-Bar on Right? Reply-To: kern@lucid.com Howdy Mr. Cramer, > Is there some way to specify that a vertical scroll-bar be on the right? Lucid CLIM 1.1 doesn't provide this functionality. I have reported this as a request for additional functionality. Sincerely, John S. Kern Lucid, Inc. Customer Support   Received: from BBN.COM by LABS-N.BBN.COM id aa05185; 17 Jun 92 12:05 EDT Received: from lucid.com by BBN.COM id aa02883; 17 Jun 92 11:50 EDT Received: from kuwait.lucid ([192.31.212.118]) by heavens-gate.lucid.com id AA10946g; Wed, 17 Jun 92 08:41:41 PDT Received: by kuwait.lucid (4.1/SMI-4.1) id AA06274; Wed, 17 Jun 92 08:50:13 PDT Date: Wed, 17 Jun 92 08:50:13 PDT From: kern%kuwait@lucid.com (John Kern) Message-Id: <9206171550.AA06274@kuwait.lucid> To: ncramer@BBN.COM Cc: clim@BBN.COM In-Reply-To: Nichael Cramer's message of Mon, 15 Jun 92 7:05:43 EDT <9206151148.AA03947@lucid.com> Subject: Accept + Mouse-Actions?? Reply-To: kern@lucid.com Howdy Mr. Cramer, Try specializing read-frame-command. There is an example of this in the puzzle.lisp file of the demo subdirectory. (defmethod read-frame-command ((puzzle puzzle) &key (stream *query-io*)) (let ((abort-chars #+Genera '(#\Abort #\End) #-Genera nil)) (let ((command (read-command-using-keystrokes (frame-command-table puzzle) abort-chars :stream stream))) (if (characterp command) (frame-exit puzzle) command)))) In this case, if a character is received the application is terminated. Commands are just returned. Sincerely, John S. Kern Lucid, Inc. Customer Support   Received: from BBN.COM by LABS-N.BBN.COM id aa08590; 17 Jun 92 16:20 EDT Received: from ptolemy-arclan.arc.nasa.gov by BBN.COM id aa17199; 17 Jun 92 16:05 EDT Received: from jung (jung.arc.nasa.gov) by ptolemy.arc.nasa.gov (4.1/) id ; Wed, 17 Jun 92 13:03:49 PDT Date: Wed, 17 Jun 92 13:03:49 PDT From: Philip Chu-Summer 92 Message-Id: <9206172003.AA12847@ptolemy.arc.nasa.gov> Received: by jung (4.1/SMI-4.1) id AA15871; Wed, 17 Jun 92 13:05:06 PDT To: clim@bbn.com Subject: archive or FAQ list Is there an ftp'able archive of this group or an FAQ list? Phil Chu Artificial Intelligence Research Branch NASA Ames Research Center pchu@ptolemy.arc.nasa.gov   Received: from BBN.COM by LABS-N.BBN.COM id aa09805; 17 Jun 92 17:57 EDT Received: from ptolemy-arclan.arc.nasa.gov by BBN.COM id aa22922; 17 Jun 92 17:50 EDT Received: from seldon.arc.nasa.gov by ptolemy.arc.nasa.gov (4.1/) id ; Wed, 17 Jun 92 14:48:31 PDT Received: by seldon.arc.nasa.gov (4.1/SMI-4.1) id AA01130; Tue, 16 Jun 92 12:47:49 PDT Date: Tue, 16 Jun 92 12:47:49 PDT From: swanson@seldon.arc.nasa.gov (Keith J. Swanson) Message-Id: <9206161947.AA01130@seldon.arc.nasa.gov> To: clim@bbn.com Subject: run commands from outside command loop? Greetings, (Using SPARCstation 2, Franz 4.1, clim 1.1) I'm developing an application where I have different clim applications running as separate processes in the same lisp. Is there some programmatic way for one clim app (or more generally, any code in another process) to cause a command to be executed in a different clim app? The docs (page 224) say clim supports four main styles of interaction. (I assume this means with the default top level loop.) Programmatic calls from outside the frame command loop doesn't seem to be one of them. Is there any easy way to get this behavior? For example, suppose I have a clim app running as a separate process. (The clim process is just waiting (oh so expectantly) to be interacted with.) Could I type a form to the lisp listener (a separate process) and cause the clim app to run one of its commands? I tried several forms of clim:execute-frame-command with no success. Can something like execute-frame-command work from another process or is it necessary to modify the top level loop of the receiving clim app? Any comments greatly appreciated. keith   Received: from BBN.COM by LABS-N.BBN.COM id aa19876; 18 Jun 92 12:15 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa17796; 18 Jun 92 12:05 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1094823; 18 Jun 1992 11:28:32-0400 Date: Thu, 18 Jun 1992 11:28-0400 From: Scott McKay Subject: run commands from outside command loop? To: swanson@seldon.arc.nasa.gov, clim@BBN.COM In-Reply-To: <9206161947.AA01130@seldon.arc.nasa.gov> Message-ID: <19920618152806.1.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 16 Jun 1992 15:47 EDT From: "Keith J. Swanson" (Using SPARCstation 2, Franz 4.1, clim 1.1) I'm developing an application where I have different clim applications running as separate processes in the same lisp. Is there some programmatic way for one clim app (or more generally, any code in another process) to cause a command to be executed in a different clim app? The docs (page 224) say clim supports four main styles of interaction. (I assume this means with the default top level loop.) Programmatic calls from outside the frame command loop doesn't seem to be one of them. Is there any easy way to get this behavior? For example, suppose I have a clim app running as a separate process. (The clim process is just waiting (oh so expectantly) to be interacted with.) Could I type a form to the lisp listener (a separate process) and cause the clim app to run one of its commands? I tried several forms of clim:execute-frame-command with no success. Can something like execute-frame-command work from another process or is it necessary to modify the top level loop of the receiving clim app? There are two choices right now: (1) Modify the top-level loop of the receiving CLIM application to look at some sort of "mail box". (2) Find the input buffer for the receiving CLIM application and insert an "accept result" into the input buffer. (An interested hacker with CLIM sources could consult clim/interactive-protocol.lisp to figure out how to do this.) Some of us have discussed adding some sort of support for this in CLIM II.   Received: from BBN.COM by LABS-N.BBN.COM id aa21283; 18 Jun 92 14:16 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa22862; 18 Jun 92 14:09 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1094925; 18 Jun 1992 14:12:16-0400 Date: Thu, 18 Jun 1992 14:11-0400 From: Scott McKay Subject: run commands from outside command loop? To: SWM@STONY-BROOK.SCRC.Symbolics.COM, swanson@seldon.arc.nasa.gov, clim@BBN.COM In-Reply-To: <19920618152806.1.SWM@SUMMER.SCRC.Symbolics.COM> Message-ID: <19920618181135.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 18 Jun 1992 11:28 EDT From: Scott McKay Date: Tue, 16 Jun 1992 15:47 EDT From: "Keith J. Swanson" Is there some programmatic way for one clim app (or more generally, any code in another process) to cause a command to be executed in a different clim app? There are two choices right now: (1) Modify the top-level loop of the receiving CLIM application to look at some sort of "mail box". (2) Find the input buffer for the receiving CLIM application and insert an "accept result" into the input buffer. (An interested hacker with CLIM sources could consult clim/interactive-protocol.lisp to figure out how to do this.) Some of us have discussed adding some sort of support for this in CLIM II. Chris Richardson tells me he has implemented (2), so I guess that means this will be part of CLIM II.   Received: from BBN.COM by LABS-N.BBN.COM id aa23429; 18 Jun 92 16:43 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa02453; 18 Jun 92 16:36 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA21111; Thu, 18 Jun 92 13:35:56 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA00307; Thu, 18 Jun 92 13:28:57 PDT Date: Thu, 18 Jun 92 13:28:57 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9206182028.AA00307@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: How to question? I read in the docs (no examples .. sigh) about read-command and execute- frame-command, but I don't think they will do what I want. How do you re-execute a command from only its command presentation object without using the mouse? ie: I already have my command presentation translators (mouse click invokation), but I want to manually reinvoke the command w/ its old arguments thru my own accept call rather than the application's command loop. Any examples would be mucho appreciated ...   Received: from BBN.COM by LABS-N.BBN.COM id aa24047; 18 Jun 92 17:45 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa05093; 18 Jun 92 17:40 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1095123; 18 Jun 1992 17:42:58-0400 Date: Thu, 18 Jun 1992 17:42-0400 From: Scott McKay Subject: How to question? To: curt@eraserhead.jpl.nasa.gov, clim@BBN.COM In-Reply-To: <9206182028.AA00307@eraserhead.Jpl.Nasa.Gov> Message-ID: <19920618214251.1.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 18 Jun 1992 16:28 EDT From: Curt Eggemeyer I read in the docs (no examples .. sigh) about read-command and execute- frame-command, but I don't think they will do what I want. How do you re-execute a command from only its command presentation object without using the mouse? ie: I already have my command presentation translators (mouse click invokation), but I want to manually reinvoke the command w/ its old arguments thru my own accept call rather than the application's command loop. Any examples would be mucho appreciated ... I suppose you could programmatically yank the last command from the command presentation history, and then execute that. The following form will re-execute the last command executed in an application: (execute-frame-command (clim::history-top-element (presentation-type-history 'command)))   Received: from BBN.COM by LABS-N.BBN.COM id aa24855; 18 Jun 92 19:05 EDT Received: from ptolemy-arclan.arc.nasa.gov by BBN.COM id aa07013; 18 Jun 92 19:01 EDT Received: from jung (jung.arc.nasa.gov) by ptolemy.arc.nasa.gov (4.1/) id ; Thu, 18 Jun 92 15:59:51 PDT Date: Thu, 18 Jun 92 15:59:51 PDT From: Philip Chu-Summer 92 Message-Id: <9206182259.AA19985@ptolemy.arc.nasa.gov> Received: by jung (4.1/SMI-4.1) id AA16568; Thu, 18 Jun 92 16:01:12 PDT To: clim@bbn.com Subject: incremental display with format-graph-from-roots Can anyone give me some tips on how one would use incremental redisplay with clim::format-graph-from-roots? Specifically, I want to efficiently display a steadily-growing DAG. Also, is there a way to control the line style used between nodes by clim::format-graph-from-roots? Thanks in advance. Phil Chu Artificial Intelligence Research Branch NASA Ames Research Center pchu@ptolemy.arc.nasa.gov   Received: from BBN.COM by LABS-N.bbn.COM id aa02946; 22 Jun 92 14:32 EDT Received: from fenrix.si.no by BBN.COM id aa21518; 22 Jun 92 14:21 EDT Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.23) id AA07544; Mon, 22 Jun 92 20:24:28 +0200 Date: Mon, 22 Jun 92 20:24:28 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9206221817.AAmonsun17438@D> To: clim@bbn.com Subject: tracking-pointer I'm using CLIM 1.0 and MCL 2.0, both beta. I've discovered a problem with clim:tracking-pointer. I track the pointer and highlight the presentations it passes over, taking care only highlighting when the pointer enters the presentation, and dehighlighting when it exits. The problem is that the exiting motion, it counts as a presentation movement, so the pointer actually is outside the presentation after the motion. In my case this means that the presentation is still highlighted after the pointer has just exited, giving the user false feedback. It also seems to be a disagreement between the :presentation clause and the :pointer-button-press clause as to when the pointer is on a presentation. When moving entering presentation and pressing the button, I get a pointer-button-press event and not a presentation-button-press event. I've been debugging my code for quite a while and am quite sure that something must be wrong with tracking-pointer. If it's needed I will try to make some code that demonstrates the problem, so others may verify the problem. Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.BBN.COM id aa04262; 22 Jun 92 16:14 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa28461; 22 Jun 92 16:09 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1096699; 22 Jun 1992 16:11:43-0400 Date: Mon, 22 Jun 1992 16:11-0400 From: Scott McKay Subject: tracking-pointer To: Hallvard.Tretteberg@si.no, clim@BBN.COM In-Reply-To: <9206221817.AAmonsun17438@D> Message-ID: <19920622201149.1.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 22 Jun 1992 14:24 EDT From: Hallvard.Tretteberg@si.no I'm using CLIM 1.0 and MCL 2.0, both beta. I've discovered a problem with clim:tracking-pointer. I track the pointer and highlight the presentations it passes over, taking care only highlighting when the pointer enters the presentation, and dehighlighting when it exits. The problem is that the exiting motion, it counts as a presentation movement, so the pointer actually is outside the presentation after the motion. In my case this means that the presentation is still highlighted after the pointer has just exited, giving the user false feedback. It also seems to be a disagreement between the :presentation clause and the :pointer-button-press clause as to when the pointer is on a presentation. When moving entering presentation and pressing the button, I get a pointer-button-press event and not a presentation-button-press event. I've been debugging my code for quite a while and am quite sure that something must be wrong with tracking-pointer. If it's needed I will try to make some code that demonstrates the problem, so others may verify the problem. Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no The CLIM 1.1 version of TRACKING-POINTER will manage highlighting for you, and does not have any of these problems.   Received: from BBN.COM by LABS-N.BBN.COM id aa10512; 23 Jun 92 5:31 EDT Received: from fenrix.si.no by BBN.COM id aa14838; 23 Jun 92 5:26 EDT Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.23) id AA14625; Tue, 23 Jun 92 11:29:17 +0200 Date: Tue, 23 Jun 92 11:29:17 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9206230922.AAmonsun17590@D> To: clim@bbn.com Subject: still tracking-pointer Yes, I'm still using CLIM 1.0, MCL 2.0, both beta. And yes, I'm still working with tracking-pointer. When I press one of the modifier keys, the :presentation and :presentation-button-press clauses are never run. I would like to do different things according to the shift mask in the event object, but I don't get any events, so what am I to do? Isn't CLIM big and ugly and full of bugs? I like it, though...;-) Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.BBN.COM id aa13274; 23 Jun 92 10:42 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa10233; 23 Jun 92 10:29 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1097143; 23 Jun 1992 10:31:13-0400 Date: Tue, 23 Jun 1992 10:31-0400 From: Scott McKay Subject: still tracking-pointer To: Hallvard.Tretteberg@si.no, clim@BBN.COM In-Reply-To: <9206230922.AAmonsun17590@D> Message-ID: <19920623143126.0.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 23 Jun 1992 05:29 EDT From: Hallvard.Tretteberg@si.no Yes, I'm still using CLIM 1.0, MCL 2.0, both beta. And yes, I'm still working with tracking-pointer. When I press one of the modifier keys, the :presentation and :presentation-button-press clauses are never run. I would like to do different things according to the shift mask in the event object, but I don't get any events, so what am I to do? As I said in my previous message, TRACKING-POINTER has had some bugs fixed in it, and this stuff works in CLIM 1.1. So, the best thing you can do is to find out what you can do to support ILA in producing CLIM 1.1 for MCL. Isn't CLIM big and ugly and full of bugs? I like it, though...;-) At least 150 bugs were fixed in CLIM 1.0 to produce CLIM 1.1. Given the size of the product and the fact that it is a first release, that number is actually quite respectable (only about 1 bug for every 350 lines of code). Unfortunately, I think that says more about the poor state of software in general than about the "good" quality of CLIM.   Received: from BBN.COM by LABS-N.BBN.COM id aa14867; 23 Jun 92 13:11 EDT Received: from PDESDS1.ATG.TRC.SCRA.ORG by BBN.COM id aa17854; 23 Jun 92 13:07 EDT Received: by pdesds1.atg.trc.scra.org (5.57/Ultrix3.0-C) id AA14784; Tue, 23 Jun 92 13:07:05 -0400 Date: Tue, 23 Jun 1992 13:06-0400 From: Craig Lanning Subject: format-graph-from-roots To: clim@bbn.com Message-Id: <19920623170650.3.CLANNING@PWA.AMRC-PWA.TRC.SCRA.ORG> I am using a Symbolics 3620 with Genera 8.1 and CLIM 1.1 (28.5). If I use CLIM:FORMAT-GRAPH-FROM-ROOTS and specify :MERGE-DUPLICATES T, some parts of the graph have the children in the same generation column as their parent. This makes the resulting graph difficult to follow (especially when there are several hundred nodes). Is there some way to get those children into the proper generation column? (Note: this behavior is also exhibited in the :VERTICAL orientation.) To see what I mean: 1. Compile and load the following code 2. Type (show-test) in a CLIM Listener 3. Look at ITEM-4 and ITEM-8 in the two resulting graphs. ------------------------------ Start of File ------------------------------ ;;; -*- Mode: LISP; Syntax: ANSI-Common-Lisp; Package: FCL-USER; Base: 10 -*- (in-package :FCL-USER) (defvar *ITEMS* nil) (defvar *ROOTS* nil) (defclass ITEM () ((name :accessor item-name :initarg :name) (children :accessor item-children :initform nil))) (defmethod PRINT-OBJECT ((item Item) stream) (with-slots (name children) item (if *print-escape* (print-unreadable-object (item stream :type t :identity t) (format stream "~D~@[ with ~D children~]" name (and children (length children)))) (format stream "ITEM-~D" name)))) (defun FIND-ITEM (name) (find name *items* :key #'item-name)) (defun SET-CHILDREN (parent &rest children) (let ((item (find-item parent)) (kids (loop for child in children collect (find-item child)))) (setf (item-children item) kids) item)) (defun INIT-ITEMS () (setf *items* (loop for i from 1 to 20 collect (make-instance 'item :name i))) (setf *roots* (loop for i in '(1 19 20) collect (find-item i))) (set-children 1 2) (set-children 2 4 3 7) (set-children 3 4 5 6 7) (set-children 4 8) (set-children 5 9 10) (set-children 6 11 12 13 14 15 16 17) *roots*) (defun FORMAT-ROOTS (&optional depth merge? &key (stream *standard-output*)) (clim:format-graph-from-roots *roots* #'princ #'item-children :graph-type :digraph ;;:orientation :vertical :stream stream :merge-duplicates merge? :cutoff-depth depth)) (defun SHOW-TEST (&optional (stream *standard-output*)) (init-items) (format stream "~%FORMAT-GRAPH-FROM-ROOTS :cutoff-depth nil :merge-duplicates t~%") (format-roots nil t :stream stream) (format stream "~2%FORMAT-GRAPH-FROM-ROOTS :cutoff-depth 4 :merge-duplicates t~%") (format-roots 4 t :stream stream) (values))   Received: from BBN.COM by LABS-N.BBN.COM id aa25419; 24 Jun 92 9:07 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa19743; 24 Jun 92 9:00 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA15730; Wed, 24 Jun 92 06:00:10 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA00329; Wed, 24 Jun 92 05:53:07 PDT Date: Wed, 24 Jun 92 05:53:07 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9206241253.AA00329@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: simple-parse-error query - maybe potential problem? In CLIM 1.1, I noticed the following problem with accept's handling of simple-parse-error and I think it may be an oversight in the CLIM specs, or maybe its a problem only in Allegro. In my own case I have complex time types that allow optional type-tags to the time values. I utilized simple-parse-error in my accept method to inform the user of various illegalities of the way they had input the time values. The simple-parse-error forms work as expected in normal accept invokation, however if you use accept-from-string and you hit the simple-parse-error form in your accept (you will hit the debugger - at least in Allegro Lispm). My question is this. I need to be able to utilize that parse-error checking capability within accept-from-string (particular case is file stream reads w/ read-line), is there a way to write an accept method that will work with simple-parse-error for both accept, and accept-from-string? Accept-from-string seems to need additional arguments in which the user can direct parse-error interaction with the user if need be? Any suggestions from the CLIM gurus out there?   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa27110; 24 Jun 92 11:19 EDT Received: by KARIBA.BBN.COM id aa08398; 24 Jun 92 9:57 EDT To: Curt Eggemeyer cc: clim@BBN.COM, jmorrill@BBN.COM Subject: Re: simple-parse-error query - maybe potential problem? In-reply-to: Curt Eggemeyer's message of Wed, 24 Jun 92 05:53:07 -0700. <9206241253.AA00329@eraserhead.Jpl.Nasa.Gov> Reply-To: jmorrill@BBN.COM Date: Wed, 24 Jun 92 09:56:05 -0400 Message-ID: <1550.709394165@bbn.com> From: Jeff Morrill Sounds like you need error handlers in your presentation-type parsers. Or if you are using them, maybe you aren't doing it right? A simple example might help. I do some fairly fancy parsers involving error handling, and it works just fine regardless of whether the input stream is interactive or a string-input-stream.   Received: from BBN.COM by LABS-N.BBN.COM id aa26768; 24 Jun 92 10:53 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa26170; 24 Jun 92 10:48 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1097769; 24 Jun 1992 10:50:08-0400 Date: Wed, 24 Jun 1992 10:50-0400 From: Scott McKay Subject: simple-parse-error query - maybe potential problem? To: curt@eraserhead.jpl.nasa.gov cc: clim@BBN.COM In-Reply-To: <9206241253.AA00329@eraserhead.Jpl.Nasa.Gov> Message-ID: <19920624145026.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 24 Jun 1992 08:53 EDT From: Curt Eggemeyer In CLIM 1.1, I noticed the following problem with ACCEPT's handling of SIMPLE-PARSE-ERROR and I think it may be an oversight in the CLIM specs, or maybe its a problem only in Allegro. In my own case I have complex time types that allow optional type-tags to the time values. I utilized SIMPLE-PARSE-ERROR in my ACCEPT method to inform the user of various illegalities of the way they had input the time values. The SIMPLE-PARSE-ERROR forms work as expected in normal accept invokation, however if you use ACCEPT-FROM-STRING and you hit the SIMPLE-PARSE-ERROR form in your ACCEPT, you will hit the debugger (at least in Allegro Lisp). My question is this. I need to be able to utilize that PARSE-ERROR checking capability within ACCEPT-FROM-STRING (particular case is file stream reads w/ READ-LINE), is there a way to write an accept method that will work with SIMPLE-PARSE-ERROR for both ACCEPT and ACCEPT-FROM-STRING? ACCEPT-FROM-STRING seems to need additional arguments in which the user can direct PARSE-ERROR interaction with the user if need be? Any suggestions from the CLIM gurus out there? Please send me the code for the presentation type.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa27433; 24 Jun 92 11:52 EDT Received: by KARIBA.BBN.COM id aa08674; 24 Jun 92 11:41 EDT To: Curt Eggemeyer cc: clim@BBN.COM, jmorrill@BBN.COM Subject: Re: Tiny example of simple-parse-error query problem? In-reply-to: Curt Eggemeyer's message of Wed, 24 Jun 92 08:08:59 -0700. <9206241508.AA00452@eraserhead.Jpl.Nasa.Gov> Reply-To: jmorrill@BBN.COM Date: Wed, 24 Jun 92 11:40:49 -0400 Message-ID: <1596.709400449@bbn.com> From: Jeff Morrill Date: Wed, 24 Jun 92 08:08:59 PDT From: Curt Eggemeyer To: SWM@stony-brook.scrc.symbolics.com Subject: Tiny example of simple-parse-error query problem? Cc: cl-bugs@franz.com, jmorrill@BBN.COM (define-command (com-test-that-doesn't-work :command-table your-command-table :name t) () (accept-from-string 'my-odd-one "4")) If CLIM won't handle it, you can do it yourself: (define-command (com-test-that-does-work :command-table your-command-table :name t) () (handler-case (accept-from-string 'my-odd-one "4") (simple-parse-error (condition) (format t "~%Oops, you goofed.") (let ((*print-escape* nil)) (print condition)))))   Received: from BBN.COM by LABS-N.BBN.COM id aa02369; 24 Jun 92 18:30 EDT Received: from aristotle.ils.nwu.edu by BBN.COM id aa20495; 24 Jun 92 18:25 EDT Received: by aristotle.ils.nwu.edu (4.1/SMI-ILS-1.05) id AA27206; Wed, 24 Jun 92 17:12:24 CDT Date: Wed, 24 Jun 92 17:12:24 CDT From: siegle@aristotle.ils.nwu.edu (Greg Siegle) Message-Id: <9206242212.AA27206@aristotle.ils.nwu.edu> To: clim@bbn.com Subject: How to manually poll for events Hi there, I'd like to be able to click on a presentation which calls a function which contains a potentially infinite loop, and still be able to click on other presentations on the screen and have them respond while that function is looping. It seems that as soon as I click on one presentation, the other presentations on the screen aren't clickable until the function called by my first click is finished executing. Do I need to make my own run-frame-top-level function (I'm using the default right now)? If need by, I can make the potentially infinite loop manually check for click events, but I'm not sure how to do that either... Has anyone done either of these things? Thanks! -- Greg   Received: from BBN.COM by LABS-N.BBN.COM id aa08129; 25 Jun 92 7:54 EDT Received: from ares.informatik.uni-ulm.de by BBN.COM id aa21158; 25 Jun 92 7:44 EDT Received: by ares.informatik.uni-ulm.de (4.1/UniUlm-info-1.1r) id AA10040; Thu, 25 Jun 92 13:43:10 +0200 Date: Thu, 25 Jun 92 13:43:10 +0200 From: manager@informatik.uni-ulm.de (System manager) Message-Id: <9206251143.AA10040@ares.informatik.uni-ulm.de> To: CL-Windows@mcc.com, CLIM@bbn.com, garnet-users@cs.cmu.edu Subject: add We'd like to get added to this mailing-list. Our e-mail address is: lisp@informatik.uni-ulm.de Thanx Harald   Received: from BBN.COM by LABS-N.BBN.COM id aa09761; 25 Jun 92 10:10 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa29681; 25 Jun 92 9:55 EDT Received: from WATERMELON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1098323; 25 Jun 1992 09:57:27-0400 Date: Thu, 25 Jun 1992 09:55-0400 From: John G. Aspinall Subject: How to manually poll for events To: siegle@aristotle.ils.nwu.edu, clim@BBN.COM In-Reply-To: <9206242212.AA27206@aristotle.ils.nwu.edu> Message-ID: <19920625135519.1.JGA@WATERMELON.SCRC.Symbolics.COM> Date: Wed, 24 Jun 1992 18:12 EDT From: Greg Siegle I'd like to be able to click on a presentation which calls a function which contains a potentially infinite loop, and still be able to click on other presentations on the screen and have them respond while that function is looping. It seems that as soon as I click on one presentation, the other presentations on the screen aren't clickable until the function called by my first click is finished executing. Do I need to make my own run-frame-top-level function (I'm using the default right now)? Your question has almost nothing to do with CLIM (that is, the answer would be almost the same in any interface), and everything to do with multiple processes, threads, or stack-groups. Since you don't say what platform you have CLIM on (ahem...) I'll answer in general terms with some reference to Genera. (Sticking to Genera terminology, I use "process" where Unix folks would probably say "thread". For purposes of this discussion they're equivalent.) In a single process, your other presentations aren't sensitive "until the function called by [your] first click is finished executing" *because* the function called by your first click hasn't finished executing. Your process is busy doing what you told it to do - that is - run the first function. To get the behaviour you want, you must have either have multiple processes, or do some event-polling from within your "potentially infinite" function. I regard polling as the inferior choice, since it requires that your function have knowledge of events and the like - which strikes me as smearing the modularity. To implement what you want, I would have the first click run a very short function which spawned another process to run the "potentially infinite" function. Process 1 returns to the command loop almost immediately and your presentations are sensitive. Meanwhile Process 2 is busy churning away. The interface application keeps track of Process 2 so it can know when it finished, kill it, restart it, or whatever. Note: it is not a good idea for Process 2 to do output directly to the CLIM frame. You would have to add locking to ensure that two processes didn't mess with each other's output. Instead, the interface should examine the state of Process 2, or its results, as part of the top level loop. Alternately, facilities so that Process 2 could insert a command in the application's input queue could be used. This isn't provided yet, but some recent discussion on this list suggests that it may be soon.   Received: from BBN.COM by LABS-N.BBN.COM id aa10895; 25 Jun 92 11:46 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa06186; 25 Jun 92 11:27 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1098387; 25 Jun 1992 11:29:22-0400 Date: Thu, 25 Jun 1992 11:29-0400 From: Scott McKay Subject: How to manually poll for events To: siegle@aristotle.ils.nwu.edu, clim@BBN.COM In-Reply-To: <9206242212.AA27206@aristotle.ils.nwu.edu> Message-ID: <19920625152949.0.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 24 Jun 1992 18:12 EDT From: Greg Siegle Hi there, I'd like to be able to click on a presentation which calls a function which contains a potentially infinite loop, and still be able to click on other presentations on the screen and have them respond while that function is looping. It seems that as soon as I click on one presentation, the other presentations on the screen aren't clickable until the function called by my first click is finished executing. Do I need to make my own run-frame-top-level function (I'm using the default right now)? If need by, I can make the potentially infinite loop manually check for click events, but I'm not sure how to do that either... The presentation type system in CLIM is essentially a synchronous model of I/O. This is intentional. You can use READ-GESTURE with :PEEK-P T to "look ahead" for pending events, and use the documented functions in the presentation type system to handle mouse click events. Has anyone done either of these things? Thanks! -- Greg   Received: from BBN.COM by LABS-N.BBN.COM id aa11694; 25 Jun 92 12:46 EDT Received: from crdgw1.GE.COM by BBN.COM id aa10967; 25 Jun 92 12:41 EDT Received: by crdgw1.ge.com (5.57/GE 1.139) id AA21486; Thu, 25 Jun 92 12:26:00 EDT Received: from diphda.crd.Ge.Com by sol.crd.Ge.Com (4.0/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA04195; Thu, 25 Jun 92 12:26:31 EDT Date: Thu, 25 Jun 92 12:26:31 EDT From: blau@sol.crd.ge.com (lauren h halverson) Message-Id: <9206251626.AA04195@sol.crd.Ge.Com> Received: by diphda.crd.Ge.Com (4.1/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA02941; Thu, 25 Jun 92 12:26:28 EDT To: clim@bbn.com Subject: Format-graph-from-roots, merge problem Reply-To: blau@crd.GE.COM Hi all, I am running lucid CLIM1.1 on a SPARCstation 2. I am trying to create a graph using FORMAT-GRAPH-FROM-ROOTS and have run into two (likely related) problems. First I try to use a merge-duplicates test of my own: (format-graph-from-roots roots obj-printer inferior-producer :merge-duplicates t :duplicate-test #'my-duplicate-test) I get the following error: >>Error: The :TEST argument, #, to MAKE-HASH-TABLE isn't legal. It should be either EQ, EQL, EQUAL, or EQUALP MAKE-HASH-TABLE: Keyword arg 0 (TEST): # Keyword arg 1 (SIZE): 67 Keyword arg 2 (REHASH-SIZE): NIL Keyword arg 3 (REHASH-THRESHOLD): NIL Keyword arg 4 (USE-CACHE): NIL :C 0: Supply a new :test 1: Retry displaying pane # 2: Skip redisplaying pane # 3: Simple Frame top level 4: Exit Simple Frame :A 5: Abort to Lisp Top Level -> :A SO instead I decided to use a duplicate-key and the dupicate-test #'equalp (format-graph-from-roots roots obj-printer inferior-producer :merge-duplicates t :duplicate-key #'my-duplicate-key :duplicate-test #'equalp) Now I don't get an error when I run, but the duplicates aren't merged. The duplicate key function is being called, but the test isn't. Any ideas ? Thanks, Lauren blau@crd.ge.com   Received: from BBN.COM by LABS-N.BBN.COM id aa12706; 25 Jun 92 14:11 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa15848; 25 Jun 92 14:07 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1098506; 25 Jun 1992 14:09:42-0400 Date: Thu, 25 Jun 1992 14:10-0400 From: Scott McKay Subject: Format-graph-from-roots, merge problem To: blau@crd.ge.com, clim@BBN.COM In-Reply-To: <9206251626.AA04195@sol.crd.Ge.Com> Message-ID: <19920625181007.5.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 25 Jun 1992 12:26 EDT From: lauren h halverson Hi all, I am running lucid CLIM1.1 on a SPARCstation 2. I am trying to create a graph using FORMAT-GRAPH-FROM-ROOTS and have run into two (likely related) problems. Hmm, this is a good one. The environment I used when writing FORMAT-GRAPH-FROM-ROOTS is less restrictive as to what test functions can be used on hash tables than X3J13 specifies. I don't know exactly what to suggest as a workaround. CLIM should fall back to using ASSOC in the case when it can't use a hash table. First I try to use a merge-duplicates test of my own: (format-graph-from-roots roots obj-printer inferior-producer :merge-duplicates t :duplicate-test #'my-duplicate-test) I get the following error: >>Error: The :TEST argument, #, to MAKE-HASH-TABLE isn't legal. It should be either EQ, EQL, EQUAL, or EQUALP MAKE-HASH-TABLE: Keyword arg 0 (TEST): # Keyword arg 1 (SIZE): 67 Keyword arg 2 (REHASH-SIZE): NIL Keyword arg 3 (REHASH-THRESHOLD): NIL Keyword arg 4 (USE-CACHE): NIL :C 0: Supply a new :test 1: Retry displaying pane # 2: Skip redisplaying pane # 3: Simple Frame top level 4: Exit Simple Frame :A 5: Abort to Lisp Top Level -> :A SO instead I decided to use a duplicate-key and the dupicate-test #'equalp (format-graph-from-roots roots obj-printer inferior-producer :merge-duplicates t :duplicate-key #'my-duplicate-key :duplicate-test #'equalp) Now I don't get an error when I run, but the duplicates aren't merged. The duplicate key function is being called, but the test isn't. Any ideas ? Thanks, Lauren blau@crd.ge.com   Received: from BBN.COM by LABS-N.BBN.COM id aa16912; 25 Jun 92 20:26 EDT Received: from daffy-duck.HQ.Ileaf.COM by HQ.Ileaf.COM (4.1/SMI-4.0-leafusa) for clim@bbn.com id AA04068; Thu, 25 Jun 92 18:27:59 EDT Received: by daffy-duck.HQ.Ileaf.COM (4.1/SMI-4.0-hq) for siegle@aristotle.ils.nwu.edu id AA02835; Thu, 25 Jun 92 18:28:07 EDT Date: Thu, 25 Jun 92 18:28:07 EDT From: leafusa!daffy-duck.HQ.Ileaf.COM!doughty Message-Id: <9206252228.AA02835@daffy-duck.HQ.Ileaf.COM> To: SWM@stony-brook.scrc.symbolics.com Cc: siegle@aristotle.ils.nwu.edu, clim@BBN.COM Subject: Re: How to manually poll for events Sender: leafusa!daffy-duck.HQ.Ileaf.COM!doughty Source-Info: From (or Sender) name not authenticated. Date: Thu, 25 Jun 1992 11:29-0400 From: Scott McKay Date: Wed, 24 Jun 1992 18:12 EDT From: Greg Siegle Hi there, I'd like to be able to click on a presentation which calls a function which contains a potentially infinite loop, and still be able to click on other presentations on the screen and have them respond while that function is looping. It seems that as soon as I click on one presentation, the other presentations on the screen aren't clickable until the function called by my first click is finished executing. Do I need to make my own run-frame-top-level function (I'm using the default right now)? If need by, I can make the potentially infinite loop manually check for click events, but I'm not sure how to do that either... The presentation type system in CLIM is essentially a synchronous model of I/O. This is intentional. You can use READ-GESTURE with :PEEK-P T to "look ahead" for pending events, and use the documented functions in the presentation type system to handle mouse click events. Don't forget to pass :timeout 0 to read-gesture so that it doesn't hang. The other utility you need to use in order to get sensitivity while you're peeking ahead is WITH-INPUT-CONTEXT. So the basic structure of your peek-ahead function is [sorry if I have any syntax wrong, I don't have a CLIM in front of me]: (defun frame-peek-ahead (program-frame &key (stream *standard-input*)) (when (with-input-context ('command) (read-gesture :stream stream :peek-p t :timeout 0)) (execute-frame-command program-frame (read-frame-command program-frame))))   Received: from BBN.COM by LABS-N.bbn.COM id aa23826; 26 Jun 92 10:50 EDT Received: by harvard.harvard.edu (5.54/a0.25) (for clim) id AA17703; Fri, 26 Jun 92 10:36:32 EDT Received: from gatech.UUCP by gatech.edu (4.1/Gatech-9.1) id AA04035 for bbn!clim; Fri, 26 Jun 92 10:29:32 EDT Received: from gatech.edu by gatech.UUCP (4.1/SMI-4.1) id AA23523; Fri, 26 Jun 92 10:29:14 EDT Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA04027 for clim@bbn; Fri, 26 Jun 92 10:29:11 EDT Received: from pravda.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA07033; for clim@bbn; Fri, 26 Jun 92 10:26:55 EDT Received: from kant.gatech.edu (kant.cc.gatech.edu) by pravda.cc.gatech.edu (4.1/SMI-4.1) id AA20462; Fri, 26 Jun 92 10:26:54 EDT Date: Fri, 26 Jun 1992 10:23-0400 From: harvard!gatech!cc!buff Subject: CLIM problems ... To: bbn!clim, cc.gatech.edu!SYMBUGS:; Message-Id: <19920626142311.2.BUFF@kant.gatech.edu> Sender: harvard!gatech!cc!buff Source-Info: From (or Sender) name not authenticated. Some observations about CLIM behavior under Genera 8.1.1 running the latest released CLIM 1.1. First, CLIM is pretty great overall, except for the following frays around the edges - some of which make our application look pretty ugly. We have a standalone piece of the larger application we are writing which we can make available to show almost all of the behaviors detailed below. However, we have not had the time to write nice little pieces of example code for each of these behaviors. If you want the standalone code, please advise (it's less than 1200 lines of code). ---------- 1) When accept'ing a string (at least), CLIM apparently treats newlines differently for _writing_ and _erasing_ text, causing a string with newlines in it to erase "too high" and blow away previous lines, as well as drawing its _last_ line on top of whatever was there before (because it's underlying erase erased the line before it) For example: Line 1: part of a string Line 2: continuation of the string Line 3: more stuff in the string Line 4: current extent of string If my cursor is at the end of Line 3 and I -p to Line 2 and type any character, Line 2 is whited-out above Line 3 (i.e. all but the final "ng" of Line 2) and as new text is typed in this display behaviour doesn't change, except for the characters in Line 2 that will now appear after the end of Line 3 (i.e. if you are adding characters to the line, the line appearing as it should begins to be displayed after (and above) the end of Line 3). The white-out is (we think) when a piece of text is changed you must erase the old version and draw the new version. Drawing the new version is correct. But erasing the old-version occurs a line to high. That means text before the area that is being redrawn is erased (as described above) and the text at the bottom of the string being redrawn does not get properly erased, and if there's any change to this last piece of text, you get muliple images overlayed. Also, if you type two returns (or more) in a row, the first descends the proper amount, but each additional return only moves the cursor down by a pixel. Under certain conditions, when the whole string has to be redrawn, then white-out is still displayed incorrectly, but the mulitiple carriage returns are displayed correctly, causing the appearence of the string to change. Tied in with this problem is the scrolling problem (see below). It doesn't seem outrageous that this should work, seeing as DW is able to do it just fine - i.e. (dw:accept 'string) has none of these problems. 2) CLIM accept on strings permits the user to write enough string to scroll off the bottom end and allows the user to go _down_ off the end of the screen with cursor keys, but will not scroll back _up_ when the user goes back up the string. This is not to say I can't move the cursor to the logical beginning of the string, but that CLIM doesn't show it to me. So, should I reposition the cursor to the beginning of the string, the screen doesn't reflect that move, but if I type a character, the whole string is redisplayed (from the top to the bottom) leaving me looking at the bottom of the string and my cursor one character from the beginning of the string - i.e. the display jumps around a ton, but always leaves me looking at the end of the string, not at what I'm typing. 3) CLIM has this funkee scrolling problem where if things scroll past the end and it then has to scroll back during the display of the same thing, parts of that thing get trashed. Example: if CLIM is presenting a single object and it goes beyond the right window margin, it scrolls horizontally to show the end of the object. BUT, if during the display the cursor goes back to the left margin, then CLIM scrolls back to show that part of the object. So far, so good. However, the stuff that was scrolled off of the screen to the left doesn't get redisplayed, and instead you have a blank white column there. 5) Scrollbars are not consistent. They often do not respond to the size of presented objects until those scrollbars are modifed by the user. If you present something in a window that doesn't fit, so it scrolls, the scroll bars indicate that you are looking at the entire object, even though you're not, until you use the scroll bar to scroll - then they correct their display and are correct after that. 6) You cannot attach a documentation string to a menu item in a command table that is a call to a nested menu; CLIM's default of "COMMANDNAME Menu" overrides the documentation. 6A) No way to change the character style for a particular item in a top level menu, as you can in clim:menu-choose. A similar syntax to clim:menu-choose for top-level menus would be nice. 7) with-drawing-options :clipping-region doesn't seem to work as expected. We expect that any activity that generates output in the window outside of the region will have its output clipped. However, when using a combination of filling-output and indenting-output correctly but using the wrong parameters so that some of the text got sent outside the clipping region, the text got printed. There's nothing to indicate that clipping-region will apply to presented text, however, given that drawing-options include other parameters that do apply to text (:text-style), nor do we find any obvious delineation between text output and other graphic output in CLIM, we assume this is the appropriate way to clip textual output. 8) with-activation-characters we would expect to work very similarly to (syntax may not be exactly right, but you get the idea): (defmacro with-act-char ((additional-characters &key (override nil)) &body body) `(let ((*standard-activation-characters* (if override additional-characters `(,@*standard-activation-characters* ,@additional-characters)))) ,@body)) It doesn't. It seems to have no effect on the activation characters. We hacked in something like the above and it all worked fine. 9) There's no way to find out the view used to put a particular presentation on the screen.   Received: from BBN.COM by LABS-N.bbn.COM id aa20245; 29 Jun 92 15:17 EDT Received: from ATHENA.MIT.EDU by BBN.COM id aa21623; 29 Jun 92 14:56 EDT Received: from SCHAROUN.MIT.EDU by Athena.MIT.EDU with SMTP id AA12364; Mon, 29 Jun 92 14:56:03 EDT From: janson@Athena.MIT.EDU Received: by scharoun (5.57/4.7) id AA04765; Mon, 29 Jun 92 14:56:02 -0400 Message-Id: <9206291856.AA04765@scharoun> To: clim@bbn.com Subject: changing the behavior of display windows. Date: Mon, 29 Jun 92 14:56:01 EDT hi. is there a supported way to add methods to application panes. i had been looking for means to either augment the class of the panes instantiated for a given application frame, or to define additional methods for a system-defined class. so far, the only class `hook' i can find is that application panes are specified to be clim:clx-window 's, but that doesn't seem quite as portable as i would hope for. thanks. james.   Received: from BBN.COM by LABS-N.BBN.COM id aa20815; 29 Jun 92 16:03 EDT Received: from aristotle.ils.nwu.edu by BBN.COM id aa25328; 29 Jun 92 15:58 EDT Received: by aristotle.ils.nwu.edu (4.1/SMI-ILS-1.05) id AA12076; Mon, 29 Jun 92 14:44:34 CDT Date: Mon, 29 Jun 92 14:44:34 CDT From: siegle@aristotle.ils.nwu.edu (Greg Siegle) Message-Id: <9206291944.AA12076@aristotle.ils.nwu.edu> To: clim@BBN.COM, janson@athena.mit.edu Subject: Re: changing the behavior of display windows. Hi Jason, CLIM lets you specify a :window-class key to a pane definition. While your window class will have to be system specific you can probably get away with a few #+'s... e.g., I define (clim:define-application-frame cpe () () (:panes ((display :application :window-class `grpwin :pt-lst '()) ... where grpwin is a window class defined as (clos:defclass grpwin (#+CLX clim::clx-window #+CLOE clim::cloe-window-stream) ((pts :initarg :pt-lst :accessor icons) (edges :initform '() :initarg :edges :accessor edges))) Hope this helps. -- Greg   Received: from BBN.COM by LABS-N.BBN.COM id aa21143; 29 Jun 92 16:21 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa26748; 29 Jun 92 16:17 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1100578; 29 Jun 1992 16:18:56-0400 Date: Mon, 29 Jun 1992 16:19-0400 From: Scott McKay Subject: changing the behavior of display windows. To: janson@athena.mit.edu, clim@BBN.COM In-Reply-To: <9206291856.AA04765@scharoun> Message-ID: <19920629201949.1.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 29 Jun 1992 14:56 EDT From: janson@athena.mit.edu hi. is there a supported way to add methods to application panes. i had been looking for means to either augment the class of the panes instantiated for a given application frame, or to define additional methods for a system-defined class. so far, the only class `hook' i can find is that application panes are specified to be clim:clx-window 's, but that doesn't seem quite as portable as i would hope for. The best you can do in CLIM 1.1 is add methods to WINDOW-MIXIN. CLIM 2.0 is better in this regard.   Received: from BBN.COM by LABS-N.BBN.COM id aa29831; 30 Jun 92 8:41 EDT Received: from mail.Germany.EU.net by BBN.COM id aa07705; 30 Jun 92 8:29 EDT Received: from sger by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA14785; Tue, 30 Jun 92 10:35:43 +0200 Received: from FUJI-SAN.SGER.UUCP ([192.1.2.67]) by sger.SGER.COM (4.1/SMI-4.1) id AA15180; Tue, 30 Jun 92 09:51:50 +0200 Date: Tue, 30 Jun 1992 10:05+0100 From: Markus Fischer Reply-To: mf@sger.uucp Subject: CLIM problems ... To: clim@bbn.com In-Reply-To: <19920626142311.2.BUFF@kant.gatech.edu> Message-Id: <19920630090532.7.MF@FUJI-SAN.SGER.UUCP> Date: Fri, 26 Jun 1992 15:23+0100 From: unido!gatech!cc!buff Some observations about CLIM behavior under Genera 8.1.1 running the latest released CLIM 1.1. First, CLIM is pretty great overall, except for the following frays around the edges - some of which make our application look pretty ugly. In general, I agree with you that CLIM has some problems with UIs that have to have real *product* quality. However, you should consider the few people implementing it in quite a short time. We have a standalone piece of the larger application we are writing which we can make available to show almost all of the behaviors detailed below. However, we have not had the time to write nice little pieces of example code for each of these behaviors. If you want the standalone code, please advise (it's less than 1200 lines of code). Even 1200 lines of code need their time to be scanned, tested, and (if possible) corrected. ---------- 1) When accept'ing a string (at least), CLIM apparently treats newlines differently for _writing_ and _erasing_ text, causing a string with newlines in it to erase "too high" and blow away previous lines, as well as drawing its _last_ line on top of whatever was there before (because it's underlying erase erased the line before it) For example: Line 1: part of a string Line 2: continuation of the string Line 3: more stuff in the string Line 4: current extent of string If my cursor is at the end of Line 3 and I -p to Line 2 and type any character, Line 2 is whited-out above Line 3 (i.e. all but the final "ng" of Line 2) and as new text is typed in this display behaviour doesn't change, except for the characters in Line 2 that will now appear after the end of Line 3 (i.e. if you are adding characters to the line, the line appearing as it should begins to be displayed after (and above) the end of Line 3). The white-out is (we think) when a piece of text is changed you must erase the old version and draw the new version. Drawing the new version is correct. But erasing the old-version occurs a line to high. That means text before the area that is being redrawn is erased (as described above) and the text at the bottom of the string being redrawn does not get properly erased, and if there's any change to this last piece of text, you get muliple images overlayed. Also, if you type two returns (or more) in a row, the first descends the proper amount, but each additional return only moves the cursor down by a pixel. Under certain conditions, when the whole string has to be redrawn, then white-out is still displayed incorrectly, but the mulitiple carriage returns are displayed correctly, causing the appearence of the string to change. Tied in with this problem is the scrolling problem (see below). It doesn't seem outrageous that this should work, seeing as DW is able to do it just fine - i.e. (dw:accept 'string) has none of these problems. 2) CLIM accept on strings permits the user to write enough string to scroll off the bottom end and allows the user to go _down_ off the end of the screen with cursor keys, but will not scroll back _up_ when the user goes back up the string. This is not to say I can't move the cursor to the logical beginning of the string, but that CLIM doesn't show it to me. So, should I reposition the cursor to the beginning of the string, the screen doesn't reflect that move, but if I type a character, the whole string is redisplayed (from the top to the bottom) leaving me looking at the bottom of the string and my cursor one character from the beginning of the string - i.e. the display jumps around a ton, but always leaves me looking at the end of the string, not at what I'm typing. 3) CLIM has this funkee scrolling problem where if things scroll past the end and it then has to scroll back during the display of the same thing, parts of that thing get trashed. Example: if CLIM is presenting a single object and it goes beyond the right window margin, it scrolls horizontally to show the end of the object. BUT, if during the display the cursor goes back to the left margin, then CLIM scrolls back to show that part of the object. So far, so good. However, the stuff that was scrolled off of the screen to the left doesn't get redisplayed, and instead you have a blank white column there. I think I did fix this bug for the NON-Silica version of CLIM, and sent the bug to Scott McKay, of Symbolics, Inc. I don't know for sure what will happen to the fix. If there are no copyright problems, you can ask Scott to send the source of the modified function around. If you've got some time left, it's better to wait for the next release. 5) Scrollbars are not consistent. They often do not respond to the size of presented objects until those scrollbars are modifed by the user. If you present something in a window that doesn't fit, so it scrolls, the scroll bars indicate that you are looking at the entire object, even though you're not, until you use the scroll bar to scroll - then they correct their display and are correct after that. I also said something to this point in this mailng list: As a quick fix, use CLIM::REDISPLAY-DECORATIONS. 6) You cannot attach a documentation string to a menu item in a command table that is a call to a nested menu; CLIM's default of "COMMANDNAME Menu" overrides the documentation. 6A) No way to change the character style for a particular item in a top level menu, as you can in clim:menu-choose. A similar syntax to clim:menu-choose for top-level menus would be nice. You're able to specify an arbitrary function in our application frame definition that is to be used to display a command menu. 7) with-drawing-options :clipping-region doesn't seem to work as expected. We expect that any activity that generates output in the window outside of the region will have its output clipped. However, when using a combination of filling-output and indenting-output correctly but using the wrong parameters so that some of the text got sent outside the clipping region, the text got printed. There's nothing to indicate that clipping-region will apply to presented text, however, given that drawing-options include other parameters that do apply to text (:text-style), nor do we find any obvious delineation between text output and other graphic output in CLIM, we assume this is the appropriate way to clip textual output. 8) with-activation-characters we would expect to work very similarly to (syntax may not be exactly right, but you get the idea): (defmacro with-act-char ((additional-characters &key (override nil)) &body body) `(let ((*standard-activation-characters* (if override additional-characters `(,@*standard-activation-characters* ,@additional-characters)))) ,@body)) It doesn't. It seems to have no effect on the activation characters. We hacked in something like the above and it all worked fine. It does not work correctly, that's true. You can contact Symbolics Software Support to report the bug. The easier the bug is to fix, the better. (Maybe you should provide your version of the macro with-actication-characters. But note that you have the options :activation-characters and :additional-activation-characters to accept, which should work, though. 9) There's no way to find out the view used to put a particular presentation on the screen. As I understand it, views are used to specialize present methods. Note that you don't have a :view option to with-output-as-presentation, because the body of such a macro call is lexically specified, i.e., fixed. Consequently, a :view option would be senseless. This reason can alo be used as an argument to motivate the non-existance of a slot "view" in tha class "presentation", resp. "standard-presentation", because once the presentation is generated, it is not important anymore, which present method was chose to create it. If you want to know about such a thing, you will have to add a subclass to "standard-presentation" with such an additional slot, you have to fill manually in your present methods.   Received: from BBN.COM by LABS-N.BBN.COM id aa14679; 1 Jul 92 7:32 EDT Received: from noc.BelWue.DE by BBN.COM id aa19787; 1 Jul 92 7:29 EDT Received: from adler.ims.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA08995 (5.65c/BelWue-M2.03 for ); Wed, 1 Jul 1992 13:29:00 +0200 Received: from milan.ims.uni-stuttgart.de by adler.ims.uni-stuttgart.de (4.1/BelWue-1.2SUN) id AA02462; Wed, 1 Jul 92 13:28:59 +0200 Date: Wed, 1 Jul 92 13:28:59 +0200 From: Oliver Christ Message-Id: <9207011128.AA02462@adler.ims.uni-stuttgart.de> Received: by milan.ims.uni-stuttgart.de (4.1/BelWue-1.2SUN) id AA12538; Wed, 1 Jul 92 13:28:58 +0200 To: clim@bbn.com Subject: Why doesn't this work? Reply-To: oli@adler.ims.uni-stuttgart.de [Lucid Lisp with CLIM 1.0 Beta] To let the user select an object of type 'dag-node (my own class) or to select nothing, I would expect the following to work: (defun read-node (stream) (clim:with-input-context ('(or clim:blank-area dag-node)) (node) (read) (dag-node node) (clim:blank-area nil))) but it doesn't. Of course, the user may select a dag-node, but clicks on the blank area of the pane aren't recognized. Why? Thanks, Oli   Received: from BBN.COM by LABS-N.BBN.COM id aa14591; 1 Jul 92 7:26 EDT Received: from noc.BelWue.DE by BBN.COM id aa19656; 1 Jul 92 7:21 EDT Received: from adler.ims.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA08611 (5.65c/BelWue-M2.03 for ); Wed, 1 Jul 1992 13:20:18 +0200 Received: from milan.ims.uni-stuttgart.de by adler.ims.uni-stuttgart.de (4.1/BelWue-1.2SUN) id AA02402; Wed, 1 Jul 92 13:20:17 +0200 Date: Wed, 1 Jul 92 13:20:17 +0200 From: Oliver Christ Message-Id: <9207011120.AA02402@adler.ims.uni-stuttgart.de> Received: by milan.ims.uni-stuttgart.de (4.1/BelWue-1.2SUN) id AA12498; Wed, 1 Jul 92 13:20:17 +0200 To: clim@bbn.com Subject: Memory problems with Lucid&CLIM1.0Beta Reply-To: oli@adler.ims.uni-stuttgart.de Dear CLIM'bers (of the Buggy Mountains), running CLIM 1.0 Beta on Lucid, I have severe memory problems. When I start and exit the (rather big) application 4 or 5 times and running it again, CLIM switches off the garbage collection (I can't determine exactly the moment this happens) and soon Lucid runs out of memory. I have to leave Lisp (or it kills itself -- no chance to 'save' anything on the disk) and restart all over again. This does *not* happen when the application runs without the CLIM interface. Has anyone similiar problems? Has anybody an idea to prevent CLIM from switching off gc? Or are there other reasons for this strange behaviour? What are the reasons for an application to switch off gc? If its a Lucid- specific problem and CLIM isn't involved, please excuse me using this mailing list. Any help appreciated, Oli ---------------------------------------------------------------------- PS: Here are some error messages ;;; GC: 232100 words [928400 bytes] of dynamic storage in use. ;;; 226650 words [906600 bytes] of free storage available before a GC. ;;; 685400 words [2741600 bytes] of free storage available if GC is disabled. ;;; GC required to reorganize memory for GC disabling ;;; GC: 232100 words [928400 bytes] of dynamic storage in use. ;;; 226650 words [906600 bytes] of free storage available before a GC. ;;; 685400 words [2741600 bytes] of free storage available if GC is disabled. >>Error: GC and EGC disabled: not enough storage after GC. CONSers are now using the storage normally reserved for copying currently allocated dynamic storage. EPHEMERAL-GC: Optional arg 0 (FORCE-TO-DYNAMIC): NIL Optional arg 1 (DISABLING-EGC): NIL :C 0: Continue the current computation with GC and EGC disabled. The next GC might fail. :A 1: Return to CLIM TFS Interface command level 2: CLIM TFS Interface top level 3: Exit CLIM TFS Interface 4: Abort to Lisp Top Level -> 0 Continue the current computation with GC and EGC disabled. The next GC might fail. <<>> ;;; Ran Out of Memory while GC Disabled   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa20038; 1 Jul 92 11:25 EDT To: oli@adler.ims.uni-stuttgart.de cc: clim@BBN.COM Subject: Re: Memory problems with Lucid&CLIM1.0Beta In-reply-to: Your message of Wed, 01 Jul 92 13:20:17 +0200. <9207011120.AA02402@adler.ims.uni-stuttgart.de> Date: Wed, 01 Jul 92 11:17:39 -0400 From: kanderso@BBN.COM Date: Wed, 1 Jul 92 13:20:17 +0200 From: Oliver Christ To: clim@BBN.COM Subject: Memory problems with Lucid&CLIM1.0Beta Reply-To: oli@adler.ims.uni-stuttgart.de PS: Here are some error messages ;;; GC: 232100 words [928400 bytes] of dynamic storage in use. ;;; 226650 words [906600 bytes] of free storage available before a GC. ;;; 685400 words [2741600 bytes] of free storage available if GC is disabled. ;;; GC required to reorganize memory for GC disabling ;;; GC: 232100 words [928400 bytes] of dynamic storage in use. ;;; 226650 words [906600 bytes] of free storage available before a GC. ;;; 685400 words [2741600 bytes] of free storage available if GC is disabled. >>Error: GC and EGC disabled: not enough storage after GC. CONSers are now using the storage normally reserved for copying currently allocated dynamic storage. EPHEMERAL-GC: Optional arg 0 (FORCE-TO-DYNAMIC): NIL Optional arg 1 (DISABLING-EGC): NIL :C 0: Continue the current computation with GC and EGC disabled. The next GC might fail. :A 1: Return to CLIM TFS Interface command level 2: CLIM TFS Interface top level 3: Exit CLIM TFS Interface 4: Abort to Lisp Top Level I don't believe this is a CLIM problem. Your operating system was not able to deliver the space requested by LUCID for a GC. This can happen if you run out of swap space for example. If you are on a unix system, you can use pstat -T to monitor you swap space. Your application may have also reached a resource limit. k   Received: from BBN.COM by LABS-N.BBN.COM id aa19614; 1 Jul 92 10:43 EDT Received: from lucid.com by BBN.COM id aa01974; 1 Jul 92 10:40 EDT Received: from kuwait.lucid ([192.31.212.118]) by heavens-gate.lucid.com id AA19619g; Wed, 1 Jul 92 07:31:45 PDT Received: by kuwait.lucid (4.1/SMI-4.1) id AA08664; Wed, 1 Jul 92 07:40:44 PDT Date: Wed, 1 Jul 92 07:40:44 PDT From: kern%kuwait@lucid.com (John Kern) Message-Id: <9207011440.AA08664@kuwait.lucid> To: oli@adler.ims.uni-stuttgart.de Cc: clim@BBN.COM In-Reply-To: Oliver Christ's message of Wed, 1 Jul 92 13:20:17 +0200 <9207011120.AA02402@adler.ims.uni-stuttgart.de> Subject: Memory problems with Lucid&CLIM1.0Beta Reply-To: kern@lucid.com Howdy Mr. Christ, This looks like a GC problem that is unrelated to CLIM. I would recommend resolving this problem via the support@lucid.com mail alias. Please, include: * the platform and version of lisp. * results of (room t) when you encounter the error Sincerely, John S. Kern Lucid, Inc. Customer Support   Received: from BBN.COM by LABS-N.BBN.COM id aa24575; 1 Jul 92 17:37 EDT Received: from ptolemy-arclan.arc.nasa.gov by BBN.COM id aa23141; 1 Jul 92 17:28 EDT Received: from kepler.arc.nasa.gov by ptolemy.arc.nasa.gov (4.1/) id ; Wed, 1 Jul 92 14:25:44 PDT Date: Wed, 1 Jul 92 14:25:44 PDT From: Philip Chu-Summer 92 Message-Id: <9207012125.AA02572@ptolemy.arc.nasa.gov> Received: by kepler.arc.nasa.gov (4.1/SMI-4.1) id AA22107; Wed, 1 Jul 92 14:21:45 PDT To: clim@bbn.com Subject: text-style-family returns number I'm using CLIM 4.1 with Franz Allegro Common Lisp on a Sun Sparcstation. After creating a text style, I'd like to be able to retrieve the text style components, but for the text face I get a number instead of the originally provided name. Is this a bug, and how do I go about getting the face name? USER(26): (clim:make-text-style :fix :bold :large) # USER(27): (clim:text-style-face *) 4 USER(28): (clim:text-style-family **) :FIX USER(29): (clim:text-style-size ***) :LARGE Phil Chu Artificial Intelligence Research Branch NASA Ames Research Center pchu@ptolemy.arc.nasa.gov   Received: from BBN.COM by LABS-N.BBN.COM id aa25258; 1 Jul 92 18:52 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa25258; 1 Jul 92 18:49 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1102093; 1 Jul 1992 18:49:52-0400 Date: Wed, 1 Jul 1992 18:50-0400 From: Scott McKay Subject: text-style-family returns number To: pchu@ptolemy.arc.nasa.gov, clim@BBN.COM In-Reply-To: <9207012125.AA02572@ptolemy.arc.nasa.gov> Message-ID: <19920701225054.6.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 1 Jul 1992 17:25 EDT From: Philip Chu-Summer 92 I'm using CLIM 4.1 with Franz Allegro Common Lisp on a Sun Sparcstation. After creating a text style, I'd like to be able to retrieve the text style components, but for the text face I get a number instead of the originally provided name. Is this a bug, and how do I go about getting the face name? USER(26): (clim:make-text-style :fix :bold :large) # USER(27): (clim:text-style-face *) 4 USER(28): (clim:text-style-family **) :FIX USER(29): (clim:text-style-size ***) :LARGE I had thought that this was fixed in CLIM 1.1, although it is possible that it did not make it into the Franz stream. CLIM::FACE-CODE->FACE will turn the number into a face name.   Received: from BBN.COM by LABS-N.BBN.COM id aa25902; 1 Jul 92 20:12 EDT Received: from ptolemy-arclan.arc.nasa.gov by BBN.COM id aa27135; 1 Jul 92 20:08 EDT Received: from kepler.arc.nasa.gov by ptolemy.arc.nasa.gov (4.1/) id ; Wed, 1 Jul 92 17:06:23 PDT Date: Wed, 1 Jul 92 17:06:23 PDT From: Philip Chu-Summer 92 Message-Id: <9207020006.AA03690@ptolemy.arc.nasa.gov> Received: by kepler.arc.nasa.gov (4.1/SMI-4.1) id AA22261; Wed, 1 Jul 92 17:02:27 PDT To: SWM@stony-brook.scrc.symbolics.com Cc: clim@BBN.COM In-Reply-To: Scott McKay's message of Wed, 1 Jul 1992 18:50-0400 <19920701225054.6.SWM@SUMMER.SCRC.Symbolics.COM> Subject: text-style-family returns number Sender: SWM%stony-brook.scrc.symbolics.com@BBN.COM Date: Wed, 1 Jul 1992 18:50-0400 From: Scott McKay Date: Wed, 1 Jul 1992 17:25 EDT From: Philip Chu-Summer 92 I'm using CLIM 4.1 with Franz Allegro Common Lisp on a Sun Sparcstation. After creating a text style, I'd like to be able to retrieve the text style components, but for the text face I get a number instead of the originally provided name. Is this a bug, and how do I go about getting the face name? USER(26): (clim:make-text-style :fix :bold :large) # USER(27): (clim:text-style-face *) 4 USER(28): (clim:text-style-family **) :FIX USER(29): (clim:text-style-size ***) :LARGE I had thought that this was fixed in CLIM 1.1, although it is possible that it did not make it into the Franz stream. CLIM::FACE-CODE->FACE will turn the number into a face name. Thanks, CLIM::FACE-CODE->FACE solved my problem. I know that besides the fix for the abovementioned problem, CLIM::FORMAT-GRAPH-FROM-ROOTS didn't make it into the CLIM 1.1 release from Franz. Is there a publicly-available list of bug-fixes/enhancements made in CLIM 1.1? If there were, I could direct my queries to the guys at Franz on topics that have already been addressed on this list. Phil Chu Artificial Intelligence Research Branch NASA Ames Research Center pchu@ptolemy.arc.nasa.gov   Received: from BBN.COM by LABS-N.BBN.COM id aa25732; 1 Jul 92 19:51 EDT Received: from hermes.intel.com by BBN.COM id aa26355; 1 Jul 92 19:46 EDT Received: from HANU.intel.com by hermes.intel.com (5.65/10.0i); Wed, 1 Jul 92 16:46:12 -0700 Date: Wed, 1 Jul 92 16:46:12 PDT From: RBHATT@HANU.intel.com Message-Id: <9207012346.utk20166@HANU.intel.com> X-To: hermes::"clim@bbn.com" Subject: Pres Qs. To: clim@bbn.com Hi! I am creating about 1600 rectangular presentation items (all uniform) on the screen to represent certain objects. The user may request changing the size of the objects (all objects simulataneously), in which case I have to erase the previous presentations (window-clear) redraw the new presentations. WHICH TAKES A WHILE. Furthermore, this is annoying especially so because there is other non-presentation graphics in the window (which is easy to draw but no-good aesthetically). Q1: Is there an easy way to change the shape of a presentation? CLIM manual says not to mess with size/shape of presentations. These presentations are also "flipped" (like in a bitmap editor) and when refreshing the window, it replays all the previous output. I tried not recording, (using with-output-recording-options with :record-p nil) and that had its problems when scrolling the window and such (I don't remeber exactly since I had tried this a while ago but I can reproduce and explain it if its necessary). Q2: Is there a way to not replay output. I guess the solution I am looking for is to draw these presentations in the background (in a process maybe) and write to an output record. Then replay the output record on my window. This way, I have the output record I want. But it still takes a long time to draw these presentations. Ideally, I should just change the size of each and be done with it. (That way, I also retain those that are selected.) Finally, the same program goes into a phase where the presentations are not mouse sensitive. Currently they are drawn inside a with output as presentation and used via a presentation to command traslator. Q3: Is there a way to remove (and add) a translator at run time (is this recommended by CLIM?). I am writing portable code and dont want to mess with low level stuff. If something is inthe"standard" (or not recommended) than I want to stay away from it for fear it wont be supported on all CLIMs. Should I be so (overly) cautious? Thanx in advance. Please respond directly to my email address. I'll summarize results, especially the innovative one. -- Rahul Bhatt rbhatt@sc9.intel.com   Received: from BBN.COM by LABS-N.BBN.COM id aa26781; 1 Jul 92 22:32 EDT Received: from hermes.intel.com by BBN.COM id aa01827; 1 Jul 92 22:28 EDT Received: from delphi.intel.com by hermes.intel.com (5.65/10.0i); Wed, 1 Jul 92 19:28:22 -0700 Received: from quasimodo (quasimodo.intel.com) by sc.intel.com with PMDF#10264; Wed, 1 Jul 1992 19:20 PST Received: by quasimodo (5.51/10.0i); Wed, 1 Jul 92 19:23:46 PDT Date: Wed, 1 Jul 92 19:23:46 PDT From: rbhatt@quasimodo.intel.com (Rahul Bhatt) Subject: Presn Questions To: clim@bbn.COM Cc: rbhatt@sc.intel.com Message-Id: <9207020223.AA21763@quasimodo> Hi! I am creating about 1600 rectangular presentation items (all uniform) on the screen to represent certain objects. The user may request changing the size of the objects (all objects simulataneously), in which case I have to erase the previous presentations (window-clear) redraw the new presentations. WHICH TAKES A WHILE. Furthermore, this is annoying especially so because there is other non-presentation graphics in the window (which is easy to draw but no-good aesthetically). Q1: Is there an easy way to change the shape of a presentation? CLIM manual says not to mess with size/shape of presentations. These presentations are also "flipped" (like in a bitmap editor) and when refreshing the window, it replays all the previous output. I tried not recording, (using with-output-recording-options with :record-p nil) and that had its problems when scrolling the window and such (I don't remeber exactly since I had tried this a while ago but I can reproduce and explain it if its necessary). Q2: Is there a way to not replay output. I guess the solution I am looking for is to draw these presentations in the background (in a process maybe) and write to an output record. Then replay the output record on my window. This way, I have the output record I want. But it still takes a long time to draw these presentations. Ideally, I should just change the size of each and be done with it. (That way, I also retain those that are selected.) Finally, the same program goes into a phase where the presentations are not mouse sensitive. Currently they are drawn inside a with output as presentation and used via a presentation to command traslator. Q3: Is there a way to remove (and add) a translator at run time (is this recommended by CLIM?). I am writing portable code and dont want to mess with low level stuff. If something is inthe"standard" (or not recommended) than I want to stay away from it for fear it wont be supported on all CLIMs. Should I be so (overly) cautious? Thanx in advance. Please respond directly to my email address. I'll summarize results, especially the innovative one. -- Rahul Bhatt rbhatt@sc9.intel.com   Received: from BBN.COM by LABS-N.BBN.COM id aa04352; 2 Jul 92 9:24 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa09743; 2 Jul 92 9:09 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1102409; 2 Jul 1992 09:10:31-0400 Date: Thu, 2 Jul 1992 09:11-0400 From: Scott McKay Subject: text-style-family returns number Sender: SWM%stony-brook.scrc.symbolics.com@BBN.COM Date: Wed, 1 Jul 1992 18:50-0400 From: Scott McKay To: pchu@ptolemy.arc.nasa.gov, SWM@STONY-BROOK.SCRC.Symbolics.COM cc: clim@BBN.COM In-Reply-To: <9207020006.AA03690@ptolemy.arc.nasa.gov> Message-ID: <19920702131146.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 1 Jul 1992 20:06 EDT From: Philip Chu-Summer 92 Date: Wed, 1 Jul 1992 17:25 EDT From: Philip Chu-Summer 92 I'm using CLIM 4.1 with Franz Allegro Common Lisp on a Sun Sparcstation. After creating a text style, I'd like to be able to retrieve the text style components, but for the text face I get a number instead of the originally provided name. Is this a bug, and how do I go about getting the face name? USER(26): (clim:make-text-style :fix :bold :large) # USER(27): (clim:text-style-face *) 4 USER(28): (clim:text-style-family **) :FIX USER(29): (clim:text-style-size ***) :LARGE I had thought that this was fixed in CLIM 1.1, although it is possible that it did not make it into the Franz stream. CLIM::FACE-CODE->FACE will turn the number into a face name. Thanks, CLIM::FACE-CODE->FACE solved my problem. I know that besides the fix for the abovementioned problem, CLIM::FORMAT-GRAPH-FROM-ROOTS didn't make it into the CLIM 1.1 release from Franz. Is there a publicly-available list of bug-fixes/enhancements made in CLIM 1.1? If there were, I could direct my queries to the guys at Franz on topics that have already been addressed on this list. The Symbolics documentation includes a list of most of the bugfixes and enhancements to CLIM 1.1. Due to internal schedules, Franz, Inc. was a little bit ahead of the rest of us in releasing CLIM 1.1, and so that list might not fully apply to them. Maybe that's what you are asking for. I don't know a good way to publish the Symbolics release notes, since they are typeset only in Concordia (which is the hypertext typesetting and documentation system used under Genera).   Received: from BBN.COM by LABS-N.BBN.COM id aa06465; 2 Jul 92 10:57 EDT Received: from mail.Germany.EU.net by BBN.COM id aa15381; 2 Jul 92 10:52 EDT Received: from sger by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA24197; Thu, 2 Jul 92 16:42:34 +0200 Received: from FUJI-SAN.SGER.UUCP ([192.1.2.67]) by sger.SGER.COM (4.1/SMI-4.1) id AA16786; Thu, 2 Jul 92 16:03:17 +0200 Date: Thu, 2 Jul 1992 16:17+0100 From: Markus Fischer Reply-To: mf@sger.uucp Subject: Presn Questions To: rbhatt@quasimodo.intel.com Cc: clim@BBN.COM In-Reply-To: <9207020223.AA21763@quasimodo> Message-Id: <19920702151706.3.MF@FUJI-SAN.SGER.UUCP> Date: Thu, 2 Jul 1992 03:23+0100 From: Rahul Bhatt Hi! I am creating about 1600 rectangular presentation items (all uniform) on the screen to represent certain objects. The user may request changing the size of the objects (all objects simulataneously), in which case I have to erase the previous presentations (window-clear) redraw the new presentations. WHICH TAKES A WHILE. Furthermore, this is annoying especially so because there is other non-presentation graphics in the window (which is easy to draw but no-good aesthetically). Q1: Is there an easy way to change the shape of a presentation? CLIM manual says not to mess with size/shape of presentations. To my knowledge, there is NO way to change a presentation at all, once it is created, using documented CLIM functions. What you've got to do is to erase presentations with the function CLIM:ERASE-OUTPUT-RECORD (note that presentations are output records) and represent your objects using CLIM:PRESENT again with the new (rectangle) size. These presentations are also "flipped" (like in a bitmap editor) and when refreshing the window, it replays all the previous output. I tried not recording, (using with-output-recording-options with :record-p nil) and that had its problems when scrolling the window and such (I don't remeber exactly since I had tried this a while ago but I can reproduce and explain it if its necessary). Q2: Is there a way to not replay output. I guess the solution I am looking for is to draw these presentations in the background (in a process maybe) and write to an output record. Then replay the output record on my window. This way, I have the output record I want. But it still takes a long time to draw these presentations. Ideally, I should just change the size of each and be done with it. (That way, I also retain those that are selected.) Your problem is (probably) that you don't erase old presentations, either "highlighted" or "non-highlighted". Replaying the window's history then results in replaying all flippings, which looks quite funny. Solution: Erase old, overwritten presentations. You can store them e.g. in a hash table, mapped on your application objects. Finally, the same program goes into a phase where the presentations are not mouse sensitive. Currently they are drawn inside a with output as presentation and used via a presentation to command traslator. Q3: Is there a way to remove (and add) a translator at run time (is this recommended by CLIM?). Why don't you use the :TESTER option to CLIM:DEFINE-PRESENTATION- TO-COMMAND-TRANSLATOR? You can test e.g. a special, boolean variable. Look up the doc for more info on testers. I am writing portable code and dont want to mess with low level stuff. If something is inthe"standard" (or not recommended) than I want to stay away from it for fear it wont be supported on all CLIMs. Should I be so (overly) cautious? We at Symbolics Systemhaus GmbH are writing large applications using CLIM. The portion of non-documented CLIM functions is quite near 0. like 0+. Markus Fischer, MF@SGER.UUCP Mergenthaler Allee 77-81 Consulting Services W-6236 Eschborn, Germany Symbolics Systemhaus GmbH Phone: +49 6196 47220, Fax 481116   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa06001; 2 Jul 92 10:17 EDT Received: by KARIBA.BBN.COM id aa04318; 2 Jul 92 10:06 EDT To: Philip Chu-Summer 92 cc: clim@BBN.COM Subject: Re: text-style-family returns number Date: Thu, 02 Jul 92 10:08:46 -0400 Message-ID: <190.710086126@bbn.com> From: Jeff Morrill Date: Wed, 1 Jul 92 17:06:23 PDT From: Philip Chu-Summer 92 To: SWM@stony-brook.scrc.symbolics.com Cc: clim@BBN.COM Subject: text-style-family returns number Thanks, CLIM::FACE-CODE->FACE solved my problem. I know that besides the fix for the abovementioned problem, CLIM::FORMAT-GRAPH-FROM-ROOTS didn't make it into the CLIM 1.1 release from Franz. Is there a publicly-available list of bug-fixes/enhancements made in CLIM 1.1? If there were, I could direct my queries to the guys at Franz on topics that have already been addressed on this list. Phil Chu Artificial Intelligence Research Branch NASA Ames Research Center pchu@ptolemy.arc.nasa.gov I already pressed them to cough up the new & improved clim grapher. Send mail to bugs@franz.com and ask for patch 3002. jeff morrill   Received: from BBN.COM by LABS-N.BBN.COM id aa09250; 2 Jul 92 15:37 EDT Received: from ptolemy-arclan.arc.nasa.gov by BBN.COM id aa03637; 2 Jul 92 15:33 EDT Received: from kepler.arc.nasa.gov by ptolemy.arc.nasa.gov (4.1/) id ; Thu, 2 Jul 92 12:30:53 PDT Date: Thu, 2 Jul 92 12:30:53 PDT From: Philip Chu-Summer 92 Message-Id: <9207021930.AA08720@ptolemy.arc.nasa.gov> Received: by kepler.arc.nasa.gov (4.1/SMI-4.1) id AA22493; Thu, 2 Jul 92 12:26:55 PDT To: clim@bbn.com Subject: fixed-size panes How do I specify that an :application or :accept-values pane be of fixed dimensions, like :pointer-documentation and :command-menu panes? Phil Chu Artificial Intelligence Research Branch NASA Ames Research Center pchu@ptolemy.arc.nasa.gov   Received: from BBN.COM by LABS-N.BBN.COM id aa11977; 6 Jul 92 11:53 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa13720; 6 Jul 92 11:41 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA19376; Mon, 6 Jul 92 08:41:24 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA00185; Mon, 6 Jul 92 08:34:14 PDT Date: Mon, 6 Jul 92 08:34:14 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9207061534.AA00185@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: Accept's input buffer editting manipulation I wish to have my own accept method complete the users input when he hits a return while in the middle of performing an inline edit on his input. Presently, if you do an (accept 'number) And the user enters -> 2034.45 But then does a meta-b and 3 control-b then a meta-d and enters 43 the input looks like -> 2043.45 with the text cursor at the decimal point. If the user hits a carriage return you only get 2043 from the accept. How can I get my accept method when it sees the carriage return to complete the input first so it would return 2043.45? Is there an easy way to do this?   Received: from BBN.COM by LABS-N.BBN.COM id aa13405; 6 Jul 92 13:40 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa18539; 6 Jul 92 13:34 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1103910; 6 Jul 1992 13:07:29-0400 Date: Mon, 6 Jul 1992 13:08-0400 From: Scott McKay Subject: Accept's input buffer editting manipulation To: curt@eraserhead.jpl.nasa.gov, clim@BBN.COM In-Reply-To: <9207061534.AA00185@eraserhead.Jpl.Nasa.Gov> Message-ID: <19920706170817.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 6 Jul 1992 11:34 EDT From: Curt Eggemeyer I wish to have my own accept method complete the users input when he hits a return while in the middle of performing an inline edit on his input. Presently, if you do an (accept 'number) And the user enters -> 2034.45 But then does a meta-b and 3 control-b then a meta-d and enters 43 the input looks like -> 2043.45 with the text cursor at the decimal point. If the user hits a carriage return you only get 2043 from the accept. How can I get my accept method when it sees the carriage return to complete the input first so it would return 2043.45? Is there an easy way to do this? I fixed this bug a while back, but don't presently have access to the patch file. Perhaps Jeff Morrill will forward the patch to you.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa14438; 6 Jul 92 14:48 EDT Received: by KARIBA.BBN.COM id aa08601; 6 Jul 92 14:37 EDT To: curt@eraserhead.jpl.nasa.gov, clim@BBN.COM Subject: Re: Accept's input buffer editting manipulation In-reply-to: Scott McKay's message of Mon, 06 Jul 92 13:08:00 -0400. <19920706170817.4.SWM@SUMMER.SCRC.Symbolics.COM> Reply-To: jmorrill@BBN.COM Date: Mon, 06 Jul 92 14:31:30 -0400 Message-ID: <552.710447490@bbn.com> From: Jeff Morrill Date: Mon, 6 Jul 1992 13:08-0400 From: Scott McKay Subject: Accept's input buffer editting manipulation To: curt@eraserhead.jpl.nasa.gov, clim@BBN.COM Date: Mon, 6 Jul 1992 11:34 EDT From: Curt Eggemeyer I wish to have my own accept method complete the users input when he hits a return while in the middle of performing an inline edit on his input. Presently, if you do an (accept 'number) And the user enters -> 2034.45 But then does a meta-b and 3 control-b then a meta-d and enters 43 the input looks like -> 2043.45 with the text cursor at the decimal point. If the user hits a carriage return you only get 2043 from the accept. How can I get my accept method when it sees the carriage return to complete the input first so it would return 2043.45? Is there an easy way to do this? I fixed this bug a while back, but don't presently have access to the patch file. Perhaps Jeff Morrill will forward the patch to you. I'll forward it to everybody. This is a set of patches to the input editor of CLIM 1.1. It's good stuff. -------- ;;; -*- Mode: LISP; Syntax: Common-Lisp; Package: CLIM; Base: 10; Patch-File: T -*- ;;; Patch file for Private version 0.0 ;;; Reason: Function (CLOS:METHOD CLIM::RESCAN-IF-NECESSARY (CLIM::INTERACTIVE-STREAM-MIXIN)): Merge ;;; this with RESCAN-FOR-ACTIVATION, and flush the latter. ;;; Function (METHOD STREAM-READ-GESTURE (INTERACTIVE-STREAM-MIXIN)): Inhibit activation rescans, ;;; reverse two clauses that could only ever have been buggy. ;;; Function CLIM:READ-TOKEN: Use RESCAN-IF-NECESSARY. ;;; Function CLIM:COMPLETE-INPUT: .. ;;; Function CLIM::SIMPLE-LISP-OBJECT-PARSER: .. ;;; Function (CLOS:METHOD CLIM::ACCEPT-METHOD (# T T T T CLIM:TEXTUAL-VIEW)): .. ;;; Macro DEFINE-INPUT-EDITOR-COMMAND: Make the default behavior be to queue a rescan, not do an ;;; immediate rescan. ;;; Recompile all the affected IE commands. ;;; Written by SWM, 4/23/92 11:26:44 ;;; while running on Zion from FEP0:>see-clim-8-1-1.load.1 ;;; with Genera 8.1.1, Logical Pathnames Translation Files NEWEST, CLIM 28.5, ;;; CLIM Demo 28.2, CLX 431.0, microcode 3640-FPA-MIC 430, FEP 127, ;;; FEP0:>v127-lisp.flod(64), FEP0:>v127-loaders.flod(64), FEP0:>v127-info.flod(64), ;;; FEP0:>v127-debug.flod(38), 1067x748 B&W Screen, Machine serial number 4001. (in-package :clim) (eval-when (compile load eval) (fmakunbound 'clim::rescan-if-necessary)) ;; Do a rescan if one is pending. ;; If it's an "activation" rescan, that means that the user typed an activation ;; character at some point, so this rescan should terminate all input. That's ;; why we set the insertion pointer to the end of the buffer... ;; In the cases where the program is maintaining another input buffer besides ;; the input editor's buffer, that buffer can get out of synch (for instance, ;; it could appear to be empty) because the user yanked something in and then ;; immediately hit . In that case, the yank commands have left a rescan ;; pending which we can take care of now. In general, any piece of code that ;; is maintaining an input buffer separate from the input editor's buffer should ;; call RESCAN-IF-NECESSARY before parsing any input. (defmethod rescan-if-necessary ((istream interactive-stream-mixin) &optional inhibit-activation) (with-slots (rescan-queued input-buffer insertion-pointer) istream (when rescan-queued (when (and (eql rescan-queued ':activation) (not inhibit-activation)) (setq insertion-pointer (fill-pointer input-buffer))) (setf rescan-queued nil) (throw 'rescan (values))))) #+genera (scl:fundefine '(method stream-read-gesture (interactive-stream-mixin))) (defmethod stream-read-gesture ((istream interactive-stream-mixin) &key timeout peek-p (input-wait-test *input-wait-test*) (input-wait-handler *input-wait-handler*) (pointer-button-press-handler *pointer-button-press-handler*)) (rescan-if-necessary istream t) (with-slots (stream input-buffer scan-pointer insertion-pointer activation-character rescanning-p numeric-argument previous-history) istream (declare (fixnum scan-pointer insertion-pointer)) (loop ;until a real gesture is read or we throw out ;; First look in the input-buffer of the input-editor and see ;; if there's something there. (loop (cond ((= scan-pointer insertion-pointer) (return)) ((< scan-pointer insertion-pointer) (let ((gesture (aref input-buffer scan-pointer))) (cond ((characterp gesture) (unless peek-p (incf scan-pointer)) (return-from stream-read-gesture (values gesture))) (t (incf scan-pointer))))) (t (return) ;; If the scan pointer is greater than the insertion pointer ;; then we'll definitely have to rescan if a character is typed ;; at this point. ))) ;; If we're about to go to the stream but there's an activation ;; character buffered, return it instead. (when activation-character (return-from stream-read-gesture (prog1 activation-character (unless peek-p (setf activation-character nil))))) ;;--- This is presumably much slower than necessary. ;;--- Perhaps there is a better way to keep track of where the cursor should be. (multiple-value-bind (x-pos y-pos) (input-buffer-input-position->cursor-position* istream insertion-pointer) (declare (fixnum x-pos y-pos)) (multiple-value-bind (cx cy) (stream-cursor-position* stream) (declare (fixnum cx cy)) ;; Don't set the cursor position if it's already right. ;; This prevents the input editor from scrolling the window after ;; the user has scrolled it back until the cursor position actually changes. (unless (and (= cx x-pos) (= cy y-pos)) (stream-set-cursor-position* stream x-pos y-pos)))) (setf rescanning-p nil) (multiple-value-bind (thing type) (let ((*accelerator-numeric-argument* (or numeric-argument 1)) (*accelerator-characters* ;; If there's anything in the input buffer, disallow accelerators (and (zerop (fill-pointer input-buffer)) *accelerator-characters*))) (stream-read-gesture stream :timeout timeout :peek-p peek-p :input-wait-test input-wait-test :input-wait-handler input-wait-handler :pointer-button-press-handler pointer-button-press-handler)) (cond ((eql type ':timeout) (return-from stream-read-gesture (values thing type))) (peek-p (return-from stream-read-gesture (values thing type))) (t (multiple-value-bind (new-thing new-type) ;; This can throw out in order to do rescans. ;; NEW-THING is a character, a presentation "blip", or NIL (interactive-stream-process-gesture istream thing type) (when (and (characterp new-thing) ;; Don't put things in the buffer that we can't echo later (ordinary-char-p new-thing) (not (activation-character-p new-thing))) (dotimes (i (or numeric-argument 1)) #-(or excl Minima) (declare (ignore i)) (cond ((< insertion-pointer (fill-pointer input-buffer)) (erase-input-buffer istream insertion-pointer) (setq input-buffer (shift-buffer-portion input-buffer insertion-pointer (1+ insertion-pointer))) (setf (aref input-buffer insertion-pointer) new-thing) (redraw-input-buffer istream insertion-pointer) (let ((rescan (> scan-pointer insertion-pointer))) (incf insertion-pointer) (if rescan (immediate-rescan istream) (setf scan-pointer insertion-pointer)))) (t (vector-push-extend new-thing input-buffer) (incf scan-pointer) (incf insertion-pointer) (when (ordinary-char-p new-thing) (write-char new-thing istream)))))) (when new-thing (setq numeric-argument nil previous-history nil) (cond ((activation-character-p new-thing) ;; If we got an activation character, we must first finish ;; scanning the input line, moving the insertion-pointer ;; to the end and finishing rescanning. Only then can we ;; return the activation character. (cond ((= insertion-pointer (fill-pointer input-buffer)) (return-from stream-read-gesture (values new-thing new-type))) (t (setf insertion-pointer (fill-pointer input-buffer)) (setf activation-character new-thing)))) ((or (not (characterp new-thing)) (ordinary-char-p new-thing)) ;; There might be some queued up rescans from destructive ;; input editing commands, so take care of them now (rescan-if-necessary istream t) (return-from stream-read-gesture (values new-thing new-type))) (t ;; Some input editing doesn't throw, and should not ;; cause us to return just yet, since IE commands don't ;; count as real gestures. (beep istream))))))))))) ;; READ-TOKEN reads characters until it encounters an activation character, ;; a blip character, or something else (like a mouse click). (defun read-token (stream &key input-wait-handler pointer-button-press-handler click-only timeout) (with-temporary-string (string :length 50 :adjustable t) (let* ((gesture nil) (gesture-type nil) (quote-seen nil) (old-blip-chars *blip-characters*) (*blip-characters* *blip-characters*)) (flet ((return-token (&optional unread) (when unread (unread-gesture unread :stream stream)) (when (and (activation-character-p unread) (interactive-stream-p stream)) (rescan-if-necessary stream)) (return-from read-token (values (evacuate-temporary-string string))))) (loop (multiple-value-setq (gesture gesture-type) (read-gesture :stream stream :input-wait-handler (or input-wait-handler *input-wait-handler*) :pointer-button-press-handler (or pointer-button-press-handler *pointer-button-press-handler*) :timeout (and click-only timeout))) (cond ((eql gesture-type :timeout) (return-from read-token :timeout)) ((and click-only (not (typep gesture 'pointer-button-event))) (beep stream)) ((typep gesture 'pointer-button-event) ;; No need to do anything, since this should have been handled ;; in the presentation type system already ) ((characterp gesture) (cond ((and (zerop (fill-pointer string)) (eql gesture *quotation-character*)) (setq quote-seen t) (setq *blip-characters* nil)) ((and quote-seen (eql gesture *quotation-character*)) (setq quote-seen nil) (setq *blip-characters* old-blip-chars)) ((activation-character-p gesture) (return-token gesture)) ((blip-character-p gesture) ;; ditto? (return-token gesture)) ((ordinary-char-p gesture) (vector-push-extend gesture string) ;;--- haven't updated WRITE-CHAR yet #+ignore (write-char gesture stream)) (t (beep stream)))) (t (return-token gesture)))))))) (defun complete-input (stream function &key partial-completers allow-any-input possibility-printer (help-displays-possibilities t)) (declare (dynamic-extent function)) (declare (values answer-object success string)) (with-temporary-string (stuff-so-far :length 100 :adjustable t) (with-blip-characters (partial-completers) (with-activation-characters (*magic-completion-characters*) (flet ((completion-help (stream action string-so-far) (declare (ignore string-so-far)) (display-completion-possibilities stream function stuff-so-far :possibility-printer possibility-printer :display-possibilities (or (eql action :possibilities) (and (eql action :help) help-displays-possibilities))))) (declare (dynamic-extent #'completion-help)) (with-accept-help ((:subhelp #'completion-help)) ;; Keep the input editor from handling help and possibilities characters. ;; They will get treated as activation characters, thus ensuring that ;; STUFF-SO-FAR will be accurate when we display the possibilities. (let ((*ie-help-enabled* nil) (location (input-position stream)) token ch unread return extend completion-mode completion-type answer-object) (flet ((ends-in-char-p (string char) (let ((sl (length string))) (and (plusp sl) (char-equal (aref string (1- sl)) char))))) (declare (dynamic-extent #'ends-in-char-p)) (loop ;; Maybe these, as well as TOKEN and CH should be LET inside the loop... (setq unread nil return nil extend nil) (setq token (read-token stream)) (setq ch (read-gesture :stream stream)) ;don't care about wait functions (extend-vector stuff-so-far token) (cond ((null ch) (error "Null ch?")) ((characterp ch) (cond ((member ch *help-characters*) (setq completion-mode ':help)) ((member ch *possibilities-characters*) (setq completion-mode ':possibilities)) ((member ch *complete-characters*) (setq completion-mode ':complete-maximal)) ((member ch partial-completers :test #'char-equal) (setq completion-mode ':complete-limited unread t extend t return 'if-completed)) ;; What about "overloaded" partial completers?? ((blip-character-p ch) (setq completion-mode (if allow-any-input nil ':complete) unread t extend t return t)) ((activation-character-p ch) (setq completion-mode (if allow-any-input nil ':complete) unread t return t)))) ((eq ch ':eof) (setq completion-mode (if allow-any-input nil ':complete) return t)) (t ;mouse click? (beep stream))) ;; OK, this is a SPECIAL case. We check to see if the null string ;; was read, and if so, we signal a parse-error (because ACCEPT ;; handles this specially) so that the default value will be filled ;; in by ACCEPT. ;; There is a tension here between wanting to fill in the default and ;; use the maximal left substring when the user types #\End or a field ;; terminator that also does completion. Putting this check before the ;; completion code means that the default always wins. (when (and return (zerop (fill-pointer stuff-so-far))) (when unread (unread-gesture ch :stream stream)) (when (interactive-stream-p stream) (rescan-if-necessary stream)) (simple-parse-error "Attempting to complete the null string")) (cond ((or (eql completion-mode ':help) (eql completion-mode ':possibilities)) ;; Since we've asked the input editor not to do this, ;; we must do it here ourselves (display-accept-help stream completion-mode "") (setq completion-type nil)) (completion-mode (multiple-value-bind (string success object nmatches) (funcall function stuff-so-far completion-mode) (setq answer-object object) (cond ((= nmatches 0) ;; no valid completion, so no replace input (setq completion-type 'invalid) (when extend (vector-push-extend ch stuff-so-far))) ((= nmatches 1) (setq completion-type (if success 'unique 'ambiguous)) ;; replace contents of stuff-so-far with completion (setf (fill-pointer stuff-so-far) 0) (extend-vector stuff-so-far string) ) ((> nmatches 1) (setq completion-type 'ambiguous) ;; replace contents of stuff-so-far with completion (setf (fill-pointer stuff-so-far) 0) (extend-vector stuff-so-far string) ;; need-to-add-delimiter test?? (when (and extend (not (ends-in-char-p string ch))) (vector-push-extend ch stuff-so-far))))))) ;; Check for errors unconditionally, remembering that we may not have ;; called the completer at all (completion-type = NIL) (ecase completion-type ((nil unique left-substring)) ; no possible errors to report (invalid (unless allow-any-input (when unread (unread-gesture ch :stream stream)) (simple-parse-error "Invalid completion: ~A" stuff-so-far))) (ambiguous ;; only beep on ambiguous full completions, in either ALLOW-ANY-INPUT mode (when (eq completion-mode :complete) (beep stream)))) (when (eq return 'if-completed) (unless (eq completion-type 'unique) (setq return nil))) ;; Decide whether or not to return, remembering that ;; we might have called the completer. (when return (when (or (member completion-type '(nil unique left-substring)) allow-any-input) ;; leave the last delimiter for our caller (when unread (unread-gesture ch :stream stream)) ;; Must replace-input after unread-gesture so the delimiter is unread ;; into the input editor's buffer, not the underlying stream's buffer (unless (rescanning-p stream) (replace-input stream stuff-so-far :buffer-start location)) (return-from complete-input (values answer-object t (evacuate-temporary-string stuff-so-far))))) ;; Not returning yet, but update the input editor's buffer anyway (unless (rescanning-p stream) (replace-input stream stuff-so-far :buffer-start location))))))))))) (defun simple-lisp-object-parser (type stream &optional coerce-test coerce-function) (loop (let ((token (read-token stream))) (when (interactive-stream-p stream) (rescan-if-necessary stream)) (multiple-value-bind (object index) (let ((*read-eval* nil)) ;disable "#." (read-from-string token nil token)) (when (eq object token) (simple-parse-error "Unexpected EOF")) ;; Too bad read-from-string doesn't take a :junk-allowed argument ;; Simulate what it would do (unless (>= index (length token)) (when (find-if-not #'whitespace-character-p token :start index) (simple-parse-error "Extra junk ~S found after the ~A." (subseq token index) (describe-presentation-type type nil nil)))) (when (presentation-typep object type) (return-from simple-lisp-object-parser (values object type))) (when coerce-function (when (funcall coerce-test object) (setq object (funcall coerce-function object)) (when (presentation-typep object type) (return-from simple-lisp-object-parser (values object type))))) (input-not-of-required-type token type))))) (define-presentation-method accept ((type expression) stream (view textual-view) &key) (let ((*read-recursive-objects* nil)) (with-temporary-string (string) (read-recursive stream string nil) (when (interactive-stream-p stream) (rescan-if-necessary stream)) (multiple-value-bind (expression index) (read-from-string string nil string) (when (eq expression string) (simple-parse-error "The input ~S is not a complete Lisp expression." (evacuate-temporary-string string))) ;; Too bad READ-FROM-STRING doesn't take a :JUNK-ALLOWED argument. ;; Simulate what it would do (unless (>= index (length string)) (when (find-if-not #'whitespace-character-p string :start index) (simple-parse-error "Extra junk ~S found after the expression." (subseq string index)))) expression)))) (defmacro define-input-editor-command ((name &key (rescan T) (type 'motion) history) arglist &body body) (multiple-value-bind (arglist ignores) (canonicalize-and-match-lambda-lists *ie-command-arglist* arglist) (let ((stream (first arglist))) `(define-group ,name define-input-editor-command (defun ,name ,arglist ,@(and ignores `((declare (ignore ,@ignores)))) ,@body (setf (slot-value ,stream 'last-command-type) ',type) ,@(unless history `((setf (slot-value ,stream 'previous-history) nil))) ,@(ecase rescan ((t) `((queue-rescan ,stream))) (:immediate `((immediate-rescan ,stream))) ((nil) nil)) (values)))))) (define-input-editor-command (com-ie-rubout :type delete) (stream input-buffer numeric-argument) (ie-rub-del stream input-buffer (- numeric-argument))) (define-input-editor-command (com-ie-delete-character :type delete) (stream input-buffer numeric-argument) (ie-rub-del stream input-buffer numeric-argument)) (define-input-editor-command (com-ie-rubout-word :type kill) (stream input-buffer numeric-argument) (ie-rub-del-word stream input-buffer (- numeric-argument))) (define-input-editor-command (com-ie-delete-word :type kill) (stream input-buffer numeric-argument) (ie-rub-del-word stream input-buffer numeric-argument)) (define-input-editor-command (com-ie-clear-input :type kill) (stream input-buffer) ;; Just push a copy of the input buffer onto the kill ring, no merging (ie-kill stream input-buffer t 0 (fill-pointer input-buffer))) (define-input-editor-command (com-ie-kill-line :type kill) (stream input-buffer numeric-argument) (let* ((reverse-p (minusp numeric-argument)) (point (insertion-pointer stream)) (other-point (if reverse-p (ie-line-start input-buffer point) (ie-line-end input-buffer point)))) (ie-kill stream input-buffer (if (eql (slot-value stream 'last-command-type) 'kill) :merge t) point other-point reverse-p))) (define-input-editor-command (com-ie-make-room) (stream input-buffer) (let ((point (insertion-pointer stream)) (end (fill-pointer input-buffer))) (cond ((= point end) (incf (fill-pointer input-buffer))) (t (erase-input-buffer stream point) (shift-buffer-portion input-buffer point (1+ point)))) (setf (aref input-buffer point) #\Newline) (redraw-input-buffer stream point))) (define-input-editor-command (com-ie-transpose-characters) (stream input-buffer) (let* ((start-position (min (1+ (insertion-pointer stream)) (fill-pointer input-buffer))) (this-position (forward-or-backward input-buffer start-position t #'true)) (prev-position (forward-or-backward input-buffer this-position t #'true))) (cond ((and this-position prev-position (/= this-position prev-position)) (let ((this-char (aref input-buffer this-position)) (prev-char (aref input-buffer prev-position))) (erase-input-buffer stream prev-position) (setf (aref input-buffer prev-position) this-char) (setf (aref input-buffer this-position) prev-char) (redraw-input-buffer stream prev-position))) (t (beep stream))))) (defun ie-kill (stream input-buffer kill-ring start end &optional reverse) (when (< end start) (rotatef start end)) (when kill-ring (let* ((top (and (eql kill-ring ':merge) (eql *kill-ring-application* *application-frame*) (history-top-element *kill-ring*))) (length (if top (length top) 0))) (setq *kill-ring-application* *application-frame*) (do-input-buffer-pieces (input-buffer :start start :end end) (start end noise-string) :normal (incf length (- end start)) :noise-string (incf length (length (noise-string-display-string noise-string)))) (let ((new-top (make-string length)) (index 0)) (when top (cond (reverse ;; Even when we're deleting backwards, we want to merge the ;; kills so they come out in the original order (replace new-top top :start1 (- length (length top))) (setq index 0)) (t (replace new-top top) (setq index (length top))))) (do-input-buffer-pieces (input-buffer :start start :end end) (start end noise-string) :normal (replace new-top input-buffer :start1 index :end1 (incf index (- end start)) :start2 start :end2 end) :noise-string (let ((string (noise-string-display-string noise-string))) (replace new-top string :start1 index :end1 (incf index (length string))))) (cond (top (setf (history-top-element *kill-ring*) new-top) #+Genera (genera-kill-ring-save new-top t)) (t (push-history-element *kill-ring* new-top) #+Genera (genera-kill-ring-save new-top nil)))))) ;; Erase what used to be there, side effect the input buffer, then redraw it (erase-input-buffer stream start) (if end (shift-buffer-portion input-buffer end start) (setf (fill-pointer input-buffer) start)) ;; The insertion-pointer started out at either start or end, they're the same now (setf (insertion-pointer stream) start) ;; Make sure the scan pointer doesn't point past the insertion pointer (MINF (INPUT-POSITION STREAM) (INSERTION-POINTER STREAM)) (redraw-input-buffer stream) ;; This can be called in a loop, so reflect the kill operation now (setf (slot-value stream 'last-command-type) 'kill))   Received: from BBN.COM by LABS-N.BBN.COM id aa13969; 6 Jul 92 14:13 EDT Received: from cs.utexas.edu by BBN.COM id aa20184; 6 Jul 92 14:08 EDT Received: from sage.cs.utexas.edu by cs.utexas.edu (5.64/1.132) with SMTP id AA28137; Mon, 6 Jul 92 13:08:17 -0500 Received: by sage.cs.utexas.edu (5.64/Client-v1.3) id AA18450; Mon, 6 Jul 92 13:08:10 -0500 Message-Id: <9207061808.AA18450@sage.cs.utexas.edu> From: eilerts@cs.utexas.edu (Erik Eilerts) Date: Mon, 6 Jul 1992 13:08:09 -0500 X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: clim@bbn.com Subject: Accepting-values question Cc: eilerts@cs.utexas.edu I am using accepting-values menus that have 2 or more fields. What I currently do is to end input in one of the fields, move the mouse over the next field, and then click the mouse to start editing. What I'd rather do is to type keystroke (such as Control-n), which would move me from my most recently edited field to the next field below it and open the field for input. That way, I wouldn't have to spend time switching between the keyboard and mouse. Does anyone know if this is possible? Thanks, Erik Eilerts University of Texas at Austin eilerts@cs.utexas.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa14698; 6 Jul 92 15:00 EDT Received: from mail.Germany.EU.net by BBN.COM id aa22375; 6 Jul 92 14:47 EDT Received: from sger by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA16353; Mon, 6 Jul 92 19:14:00 +0200 Received: from FUJI-SAN.SGER.UUCP ([192.1.2.67]) by sger.SGER.COM (4.1/SMI-4.1) id AA19345; Mon, 6 Jul 92 18:41:36 +0200 Date: Mon, 6 Jul 1992 18:55+0100 From: Markus Fischer Reply-To: mf@sger.uucp Subject: Why doesn't this work? To: oli@adler.ims.uni-stuttgart.de Cc: clim@bbn.com In-Reply-To: <9207011128.AA02462@adler.ims.uni-stuttgart.de> Message-Id: <19920706175537.5.MF@FUJI-SAN.SGER.UUCP> Date: Wed, 1 Jul 1992 12:28+0100 From: Oliver Christ [Lucid Lisp with CLIM 1.0 Beta] To let the user select an object of type 'dag-node (my own class) or to select nothing, I would expect the following to work: (defun read-node (stream) (clim:with-input-context ('(or clim:blank-area dag-node)) (node) (read) (dag-node node) (clim:blank-area nil))) but it doesn't. Of course, the user may select a dag-node, but clicks on the blank area of the pane aren't recognized. Why? Thanks, Oli This seems to be a bug even in CLIM 1.1, but (accept 'blank-area) works perfectly. Markus Fischer, MF@SGER.UUCP Mergenthaler Allee 77-81 Consulting Services W-6236 Eschborn, Germany Symbolics Systemhaus GmbH Phone: +49 6196 47220, Fax 481116   Received: from BBN.COM by LABS-N.BBN.COM id aa16509; 6 Jul 92 17:22 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa01600; 6 Jul 92 17:18 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AB04317; Mon, 6 Jul 92 14:18:24 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA00373; Mon, 6 Jul 92 14:11:13 PDT Date: Mon, 6 Jul 92 14:11:13 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9207062111.AA00373@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: accept-from-string within accept methods I can't seem to get accept-from-string calls within my accept method to work in cases where I do a regular accept. If I do an accept-from-string call my accept method will work. It seems that there is a stream sharing going on between the accept method and my accept-from-string calls within it, because my accept-from-string always gets passed nil even though I am passing a substring of what I got from the read-token. How can one get around this problem?   Received: from BBN.COM by LABS-N.BBN.COM id aa16152; 6 Jul 92 16:52 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa29493; 6 Jul 92 16:42 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1104062; 6 Jul 1992 16:44:13-0400 Date: Mon, 6 Jul 1992 16:45-0400 From: Scott McKay Subject: Accepting-values question To: eilerts@cs.utexas.edu, clim@BBN.COM In-Reply-To: <9207061808.AA18450@sage.cs.utexas.edu> Message-ID: <19920706204504.9.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 6 Jul 1992 14:08 EDT From: Erik Eilerts I am using accepting-values menus that have 2 or more fields. What I currently do is to end input in one of the fields, move the mouse over the next field, and then click the mouse to start editing. What I'd rather do is to type keystroke (such as Control-n), which would move me from my most recently edited field to the next field below it and open the field for input. That way, I wouldn't have to spend time switching between the keyboard and mouse. Does anyone know if this is possible? This is partially implemented in ACCEPTING-VALUES for Genera. I decided it was not worth finishing since there are so many other things to do.   Received: from BBN.COM by LABS-N.BBN.COM id aa00703; 7 Jul 92 16:25 EDT Received: from [129.197.134.99] by BBN.COM id aa02997; 7 Jul 92 16:19 EDT Received: from jade.rdd.lmsc.lockheed.com by dipl.rdd.lmsc.lockheed.com (4.0/SMI-4.1) id AA16587; Tue, 7 Jul 92 13:23:38 PDT Received: from cluso.lmsc.com by jade.rdd.lmsc.lockheed.com (4.1/SMI-4.0) id AA08435; Tue, 7 Jul 92 13:20:13 PDT Date: Tue, 7 Jul 92 13:20:13 PDT From: ttrinko@dipl.rdd.lmsc.lockheed.com (Tom Trinko) Message-Id: <9207072020.AA08435@jade.rdd.lmsc.lockheed.com> To: clim@bbn.com Subject: menus and commands I'm using CLIM 1.1, common lisp, and Genera 8.1.1 but I think these are generic CLIM questions. 1) I have a popup menu associated with presentation objects. I use the define presentation action command which in turn calls the call-presentation-menu command. This works fine except the list of commands doesn't appear to be alphabetized. I have added the :after :sort options to some, but not all of the commands that appear in the popup menu. The commands with the :after :sort don't seem to appear in alphabetical order. What am I doing wrong? 2) we have several panes that contain command menus. we use the display-command-menu as the display function. some of the commands in the command-menu have menu's associated with them. I'd like to be able to associate some of the commands in the menu's that popup with the top level command. for example the command pane might look like this command 1 command 2 command 3 when you click on command 2 you get a menu with entries command 1-1 command 1-2 command 1-3 what I'd like to do is associate command 1-3 with the top level command 2 so that when the user moves the mouse over command 2 and clicks say shift mouse middle command 1-3 is executed. in dw we used define-command-menu-handler to get this behavior. Thanks for any help. I'd especially appreciate code samples.   Received: from BBN.COM by LABS-N.BBN.COM id aa01813; 7 Jul 92 17:55 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa07141; 7 Jul 92 17:46 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1104793; 7 Jul 1992 17:48:00-0400 Date: Tue, 7 Jul 1992 17:48-0400 From: Scott McKay Subject: menus and commands To: ttrinko@dipl.rdd.lmsc.lockheed.com, clim@BBN.COM In-Reply-To: <9207072020.AA08435@jade.rdd.lmsc.lockheed.com> Message-ID: <19920707214858.5.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 7 Jul 1992 16:20 EDT From: Tom Trinko I'm using CLIM 1.1, common lisp, and Genera 8.1.1 but I think these are generic CLIM questions. 1) I have a popup menu associated with presentation objects. I use the define presentation action command which in turn calls the call-presentation-menu command. This works fine except the list of commands doesn't appear to be alphabetized. I have added the :after :sort options to some, but not all of the commands that appear in the popup menu. The commands with the :after :sort don't seem to appear in alphabetical order. What am I doing wrong? :AFTER :SORT affects command menus, not menus of presentation translators. CALL-PRESENTATION-MENU could certainly sort the translators it comes up with, maybe based on the command names. I've included the source below for you to hack on. 2) we have several panes that contain command menus. we use the display-command-menu as the display function. some of the commands in the command-menu have menu's associated with them. I'd like to be able to associate some of the commands in the menu's that popup with the top level command. for example the command pane might look like this command 1 command 2 command 3 when you click on command 2 you get a menu with entries command 1-1 command 1-2 command 1-3 what I'd like to do is associate command 1-3 with the top level command 2 so that when the user moves the mouse over command 2 and clicks say shift mouse middle command 1-3 is executed. in dw we used define-command-menu-handler to get this behavior. Thanks for any help. I'd especially appreciate code samples. I used the following code for a hack I was working on. I think it will work in CLIM 1.1, but I did not test it again to make sure. It does not presently get the mouse doc line right, either. No warranties expressed or implied. -------- command menu handlers -------- ;;; -*- Mode: LISP; Syntax: Common-Lisp; Package: CLIM; Base: 10; Lowercase: Yes -*- (in-package "CLIM") (eval-when (compile load eval) (export '(clim::define-command-menu-handlers) 'clim)) ;; Defines a command menu item named MENU-NAME (a string) in the command table ;; COMMAND-TABLE that has multiple "handlers". HANDLER-NAME is a symbol that ;; names the handler. Each of the clauses in HANDLERS is a list of the FORM ;; (GESTURE-NAME COMMAND). (defmacro define-command-menu-handlers (menu-name handler-name command-table &body handlers) `(progn (defun ,handler-name (event numeric-arg) (declare (ignore numeric-arg)) (typecase event (null ;;--- We really want to compute all the pointer documentation here, ;;--- but CLIM just can't manage that right now, because things like ;;--- FIND-INNERMOST-APPLICABLE-PRESENTATION do not pass along the ;;--- event (or shift mask) argument uniformly when we are running ;;--- to compute documentation. ',(second (first handlers))) (pointer-button-press-event (cond ,@(mapcar #'(lambda (h) `((button-press-event-matches-gesture-name event ',(first h)) ',(second h))) handlers))))) (add-menu-item-to-command-table ',command-table ,menu-name :function ',handler-name :errorp nil))) ;;--- Adding :GESTURE T to these has the unpleasant side-effects that ;;--- the :MENU gesture stops working for command menu items. (define-presentation-translator command-menu-element-to-command (command-menu-element command global-command-table :gesture t :tester ((object event) (let* ((menu-item (third object)) (type (command-menu-item-type menu-item))) (and (or (eql type ':command) (eql type ':function)) (command-enabled-p (command-name (extract-command-menu-item-value menu-item event)) *application-frame*)))) :tester-definitive t ;; The pointer-documentation uses this, too :documentation ((object presentation context-type frame event window x y stream) (let ((documentation (getf (command-menu-item-options (third object)) :documentation))) (if documentation (write-string documentation stream) (document-presentation-to-command-translator (find-presentation-translator 'command-menu-element-to-command 'global-command-table) presentation context-type frame event window x y stream))))) (object event) (extract-command-menu-item-value (third object) event)) (define-presentation-translator command-menu-element-to-sub-menu (command-menu-element command global-command-table :gesture t :tester ((object) (let ((menu-item (third object))) (and (eql (command-menu-item-type menu-item) ':menu) (let ((comtab (find-command-table (command-menu-item-value menu-item) :errorp nil))) (and comtab (slot-value comtab 'menu) ;; You might think that including the following in the ;; tester is reasonable (that is, make the translator ;; applicable only if the context's command table inherits ;; from the command table that this menu item points to.) ;; Unfortunately, that doesn't work because command table ;; inheritance isn't the only way to get something into a ;; command table. The only alternative is to recursively ;; walk over the sub-menu(s) to see if at least one command ;; is applicable. #+++ignore (with-presentation-type-parameters (command context-type) (command-table-presentation-subtypep command-table comtab))))))) :tester-definitive t ;; The pointer-documentation uses this, too :documentation ((object stream) (write-string (first object) stream) (write-char #\Space stream) (write-string "Menu" stream))) (object window) (values (menu-execute-command-from-command-table (command-menu-item-value (third object)) :associated-window window :cache t))) -------- hack this to sort presentation menus -------- ;;; -*- Mode: LISP; Syntax: Common-Lisp; Package: CLIM; Base: 10; Lowercase: Yes -*- (in-package "CLIM") (defun call-presentation-menu (presentation input-context frame window x y &key (for-menu t) label) (let* ((translators (find-applicable-translators presentation input-context frame window x y :event nil :for-menu for-menu)) ;; Yecch. The problem is each "translator stuff" is a list, which ;; is indistinguishable from the item syntax. Oh well, we're already ;; consing up stuff already... (item-list (and translators (map 'list #'(lambda (thing) (list thing :value thing)) translators)))) (when translators ;just in case... (flet ((translator-documentation (translator-stuff stream) (setq translator-stuff (menu-item-value translator-stuff)) (let* ((translator (pop translator-stuff)) (presentation (pop translator-stuff)) (context-type (pop translator-stuff))) (document-presentation-translator translator presentation context-type frame nil window x y :stream stream ;; Run the body if need be :documentation-type :from-body)))) (declare (dynamic-extent #'translator-documentation)) (let ((chosen (menu-choose item-list :associated-window window :label label :printer #'translator-documentation))) (when chosen ;; Anticipate the day when we can move the mouse off the menu (let* ((translator (pop chosen)) (presentation (pop chosen)) (context-type (pop chosen)) (tag (pop chosen))) (multiple-value-bind (translated-object translated-type options) (call-presentation-translator translator presentation context-type frame nil window x y) (throw tag (values translated-object (or translated-type context-type) nil ;would be an event... options))))))))))   Received: from BBN.COM by LABS-N.BBN.COM id aa02821; 7 Jul 92 19:36 EDT Received: from charon.arc.nasa.gov by BBN.COM id aa09650; 7 Jul 92 19:32 EDT Received: from HALEAKALA.arc.nasa.gov by CHARON.arc.nasa.gov via INTERNET with SMTP id 129841; 7 Jul 1992 16:30:57-0700 Date: Tue, 7 Jul 1992 16:30-0700 From: will taylor Subject: Standalone Windows Resource? To: clim@bbn.com cc: taylor@CHARON.arc.nasa.gov Message-ID: <19920707233051.6.TAYLOR@HALEAKALA.arc.nasa.gov> I am using CLIM 1.0 (27.5) under Genera 8.1.1 I would like to pop-up a window over my application frame which has :scroll-bars :both and whose size I can determine. I can use OPEN-WINDOW-STREAM & WINDOW-EXPOSE to display the window. But if I want it to appear under the cursor I need to be able to move its location and re-size it OR be able to return the window to the "window-resource" and then create a new one with the size and location I desire. I guess what I am looking for is a window analog to WITH-MENU & MENU-CHOSE-FROM-DRAWER which has both scroll bars and gives me control over its size. Anyone know how to do something like this. Thanks - Will Taylor   Received: from BBN.COM by LABS-N.BBN.COM id aa12314; 8 Jul 92 9:41 EDT Received: from [129.197.134.99] by BBN.COM id aa26068; 8 Jul 92 9:34 EDT Received: from jade.rdd.lmsc.lockheed.com by dipl.rdd.lmsc.lockheed.com (4.0/SMI-4.1) id AA18227; Wed, 8 Jul 92 06:38:05 PDT Received: from cluso.lmsc.com by jade.rdd.lmsc.lockheed.com (4.1/SMI-4.0) id AA14966; Wed, 8 Jul 92 06:34:37 PDT Date: Wed, 8 Jul 92 06:34:37 PDT From: ttrinko@dipl.rdd.lmsc.lockheed.com (Tom Trinko) Message-Id: <9207081334.AA14966@jade.rdd.lmsc.lockheed.com> To: clim@bbn.com Subject: RE: Common Lisp window standards I wouldn't recommend changing CLIM by basing it on Bedrock but it would be nice if CLIM 2.0 supported the "look" of Bedrock, if Bedrock has a distinct "look", just as its supposed to support Motif, open look etc.   Received: from BBN.COM by LABS-N.BBN.COM id aa13147; 8 Jul 92 9:53 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa26631; 8 Jul 92 9:43 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1105139; 8 Jul 1992 09:45:16-0400 Date: Wed, 8 Jul 1992 09:46-0400 From: Scott McKay Subject: RE: Common Lisp window standards To: pierce@at-mail-server.vitro.com, clim@BBN.COM In-Reply-To: The message of 7 Jul 1992 20:40 EDT from pierce Message-ID: <19920708134619.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 7 Jul 1992 20:40 EDT From: pierce Do any current or potential CLIM implementors who are familiar with Bedrock have an opinion regarding whether a future version of CLIM should or should not be based on Bedrock for the Macintosh or other platforms? To the best of my knowledge, no CLIM implementors are familiar with Bedrock except at the most superficial level. If you have any way to get more information to me, I could give a meaningful opinion. Dave Moon sent me some small amount of information which is enough to start me thinking, but not enough for me to say much.   Received: from BBN.COM by LABS-N.BBN.COM id aa09402; 8 Jul 92 8:48 EDT Received: from at-mail-server.vitro.com by BBN.COM id aa23250; 8 Jul 92 8:39 EDT Date: 8 Jul 92 08:40:44 U From: "pierce" Subject: RE: Common Lisp window standards To: clim@bbn.com Do any current or potential CLIM implementors who are familiar with Bedrock have an opinion regarding whether a future version of CLIM should or should not be based on Bedrock for the Macintosh or other platforms? -Jonathan   Received: from BBN.COM by LABS-N.BBN.COM id aa11648; 8 Jul 92 9:35 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa25507; 8 Jul 92 9:24 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1105127; 8 Jul 1992 09:26:22-0400 Date: Wed, 8 Jul 1992 09:27-0400 From: Scott McKay Subject: Standalone Windows Resource? To: taylor@charon.arc.nasa.gov, clim@BBN.COM In-Reply-To: <19920707233051.6.TAYLOR@HALEAKALA.arc.nasa.gov> Message-ID: <19920708132723.9.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 7 Jul 1992 19:30 EDT From: will taylor I am using CLIM 1.0 (27.5) under Genera 8.1.1 I would like to pop-up a window over my application frame which has :scroll-bars :both and whose size I can determine. I can use OPEN-WINDOW-STREAM & WINDOW-EXPOSE to display the window. But if I want it to appear under the cursor I need to be able to move its location and re-size it OR be able to return the window to the "window-resource" and then create a new one with the size and location I desire. I guess what I am looking for is a window analog to WITH-MENU & MENU-CHOSE-FROM-DRAWER which has both scroll bars and gives me control over its size. Anyone know how to do something like this. Here is what CLIM uses to define WITH-MENU resources: (defresource menu (associated-window root) :constructor (open-window-stream :parent root ;"random" size :left 100 :top 100 :width 300 :height 200 :scroll-bars ':vertical :window-class (menu-class-name root) :save-under T) :initializer (initialize-menu menu associated-window) :deinitializer (progn (setf (window-visibility menu) nil) (window-clear menu) (setf (window-label menu) nil)) :matcher (eql (window-parent menu) root)) (defmacro with-menu ((menu &optional (associated-window nil aw-p)) &body body) (let ((window '#:associated-window)) `(let ((,window ,(if aw-p associated-window `(frame-top-level-window *application-frame*)))) ;once-only (using-resource (,menu menu (window-top-level-window ,window) (window-root ,window)) (letf-globally (((stream-default-view ,menu) +menu-view+)) ,@body))))) You can call the two (internal) functions SIZE-MENU-APPROPRIATELY (which computes the size based on what is in the output history) and POSITION-WINDOW-NEAR-CAREFULLY to set the size and position of the window once you have gooten it from the resource. The typical thing to do is (in this order): - allocate a window from the resource - compute its contents - call CLIM::SIZE-MENU-APPROPRIATELY - call CLIM::POSITION-WINDOW-NEAR-CAREFULLY - call WINDOW-EXPOSE   Received: from BBN.COM by LABS-N.bbn.COM id aa16181; 8 Jul 92 12:49 EDT Received: from mail.germany.eu.net by BBN.COM id aa04910; 8 Jul 92 12:41 EDT Received: from sger by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA22215; Wed, 8 Jul 92 18:41:36 +0200 Received: from FUJI-SAN.SGER.UUCP ([192.109.230.67]) by sger.SGER.COM (4.1/SMI-4.1) id AA00303; Wed, 8 Jul 92 18:12:02 +0200 Date: Wed, 8 Jul 1992 18:11+0100 From: Markus Fischer Reply-To: mf@sger.uucp Subject: Standalone Windows Resource? To: taylor@charon.arc.nasa.gov, clim@BBN.COM Cc: taylor@charon.arc.nasa.gov In-Reply-To: <19920707233051.6.TAYLOR@HALEAKALA.arc.nasa.gov> Message-Id: <19920708171100.1.MF@FUJI-SAN.SGER.UUCP> Date: Wed, 8 Jul 1992 00:30+0100 From: will taylor I am using CLIM 1.0 (27.5) under Genera 8.1.1 I would like to pop-up a window over my application frame which has :scroll-bars :both and whose size I can determine. I can use OPEN-WINDOW-STREAM & WINDOW-EXPOSE to display the window. But if I want it to appear under the cursor I need to be able to move its location and re-size it OR be able to return the window to the "window-resource" and then create a new one with the size and location I desire. I guess what I am looking for is a window analog to WITH-MENU & MENU-CHOSE-FROM-DRAWER which has both scroll bars and gives me control over its size. Anyone know how to do something like this. Even in 1.0 you should have the functions CLIM:WINDOW-SET-INSIDE-SIZE and CLIM:WINDOW-SET-INSIDE-EDGES. These size and position windows. Note the the edge coordinates in CLIM:WINDOW-SET-INSIDE-EDGES are relative to the window's parent. Also, don't forget to provide :save-under T to CLIM:OPEN-WINDOW-STREAM. I hope that helps a bit. Markus Fischer, MF@SGER.UUCP Mergenthaler Allee 77-81 Consulting Services W-6236 Eschborn, Germany Symbolics Systemhaus GmbH Phone: +49 6196 47220, Fax 481116   Received: from BBN.COM by LABS-N.bbn.COM id aa15847; 8 Jul 92 12:22 EDT Received: from mail.germany.eu.net by BBN.COM id aa03865; 8 Jul 92 12:13 EDT Received: from sger by mail.Germany.EU.net with UUCP (5.65+/UNIDO-2.1.0.b) via EUnet for bbn.com id AA19877; Wed, 8 Jul 92 18:11:49 +0200 Received: from FUJI-SAN.SGER.UUCP ([192.109.230.67]) by sger.SGER.COM (4.1/SMI-4.1) id AA00234; Wed, 8 Jul 92 17:55:59 +0200 Date: Wed, 8 Jul 1992 17:54+0100 From: Markus Fischer Reply-To: mf@sger.uucp Subject: accept-from-string within accept methods To: curt@eraserhead.jpl.nasa.gov, clim@BBN.COM In-Reply-To: <9207062111.AA00373@eraserhead.Jpl.Nasa.Gov> Message-Id: <19920708165452.0.MF@FUJI-SAN.SGER.UUCP> Date: Mon, 6 Jul 1992 22:11+0100 From: Curt Eggemeyer I can't seem to get accept-from-string calls within my accept method to work in cases where I do a regular accept. If I do an accept-from-string call my accept method will work. It seems that there is a stream sharing going on between the accept method and my accept-from-string calls within it, because my accept-from-string always gets passed nil even though I am passing a substring of what I got from the read-token. How can one get around this problem? You should really provide examples, otherwise it's hard to understand your problem. Anyway: (define-presentation-type foo ()) Do you mean sth like this(?): (define-presentation-method accept ((type foo) stream view &key) .. (accept-from-string 'integer stream) ..) assuming always calling (accept-from-string 'foo "123456"). Even if this would work the way you expect, this is against the intention of accept of working with all kinds of streams. Probably you mean: (define-presentation-method accept ((type foo) stream view &key) .. (accept-from-string 'integer (read-token stream)) ..) which works fine for me (on Symbolics CLIM 1.1) Markus Fischer, MF@SGER.UUCP Mergenthaler Allee 77-81 Consulting Services W-6236 Eschborn, Germany Symbolics Systemhaus GmbH Phone: +49 6196 47220, Fax 481116   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa17191; 8 Jul 92 14:03 EDT Received: by KARIBA.BBN.COM id ab04670; 8 Jul 92 13:52 EDT To: mf%sger.uucp@BBN.COM cc: clim@BBN.COM, jmorrill@BBN.COM Subject: RE: accept-from-string within accept methods Date: Wed, 08 Jul 92 13:48:03 -0400 Message-ID: <2928.710617683@bbn.com> From: Jeff Morrill Date: Wed, 8 Jul 1992 17:54+0100 From: Markus Fischer Reply-To: mf%sger.uucp@BBN.COM Subject: accept-from-string within accept methods To: curt@eraserhead.jpl.nasa.gov, clim@BBN.COM ... Probably you mean: (define-presentation-method accept ((type foo) stream view &key) .. (accept-from-string 'integer (read-token stream)) ..) which works fine for me (on Symbolics CLIM 1.1) This is quite inefficient. Accept-from-string essentially does this: (with-input-from-string (stream string) (accept presentation-type stream)) The parser for integer acts like a glorified version of: (define-presentation-method accept ((type integer) stream view &key) (parse-integer (read-token stream))) So your suggestion is equivalent to: (with-input-from-string (s (read-token stream)) (parse-integer (read-token s))) I suggest instead: (define-presentation-method accept ((type foo) stream view &key) .. (accept 'integer stream) ..)   Received: from BBN.COM by LABS-N.BBN.COM id aa01047; 9 Jul 92 13:38 EDT Received: from [129.197.134.99] by BBN.COM id aa27826; 9 Jul 92 13:27 EDT Received: from jade.rdd.lmsc.lockheed.com by dipl.rdd.lmsc.lockheed.com (4.0/SMI-4.1) id AA19348; Thu, 9 Jul 92 10:31:38 PDT Received: from cluso.lmsc.com by jade.rdd.lmsc.lockheed.com (4.1/SMI-4.0) id AA21575; Thu, 9 Jul 92 10:28:08 PDT Date: Thu, 9 Jul 92 10:28:08 PDT From: ttrinko@dipl.rdd.lmsc.lockheed.com (Tom Trinko) Message-Id: <9207091728.AA21575@jade.rdd.lmsc.lockheed.com> To: clim@bbn.com Subject: handling aborts from accepting values We need to handle aborts arising from the user aborting out of accepting values dialogs. I've tried (handle-case (abort #'function) but in clim 1.1 genera 8.1.1 it doesn't like abort and sys:abort doesn't work and clim-user:abort doesn't work either. I need to know what condition is generated when the user hits the abort key and/or the abort menu item in an accepting values menu which has its own window. Also any other ways of cleaning up after the user aborts, other than handle-case or with-simple-restart, would be of interest. Thanks.   Received: from BBN.COM by LABS-N.bbn.COM id aa02420; 9 Jul 92 15:36 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa03247; 9 Jul 92 15:31 EDT Received: from WATERMELON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1106001; 9 Jul 1992 15:33:21-0400 Date: Thu, 9 Jul 1992 15:31-0400 From: John G. Aspinall Subject: handling aborts from accepting values To: ttrinko@dipl.rdd.lmsc.lockheed.com cc: clim@BBN.COM In-Reply-To: <9207091728.AA21575@jade.rdd.lmsc.lockheed.com> Message-ID: <19920709193152.3.JGA@WATERMELON.SCRC.Symbolics.COM> Date: Thu, 9 Jul 1992 13:28 EDT From: Tom Trinko We need to handle aborts arising from the user aborting out of accepting values dialogs. I've tried (handle-case (abort #'function) but in clim 1.1 genera 8.1.1 it doesn't like abort and sys:abort doesn't work and clim-user:abort doesn't work either. I need to know what condition is generated when the user hits the abort key and/or the abort menu item in an accepting values menu which has its own window. Also any other ways of cleaning up after the user aborts, other than handle-case or with-simple-restart, would be of interest. Thanks. It's a restart, not a condition. You know that already, because you have a working example that uses with-simple-restart, viz: (defun two-menus (stream) (with-simple-restart (abort "Return from both menus") (accepting-values (stream :own-window t :label "1st Menu") (accept 'integer :stream stream :prompt "The number")) (accepting-values (stream :own-window t :label "2nd Menu") (accept 'integer :stream stream :prompt "The number")))) This is the rough equivalent with restart-case: (defun two-menus-2 (stream) (restart-case (progn (accepting-values (stream :own-window t :label "1st Menu") (accept 'integer :stream stream :prompt "The number")) (accepting-values (stream :own-window t :label "2nd Menu") (accept 'integer :stream stream :prompt "The number"))) (abort () :report "Return from both menus" (return-from two-menus-2 nil))))   Received: from BBN.COM by LABS-N.bbn.COM id aa02410; 9 Jul 92 15:34 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa03184; 9 Jul 92 15:30 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1105999; 9 Jul 1992 15:32:19-0400 Date: Thu, 9 Jul 1992 15:32-0400 From: Scott McKay Subject: handling aborts from accepting values To: ttrinko@dipl.rdd.lmsc.lockheed.com, clim@BBN.COM In-Reply-To: <9207091728.AA21575@jade.rdd.lmsc.lockheed.com> Message-ID: <19920709193218.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 9 Jul 1992 13:28 EDT From: Tom Trinko We need to handle aborts arising from the user aborting out of accepting values dialogs. I've tried (handle-case (abort #'function) but in clim 1.1 genera 8.1.1 it doesn't like abort and sys:abort doesn't work and clim-user:abort doesn't work either. I need to know what condition is generated when the user hits the abort key and/or the abort menu item in an accepting values menu which has its own window. Also any other ways of cleaning up after the user aborts, other than handle-case or with-simple-restart, would be of interest. Thanks. ABORT is a restart, not a condition. Use RESTART-BIND or RESTART-CASE.   Received: from BBN.COM by LABS-N.bbn.COM id aa10663; 10 Jul 92 8:17 EDT Received: from fenrix.si.no by BBN.COM id aa23555; 10 Jul 92 8:12 EDT Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.23) id AA06853; Fri, 10 Jul 92 14:12:38 +0200 Date: Fri, 10 Jul 92 14:12:38 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9207101207.AAmonsun02655@D> To: clim@bbn.com Subject: MacIntosh gestures System: CLIM 1.0, MCL 2.0 (both beta). Could someone please tell me the mapping from modifier keys and mouse button press to CLIM gestures (select, edit, delete, menu...). Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.bbn.COM id ad03058; 13 Jul 92 11:31 EDT Received: from jonquil.uchicago.edu by BBN.COM id aa15036; 13 Jul 92 11:10 EDT Return-Path: Received: by jonquil.uchicago.edu (4.1/UofC4.0x) id AA01715; Mon, 13 Jul 92 10:10:02 CDT Date: Mon, 13 Jul 92 10:10:02 CDT From: Message-Id: <9207131510.AA01715@jonquil.uchicago.edu> To: clim@bbn.com Subject: Overlapping windows to CLIM application frameworks I guess this is an "Am I mixing my user-interface metaphors?" question, a question of how CLIM applications and overlapping windows should coexist. Typically, CLIM application frameworks appear on the screen as a window with non-overlapping subordinate panes. I think what I want to do is add, to a CLIM application, dynamically created, persistent, buryable overlapping windows; windows that are owned by the application but that are not (visually) panes of the application's main window. Specifically, I want to present a list of objects in one of the application's panes. Each time one of the presentations objects is selected, I want to create a new window displaying detailed attributes of that object. I want the freshly-created window not to occupy any of the application frame's screen real estate (it's ok for the new window to appear in front of the application frame, but it must be relocatable and buryable) and I want it to persist until the user explicitly kills it, and I want more than one instance of this type of window to be able to coexist on the screen (i.e. I want the user to be able to look at more than one object simultaneously). I also want to be able to display mouse-sensitive presentations in these new windows. Mechanically, I can do all of this. My question is whether it makes sense from a consistent user inteface point of view, and, if it doesn't, how people suggest dealing with this user interface task in some other way. I'd appreciate direct e-mail copies of any replies since I'm not sure I'm properly wired up to the CLIM mailing list. Thank you much.   Received: from BBN.COM by LABS-N.bbn.COM id aa02644; 13 Jul 92 11:11 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa06396; 13 Jul 92 9:06 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA20906; Mon, 13 Jul 92 06:06:43 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA01459; Mon, 13 Jul 92 05:59:26 PDT Date: Mon, 13 Jul 92 05:59:26 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9207131259.AA01459@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: Quickie question on color? Is there a function or a symbol in CLIM that returns a list of all of the symbols CLIM has for colors (ie: like those on p. 146 in the CLIM docs)?   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa05033; 13 Jul 92 13:57 EDT Received: by KARIBA.BBN.COM id ab02154; 13 Jul 92 13:45 EDT To: owens@cs.uchicago.edu cc: clim@BBN.COM Subject: Re: Overlapping windows to CLIM application frameworks In-reply-to: Your message of Mon, 13 Jul 92 10:10:02 -0500. <9207131510.AA01715@jonquil.uchicago.edu> Reply-To: jmorrill@BBN.COM Date: Mon, 13 Jul 92 13:39:46 -0400 Message-ID: <499.711049186@bbn.com> From: Jeff Morrill Date: Mon, 13 Jul 92 10:10:02 CDT From: owens@cs.uchicago.edu MMDF-Warning: Parse error in original version of preceding line at BBN.COM To: clim@BBN.COM Subject: Overlapping windows to CLIM application frameworks ... Specifically, I want to present a list of objects in one of the application's panes. Each time one of the presentations objects is selected, I want to create a new window displaying detailed attributes of that object. I want the freshly-created window not to occupy any of the application frame's screen real estate (it's ok for the new window to appear in front of the application frame, but it must be relocatable and buryable) and I want it to persist until the user explicitly kills it, and I want more than one instance of this type of window to be able to coexist on the screen (i.e. I want the user to be able to look at more than one object simultaneously). I also want to be able to display mouse-sensitive presentations in these new windows. (When you say 'window' I assume you mean 'frame.' In clim, the visible windows are the frame's panes, and those things can't be overlapped or buried independently of the frame to which they belong.) Mechanically, I can do all of this. My question is whether it makes sense from a consistent user inteface point of view, and, if it doesn't, how people suggest dealing with this user interface task in some other way. It sounds like you are trying to implement the "desktop" metaphor. This makes a great deal of sense but it may be difficult for clim to deal with. I have tried implementing it as having a bunch of application frames that the user is free to bury, resize, reposition, and so on. The frames are conceptually part of a single activity, and this causes some difficulty because it is not clear how they should all interact. What a desktop metaphor needs is a single top-level loop for reading commands from any of several frames in the desktop. It is possible to trick clim into doing this, but it is a bit of a kludge and requires getting your hands dirty with clim internals. Even so, clim's design makes this alternative difficult because you can't use *application-frame* anymore and because you have to keep track of all the frames on your desktop so that things like EXIT will do the right thing. You also must redisplay frame panes manually since clim doesn`t know how. It is a little easier to associate each frame with its own process. Then clim works pretty good, but only because you have broken a single activity into artificially many activities. The worst part about this alternative is that you have many input contexts, one for each frame, whereas there ought to be only one. The impression one gets from reading the clim documentation is that there must be a one-to-one correspondence between applications and frames. If you can live with this assumption, then your life will be easier. But I wish the assumption could be removed.   Received: from BBN.COM by LABS-N.BBN.COM id aa05320; 13 Jul 92 14:22 EDT Received: from gatech.edu by BBN.COM id aa25163; 13 Jul 92 14:12 EDT Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA04307 for clim@bbn.com; Mon, 13 Jul 92 14:12:43 EDT Received: from pravda.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA17968; for owens@cs.uchicago.edu; Mon, 13 Jul 92 14:12:33 EDT Received: from kant.gatech.edu (kant.cc.gatech.edu) by pravda.cc.gatech.edu (4.1/SMI-4.1) id AA16504; Mon, 13 Jul 92 14:12:31 EDT Date: Mon, 13 Jul 1992 14:08-0400 From: Richard Billington Subject: Overlapping windows to CLIM application frameworks To: owens@cs.uchicago.edu Cc: clim@bbn.com In-Reply-To: <9207131510.AA01715@jonquil.uchicago.edu> Message-Id: <19920713180826.2.BUFF@kant.gatech.edu> This seems like a computer-human interface question, not a CLIM question. That said, let me also say that I'm not a chi-type, so the following is all seat-of-the-pants. The technique is certainly not bad in and of itself (I'm using it myself), the question is whether the control structure of the overall task your program is accomplishing can be logically broken up into a collection of semi-independent tasks: that is, when I'm looking at the information presented in the "new" window is it self-contained or am I going to want to refer to information on the "parent" frame? If the former, then I should think this technique is fine, if the latter, I'd say it wasn't. There's also a "navigation" issue - how important is it that the user be able to quickly move amongst the various independent windows associated with the application (including the main one) dictates how much effort you put into providing that control. Depending on the underlying window system to be the sole provider of that kind of navigational capability sounds like a bad idea - some window system make this fairly straight-forward to the novice, others don't.   Received: from PEBBLES.BBN.COM by LABS-N.BBN.COM id aa04806; 13 Jul 92 13:38 EDT From: burstein@BBN.COM Sender: burstein@BBN.COM To: owens@cs.uchicago.edu CC: clim@BBN.COM In-reply-to: owens@cs.uchicago.edu's message of Mon, 13 Jul 92 10:10:02 CDT <9207131510.AA01715@jonquil.uchicago.edu> Subject: Overlapping windows to CLIM application frameworks Date: Mon, 13 Jul 92 13:30:12 EDT Source-Info: From (or Sender) name not authenticated. We do this sort of thing all the time with CLIM. To me, the question is whether it is consistent with the window manager you are using, rather than with CLIM. The constraint-frame model was more typical of Symbolics windows than the environments that CLIM is now being used with. Mark   Received: from BBN.COM by LABS-N.BBN.COM id aa07969; 13 Jul 92 17:48 EDT Received: from gatech.edu by BBN.COM id aa08054; 13 Jul 92 17:44 EDT Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA08087 for clim@bbn.com; Mon, 13 Jul 92 17:44:07 EDT Received: from pravda.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA21001; for jmorrill@BBN.COM; Mon, 13 Jul 92 17:44:04 EDT Received: from kant.gatech.edu (kant.cc.gatech.edu) by pravda.cc.gatech.edu (4.1/SMI-4.1) id AA17889; Mon, 13 Jul 92 17:44:02 EDT Date: Mon, 13 Jul 1992 17:39-0400 From: Richard Billington Subject: Re: Overlapping windows to CLIM application frameworks To: jmorrill@BBN.COM, clim@bbn.com In-Reply-To: <499.711049186@bbn.com> Message-Id: <19920713213957.3.BUFF@kant.gatech.edu> Actually, this leads into a problem I'm having right now. I want to use CLIM:WITH-MENU, except that what I want to put up are application frames. WITH-MENU creates a temp-clim-sheet for you to work in, but you can't tell an application frame "here, use this window as your top-level-window". What I want seems pretty simple - if I bury an application, I want it to frame-exit. Ideally, if its buried I wish it would raise a condition I could handle. Any ideas? Or do I need to rebuild my application-frame-based menus as semething using WITH-MENU's temp windows?   Received: from BBN.COM by LABS-N.BBN.COM id aa14714; 14 Jul 92 9:04 EDT Received: from [192.44.1.1] by BBN.COM id aa09367; 14 Jul 92 8:52 EDT Received: by fhg.de (fhg1.fhg.de) with PRESMTP; Tue, 14 Jul 92 14:51:03 +0200 from FHG-GATEWAY Received: by fhg.de (fhg1.fhg.de) with UUCP; Tue, 14 Jul 92 14:50:55 +0200 from imldo Received: by iml.fhg.de with SMTP; Tue, 14 Jul 92 14:47:52 +0200 Date: Tue, 14 Jul 1992 14:46+0200 From: Stefan Bernemann Subject: Re: Overlapping windows to CLIM application frameworks To: jmorrill@BBN.COM Cc: clim@bbn.com In-Reply-To: <499.711049186@bbn.com> Message-Id: <19920714124652.1.STEFAN@ANNA.iml.fhg.de> Date: Mon, 13 Jul 1992 19:39 MEST From: Jeff Morrill ... It sounds like you are trying to implement the "desktop" metaphor. This makes a great deal of sense but it may be difficult for clim to deal with. I have tried implementing it as having a bunch of application frames that the user is free to bury, resize, reposition, and so on. The frames are conceptually part of a single activity, and this causes some difficulty because it is not clear how they should all interact. That's exactly what we need, too. Can someone comment on how CLIM 2.0 will deal with this subject? Are those "frame-managers" the solution that clim programmers are to use/implement (without "multi-proceccing")? What a desktop metaphor needs is a single top-level loop for reading commands from any of several frames in the desktop. It is possible to trick clim into doing this, but it is a bit of a kludge and requires getting your hands dirty with clim internals. Can you provide some (example) code, as the documentation on how to implement my own top-level loop seems to be too straight for my simple mind... The lisp listener from the examples also doesn't enlighten me too much for this problem. Again, is there a chance that the functionality of this code will be part of clim 2.0? Even so, clim's design makes this alternative difficult because you can't use *application-frame* anymore and because you have to keep track of all the frames on your desktop so that things like EXIT will do the right thing. You also must redisplay frame panes manually since clim doesn`t know how. It is a little easier to associate each frame with its own process. Then clim works pretty good, but only because you have broken a single activity into artificially many activities. The worst part about this alternative is that you have many input contexts, one for each frame, whereas there ought to be only one. The impression one gets from reading the clim documentation is that there must be a one-to-one correspondence between applications and frames. If you can live with this assumption, then your life will be easier. But I wish the assumption could be removed. Thanks a lot - Stefan B. Mail: Stefan Bernemann ! Phone: +49-231-9743-139 c/o FhG IML Dortmund ! Fax: +49-231-9743-234 Emil-Figge-Str. 75 ! Email: berni@iml.fhg.de D-4600 Dortmund 50, FRG !   Received: from BBN.COM by LABS-N.bbn.COM id aa16376; 14 Jul 92 11:20 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa17999; 14 Jul 92 11:15 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1107952; 14 Jul 1992 11:17:09-0400 Date: Tue, 14 Jul 1992 11:17-0400 From: Scott McKay Subject: Re: Overlapping windows to CLIM application frameworks To: berni@iml.fhg.de, jmorrill@BBN.COM cc: clim@BBN.COM In-Reply-To: <19920714124652.1.STEFAN@ANNA.iml.fhg.de> Message-ID: <19920714151736.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 14 Jul 1992 08:46 EDT From: Stefan Bernemann Date: Mon, 13 Jul 1992 19:39 MEST From: Jeff Morrill ... It sounds like you are trying to implement the "desktop" metaphor. This makes a great deal of sense but it may be difficult for clim to deal with. I have tried implementing it as having a bunch of application frames that the user is free to bury, resize, reposition, and so on. The frames are conceptually part of a single activity, and this causes some difficulty because it is not clear how they should all interact. That's exactly what we need, too. Can someone comment on how CLIM 2.0 will deal with this subject? Are those "frame-managers" the solution that clim programmers are to use/implement (without "multi-proceccing")? No deep thought has been spent in this area. Nobody with a vested interest has submitted any proposal in this area, never mind a coherent proposal. As usual, concrete proposals are welcome. What a desktop metaphor needs is a single top-level loop for reading commands from any of several frames in the desktop. It is possible to trick clim into doing this, but it is a bit of a kludge and requires getting your hands dirty with clim internals. Can you provide some (example) code, as the documentation on how to implement my own top-level loop seems to be too straight for my simple mind... The lisp listener from the examples also doesn't enlighten me too much for this problem. Again, is there a chance that the functionality of this code will be part of clim 2.0? Even so, clim's design makes this alternative difficult because you can't use *application-frame* anymore and because you have to keep track of all the frames on your desktop so that things like EXIT will do the right thing. You also must redisplay frame panes manually since clim doesn`t know how. It is a little easier to associate each frame with its own process. Then clim works pretty good, but only because you have broken a single activity into artificially many activities. The worst part about this alternative is that you have many input contexts, one for each frame, whereas there ought to be only one. The impression one gets from reading the clim documentation is that there must be a one-to-one correspondence between applications and frames. If you can live with this assumption, then your life will be easier. But I wish the assumption could be removed. Thanks a lot - Stefan B. Mail: Stefan Bernemann ! Phone: +49-231-9743-139 c/o FhG IML Dortmund ! Fax: +49-231-9743-234 Emil-Figge-Str. 75 ! Email: berni@iml.fhg.de D-4600 Dortmund 50, FRG !   Received: from KARIBA.BBN.COM by LABS-N.bbn.COM id aa15765; 14 Jul 92 10:34 EDT Received: by KARIBA.BBN.COM id aa05731; 14 Jul 92 10:21 EDT To: Stefan Bernemann cc: clim@BBN.COM Subject: Re: Overlapping windows to CLIM application frameworks In-reply-to: Stefan Bernemann's message of Tue, 14 Jul 92 14:46:00 +0200. <19920714124652.1.STEFAN@ANNA.iml.fhg.de> Reply-To: jmorrill@BBN.COM Date: Tue, 14 Jul 92 10:17:33 -0400 Message-ID: <846.711123453@bbn.com> From: Jeff Morrill Date: Tue, 14 Jul 1992 14:46+0200 From: Stefan Bernemann That's exactly what we need, too. Can someone comment on how CLIM 2.0 will deal with this subject? Are those "frame-managers" the solution that clim programmers are to use/implement (without "multi-proceccing")? CLIM 2 probably won't do any better than CLIM 1 on this point. Can you provide some (example) code, as the documentation on how to implement my own top-level loop seems to be too straight for my simple mind... The lisp listener from the examples also doesn't enlighten me too much for this problem. Again, is there a chance that the functionality of this code will be part of clim 2.0? Here is some code to get you started that should work in clim 1.1. The basic idea is that you have one frame, called the "master", that works like normal clim application frames and that is used to provide the top-level loop for the whole "desktop." All of the rest of the frames have no top-level loop, they merely provide some real estate that you can draw upon. I call these the "slave" frames. If they share the same input buffer as the master, then presentations drawn on slave frames become "applicable" to the input context provided by the master. (I don't know if this behavior is a documented feature of clim, but I have found it to be true.) (defun start-slave-frame (frame &optional (master *application-frame*)) (let ((b (clim:stream-input-buffer (clim:frame-top-level-window master))) (top-level-window (clim:frame-top-level-window frame))) (labels ((set-input-buffer (window buffer) (setf (clim:stream-input-buffer window) buffer) (dolist (w (clim:window-children window)) (set-input-buffer w buffer)))) (set-input-buffer top-level-window b) (clim:window-expose top-level-window) (clim:redisplay-frame-panes frame :force-p t))))   Received: from BBN.COM by LABS-N.bbn.COM id ab17259; 14 Jul 92 12:36 EDT Received: from watson.ibm.com by BBN.COM id aa21327; 14 Jul 92 12:32 EDT Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 6859; Tue, 14 Jul 92 12:32:29 EDT Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0" id 1393; Tue, 14 Jul 1992 12:32:23 EDT Received: from fiasco.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2) with TCP; Tue, 14 Jul 92 12:32:22 EDT Received: by fiasco.watson.ibm.com (AIX 3.1/UCB 5.61/920123) id AA37275; Tue, 14 Jul 92 12:32:26 -0400 Message-Id: <9207141632.AA37275@fiasco.watson.ibm.com> To: clim@BBN.COM X-External-Networks: yes Reply-To: meir@watson.ibm.com Subject: multiple command menu panes in one application Date: Tue, 14 Jul 92 12:32:25 -0500 From: "Meir Laker" Normally, I would like one command menu pane for my users to interact with my application. However, for debugging purposes, it would be nice to add a second menu pane on demand with debugging commands. How do I do this? CLIM:DEFINE-PROGRAM-FRAMEWORK seems to allow multiple command menu panes, but they all show the same set of commands; there doesn't seem to be any way to specify the commands-table. On the other hand, if I use CLIM:DISPLAY-COMMAND-MENU to display to an :application pane, the commands are not mouse-sensitive. Meir Laker   Received: from BBN.COM by LABS-N.bbn.COM id aa17788; 14 Jul 92 13:34 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa23500; 14 Jul 92 13:28 EDT Received: from WATERMELON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1108027; 14 Jul 1992 13:30:03-0400 Date: Tue, 14 Jul 1992 13:29-0400 From: John G. Aspinall Subject: multiple command menu panes in one application To: meir@watson.ibm.com cc: clim@BBN.COM In-Reply-To: <9207141632.AA37275@fiasco.watson.ibm.com> Message-ID: <19920714172919.3.JGA@WATERMELON.SCRC.Symbolics.COM> Date: Tue, 14 Jul 1992 13:32 EDT From: Meir Laker Normally, I would like one command menu pane for my users to interact with my application. However, for debugging purposes, it would be nice to add a second menu pane on demand with debugging commands. How do I do this? CLIM:DEFINE-PROGRAM-FRAMEWORK seems to allow multiple command menu panes, but they all show the same set of commands; there doesn't seem to be any way to specify the commands-table. On the other hand, if I use CLIM:DISPLAY-COMMAND-MENU to display to an :application pane, the commands are not mouse-sensitive. ;;; -*- Mode: LISP; Syntax: Common-Lisp; Base: 10; Package: CLIM-USER -*- ;;;>********************************************************************* ;;;> ;;;> Symbolics hereby grants permission to customer to incorporate ;;;> the examples in this file in any work belonging to customer. ;;;> ;;;>********************************************************************* ;;; Simple example of how to use command-table inheritance to get ;;; multiple menus in a frame. (define-command-table primary) (define-command (com-red :command-table primary :menu t) () (echo-command *application-frame* "Red")) (define-command (com-blue :command-table primary :menu t) () (echo-command *application-frame* "Blue")) (define-command (com-green :command-table primary :menu t) () (echo-command *application-frame* "Green")) (define-command-table secondary) (define-command (com-yellow :command-table secondary :menu t) () (echo-command *application-frame* "Yellow")) (define-command (com-cyan :command-table secondary :menu t) () (echo-command *application-frame* "Cyan")) (define-command (com-magenta :command-table secondary :menu t) () (echo-command *application-frame* "Magenta")) ;;; first version with one layout (clim:define-application-frame multi-menu () () (:command-table (t :inherit-from (primary secondary))) (:panes ((display :application) (own-menu :command-menu) (primary-menu :command-menu :display-function '(clim:display-command-menu :command-table primary)) (secondary-menu :command-menu :display-function '(clim:display-command-menu :command-table secondary)))) (:layout ((regular (:column 1 (display :rest) (:row 1/6 (primary-menu :compute) (secondary-menu :compute) (own-menu :rest))))))) (define-multi-menu-command (com-exit-multi-menu :menu "Exit") () (frame-exit *application-frame*)) (defmethod echo-command ((frame multi-menu) string) (let ((stream (get-frame-pane frame 'display))) (format stream "~%The ~A command." string))) ;;; second version with multiple configurations (clim:define-application-frame multi-menu () () (:command-table (t :inherit-from (primary secondary))) (:panes ((display :application) (own-menu :command-menu) (primary-menu :command-menu :display-function '(clim:display-command-menu :command-table primary)) (secondary-menu :command-menu :display-function '(clim:display-command-menu :command-table secondary)))) (:layout ((primary (:column 1 (display :rest) (:row 1/6 (primary-menu :compute) (own-menu :rest)))) (secondary (:column 1 (display :rest) (:row 1/6 (secondary-menu :compute) (own-menu :rest))))))) (define-multi-menu-command (com-exit-multi-menu :menu "Exit") () (frame-exit *application-frame*)) (defmethod echo-command ((frame multi-menu) string) (let ((stream (get-frame-pane frame 'display))) (format stream "~%The ~A command." string))) (define-multi-menu-command (switch-configurations :menu "Switch") () (let ((new-config (case (frame-current-layout *application-frame*) (primary 'secondary) (secondary 'primary)))) (set-frame-layout *application-frame* new-config))) #|| () ;standalone testing (defvar *clim-root* (open-root-window :sheet)) (setq mm (clim:make-application-frame 'multi-menu :parent *clim-root* :width 600 :height 500 :left 100 :top 100)) (clim:run-frame-top-level mm) ||#   Received: from BBN.COM by LABS-N.bbn.COM id aa19102; 14 Jul 92 14:42 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa27022; 14 Jul 92 14:36 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1108074; 14 Jul 1992 14:37:46-0400 Date: Tue, 14 Jul 1992 14:38-0400 From: Scott McKay Subject: multiple command menu panes in one application To: meir@watson.ibm.com, clim@BBN.COM In-Reply-To: <9207141632.AA37275@fiasco.watson.ibm.com> Message-ID: <19920714183816.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 14 Jul 1992 13:32 EDT From: Meir Laker Normally, I would like one command menu pane for my users to interact with my application. However, for debugging purposes, it would be nice to add a second menu pane on demand with debugging commands. How do I do this? CLIM:DEFINE-PROGRAM-FRAMEWORK seems to allow multiple command menu panes, but they all show the same set of commands; there doesn't seem to be any way to specify the commands-table. On the other hand, if I use CLIM:DISPLAY-COMMAND-MENU to display to an :application pane, the commands are not mouse-sensitive. Use a :COMMAND-MENU panes with :DISPLAY-FUNCTION (CLIM:DISPLAY-COMMAND-MENU :COMMAND-TABLE ) works for me.   Received: from BBN.COM by LABS-N.BBN.COM id aa19114; 14 Jul 92 14:42 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa27028; 14 Jul 92 14:36 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1108075; 14 Jul 1992 14:37:54-0400 Date: Tue, 14 Jul 1992 14:38-0400 From: Scott McKay Subject: multiple command menu panes in one application To: meir@watson.ibm.com, clim@BBN.COM In-Reply-To: <9207141632.AA37275@fiasco.watson.ibm.com> Supersedes: <19920714183816.8.SWM@SUMMER.SCRC.Symbolics.COM> Message-ID: <19920714183825.9.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 14 Jul 1992 13:32 EDT From: Meir Laker Normally, I would like one command menu pane for my users to interact with my application. However, for debugging purposes, it would be nice to add a second menu pane on demand with debugging commands. How do I do this? CLIM:DEFINE-PROGRAM-FRAMEWORK seems to allow multiple command menu panes, but they all show the same set of commands; there doesn't seem to be any way to specify the commands-table. On the other hand, if I use CLIM:DISPLAY-COMMAND-MENU to display to an :application pane, the commands are not mouse-sensitive. Using :COMMAND-MENU panes with :DISPLAY-FUNCTION (CLIM:DISPLAY-COMMAND-MENU :COMMAND-TABLE ) works for me.   Received: from BBN.COM by LABS-N.bbn.COM id aa20831; 14 Jul 92 15:23 EDT Received: from host4.colby.edu by BBN.COM id aa29041; 14 Jul 92 15:20 EDT Received: by host4.COLBY.EDU (5.57/Colby 1.1) id AA11431; Tue, 14 Jul 92 15:23:06 -0400 Message-Id: <9207141923.AA11431@host4.COLBY.EDU> Date: Tue, 14 Jul 1992 15:24:05 +0000 To: clim@BBN.COM From: djskrien@COLBY.EDU (Dale Skrien) Subject: Please remove me Please remove my name from the mailing list. Thanks.   Received: from BBN.COM by LABS-N.BBN.COM id aa23822; 14 Jul 92 20:21 EDT Received: from charon.arc.nasa.gov by BBN.COM id aa13502; 14 Jul 92 20:18 EDT Received: from HALEAKALA.arc.nasa.gov by CHARON.arc.nasa.gov via INTERNET with SMTP id 130770; 14 Jul 1992 17:18:45-0700 Date: Tue, 14 Jul 1992 17:18-0700 From: will taylor Subject: Two Mouse Clicks to Discard Window Resource To: clim@bbn.com cc: taylor@CHARON.arc.nasa.gov Message-ID: <19920715001836.2.TAYLOR@HALEAKALA.arc.nasa.gov> Symbolics 8.1.1 - CLIM 1.1 When my application menu command is clicked and it puts up a menu with CLIM:WITH-MENU and I want to discard it, I click once and it is gone and any mouse sensitive presentations on my frame are again mouse sensitive. I created a "both-scroll-menu" which is resource like MENU, but has both scroll bars and I use it to show the user information which may be of large extent in both directions. The only problem is that it takes TWO mouse clicks off the "both-scroll-menu" 1) to discard the menu, and 2) to get mouse sensitivity back for the presentations. My code is below -- I must be neglecting something .. Thanks for any suggestions. ==> Will Taylor (clim::defresource BOTH-SCROLL-MENU (associated-window root) :constructor (open-window-stream :parent root :left 100 :top 100 :width 600 :height 400 ;"random" size :scroll-bars ':both :window-class (clim::menu-class-name root) :save-under t) :initializer (clim::initialize-menu both-scroll-menu associated-window) :deinitializer (progn (setf (window-visibility both-scroll-menu) nil) (window-clear both-scroll-menu) (setf (window-label both-scroll-menu) nil)) :matcher (eql (window-parent both-scroll-menu) root)) (defmacro WITH-BOTH-SCROLL-MENU ((menu associated-window &key (label " ")) &body body) "bring up both scroll bar menu with output in body" (let ((window '#:associated-window)) `(let ((,window ,associated-window)) (clim::using-resource (,menu both-scroll-menu (window-top-level-window ,window) (window-root ,window)) (clim::letf-globally (((stream-default-view ,window) +menu-view+)) (formatting-table (,menu :inter-row-spacing 5) (formatting-row (,menu) (formatting-cell (,menu :align-x :center) (DRAW-MENU-LABEL ,label 0 ,menu))) (formatting-row (,menu) (formatting-cell (,menu :align-x :center) ,@body (with-text-face (:italic ,menu) (format ,menu "~%To discard: Click TWICE off menu ~%"))))) (clim::size-menu-appropriately ,menu) (multiple-value-bind (x y) (clim::pointer-position* (stream-primary-pointer ,associated-window)) (clim::position-window-near-carefully ,menu x y)) (window-expose ,menu) (stream-input-wait ,associated-window)))))) (define-evolutionary-tree-frame-command (COM-MATRIX) ((pane 'scaled-editor-pane-class)) (let* ((frame *application-frame*) (associated-window (frame-top-level-window frame)) (matrix-type (menu-choose-item :question "Choose matrix type" :item-list '(("dna" :value genesys::dna) ("rna" :value genesys::rna) ("amino acid" :value genesys::amino)) :no-menu-if-1-item-p t :associated-window associated-window))) (when matrix-type (let ((label-format-string (case matrix-type (genesys::dna "~A: DNA Matrix") (genesys::rna "~A: RNA Matrix") (genesys::amino "~A: Amino Acid Matrix")))) ;; pop-up a scrollable window (WITH-BOTH-SCROLL-MENU (menu associated-window :label (format nil label-format-string (name (current-tree pane)))) (case matrix-type (genesys::dna (GENESYS::MATRIX-PRINT-MATRIX (first (genesys::transition-matrices (genesys-tree (current-tree pane)))) :stream menu) (format menu "~%")) (otherwise (format menu " NOT AVAILABLE YET ~%")))))))) ------------------------------------------------------------------------   Received: from BBN.COM by LABS-N.bbn.COM id aa24854; 14 Jul 92 22:47 EDT Received: from breeze.bellcore.com by BBN.COM id aa20159; 14 Jul 92 22:43 EDT Received: from ALEX.ims.bellcore.com by breeze.bellcore.com (5.61/1.34) id AA05540; Tue, 14 Jul 92 22:43:39 -0400 Date: Tue, 14 Jul 1992 22:43-0400 From: Peter Clitherow Subject: bulk text editing. To: clim@bbn.com Message-Id: <19920715024338.0.PC@ALEX.ims.bellcore.com> in my old DW and TV code on the Symbolics i could setup a window (tv:make-window 'zwei:standalone-editor-frame) and send it various messages, whereapon it would behave like a regular emacs, and let me do bulk text editing. i'm finding editing large text strings in CLIM:ACCEPT :own-windows rather painful in symbolics CLIM1.1. is there a more satisfactory, portable way of doing this editing on multi line strings? (e.g. mail messages). probably some combination of CLIM:WITH-INPUT-EDITING and CLIM:WITH-INPUT-EDITOR-TYPEOUT to replay the screen when you move up/down would probably help me here, but it's really too late at night for me to figure this out, without an example. or should this all work automatically, and the implementation is just sub-optimal? tnx, pc   Received: from BBN.COM by LABS-N.BBN.COM id aa29646; 15 Jul 92 7:01 EDT Received: from nixpbe.sni.de by BBN.COM id aa23300; 15 Jul 92 6:45 EDT Received: from ap542.sniap.mchp.sni.de by nixpbe.sto.pdb.sni.de (5.65/1.34) id AA08584; Wed, 15 Jul 92 12:18:54 +0200 Received: from Sun4.sniap.mchp.sni.de by ap542.sniap.mchp.sni.de with SMTP id AA25084 (5.65c/IDA-1.4.4); Wed, 15 Jul 1992 12:14:15 +0100 From: Thomas Ruedesheim Date: Wed, 15 Jul 92 12:14:46 +0200 Message-Id: <9207151014.AA04227@Sun4.sniap.mchp.sni.de> To: clim@BBN.COM Subject: Multiprocessing and CLIM Cc: bugs@FRANZ.COM Hi, there. I am using CLIM 1.1 on Allegro CL 4.1. There seem to be problems when you spawn a new process with MP:PROCESS-RUN-FUNCTION while performing a CLIM command: the application frame becomes inactive (you cannot invoke another command). There are several functions concerning processes in the CLIM-UTIL package. Should I use them instead? How can I get a documentation for them? Thomas   Received: from BBN.COM by LABS-N.BBN.COM id aa02296; 15 Jul 92 10:08 EDT Received: from mcsun.EU.net by BBN.COM id aa04896; 15 Jul 92 9:52 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA21228 (5.65b/CWI-2.170); Wed, 15 Jul 1992 15:49:23 +0200 Received: from nrb.UUCP by ub4b.buug.be (5.65c/ub4b_02) id AA23586; Wed, 15 Jul 1992 15:49:22 +0200 Received: from nrbmi1.ia.nrb.be by scosysv.nrb.be with SMTP (5.59/NRB25-f-eef-ev@nrb) id AA00607; Wed, 15 Jul 92 21:12:47 +0100 Date: Wed, 15 Jul 1992 15:22+0200 From: Vincent Keunen Reply-To: nrb!keunen@relay.EU.net Subject: proposals for meta-applications, frameworks, windows...(long message) To: clim@nrbmi2.ia.nrb.be In-Reply-To: <19920714151736.4.SWM@SUMMER.SCRC.Symbolics.COM> Message-Id: <19920715132226.2.KEUNEN@nrbmi1.ia.nrb.be> Date: Tue, 14 Jul 1992 17:17+0200 From: Scott McKay No deep thought has been spent in this area. Nobody with a vested interest has submitted any proposal in this area, never mind a coherent proposal. As usual, concrete proposals are welcome. I haven't though deeply either, however, I think CLIM has a concept of applications (at least a word for the concept, cf define-APPLICATION-framework...). I think it's adequate. But... 1- proposal for a meta-application ---------------------------------- For multiple instanciations of applications (select-c-?), there should be a "higher thing" if there is a need to control all the applications. I can imagine several applications using common information - something like a central database. The specific application information can be stored in state variables (things like "preferred view" for visual representations,...) and that's good. But for the moment, the only way to share between applications is by using global variables, which is too "high level", I think. The "higher thing" could be named something like a meta-application, or an application-manager,... It should have state variables of its own and, at least, a list of applications that it "manages". 2- proposal for DAs ------------------- CLIM also has concepts of frameworks, panes and windows. I must admit that I've long been mixed up with these and I'm not sure I can put all the pieces in the correct places yet. First it seems to me that clim-windows are not the same as things-usually-called-windows (in X, Mac, ...). If I am correct, these systems all talk about a root window (one per screen??) that has child windows (for the mac, the root window could be the desktop). I think that the questions of applications and visible objects have to be separated. So what we need could be (this is my first try): Preliminary: Since everybody uses the same words in various senses, I'll try to use words that mean nothing (don't say I always do!). This way, the confusion will be lessened and words will be found later for these entities. I'll talk about DAs (for display areas). They need not be real DAs, they could be virtual and/or infinite (as with clim's drawing panes). a level0-DA: the ancestor of all level1 DAs (has pointers to them) a level1-DA: the most general area where display can occur (it can be shared by various machines - useful for future very heavy applications that use multiple machines to cooperate in the display of something). In the X world, all the network-distributed windows could be part of the same level1-DA. This could also be called something like "virtual distributed desktop". a level2-DA: the total area a single machine can access locally (the generalized desktop, maybe displayed on more than one screen - cf a mac with several screens) a level3-DA: this could correspond to the area displayed by a unique screen on one single machine. This is the first DA not to be virtual (or could there be virtual screens?). a level4-DA: could be a single visible object (a window in most window systems, but also a framework in clim's terms if my understanding is correct). a level5-DA: a subdivision of level4-DA (panes for clim). etc... Now I'm asking the specialists: will there be a mapping from all other systems' concepts (X-root window, X-window, mac desktop, mac window, clim's frame, panes, views, viewports, menus, dialogs, sheets,...) to these???? From there, one could see where the connection between applications (processes,...) and DA is best done. Does an app manage leveli-DA? etc... These are my first thoughts... Please comment on these. vk =============================================================== Keunen Vincent Network Research Belgium R&D, Software Engineer Parc Industriel des Hauts-Sarts keunen@nrb.be 2e Avenue, 65 tel: +32 41 407282 B-4040 Herstal fax: +32 41 481170 BELGIUM ===============================================================   Received: from BBN.COM by LABS-N.BBN.COM id aa02670; 15 Jul 92 10:44 EDT Received: from mcsun.EU.net by BBN.COM id aa06576; 15 Jul 92 10:19 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA22955 (5.65b/CWI-2.170); Wed, 15 Jul 1992 16:19:15 +0200 Received: from nrb.UUCP by ub4b.buug.be (5.65c/ub4b_02) id AA24800; Wed, 15 Jul 1992 16:19:15 +0200 Received: from nrbmi1.ia.nrb.be by scosysv.nrb.be with SMTP (5.59/NRB25-f-eef-ev@nrb) id AA00663; Wed, 15 Jul 92 21:51:38 +0100 Date: Wed, 15 Jul 1992 16:01+0200 From: Vincent Keunen Reply-To: nrb!keunen@relay.EU.net Subject: CLIM ftp server To: clim@nrbmi2.ia.nrb.be Message-Id: <19920715140116.4.KEUNEN@nrbmi1.ia.nrb.be> After various discussions with Scott McKay and Christopher Fry, I have volunteered to be a librarian for CLIM utilities. Steve Strassmann has agreed to dedicate some disk space for clim code. Therefore, this first request: If you have clim code that you would like to share, you can load it onto cambridge.apple.com:/pub/MCL2/contrib/clim Although this directory is under MCL2, it doesn't mean that the code is specific to MCL (Macintosh CL). Steve: would it be possible to move the directory up to /pub/clim (or make some kind of logical link?). This directory is intended to contain clim utilities (browsers,...), clim example code and clim patches. Since clim runs on unix, symbolics and mac machines, it is best not to use compression formats when possible. As a convention, I suggest that large portions of code be accompanied by a read-me file: my-code.lisp my-code.readme Short contributions can include readme information in the header of the file. Please mail keunen@nrb.be for any suggestions or comments. Thanks Have fun! vk =============================================================== Keunen Vincent Network Research Belgium R&D, Software Engineer Parc Industriel des Hauts-Sarts keunen@nrb.be 2e Avenue, 65 tel: +32 41 407282 B-4040 Herstal fax: +32 41 481170 BELGIUM ===============================================================   Received: from BBN.COM by LABS-N.BBN.COM id aa03955; 15 Jul 92 12:29 EDT Received: from [129.197.134.99] by BBN.COM id aa12369; 15 Jul 92 12:20 EDT Received: from jade.rdd.lmsc.lockheed.com by dipl.rdd.lmsc.lockheed.com (4.0/SMI-4.1) id AA23507; Wed, 15 Jul 92 09:24:36 PDT Received: from cluso.lmsc.com by jade.rdd.lmsc.lockheed.com (4.1/SMI-4.0) id AA12020; Wed, 15 Jul 92 09:20:47 PDT Date: Wed, 15 Jul 92 09:20:47 PDT From: ttrinko@dipl.rdd.lmsc.lockheed.com (Tom Trinko) Message-Id: <9207151620.AA12020@jade.rdd.lmsc.lockheed.com> To: customer-reports@riverside.scrc.symbolics.com Subject: problem with accept Cc: clim@bbn.com Mark: This is the code which seems to have a problem (defun menu (stream) (accepting-values (stream :own-window t :label "abc") (accept 'string :stream stream :prompt t))) when I execute this I see the following problem. click on the string value to enter it start typing when you hit 35 characters or so--including the prompt-- the text wraps to the next line even though there is plenty of space to the right. In our full application we see that if the prompt is > 35 characters long the everything the user types appears on the next line. We also see the "no" option from accept 'boolean appearing on the next line. Am i doing something stupid or is this a real bug? Thanks for any help   Received: from BBN.COM by LABS-N.BBN.COM id aa05048; 15 Jul 92 14:09 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa16781; 15 Jul 92 14:01 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1108693; 15 Jul 1992 13:24:45-0400 Date: Wed, 15 Jul 1992 13:24-0400 From: Scott McKay Subject: proposals for meta-applications, frameworks, windows...(long message) To: nrb!keunen@relay.eu.net, clim@bbn.com In-Reply-To: <19920715132226.2.KEUNEN@nrbmi1.ia.nrb.be> Message-ID: <19920715172443.5.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 15 Jul 1992 09:22 EDT From: Vincent Keunen Date: Tue, 14 Jul 1992 17:17+0200 From: Scott McKay No deep thought has been spent in this area. Nobody with a vested interest has submitted any proposal in this area, never mind a coherent proposal. As usual, concrete proposals are welcome. I haven't though deeply either, however, I think CLIM has a concept of applications (at least a word for the concept, cf define-APPLICATION-framework...). I think it's adequate. But... This following two paragraphs will sound a bit like I am scolding Mr. Keunen, but that's really not my intention. But this message is a good example of useful information that is not actually a concrete proposal. The reason I asked for a concrete proposal is that I myself have not ever had the need to use multiple application frames that interconnect beyond simply sharing data through an agreed-upon "database" of some sort. Therefore, I am not sure I can design a module that adequately serves the needs of people who do need such a thing. Therefore, I need one or more concrete proposals that describe exactly what people want to do. The more specific, the better; so a proposal complete with classes, generic functions, and examples of use is most desirable. So, while this input is useful, this is not what I mean by a "proposal". At the very least, a concrete proposal should outline precisely what is being accomplished, and documents a set of classes and generic functions on those classes. 1- proposal for a meta-application ---------------------------------- For multiple instanciations of applications (select-c-?), there should be a "higher thing" if there is a need to control all the applications. I can imagine several applications using common information - something like a central database. The specific application information can be stored in state variables (things like "preferred view" for visual representations,...) and that's good. But for the moment, the only way to share between applications is by using global variables, which is too "high level", I think. Global variables are simply a special case of an agreed upon "database". There are more flexible ways to do this, but global variables are not inherently bad for this purpose. The "higher thing" could be named something like a meta-application, or an application-manager,... It should have state variables of its own and, at least, a list of applications that it "manages". I believe that a normal CLIM application frame can serve exactly the function of what you call a "meta-application". 2- proposal for DAs ------------------- CLIM also has concepts of frameworks, panes and windows. I must admit that I've long been mixed up with these and I'm not sure I can put all the pieces in the correct places yet. First it seems to me that clim-windows are not the same as things-usually-called-windows (in X, Mac, ...). If I am correct, these systems all talk about a root window (one per screen??) that has child windows (for the mac, the root window could be the desktop). A window in CLIM is the same as a window in X or MCL or whatever. A pane is a window whose parent is an application frame. An application frame is an object that groups together some state variables, (optionally) a process, a command loop, and zero or more panes. I think that the questions of applications and visible objects have to be separated. So what we need could be (this is my first try): I am not sure that the following addresses what people are asking for, which I understand to be a principled way for one single "meta-application" to control a number of inferior applications. I certainly don't think that CLIM 2.0 should be breaking ground in the area of "virtual distributed desktops". Maybe later... Preliminary: Since everybody uses the same words in various senses, I'll try to use words that mean nothing (don't say I always do!). This way, the confusion will be lessened and words will be found later for these entities. I'll talk about DAs (for display areas). They need not be real DAs, they could be virtual and/or infinite (as with clim's drawing panes). a level0-DA: the ancestor of all level1 DAs (has pointers to them) a level1-DA: the most general area where display can occur (it can be shared by various machines - useful for future very heavy applications that use multiple machines to cooperate in the display of something). In the X world, all the network-distributed windows could be part of the same level1-DA. This could also be called something like "virtual distributed desktop". a level2-DA: the total area a single machine can access locally (the generalized desktop, maybe displayed on more than one screen - cf a mac with several screens) a level3-DA: this could correspond to the area displayed by a unique screen on one single machine. This is the first DA not to be virtual (or could there be virtual screens?). a level4-DA: could be a single visible object (a window in most window systems, but also a framework in clim's terms if my understanding is correct). a level5-DA: a subdivision of level4-DA (panes for clim). etc... Now I'm asking the specialists: will there be a mapping from all other systems' concepts (X-root window, X-window, mac desktop, mac window, clim's frame, panes, views, viewports, menus, dialogs, sheets,...) to these???? From there, one could see where the connection between applications (processes,...) and DA is best done. Does an app manage leveli-DA? etc... These are my first thoughts... Please comment on these.   Received: from BBN.COM by LABS-N.BBN.COM id aa05036; 15 Jul 92 14:05 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa16352; 15 Jul 92 13:50 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1108687; 15 Jul 1992 13:07:22-0400 Date: Wed, 15 Jul 1992 13:07-0400 From: Scott McKay Subject: bulk text editing. To: pc@breeze.bellcore.com, clim@BBN.COM In-Reply-To: <19920715024338.0.PC@ALEX.ims.bellcore.com> Message-ID: <19920715170719.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 14 Jul 1992 22:43 EDT From: Peter Clitherow in my old DW and TV code on the Symbolics i could setup a window (tv:make-window 'zwei:standalone-editor-frame) and send it various messages, whereapon it would behave like a regular emacs, and let me do bulk text editing. i'm finding editing large text strings in CLIM:ACCEPT :own-windows rather painful in symbolics CLIM1.1. is there a more satisfactory, portable way of doing this editing on multi line strings? (e.g. mail messages). probably some combination of CLIM:WITH-INPUT-EDITING and CLIM:WITH-INPUT-EDITOR-TYPEOUT to replay the screen when you move up/down would probably help me here, but it's really too late at night for me to figure this out, without an example. or should this all work automatically, and the implementation is just sub-optimal? CLIM 1.1 is no good at this. On Genera, you could always compile-time conditionalize and just use ZWEI:STANDALONE-EDITOR-FRAME. CLIM 2.0 will have "text-editor" gadgets whose value is the edited string. These should work much better.   Received: from BBN.COM by LABS-N.BBN.COM id aa06610; 15 Jul 92 16:11 EDT Received: from gatech.edu by BBN.COM id aa24356; 15 Jul 92 16:03 EDT Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA11285 for clim@BBN.COM; Wed, 15 Jul 92 16:03:19 EDT Received: from pravda.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA11665; for ttrinko@dipl.rdd.lmsc.lockheed.com; Wed, 15 Jul 92 16:03:15 EDT Received: from kant.gatech.edu (kant.cc.gatech.edu) by pravda.cc.gatech.edu (4.1/SMI-4.1) id AA24871; Wed, 15 Jul 92 16:03:10 EDT Date: Wed, 15 Jul 1992 15:59-0400 From: Richard Billington Subject: problem with accept To: ttrinko@dipl.rdd.lmsc.lockheed.com, customer-reports@riverside.scrc.symbolics.com Cc: clim@BBN.COM In-Reply-To: <9207151620.AA12020@jade.rdd.lmsc.lockheed.com> Message-Id: <19920715195907.3.BUFF@kant.gatech.edu> Date: Wed, 15 Jul 1992 12:20 EDT From: Tom Trinko Mark: This is the code which seems to have a problem (defun menu (stream) (accepting-values (stream :own-window t :label "abc") (accept 'string :stream stream :prompt t))) when I execute this I see the following problem. click on the string value to enter it start typing when you hit 35 characters or so--including the prompt-- the text wraps to the next line even though there is plenty of space to the right. In our full application we see that if the prompt is > 35 characters long the everything the user types appears on the next line. We also see the "no" option from accept 'boolean appearing on the next line. Am i doing something stupid or is this a real bug? Thanks for any help I came up with a workaround for this, but forgot to report the problem. The problem is that the stream-text-margin is not set and the default is 35. Here's code that works for us. Notice the first line within the accepting-values is (setf (stream-text-margin ...). This is what does the fix and it must be able to access the stream, so using t as a value for stream in accepting-values doesn't work. We just bind stream to (frame-top-level-window *application-frame*). (let ((stream (frame-top-level-window *application-frame*))) (clim:accepting-values (stream :own-window '(:right-margin (20 :character) :bottom-margin (5 :character)) :label "Change existing object or create new one") (setf (stream-text-margin stream) (window-inside-width stream)) (setf change? (accept '(member :yes :no) :prompt (format nil "Change existing object named ~A" name) :default :no :stream stream))))   Received: from BBN.COM by LABS-N.BBN.COM id aa07169; 15 Jul 92 17:09 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa28070; 15 Jul 92 17:05 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1108834; 15 Jul 1992 17:06:15-0400 Date: Wed, 15 Jul 1992 17:06-0400 From: Scott McKay Subject: CLIM II draft specification available for comment To: clim@bbn.com, slug@ai.sri.com Message-ID: <19920715210614.4.SWM@SUMMER.SCRC.Symbolics.COM> CLIM II specification announcement July 15, 1992 As indicated in a previous press release, Franz Inc., Lucid Inc., and Symbolics Inc. are making available for public review and comment a draft of the CLIM 2.0 specification. The draft being made available is Symbolics' May 6 draft of the CLIM 2.0 Specification, which is serving as the starting point for the multi-vendor effort. The document is intended to specify both the application programmer's interface (API) for general programmers and the lower-level protocols for programmers who are extending or implementing CLIM. The specification is available via anonymous FTP at: ftp.uu.net in the file /vendor/franz/clim/clim.ps.Z, which is the compressed postscript file (specify binary protocol to FTP). Comments should be sent to CLIM-Spec@Riverside.SCRC.Symbolics.COM. Please include appropriate page numbers with each comment. The great majority of the open issues in the specification have been resolved, but several sections of this draft are currently in dispute. The vendors believe that it is better to issue a complete, even if imperfect, draft. In some cases, a disputed section represents the solution that one or more vendor favors. In other cases, a disputed section is approved by no vendor. In all cases, we believe that comments from the user community can help to resolve the disputed issues. The remainder of this cover letter highlights the issues in the specification that either require some further consideration or work, or are the subject of active dispute among members of the CLIM coalition. Some of these items may already be resolved in the current working version of the specification and some are even noted in the May 6th document itself. We hope that this concise listing will help readers to focus on disputes, while also allowing those interested in CLIM to focus on the settled portions of the specification. Note that this is only a terse listing intended to give some sense of the scope of the problems rather than a detailed discussion. The chapter and section numbers listed below are from the specification dated May 6. Chapter 3. Geometry 3.1 General Regions 3.2 Other Region Types 3.2.2 Polygons and Polylines 3.2.3 Lines 3.2.5 Ellipses and Elliptical Arcs The May 6 specification describes several regions classes (PATH, AREA, POLYLINE, POLYGON, LINE, ELLIPSE, and ELLIPTICAL-ARC) that some members feel are of marginal utility. On the one hand, CLIM itself and may applications do not use any of these classes. On the other hand, there is a family of applications (such as graphic editors) that do use these classes. Furthermore, to fully implement the geometry protocol (such as transformations, point containment and region intersection predicates, and so on) is not trivial. One proposal under consideration is to move these classes into an optional module that is not part of CLIM itself. Chapter 8. Sheet Protocols 8.4.1 Repaint Protocol functions One group working on the implementation of CLIM 2.0 re-implemented the so-called "Silica" layer found in CLIM 0.9. In doing so, the semantics of the repaint protocol functions were changed in such a way that the names are inconsistent with the input protocol functions. For example, HANDLE-REPAINT and HANDLE-EVENT are no longer analogous. There is also some question whether the current specification lets you mix queued and immediate repaints properly. There is no disputed issue here per se, but this section will probably change in order to fix these problems. Chapter 9. Ports, Grafts, and Mirrored Sheets This entire chapter will be rewritten in order to make it accurate. Chapter 12. Graphics 12.6.3 Port-specific Drawing Functions The PORT-DRAW-xxx functions have been discarded in favor of folding that layer into the medium layer. The specification will be changed to reflect this. There are also no functions with which to query device characteristics, such as resolution, color depth, and so on. Chapter 13. Drawing in Color There is a proposal to add a portable color map abstraction to CLIM, which are called "palettes". There is also a proposal to add "raster colors", which can be used to more directly model "deep" color displays with overlay planes. Chapter 13. Drawing in Color Chapter 14. Patterned Designs These two chapters are based on CLIM 1.0's "design-based" drawing model. Some members of the coalition claim this model is confusing and point out that there is not yet a complete implementation that can justify it. Supporters of the "design-based" drawing model feels that it reflects a powerful, abstract, and portable graphics model that is consistent with new trends in graphics on commonly available platforms. A plan under consideration is to carefully recast Chapter 13 so that it makes no references to the "design-based" drawing model, and recast Chapter 14 to extend Chapter 13 to support the more advanced model. A conforming CLIM implementation would not be required to implement the functionality described in Chapter 14. Chapter 15. Extended Stream Output 15.3 The Text Cursor 15.3.1 Text Cursor Protocol 15.3.2 Stream Text Cursor Protocol There is some question about the utility of advertising the cursor protocol. At the API level, cursor objects are not useful, but the May 6 document is intended to serve as a document for implementor as well, and these people do need to understand cursors. In any case, the specification has holes in the protocol for dealing with multiple cursors. Chapter 16. Output Recording 16.1 Output Records 16.1.1 The Basic Output Record Protocol 16.1.2 The Output Record "Database" Protocol There is a desire among all participants to unify some aspects of the sheet protocol and output record protocol. Doing so will cause most of the functions in this section (and some of the functions in Chapter 7) to be renamed. For SHEET-ADOPT-CHILD and ADD-OUTPUT-RECORD might be unified under the name SHEET-ADD-CHILD, SHEET-DISOWN-CHILD and DELETE-OUTPUT-RECORD might be unified under the name SHEET-DELETE-CHILD, OUTPUT-RECORD-PARENT would be renamed SHEET-PARENT, and so on. Chapter 21. Incremental Redisplay 21.3 Incremental Redisplay Protocol 21.4 Incremental Redisplay Stream Protocol The specification of the incremental redisplay protocol is presently rather dubious. Proposals include completely rewriting the sections, to discarding them from the specification entirely. Unfortunately, there is noone who thinks that the existing protocol is even the right thing. The disposition of these sections remains cloudy. Chapter 22. Extended Stream Input 22.2 Extended Input Stream 22.2.1 The Extended Input Stream Protocol 22.4 The Pointer Protocol As with the cursor objects, some members question the usefulness of advertising the pointer protocol. There are also holes in the protocol when it comes to dealing with multiple pointers. Chapter 22. Extended Stream Input 22.5 Pointer Tracking There is a minor issue regarding whether or not to use &KEY in the TRACKING-POINTER clauses. The open problem is that it may be difficult to detect the incompatible change from CLIM 1.1. Chapter 22. Extended Stream Input 22.6 Gesture Preprocessing It has been suggested that gesture preprocessing be discarded, as there are no contemplated clients of this facility. Chapter 25. Menu Facilities Chapter 26. Dialog Facilities These chapters need to specify more about how they interact with underlying gadget toolkits. There have also been various requests for additional functionality associated with the "exit boxes". Chapter 27. Command Processing 27.3 Command Menus It has been suggested that something like the "menu groups" from CLIM 0.9 should be reinstated. There is some dispute over the manner and extent to which the menu group paradigm should be modified. On the other hand, some members claim that the :MENU option of command tables fully subsumes menu groups. If this is the case, it may be sufficient to simply advertise the object used to represent the menu within the command table as a "menu group". Chapter 28. Application Frames 28.2 Defining and Creating Application Frames 28.6 Examples of Applications Chapter 29. Panes 29.3 Layout and Layout panes There are still some minor disagreements about the design of the pane description language and the layout options. Chapter 28. Application Frames 28.4 Generic Command Loop There is a proposal for breaking command loops down into their component pieces so that they can be more easily tailored. There is no disagreement here, but the proposal is incomplete as it stands. Chapter 30. Gadget Panes 30.2.1 Using Gadgets Some members dislike the new functionality of passing an optional functional argument for the various callback when calling MAKE-PANE to create a gadget. Supporters feel this allows a programmer to more easily and concisely customize callbacks for particular instances of gadget panes without having to resort to EQL-specializing the identifier argument for the various callback methods.   Received: from BBN.COM by LABS-N.BBN.COM id aa11798; 16 Jul 92 3:51 EDT Received: from mcsun.EU.net by BBN.COM id aa07451; 16 Jul 92 3:47 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA23249 (5.65b/CWI-2.170); Thu, 16 Jul 1992 09:47:29 +0200 Received: from nrb.UUCP by ub4b.buug.be (5.65c/ub4b_02) id AA02039; Thu, 16 Jul 1992 09:47:24 +0200 Received: from nrbmi1.ia.nrb.be by scosysv.nrb.be with SMTP (5.59/NRB25-f-eef-ev@nrb) id AA01814; Thu, 16 Jul 92 15:29:14 +0100 Date: Thu, 16 Jul 1992 09:39+0200 From: Vincent Keunen Reply-To: nrb!keunen@relay.EU.net Subject: Re: CLIM ftp server To: clim@nrbmi2.ia.nrb.be In-Reply-To: <9207151600.AA00980@void.ncsa.uiuc.edu> Message-Id: <19920716073900.6.KEUNEN@nrbmi1.ia.nrb.be> Date: Wed, 15 Jul 1992 18:00+0200 From: liberte@ncsa.uiuc.edu (Daniel LaLiberte) I recommend that folks add to a README for the whole directory, similar to what has been set up for the MCL2/contrib directory. It is useful to read a little bit about a package before downloading it. dan Good idea. I suggest the file be named ABSTRACTS as in the other directories. The README file could contain info about the directory and other stuff... vk =============================================================== Keunen Vincent Network Research Belgium R&D, Software Engineer Parc Industriel des Hauts-Sarts keunen@nrb.be 2e Avenue, 65 tel: +32 41 407282 B-4040 Herstal fax: +32 41 481170 BELGIUM ===============================================================   Received: from BBN.COM by LABS-N.BBN.COM id aa16806; 16 Jul 92 11:19 EDT Received: from [130.251.1.17] by BBN.COM id aa22290; 16 Jul 92 11:09 EDT Received: from automa.UUCP by carla.dist.unige.it with UUCP (5.61++/IDA-1.2.8) id AA14836; Thu, 16 Jul 92 17:09:11 +0200 Received: by (4.0/SMI-4.0) id AA08718; Thu, 16 Jul 92 13:41:45 +0200 Date: Thu, 16 Jul 92 13:41:45 +0200 From: marcob@automa.UUCP (Marco Boero) Message-Id: <9207161141.AA08718@> To: clim@bbn.com Dear Sirs, I'm using CLIM (on a SUN4 platform) and I'm interested in being included in the CLIM's users mailing list for future exchange of information. My E-mail address is as follows: marcob%automa@italy.eu.net (this should be replaced soon by the following: marcob@automa.it) Thank you. Best regards Marco Boero ------------------------------------------------------------------- AUTOMA Industrial Automation Systems, R&D Department Via al Molo Vecchio, Calata Gadda I-16126 Genova Italy phone: +39 10 2092 591 (voice) +39 10 203987 (fax) --------------------------------------------------------------------   Received: from BBN.COM by LABS-N.BBN.COM id aa25229; 17 Jul 92 4:01 EDT Received: from [192.44.1.1] by BBN.COM id aa17423; 17 Jul 92 3:56 EDT Received: by fhg.de (fhg1.fhg.de) with PRESMTP; Fri, 17 Jul 92 09:56:11 +0200 from FHG-GATEWAY Received: by fhg.de (fhg1.fhg.de) with UUCP; Fri, 17 Jul 92 09:55:26 +0200 from imldo Received: by iml.fhg.de with SMTP; Fri, 17 Jul 92 09:54:14 +0200 Date: Fri, 17 Jul 1992 09:52+0200 From: Stefan Bernemann Subject: proposals for meta-applications, frameworks, windows To: SWM@stony-brook.scrc.symbolics.com Cc: clim@BBN.COM In-Reply-To: <19920715172443.5.SWM@SUMMER.SCRC.Symbolics.COM> Message-Id: <19920717075249.2.STEFAN@ANNA.iml.fhg.de> Date: Wed, 15 Jul 1992 19:24 MEST From: Scott McKay Date: Wed, 15 Jul 1992 09:22 EDT From: Vincent Keunen Date: Tue, 14 Jul 1992 17:17+0200 From: Scott McKay No deep thought has been spent in this area. Nobody with a vested interest has submitted any proposal in this area, never mind a coherent proposal. As usual, concrete proposals are welcome. I haven't though deeply either, however, I think CLIM has a concept of applications (at least a word for the concept, cf define-APPLICATION-framework...). I think it's adequate. But... This following two paragraphs will sound a bit like I am scolding Mr. Keunen, but that's really not my intention. But this message is a good example of useful information that is not actually a concrete proposal. The reason I asked for a concrete proposal is that I myself have not ever had the need to use multiple application frames that interconnect beyond simply sharing data through an agreed-upon "database" of some sort. Therefore, I am not sure I can design a module that adequately serves the needs of people who do need such a thing. Therefore, I need one or more concrete proposals that describe exactly what people want to do. The more specific, the better; so a proposal complete with classes, generic functions, and examples of use is most desirable. So, while this input is useful, this is not what I mean by a "proposal". At the very least, a concrete proposal should outline precisely what is being accomplished, and documents a set of classes and generic functions on those classes. ... This won't be a concrete proposal either, I try to describe what's needed from our perspective. (The use of "we" in this message denotes people of our institute) Much of our background and experience with the use of window-based user interfaces was formed by the macintosh. Applications on the Macintosh are using the "document methaphor". That is, an application works on one or more "documents", an open document is associated with a window on the macintosh desktop. In terms of clim, such a "document window" would be an instance of an application frame. These document-windows can be freely moved on the macintosh-desktop, i.e. they are under the control of the server's window manager. As far as my limited experience with (MS)windows on a PC goes, things are different in that an application (e.g. an editor) is associated with an "host window" (forgive me the unprecise terms) and *inside* this window different document-windows can be created. This is, what could be done with clim by creating an application-frame-object with another one as its parent -- as far as I understand the documentation. However, this seems to confuse the window-managers at least on my mac (using clim1.0b with mcl 2.0bp3) and under genera (8.1 with clim1.0). BUT -- I don't want that behavior, at least as long as I'm not porting the application to PC-platforms. Under motif, there are as well applications with serveral "independant" windows, cf xman as an simple example. Summarizing, it should be possible to let an application consist of serveral (not neccessariliy limited at compile time) windows. These windows may have "equal" structure (like document-windows on the macintosh), but this need not to be. After this long prologue, where does this not fit into the clim model? I would use application frames to implement these different windows. But then there's no concept to say "these instances of application frame objects belong to or form one 'application'". Let me name this concept "activity". An activity is informed about what application frame objects are created, it manages some sort of communication between them. This can be implemented on top of clim, no problem. But, the top-level loop should be associated with an activity, not with individual frames. Having multiple processes and doing some careful synchronization, one can *emulate* this behavior, however this fails on platforms not supporting processes and, what is more, I feel it is conceptually better to have one top-level associated with an activity. (Like one top-level now "controls" serveral panes -- from this point of view, the document windows are somewhat like freely moveble panes). To implement this, (at least) two things are needed: First, a closer interaction with the window-magager of the display server. The activity (or the involved application frame object) must become informed when a user selects / activates / deactivates a (top-level) host window. In other words, instead of the special variable *application-frame* the should be something like *activiy* AND the activty must know about the "selected" or "active" application-frame. Different window systems have different meanings of windows being "active" or "selected", so that's not so trivial. But that's basically what I mean by "closer interaction". As far as I understand the 2.0 specs, the frame-managers try to adress this problem? The current solution, just binding the variable in the top-level-loop (having a per-process-binding) does not reflect "what's going on on the user's screen". Second, the top-level-loop must be more carefully designed where to get input from and where to do output. I think, it's ok to share one input-buffer among all frames of the activity. That's what clim now does do serve different panes and this can be done now already to implement one top-level-loop serving serveral frames (using only advertised clim functions!). However, the programmer must specify, where to do output, where to echo commands etc. Exampele: A (end-)user has entered a partial command in one frame (window), then he switches to another frame. In that case, he can of course only enter the arguments to the partial command, not a new command -- otherwise there would be a principally asychronus behavior, use processes if you need this. But, if the second frame has a pointer-documentation pane, the command loop should redirect the documentation to this pane, as this frame is now the user's focus. how command echoing should be done is event more application dependant, so these aspects must be specified by the programmer. I don't know if these statements are helpful, I could spend some more thoughts about it during the weekend. This mail seems to be long enough for now, so nice weekend to everybody - Stefan B. Mail: Stefan Bernemann ! Phone: +49-231-9743-139 c/o FhG IML Dortmund ! Fax: +49-231-9743-234 Emil-Figge-Str. 75 ! Email: berni@iml.fhg.de D-4600 Dortmund 50, FRG !   Received: from BBN.COM by LABS-N.BBN.COM id aa29207; 17 Jul 92 11:15 EDT Received: from mcsun.EU.net by BBN.COM id aa02012; 17 Jul 92 11:07 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA28000 (5.65b/CWI-2.170); Fri, 17 Jul 1992 17:07:04 +0200 Received: from nrb.UUCP by ub4b.buug.be (5.65c/ub4b_02) id AA11064; Fri, 17 Jul 1992 16:19:20 +0200 Received: from nrbmi1.ia.nrb.be by scosysv.nrb.be with SMTP (5.59/NRB25-f-eef-ev@nrb) id AA02233; Thu, 16 Jul 92 21:48:32 +0100 Date: Thu, 16 Jul 1992 15:58+0200 From: Vincent Keunen Reply-To: nrb!keunen@relay.EU.net Subject: proposals for meta-applications, frameworks, windows...(long message) To: clim@nrbmi2.ia.nrb.be In-Reply-To: <19920715172443.5.SWM@SUMMER.SCRC.Symbolics.COM> Message-Id: <19920716135813.7.KEUNEN@nrbmi1.ia.nrb.be> Date: Wed, 15 Jul 1992 19:24+0200 From: Scott McKay [...] Global variables are simply a special case of an agreed upon "database". There are more flexible ways to do this, but global variables are not inherently bad for this purpose. Suppose I have 2 app-frames displaying the state of a network. The data about the network is to be shared between the two, but the "current view style" is app-specific. Therefore, i would use state variables for the "current view style". But what do I use for the state of the network? If I use global variables, they are accessible to all applications... Of course I could use packages, but it's a "side solution", not a "hierarchical one". There should be state variables for a type of application (what I called a meta-app) that are shared by all app-instances of the type. I believe that a normal CLIM application frame can serve exactly the function of what you call a "meta-application". Can I use child/parent applications? How does that fit in the clim theory? A window in CLIM is the same as a window in X or MCL or whatever. A pane is a window whose parent is an application frame. An application frame is an object that groups together some state variables, (optionally) a process, a command loop, and zero or more panes. Can you open/close panes independently and have them "float around" independently also? What about the active one and the input "focus"? I certainly don't think that CLIM 2.0 should be breaking ground in the area of "virtual distributed desktops". Maybe later... Is it really breaking ground? Isn't that trying to clarify concepts we're using and placing them in a general context? vk =============================================================== Keunen Vincent Network Research Belgium R&D, Software Engineer Parc Industriel des Hauts-Sarts keunen@nrb.be 2e Avenue, 65 tel: +32 41 407282 B-4040 Herstal fax: +32 41 481170 BELGIUM ===============================================================   Received: from BBN.COM by LABS-N.bbn.COM id aa29108; 17 Jul 92 10:59 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa01165; 17 Jul 92 10:49 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1109809; 17 Jul 1992 10:51:05-0400 Date: Fri, 17 Jul 1992 10:51-0400 From: Scott McKay Subject: proposals for meta-applications, frameworks, windows To: berni@iml.fhg.de cc: clim@BBN.COM In-Reply-To: <19920717075249.2.STEFAN@ANNA.iml.fhg.de> Message-ID: <19920717145121.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 17 Jul 1992 03:52 EDT From: Stefan Bernemann This won't be a concrete proposal either, I try to describe what's needed from our perspective. (The use of "we" in this message denotes people of our institute) This is enormously helpful to me. Thanks.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa29968; 17 Jul 92 12:44 EDT Received: by KARIBA.BBN.COM id aa11711; 17 Jul 92 12:34 EDT To: clim@BBN.COM Subject: Re: proposals for meta-applications, frameworks, windows In-reply-to: Stefan Bernemann's message of Fri, 17 Jul 92 09:52:00 +0200. <19920717075249.2.STEFAN@ANNA.iml.fhg.de> Reply-To: jmorrill@BBN.COM Date: Fri, 17 Jul 92 12:33:48 -0400 Message-ID: <1116.711390828@bbn.com> From: Jeff Morrill These ideas are interesting. Let me amplify a few points that seem important. 1. This concept of an "activity" serves to separate the top-level loop (which provides the input context) from the frames (which provide the screen real-estate). In my mind, this separation is the key element of this "desktop" metaphor that we are discussing. 2. The activity must know what frames it manages, and be capable of performing some window-manager types of operations on them. I don't advocate applications that try too hard to override the native window-manager; but I have found that operations such as iconify/deiconify and stack-on-top/bottom are occasionally appropriate. Also, when the EXIT command is executed, its frames must of course go away. One would also need a form of start-frame that was something like the start-slave-frame that I previously posted, except that it also pushes the frame onto one of the state variables of the activity. 3. The top-level loop must do redisplay. Something like REDISPLAY-ACTIVITY-PANES would do just fine if it just called REDISPLAY-FRAME-PANES on all of the associated frames. 4. The activity must have methods to choose *standard-input*, *standard-output*, and so on. This is indeed tricky for the reason that the top-level loop is now decoupled from the frames. If we associate *standard-input* with some frame pane, and the user makes that frame go away, what should happen? One possible solution is to give one of the frames special status, and to use that frame for *standard-input* and *standard-output*. If it goes away, then the whole activity goes away. The xman application has this feature. This solution would enable an "activity" to be implemented as a subclass of application-frame. jeff morrill   Received: from BBN.COM by LABS-N.bbn.COM id aa20582; 19 Jul 92 22:05 EDT Received: from eola.cs.ucf.edu by BBN.COM id aa08404; 19 Jul 92 21:49 EDT Received: by eola.cs.ucf.edu (5.61/1.34) id AA03800; Sun, 19 Jul 92 21:47:02 EDT Date: Sun, 19 Jul 92 21:47:02 EDT From: hull@eola.cs.ucf.edu (Richard Hull) Message-Id: <9207200147.AA03800@eola.cs.ucf.edu> To: clim@BBN.COM Subject: Duplicate Nodes in Format-Graph-From-Roots (Allegro CLIM) Several weeks ago I had a problem with duplicate nodes appearing when I was running format-graph-from-roots under Symbolics CLIM 1.1 with the keyword option :merge-duplicates. The problem was (as was explained to me by Markus Fischer of Symbolics), that I wasn't aware of the undocumented keyword :duplicates-test that I needed to include. Using :duplicates-test #'equal worked fine on the Symbolics, but when I ran the code on a SUN workstation under Allegro CLIM I now get the duplicate nodes again! Did Allegro implement this functionality of format-graph-from-roots differently? Any help would be greatly appreciated. Thank you. Richard Hull University of Central Florida AI Labs   Received: from BBN.COM by LABS-N.BBN.COM id aa23052; 20 Jul 92 3:58 EDT Received: from fenrix.si.no by BBN.COM id aa21067; 20 Jul 92 3:53 EDT Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.23) id AA05758; Mon, 20 Jul 92 09:35:25 +0200 Date: Mon, 20 Jul 92 09:35:25 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9207200728.AAmonsun04603@D> To: clim@bbn.com Subject: mac gestures Hi CLIM'ers I'm using CLIM 1.0 with MCL 2.0b1p3 (on a Mac IIcx) and am experimenting with gestures. This message is mostly Mac/MCL specific I guess, so please read it Apple/ILA folks! First of all I need to know the mapping from mouse clicks and modifier buttons to gestures. I have found the :select, :edit and :delete gestures as click, alt-click (option-click) and shift-click, but would like a full list. When I use the :delete gesture in a translator the presentations highlights OK but I get a beep when clicking. Replacing :delete with :edit works fine, makes the translator run without a beep. When I try the :menu gesture in the translator it displays R: command in the pointer documentation pane, but how can I click the right button on a one button Mac mouse? A general comment: I like working with CLIM, but it is annoying not having any MCL specific documentation. And while everyone is talking about CLIM 1.1 and 2.0 there still hasn't come any new releases since CLIM 1.0 beta for MCL, not even new patches. I look forward to getting more MCL specific support in the future. Thanks! Regards, Hallvard Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Date: Mon, 20 Jul 92 5:06:45 EDT From: Nichael Cramer To: clim@bbn.com Subject: Three Questions [RUNNING: CLIM-1.1, LUCID, SUN] 1] How can the fore/background for an existing window be changed? The :STREAM-BACKGROUND init-form works fine when the window is created, but after the window is created there doesn't seem to be an obvious way to do this (nor can I find anything in the documentation I have). BTW, naively setting the clim::BACKGROUND slot doesn work (presumably because the context/gc's aren't affected?) 2] Forms inside a DEFINE-APPLICATION (e.g. *MY-STYLE* in the following): (define-application-frame MY-FRAME () () (:panes ((MY-PANE :APPLICATION :DEFAULT-TEXT-STYLE *MY-STYLE*) . . . seem to be eval'ed at compile/load time (i.e. as opposed to at run/create-time). Is this correct. Is there anyway to trick this into eval-ing at the later time? 3] How can I get my hands on the frame when a pane is being created? The slots pointing to the frame don't seem to be set until after the initialize-instance is run and the standard variables (e.g. *APPLICATION-FRAME*) don't seem to be set (at least not to the right thing). Thanks Nichael   Received: from BBN.COM by LABS-N.BBN.COM id aa27011; 20 Jul 92 9:33 EDT Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa29526; 20 Jul 92 9:23 EDT Received: from LILIKOI.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 865652; 20 Jul 1992 09:24:26-0400 Date: Mon, 20 Jul 1992 09:36-0400 From: Mark Nahabedian Subject: Three Questions To: ncramer@BBN.COM, clim@BBN.COM In-Reply-To: The message of 20 Jul 1992 05:06 EDT from Nichael Cramer Message-ID: <19920720133653.9.NAHA@LILIKOI.SCRC.Symbolics.COM> Character-Type-Mappings: (1 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB") Fonts: CPTFONT, CPTFONTCB Here is something from my init file that I believe answers your question about changing the background: (clim:define-command (1com-invert-video0 :name t :command-table clim:user-command-table) () (dolist (medium (clim:frame-panes clim:*application-frame*)) (ignore-errors (rotatef (clim:medium-foreground medium) (clim:medium-background medium)))))   Received: from BBN.COM by LABS-N.BBN.COM id aa27640; 20 Jul 92 10:24 EDT Received: from gatech.edu by BBN.COM id aa02368; 20 Jul 92 10:13 EDT Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA14429 for clim@bbn.com; Mon, 20 Jul 92 10:13:18 EDT Received: from pravda.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA15778; for clim@bbn.com; Mon, 20 Jul 92 10:13:15 EDT Received: from kant.gatech.edu (kant.cc.gatech.edu) by pravda.cc.gatech.edu (4.1/SMI-4.1) id AA07399; Mon, 20 Jul 92 10:13:12 EDT Date: Mon, 20 Jul 1992 10:09-0400 From: Richard Billington Subject: Re: proposals for meta-applications, frameworks, windows To: clim@bbn.com In-Reply-To: <1116.711390828@bbn.com> Supersedes: <19920720135251.0.BUFF@kant.gatech.edu> Comments: Sorry, I hit before I was quite through. Message-Id: <19920720140908.1.BUFF@kant.gatech.edu> This is off the top of my head, so don't hold me to it being a complete, formal proposal - it ain't. There are two different situations: one is that you want to have most of a CLIM applications real-estate power in more than one frame; the other is where you want to have semi-independent applications using all of CLIM's power but able to be controllable at the window manager level. Let me give examples of each: Real-estate in more than one frame - I have an application that needs lots of different layouts, sometimes I'd like to have more than one of those layouts on the screen at the same time, and every possible set of up to (say) three is possibly desireable. Semi-independent applications - I have an application that allows someone to browse a database and to modify it. Examining, adding, or changing particular pieces of information in that database, I'd spawn seperate examiner/editor applications - when they're done they return. I guess the big difference to me is whether or not the family of applications shares a command table and a process. In my first example, they would. In my second, they wouldn't. However, there's also the matter of controlling a family of applications as a unit. Within the context of the window system, these windows are a loosely coupled unit. If I kill one I should probably find myself looking at a sib or parent. If I kill a parent, its children should die (or I shouldn't be allowed to kill it without being notified of its children's imminent death). If a frame is temporary it should get killed off when clicked off of (same as a menu). Finally, a mechanism for defining a frame family, so that you could define frame-family commands, which all members of the frame family could access. (define-frame-family ((frame-type-list list-of-application-frame-types))) (make-annotation-frame ... :family (:parent *application-frame*) (:temporary nil) ...) OR (make-annotation-frame ... :family (:sibling *application-frame*) ...) ;; Functions for getting at other members of the application-frame's family. (frame-children (frame application-frame)) <= method returns list of frames (frame-descendents (frame applcation-frame)) <= method returns list of trees of frames (i.e. there's an entry for each child, but the entry is a list reflecting the structure of descendents). (parent (frame application-frame)) <= method returns a frame (frame-siblings (frame application-frame)) <= method returns a list of frames (frame-family (frame application-frame)) <= method returns a tree with the root being the CLOS-object representing the family, and then the frames organized heirarchically. modify frame-exit to take a (:switch-to frame) argument with default being the parent (if there is one) or a sib (otherwise).   Received: from BBN.COM by LABS-N.BBN.COM id aa27933; 20 Jul 92 10:46 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa03186; 20 Jul 92 10:37 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1110618; 20 Jul 1992 10:00:07-0400 Date: Mon, 20 Jul 1992 10:00-0400 From: Scott McKay Subject: Three Questions To: ncramer@BBN.COM, clim@BBN.COM In-Reply-To: The message of 20 Jul 1992 05:06 EDT from Nichael Cramer Message-ID: <19920720140026.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 20 Jul 1992 05:06 EDT From: Nichael Cramer [RUNNING: CLIM-1.1, LUCID, SUN] 1] How can the fore/background for an existing window be changed? The :STREAM-BACKGROUND init-form works fine when the window is created, but after the window is created there doesn't seem to be an obvious way to do this (nor can I find anything in the documentation I have). BTW, naively setting the clim::BACKGROUND slot doesn work (presumably because the context/gc's aren't affected?) :STREAM-BACKGROUND has a misleading name, which is probably fooling you. Just use (SETF (MEDIUM-BACKGROUND stream) color). This has :AFTER methods that update the gcontext. 2] Forms inside a DEFINE-APPLICATION (e.g. *MY-STYLE* in the following): (define-application-frame MY-FRAME () () (:panes ((MY-PANE :APPLICATION :DEFAULT-TEXT-STYLE *MY-STYLE*) . . . seem to be eval'ed at compile/load time (i.e. as opposed to at run/create-time). Is this correct. Is there anyway to trick this into eval-ing at the later time? It's a bug that it gets eval'ed at compile time. It is intentional that it gets eval'ed at load time. 3] How can I get my hands on the frame when a pane is being created? The slots pointing to the frame don't seem to be set until after the initialize-instance is run and the standard variables (e.g. *APPLICATION-FRAME*) don't seem to be set (at least not to the right thing). Odd, I could swear that the pane layout code binds *APPLICATION-FRAME*. Maybe this fix was made after Lucid released CLIM 1.1. Try this: (in-package :clim) (defmethod initialize-instance :after ((frame application-frame) &key pane-descriptions parent left top right bottom width height) ;; If parent is NIL, assume that the caller of MAKE-APPLICATION-FRAME is going ;; to take care of window initialization. (when parent (multiple-value-bind (main-window panes) (create-windows-from-description frame pane-descriptions parent :left left :top top :right right :bottom bottom :width width :height height) (setf (slot-value frame 'top-level-window) main-window) (setf (slot-value frame 'panes) panes) (let ((*application-frame* frame)) (layout-frame-panes frame main-window)))))   Received: from BBN.COM by LABS-N.BBN.COM id aa27503; 20 Jul 92 10:16 EDT Received: from gatech.edu by BBN.COM id aa01640; 20 Jul 92 9:57 EDT Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA14142 for clim@bbn.com; Mon, 20 Jul 92 09:57:05 EDT Received: from pravda.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA15534; for clim@bbn.com; Mon, 20 Jul 92 09:56:59 EDT Received: from kant.gatech.edu (kant.cc.gatech.edu) by pravda.cc.gatech.edu (4.1/SMI-4.1) id AA07337; Mon, 20 Jul 92 09:56:56 EDT Date: Mon, 20 Jul 1992 09:52-0400 From: Richard Billington Subject: Re: proposals for meta-applications, frameworks, windows To: clim@bbn.com In-Reply-To: <1116.711390828@bbn.com> Message-Id: <19920720135251.0.BUFF@kant.gatech.edu> This is off the top of my head, so don't hold me to it being a complete, formal proposal - it ain't. There are two different situations: one is that you want to have most of a CLIM applications real-estate power in more than one frame; the other is where you want to have semi-independent applications using all of CLIM's power but able to be controllable at the window manager level. Let me give examples of each: Real-estate in more than one frame - I have an application that needs lots of different layouts, sometimes I'd like to have more than one of those layouts on the screen at the same time, and every possible set of up to (say) three is possibly desireable. Semi-independent applications - I have an application that allows someone to browse a database and to modify it. Examining, adding, or changing particular pieces of information in that database, I'd spawn seperate examiner/editor applications - when they're done they return. I guess the big difference to me is whether or not the family of applications shares a command table and a process. In my first example, they would. In my second, they wouldn't. However, there's also the matter of controlling a family of applications as a unit. Within the context of the window system, these windows are a loosely coupled unit. If I kill one I should probably find myself looking at a sib or parent. If I kill a parent, its children should die (or I shouldn't be allowed to kill it without being notified of its children's imminent death). If a frame is temporary it should get killed off when clicked off of (same as a menu). (make-annotation-frame ... (:parent *application-frame*) (:temporary nil) ...) OR (make-annotation-frame ... (:sibling *application-frame*) ...) ;; Functions for getting at other members of the application-frame's family. (frame-children (frame application-frame)) <= method (frame-descendents (frame applcation-frame)) <= method (parent (frame application-frame)) <= method (frame-siblings (frame application-frame)) <= method Modify frame-exit to take a (:switch-to frame) argument.   Received: from BBN.COM by LABS-N.BBN.COM id aa28260; 20 Jul 92 11:05 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa03668; 20 Jul 92 10:46 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA05604; Mon, 20 Jul 92 07:46:00 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA00437; Mon, 20 Jul 92 07:38:40 PDT Date: Mon, 20 Jul 92 07:38:40 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9207201438.AA00437@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: Re: proposals for meta-applications, frameworks, windows I tend to agree with R. Billington. In the Motif world our large applications tend to utilize the "Real-Estate" methodology more than the "semi-independent application" methodology.   Received: from BBN.COM by LABS-N.BBN.COM id aa28410; 20 Jul 92 11:17 EDT Received: from mwunix.mitre.org by BBN.COM id aa04630; 20 Jul 92 11:07 EDT Return-Path: Received: from cypress.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA21657; Mon, 20 Jul 92 11:05:13 -0400 Received: by cypress.mitre.org (4.1/SMI-4.1) id AA03589; Mon, 20 Jul 92 11:11:54 EDT Date: Mon, 20 Jul 92 11:11:54 EDT From: gmw@cypress.mitre.org (Gregory M. Whittaker) Message-Id: <9207201511.AA03589@cypress.mitre.org> To: clim@bbn.com Subject: Post-script output in CLIM-2.0? Cc: greg@mitre.org, info@franz.com I'm just getting familiar with CLIM-2.0.alpha and have immediately run into some incompatabilities. I don't know if these are transient, superficial, or permanent. I would like to make use of the CLIM-1.0 with-output-to-postscript-stream capability, but do not know what the appropriate form would be called in CLIM-2.0. Also I would like to find some encapsulated PS output mode as well. Does anyone know about this? Could you add me to the distribution list? -------- Cordially, Gregory M. Whittaker, The MITRE Corporation Center for Advanced Aviation System Development Internet: greg@mitre.org 7525 Colshire Drive Phone: (703) 883-5549 McLean Virginia 22102-3481 FAX: (703) 883-1226 Mail Stop: W215   Received: from BBN.COM by LABS-N.BBN.COM id aa29627; 20 Jul 92 13:02 EDT Received: from mwunix.mitre.org by BBN.COM id aa09031; 20 Jul 92 12:55 EDT Return-Path: Received: from cypress.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA28497; Mon, 20 Jul 92 12:53:15 -0400 Received: by cypress.mitre.org (4.1/SMI-4.1) id AA03636; Mon, 20 Jul 92 12:59:54 EDT Date: Mon, 20 Jul 92 12:59:54 EDT From: gmw@cypress.mitre.org (Gregory M. Whittaker) Message-Id: <9207201659.AA03636@cypress.mitre.org> To: CLIM@bbn.com Subject: Postscript Output in CLIM-2.0 ? Cc: greg@mitre.org I'm just getting familiar with CLIM-2.0.alpha and have immediately run into some incompatabilities. I don't know if these are transient, superficial, or permanent. I would like to make use of the CLIM-1.0 with-output-to-postscript-stream capability, but do not know what the appropriate form would be called in CLIM-2.0. Also I would like to find some encapsulated PS output mode as well. Does anyone know about this? Could you add me to the distribution list? -------- Cordially, Gregory M. Whittaker, The MITRE Corporation Center for Advanced Aviation System Development Internet: greg@mitre.org 7525 Colshire Drive Phone: (703) 883-5549 McLean Virginia 22102-3481 FAX: (703) 883-1226 Mail Stop: W215   Received: from BBN.COM by LABS-N.BBN.COM id aa29695; 20 Jul 92 13:05 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa09210; 20 Jul 92 12:59 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1110770; 20 Jul 1992 13:00:46-0400 Date: Mon, 20 Jul 1992 13:01-0400 From: Scott McKay Subject: Post-script output in CLIM-2.0? To: gmw@cypress.mitre.org, clim@BBN.COM cc: greg@mitre.org, info@franz.com In-Reply-To: <9207201511.AA03589@cypress.mitre.org> Message-ID: <19920720170106.1.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 20 Jul 1992 11:11 EDT From: "Gregory M. Whittaker" I'm just getting familiar with CLIM-2.0.alpha and have immediately run into some incompatabilities. I don't know if these are transient, superficial, or permanent. I would like to make use of the CLIM-1.0 with-output-to-postscript-stream capability, but do not know what the appropriate form would be called in CLIM-2.0. Also I would like to find some encapsulated PS output mode as well. Does anyone know about this? WITH-OUTPUT-TO-POSTSCRIPT-STREAM is not yet implemented in CLIM 2.0 Could you add me to the distribution list? -------- Cordially, Gregory M. Whittaker, The MITRE Corporation Center for Advanced Aviation System Development Internet: greg@mitre.org 7525 Colshire Drive Phone: (703) 883-5549 McLean Virginia 22102-3481 FAX: (703) 883-1226 Mail Stop: W215   Received: from BBN.COM by LABS-N.BBN.COM id aa01477; 20 Jul 92 15:33 EDT Received: from sask.usask.ca by BBN.COM id aa16722; 20 Jul 92 15:27 EDT Received: from access.USask.Ca by SASK.USask.CA (PMDF #12333) id <01GMLQ7XZ9XS002M5N@SASK.USask.CA>; Mon, 20 Jul 1992 13:29 CST Received: by access.USask.Ca (5.57/GLH-1.0); Mon, 20 Jul 92 13:26:55 -0600 id AA01154 for clim@bbn.com Received: from skaries.USask.ca by skdad.USask.ca (4.1/SMI-4.1) id AA23328; Mon, 20 Jul 92 13:26:49 CST Date: Mon, 20 Jul 92 13:26:47 CST From: coulman@skdad.usask.ca (Randy Coulman) Subject: Menu item inheritance in command tables To: clim@bbn.com (Clim Users Mailing List) Message-id: <9207201926.AA23328@skdad.USask.ca> X-Envelope-to: clim@bbn.com X-Mailer: ELM [version 2.3 PL11] I am implementing a system which has two layouts. The two layouts have some commands in common, but others are different. So, I've defined separate command tables for the two. I then defined a parent command table that contains the common commands and the other two command tables inherit from this parent command table. So far, so good. The problem is that the menus for the two interfaces do not display the items from the parent command table. I searched back in my archives of this list and found this subject discussed before. It seems that an implementation decision was made that menu items should not be inherited in command tables, because the implementers felt that this was wrong for most cases. This may be true, but for my case, it is not wrong. I can solve the problem by using add-menu-item-to-command-table to add menu items to the child command tables for each common command. Since my requirements are quite simple, this isn't to bad. However, if someone had many levels of inheritance or many inherited commands, this technique would soon grow quite unwieldy. Would it be possible/desirable to add a keyword argument somewhere to allow this type of functionality? Something along the lines of the :inherited keyword to map-over-command-table-commands would do nicely. Any comments? Also, does anyone have a better approach? I considered defining two different versions of the common commands, but decided against it. It wouldn't be too hard to return to that technique, if someone has convincing arguments that things should be done that way. Thanks, Randy -- Randy A. Coulman | ARIES Laboratory | Department of Computational Science coulman@cs.Usask.ca | University of Saskatchewan | Saskatoon, SK S7N 0W0   Received: from BBN.COM by LABS-N.BBN.COM id aa02646; 20 Jul 92 17:01 EDT Received: by harvard.harvard.edu (5.54/a0.25) (for clim) id AA09442; Mon, 20 Jul 92 16:55:45 EDT Received: from gatech.UUCP by gatech.edu (4.1/Gatech-9.1) id AA22868 for bbn!clim; Mon, 20 Jul 92 16:51:24 EDT Received: from gatech.edu by gatech.UUCP (4.1/SMI-4.1) id AA28088; Mon, 20 Jul 92 16:51:02 EDT Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA22861 for clim@bbn; Mon, 20 Jul 92 16:50:59 EDT Received: from pravda.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA21460; for clim@bbn; Mon, 20 Jul 92 16:50:57 EDT Received: from kant.gatech.edu (kant.cc.gatech.edu) by pravda.cc.gatech.edu (4.1/SMI-4.1) id AA10053; Mon, 20 Jul 92 16:50:55 EDT Date: Mon, 20 Jul 1992 16:46-0400 From: harvard!gatech!cc!buff Subject: standard output and frames To: bbn!clim Message-Id: <19920720204656.3.BUFF@kant.gatech.edu> Sender: harvard!gatech!cc!buff Source-Info: From (or Sender) name not authenticated. I've got an application which shouldn't echo anything to the screen - i.e., there's no keyboard input expected, and if there is any, I'd like it to be ignored not echoed. Currently, this stuff all gets echoed to a pane in my application which happens to be the one chosen by the default frame-standard-output. I'm at a loss as to how to customize frame-standare-output to do what I want. I defined it to return NIL ... well, you can imagine, that doesn't work (but I had to try it). This behaviour was available in DW (Symbolics) by specifying :top-level (dw:default-command-top-level :echo-stream ignore) in the frame definition.   Received: from BBN.COM by LABS-N.BBN.COM id aa03421; 20 Jul 92 18:04 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa25805; 20 Jul 92 18:00 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1110960; 20 Jul 1992 18:01:37-0400 Date: Mon, 20 Jul 1992 18:01-0400 From: Scott McKay Subject: Menu item inheritance in command tables To: coulman@skdad.usask.ca, clim@BBN.COM In-Reply-To: <9207201926.AA23328@skdad.USask.ca> Message-ID: <19920720220159.1.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 20 Jul 1992 15:26 EDT From: Randy Coulman I am implementing a system which has two layouts. The two layouts have some commands in common, but others are different. So, I've defined separate command tables for the two. I then defined a parent command table that contains the common commands and the other two command tables inherit from this parent command table. So far, so good. The problem is that the menus for the two interfaces do not display the items from the parent command table. I searched back in my archives of this list and found this subject discussed before. It seems that an implementation decision was made that menu items should not be inherited in command tables, because the implementers felt that this was wrong for most cases. This may be true, but for my case, it is not wrong. I can solve the problem by using add-menu-item-to-command-table to add menu items to the child command tables for each common command. Since my requirements are quite simple, this isn't to bad. However, if someone had many levels of inheritance or many inherited commands, this technique would soon grow quite unwieldy. Would it be possible/desirable to add a keyword argument somewhere to allow this type of functionality? Something along the lines of the :inherited keyword to map-over-command-table-commands would do nicely. Any comments? Also, does anyone have a better approach? I considered defining two different versions of the common commands, but decided against it. It wouldn't be too hard to return to that technique, if someone has convincing arguments that things should be done that way. I will implement an :INHERIT-MENU option for CLIM 2.0, since this has been requested so many times. The following will do the trick in CLIM 1.1, but this will not necessarily be exactly what will appear in CLIM 2.0. ---------------- (in-package :clim) (defun make-command-table (name &key inherit-from menu inherit-menu (errorp t)) (check-type name symbol) (check-type inherit-from list) (let ((command-table (find-command-table name :errorp nil))) (when command-table (ecase errorp ((t) (cerror "Remove the command table and proceed" 'command-table-already-exists :format-string "Command table ~S already exists" :format-args (list name)) (remhash name *all-command-tables*)) ((nil) (remhash name *all-command-tables*)))) (setq command-table (make-instance 'standard-command-table :name name :inherit-from inherit-from)) (process-command-table-menu command-table menu inherit-menu) (setf (gethash name *all-command-tables*) command-table) command-table)) (defun process-command-table-menu (command-table menu inherit-menu) (check-type menu list) (check-type inherit-menu boolean) (when inherit-menu (dolist (comtab (command-table-inherit-from command-table)) (let* ((comtab (find-command-table comtab :errorp nil)) (menu (and comtab (slot-value comtab 'menu)))) (when menu (dovector (element menu) (destructuring-bind (string keystroke (type value &rest options)) element (apply #'add-menu-item-to-command-table command-table string type value :keystroke keystroke :errorp nil options))))))) (dolist (item menu) (let* ((string (pop item)) (type (pop item)) (value (pop item)) (options item)) (apply #'add-menu-item-to-command-table command-table string type value :errorp nil options)))) (defmacro define-command-table (name &key inherit-from (menu nil menu-p) inherit-menu) #+Genera (declare (zwei:indentation 1 1)) (setf (compile-time-property name 'command-table-name) t) `(define-command-table-1 ',name :inherit-from ',inherit-from ,@(and menu-p `(:menu ',menu)) :inherit-menu ,inherit-menu)) (defun define-command-table-1 (name &key inherit-from (menu nil menu-p) inherit-menu) (check-type name symbol) (check-type inherit-from list) (when (null inherit-from) (setq inherit-from (list (command-table-name *global-command-table*)))) (let ((old-command-table (find-command-table name :errorp nil))) (cond (old-command-table (setf (command-table-inherit-from old-command-table) inherit-from) (when menu-p ;; Only discard the old menu if a new one was explicitly ;; supplied. This keeps us from throwing away menu items ;; that the user asked for via :MENU to DEFINE-COMMAND. (setf (slot-value old-command-table 'menu) nil)) (process-command-table-menu old-command-table menu inherit-menu) (setf (slot-value old-command-table 'keystrokes) nil) old-command-table) (t (make-command-table name :inherit-from inherit-from :menu menu :inherit-menu inherit-menu)))))   Received: from BBN.COM by LABS-N.BBN.COM id aa07501; 21 Jul 92 3:55 EDT Received: from gmdzi.gmd.de by BBN.COM id aa02881; 21 Jul 92 3:50 EDT Received: from localhost by gmdzi.gmd.de with SMTP id AA07619 (5.65c/IDA-1.4.4 for clim@bbn.com); Tue, 21 Jul 1992 09:49:35 +0200 Message-Id: <199207210749.AA07619@gmdzi.gmd.de> To: clim@bbn.com Cc: ralph.hensel@gmd.de Subject: subscribe in the clim mailing list. Date: Tue, 21 Jul 92 09:49:34 +0200 From: hensel@gmdzi.gmd.de X-Mts: smtp Hallo, would you please add me to your mailing list. Ralph Hensel German National Research Center for Computer Science (GMD-FIT.KI) P.O. Box 1316, D-5205 Sankt Augustin, Germany mail:hensel@gmdzi.gmd.de fax:+49-2241-14-2889 phone:+49-2241-14-1   Received: from BBN.COM by LABS-N.BBN.COM id aa17416; 21 Jul 92 18:51 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa03017; 21 Jul 92 18:37 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1111648; 21 Jul 1992 18:38:59-0400 Date: Tue, 21 Jul 1992 18:39-0400 From: Scott McKay Subject: CLIM command-table bug To: mf%sger.uucp@BBN.COM, clim@BBN.COM, rwk@crl.dec.com In-Reply-To: <19920610094740.4.MF@FUJI-SAN.SGER.UUCP> Message-ID: <19920721223928.1.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 10 Jun 1992 05:47 EDT From: Markus Fischer Date: Tue, 9 Jun 1992 23:19+0200 From: "Robert W. Kerns" Could someone please explain to me the logic of having keystrokes not be inherited by command tables?? DEFINE-COMMAND-TABLE now takes a :INHERIT-MENU option that tells the new command table to inherit menu items and keystrokes from the parents. It seems to me that this renders CLIM command tables completely useless if you care about inheritance, and you use keystrokes. How can it possibly be sane for the inheritance of keystrokes and other attributes to be different??? If keystrokes were inherited, and you wanted to use a different set of keystrokes in some situation, define the commands in one command table, the keystrokes in another, and use whichever you want, depending on whether or not you want the keystrokes. This is elementary object-oriented-programming modularity. No such modularity is possible if they follow different rules. I don't know about keystrokes, because I don't use them, but I think menu items aren't inherited either, and I find that quite bad, too. Markus Fischer, MF@SGER.UUCP Mergenthaler Allee 77-81 Consulting Services W-6236 Eschborn, Germany Symbolics Systemhaus GmbH Phone: +49 6196 47220, Fax 481116   Received: from BBN.COM by LABS-N.BBN.COM id aa17385; 21 Jul 92 18:43 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa03031; 21 Jul 92 18:37 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1111649; 21 Jul 1992 18:39:12-0400 Date: Tue, 21 Jul 1992 18:39-0400 From: Scott McKay Subject: CLIM command-table bug To: mf%sger.uucp@BBN.COM, clim@BBN.COM, rwk@crl.dec.com In-Reply-To: <19920610094740.4.MF@FUJI-SAN.SGER.UUCP> Supersedes: <19920721223928.1.SWM@SUMMER.SCRC.Symbolics.COM> Message-ID: <19920721223941.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 10 Jun 1992 05:47 EDT From: Markus Fischer Date: Tue, 9 Jun 1992 23:19+0200 From: "Robert W. Kerns" Could someone please explain to me the logic of having keystrokes not be inherited by command tables?? DEFINE-COMMAND-TABLE now takes a :INHERIT-MENU option that tells the new command table to inherit menu items and keystrokes from the parents. :INHERIT-MENU defaults to NIL. It seems to me that this renders CLIM command tables completely useless if you care about inheritance, and you use keystrokes. How can it possibly be sane for the inheritance of keystrokes and other attributes to be different??? If keystrokes were inherited, and you wanted to use a different set of keystrokes in some situation, define the commands in one command table, the keystrokes in another, and use whichever you want, depending on whether or not you want the keystrokes. This is elementary object-oriented-programming modularity. No such modularity is possible if they follow different rules. I don't know about keystrokes, because I don't use them, but I think menu items aren't inherited either, and I find that quite bad, too. Markus Fischer, MF@SGER.UUCP Mergenthaler Allee 77-81 Consulting Services W-6236 Eschborn, Germany Symbolics Systemhaus GmbH Phone: +49 6196 47220, Fax 481116   Received: from BBN.COM by LABS-N.BBN.COM id aa27903; 22 Jul 92 14:01 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa03844; 22 Jul 92 13:57 EDT Received: from WATERMELON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1112151; 22 Jul 1992 13:58:13-0400 Date: Wed, 22 Jul 1992 13:58-0400 From: John G. Aspinall Subject: Re: CLIM question To: gmw@cypress.mitre.org, JGA@STONY-BROOK.SCRC.Symbolics.COM, greg@mitre.org cc: CLIM@bbn.com, lwolf@franz.com In-Reply-To: <9207221657.AA00409@cypress.mitre.org> Message-ID: <19920722175810.2.JGA@WATERMELON.SCRC.Symbolics.COM> Date: Wed, 22 Jul 1992 12:57 EDT From: gmw@cypress.mitre.org (Gregory M. Whittaker) I have been working with CLIM-2.0.alpha and just getting familiar with some of the basic properties of CLIM geometry. I don't know how much of what I am discovering is merely an artifact of the alpha version and how much is there by design. But my feeling is that there is an apparent effort to minimize the sophistication of the geometry model. My concern is that the geometry model will have very limited utility for spacial modeling and necessitate the development of entirely parallel geometry models to do anything non-trivial in a mathematical sense. CLIM does not intend to provide any sort of a substrate for spatial modeling. CLIM is for building user interfaces, and as such CLIM's interest in geometry is limited to the geometry necessary for describing such interfaces. Because one of the goals of CLIM was to describe appearances in a device-independent manner, CLIM has more geometry (and is more careful and explicit about it) than most user-interface languages. This has lead some people to believe that they were getting some sort of geometric modeling capability "thrown in for free". They were wrong. [...] I think it would be nice if rectangular polygons could be coerced to rectangles at creation, since they are immutable and could logically be considered a subclass of polygon so that the test rectanglep would work on arbitrary rectangular regions and the rectangles would not be bereft of the polygon protocols such as map-over-polygon-segments or map-over- polygon-coordinates. I agree that rectangles should obey the full set of polygon protocols. Reading the beginning of section 3.2 Other Region Types in the 2.0.alpha documentation (from Franz) indicates that there is some sort of proposal to even further diminish the utility of regions by removing polygons, poly- lines, ellipses, and elliptical arcs. I certainly would like to hear the rationale for this; I think it would be a serious flaw and is a move in the wrong direction. I believe the proposal is not to remove certain pieces completely, but to have them available as optional add-ons. Any proposal to "demote" certain objects to optional status, or for that matter to add on certain new classes of objects (e.g. splines), can only remove (add) entire classes that are closed under affine transformation. So you can't remove ellipses without removing circles. Whether such a stripped-down CLIM, whose only graphics were lines and points, would be useful to anyone is an open question. Perhaps a CLIM without any graphics at all would be useful in some situations. My own belief is that such a stripping-down procedure is more profitably done at application-delivery time, by a "garbage-collecting linking loader" or "tree-shaker". Then you can strip out exactly and precisely what your application doesn't need. And you can strip it out of the entire Lisp, not just the UI.   Received: from BBN.COM by LABS-N.BBN.COM id aa27148; 22 Jul 92 12:57 EDT Received: from mwunix.mitre.org by BBN.COM id aa01422; 22 Jul 92 12:53 EDT Return-Path: Received: from cypress.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA23248; Wed, 22 Jul 92 12:51:09 -0400 Received: by cypress.mitre.org (4.1/SMI-4.1) id AA00409; Wed, 22 Jul 92 12:57:53 EDT Date: Wed, 22 Jul 92 12:57:53 EDT From: gmw@cypress.mitre.org (Gregory M. Whittaker) Message-Id: <9207221657.AA00409@cypress.mitre.org> To: JGA@STONY-BROOK.SCRC.Symbolics.COM, greg@mitre.org Subject: Re: CLIM question Cc: CLIM@bbn.com, lwolf@franz.com John, I have been working with CLIM-2.0.alpha and just getting familiar with some of the basic properties of CLIM geometry. I don't know how much of what I am discovering is merely an artifact of the alpha version and how much is there by design. But my feeling is that there is an apparent effort to minimize the sophistication of the geometry model. My concern is that the geometry model will have very limited utility for spacial modeling and necessitate the development of entirely parallel geometry models to do anything non-trivial in a mathematical sense. For example, I was dissappointed to find that region-intersection does not currently provide a means of determining if two line-segments intersect, but only if they overlap, due to the dimensionality rule. This of course is also a problem for intersections of areas or areas and lines, etc. Similarly, region-union seems to provide identical (eq) results for polylines in union with polygons, at least in the test case I ran. I have also had problems with the containment test generic function, not having methods defined for all possible combinations of regions. But I suspect that is merely an alpha artifact. I think it would be nice if rectangular polygons could be coerced to rectangles at creation, since they are immutable and could logically be considered a subclass of polygon so that the test rectanglep would work on arbitrary rectangular regions and the rectangles would not be bereft of the polygon protocols such as map-over-polygon-segments or map-over- polygon-coordinates. Reading the beginning of section 3.2 Other Region Types in the 2.0.alpha documentation (from Franz) indicates that there is some sort of proposal to even further diminish the utility of regions by removing polygons, poly- lines, ellipses, and elliptical arcs. I certainly would like to hear the rationale for this; I think it would be a serious flaw and is a move in the wrong direction. Please give me a little background on the current philosophy of CLIM development as it pertains to these concerns and to any other areas that may still be in a state of flux. I could go on and on, but this is enough to get a discussion going. -------- Cordially, Gregory M. Whittaker, The MITRE Corporation Center for Advanced Aviation System Development Internet: greg@mitre.org 7525 Colshire Drive Phone: (703) 883-5549 McLean Virginia 22102-3481 FAX: (703) 883-1226 Mail Stop: W215   Received: from BBN.COM by LABS-N.BBN.COM id aa28707; 22 Jul 92 15:06 EDT Received: from aplcen.apl.jhu.edu by BBN.COM id aa06683; 22 Jul 92 15:03 EDT Received: by aplcen.apl.jhu.edu (5.57/Ultrix2.4-XDccg) id AA09496; Wed, 22 Jul 92 15:03:04 -0400 Date: Wed, 22 Jul 92 15:03:04 -0400 From: lien@aplcen.apl.jhu.edu (Duong lien t) Message-Id: <9207221903.AA09496@aplcen.apl.jhu.edu> X-Mailer: Mail User's Shell (6.1 4/26/88) To: clim@bbn.com Subject: transformation for bitmap Hi, does anyone has an algorithm that provides transformations for bitmap? thanks, Lien.   Received: from BBN.COM by LABS-N.BBN.COM id aa00273; 22 Jul 92 17:13 EDT Received: from chesapeake.ads.com by BBN.COM id aa13654; 22 Jul 92 17:09 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA00797; Wed, 22 Jul 92 17:11:00 EDT Date: Wed, 22 Jul 92 17:11:00 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9207222111.AA00797@chesapeake.ads.com> To: clim@bbn.com Subject: Tracking pointers... Reply-To: jclose@ads.com Greetings... I have a problem involving CLIM:Tracking-Pointer. I want to be able to track the pointer out of one pane of a frame and across other panes, and know what pane it currently rests in. Does any one have any ideas on how I can manage that? Thanks much for any suggestions. Jeff   Received: from BBN.COM by LABS-N.BBN.COM id aa00457; 22 Jul 92 17:27 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa15204; 22 Jul 92 17:21 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1112351; 22 Jul 1992 17:22:51-0400 Date: Wed, 22 Jul 1992 17:23-0400 From: Scott McKay Subject: transformation for bitmap To: lien@aplcen.apl.jhu.edu, clim@BBN.COM In-Reply-To: <9207221903.AA09496@aplcen.apl.jhu.edu> Message-ID: <19920722212324.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 22 Jul 1992 15:03 EDT From: Duong lien t does anyone has an algorithm that provides transformations for bitmap? Tell me if you do, please. Mine is too feeble to warrant installation into CLIM, and the more general one I wrote uses rasterization to do the transformations (!).   Received: from BBN.COM by LABS-N.BBN.COM id aa29749; 22 Jul 92 16:43 EDT Received: from chesapeake.ads.com by BBN.COM id aa11758; 22 Jul 92 16:38 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA00369; Wed, 22 Jul 92 16:40:25 EDT Date: Wed, 22 Jul 92 16:40:25 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9207222040.AA00369@chesapeake.ads.com> To: lien@aplcen.apl.jhu.edu Cc: clim@bbn.com In-Reply-To: Duong lien t's message of Wed, 22 Jul 92 15:03:04 -0400 <9207221903.AA09496@aplcen.apl.jhu.edu> Subject: Re: transformation for bitmap Reply-To: jclose@ads.com Date: Wed, 22 Jul 92 15:03:04 -0400 From: Duong lien t X-Mailer: Mail User's Shell (6.1 4/26/88) .. does anyone has an algorithm that provides transformations for bitmap? Lien. That depends -- what kind of transformation do you mean, and for what bitmaps? Jeff   Received: from BBN.COM by LABS-N.BBN.COM id aa10254; 23 Jul 92 10:55 EDT Received: from chesapeake.ads.com by BBN.COM id aa13356; 23 Jul 92 10:50 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA09784; Thu, 23 Jul 92 10:52:25 EDT Date: Thu, 23 Jul 92 10:52:25 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9207231452.AA09784@chesapeake.ads.com> To: SWM@stony-brook.scrc.symbolics.com Cc: clim@bbn.com In-Reply-To: Scott McKay's message of Thu, 23 Jul 1992 10:32-0400 <19920723143234.7.SWM@SUMMER.SCRC.Symbolics.COM> Subject: Re: Tracking pointers... Reply-To: jclose@ads.com Date: Thu, 23 Jul 1992 10:32-0400 From: Scott McKay Date: Wed, 22 Jul 1992 17:11 EDT From: Jeff Close I have a problem involving CLIM:Tracking-Pointer. I want to be able to track the pointer out of one pane of a frame and across other panes, and know what pane it currently rests in. Does any one have any ideas on how I can manage that? Thanks much for any suggestions. Does :MULTIPLE-WINDOW T not work? Scott, Thanks for your response. I thought it would, but what I've discovered has turned what I thought would be a simple tracking routine into a total mess. I can't tell that :multiple-window T does ANYTHING! Here's what I've done: the mult. win keyword, track the pointer, and wait for :pointer-motion to redraw a picture, I would think that the window argument to :pointer-motion would refer to the window (pane, in a frame) that the mouse currently sits on, and therefore that drawing to this window would draw the picture following the pointer as it moves into different panes. BUT... it merely draws into the original pane, which is overlapped by the neighboring panes once the pointer goes beyond that pane's borders. Has anyone used :multiple-window succesfully? Jeff   Received: from BBN.COM by LABS-N.BBN.COM id aa10379; 23 Jul 92 10:59 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa13478; 23 Jul 92 10:54 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1112790; 23 Jul 1992 10:55:44-0400 Date: Thu, 23 Jul 1992 10:56-0400 From: Scott McKay Subject: Re: Tracking pointers... To: jclose@ads.com, SWM@STONY-BROOK.SCRC.Symbolics.COM cc: clim@bbn.com In-Reply-To: <9207231452.AA09784@chesapeake.ads.com> Message-ID: <19920723145625.1.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 23 Jul 1992 10:52 EDT From: jclose@chesapeake.ads.com (Jeff Close) Date: Thu, 23 Jul 1992 10:32-0400 From: Scott McKay Date: Wed, 22 Jul 1992 17:11 EDT From: Jeff Close I have a problem involving CLIM:Tracking-Pointer. I want to be able to track the pointer out of one pane of a frame and across other panes, and know what pane it currently rests in. Does any one have any ideas on how I can manage that? Thanks much for any suggestions. Does :MULTIPLE-WINDOW T not work? Scott, Thanks for your response. I thought it would, but what I've discovered has turned what I thought would be a simple tracking routine into a total mess. I can't tell that :multiple-window T does ANYTHING! Here's what I've done: the mult. win keyword, track the pointer, and wait for :pointer-motion to redraw a picture, I would think that the window argument to :pointer-motion would refer to the window (pane, in a frame) that the mouse currently sits on, and therefore that drawing to this window would draw the picture following the pointer as it moves into different panes. BUT... it merely draws into the original pane, which is overlapped by the neighboring panes once the pointer goes beyond that pane's borders. Has anyone used :multiple-window succesfully? I guess this is a bug report. It won't be fixed in CLIM 1.1, except by some miracle. I will investigate further for CLIM 2.0   Received: from BBN.COM by LABS-N.BBN.COM id aa10034; 23 Jul 92 10:41 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa12567; 23 Jul 92 10:31 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1112763; 23 Jul 1992 10:31:54-0400 Date: Thu, 23 Jul 1992 10:32-0400 From: Scott McKay Subject: Tracking pointers... To: jclose@ads.com, clim@BBN.COM In-Reply-To: <9207222111.AA00797@chesapeake.ads.com> Message-ID: <19920723143234.7.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 22 Jul 1992 17:11 EDT From: Jeff Close I have a problem involving CLIM:Tracking-Pointer. I want to be able to track the pointer out of one pane of a frame and across other panes, and know what pane it currently rests in. Does any one have any ideas on how I can manage that? Thanks much for any suggestions. Does :MULTIPLE-WINDOW T not work?   Received: from BBN.COM by LABS-N.BBN.COM id aa10767; 23 Jul 92 11:35 EDT Received: from chesapeake.ads.com by BBN.COM id aa15370; 23 Jul 92 11:31 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA10224; Thu, 23 Jul 92 11:33:17 EDT Date: Thu, 23 Jul 92 11:33:17 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9207231533.AA10224@chesapeake.ads.com> To: jclose@ads.com Cc: SWM@stony-brook.scrc.symbolics.com, clim@bbn.com In-Reply-To: Jeff Close's message of Thu, 23 Jul 92 10:52:25 EDT <9207231452.AA09784@chesapeake.ads.com> Subject: Re: Tracking pointers... Reply-To: jclose@ads.com Scott, et al.: How about this for an alternate approach -- what function (if one exists) can tell me the inferior pane given a coordinate pair relative to a frame? This would let me switch the window I'm tracking in when the window changes. Jeffrey   Received: from BBN.COM by LABS-N.BBN.COM id aa10776; 23 Jul 92 11:39 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa15554; 23 Jul 92 11:35 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1112830; 23 Jul 1992 11:36:15-0400 Date: Thu, 23 Jul 1992 11:36-0400 From: Scott McKay Subject: Re: Tracking pointers... To: jclose@ads.com cc: SWM@STONY-BROOK.SCRC.Symbolics.COM, clim@bbn.com In-Reply-To: <9207231533.AA10224@chesapeake.ads.com> Message-ID: <19920723153655.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 23 Jul 1992 11:33 EDT From: jclose@chesapeake.ads.com (Jeff Close) Scott, et al.: How about this for an alternate approach -- what function (if one exists) can tell me the inferior pane given a coordinate pair relative to a frame? This would let me switch the window I'm tracking in when the window changes. Jeffrey I don't recall. Maybe CLIM::POINTER-WINDOW?   Received: from BBN.COM by LABS-N.BBN.COM id aa10890; 23 Jul 92 11:51 EDT Received: from chesapeake.ads.com by BBN.COM id aa16050; 23 Jul 92 11:47 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA10391; Thu, 23 Jul 92 11:49:11 EDT Date: Thu, 23 Jul 92 11:49:11 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9207231549.AA10391@chesapeake.ads.com> To: SWM@stony-brook.scrc.symbolics.com Cc: clim@bbn.com In-Reply-To: Scott McKay's message of Thu, 23 Jul 1992 10:56-0400 <19920723145625.1.SWM@SUMMER.SCRC.Symbolics.COM> Subject: Re: Tracking pointers... Reply-To: jclose@ads.com Scott, Apologies to those who don't care to follow this, but if there is a bug, some people may be interested in approaches. One can use (clim::pointer-window pointer) to get the window under the pointer, and this window changes as the pointer moves across panes. Then one should be able to use this in the tracking convert coordinates to frame and back to the other window, then to draw into the appropriate pane. Jeff   Received: from BBN.COM by LABS-N.BBN.COM id aa11890; 23 Jul 92 13:06 EDT Received: from fenrix.si.no by BBN.COM id aa18899; 23 Jul 92 13:03 EDT Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.23) id AA04344; Thu, 23 Jul 92 19:04:06 +0200 Date: Thu, 23 Jul 92 19:04:06 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9207231658.AAmonsun05367@D> To: jclose@ads.com Cc: SWM@stony-brook.scrc.symbolics.com, clim@BBN.COM In-Reply-To: Jeff Close's message of Thu, 23 Jul 92 10:52:25 EDT <9207231452.AA09784@chesapeake.ads.com> Subject: Tracking pointers... I tried using tracking-pointer with multiple-window once, when making a rubber-banding drawing mode. The problem I met was that the x,y-coordinates received in the pointer-motion clause, was relative to the window under the cursor and not the pane argument to tracking-pointer. This may be correct for some uses of tracking-pointer and multiple-window but for me it wasn't. It was best to stop tracking at the border and catching up when the pointer entered again.   Received: from BBN.COM by LABS-N.BBN.COM id aa12934; 23 Jul 92 14:12 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa21603; 23 Jul 92 14:08 EDT Received: from WATERMELON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1112990; 23 Jul 1992 14:09:29-0400 Date: Thu, 23 Jul 1992 14:09-0400 From: John G. Aspinall Subject: Re: Tracking pointers... To: jclose@ads.com, SWM@STONY-BROOK.SCRC.Symbolics.COM cc: clim@BBN.COM In-Reply-To: <9207231533.AA10224@chesapeake.ads.com>, <19920723145625.1.SWM@SUMMER.SCRC.Symbolics.COM>, <9207231452.AA09784@chesapeake.ads.com> Message-ID: <19920723180929.7.JGA@WATERMELON.SCRC.Symbolics.COM> Hold it, you guys. How about a real bug report? If there's a bug here, we need a much better example of just what you're trying to do. The following example works fine for me, it tracks the pointer across multiple windows, detecting the crossings just fine. (Cut me a small amount of slack on the internal kludgery necessary to find the name of a pane.) ;;; -*- Mode: LISP; Syntax: Common-Lisp; Base: 10; Package: CLIM-USER -*- (define-application-frame track-test () () (:panes ((display1 :application :scroll-bars nil) (display2 :application :scroll-bars nil) (menu :command-menu) (history :interactor))) (:layout ((regular (:column 1 (:row 1/2 (display1 1/2) (display2 :rest)) (:row :rest (history 3/4) (menu :rest))))))) (define-track-test-command (com-exit-track-test :menu "Exit") () (frame-exit *application-frame*)) (define-track-test-command (com-test-tracking :menu "Test") () (tracking-test *application-frame*)) (defmethod tracking-test ((frame track-test)) (let ((display1 (get-frame-pane frame 'display1)) (display2 (get-frame-pane frame 'display2)) (history (get-frame-pane frame 'history)) old-window old-x old-y) (tracking-pointer (display1 :multiple-window t) (:pointer-motion (window x y) (when (or (not (eql window old-window)) (> (abs (- x old-x)) 10) (> (abs (- y old-y)) 10)) (setq old-window window old-x x old-y y) (let ((name (clim::pane-descriptor-name (nth (position window (frame-panes frame)) (clim::frame-descriptor-pane-descriptions (clim::find-frame-descriptor frame)))))) (format history "~&Tracking in pane ~S, x,y = ~D,~D" name x y)))) (:pointer-button-press (event) (return-from tracking-test))))) #|| (defvar *clim-root* (open-root-window :sheet)) (setq tt (clim:make-application-frame 'track-test :parent *clim-root* :width 800 :height 800)) (clim:run-frame-top-level tt) ||#   Received: from BBN.COM by LABS-N.bbn.COM id aa13441; 23 Jul 92 14:51 EDT Received: from [192.35.17.2] by BBN.COM id aa23279; 23 Jul 92 14:42 EDT Received: from ap542.sniap.mchp.sni.de by murignis.mchp.sni.de with SMTP id AA11442 (5.65c/IDA-1.4.4 for ); Thu, 23 Jul 1992 20:40:44 +0200 Received: from Sun4.sniap.mchp.sni.de by ap542.sniap.mchp.sni.de with SMTP id AA03717 (5.65c/IDA-1.4.4); Thu, 23 Jul 1992 20:38:02 +0100 From: Thomas Ruedesheim Date: Thu, 23 Jul 92 20:38:41 +0200 Message-Id: <9207231838.AA08094@Sun4.sniap.mchp.sni.de> To: clim@bbn.com Subject: Question about defining presentation types with parameters and options Cc: bugs@franz.com Hi there, Consider the following small example: ;;; -*- Mode: Common-Lisp; Package: CLIM-USER; -*- (define-presentation-type sentence (language) :options (direction) :inherit-from 'string) (define-presentation-method accept ((type sentence) stream (view textual-view) &key) (with-input-editing (stream) (read-line stream))) (define-presentation-method present (object (type sentence) stream (view textual-view) &key) (format stream "~a" object)) (define-presentation-method presentation-typep (object (type sentence)) (and (typep object 'standard-presentation) (let ((ptype (presentation-type object))) (and (listp ptype) (equal ptype (list 'sentence language))))) ) (define-presentation-method presentation-subtypep ((type sentence) putative-supertype) (let (language1) (with-presentation-type-parameters (sentence type) (setf language1 language)) (with-presentation-type-parameters (sentence putative-supertype) (if (eq language1 language) (values t t) (values nil t))))) (defun test () (present "Das Haus brennt" '((sentence german) :direction :source)) (terpri) (present "The house burns." '((sentence english) :direction :target)) (terpri) (accept '((sentence german) :direction :source))) Here is my question: Call the function test inside an application frame's interactor pane. The inner call to ACCEPT accepts both the german and the english sentence. How could I change my code, so that only german sentences are accepted? Thomas   Received: from BBN.COM by LABS-N.bbn.COM id aa17846; 23 Jul 92 23:26 EDT Received: from sask.usask.ca by BBN.COM id aa18772; 23 Jul 92 23:21 EDT Received: from access.USask.Ca by SASK.USask.CA (PMDF #12333) id <01GMQDMCQESW003I4Z@SASK.USask.CA>; Thu, 23 Jul 1992 21:23 CST Received: by access.USask.Ca (5.57/GLH-1.0); Thu, 23 Jul 92 21:20:42 -0600 id AA12208 for clim@bbn.com Received: from skaries.USask.ca by skdad.USask.ca (4.1/SMI-4.1) id AA24744; Thu, 23 Jul 92 21:20:40 CST Date: Thu, 23 Jul 92 21:20:38 CST From: coulman@skdad.usask.ca (Randy Coulman) Subject: Transformations and graphs To: clim@bbn.com (Clim Users Mailing List) Message-id: <9207240320.AA24744@skdad.USask.ca> X-Envelope-to: clim@bbn.com X-Mailer: ELM [version 2.3 PL11] I'm trying to apply transformations to graphs that are created with format-graph-from-root. What happens is any text (node labels, for example) do not get transformed, but everything else does (arcs, borders created with surrounding-output-with-borders, etc.). Should it work? I'm using Allegro CL 4.1 with CLIM 1.1 on a Sparc 1+. Here's a test program, loosely based on the example in the manual: (in-package :clim-user) (defstruct node (name "") (children '()) ) (defvar g1 (let* ((2a (make-node :name "2A")) (2b (make-node :name "2B")) (2c (make-node :name "2C")) (1a (make-node :name "1A" :children (list 2a 2b))) (1b (make-node :name "1B" :children (list 2b 2c)))) (make-node :name "0" :children (list 1a 1b)))) (define-application-frame test () ((root :accessor frame-root :initform g1)) (:panes ((display :application :display-function 'test-graph) (menu :command-menu)) ) ) (define-test-command (exit :menu t) () (frame-exit *application-frame*) ) (defmethod test-graph ((frame test) stream) (let ((root (frame-root frame)) ) (with-translation (stream 100 100) (format-graph-from-root root #'(lambda (node s) (write-string (node-name node) s)) #'node-children :stream stream) ) )) When this example is run, the arcs of the graph are translated, while the node labels stay in the upper left corner. Any ideas? Thanks, Randy -- Randy A. Coulman | ARIES Laboratory | Department of Computational Science coulman@cs.Usask.ca | University of Saskatchewan | Saskatoon, SK S7N 0W0   Received: from BBN.COM by LABS-N.bbn.COM id aa20328; 24 Jul 92 5:40 EDT Received: from gmdzi.gmd.de by BBN.COM id aa18816; 24 Jul 92 5:36 EDT Received: from localhost by gmdzi.gmd.de with SMTP id AA10900 (5.65c/IDA-1.4.4 for clim@BBN.COM); Fri, 24 Jul 1992 11:34:58 +0200 Message-Id: <199207240934.AA10900@gmdzi.gmd.de> To: clim@BBN.COM Subject: help for editing text. Date: Fri, 24 Jul 92 11:34:57 +0200 From: Ralph.Hensel@gmd.de X-Mts: smtp Hi, I have some problems involving the following: 1. If I try to accept a string that has some contents in it like "default". It seems impossible to edit that. Instead I have always to retype the complete former input. I may use the default presentation, but if I like to make minor changes, like corrections, I have to retype the input. Can somebody give me an example how to re-edit strings? 2. I would like to have a little text editor, so I can accept a few (more than one) line of text. I think that question is somewhat connected with 1. 3. It would be great, if that more than one line editing could be extended to lisp-expressions. I tried a little with clim:with-input-editing, but I didn`t get propper results. I am working on SUN sparc2 with clim 1.0 and allegro 4.0. thanks, Ralph Hensel German National Research Center for Computer Science (GMD-FIT.KI) P.O. Box 1316, D-5205 Sankt Augustin, Germany mail:hensel@gmdzi.gmd.de fax:+49-2241-14-2889 phone:+49-2241-14-1   Received: from BBN.COM by LABS-N.BBN.COM id aa21830; 24 Jul 92 8:03 EDT Received: from linus.mitre.org by BBN.COM id aa21596; 24 Jul 92 7:59 EDT Return-Path: Received: by linus.mitre.org (5.61/RCF-4S) id AA13502; Fri, 24 Jul 92 07:59:48 -0400 Date: Fri, 24 Jul 92 07:59:48 -0400 From: mark@linus.mitre.org (Mark K. Cimini) Full-Name: Mark K. Cimini Posted-Date: Fri, 24 Jul 92 07:59:48 -0400 Message-Id: <9207241159.AA13502@linus.mitre.org> To: clim@bbn.com Subject: Remove from list The subject line says it all Thanks.   Received: from BBN.COM by LABS-N.BBN.COM id aa23428; 24 Jul 92 10:37 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa28791; 24 Jul 92 10:30 EDT Received: from WATERMELON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1113558; 24 Jul 1992 10:31:55-0400 Date: Fri, 24 Jul 1992 10:31-0400 From: John G. Aspinall Subject: Transformations and graphs To: coulman@skdad.usask.ca cc: clim@BBN.COM In-Reply-To: <9207240320.AA24744@skdad.USask.ca> Message-ID: <19920724143144.0.JGA@WATERMELON.SCRC.Symbolics.COM> Use draw-string* to draw the name of the node.   Received: from BBN.COM by LABS-N.BBN.COM id aa23089; 24 Jul 92 10:05 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa27313; 24 Jul 92 10:00 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1113504; 24 Jul 1992 09:22:05-0400 Date: Fri, 24 Jul 1992 09:22-0400 From: Scott McKay Subject: Transformations and graphs To: coulman@skdad.usask.ca, clim@BBN.COM In-Reply-To: <9207240320.AA24744@skdad.USask.ca> Message-ID: <19920724132235.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 23 Jul 1992 23:20 EDT From: Randy Coulman I'm trying to apply transformations to graphs that are created with format-graph-from-root. What happens is any text (node labels, for example) do not get transformed, but everything else does (arcs, borders created with surrounding-output-with-borders, etc.). Should it work? CLIM 1.1 does not support transformation of text. I believe all ports of CLIM 2.0 will support transformation of the baseline of the text (that is, where the glyphs get drawn), but will probably not support general transformations of the glyphs themselves. Transformation of glyphs by 90-degree rotations might work. I'm using Allegro CL 4.1 with CLIM 1.1 on a Sparc 1+. Here's a test program, loosely based on the example in the manual: (in-package :clim-user) (defstruct node (name "") (children '()) ) (defvar g1 (let* ((2a (make-node :name "2A")) (2b (make-node :name "2B")) (2c (make-node :name "2C")) (1a (make-node :name "1A" :children (list 2a 2b))) (1b (make-node :name "1B" :children (list 2b 2c)))) (make-node :name "0" :children (list 1a 1b)))) (define-application-frame test () ((root :accessor frame-root :initform g1)) (:panes ((display :application :display-function 'test-graph) (menu :command-menu)) ) ) (define-test-command (exit :menu t) () (frame-exit *application-frame*) ) (defmethod test-graph ((frame test) stream) (let ((root (frame-root frame)) ) (with-translation (stream 100 100) (format-graph-from-root root #'(lambda (node s) (write-string (node-name node) s)) #'node-children :stream stream) ) )) When this example is run, the arcs of the graph are translated, while the node labels stay in the upper left corner. Any ideas? Thanks, Randy -- Randy A. Coulman | ARIES Laboratory | Department of Computational Science coulman@cs.Usask.ca | University of Saskatchewan | Saskatoon, SK S7N 0W0   Received: from BBN.COM by LABS-N.BBN.COM id aa23584; 24 Jul 92 10:50 EDT Received: from lutsen.ssdc.honeywell.com by BBN.COM id aa29350; 24 Jul 92 10:44 EDT Message-Id: <9207241440.AA13645@lutsen.hi-csc.honeywell.com> Received: from msmail.ssdc.honeywell.com by lutsen.hi-csc.honeywell.com; Fri, 24 Jul 92 09:40:59 -0500 Date: 24 Jul 92 09:28:53 U From: "Nasiruddin Mohammed" Subject: Please remove from list. Return-Receipt-To: "Nasiruddin Mohammed" To: clim@bbn.com Please remove "nasir@umn.cs.edu" from the mailing list. Thanks. -- Nasir   Received: from BBN.COM by LABS-N.BBN.COM id aa26150; 24 Jul 92 14:42 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa08828; 24 Jul 92 14:38 EDT Received: from WATERMELON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1113746; 24 Jul 1992 14:39:33-0400 Date: Fri, 24 Jul 1992 14:39-0400 From: John G. Aspinall Subject: help for editing text. To: Ralph.Hensel@gmd.de cc: clim@BBN.COM In-Reply-To: <199207240934.AA10900@gmdzi.gmd.de> Message-ID: <19920724183923.9.JGA@WATERMELON.SCRC.Symbolics.COM> Date: Fri, 24 Jul 1992 05:34 EDT From: Ralph.Hensel@gmd.de If I try to accept a string that has some contents in it like "default". It seems impossible to edit that. Instead I have always to retype the complete former input. I may use the default presentation, but if I like to make minor changes, like corrections, I have to retype the input. Can somebody give me an example how to re-edit strings? Here's a quick-and-dirty example that Scott and I worked out a while ago. Things to understand: - Call REPLACE-INPUT to fill the input buffer of an input-editing stream. - Code inside with-input-editing will restart any time the user edits (e.g. types ). Therefore you must make sure that replace-input only gets called the first time. That's why it says (when default-note (replace-input ...) (setq default-note nil)) - The cursor-visibility stuff is to make the cursor visible during editing. Don't try to understand that stuff, it's just a kludge. Disclaimer: only tested on Genera. ================================================================ ;;; -*- Mode: Lisp; Package: CLIM-USER; Syntax: Common-Lisp; Lowercase: Yes -*- (defun read-note (&optional default-note) (with-menu (stream) ;; Set up the pop-up window the way we want to see it (setf (clim::cursor-visibility (clim::stream-text-cursor stream)) :off) (clim::window-set-inside-size stream (* 60 (stream-character-width stream #\Space)) (* 10 (stream-line-height stream))) (write-string "Enter a note:" stream) (fresh-line stream) (setf (stream-text-margin stream) (bounding-rectangle-width (window-viewport stream))) (window-expose stream) (unwind-protect (with-input-editing (stream) ;; Put the default note into the input buffer and ensure that ;; we never do it again (when default-note (replace-input stream default-note :rescan t) (setq default-note nil)) ;; Now get the input from the user (with-activation-characters ('(#\Newline) :override t) (unwind-protect (read-token stream) ;; Eat the activation character (read-gesture :stream stream :timeout 0)))) (setf (clim::cursor-visibility (clim::stream-text-cursor stream)) :inactive))))   Received: from BBN.COM by LABS-N.BBN.COM id aa26139; 24 Jul 92 14:41 EDT Received: from venera.isi.edu by BBN.COM id aa08760; 24 Jul 92 14:36 EDT Received: from sunstruck.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Fri, 24 Jul 1992 11:38:24 -0700 Date: Fri, 24 Jul 1992 11:40:10 -0700 From: chee@ISI.EDU Posted-Date: Fri, 24 Jul 1992 11:40:10 -0700 Message-Id: <199207241840.AA05175@sunstruck.isi.edu> Received: by sunstruck.isi.edu (5.65c/4.0.3-4) id ; Fri, 24 Jul 1992 11:40:10 -0700 To: clim@BBN.COM In-Reply-To: Ralph.Hensel@gmd.de's message of Fri, 24 Jul 92 11:34:57 +0200 <199207240934.AA10900@gmdzi.gmd.de> Subject: help for editing text. Reply-To: chee@ISI.EDU > I would like to have a little text editor, so I can accept a few (more than > one) line of text. I think that question is somewhat connected with 1. Here's what works for me... (defun edit-obj (obj associated-window &optional pkg) (let* ((*package* (if (symbolp obj) (symbol-package obj) *package*)) ;; just so package prefix is not printed. (df (with-output-to-string (s) (pprint obj s)))) (clim::with-menu (str associated-window) (clim::clear-input str) ;; set to some arbitrary "nice" size, LUCID comes up with a very ;; small one by default. (clim::window-set-inside-size str 700 300) (setf (clim::stream-text-margin str) (clim::window-inside-width str)) (clim::window-expose str) ;; just to make sure pointer is in the window... (clim::stream-set-pointer-position* str 100 100) (clim::with-input-editing (str :initial-contents df) #+excl (mp::process-run-function "OLD KLUDGE" #'bloody-kludge str) #+lcl (lcl::make-process :name "OLD KLUDGE" :function #'bloody-kludge :args (list str)) (read str))))) (defun bloody-kludge (str) ;;; AAAAAAAARGH, MAJOR KLUDGERY to get text displayed (sleep 1) (clim::window-refresh str)) This works on a SUN with either Allegro or Lucid CL. Also, I think for LUCID, you need to be careful about the argument to :initial-contents, if it is a well-formed (expr) list, it may return immediately, so you may want to do something like (subseq obj 0 (1- (length obj))) after you've converted obj into a string. Unfortunately you won't get a cursor. Since this is really primitive, if you have something that is more than one line long, you'll prolly have to write something that breaks it up reasonably. Hope this helps. Chee-rs.   Received: from BBN.COM by LABS-N.BBN.COM id aa21417; 27 Jul 92 11:36 EDT Received: from [192.35.17.2] by BBN.COM id aa21673; 27 Jul 92 11:30 EDT Received: from ap542.sniap.mchp.sni.de by murignis.mchp.sni.de with SMTP id AA05043 (5.65c/IDA-1.4.4 for ); Mon, 27 Jul 1992 17:27:36 +0200 Received: from Sun4.sniap.mchp.sni.de by ap542.sniap.mchp.sni.de with SMTP id AA01748 (5.65c/IDA-1.4.4); Mon, 27 Jul 1992 17:24:43 +0100 From: Thomas Ruedesheim Date: Mon, 27 Jul 92 11:06:13 +0200 Message-Id: <9207270906.AA14359@Sun4.sniap.mchp.sni.de> To: CLIM@BBN.COM, bugs@Franz.COM Subject: Question about defining presentation types with parameters and options Hi there, Consider the following small example: ;;; -*- Mode: Common-Lisp; Package: CLIM-USER; -*- (define-presentation-type sentence (language) :options (direction) :inherit-from 'string) (define-presentation-method accept ((type sentence) stream (view textual-view) &key) (with-input-editing (stream) (read-line stream))) (define-presentation-method present (object (type sentence) stream (view textual-view) &key) (format stream "~a" object)) (define-presentation-method presentation-typep (object (type sentence)) (and (typep object 'standard-presentation) (let ((ptype (presentation-type object))) (and (listp ptype) (equal ptype (list 'sentence language))))) ) (define-presentation-method presentation-subtypep ((type sentence) putative-supertype) (let (language1) (with-presentation-type-parameters (sentence type) (setf language1 language)) (with-presentation-type-parameters (sentence putative-supertype) (if (eq language1 language) (values t t) (values nil t))))) (defun test () (present "Das Haus brennt" '((sentence german) :direction :source)) (terpri) (present "The house burns." '((sentence english) :direction :target)) (terpri) (accept '((sentence german) :direction :source))) Here is my question: Call the function test inside an application frame's interactor pane. The inner call to ACCEPT accepts both the german and the english sentence. How could I change my code, so that only german sentences are accepted? Thomas   Received: from BBN.COM by LABS-N.BBN.COM id aa20909; 27 Jul 92 10:54 EDT Received: from Sun.COM by BBN.COM id aa18029; 27 Jul 92 10:20 EDT Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA03555; Mon, 27 Jul 92 07:20:50 PDT Received: from East.Sun.COM by snail.Sun.COM (4.1/SMI-4.1) id AA26321; Mon, 27 Jul 92 07:20:49 PDT Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA27735; Mon, 27 Jul 92 10:20:48 EDT Received: from hummer.East.Sun.COM by suneast.East.Sun.COM (4.1/SMI-4.1) id AA07324; Mon, 27 Jul 92 10:19:18 EDT Received: by hummer.East.Sun.COM (4.1/SMI-4.1) id AA04552; Mon, 27 Jul 92 10:10:53 EDT Date: Mon, 27 Jul 92 10:10:53 EDT From: demarcke@suneast.East.Sun.COM (Carl deMarcken - Sun Labs East) Message-Id: <9207271410.AA04552@hummer.East.Sun.COM> To: clim@bbn.com Subject: Problems with UPDATING-OUTPUT I'm using CLIM 1.1 and have been experiencing problems with CLIM:UPDATING-OUTPUT. Code that looks like (clim:updating-output (stream ...) (clim:with-output-as-presenation (...) ... draw stuff ... ) ... (clim:draw-text* ...) ... ) will not include the text in the output record. If instead the text is included inside the scope of the WITH-OUTPUT-AS-PRESENTATION the text is recorded in the output record. Is there an easy way to get around this problem? Carl de Marcken   Received: from BBN.COM by LABS-N.BBN.COM id aa21812; 27 Jul 92 12:08 EDT Received: from iraun1.ira.uka.de by BBN.COM id aa23140; 27 Jul 92 12:00 EDT Received: from ira.uka.de by iraun1.ira.uka.de with SMTP (PP) id <07762-0@iraun1.ira.uka.de>; Mon, 27 Jul 1992 18:00:17 +0200 Date: Mon, 27 Jul 92 18:00:19 MET DST From: Karsten Poeck To: seth@gandalf.hrl.hac.com cc: clim@bbn.com Subject: multiple frames on the mac A while ago Seth Goldman posted same code for using multiple application frames for clim 1.beta and Macintosh CL 2.b1p3. I you still have the code would you put it on the CLIM file server on cambridge.apple.com or send me a copy so that I could put it on the file server? karsten poeck university of karlsruhe institute of logic   Received: from BBN.COM by LABS-N.BBN.COM id aa21466; 27 Jul 92 11:41 EDT Received: from chesapeake.ads.com by BBN.COM id aa21805; 27 Jul 92 11:32 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA24386; Mon, 27 Jul 92 11:34:06 EDT Date: Mon, 27 Jul 92 11:34:06 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9207271534.AA24386@chesapeake.ads.com> To: demarcke@suneast.east.sun.com Cc: clim@bbn.com In-Reply-To: Carl deMarcken - Sun Labs East's message of Mon, 27 Jul 92 10:10:53 EDT <9207271410.AA04552@hummer.East.Sun.COM> Subject: Re: Problems with UPDATING-OUTPUT Reply-To: jclose@ads.com ... (clim:updating-output (stream ...) (clim:with-output-as-presenation (...) ... draw stuff ... ) ... (clim:draw-text* ...) ... ) will not include the text in the output record. If instead the text is included inside the scope of the WITH-OUTPUT-AS-PRESENTATION the text is recorded in the output record. Carl, I believe you have to produce an output record explicitly if you are not presenting the text (which would create an output record as a by-product). Use CLIM:WITH-OUTPUT-TO-OUTPUT-RECORD or CLIM:WITH-NEW-OUTPUT-RECORD. Jeffrey   Received: from BBN.COM by LABS-N.BBN.COM id aa21561; 27 Jul 92 11:49 EDT Received: from iraun1.ira.uka.de by BBN.COM id aa22298; 27 Jul 92 11:43 EDT Received: from ira.uka.de by iraun1.ira.uka.de with SMTP (PP) id <07549-0@iraun1.ira.uka.de>; Mon, 27 Jul 1992 17:43:20 +0200 Date: Mon, 27 Jul 92 17:43:26 MET DST From: Karsten Poeck To: clim@bbn.com Subject: CLIM for WINDOWS? I have a question about the availability of CLIM for IBMPC: Is it true that Gold Hill or somebody else is working on an implementation for CLIM for Golden Common Lisp on IBM PC? Karsten Poeck institute of Logic University of karlsruhe   Received: from BBN.COM by LABS-N.BBN.COM id aa23145; 27 Jul 92 13:58 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa27643; 27 Jul 92 13:53 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1114748; 27 Jul 1992 13:55:01-0400 Date: Mon, 27 Jul 1992 13:55-0400 From: Scott McKay Subject: CLIM for WINDOWS? To: poeck@ira.uka.de, clim@bbn.com In-Reply-To: The message from Karsten Poeck Message-ID: <19920727175553.7.SWM@SUMMER.SCRC.Symbolics.COM> From: Karsten Poeck I have a question about the availability of CLIM for IBMPC: Is it true that Gold Hill or somebody else is working on an implementation for CLIM for Golden Common Lisp on IBM PC? Karsten Poeck institute of Logic University of karlsruhe CLIM 1.1 already works under Symbolics CLOE on the IBM PC.   Received: from BBN.COM by LABS-N.BBN.COM id aa26106; 27 Jul 92 18:36 EDT Received: from chesapeake.ads.com by BBN.COM id aa12045; 27 Jul 92 18:33 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA29099; Mon, 27 Jul 92 18:35:01 EDT Date: Mon, 27 Jul 92 18:35:01 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9207272235.AA29099@chesapeake.ads.com> To: clim@bbn.com Subject: QUESTION about presentation type inheritance and command-traanslators Reply-To: jclose@ads.com I've got some CLOS classes with analogous presentation types. The presentation types are defined with the basic defaults (no-options). Suppose CLOS Class-A has subtype CLOS Class-B, and both have presentation types of the same name. The question: I'd like to define presentation-to-command translators for both classes with the gesture :select, but to different commands, i.e., the subclasses and presentation subtypes would get a different command translated with :select. It seems to be seeing only the more basic type translator first, such that the Pres-Type-A command always gets run. Is this the appropriate place to use a more specific tester? Or where should I be specializing the translator so that the new command applies to the more specialized objects? Thanks for any thoughts. On anything. Perot. The weather. Ren and Stimpy. Anything.   Received: from BBN.COM by LABS-N.BBN.COM id aa25532; 27 Jul 92 17:38 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa10425; 27 Jul 92 17:34 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1115038; 27 Jul 1992 17:35:55-0400 Date: Mon, 27 Jul 1992 17:36-0400 From: Scott McKay Subject: Question about defining presentation types with parameters and options To: Thomas.Ruedesheim@sniap.mchp.sni.de, CLIM@BBN.COM, bugs@franz.com In-Reply-To: <9207270906.AA14359@Sun4.sniap.mchp.sni.de> Message-ID: <19920727213644.7.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 27 Jul 1992 05:06 EDT From: Thomas Ruedesheim There is in fact a CLIM bug here. However there are some problems with the example, too, and it is probably worthwhile going through them so just for all of our benefit. Consider the following small example: ;;; -*- Mode: Common-Lisp; Package: CLIM-USER; -*- (define-presentation-type sentence (language) :options (direction) :inherit-from 'string) First off, I think that the SENTENCE type needs to store what language it is in in the SENTENCE object itself, not simply in the presentation. This is because the sentence's language is a property of the sentence, not simply a property of its user-interface behavior. (define-presentation-method accept ((type sentence) stream (view textual-view) &key) (with-input-editing (stream) (read-line stream))) You don't need WITH-INPUT-EDITING, since ACCEPT does that for you. This will need to create a SENTENCE object instead of just returning a string. (define-presentation-method present (object (type sentence) stream (view textual-view) &key) (format stream "~a" object)) This will need to access the string within the SENTENCE object. (define-presentation-method presentation-typep (object (type sentence)) (and (typep object 'standard-presentation) (let ((ptype (presentation-type object))) (and (listp ptype) (equal ptype (list 'sentence language))))) ) This is all confused. The PRESENTATION-TYPEP method will never see any objects of type STANDARD-PRESENTATION, only objects of type SENTENCE. Thus, you can't extract this information from the presentation object that you don't even have. Also, this conses. PRESENTATION-TYPEP methods get called all the time, so they shouldn't cons. (define-presentation-method presentation-subtypep ((type sentence) putative-supertype) (let (language1) (with-presentation-type-parameters (sentence type) (setf language1 language)) (with-presentation-type-parameters (sentence putative-supertype) (if (eq language1 language) (values t t) (values nil t))))) (defun test () (present "Das Haus brennt" '((sentence german) :direction :source)) (terpri) (present "The house burns." '((sentence english) :direction :target)) (terpri) (accept '((sentence german) :direction :source))) This needs to create SENTENCE objects Here is my question: Call the function test inside an application frame's interactor pane. The inner call to ACCEPT accepts both the german and the english sentence. How could I change my code, so that only german sentences are accepted? Thomas The following is the code I would write: ;;; -*- Mode: Lisp; Syntax: ANSI-Common-Lisp; Package: CLIM-USER; Base: 10; Lowercase: Yes -*- (in-package :clim-user) (defclass sentence () ((string :initarg :string :reader sentence-string) (language :initarg :language :reader sentence-language))) (declaim (inline make-sentence)) (defun make-sentence (string &optional (language '*)) (make-instance 'sentence :string string :language language)) ;; Language of '* means anything is OK (define-presentation-type sentence (&optional (language '*)) :options (direction)) (define-presentation-method accept ((type sentence) stream (view textual-view) &key) (let ((string (read-line stream))) (make-sentence string language))) (define-presentation-method present (sentence (type sentence) stream (view textual-view) &key) (format stream "~A" (sentence-string sentence))) (define-presentation-method presentation-typep (sentence (type sentence)) (or (eql language '*) (eql language (sentence-language sentence)))) (define-presentation-method presentation-subtypep ((type1 sentence) type2) (let ((language1 (with-presentation-type-parameters (sentence type1) language)) (language2 (with-presentation-type-parameters (sentence type2) language))) (values (or (eql language2 '*) (eql language1 language2)) t))) (defun test () (present (make-sentence "Das Haus brennt" 'german) '((sentence german) :direction :source)) (terpri) (present (make-sentence "The house burns." 'english) '((sentence english) :direction :target)) (terpri) (accept '((sentence german) :direction :source))) ------------ Now we get to the CLIM bug. It seems that the function IDENTITY-TRANSLATOR-APPLICABLE-P is accepting too much, which is simply awful. I did not test this completely thoroughly, but you might try this definition for it: (in-package :clim) (defun identity-translator-applicable-p (presentation context-type) (let* ((type (presentation-type presentation)) (type-name (presentation-type-name type)) (object (presentation-object presentation))) (with-presentation-type-decoded (context-name context-parameters) context-type (if (eq type-name 'blank-area) (eq context-name 'blank-area) ;; Let MENU-ITEM-IDENTITY take care of pure menu items (unless (and (eq type-name 'menu-item) (eq context-name 'menu-item)) ;; Either the types definitely match, or the types nominally match ;; and the object must be validated. (or (presentation-subtypep type context-type) (and (not (null context-parameters)) (presentation-typep object context-type))))))))   Received: from BBN.COM by LABS-N.BBN.COM id aa00675; 28 Jul 92 8:48 EDT Received: from fenrix.si.no by BBN.COM id aa04548; 28 Jul 92 8:38 EDT Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.23) id AA20271; Tue, 28 Jul 92 14:39:29 +0200 Date: Tue, 28 Jul 92 14:39:29 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9207281233.AAmonsun06104@D> To: clim@bbn.com Subject: event lookahead Hi, I'm making a window editor and want to process as many keyboard events as possible before refreshing the screen. When I get a keyboard event (using tracking-pointer), I first update the internal editor representation, then try to refresh as little as possible of the screen. Since this takes a long time, there might be several keyboard events waiting each time and I would like to process them all before the next refresh. I need something like get-all-keyboard-events-from-event-queue, perhaps using read-gesture with zero timeout? Any hints? Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.BBN.COM id aa02097; 28 Jul 92 10:18 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa11313; 28 Jul 92 10:13 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1115413; 28 Jul 1992 10:14:46-0400 Date: Tue, 28 Jul 1992 10:15-0400 From: Scott McKay Subject: event lookahead To: Hallvard.Tretteberg@si.no, clim@BBN.COM In-Reply-To: <9207281233.AAmonsun06104@D> Message-ID: <19920728141544.9.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 28 Jul 1992 08:39 EDT From: Hallvard.Tretteberg@si.no Hi, I'm making a window editor and want to process as many keyboard events as possible before refreshing the screen. When I get a keyboard event (using tracking-pointer), I first update the internal editor representation, then try to refresh as little as possible of the screen. Since this takes a long time, there might be several keyboard events waiting each time and I would like to process them all before the next refresh. I need something like get-all-keyboard-events-from-event-queue, perhaps using read-gesture with zero timeout? Any hints? I should thing that doing the following will work: (read-gesture :stream :timeout 0 :peek-p t) Have you tried it and not succeeded?   Received: from BBN.COM by LABS-N.BBN.COM id aa06657; 28 Jul 92 16:13 EDT Received: from rpal.rockwell.com by BBN.COM id aa27447; 28 Jul 92 16:08 EDT Received: from carbon.elements.rpal.rockwell.com (MAC-202.rpal.rockwell.com) by rpal.rockwell.com (4.1/rpal-4.1.0) id AA14350; Tue, 28 Jul 92 13:07:26 PDT Message-Id: <9207282007.AA14350@rpal.rockwell.com> Date: Tue, 28 Jul 92 13:08:14 PST From: Phil Stubblefield Subject: CLIM 1.0 vs. 1.1 Features To: clim@bbn.com X-Mailer: LeeMail 1.2.4 What is the best way to differentiate between the presence of CLIM 1.0 and 1.1? There seem to be no consistent elements on the *FEATURES* list, nor any variable or function related to "RELEASE" or "VERSION". Phil Stubblefield (415) 325-7165 Rockwell Palo Alto Laboratory phil@rpal.rockwell.com   Received: from BBN.COM by LABS-N.BBN.COM id aa07962; 28 Jul 92 17:23 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa03450; 28 Jul 92 17:20 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1115698; 28 Jul 1992 17:22:01-0400 Date: Tue, 28 Jul 1992 17:23-0400 From: Scott McKay Subject: CLIM 1.0 vs. 1.1 Features To: phil@rpal.rockwell.com, clim@BBN.COM In-Reply-To: <9207282007.AA14350@rpal.rockwell.com> Message-ID: <19920728212301.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 28 Jul 1992 17:08 EDT From: Phil Stubblefield I don't think there is a way to distinguish. CLIM 2.0 pushes both :CLIM-2 and :CLIM-2.0 onto *FEATURES*; CLIM 2.1 will obviously push :CLIM-2 and :CLIM-2.1, but omit :CLIM-2.0. I can't offhand think of any functions whose existence you can check for to be able to decide. What is the best way to differentiate between the presence of CLIM 1.0 and 1.1? There seem to be no consistent elements on the *FEATURES* list, nor any variable or function related to "RELEASE" or "VERSION". Phil Stubblefield (415) 325-7165 Rockwell Palo Alto Laboratory phil@rpal.rockwell.com   Received: from BBN.COM by LABS-N.BBN.COM id aa06595; 28 Jul 92 16:09 EDT Received: from jazz.al.alcoa.com by BBN.COM id aa27199; 28 Jul 92 16:04 EDT Received: from HUCKLEBERRY-HOUND.al.alcoa.com by jazz.al.alcoa.com via CHAOS with CHAOS-MAIL id 40953; 28 Jul 92 16:10:21 EDT Date: Tue, 28 Jul 1992 16:01-0400 From: Peter Van Sickel Subject: Reminder: Register for LUV-92 To: slug@ai.sri.com, info-macl@cambridge.apple.com, common-lisp@mcc.com, clim@bbn.com, comp.lang.clos@cis.ohio-state.com, comp.lang.lisp@cis.ohio-state.com Message-ID: <19920728200136.5.PVS@HUCKLEBERRY-HOUND.al.alcoa.com> LUV-92 is fast approaching. August 10 - 14 in San Diego at the US Grant Hotel. For registration information contact Laura Lotz at 215/651-2990. If you haven't seen a brochure descibing the tutorials and speakers, contact your favorite Lisp vendor. Be there!   Received: from BBN.COM by LABS-N.BBN.COM id aa08487; 28 Jul 92 17:54 EDT Received: from chesapeake.ads.com by BBN.COM id aa04313; 28 Jul 92 17:50 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA11719; Tue, 28 Jul 92 17:52:16 EDT Date: Tue, 28 Jul 92 17:52:16 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9207282152.AA11719@chesapeake.ads.com> To: siegle@aristotle.ils.nwu.edu Cc: clim@bbn.com In-Reply-To: Greg Siegle's message of Tue, 28 Jul 92 16:00:31 CDT <9207282100.AA02942@aristotle.ils.nwu.edu> Subject: Re: How-to presentation type question Reply-To: jclose@ads.com   Received: from BBN.COM by LABS-N.BBN.COM id aa07685; 28 Jul 92 17:07 EDT Received: from aristotle.ils.nwu.edu by BBN.COM id aa02826; 28 Jul 92 17:04 EDT Received: by aristotle.ils.nwu.edu (4.1/SMI-ILS-1.05) id AA02942; Tue, 28 Jul 92 16:00:31 CDT Date: Tue, 28 Jul 92 16:00:31 CDT From: siegle@aristotle.ils.nwu.edu (Greg Siegle) Message-Id: <9207282100.AA02942@aristotle.ils.nwu.edu> To: clim@bbn.com Subject: How-to presentation type question Hi there, I'd like to implement a presentation type something like clim:member-alist which changes the color of a selected item rather than boldfaces them. Also I need to be able to specify that some of the items in a given alist are to be bold-faced. User selection of a presentation will not change whether an item is bold-faced. Can this be done as a presentation type abbreviation of clim:completion? So far it's seemed much more difficult than I believe it should be... Is there an easy way to implement this? I'm working in Lucid CLIM 1.1 on an IBM RS/6000. Thanks in advance. -- Greg   Received: from BBN.COM by LABS-N.BBN.COM id aa13085; 28 Jul 92 22:44 EDT Received: from hyper.franz.com by BBN.COM id aa14579; 28 Jul 92 22:40 EDT Return-Path: Received: from fiona.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA27152; Tue, 28 Jul 92 19:37:57 PDT Received: by fiona.Franz.COM (4.0/FI-2.0) id AA14856; Tue, 28 Jul 92 19:38:05 PDT Date: Tue, 28 Jul 92 19:38:05 PDT From: colin@Franz.COM (Colin Meldrum) Message-Id: <9207290238.AA14856@fiona.Franz.COM> To: Thomas.Ruedesheim@sniap.mchp.sni.de Class: bh Bh-Id: spr6202 Bh: append spr6202 Subject: Re: [spr6202] Question about defining presentation types with parameters and options Cc: bugs@Franz.COM, clim@bbn.com Your problem report has been assigned a tracking id of spr6202, so please use this id in the subject line of any mail related to it so that we may better track communication on your inquiry. Also, please cc bugs@franz.com, so your questions can be answered if I am unavailable. Hi there, Consider the following small example: ;;; -*- Mode: Common-Lisp; Package: CLIM-USER; -*- (define-presentation-type sentence (language) :options (direction) :inherit-from 'string) (define-presentation-method accept ((type sentence) stream (view textual-view) &key) (with-input-editing (stream) (read-line stream))) (define-presentation-method present (object (type sentence) stream (view textual-view) &key) (format stream "~a" object)) (define-presentation-method presentation-typep (object (type sentence)) (and (typep object 'standard-presentation) (let ((ptype (presentation-type object))) (and (listp ptype) (equal ptype (list 'sentence language))))) ) (define-presentation-method presentation-subtypep ((type sentence) putative-supertype) (let (language1) (with-presentation-type-parameters (sentence type) (setf language1 language)) (with-presentation-type-parameters (sentence putative-supertype) (if (eq language1 language) (values t t) (values nil t))))) (defun test () (present "Das Haus brennt" '((sentence german) :direction :source)) (terpri) (present "The house burns." '((sentence english) :direction :target)) (terpri) (accept '((sentence german) :direction :source))) Here is my question: Call the function test inside an application frame's interactor pane. The inner call to ACCEPT accepts both the german and the english sentence. How could I change my code, so that only german sentences are accepted? Thomas Hello, It seems that Scott McKay should have answered your problem though his bug fix should be in the clim-internals package rather than the clim package. ie (in-package :clim-internals) ;^^^^^^^^^^ (defun identity-translator-applicable-p (presentation context-type) (let* ((type (presentation-type presentation)) (type-name (presentation-type-name type)) (object (presentation-object presentation))) (with-presentation-type-decoded (context-name context-parameters) context-type (if (eq type-name 'blank-area) (eq context-name 'blank-area) ;; Let MENU-ITEM-IDENTITY take care of pure menu items (unless (and (eq type-name 'menu-item) (eq context-name 'menu-item)) ;; Either the types definitely match, or the types nominally match ;; and the object must be validated. (or (presentation-subtypep type context-type) (and (not (null context-parameters)) (presentation-typep object context-type)))))))) Hope this has fixed your problem adequately. ----- Colin Meldrum, Franz Inc. 1995 University Avenue, Suite 275 colin@Franz.COM (internet) Berkeley, CA 94704 uunet!franz!colin (uucp) Phone: (510) 548-3600; FAX: (510) 548-8253   Received: from BBN.COM by LABS-N.BBN.COM id aa26227; 29 Jul 92 11:21 EDT Received: from hermes.intel.com by BBN.COM id aa28647; 29 Jul 92 11:16 EDT Received: from taos.intel.com by hermes.intel.com (5.65/10.0i); Wed, 29 Jul 92 08:16:34 -0700 Received: from nachos by taos via INTERNET with SMTP id 34487; 29 Jul 1992 09:17:17-0600 Date: Wed, 29 Jul 1992 09:17-0600 From: marcos@taos.intel.com Subject: Symbolics CLOE mailing list To: clim%BBN.COM@hermes.intel.com Fcc: N:>marcos>mail>mail-fcc.text.newest Message-Id: <19920729151709.1.MARCOS@nachos> Is there a mailing list for Symbolics CLOE, similar to the mailing list for Mac Common Lisp, only for CLIM/CLOS/Windows issues? Marcos Paz Intel Corp. 4100 Sara Rd. MS F9-04 Rio Rancho, NM 87124 (505) 893-1623 mpaz@taos.intel.com   Received: from BBN.COM by LABS-N.BBN.COM id aa25655; 29 Jul 92 10:35 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa26003; 29 Jul 92 10:29 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1116018; 29 Jul 1992 10:22:41-0400 Date: Wed, 29 Jul 1992 10:23-0400 From: Scott McKay Subject: Re: [spr6202] Question about defining presentation types with parameters and options To: colin@franz.com, Thomas.Ruedesheim@sniap.mchp.sni.de cc: bugs@franz.com, clim@BBN.COM In-Reply-To: <9207290238.AA14856@fiona.Franz.COM> Message-ID: <19920729142345.9.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 28 Jul 1992 22:38 EDT From: Colin Meldrum Your problem report has been assigned a tracking id of spr6202, so please use this id in the subject line of any mail related to it so that we may better track communication on your inquiry. Also, please cc bugs@franz.com, so your questions can be answered if I am unavailable. Hi there, Consider the following small example: ;;; -*- Mode: Common-Lisp; Package: CLIM-USER; -*- (define-presentation-type sentence (language) :options (direction) :inherit-from 'string) (define-presentation-method accept ((type sentence) stream (view textual-view) &key) (with-input-editing (stream) (read-line stream))) (define-presentation-method present (object (type sentence) stream (view textual-view) &key) (format stream "~a" object)) (define-presentation-method presentation-typep (object (type sentence)) (and (typep object 'standard-presentation) (let ((ptype (presentation-type object))) (and (listp ptype) (equal ptype (list 'sentence language))))) ) (define-presentation-method presentation-subtypep ((type sentence) putative-supertype) (let (language1) (with-presentation-type-parameters (sentence type) (setf language1 language)) (with-presentation-type-parameters (sentence putative-supertype) (if (eq language1 language) (values t t) (values nil t))))) (defun test () (present "Das Haus brennt" '((sentence german) :direction :source)) (terpri) (present "The house burns." '((sentence english) :direction :target)) (terpri) (accept '((sentence german) :direction :source))) Here is my question: Call the function test inside an application frame's interactor pane. The inner call to ACCEPT accepts both the german and the english sentence. How could I change my code, so that only german sentences are accepted? Thomas Hello, It seems that Scott McKay should have answered your problem though his bug fix should be in the clim-internals package rather than the clim package. There's a bit of confusion here. In CLIM 1.0/1.1, the package :CLIM is both the "export" package and the implementation package. In CLIM 2.0, the "export" package is :CLIM and the implementation package is :CLIM-INTERNALS. Assuming that H. Ruedesheim is using CLIM 1.1, the IN-PACKAGE form should use :CLIM; if he is useing CLIM 2.0, the IN-PACKAGE form should use :CLIM-INTERNALS. ie (in-package :clim-internals) ;^^^^^^^^^^ (defun identity-translator-applicable-p (presentation context-type) (let* ((type (presentation-type presentation)) (type-name (presentation-type-name type)) (object (presentation-object presentation))) (with-presentation-type-decoded (context-name context-parameters) context-type (if (eq type-name 'blank-area) (eq context-name 'blank-area) ;; Let MENU-ITEM-IDENTITY take care of pure menu items (unless (and (eq type-name 'menu-item) (eq context-name 'menu-item)) ;; Either the types definitely match, or the types nominally match ;; and the object must be validated. (or (presentation-subtypep type context-type) (and (not (null context-parameters)) (presentation-typep object context-type)))))))) Hope this has fixed your problem adequately. ----- Colin Meldrum, Franz Inc. 1995 University Avenue, Suite 275 colin@Franz.COM (internet) Berkeley, CA 94704 uunet!franz!colin (uucp) Phone: (510) 548-3600; FAX: (510) 548-8253   Received: from BBN.COM by LABS-N.BBN.COM id aa26813; 29 Jul 92 11:58 EDT Received: from aplcen.apl.jhu.edu by BBN.COM id aa00766; 29 Jul 92 11:54 EDT Received: by aplcen.apl.jhu.edu (5.57/Ultrix2.4-XDccg) id AA15806; Wed, 29 Jul 92 11:54:09 -0400 Date: Wed, 29 Jul 92 11:54:09 -0400 From: hall@aplcen.apl.jhu.edu (Marty Hall) Message-Id: <9207291554.AA15806@aplcen.apl.jhu.edu> In-Reply-To: marcos@taos.intel.com's message of Jul 29, 9:17 X-Mailer: Mail User's Shell (6.1 4/26/88) To: marcos@taos.intel.com, clim@bbn.com Subject: Re: Symbolics CLOE mailing list In message entitled "Symbolics CLOE mailing list" on Jul 29, Marcos Paz writes: > > Is there a mailing list for Symbolics CLOE, similar to the mailing list > for Mac Common Lisp, only for CLIM/CLOS/Windows issues? The main Symbolics mailing list includes CLOE discussions. Use slug-request@ai.sri.com to subscribe/unsubscribe, and slug@ai.sri.com to send to the whole group. You could also try Roberta Ingemi at Symbolics; I think she is overseeing CLOE nowadays, and may know more. 508-287-155, ingemi@riverside.scrc.symbolics.com. - Marty Hall ---------------------------------------------------------------------- Q: Did you bring your Rollerblades? A: (Catholic-p 'Pope) - Conversation with Paul McNamee   Received: from BBN.COM by LABS-N.BBN.COM id aa25950; 29 Jul 92 11:00 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa26874; 29 Jul 92 10:45 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1116037; 29 Jul 1992 10:46:03-0400 Date: Wed, 29 Jul 1992 10:47-0400 From: Scott McKay Subject: How-to presentation type question To: siegle@aristotle.ils.nwu.edu, clim@BBN.COM In-Reply-To: <9207282100.AA02942@aristotle.ils.nwu.edu> Message-ID: <19920729144707.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 28 Jul 1992 17:00 EDT From: Greg Siegle Hi there, I'd like to implement a presentation type something like clim:member-alist which changes the color of a selected item rather than boldfaces them. Also I need to be able to specify that some of the items in a given alist are to be bold-faced. User selection of a presentation will not change whether an item is bold-faced. Can this be done as a presentation type abbreviation of clim:completion? So far it's seemed much more difficult than I believe it should be... Is there an easy way to implement this? I'm working in Lucid CLIM 1.1 on an IBM RS/6000. Thanks in advance. -- Greg I used this kludge in a program I wrote recently. I hope that we come up with a cleaner interface for CLIM 2.0. I'm sure you can tailor this to fit your requirements... -------- (define-presentation-type line-thickness () :inherit-from `(integer 1 4)) (define-presentation-method accept-present-default ((type line-thickness) stream (view dialog-view) default default-supplied-p present-p query-identifier) (declare (ignore default-supplied-p present-p)) (flet ((presenter (thing stream) (let ((y (stream-line-height stream))) (with-room-for-graphics (stream) (draw-rectangle* stream 0 2 16 (- y 2) :filled nil :ink +background+) (draw-line* stream 0 (floor y 2) 16 (floor y 2) :line-thickness thing))))) (declare (dynamic-extent #'presenter)) (clim::accept-values-choose-from-sequence-1 stream '(("1" 1) ("2" 2) ("3" 3) ("4" 4)) #'second default #'eql type query-identifier #'(lambda (choice-value query-value) (declare (ignore query-value)) choice-value) #'(lambda (continuation object stream) (surrounding-output-with-border (stream) (funcall continuation object stream))) 'clim::accept-values-one-of #'presenter)))   Received: from BBN.COM by LABS-N.BBN.COM id aa27889; 29 Jul 92 13:11 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa04028; 29 Jul 92 13:08 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1116149; 29 Jul 1992 13:09:14-0400 Date: Wed, 29 Jul 1992 13:10-0400 From: Scott McKay Subject: CLIM windows and xlib resources To: jmorrill@BBN.COM, clim@BBN.COM In-Reply-To: <10095.703521967@bbn.com> Message-ID: <19920729171017.0.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 17 Apr 1992 10:46 EDT From: Jeff Morrill Those of you using CLIM 1.1 under X Windows may be interested in this. After making a frame but before calling clim:run-frame-top-level to expose it, it is useful to perform the following operation on the frame: #+xlib (let ((xwin (slot-value (clim:frame-top-level-window frame) 'clim::window))) (xlib:set-wm-class xwin "clim" "clim")) 1. The UNIX command xprop may finally be used to see that indeed it is a clim window. 2. One may add lines to a resources file (such as .Xdefaults) to control what the window manager does with clim windows: olwm.MinimalDecor: clim 3. Having a WM_CLASS attribute, it is easy to write standard XLIB calls in C that do interesting things to CLIM windows. We have one that changes the mouse cursor of clim windows to a wristwatch during GC operations. Enjoy. jeff morrill p.s. Can the CLIM developers add this in for the next release? Please? Done in CLIM 2.0   Received: from BBN.COM by LABS-N.BBN.COM id aa27717; 29 Jul 92 13:00 EDT Received: from [128.233.1.11] by BBN.COM id aa03554; 29 Jul 92 12:56 EDT Received: from access.USask.Ca by SASK.USask.CA (PMDF #12333) id <01GMY5JZVY7400473L@SASK.USask.CA>; Wed, 29 Jul 1992 10:58 CST Received: by access.USask.Ca (5.57/GLH-1.0); Wed, 29 Jul 92 10:55:47 -0600 id AA29910 for clim@bbn.com Received: from skaries.USask.ca by skdad.USask.ca (4.1/SMI-4.1) id AA03566; Wed, 29 Jul 92 10:55:37 CST Date: Wed, 29 Jul 92 10:55:35 CST From: coulman@skdad.usask.ca (Randy Coulman) Subject: Strange accepting-values behavior (and more) To: clim@bbn.com Message-id: <9207291655.AA03566@skdad.USask.ca> X-Envelope-to: clim@bbn.com X-Mailer: ELM [version 2.3 PL11] I'm using Franz CLIM 1.1 on a Sparc 1+ with Allegro CL 4.1. I have a couple of questions/comments: 1.) I am working on a type of graph editor using CLIM. I have defined a new gesture which I call :part. I also have a command com-attach-part which takes one argument, the part to attach. The command can either be invoked via menu or by using the :part gesture on an appropriate object. The command is designed to attach the selected object to the current focus object in the graph. The command pops up an accepting values dialog (:own-window t) to allow the user to customize the interaction between the part and the focus object. Two of the accepts in the dialog look like this: (setq rel (accept '(member = < > <= >= /=) :stream stream :default rel ;; initially '= :provide-default t :insert-default t :prompt "Number of occurrences must be")) (princ " " stream) (setq comp (accept 'number :stream stream :default comp ;; initially 1 :provide-default t :insert-default t :prompt nil :display-default nil)) Two things: If the command is activated via the menu, the relevant section of the dialog looks like this: Number of occurrences must be: = < > <= >= /= 1 If, instead, the gesture is used to invoke the command, the dialog looks like this: Number of occurrences must be: = < > <= >= /= 1 which is what I want all the time. Why are the two different? Second, the = is not initially highlighted. If I select something else, that gets highlighted. If I then re-select =, it is not highlighted. Any ideas? Or is it that the bolding of the = sign just doesn't show up on my display? 2.) This is more of a comment. I use define-border-type to define a new border type for nodes in my graph. Here is the code: (clim:define-border-type :ellipse (stream record left top right bottom) (declare (ignore record)) (let ((cx (/ (+ left right) 2)) (cy (/ (+ top bottom) 2)) (rx (+ 8 (/ (- right left) 2))) ;; the 8 is to ensure that the (ry (+ 8 (/ (- bottom top) 2))) ) ;; ellipse surrounds the text (clim:draw-ellipse* stream cx cy rx 0 0 ry :filled nil)) ) When this code is compiled, the declare form is ignored and I still get a warning message about not using record. I'm not sure if this is a general CLIM issue, or if it is specifically related to Franz's version. It doesn't cause a crash, but I pride myself on writing "warning-free" code and this warning message violates that. Thanks for any help, Randy -- Randy A. Coulman | ARIES Laboratory | Department of Computational Science coulman@cs.Usask.ca | University of Saskatchewan | Saskatoon, SK S7N 0W0   Received: from BBN.COM by LABS-N.BBN.COM id aa29007; 29 Jul 92 14:25 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa07695; 29 Jul 92 14:22 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1116210; 29 Jul 1992 14:22:13-0400 Date: Wed, 29 Jul 1992 14:23-0400 From: Scott McKay Subject: Strange accepting-values behavior (and more) To: coulman@skdad.usask.ca, clim@BBN.COM In-Reply-To: <9207291655.AA03566@skdad.USask.ca> Message-ID: <19920729182319.7.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 29 Jul 1992 12:55 EDT From: Randy Coulman I'm using Franz CLIM 1.1 on a Sparc 1+ with Allegro CL 4.1. I have a couple of questions/comments: 1.) I am working on a type of graph editor using CLIM. I have defined a new gesture which I call :part. I also have a command com-attach-part which takes one argument, the part to attach. The command can either be invoked via menu or by using the :part gesture on an appropriate object. The command is designed to attach the selected object to the current focus object in the graph. The command pops up an accepting values dialog (:own-window t) to allow the user to customize the interaction between the part and the focus object. Two of the accepts in the dialog look like this: (setq rel (accept '(member = < > <= >= /=) :stream stream :default rel ;; initially '= :provide-default t :insert-default t :prompt "Number of occurrences must be")) (princ " " stream) (setq comp (accept 'number :stream stream :default comp ;; initially 1 :provide-default t :insert-default t :prompt nil :display-default nil)) Two things: If the command is activated via the menu, the relevant section of the dialog looks like this: Number of occurrences must be: = < > <= >= /= 1 The window used for the own-window dialog is gotten from the same resource as the window used for the menu, and the narrower width window from the menu is affecting the dialog. I believe that this is now fixed in CLIM 2.0 If, instead, the gesture is used to invoke the command, the dialog looks like this: Number of occurrences must be: = < > <= >= /= 1 which is what I want all the time. Why are the two different? Second, the = is not initially highlighted. If I select something else, that gets highlighted. If I then re-select =, it is not highlighted. Any ideas? Or is it that the bolding of the = sign just doesn't show up on my display? The bolding of the = sign is not showing up. 2.) This is more of a comment. I use define-border-type to define a new border type for nodes in my graph. Here is the code: (clim:define-border-type :ellipse (stream record left top right bottom) (declare (ignore record)) (let ((cx (/ (+ left right) 2)) (cy (/ (+ top bottom) 2)) (rx (+ 8 (/ (- right left) 2))) ;; the 8 is to ensure that the (ry (+ 8 (/ (- bottom top) 2))) ) ;; ellipse surrounds the text (clim:draw-ellipse* stream cx cy rx 0 0 ry :filled nil)) ) When this code is compiled, the declare form is ignored and I still get a warning message about not using record. I'm not sure if this is a general CLIM issue, or if it is specifically related to Franz's version. It doesn't cause a crash, but I pride myself on writing "warning-free" code and this warning message violates that. Just omit RECORD from the arglist.   Received: from BBN.COM by LABS-N.BBN.COM id aa00511; 29 Jul 92 16:16 EDT Received: from [129.197.134.99] by BBN.COM id aa20874; 29 Jul 92 16:11 EDT Received: from jade.rdd.lmsc.lockheed.com by dipl.rdd.lmsc.lockheed.com (4.0/SMI-4.1) id AA03755; Wed, 29 Jul 92 13:16:31 PDT Received: from dipl.rdd.lmsc.lockheed.com by jade.rdd.lmsc.lockheed.com (4.1/SMI-4.0) id AA27554; Wed, 29 Jul 92 13:11:59 PDT Date: Wed, 29 Jul 92 13:11:59 PDT From: ttrinko@dipl.rdd.lmsc.lockheed.com (Tom Trinko) Message-Id: <9207292011.AA27554@jade.rdd.lmsc.lockheed.com> To: clim@bbn.com Subject: selective accept This is on a symbolics running genera 8.1.1 and CLIM 1.1 but the problem also appears on the SUN I need to allow only certain instances of a class to be accepted in a certain accept statement. I supply parameters which are used in the determination. Present-typep correctly evaluates the parameters and returns nil for the instances that are not supposed to present. Unfortunetly the instances present--ie a box is draw around them--anyway. I even hardwired presentation-typep so it always returned nil and that made no difference. If i use the help key to get the suggestions for what instances are acceptable i get the correct list with only the intances that pass the test in present, which is based on the parameters in the accept statement. I tried using the modifications to identity-translator-applicable-p that were posted here recently but that didn't seem to help. The basic question is how do I limit which instances of a class are mouse sensitive? the basic code layout is (accept `((unit :parameter ,test-value ...)) presentation-typep (if (function test-value) t nil) Thanks for any help.   Received: from BBN.COM by LABS-N.BBN.COM id aa00838; 29 Jul 92 16:40 EDT Received: from mwunix.mitre.org by BBN.COM id aa22213; 29 Jul 92 16:35 EDT Return-Path: Received: from cypress.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA10362; Wed, 29 Jul 92 16:33:28 -0400 Received: by cypress.mitre.org (4.1/SMI-4.1) id AA01164; Wed, 29 Jul 92 16:40:21 EDT Date: Wed, 29 Jul 92 16:40:21 EDT From: gmw@cypress.mitre.org (Gregory M. Whittaker) Message-Id: <9207292040.AA01164@cypress.mitre.org> To: CLIM@bbn.com Subject: Tutorial Problems for CLIM updated to 2.0 Cc: greg@mitre.org I have been trying to work through some example code shown in papers by ILA, and tutorials given by Franz. These were written over a year ago in some cases 2 or more years ago. I am not having an easy time with any of this older code on version 2.0.alpha. Are you aware of any simple short 2.0 compatible example code that would be likely to work on 2.0.alpha. For tutorial purposes, much of the code presented in the CLIM demos distributed with 2.0.alpha is too complex. (also, it is very easy to hang up the entire system when working with some of these examples) In lieu of any tutorial code, do you know of any tutorial printed matter, that is compatible with 2.0. It is very difficult to get started with the 2.0 CLIM specification, because it obviously was not intended to be tutorial in nature, and because there are hidden pitfalls in the alpha implementation. Any suggestions? -------- Cordially, Gregory M. Whittaker, The MITRE Corporation Center for Advanced Aviation System Development Internet: greg@mitre.org 7525 Colshire Drive Phone: (703) 883-5549 McLean Virginia 22102-3481 FAX: (703) 883-1226 Mail Stop: W215   Received: from BBN.COM by LABS-N.BBN.COM id aa01493; 29 Jul 92 17:24 EDT Received: from gatech.edu by BBN.COM id aa25203; 29 Jul 92 17:19 EDT Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA12359 for clim@bbn.com; Wed, 29 Jul 92 17:19:37 EDT Received: from pravda.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA08893; for ttrinko@dipl.rdd.lmsc.lockheed.com; Wed, 29 Jul 92 17:19:30 EDT Received: from kant.gatech.edu (kant.cc.gatech.edu) by pravda.cc.gatech.edu (4.1/SMI-4.1) id AA21108; Wed, 29 Jul 92 17:19:17 EDT Date: Wed, 29 Jul 1992 17:17-0400 From: Richard Billington Subject: selective accept To: ttrinko@dipl.rdd.lmsc.lockheed.com, clim@bbn.com In-Reply-To: <9207292011.AA27554@jade.rdd.lmsc.lockheed.com> Message-Id: <19920729211748.5.BUFF@kant.gatech.edu> Character-Type-Mappings: (1 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB") Fonts: CPTFONT, CPTFONTCB Just a couple of quick ideas, 'cause I'm not sure I exactly understand your problem: what about defining a tester for the translator? Alternatively, (and this is where I'm not sure I understand your problem), create a new presentation type which inherits from your present one and create translators for that new type: (define-presentation-type 1button 0(button-type) :options (aspect) :description "Buttons display some representation of an object and associate behavior with it. button-type ::= [ link | aspect | user-type | set | control ] aspect ::= [ text | graphic | video ]") (define-presentation-type 1hyperobject-link-button 0() :options (link-aspect) :inherit-from `((button link) :aspect ,link-aspect)) Also don't forget that you've got to define a presentation-subtypep method for parameterized presentation-types (sec. 17.6.2, p. 170 Symbolics CLIM).   Received: from BBN.COM by LABS-N.BBN.COM id aa04705; 30 Jul 92 0:05 EDT Received: from ptolemy-arclan.arc.nasa.gov by BBN.COM id aa29638; 30 Jul 92 0:01 EDT Received: from dennett.arc.nasa.gov by ptolemy.arc.nasa.gov (4.1/) id ; Wed, 29 Jul 92 21:01:55 PDT Date: Wed, 29 Jul 92 21:01:55 PDT From: Philip Chu-Summer 92 Message-Id: <9207300401.AA02734@ptolemy.arc.nasa.gov> Received: by dennett.arc.nasa.gov (4.1/SMI-4.1) id AA01580; Wed, 29 Jul 92 21:02:21 PDT To: clim@bbn.com Subject: list of color constants Is there a variable or function that will give me a list of the names of all the provided color constants? I'd like to make a menu or dialog to choose colors, and I don't want to type them all in. I'm using CLIM 2.0a with Franz Allegro CL. Phil Chu Artificial Intelligence Research Branch NASA Ames Research Center pchu@ptolemy.arc.nasa.gov   Received: from BBN.COM by LABS-N.BBN.COM id ab10359; 30 Jul 92 10:07 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa17189; 30 Jul 92 9:47 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1116726; 30 Jul 1992 09:19:53-0400 Date: Thu, 30 Jul 1992 09:19-0400 From: Scott McKay Subject: selective accept To: ttrinko@dipl.rdd.lmsc.lockheed.com, clim@BBN.COM In-Reply-To: <9207292011.AA27554@jade.rdd.lmsc.lockheed.com> Message-ID: <19920730131955.6.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 29 Jul 1992 16:11 EDT From: Tom Trinko This is on a symbolics running genera 8.1.1 and CLIM 1.1 but the problem also appears on the SUN I need to allow only certain instances of a class to be accepted in a certain accept statement. I supply parameters which are used in the determination. Present-typep correctly evaluates the parameters and returns nil for the instances that are not supposed to present. Unfortunetly the instances present--ie a box is draw around them--anyway. I even hardwired presentation-typep so it always returned nil and that made no difference. If i use the help key to get the suggestions for what instances are acceptable i get the correct list with only the intances that pass the test in present, which is based on the parameters in the accept statement. I tried using the modifications to identity-translator-applicable-p that were posted here recently but that didn't seem to help. The basic question is how do I limit which instances of a class are mouse sensitive? the basic code layout is (accept `((unit :parameter ,test-value ...)) presentation-typep (if (function test-value) t nil) Thanks for any help. Please send a small, failing test case, so I don't have to come up with one myself.   Received: from BBN.COM by LABS-N.BBN.COM id aa10423; 30 Jul 92 10:13 EDT Received: from aio.jsc.nasa.gov by BBN.COM id aa17974; 30 Jul 92 10:03 EDT Received: by aio.jsc.nasa.gov (5.57/Ultrix3.0-C) id AA19204; Thu, 30 Jul 92 09:03:24 -0500 Date: Thu, 30 Jul 92 09:03:24 -0500 From: fleming@aio.jsc.nasa.gov (Land Fleming) Message-Id: <9207301403.AA19204@aio.jsc.nasa.gov> To: clim@bbn.com Subject: Selective Accept I think I have a similar problem to the one described in the orignal question on "Selective Accept:" I have defined a "NODE presentation and have commands that involve accept statements accepting such presentations. My problem is that the "accept" statement is supposed to accept only nodes from a previously specified graph, and there may be any number of graphs currently displayed, all of which have sets of nodes that are mututally exclusive but all of the same class (NODE); Duing the accept interaction, any presentation of a NODE is highlighted when the pointer moves over it, even if it is a node in the wrong graph. I haven't been able to think of a way to control the highlighting of presentations of the same kind. What I would like is to be able to pass a :TEST function argument to the accept function itself (not the command translator, since the command leading to the accept is not involved here). I would then be able to test if a given Node's "graph" slot held a pointer to the appropriate graph by writing a statement like: (accept Node :TEST #'(lambda (node.presentation) (eq (graph (presentation-object node.presentation)) *current-graph*))), where "graph" is s slot in the node object pointing to the graph that it is in. My current "solution" is just do the test of the presentation after it is accepted and inform the user that the node selected is not from the intended graph. This is not really satisfactory because the nodes not in the selected graph should not be highlighted in the first place. I would like to see such a :TEST capability for the accept function in CLIM 2.0. L.D. Fleming   Received: from BBN.COM by LABS-N.BBN.COM id aa10172; 30 Jul 92 9:59 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa17200; 30 Jul 92 9:48 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1116727; 30 Jul 1992 09:22:49-0400 Date: Thu, 30 Jul 1992 09:22-0400 From: Scott McKay Subject: Tutorial Problems for CLIM updated to 2.0 To: gmw@cypress.mitre.org, CLIM@BBN.COM cc: greg@mitre.org In-Reply-To: <9207292040.AA01164@cypress.mitre.org> Message-ID: <19920730132250.7.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 29 Jul 1992 16:40 EDT From: "Gregory M. Whittaker" I have been trying to work through some example code shown in papers by ILA, and tutorials given by Franz. These were written over a year ago in some cases 2 or more years ago. I am not having an easy time with any of this older code on version 2.0.alpha. Are you aware of any simple short 2.0 compatible example code that would be likely to work on 2.0.alpha. For tutorial purposes, much of the code presented in the CLIM demos distributed with 2.0.alpha is too complex. (also, it is very easy to hang up the entire system when working with some of these examples) In lieu of any tutorial code, do you know of any tutorial printed matter, that is compatible with 2.0. It is very difficult to get started with the 2.0 CLIM specification, because it obviously was not intended to be tutorial in nature, and because there are hidden pitfalls in the alpha implementation. Any suggestions? There is no proper documentation for CLIM 2.0 yet. That's one of the pitfalls of using an alpha release, unfortunately. I think you will simply have to rely on the CLIM 1.0/1.1 documentation, and use Appendix E from the CLIM 2.0 specification to guide you in where the differences are. The only place Appendix E is useless is in descibing the differences between the frame pane and layout language; for this, you will have to rely on the code in the CLIM demos. I'm sorry that the answer is not more satisfactory. -------- Cordially, Gregory M. Whittaker, The MITRE Corporation Center for Advanced Aviation System Development Internet: greg@mitre.org 7525 Colshire Drive Phone: (703) 883-5549 McLean Virginia 22102-3481 FAX: (703) 883-1226 Mail Stop: W215   Received: from BBN.COM by LABS-N.BBN.COM id aa10359; 30 Jul 92 10:06 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa17183; 30 Jul 92 9:47 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1116717; 30 Jul 1992 09:15:09-0400 Date: Thu, 30 Jul 1992 09:15-0400 From: Scott McKay Subject: list of color constants To: pchu@ptolemy.arc.nasa.gov, clim@BBN.COM In-Reply-To: <9207300401.AA02734@ptolemy.arc.nasa.gov> Message-ID: <19920730131511.5.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 30 Jul 1992 00:01 EDT From: Philip Chu-Summer 92 Is there a variable or function that will give me a list of the names of all the provided color constants? I'd like to make a menu or dialog to choose colors, and I don't want to type them all in. I'm using CLIM 2.0a with Franz Allegro CL. Why not just create a dialog to allow the person to choose RGB values? The named color constants are pretty arbitrary, and quite a few people have suggested that they be flushed from CLIM altogether.   Received: from BBN.COM by LABS-N.BBN.COM id aa12616; 30 Jul 92 13:46 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa28868; 30 Jul 92 13:40 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA00389; Thu, 30 Jul 92 10:39:44 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA02667; Thu, 30 Jul 92 10:32:13 PDT Date: Thu, 30 Jul 92 10:32:13 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9207301732.AA02667@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: Wishful - Sequence presentation type standard change I have found that I use the sequence presentation type a lot of times in situations that I wish it had an optional parameter(s) specifying length. This is only just a suggestion! I know can make my own subtype inheriting from sequence (already have), but has any of the CLIM creators gave much thought of standardizing that presentation type to utilize an optional length parameter for sequence, sort of like the string type. It would make it a little more consistent in the base types CLIM provides.   Received: from BBN.COM by LABS-N.BBN.COM id aa12079; 30 Jul 92 12:54 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa26711; 30 Jul 92 12:47 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1116885; 30 Jul 1992 12:48:38-0400 Date: Thu, 30 Jul 1992 12:48-0400 From: Scott McKay Subject: Selective Accept To: fleming@aio.jsc.nasa.gov, clim@BBN.COM In-Reply-To: <9207301403.AA19204@aio.jsc.nasa.gov> Message-ID: <19920730164839.9.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 30 Jul 1992 10:03 EDT From: Land Fleming I think I have a similar problem to the one described in the orignal question on "Selective Accept:" I have defined a "NODE presentation and have commands that involve accept statements accepting such presentations. My problem is that the "accept" statement is supposed to accept only nodes from a previously specified graph, and there may be any number of graphs currently displayed, all of which have sets of nodes that are mututally exclusive but all of the same class (NODE); Duing the accept interaction, any presentation of a NODE is highlighted when the pointer moves over it, even if it is a node in the wrong graph. I haven't been able to think of a way to control the highlighting of presentations of the same kind. What I would like is to be able to pass a :TEST function argument to the accept function itself (not the command translator, since the command leading to the accept is not involved here). I would then be able to test if a given Node's "graph" slot held a pointer to the appropriate graph by writing a statement like: (accept Node :TEST #'(lambda (node.presentation) (eq (graph (presentation-object node.presentation)) *current-graph*))), where "graph" is s slot in the node object pointing to the graph that it is in. My current "solution" is just do the test of the presentation after it is accepted and inform the user that the node selected is not from the intended graph. This is not really satisfactory because the nodes not in the selected graph should not be highlighted in the first place. I would like to see such a :TEST capability for the accept function in CLIM 2.0. ACCEPT doesn't need such a capability. Simply add a PRESENTATION-TYPEP method to your NODE presentation type that does the same test.   Received: from BBN.COM by LABS-N.BBN.COM id aa14623; 30 Jul 92 15:44 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa05957; 30 Jul 92 15:30 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1117010; 30 Jul 1992 15:31:15-0400 Date: Thu, 30 Jul 1992 15:31-0400 From: Scott McKay Subject: Wishful - Sequence presentation type standard change To: curt@eraserhead.jpl.nasa.gov, clim@BBN.COM In-Reply-To: <9207301732.AA02667@eraserhead.Jpl.Nasa.Gov> Message-ID: <19920730193116.5.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 30 Jul 1992 13:32 EDT From: Curt Eggemeyer I have found that I use the sequence presentation type a lot of times in situations that I wish it had an optional parameter(s) specifying length. This is only just a suggestion! I know can make my own subtype inheriting from sequence (already have), but has any of the CLIM creators gave much thought of standardizing that presentation type to utilize an optional length parameter for sequence, sort of like the string type. It would make it a little more consistent in the base types CLIM provides. Adding a length argument to the SEQUENCE presentation type would make it inconsistent with the Common Lisp SEQUENCE type. We have tried to avoid this as much as possible throughout CLIM. I propose you do this (if you haven't already): (define-presentation-type-abbreviation bounded-sequence (element-type length) `((sequence-enumerated ,@(make-list length :initial-element element-type)) :separator ,separator :echo-space ,echo-space) :options ((separator #\,) (echo-space t))) If you want it to be spiffier, you can make this change, too, which I will include in CLIM 2.0: (in-package #+clim-1 :clim #+clim-2 :clim-internals) (define-presentation-method describe-presentation-type ((type sequence-enumerated) stream plural-count) (declare (ignore plural-count)) ;it's too hard to handle (cond ((let ((type (first element-types))) (dolist (x (cdr element-types) t) (unless (equal x type) (return nil)))) ;; Do this if all the element types are the same (format stream "~D " (length element-types)) (describe-presentation-type (car element-types) stream (length element-types))) (t (let ((position 0) (last (1- (length element-types)))) (dolist (element-type element-types) (describe-presentation-type element-type stream 1) (unless (= position last) (write-string (if (= last 1) " " ", ") stream) (when (= (incf position) last) (write-string "and " stream))))))))   Received: from BBN.COM by LABS-N.BBN.COM id aa24182; 31 Jul 92 10:00 EDT Received: from fenrix.si.no by BBN.COM id aa02044; 31 Jul 92 9:54 EDT Received: from monsun.si.no by fenrix.si.no with SMTP (16.7/16.4.1.23) id AA19916; Fri, 31 Jul 92 15:55:37 +0200 Date: Fri, 31 Jul 92 15:55:37 +0200 From: Hallvard.Tretteberg@si.no Message-Id: <9207311349.AAmonsun06838@D> To: clim@bbn.com Subject: CLIM for MCL 2.0 (final) I just received my MCL 2.0 upgrade from beta to final, but until I get the CLIM upgrade I'll still have to include (both beta) in my questions. Does anybody know when the CLIM upgrade for MCL 2.0 (final) will be shipping? The doc mentions CLIM 1.1 and a CLIM demo, is this the upgrade I'm looking for? Thanks, Hallvard Hallvard Traetteberg Dept. of Knowledge Based Systems Center for Industrial Research Box 124 Blindern, 0314 Oslo 3 NORWAY Tlf: +47 2 45 20 10 Fax: +47 2 45 20 40 Email: haltraet@si.no   Received: from BBN.COM by LABS-N.BBN.COM id aa01187; 31 Jul 92 17:57 EDT Received: from ptolemy-arclan.arc.nasa.gov by BBN.COM id aa25509; 31 Jul 92 17:47 EDT Received: from dennett.arc.nasa.gov by ptolemy.arc.nasa.gov (4.1/) id ; Fri, 31 Jul 92 14:47:41 PDT Date: Fri, 31 Jul 92 14:47:41 PDT From: Philip Chu-Summer 92 Message-Id: <9207312147.AA19740@ptolemy.arc.nasa.gov> Received: by dennett.arc.nasa.gov (4.1/SMI-4.1) id AA02604; Fri, 31 Jul 92 14:48:15 PDT To: clim@bbn.com Subject: accept-values panes in CLIM 2.0 Is CLIM 2.0 going to support ACCEPT-VALUES panes? I can find only one reference to it in the spec (p. 289), and no reference to the function ACCEPT-VALUES-PANE-DISPLAYER or the command table ACCEPT-VALUES-PANE. Phil Chu Artificial Intelligence Research Branch NASA Ames Research Center pchu@ptolemy.arc.nasa.gov   Received: from BBN.COM by LABS-N.BBN.COM id aa24189; 3 Aug 92 11:06 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa13016; 3 Aug 92 11:00 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1118338; 3 Aug 1992 11:01:11-0400 Date: Mon, 3 Aug 1992 11:01-0400 From: Scott McKay Subject: accept-values panes in CLIM 2.0 To: pchu@ptolemy.arc.nasa.gov, clim@BBN.COM In-Reply-To: <9207312147.AA19740@ptolemy.arc.nasa.gov> Message-ID: <19920803150138.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 31 Jul 1992 17:47 EDT From: Philip Chu-Summer 92 Is CLIM 2.0 going to support ACCEPT-VALUES panes? Yes. I can find only one reference to it in the spec (p. 289), and no reference to the function ACCEPT-VALUES-PANE-DISPLAYER or the command table ACCEPT-VALUES-PANE.   Received: from BBN.COM by LABS-N.BBN.COM id aa23733; 3 Aug 92 10:36 EDT Received: from aplcen.apl.jhu.edu by BBN.COM id aa10241; 3 Aug 92 10:22 EDT Received: by aplcen.apl.jhu.edu (5.57/Ultrix2.4-XDccg) id AA10566; Mon, 3 Aug 92 10:21:30 -0400 Date: Mon, 3 Aug 92 10:21:30 -0400 From: lien@aplcen.apl.jhu.edu (Duong lien t) Message-Id: <9208031421.AA10566@aplcen.apl.jhu.edu> X-Mailer: Mail User's Shell (6.1 4/26/88) To: clim@bbn.com Subject: window coord. & print text Does anyone know how to do the following: 1. Create a CLIM window with coord (0,0) at the bottom left corner with Y going up instead of at the top left corner? 2. How to print text side ways? Thanks!   Received: from BBN.COM by LABS-N.BBN.COM id aa24700; 3 Aug 92 11:52 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa18644; 3 Aug 92 11:46 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1118380; 3 Aug 1992 11:47:22-0400 Date: Mon, 3 Aug 1992 11:47-0400 From: Scott McKay Subject: window coord. & print text To: lien@aplcen.apl.jhu.edu, clim@BBN.COM In-Reply-To: <9208031421.AA10566@aplcen.apl.jhu.edu> Message-ID: <19920803154749.7.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 3 Aug 1992 10:21 EDT From: Duong lien t Does anyone know how to do the following: 1. Create a CLIM window with coord (0,0) at the bottom left corner with Y going up instead of at the top left corner? CLIM windows by definition have the (0,0) at the upper left. You can invert the sense of the stream's coordinate system by using WITH-FIRST-QUADRANT-COORDINATES. 2. How to print text side ways? There is no good way to do this in CLIM 1.1 Thanks!   Received: from BBN.COM by LABS-N.BBN.COM id aa24935; 3 Aug 92 12:07 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa19455; 3 Aug 92 12:03 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA16168; Mon, 3 Aug 92 09:02:56 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA03111; Mon, 3 Aug 92 08:55:24 PDT Date: Mon, 3 Aug 92 08:55:24 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9208031555.AA03111@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: presentation-translator question I have defined my own presentation type in which I added my own accept and present methods (which are too long to include here, but work fine) that may utilize additional keyword options (below). (define-presentation-type time (&key (minimum nil) (maximum nil) (window nil) (io-type nil) (sync-to nil))) I have also defined a presentation translator (below) (define-presentation-translator blank-time (blank-area time my-applic :gesture :left :pointer-documentation "time") (x) (+ (Display-Frame-Start *my-app*) (truncate (- x *legend-border*) (pixel-per-time *my-app*)))) All of which works fine. Except if I do something like: (accept '(time :minimum 20 :maximum 100) :stream *interactor-stream*) and click somewhere on my display-frame, the translator will even accept those time points outside of my range. How does one handle user-added keyword options to their presentation types within the define-presentation-translator context? Is there a way I can grab them and utilize it within the :tester function for the translator? Any examples?   Received: from BBN.COM by LABS-N.BBN.COM id aa25020; 3 Aug 92 12:16 EDT Received: from chesapeake.ads.com by BBN.COM id aa19921; 3 Aug 92 12:13 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA24617; Mon, 3 Aug 92 12:15:42 EDT Date: Mon, 3 Aug 92 12:15:42 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9208031615.AA24617@chesapeake.ads.com> To: lien@aplcen.apl.jhu.edu Cc: clim@bbn.com In-Reply-To: Duong lien t's message of Mon, 3 Aug 92 10:21:30 -0400 <9208031421.AA10566@aplcen.apl.jhu.edu> Subject: Re: window coord. & print text Reply-To: jclose@ads.com From: Duong lien t ... 1. Create a CLIM window with coord (0,0) at the bottom left corner with Y going up instead of at the top left corner? 2. How to print text side ways? ... 1. No, but you can use the various "clim:with-.." macros to invert the coordinates. 2. Not that I know of. The clim:with-rotation macro and clim:make-rotation-transformation function are no-ops when used with draw-text*. Jeff   Received: from BBN.COM by LABS-N.BBN.COM id aa02976; 4 Aug 92 3:06 EDT Received: from gmdzi.gmd.de by BBN.COM id aa13420; 4 Aug 92 2:53 EDT Received: from localhost by gmdzi.gmd.de with SMTP id AA04959 (5.65c/IDA-1.4.4 for clim@BBN.COM); Tue, 4 Aug 1992 08:52:13 +0200 Message-Id: <199208040652.AA04959@gmdzi.gmd.de> To: lien@aplcen.apl.jhu.edu Cc: clim@BBN.COM Subject: Re: window coord. & print text Date: Tue, 04 Aug 92 08:52:12 +0200 From: Ralph.Hensel@gmd.de X-Mts: smtp Does anyone know how to do the following: 1. Create a CLIM window with coord (0,0) at the bottom left corner with Y going up instead of at the top left corner? 2. How to print text side ways? 1. See documentation p.110-112 and with-room-for-graphics macro. 2. On Sun Allegro 4.01 under CLIM 1.0 there are two undocumented functions draw-string* and draw-vertical-string*. I don't know if they are available on other implemetations of CLIM, but although a little bit strange they worked fine on SUN. Ralph Hensel German National Research Center for Computer Science (GMD-FIT.KI) P.O. Box 1316, D-5205 Sankt Augustin, Germany mail:hensel@gmdzi.gmd.de fax:+49-2241-14-2889 phone:+49-2241-14-1   Received: from BBN.COM by LABS-N.BBN.COM id aa03065; 4 Aug 92 3:49 EDT Received: from mcsun.EU.net by BBN.COM id aa15125; 4 Aug 92 3:44 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA16402 (5.65b/CWI-2.173); Tue, 4 Aug 1992 09:15:14 +0200 Received: from nrb.UUCP by ub4b.buug.be (5.65c/ub4b_02) id AA06512; Tue, 4 Aug 1992 09:15:10 +0200 Received: from nrbmi1.ia.nrb.be by scosysv.nrb.be with SMTP (5.59/NRB25-f-eef-ev@nrb) id AA00427; Tue, 4 Aug 92 14:54:31 +0100 Date: Mon, 3 Aug 1992 17:26+0200 From: Vincent Keunen Reply-To: nrb!keunen@relay.EU.net Subject: clim library suggestions To: clim@nrbmi2.ia.nrb.be, clim-request@bbn.com In-Reply-To: <9207250102.AA16222@ptolemy.arc.nasa.gov> Message-Id: <19920803152608.6.KEUNEN@nrbmi1.ia.nrb.be> Philip Chu says: Date: Sat, 25 Jul 1992 03:02+0200 From: Philip Chu-Summer 92 I've noticed there isn't anything in the CLIM library, yet. I may have some stuff at the end of the summer, but in the meantime I have a couple of suggestions for entries: 1) The example code supplied by the CLIM vendors--I seem to remember th ILA/MCL version including a number of instructive demos. (The only one I can remember is an address book). I suppose the vendors would have to be contacted and agree to that. 2) A mail archive for the clim@bbn mail list. I don't know how you'd go about setting one up, but I've often wished for one when plowing through my Symbolics CLIM manual. Do the people at bbn maintaining the clim list keep an archive? If not, would it be a lot of work? By the way, thanks for volunteering to maintain the library. I certainly wouldn't have done it. Phil Chu Artificial Intelligence Research Branch NASA Ames Research Center pchu@ptolemy.arc.nasa.gov Sorry to ask that on the list, but I don't know who to contact. Vincent =============================================================== Keunen Vincent Network Research Belgium R&D, Software Engineer Parc Industriel des Hauts-Sarts keunen@nrb.be 2e Avenue, 65 tel: +32 41 407282 B-4040 Herstal fax: +32 41 481170 BELGIUM ===============================================================   Received: from BBN.COM by LABS-N.BBN.COM id aa06528; 4 Aug 92 9:36 EDT Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa11186; 4 Aug 92 9:32 EDT Received: from LILIKOI.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 877044; 4 Aug 1992 09:33:47-0400 Date: Tue, 4 Aug 1992 09:46-0400 From: Mark Nahabedian Subject: Re: window coord. & print text To: Ralph.Hensel@gmd.de, lien@aplcen.apl.jhu.edu cc: clim@BBN.COM In-Reply-To: <199208040652.AA04959@gmdzi.gmd.de> Message-ID: <19920804134649.8.NAHA@LILIKOI.SCRC.Symbolics.COM> Date: Tue, 4 Aug 1992 02:52 EDT From: Ralph.Hensel@gmd.de Does anyone know how to do the following: 1. Create a CLIM window with coord (0,0) at the bottom left corner with Y going up instead of at the top left corner? 2. How to print text side ways? 1. See documentation p.110-112 and with-room-for-graphics macro. 2. On Sun Allegro 4.01 under CLIM 1.0 there are two undocumented functions draw-string* and draw-vertical-string*. I don't know if they are available on other implemetations of CLIM, but although a little bit strange they worked fine on SUN. CLIM currently provides no general way to draw text at odd angles. The only affect a transformation has on the draw-string operation is to transform the location of the starting point. Some host window systems don't provides a way of doing this short of performing the transformation on pixel arrays and then rendering them. draw-vertical-string* is a hack rpovided for the simple purpose of labeling the Y axis of a graph. I u m t s u e c i f h s u l e n l o f s t o e r .   Received: from BBN.COM by LABS-N.BBN.COM id aa10783; 4 Aug 92 15:07 EDT Received: from techunix.technion.ac.il by BBN.COM id aa26719; 4 Aug 92 14:57 EDT Return-Path: Received: from ALTDORF.AI.MIT.EDU by techunix.technion.ac.il (sendmail 5.65+/920105) id AA17352; Tue, 4 Aug 92 16:39:59 +0300 Received: from life.ai.mit.edu by martigny.ai.mit.edu with SMTP (16.7/15.6) id AA16513; Tue, 4 Aug 92 09:42:42 -0400 Received: from LABS-N.BBN.COM by life.ai.mit.edu (4.1/AI-4.10) id AA06964; Tue, 4 Aug 92 09:39:00 EDT Received: from BBN.COM by LABS-N.BBN.COM id aa06528; 4 Aug 92 9:36 EDT Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa11186; 4 Aug 92 9:32 EDT Received: from LILIKOI.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 877044; 4 Aug 1992 09:33:47-0400 Date: Tue, 4 Aug 1992 09:46-0400 From: Mark Nahabedian Subject: Re: window coord. & print text To: Ralph.Hensel@gmd.de, lien@aplcen.apl.jhu.edu Cc: clim@bbn.com In-Reply-To: <199208040652.AA04959@gmdzi.gmd.de> Message-Id: <19920804134649.8.NAHA@LILIKOI.SCRC.Symbolics.COM> Status: R Date: Tue, 4 Aug 1992 02:52 EDT From: Ralph.Hensel@gmd.de Does anyone know how to do the following: 1. Create a CLIM window with coord (0,0) at the bottom left corner with Y going up instead of at the top left corner? 2. How to print text side ways? 1. See documentation p.110-112 and with-room-for-graphics macro. 2. On Sun Allegro 4.01 under CLIM 1.0 there are two undocumented functions draw-string* and draw-vertical-string*. I don't know if they are available on other implemetations of CLIM, but although a little bit strange they worked fine on SUN. CLIM currently provides no general way to draw text at odd angles. The only affect a transformation has on the draw-string operation is to transform the location of the starting point. Some host window systems don't provides a way of doing this short of performing the transformation on pixel arrays and then rendering them. draw-vertical-string* is a hack rpovided for the simple purpose of labeling the Y axis of a graph. I u m t s u e c i f h s u l e n l o f s t o e r . From clay@A.GP.CS.CMU.EDU Tue Aug 4 17:47:38 1992 Received: from A.GP.CS.CMU.EDU by techunix.technion.ac.il (sendmail 5.65+/920105) id AA18965; Tue, 4 Aug 92 17:47:25 +0300 Message-Id: <9208041447.AA18965@techunix.technion.ac.il> Received: by A.GP.CS.CMU.EDU id aa01122; 4 Aug 92 9:46:45 EDT To: Excel Developers List Date: Tue, 4 Aug 92 08:59 EDT From: F0O@PSUVM.PSU.EDU Mmdf-Warning: Parse error in original version of preceding line at A.GP.CS.CMU.EDU Subject: Some help needed on DDE Reply-To: clay=xldev@cs.cmu.edu Errors-To: clay=xldev-request@cs.cmu.edu Sender: clay@A.GP.CS.CMU.EDU Status: R I'm writing macros in Excel 3.0 and Word to create an app I need. I'm using DDE to have Excel and Word talk to each other, and this works fine, except I'd like to know if it's possible to pass parameters to a Word or Excel macro when I call it using the Execute function. I couldn't find a way to do it, so I tried passing a literal value to a Word bookmark using SetBookmark(), which worked. The problem came when I wanted the value of an Excel macro variable to be put into the Word bookmark. I was then given a type mismatch error in Word. I've asked this question a number of times, and have never received an answer. Am I asking too much of DDE? [Tim] From slug-admin%iu.ai.sri.com%martigny.ai.mit.edu,@iu.ai.sri.com Tue Aug 4 20:07:24 1992 Received: from ALTDORF.AI.MIT.EDU by techunix.technion.ac.il (sendmail 5.65+/920105) id AA21639; Tue, 4 Aug 92 20:06:42 +0300 Received: from life.ai.mit.edu by martigny.ai.mit.edu with SMTP (16.7/15.6) id AA23179; Tue, 4 Aug 92 13:09:11 -0400 Received: from IU.AI.SRI.COM by life.ai.mit.edu (4.1/AI-4.10) id AA14793; Tue, 4 Aug 92 13:05:30 EDT Received: from Sunset.AI.SRI.COM by IU.AI.SRI.COM via SMTP with TCP; Tue, 4 Aug 92 09:05:44-PST Received: from RIVERSIDE.SCRC.Symbolics.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA02189 for slug-board@iu.ai.sri.com; Tue, 4 Aug 92 09:01:30 PDT Received: from ATHENA.PANGARO.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 877161; 4 Aug 1992 12:00:47-0400 Date: Tue, 4 Aug 1992 11:50-0400 From: Paul Pangaro Subject: The End of an Era To: h2@athena.pangaro.dialnet.symbolics.com, dan-chris@athena.pangaro.dialnet.symbolics.com, ron-k@athena.pangaro.dialnet.symbolics.com, bruce-mc@athena.pangaro.dialnet.symbolics.com, gander@athena.pangaro.dialnet.symbolics.com, radel@athena.pangaro.dialnet.symbolics.com, jix@athena.pangaro.dialnet.symbolics.com, cariani@athena.pangaro.dialnet.symbolics.com, p2@athena.pangaro.dialnet.symbolics.com, edith@athena.pangaro.dialnet.symbolics.com, naimark@athena.pangaro.dialnet.symbolics.com, slug%ai.sri.com@riverside.scrc.symbolics.com, 100010.426%CompuServe.COM@riverside.scrc.symbolics.com, AKELLER%UVVM.UVic.CA%cunyvm.cuny.edu@riverside.scrc.symbolics.com, VELICK%ACFcluster.NYU.EDU@riverside.scrc.symbolics.com, adrian%cipr-server.MGH.Harvard.Edu@riverside.scrc.symbolics.com, slug-board%ai.sri.com@riverside.scrc.symbolics.com, 20677MAI%MSU.BITNET%CUNYVM.CUNY.EDU@athena.pangaro.dialnet.symbolics.com, 9102211813.AA18531%news18.sfc@riverside.scrc.symbolics.com, mike%ooc.uva.nl@riverside.scrc.symbolics.com Cc: slug-request@ai.sri.com Supersedes: <19920804155023.4.PAN@ATHENA.PANGARO.dialnet.symbolics.com> Message-Id: <19920804155032.5.PAN@ATHENA.PANGARO.dialnet.symbolics.com> Status: R Dear Friends: This machine, the mighty Symbolics 3600 with Instruction Fetch Unit and the lowest serial number still in use, will shortly be taken offline (sometime between now and 16 August). It will not be going to scrap, thank heaven, but to a devoted user. For that I am most grateful. Unfortunately it will mean an interruption in my capacity for sending and recieving e-mail via Internet (or any other means, for that matter). I hope someday to be up again on the net, once I am settled in Cambridge, MA, sometime after September 92. Meantime I am best reached via 617-621-3070 --- the address below will become active in the next week or so, but I will pickup physical mail there only after 4 September. Good luck and happy mailing to you all. You have not heard the last of me. Dr Paul Pangaro, President PANGARO Incorporated P O Box 390420 Cambridge, MA 02139 Voice: 617-621-3070 From clay@A.GP.CS.CMU.EDU Tue Aug 4 21:05:39 1992 Received: from A.GP.CS.CMU.EDU by techunix.technion.ac.il (sendmail 5.65+/920105) id AA22577; Tue, 4 Aug 92 21:05:03 +0300 Message-Id: <9208041805.AA22577@techunix.technion.ac.il> To: Excel Developers List Date: Tue, 04 Aug 92 19:15:53 MEZ From: Erich Neuwirth Subject: tool bitmap and xlmath question Reply-To: clay=xldev@cs.cmu.edu Errors-To: clay=xldev-request@cs.cmu.edu Sender: clay@A.GP.CS.CMU.EDU Status: R hi vereybody, i am new to the list, and i have 2 questions. i just developed a small net of new tools for myself, and i also created new tool faces. i used windows paint for it. now this is painful. for copying the bitmap to the clipboard one has tr to view the bitmap in normal size, which is tiny. and getting the frame to cut out right one has to be correct to one pixel, which is extremely tedious. is there any free painting program which can cut and paste while in zoomed in mode? that would solve the problem. 2nd question. there is this shareware or freeware package xlmath10 floating around on the internet. it is an addin dll adding a few new funtions kike eigenvalues of matrices and so on. it also difens a frequency function, which has not been available in versions of excel prior to 4.0. it seems to be developed for excel 3.0 does anybody know of a version which has been updated for 4.0 (leaving out frequence, for example). by the way, what is the easiest way of getting microsofts excel developers pack with the c header files and libraries allowing you to write your own dalls for excel? and is there an academic version or discount for this developers pack? ERICH NEUWIRTH BITNET (EARN): A4422DAB@AWIUNI11 INTERNET: a4422DAB@vm.univie.ac.at = 131.130.1.2 Institute for Statistics and Computer Science UNIVERSITY OF VIENNA, UNIVERSITAETSSTR. 5/9, A-1010 VIENNA, AUSTRIA TEL.: +43-1-40407-160 FAX: +43-1-40407-88 From SNEWMAN@auvm.american.edu Tue Aug 4 21:38:21 1992 Received: from auvm.american.edu by techunix.technion.ac.il (sendmail 5.65+/920105) id AA23067; Tue, 4 Aug 92 21:38:15 +0300 Message-Id: <9208041838.AA23067@techunix.technion.ac.il> Received: from AUVM.AMERICAN.EDU by AUVM.AMERICAN.EDU (IBM VM SMTP V2R2) with BSMTP id 2044; Tue, 04 Aug 92 14:38:03 EDT Received: from auvm.american.edu (SNEWMAN) by AUVM.AMERICAN.EDU (Mailer R2.08) with BSMTP id 4474; Tue, 04 Aug 92 14:38:02 EDT Date: Tue, 04 Aug 92 14:37:18 EDT From: Saul Newman Organization: The American University Subject: Re: Apartments To: David Goldfarb In-Reply-To: Your message of Mon 03-Aug-92 22:31:30 IST Status: R Thanks for your help. I will talk to Naomi and get back to you. Things are hectic at the moment. Saul   Received: from BBN.COM by LABS-N.BBN.COM id aa26992; 5 Aug 92 20:05 EDT Received: from ptolemy-arclan.arc.nasa.gov by BBN.COM id aa28410; 5 Aug 92 20:00 EDT Received: from dennett.arc.nasa.gov by ptolemy.arc.nasa.gov (4.1/) id ; Wed, 5 Aug 92 17:00:16 PDT Date: Wed, 5 Aug 92 17:00:16 PDT From: Philip Chu-Summer 92 Message-Id: <9208060000.AA16109@ptolemy.arc.nasa.gov> Received: by dennett.arc.nasa.gov (4.1/SMI-4.1) id AA00859; Wed, 5 Aug 92 17:01:15 PDT To: clim@bbn.com Subject: clim 2.0 color dialog code This is my first cut at CLIM 2.0 code (and, as yet, still one of my early uses of any version of CLIM). It consists of color dialogs that have sliders to change the color components. The calling form is (CHOOSE-COLOR mode) where mode is one of :RGB or :GRAY. (I had started to add :IHS as option, but I found that COLOR-IHS couldn't extract components from non-ihs colors, a bug I've reported to Franz). I've only run this with Franz ACL and Motif, so I don't have any idea how it looks on other setups. I'd appreciate anyone giving the code a look-over and some feedback. In particular, is DEFINE-APPLICATION-FRAME an appropriate way to define dialogs that are used as part of a larger application? Am I defining the callbacks in an appropriate manner? etc. Thanks in advance. -Phil Chu ;;; basic stuff (defvar *scale* 255) (defclass color-chooser (standard-application-frame) ((color :accessor color :initform +black+))) (defmethod display ((frame color-chooser) stream) "Color display function." (setf (medium-background stream) (color frame)) (window-clear (get-frame-pane frame 'display))) (defmethod value-changed-callback :after ((slider slider) (client (eql 'color)) id value) "Make sure new color is displayed." (redisplay-frame-pane *application-frame* 'display)) (defmethod activate-callback ((gadget push-button) (client (eql 'color)) (id (eql 'ok))) "Callback for OK button." (frame-exit *application-frame*)) ;;; this is the function to run (defun choose-color (&optional (mode :rgb) &key (scale *scale*)) "Pops up a dialog and returns the chosen color." (let ((dialog (color-dialog mode))) (run-frame-top-level dialog) (color dialog))) ;;; gray scale (defmethod color-dialog ((mode (eql :gray))) (make-application-frame 'gray-chooser :pretty-name "Gray Scale")) (define-application-frame gray-chooser (color-chooser) () (:panes (display :application :scroll-bars nil :display-function 'display) (ok push-button :client 'color :id 'ok) (gray slider :show-value-p t :foreground +blue+ :client 'color :id 'gray :orientation :vertical :min-value 0 :max-value *scale*)) (:layouts (default (horizontally () (vertically () display ok) gray)))) (defmethod value-changed-callback ((slider slider) (client (eql 'color)) (id (eql 'gray)) value) "" (setf (color *application-frame*) (make-gray-color (/ value *scale*)))) ;;; rgb colors (defmethod color-dialog ((mode (eql :rgb))) (make-application-frame 'rgb-chooser :pretty-name "RGB Color")) (define-application-frame rgb-chooser (color-chooser) () (:panes (display :application :scroll-bars nil :display-function 'display) (ok push-button :client 'color :id 'ok) (red slider :min-value 0 :max-value *scale* :orientation :vertical :id 'red :client 'color :foreground +red+ :show-value-p t) (green slider :show-value-p t :foreground +green+ :client 'color :id 'green :orientation :vertical :min-value 0 :max-value *scale*) (blue slider :show-value-p t :foreground +blue+ :client 'color :id 'blue :orientation :vertical :min-value 0 :max-value *scale*)) (:layouts (default (horizontally () (vertically () display ok) red green blue)))) (defmethod value-changed-callback ((slider slider) (client (eql 'color)) (id (eql 'red)) value) "" (multiple-value-bind (red green blue) (color-rgb (color *application-frame*)) (setf (color *application-frame*) (make-rgb-color (/ value *scale*) green blue)))) (defmethod value-changed-callback ((slider slider) (client (eql 'color)) (id (eql 'green)) value) "" (multiple-value-bind (red green blue) (color-rgb (color *application-frame*)) (setf (color *application-frame*) (make-rgb-color red (/ value *scale*) blue)))) (defmethod value-changed-callback ((slider slider) (client (eql 'color)) (id (eql 'blue)) value) "" (multiple-value-bind (red green blue) (color-rgb (color *application-frame*)) (setf (color *application-frame*) (make-rgb-color red green (/ value *scale*)))))   Received: from BBN.COM by LABS-N.BBN.COM id aa04407; 6 Aug 92 10:14 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa15211; 6 Aug 92 10:01 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA26506; Thu, 6 Aug 92 07:01:25 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA00545; Thu, 6 Aug 92 06:53:51 PDT Date: Thu, 6 Aug 92 06:53:51 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9208061353.AA00545@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: Plot in landscape format - can it be done in CLIM? Any examples out there utilizing with-output-to-postscript-stream that plots out a graph in landscape format? Something like below: ------------------------------------------------- | TITLE | | | | | | 30 -| x | | 20 -| x x | | 10 -| | | 0 -| x | | ------------------------------------- | | 0 5 10 15 20 | | | |------------------------------------------------   Received: from BBN.COM by LABS-N.BBN.COM id aa07099; 6 Aug 92 14:07 EDT Received: from chesapeake.ads.com by BBN.COM id aa27616; 6 Aug 92 14:04 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA06642; Thu, 6 Aug 92 14:06:22 EDT Date: Thu, 6 Aug 92 14:06:22 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9208061806.AA06642@chesapeake.ads.com> To: clim@bbn.com Subject: Style and Design question about presentations Reply-To: jclose@ads.com Greetings, I'm designing an interface for a system that will run parallel to another existing system. My system uses classes defined in the other system, but not vice-versa. The intent is to be able to load either in any order and run them separately without them interfering with one another. In System-X I'd like to present objects from System-Y differently than they are presented within that system. Obviously, I don't want to redefine presentation methods on the original System-Y presentations so that they would then be presented differently back in System-Y. Further, if presentation translators are defined on those presentations, then I don't want to give the original System-Y presentations new behavior. What's the best way to do this? The essence of this question really begs a pretty basic question about presentations and the best way to present the same object differently.   Received: from BBN.COM by LABS-N.BBN.COM id aa06874; 6 Aug 92 13:50 EDT Received: from [129.197.134.99] by BBN.COM id aa26817; 6 Aug 92 13:46 EDT Received: from jade.rdd.lmsc.lockheed.com by dipl.rdd.lmsc.lockheed.com (4.0/SMI-4.1) id AA00674; Thu, 6 Aug 92 10:51:15 PDT Received: from dipl.rdd.lmsc.lockheed.com by jade.rdd.lmsc.lockheed.com (4.1/SMI-4.0) id AA26043; Thu, 6 Aug 92 10:46:18 PDT Date: Thu, 6 Aug 92 10:46:18 PDT From: ttrinko@dipl.rdd.lmsc.lockheed.com (Tom Trinko) Message-Id: <9208061746.AA26043@jade.rdd.lmsc.lockheed.com> To: clim@bbn.com Subject: arrows our application uses arrows extensively in its interface. symbolics clim 1.1 supports the draw-arrow command. unfortunetly franz clim 1.1,which we use on the sun, doesn't. Does anyone have an arrow drawing routine we can use until clim 2.0 comes out? thanks for any help.   Received: from BBN.COM by LABS-N.BBN.COM id aa08319; 6 Aug 92 15:54 EDT Received: from brazil.cambridge.apple.com by BBN.COM id aa05004; 6 Aug 92 15:50 EDT Received: from ministry.cambridge.apple.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef) id AA02406; Thu, 6 Aug 92 15:50:39 -0400 for clim@BBN.COM Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef) id AA12250; Thu, 6 Aug 92 15:50:44 -0400 Message-Id: <9208061950.AA12250@cambridge.apple.com> Date: Thu, 06 Aug 92 15:54:48 EDT From: moon@cambridge.apple.com (David A. Moon) To: jclose@ads.com Subject: Re: Style and Design question about presentations Cc: clim@BBN.COM > Date: Thu, 6 Aug 92 14:06:22 EDT > From: Jeff Close > > I'm designing an interface for a system that will run parallel to > another existing system. My system uses classes defined in the other > system, but not vice-versa. The intent is to be able to load either > in any order and run them separately without them interfering with > one another. In System-X I'd like to present objects from System-Y > differently than they are presented within that system. > > Obviously, I don't want to redefine presentation methods on the > original System-Y presentations so that they would then be presented > differently back in System-Y. Further, if presentation translators > are defined on those presentations, then I don't want to give the > original System-Y presentations new behavior. What's the best way to > do this? The essence of this question really begs a pretty basic > question about presentations and the best way to present the same > object differently. Well, you have to decide what it means to be "in system-X" or "in system-Y" and how you're going to communicate that context to the presentation methods. Perhaps you can use the :view argument to PRESENT as part of your solution. That's only a guess though, I don't know its current status.   Received: from BBN.COM by LABS-N.BBN.COM id aa08649; 6 Aug 92 16:12 EDT Received: from [192.44.1.1] by BBN.COM id aa05991; 6 Aug 92 16:08 EDT Received: by fhg.de (fhg1.fhg.de) with PRESMTP; Thu, 6 Aug 92 22:08:19 +0200 from FHG-GATEWAY Received: by fhg.de (fhg1.fhg.de) with UUCP; Thu, 6 Aug 92 22:08:16 +0200 from imldo Received: by iml.fhg.de with SMTP; Thu, 6 Aug 92 21:57:26 +0200 Date: Thu, 6 Aug 1992 20:55+0100 From: Stefan Bernemann Subject: updating-output and format-graph-from-root To: clim@bbn.com Message-Id: <19920806195543.1.STEFAN@ANNA.iml.fhg.de> I'm using CLIM 1.1 under Genera 8.1 and CLIM 1.0 beta under MCL 2.0bp3. I want to display a hierarchy of objects in form of a tree, where the user can collapse nodes with children or expand collapsed nodes. It would be nice if updating-output could be used. However, my first naive test program showed, that in principle the nodes are "re-layeouted" correctly during redisplay as can be seen from the bounding rectangles when the nodes are highlighted. However, the display gets messed up by either erasing too much or too less of the output. A complete redisplay (Function-Refresh on the Symbolics) builds up the display correctly. Is there an easy solution for this problem using updating-output? I've appended short example code after this message. Thanks - Stefan B. Mail: Stefan Bernemann ! Phone: +49-231-9743-139 c/o FhG IML Dortmund ! Fax: +49-231-9743-234 Emil-Figge-Str. 75 ! Email: berni@iml.fhg.de D-4600 Dortmund 50, FRG ! ;;; -*- Package: CLIM-USER; Syntax: Common-Lisp; Mode: LISP; Base: 10 -*- (in-package :clim-user) ;;; Some Tree stuff (defclass tree-node () ((node-value :accessor tree-node-value :initarg :node-value) (node-children :accessor tree-node-children :initarg :node-children :initform nil) (expanded :accessor tree-node-expanded :initarg :expanded :initform t) (tick-mark :accessor tree-node-tick-mark :initform 0) (node-parent :accessor tree-node-parent :initarg :node-parent :initform nil))) (defun make-tree-from-list (tree-in-list-form &optional (parent nil)) (if (atom tree-in-list-form) (make-instance 'tree-node :node-value tree-in-list-form :node-parent parent) (let ((tree (make-instance 'tree-node :node-value (car tree-in-list-form) :node-parent parent))) (setf (tree-node-children tree) (mapcar #'(lambda (child) (make-tree-from-list child tree)) (cdr tree-in-list-form))) tree))) ;;; The Application Frame (define-application-frame tree1 () ((tree :initform (make-tree-from-list '(root (node1 (node1-1 leaf1-1-1 leaf1-1-2) (node1-2 leaf1-2-1 leaf1-2-2)) (node2 (node2-1 leaf2-1-1 leaf2-1-2) (node2-2 leaf2-2-1 leaf2-2-2)) (node3 (node3-1 leaf3-1-1 leaf3-1-2) (node3-1 leaf3-2-1 leaf3-2-2)))) :accessor tree1-tree)) (:panes ((title :title) (menu :command-menu) (display-tree :application :default-text-style '(:fix :bold :normal) :incremental-redisplay T :scroll-bars :both :display-function 'draw-tree-as-tree) (doc :pointer-documentation)))) (define-tree1-command (com-exit-tree :menu "Exit") () (frame-exit *application-frame*)) (define-presentation-type tree () ) ;;; *** THE DISPLAY FUNCTION *** (defmethod draw-tree-as-tree ((frame tree1) stream) (let ((tree (tree1-tree frame)) (node-printer #'(lambda (node stream) (let ((text-face (cond ((null (tree-node-children node)) :italic) ((tree-node-expanded node) :roman) (t :bold)))) (updating-output (stream :unique-id node :cache-value (tree-node-tick-mark node) :cache-test #'=) (with-output-as-presentation (:stream stream :object node :type 'tree) (with-drawing-options (stream :text-face text-face) (format stream "~A" (tree-node-value node))) )))))) (format-graph-from-root tree node-printer #'(lambda (node) (and (tree-node-expanded node) (tree-node-children node))) :stream stream :orientation ':horizontal))) (define-tree1-command com-toggle-expand ((tree 'tree)) (setf (tree-node-expanded tree) (not (tree-node-expanded tree))) ;; Mark all parent nodes as invalid (loop for node = tree then (tree-node-parent node) while node do (incf (tree-node-tick-mark node)))) (define-presentation-to-command-translator toggle-expand-status (tree com-toggle-expand tree1 :pointer-documentation ((object stream) (format stream "~A ~A" (if (tree-node-expanded object) "Collapse" "Expand") (tree-node-value object))) :tester ((object) (tree-node-children object))) (object) (list object)) #|| t (defvar *clim-root* (open-root-window #+:mcl :mcl #+:genera :sheet) (defvar *my-window*) (setf *my-window* (make-application-frame 'tree1 :parent *clim-root*)) (run-frame-top-level *my-window*) ||#   Received: from BBN.COM by LABS-N.BBN.COM id aa07775; 6 Aug 92 14:56 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa29753; 6 Aug 92 14:50 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1120554; 6 Aug 1992 14:51:12-0400 Date: Thu, 6 Aug 1992 14:51-0400 From: Scott McKay Subject: arrows To: ttrinko@dipl.rdd.lmsc.lockheed.com, clim@BBN.COM In-Reply-To: <9208061746.AA26043@jade.rdd.lmsc.lockheed.com> Message-ID: <19920806185159.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 6 Aug 1992 13:46 EDT From: Tom Trinko our application uses arrows extensively in its interface. symbolics clim 1.1 supports the draw-arrow command. unfortunetly franz clim 1.1,which we use on the sun, doesn't. Does anyone have an arrow drawing routine we can use until clim 2.0 comes out? thanks for any help. (in-package :clim) (define-graphics-operation draw-arrow (x1 y1 x2 y2 &key (from-head nil) (to-head t) (head-length 10) (head-width 5)) :arguments ((point x1 y1 x2 y2)) :drawing-options :line-cap :method-body (with-transformed-arguments (let* ((dx (- x2 x1)) (dy (- y2 y1)) (norm (if (zerop dx) (if (zerop dy) nil (/ 1.0 (abs dy))) (if (zerop dy) (/ 1.0 (abs dx)) (/ (sqrt (+ (* dx dx) (* dy dy)))))))) (when norm (let* ((length-norm (* head-length norm)) (ldx (* dx length-norm)) (ldy (* dy length-norm)) (base-norm (* head-width norm 0.5)) (bdx (* dy base-norm)) (bdy (* dx base-norm)) (ink (medium-ink stream)) (line-style (medium-line-style stream))) (draw-line-internal stream 0 0 x1 y1 x2 y2 ink line-style) (when from-head (let ((xa (+ x1 ldx)) (ya (+ y1 ldy))) (with-stack-list (points x1 y1 (+ xa bdx) (- ya bdy) (- xa bdx) (+ ya bdy)) (draw-polygon-internal stream 0 0 points t ink nil)) (setq x1 xa y1 ya))) (when to-head (let ((xa (- x2 ldx)) (ya (- y2 ldy))) (with-stack-list (points x2 y2 (+ xa bdx) (- ya bdy) (- xa bdx) (+ ya bdy)) (draw-polygon-internal stream 0 0 points t ink nil) (setq x2 xa y2 ya)))))))))   Received: from BBN.COM by LABS-N.BBN.COM id aa13845; 7 Aug 92 3:31 EDT Received: from gmdzi.gmd.de by BBN.COM id aa17811; 7 Aug 92 3:27 EDT Received: from localhost by gmdzi.gmd.de with SMTP id AA06384 (5.65c/IDA-1.4.4 for clim@BBN.COM); Fri, 7 Aug 1992 09:26:05 +0200 Message-Id: <199208070726.AA06384@gmdzi.gmd.de> To: SWM@stony-brook.scrc.symbolics.com Cc: clim@BBN.COM Subject: arrows & your answer Date: Fri, 07 Aug 92 09:26:03 +0200 From: Ralph.Hensel@gmd.de X-Mts: smtp Hi, I`m working on Sun with Framz Allegro 4.01 and CLIM 1.0 You wrote that the following will work on SUN as draw-arrow: (in-package :clim) (define-graphics-operation draw-arrow (x1 y1 x2 y2 &key (from-head nil) (to-head t) (head-length 10) (head-width 5)) :arguments ((point x1 y1 x2 y2)) :drawing-options :line-cap :method-body (with-transformed-arguments (let* ((dx (- x2 x1)) (dy (- y2 y1)) (norm (if (zerop dx) (if (zerop dy) nil (/ 1.0 (abs dy))) (if (zerop dy) (/ 1.0 (abs dx)) (/ (sqrt (+ (* dx dx) (* dy dy)))))))) (when norm (let* ((length-norm (* head-length norm)) (ldx (* dx length-norm)) (ldy (* dy length-norm)) (base-norm (* head-width norm 0.5)) (bdx (* dy base-norm)) (bdy (* dx base-norm)) (ink (medium-ink stream)) (line-style (medium-line-style stream))) (draw-line-internal stream 0 0 x1 y1 x2 y2 ink line-style) (when from-head (let ((xa (+ x1 ldx)) (ya (+ y1 ldy))) (with-stack-list (points x1 y1 (+ xa bdx) (- ya bdy) (- xa bdx) (+ ya bdy)) (draw-polygon-internal stream 0 0 points t ink nil)) (setq x1 xa y1 ya))) (when to-head (let ((xa (- x2 ldx)) (ya (- y2 ldy))) (with-stack-list (points x2 y2 (+ xa bdx) (- ya bdy) (- xa bdx) (+ ya bdy)) (draw-polygon-internal stream 0 0 points t ink nil) (setq x2 xa y2 ya))))))))) But what is (with-transformed-arguments ...). It seems that it doesn't work under CLIM 1.0 Ralph Hensel German National Research Center for Computer Science (GMD-FIT.KI) P.O. Box 1316, D-5205 Sankt Augustin, Germany mail:hensel@gmdzi.gmd.de fax:+49-2241-14-2889 phone:+49-2241-14-1   Received: from BBN.COM by LABS-N.BBN.COM id aa16098; 7 Aug 92 7:32 EDT Received: from [192.44.1.1] by BBN.COM id aa22596; 7 Aug 92 7:28 EDT Received: by fhg.de (fhg1.fhg.de) with PRESMTP; Fri, 7 Aug 92 13:27:58 +0200 from FHG-GATEWAY Received: by fhg.de (fhg1.fhg.de) with UUCP; Fri, 7 Aug 92 13:27:55 +0200 from imldo Received: by iml.fhg.de with SMTP; Fri, 7 Aug 92 13:22:24 +0200 Date: Fri, 7 Aug 1992 12:20+0100 From: Stefan Bernemann Subject: updating-output and recursive use of formatting-graph-from-root To: clim@bbn.com Message-Id: <19920807112039.1.STEFAN@ANNA.iml.fhg.de> I'm using CLIM 1.1 with Genera 8.1 This is a next try in my efforts of drawing a tree, where the user can collapse or expand individual nodes in the display. (CF my last message!) To implement this, I want to use updating-output. Each subtree of the tree (and the tree as a whole) is presented as an output-record with updating-output. Therefore, I call format-graph-from-root recursively to get one output-record for each subtree. This version works in first displaying the fully expanded tree. The user can collapse individual nodes and the display is updated correctly (in contrast to my version posted in the last message!). HOWEVER, if on node is expanded, the program runs into an infinite loop (in the function layout-graph called by format-graph-from-root called with the expanded node as the root-node-argument by the redisplay mechanism). Is what I'm doing wrong in principle, is there a bug in my code or a bug in CLIM? Lost in helplessness - Stefan B. ;;;What follows is the display method for the tree-pane: (defmethod draw-tree-as-tree ((frame tree1) stream) (let ((tree (tree1-tree frame))) (labels ((draw-subtree (subtree stream) (let* ((inferior-producer #'(lambda (node) ;; just return the direct inferiors (and (eql node subtree) (tree-node-expanded node) (tree-node-children node))))) (updating-output (stream :unique-id subtree :cache-value (tree-node-tick-mark subtree) :cache-test #'=) (with-output-as-presentation (:stream stream :object subtree :type 'tree) (cond ((and (tree-node-children subtree) (tree-node-expanded subtree)) ; we have to draw a tree (format-graph-from-root subtree #'(lambda (node stream) (if (eql node subtree) (format stream "~A" ; draw root node (tree-node-value node)) (draw-subtree node stream))) ; draw sons as trees inferior-producer :stream stream)) (t ; we have to draw a leaf (format stream "~A" (tree-node-value subtree))))))))) (draw-subtree tree stream)))) Mail: Stefan Bernemann ! Phone: +49-231-9743-139 c/o FhG IML Dortmund ! Fax: +49-231-9743-234 Emil-Figge-Str. 75 ! Email: berni@iml.fhg.de D-4600 Dortmund 50, FRG !   Received: from BBN.COM by LABS-N.BBN.COM id aa17877; 7 Aug 92 10:22 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa00338; 7 Aug 92 10:15 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1121132; 7 Aug 1992 10:15:59-0400 Date: Fri, 7 Aug 1992 10:16-0400 From: Scott McKay Subject: Style and Design question about presentations To: jclose@ads.com, clim@BBN.COM In-Reply-To: <9208061806.AA06642@chesapeake.ads.com> Message-ID: <19920807141653.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 6 Aug 1992 14:06 EDT From: Jeff Close I'm designing an interface for a system that will run parallel to another existing system. My system uses classes defined in the other system, but not vice-versa. The intent is to be able to load either in any order and run them separately without them interfering with one another. In System-X I'd like to present objects from System-Y differently than they are presented within that system. Obviously, I don't want to redefine presentation methods on the original System-Y presentations so that they would then be presented differently back in System-Y. Further, if presentation translators are defined on those presentations, then I don't want to give the original System-Y presentations new behavior. What's the best way to do this? The essence of this question really begs a pretty basic question about presentations and the best way to present the same object differently. First off, you have to answer the question, what protocol do you intend to use to communicate between System X and System Y. This is especially important since you say that you wish to be able to run them separately. This has nothing to do with CLIM. In order to present things differently based on which system you are in, use the VIEW argument to PRESENT and/or ACCEPT. For example, (define-presentation-type my-integer () :inherit-from 'integer) (defclass binary-view (textual-view) ()) (defvar +binary-view+ (make-instance 'binary-view)) (defclass octal-view (textual-view) ()) (defvar +octal-view+ (make-instance 'octal-view)) (define-presentation-method present (mi (type my-integer) stream (view binary-view) &key) (write mi :base 2 :stream stream)) (define-presentation-method present (mi (type my-integer) stream (view octal-view) &key) (write mi :base 8 :stream stream)) (present '10 'my-integer :view +binary-view+) ==> 1010 (present '10 'my-integer :view +octal-view+) ==> 12 This is the same mechanism used by CLIM 2.0 to hook up presentation types to gadgets. For instance, the following method causes booleans to be displayed as check-boxes inside of a dialog: (define-presentation-method accept-present-default ((type boolean) stream (view toggle-button-view) default default-supplied-p present-p query-identifier &key (prompt t)) (declare (ignore default-supplied-p present-p)) (flet ((update-gadget (record gadget button) (declare (ignore record gadget)) (setf (gadget-value button) default))) (with-output-as-gadget (stream :cache-value type :update-gadget #'update-gadget) (let ((button (make-pane-from-view 'toggle-button view :label (and (stringp prompt) prompt) :value default :client stream :id query-identifier :value-changed-callback (make-accept-values-value-changed-callback stream query-identifier)))) (values (outlining () button) button)))))   Received: from BBN.COM by LABS-N.BBN.COM id aa17623; 7 Aug 92 10:01 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa29282; 7 Aug 92 9:55 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1121103; 7 Aug 1992 09:55:46-0400 Date: Fri, 7 Aug 1992 09:56-0400 From: Scott McKay Subject: arrows & your answer To: Ralph.Hensel@gmd.de, SWM@STONY-BROOK.SCRC.Symbolics.COM cc: clim@BBN.COM In-Reply-To: <199208070726.AA06384@gmdzi.gmd.de> Message-ID: <19920807135640.6.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 7 Aug 1992 03:26 EDT From: Ralph.Hensel@gmd.de Hi, I`m working on Sun with Framz Allegro 4.01 and CLIM 1.0 You need CLIM 1.1 You wrote that the following will work on SUN as draw-arrow: (in-package :clim) (define-graphics-operation draw-arrow (x1 y1 x2 y2 &key (from-head nil) (to-head t) (head-length 10) (head-width 5)) :arguments ((point x1 y1 x2 y2)) :drawing-options :line-cap :method-body (with-transformed-arguments (let* ((dx (- x2 x1)) (dy (- y2 y1)) (norm (if (zerop dx) (if (zerop dy) nil (/ 1.0 (abs dy))) (if (zerop dy) (/ 1.0 (abs dx)) (/ (sqrt (+ (* dx dx) (* dy dy)))))))) (when norm (let* ((length-norm (* head-length norm)) (ldx (* dx length-norm)) (ldy (* dy length-norm)) (base-norm (* head-width norm 0.5)) (bdx (* dy base-norm)) (bdy (* dx base-norm)) (ink (medium-ink stream)) (line-style (medium-line-style stream))) (draw-line-internal stream 0 0 x1 y1 x2 y2 ink line-style) (when from-head (let ((xa (+ x1 ldx)) (ya (+ y1 ldy))) (with-stack-list (points x1 y1 (+ xa bdx) (- ya bdy) (- xa bdx) (+ ya bdy)) (draw-polygon-internal stream 0 0 points t ink nil)) (setq x1 xa y1 ya))) (when to-head (let ((xa (- x2 ldx)) (ya (- y2 ldy))) (with-stack-list (points x2 y2 (+ xa bdx) (- ya bdy) (- xa bdx) (+ ya bdy)) (draw-polygon-internal stream 0 0 points t ink nil) (setq x2 xa y2 ya))))))))) But what is (with-transformed-arguments ...). It seems that it doesn't work under CLIM 1.0 Ralph Hensel German National Research Center for Computer Science (GMD-FIT.KI) P.O. Box 1316, D-5205 Sankt Augustin, Germany mail:hensel@gmdzi.gmd.de fax:+49-2241-14-2889 phone:+49-2241-14-1   Received: from BBN.COM by LABS-N.BBN.COM id aa19449; 7 Aug 92 12:36 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa06837; 7 Aug 92 12:32 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1121249; 7 Aug 1992 12:32:23-0400 Date: Fri, 7 Aug 1992 12:33-0400 From: Scott McKay Subject: clim 2.0 color dialog code To: pchu@ptolemy.arc.nasa.gov, clim@BBN.COM In-Reply-To: <9208060000.AA16109@ptolemy.arc.nasa.gov> Message-ID: <19920807163314.9.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 5 Aug 1992 20:00 EDT From: Philip Chu-Summer 92 This is my first cut at CLIM 2.0 code (and, as yet, still one of my early uses of any version of CLIM). It consists of color dialogs that have sliders to change the color components. The calling form is (CHOOSE-COLOR mode) where mode is one of :RGB or :GRAY. (I had started to add :IHS as option, but I found that COLOR-IHS couldn't extract components from non-ihs colors, a bug I've reported to Franz). I've only run this with Franz ACL and Motif, so I don't have any idea how it looks on other setups. I'd appreciate anyone giving the code a look-over and some feedback. In particular, is DEFINE-APPLICATION-FRAME an appropriate way to define dialogs that are used as part of a larger application? Am I defining the callbacks in an appropriate manner? etc. By coincidence, I had literally just started writing a little "color editor" demo when this message came in. This is what I came up with. There are a few things to notice: - the slightly different callback function for the Exit button - the way the RGB sliders are linked to the IHS sliders - different way of painting the color swatch, which is lower overhead than changing the medium backgound of the display pane - use of the PANE-FRAME function rather than *APPLICATION-FRAME* Note that you seem not have a complete implementation of COLOR-RGB and COLOR-IHS -- I just did those recently. Also, I had to fix a bug in WINDOW-VIEWPORT for panes that do not have scrollbars. ------------ ;;; -*- Mode: Lisp; Syntax: ANSI-Common-Lisp; Package: CLIM-DEMO; Base: 10; Lowercase: Yes -*- (in-package :clim-demo) "Copyright (c) 1992 Symbolics, Inc. All rights reserved." (define-application-frame color-chooser () ((color :accessor color :initform +black+) red blue green intensity hue saturation) (:menu-bar nil) (:panes (display :application :scroll-bars nil :display-function 'display-color ;; Make sure we don't have a useless cursor blinking away... :initial-cursor-visibility nil) (exit push-button :label "Exit" :activate-callback #'(lambda (button) (frame-exit (pane-frame button)))) (rgb (with-slots (red green blue) *application-frame* (outlining () (horizontally () (setq red (make-pane 'slider :label "Red" :foreground +red+ :orientation :vertical :min-value 0.0 :max-value 1.0 :show-value-p t :decimal-places 3 :client 'color :id 'red)) (setq green (make-pane 'slider :label "Green" :foreground +green+ :orientation :vertical :min-value 0.0 :max-value 1.0 :show-value-p t :decimal-places 3 :client 'color :id 'green)) (setq blue (make-pane 'slider :label "Blue" :foreground +blue+ :orientation :vertical :min-value 0.0 :max-value 1.0 :show-value-p t :decimal-places 3 :client 'color :id 'blue)))))) (ihs (with-slots (intensity hue saturation) *application-frame* (outlining () (horizontally () (setq intensity (make-pane 'slider :label "Intensity" :orientation :vertical :min-value 0.0 :max-value (sqrt 3) :show-value-p t :decimal-places 3 :client 'color :id 'intensity)) (setq hue (make-pane 'slider :label "Hue" :orientation :vertical :min-value 0.0 :max-value 1.0 :show-value-p t :decimal-places 3 :client 'color :id 'hue)) (setq saturation (make-pane 'slider :label "Saturation" :orientation :vertical :min-value 0.0 :max-value 1.0 :show-value-p t :decimal-places 3 :client 'color :id 'saturation))))))) (:layouts (default (horizontally () (outlining () (vertically () display exit)) rgb ihs)))) (defmethod display-color ((frame color-chooser) stream) (with-bounding-rectangle* (left top right bottom) (window-viewport stream) (with-output-recording-options (stream :record nil) (draw-rectangle* stream left top right bottom :filled t :ink (color frame))))) (defmacro define-rgb-callbacks (color) (check-type color (member red green blue)) (let* ((rgb '(red green blue)) (new-rgb (substitute 'value color rgb))) `(progn (defmethod value-changed-callback ((slider slider) (client (eql 'color)) (id (eql ',color)) value) (let ((frame (pane-frame slider))) (multiple-value-bind (,@rgb) (color-rgb (color frame)) (declare (ignore ,color)) (setf (color frame) (make-rgb-color ,@new-rgb))) (update-ihs frame))) (defmethod drag-callback ((slider slider) (client (eql 'color)) (id (eql ',color)) value) (let ((frame (pane-frame slider))) (multiple-value-bind (,@rgb) (color-rgb (color frame)) (declare (ignore ,color)) (setf (color frame) (make-rgb-color ,@new-rgb))) (update-ihs frame)))))) (define-rgb-callbacks red) (define-rgb-callbacks green) (define-rgb-callbacks blue) (defmethod update-ihs ((frame color-chooser)) (with-slots (intensity hue saturation) frame (multiple-value-bind (ii hh ss) (color-ihs (color frame)) (setf (gadget-value intensity :invoke-callback nil) ii) (setf (gadget-value hue :invoke-callback nil) hh) (setf (gadget-value saturation :invoke-callback nil) ss)))) (defmacro define-ihs-callbacks (color) (check-type color (member intensity hue saturation)) (let* ((ihs '(intensity hue saturation)) (new-ihs (substitute 'value color ihs))) `(progn (defmethod value-changed-callback ((slider slider) (client (eql 'color)) (id (eql ',color)) value) (let ((frame (pane-frame slider))) (multiple-value-bind (,@ihs) (color-ihs (color frame)) (declare (ignore ,color)) (setf (color frame) (make-ihs-color ,@new-ihs))) (update-rgb frame))) (defmethod drag-callback ((slider slider) (client (eql 'color)) (id (eql ',color)) value) (let ((frame (pane-frame slider))) (multiple-value-bind (,@ihs) (color-ihs (color frame)) (declare (ignore ,color)) (setf (color frame) (make-ihs-color ,@new-ihs))) (update-rgb frame)))))) (define-ihs-callbacks intensity) (define-ihs-callbacks hue) (define-ihs-callbacks saturation) (defmethod update-rgb ((frame color-chooser)) (with-slots (red green blue) frame (multiple-value-bind (rr gg bb) (color-rgb (color frame)) (setf (gadget-value red :invoke-callback nil) rr) (setf (gadget-value green :invoke-callback nil) gg) (setf (gadget-value blue :invoke-callback nil) bb)))) (defmethod value-changed-callback :after ((slider slider) (client (eql 'color)) id value) (declare (ignore id value)) (redisplay-frame-pane (pane-frame slider) 'display)) (defvar *color-choosers* nil) (defun do-color-chooser (&key (port (find-port)) (force nil)) (let* ((framem (find-frame-manager :port port)) (frame (let* ((entry (assoc port *color-choosers*)) (frame (cdr entry))) (when (or force (null frame)) (setq frame (make-application-frame 'color-chooser :frame-manager framem))) (if entry (setf (cdr entry) frame) (push (cons port frame) *color-choosers*)) frame))) (run-frame-top-level frame) (color frame))) (define-demo "Color Chooser" do-color-chooser)   Received: from BBN.COM by LABS-N.BBN.COM id aa21407; 7 Aug 92 15:15 EDT Received: from chesapeake.ads.com by BBN.COM id aa14644; 7 Aug 92 15:12 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA20833; Fri, 7 Aug 92 15:14:03 EDT Date: Fri, 7 Aug 92 15:14:03 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9208071914.AA20833@chesapeake.ads.com> To: berni@iml.fhg.de Cc: clim@bbn.com In-Reply-To: Stefan Bernemann's message of Fri, 7 Aug 1992 12:20+0100 <19920807112039.1.STEFAN@ANNA.iml.fhg.de> Subject: Re: updating-output and recursive use of formatting-graph-from-root Reply-To: jclose@ads.com Stefan, In your example: Lost in helplessness - Stefan B. ;;;What follows is the display method for the tree-pane: (defmethod draw-tree-as-tree ((frame tree1) stream) (let ((tree (tree1-tree frame))) (labels ((draw-subtree (subtree stream) (let* ((inferior-producer #'(lambda (node) ;; just return the direct inferiors (and (eql node subtree) (tree-node-expanded node) (tree-node-children node))))) (updating-output (stream :unique-id subtree :cache-value (tree-node-tick-mark subtree) :cache-test #'=) (with-output-as-presentation (:stream stream :object subtree :type 'tree) (cond ((and (tree-node-children subtree) (tree-node-expanded subtree)) ; we have to draw a tree (format-graph-from-root subtree #'(lambda (node stream) (if (eql node subtree) (format stream "~A" ; draw root node (tree-node-value node)) (draw-subtree node stream))) ; draw sons as trees inferior-producer :stream stream)) (t ; we have to draw a leaf (format stream "~A" (tree-node-value subtree))))))))) (draw-subtree tree stream)))) It looks like you're trying to call format-graph-from-root recursively, which I don't believe you want. In effect, you are giving format-graph-from-root the form to create a whole subtree where it only wants the form to draw one node of the tree. I think you may accomplish what you want by giving a single-node drawing form to f-g-f-r as the printer, with that form including an updating-output and an output-record producing form (like a presentation). Your code is trying to draw the tree itself, which frmat-.. already does. Or, I could be totally off on this. Jeff   Received: from BBN.COM by LABS-N.BBN.COM id aa21162; 7 Aug 92 14:56 EDT Received: from chesapeake.ads.com by BBN.COM id aa13563; 7 Aug 92 14:51 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA20611; Fri, 7 Aug 92 14:53:12 EDT Date: Fri, 7 Aug 92 14:53:12 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9208071853.AA20611@chesapeake.ads.com> To: SWM@stony-brook.scrc.symbolics.com Cc: clim@bbn.com In-Reply-To: Scott McKay's message of Fri, 7 Aug 1992 10:16-0400 <19920807141653.8.SWM@SUMMER.SCRC.Symbolics.COM> Subject: Re: Style and Design question about presentations Reply-To: jclose@ads.com Scott, et al. Thanks for your response. This is what I was working towards when I got your message: ;;; Display routines for PPs ;;; (defclass kat-display-view (clim:dialog-view) ()) (defvar +kat-display-view+ (make-instance 'kat-display-view)) ;;; present in my view (clim:define-presentation-method clim:present (self (type progress-profile) stream (view kat-display-view) &key) (clim:with-output-as-presentation (:object self :stream stream :single-box t) (kat-display self stream)) ) "progress-profile" is a class from the other application "kat" is my system I.e., at least I was on the right track (even down to the plus signs :). One thing I'm not sure I understand about your example -- is there any reason I need to define a new pres-type? It doesn't seem necessary. I should be able to define new clim:present methods with a different view without otherwise interfering with the old presentation type. Jeff   Received: from BBN.COM by LABS-N.BBN.COM id ab22284; 7 Aug 92 16:54 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa15656; 7 Aug 92 15:47 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1121406; 7 Aug 1992 15:47:38-0400 Date: Fri, 7 Aug 1992 15:48-0400 From: Scott McKay Subject: Re: Style and Design question about presentations To: jclose@ads.com, SWM@STONY-BROOK.SCRC.Symbolics.COM cc: clim@bbn.com In-Reply-To: <9208071853.AA20611@chesapeake.ads.com> Message-ID: <19920807194818.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 7 Aug 1992 14:53 EDT From: jclose@chesapeake.ads.com (Jeff Close) Scott, et al. Thanks for your response. This is what I was working towards when I got your message: ;;; Display routines for PPs ;;; (defclass kat-display-view (clim:dialog-view) ()) (defvar +kat-display-view+ (make-instance 'kat-display-view)) ;;; present in my view (clim:define-presentation-method clim:present (self (type progress-profile) stream (view kat-display-view) &key) (clim:with-output-as-presentation (:object self :stream stream :single-box t) (kat-display self stream)) ) "progress-profile" is a class from the other application "kat" is my system I.e., at least I was on the right track (even down to the plus signs :). One thing I'm not sure I understand about your example -- is there any reason I need to define a new pres-type? It doesn't seem necessary. I should be able to define new clim:present methods with a different view without otherwise interfering with the old presentation type. You don't need to define a new presentation type. I guess my example was confusing in that regard; sorry about that.   Received: from BBN.COM by LABS-N.BBN.COM id ac22284; 7 Aug 92 16:54 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa15679; 7 Aug 92 15:50 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1121410; 7 Aug 1992 15:49:23-0400 Date: Fri, 7 Aug 1992 15:50-0400 From: Scott McKay Subject: Re: Style and Design question about presentations To: jclose@ads.com, SWM@STONY-BROOK.SCRC.Symbolics.COM cc: clim@bbn.com In-Reply-To: <9208071928.AA21028@chesapeake.ads.com> Message-ID: <19920807195004.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 7 Aug 1992 15:28 EDT From: jclose@chesapeake.ads.com (Jeff Close) Whoops. I asked why I needed to define a new pres-type in my "view" problem. I just realized that presentation-to-command-translators don't have a view argument. Is this why a new pres-type is needed? Could I still use the old pres-type and test the view in the translator tester? The view isn't actually stored in the presentation. I would simply have different command tables for "system X" and "system Y", and have different translators for each system.   Received: from BBN.COM by LABS-N.BBN.COM id ai22284; 7 Aug 92 16:55 EDT Received: from atc.boeing.com by BBN.COM id aa17549; 7 Aug 92 16:19 EDT Received: by atc.boeing.com (5.57) id AA29788; Fri, 7 Aug 92 13:10:24 PDT Received: by hsvaic.boeing.com (4.1/SMI-4.1-hsvaic-s.2) id AA14246; Fri, 7 Aug 92 15:10:53 CDT Message-Id: <9208072010.AA14246@hsvaic.boeing.com> From: george@hsvaic.boeing.com (George Williams) Date: Fri, 7 Aug 1992 15:10:53 -0500 X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: clim@bbn.com Subject: help for editing text. (cont'd) ;;; -*- Mode: LISP; Syntax: Common-lisp; Package: ALEPS-USER; Base: 10 -*- ;; The following function is based on code from chee@isi.edu, "John G. Aspinall" , ;; and "Mike Brady" . ;; Some changes were made for flexibility. Others were necessary to get it to work from a button on an accepting-values dialog. (defun EDIT-POPUP (text &KEY (title "Hit when finished editing.") (width 60) (height 10) (associated-window (frame-top-level-window *application-frame*))) "Creates an edit popup window with the string TEXT to be edited. Returns the edited string. :TITLE is centered at the top of the window, :WIDTH and :HEIGHT are the window size in characters. If used in the context of ACCEPTING-VALUES, :ASSOCIATED-WINDOW must specify the a `real' frame-top-level-window, i.e., one from a real application-frame." (with-menu (stream associated-window) ;; Set up the pop-up window the way we want to see it (setf (clim::cursor-visibility (clim::stream-text-cursor stream)) :off) ;kludge (setq width (* width (stream-character-width stream #\Space)) height (* height (stream-line-height stream))) (clim::window-set-inside-size stream width height) (setf (stream-text-margin stream) (bounding-rectangle-width (window-viewport stream))) (when title (loop as pos = (position #\Return title) while pos as line = (subseq title 0 pos) finally (format stream "~A~2%" (centerable-string title stream :stream-width width)) do (setq title (subseq title (1+ pos))) (format stream (centerable-string line stream)))) (setf (stream-text-margin stream) (bounding-rectangle-width (window-viewport stream))) (window-expose stream) (unwind-protect (with-input-editing (stream) ;; Put the text into the input buffer and ensure that we never do it again ;; Code inside with-input-editing will restart any time the user edits ;; (e.g. types ). Therefore you must make sure that replace-input ;; only gets called the first time. (when text ;; fill the input buffer of the input-editing stream (replace-input stream text :rescan t) (setq text nil)) ;; kludge to get the contents displayed #+excl (window-refresh stream) ;; sometimes the simple window-refresh happens too soon... #+excl (mp::process-run-function "edit-popup-kludge" #'(lambda (stream) (sleep 1) (clim::window-refresh stream)) stream) ;; Now get the input from the user (with-activation-characters ('(#\Newline) :override t) (unwind-protect (read-token stream) ;; Eat the activation character (read-gesture :stream stream :timeout 0)))) ;; for some reason, the following line doesn't seem to work. (stream-set-cursor-position* stream (1- width) (1- height)) ;so we don't lose text after the cursor (setf (clim::cursor-visibility (clim::stream-text-cursor stream)) :inactive)))) ;kludge #| George Williams BCS Huntsville Artificial Intelligence Center Boeing Computer Services Internet: george@hsvaic.boeing.com POBox 240002, M/S JY-58 UUCP: ...!uw-beaver!bcsaic!hsvaic!george Huntsville AL 35824-6402 Phone: 205+464-4968 FAX: 205+464-4930 |#   Received: from BBN.COM by LABS-N.BBN.COM id al22284; 7 Aug 92 16:56 EDT Received: from aerospace.aero.org by BBN.COM id aa18169; 7 Aug 92 16:25 EDT Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT) id AA27463 for clim@bbn.com; Fri, 7 Aug 1992 13:20:57 -0700 Posted-Date: Fri, 7 Aug 92 13:20:52 PDT Message-Id: <199208072020.AA27463@aerospace.aero.org> Received: from reify.aero.org by antares.aero.org (4.1/AMS-1.0) id AA03923 for jdi@franz.com; Fri, 7 Aug 92 13:20:54 PDT Date: Fri, 7 Aug 92 13:20:52 PDT From: abbott@aero.org To: jdi@franz.com Cc: clim@bbn.com, swm@symbolics.com, ric@aero.org In-Reply-To: John Irwin's message of Wed, 05 Aug 92 17:39:08 -0700 <9208060039.AA26805@sparky.Franz.COM> Subject: [spr6315] menu-choose inside an accept-values-command-button This is in response to a reply from Franz to a request for help with an CLIM error message. You can skip to the code at the end and not lose anything important. | | > I get the following error message. | > | > Error: The unique-id (:BUTTON "") was used in more than one UPDATING-OUTPUT at the same level. | | This probably is happening because you have two accepts or | accept-values-command-buttons that accepting-values cannot tell apart. IE: | they have the same query-identifier. Every accept must have a unique | query-identifier. | | The query-identifier, if not specified for each accept or accept-values-command- | button, is gotten from the prompt. So if you have two accepts with the | same prompt, you'll need to supply explicit :query-identifier arguments | so that accepting-values can tell them apart. | | Let us know if this doesn't solve the problem for you. | | -- John | This doesn't solve my problem. Here is some example code that generates the error message. (defun test (Ttl) (accept-values-command-button (W) Ttl)) Generate a window W. Then: (accepting-values (W) (window-clear W) (test 1) (test 2)) -- Russ Abbott   Received: from BBN.COM by LABS-N.BBN.COM id ax22284; 7 Aug 92 16:56 EDT Received: from aerospace.aero.org by BBN.COM id aa18888; 7 Aug 92 16:33 EDT Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT) id AA27819 for clim@bbn.com; Fri, 7 Aug 1992 13:33:30 -0700 Posted-Date: Fri, 7 Aug 92 13:33:28 PDT Message-Id: <199208072033.AA27819@aerospace.aero.org> Received: from reify.aero.org by antares.aero.org (4.1/AMS-1.0) id AA04254 for clim@bbn.com; Fri, 7 Aug 92 13:33:29 PDT Date: Fri, 7 Aug 92 13:33:28 PDT From: abbott@aero.org To: clim@bbn.com Subject: PLease put my name on this list. Thanks   Received: from BBN.COM by LABS-N.BBN.COM id ad22568; 7 Aug 92 17:08 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa20263; 7 Aug 92 16:48 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1121472; 7 Aug 1992 16:49:03-0400 Date: Fri, 7 Aug 1992 16:49-0400 From: Scott McKay Subject: [spr6315] menu-choose inside an accept-values-command-button To: abbott@aero.org, jdi@franz.com cc: clim@bbn.com, swm@symbolics.com, ric@aero.org In-Reply-To: <199208072020.AA27463@aerospace.aero.org> Message-ID: <19920807204942.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 7 Aug 1992 16:20 EDT From: abbott@aero.org This is in response to a reply from Franz to a request for help with an CLIM error message. You can skip to the code at the end and not lose anything important. | | > I get the following error message. | > | > Error: The unique-id (:BUTTON "") was used in more than one UPDATING-OUTPUT at the same level. | | This probably is happening because you have two accepts or | accept-values-command-buttons that accepting-values cannot tell apart. IE: | they have the same query-identifier. Every accept must have a unique | query-identifier. | | The query-identifier, if not specified for each accept or accept-values-command- | button, is gotten from the prompt. So if you have two accepts with the | same prompt, you'll need to supply explicit :query-identifier arguments | so that accepting-values can tell them apart. | | Let us know if this doesn't solve the problem for you. | | -- John | This doesn't solve my problem. Here is some example code that generates the error message. (defun test (Ttl) (accept-values-command-button (W) Ttl)) Generate a window W. Then: (accepting-values (W) (window-clear W) (test 1) (test 2)) This code does not do what JDI suggested. The two command buttons have the same query id. You need to either (1) specify different prompts for the buttons, (2) specify different documentation for the buttons, or (3) explicitly specify different query indentifiers for the two command buttons.   Received: from BBN.COM by LABS-N.BBN.COM id aa22208; 7 Aug 92 16:51 EDT Received: from chesapeake.ads.com by BBN.COM id aa15189; 7 Aug 92 15:28 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA21028; Fri, 7 Aug 92 15:28:47 EDT Date: Fri, 7 Aug 92 15:28:47 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9208071928.AA21028@chesapeake.ads.com> To: SWM@stony-brook.scrc.symbolics.com Cc: clim@bbn.com In-Reply-To: Jeff Close's message of Fri, 7 Aug 92 14:53:12 EDT <9208071853.AA20611@chesapeake.ads.com> Subject: Re: Style and Design question about presentations Reply-To: jclose@ads.com Whoops. I asked why I needed to define a new pres-type in my "view" problem. I just realized that presentation-to-command-translators don't have a view argument. Is this why a new pres-type is needed? Could I still use the old pres-type and test the view in the translator tester? Jeff   Received: from BBN.COM by LABS-N.BBN.COM id aa00755; 8 Aug 92 15:23 EDT Received: from [192.44.1.1] by BBN.COM id aa12268; 8 Aug 92 15:14 EDT Received: by fhg.de (fhg1.fhg.de) with PRESMTP; Sat, 8 Aug 92 21:13:27 +0200 from FHG-GATEWAY Received: by fhg.de (fhg1.fhg.de) with SMTP; Sat, 8 Aug 92 21:12:32 +0200 from fhg.de Received: by fhg.de (fhg1.fhg.de) with PRESMTP; Sat, 8 Aug 92 21:12:31 +0200 from FHG-GATEWAY Received: by fhg.de (fhg1.fhg.de) with SMTP; Sat, 8 Aug 92 21:11:23 +0200 from fhg.de Received: by fhg.de (fhg1.fhg.de) with PRESMTP; Sat, 8 Aug 92 21:11:21 +0200 from FHG-GATEWAY Received: by fhg.de (fhg1.fhg.de) with SMTP; Sat, 8 Aug 92 21:10:12 +0200 from fhg.de Received: by fhg.de (fhg1.fhg.de) with PRESMTP; Sat, 8 Aug 92 21:10:11 +0200 from FHG-GATEWAY Received: by fhg.de (fhg1.fhg.de) with UUCP; Sat, 8 Aug 92 21:07:41 +0200 from imldo Received: by iml.fhg.de with SMTP; Sat, 8 Aug 92 20:56:41 +0200 Date: Sat, 8 Aug 1992 20:54+0200 From: Stefan Bernemann Subject: Re: updating-output and recursive use of formatting-graph-from-root To: jclose@ads.com Cc: clim@bbn.com In-Reply-To: <9208071914.AA20833@chesapeake.ads.com> Message-Id: <19920808185459.1.STEFAN@ANNA.iml.fhg.de> Date: Fri, 7 Aug 1992 21:14 MEST From: jclose%chesapeake.ads.com@fhg.de (Jeff Close) Stefan, In your example: [...] It looks like you're trying to call format-graph-from-root recursively, which I don't believe you want. In effect, you are Hm, I *want* to display trees where individual subtrees can be incrementally redisplayed. But yes, in this try I indeed call f-g-f-r recursively so that every subtree (the whole tree output record, not just the presentation of the node) is captured by an updating-output-record. giving format-graph-from-root the form to create a whole subtree where it only wants the form to draw one node of the tree. I think you may accomplish what you want by giving a single-node drawing form to f-g-f-r as the printer, with that form including an updating-output and an output-record producing form (like a presentation). Your code That's what I've tried before (see my previous posting for a complete code example) but the incremental redisplay didn't manage to "move" otherwise unaffected subtrees - maybe because just the presentations of the nodes are captured inside of updating-output, not the output record of a whole (sub)tree. is trying to draw the tree itself, which frmat-.. already does. Or, I could be totally off on this. Jeff I'm wondering - How to implement the behavior I want - Wy my code runs into an infinite loop, i.e. is there a bug in my code, is there a bug in CLIM or is there something missing in the documentation forbidding what I'm doing (calling f-g-f-r recursively or using it together with updating-output) or have I overlooked it in the docs (But then I overlooked it many times!) Stefan B.   Received: from BBN.COM by LABS-N.BBN.COM id aa26382; 10 Aug 92 23:55 EDT Received: from ptolemy-arclan.arc.nasa.gov by BBN.COM id aa27132; 10 Aug 92 23:42 EDT Received: from jung.arc.nasa.gov by ptolemy.arc.nasa.gov (4.1/) id ; Mon, 10 Aug 92 20:43:29 PDT Date: Mon, 10 Aug 92 20:43:29 PDT From: Philip Chu-Summer 92 Message-Id: <9208110343.AA16604@ptolemy.arc.nasa.gov> Received: by jung.arc.nasa.gov (4.1/SMI-4.1) id AA14344; Mon, 10 Aug 92 20:35:52 PDT To: SWM@stony-brook.scrc.symbolics.com Cc: clim@BBN.COM In-Reply-To: Scott McKay's message of Fri, 7 Aug 1992 12:33-0400 <19920807163314.9.SWM@SUMMER.SCRC.Symbolics.COM> Subject: clim 2.0 color dialog code Sender: SWM%stony-brook.scrc.symbolics.com@BBN.COM Date: Fri, 7 Aug 1992 12:33-0400 From: Scott McKay Date: Wed, 5 Aug 1992 20:00 EDT From: Philip Chu-Summer 92 By coincidence, I had literally just started writing a little "color editor" demo when this message came in. This is what I came up with. There are a few things to notice: - the slightly different callback function for the Exit button - the way the RGB sliders are linked to the IHS sliders - different way of painting the color swatch, which is lower overhead than changing the medium backgound of the display pane - use of the PANE-FRAME function rather than *APPLICATION-FRAME* Note that you seem not have a complete implementation of COLOR-RGB and COLOR-IHS -- I just did those recently. Also, I had to fix a bug in WINDOW-VIEWPORT for panes that do not have scrollbars. Thanks, I found your color demo helpful in clearing up a lot of points. I am still puzzled by one aspect of slider callbacks. Originally, I defined a method on DRAG-CALLBACK, but that didn't seem to have any effect, so I switched to VALUE-CHANGED-CALLBACK. I noticed in your example that you define identical methods on both. Are they both called when the slider is dragged, or is one supposed to supersede the other? Phil Chu Artificial Intelligence Research Branch NASA Ames Research Center pchu@ptolemy.arc.nasa.gov   Received: from BBN.COM by LABS-N.BBN.COM id aa04942; 11 Aug 92 13:30 EDT Received: from atc.boeing.com by BBN.COM id aa17783; 11 Aug 92 13:25 EDT Received: by atc.boeing.com (5.57) id AA04518; Tue, 11 Aug 92 10:07:51 PDT Received: by hsvaic.boeing.com (4.1/SMI-4.1-hsvaic-s.2) id AA11918; Tue, 11 Aug 92 12:13:55 CDT Date: Tue, 11 Aug 92 12:13:55 CDT From: george@hsvaic.boeing.com (George Williams) Message-Id: <9208111713.AA11918@hsvaic.boeing.com> To: clim@bbn.com Subject: problem with buttons in dialogs Try this simple test. When you click on the buttons to toggle the values, the text in the buttons disappears. Suggestions? Thanks, George Williams BCS Huntsville Artificial Intelligence Center Boeing Computer Services Internet: george@hsvaic.boeing.com POBox 240002, M/S JY-58 UUCP: ...!uw-beaver!bcsaic!hsvaic!george Huntsville AL 35824-6402 Phone: 205+464-4968 FAX: 205+464-4930 ----8< snip >8--------8< snip >8--------8< snip >8--------8< snip >8---- (defun test (x &AUX (stream *root-window*)) (accepting-values (stream :own-window '(:right-margin (15 :character)) :resynchronize-every-pass t) (format stream "Value Of X.............................. ") (with-drawing-options (stream :line-thickness 2) (surrounding-output-with-border (stream) (setq x (car (accept '(subset-alist (("Toggle X" . t))) :prompt "" :query-identifier "1" :prompt-mode :raw :stream stream :default (list x)))))) (terpri stream) (format stream "Value Of X.............................. ") (with-drawing-options (stream :line-thickness 2) (surrounding-output-with-border (stream) (setq x (car (accept '(subset-alist (("Toggle X" . t))) :prompt "" :query-identifier "2" :prompt-mode :raw :stream stream :default (list x)))))))) (test t)   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa04661; 11 Aug 92 13:18 EDT Received: by KARIBA.BBN.COM id ab25595; 11 Aug 92 11:51 EDT To: nrb!keunen@relay.eu.net cc: clim@BBN.COM, cerys@BBN.COM Subject: Re: clim library suggestions In-reply-to: Vincent Keunen's message of Mon, 03 Aug 92 17:26:00 +0200. <19920803152608.6.KEUNEN@nrbmi1.ia.nrb.be> Reply-To: jmorrill@BBN.COM Date: Tue, 11 Aug 92 11:46:11 -0400 Message-ID: <1341.713547971@bbn.com> From: Jeff Morrill Date: Mon, 3 Aug 1992 17:26+0200 From: Vincent Keunen Reply-To: nrb!keunen@relay.eu.net Subject: clim library suggestions To: clim@nrbmi2.ia.nrb.be, clim-request@BBN.COM Philip Chu says: Date: Sat, 25 Jul 1992 03:02+0200 From: Philip Chu-Summer 92 2) A mail archive for the clim@bbn mail list. I don't know how you'd go about setting one up, but I've often wished for one when plowing through my Symbolics CLIM manual. Do the people at bbn maintaining the clim list keep an archive? If not, would it be a lot of work? Sorry to ask that on the list, but I don't know who to contact. Vincent =============================================================== Keunen Vincent Network Research Belgium R&D, Software Engineer Parc Industriel des Hauts-Sarts keunen@nrb.be 2e Avenue, 65 tel: +32 41 407282 B-4040 Herstal fax: +32 41 481170 BELGIUM =============================================================== Dan Cerys maintains this list, but apparently he is on vacation till August 17. I believe there is an archive, but I am not sure. This sounds like a good suggestion. jeff morrill   Received: from BBN.COM by LABS-N.BBN.COM id aa08659; 11 Aug 92 18:08 EDT Received: from atc.boeing.com by BBN.COM id aa02957; 11 Aug 92 18:03 EDT Received: by atc.boeing.com (5.57) id AA25985; Tue, 11 Aug 92 14:57:31 PDT Received: by hsvaic.boeing.com (4.1/SMI-4.1-hsvaic-s.2) id AA14119; Tue, 11 Aug 92 17:03:34 CDT Message-Id: <9208112203.AA14119@hsvaic.boeing.com> From: george@hsvaic.boeing.com (George Williams) Date: Tue, 11 Aug 1992 17:03:34 -0500 X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: clim@bbn.com Subject: Re: problem with buttons in dialogs I earlier wrote: > Try this simple test. When you click on the buttons to toggle the > values, the text in the buttons disappears. [code omitted] I have since discovered that adding the following code at the end of the accepting-values body causes the dialog to be updated (after a second of looking ugly). BTW, this is CLIM 1.1, Franz ACL 4.1, Sun-4. (mp:process-run-function "redisplay-kludge" #'(lambda (stream) (sleep 1) (window-refresh stream)) stream) I would welcome a more aesthetic resolution to this. George Williams BCS Huntsville Artificial Intelligence Center Boeing Computer Services Internet: george@hsvaic.boeing.com POBox 240002, M/S JY-58 UUCP: ...!uw-beaver!bcsaic!hsvaic!george Huntsville AL 35824-6402 Phone: 205+464-4968 FAX: 205+464-4930   Received: from BBN.COM by LABS-N.BBN.COM id aa09311; 11 Aug 92 19:19 EDT Received: from pecos.ads.com by BBN.COM id aa04613; 11 Aug 92 19:16 EDT Received: by pecos.ads.com (4.1/1.34v1.3) id AA00675; Tue, 11 Aug 92 19:19:14 EDT Date: Tue, 11 Aug 92 19:19:14 EDT From: chyde@chesapeake.ads.com (Clinton Hyde) Message-Id: <9208112319.AA00675@pecos.ads.com> To: clim@bbn.com Subject: accepting-values and exit-boxes is Accepting-values only allowed to have the two exit-boxes :exit and :abort? I'd really like to have three, and attach some behavior to them. -- clint   Received: from BBN.COM by LABS-N.bbn.COM id aa06128; 13 Aug 92 18:35 EDT Received: from chesapeake.ads.com by BBN.COM id aa29410; 13 Aug 92 18:28 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA01658; Thu, 13 Aug 92 18:31:26 EDT Date: Thu, 13 Aug 92 18:31:26 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9208132231.AA01658@chesapeake.ads.com> To: clim@bbn.com Subject: Accept definition with nested accepts... again Reply-To: jclose@ads.com Greetings, It's been awhile since I did this in DW and I can't remember how to do it. I'd like to write an accept method in CLIM that has several accepts inside it. Defining the accept for pres type Z. If I use individual accepts inside the definition, and then do an (accept 'z), it attempts to exit the main accept. If I use an accepting values inside, as soon as I click on the first item, I get an error from STREAM-TEXT-CURSOR. I know this should be pat by now, but, ... what can I say, I'm beat :) Jeff   Received: from BBN.COM by LABS-N.BBN.COM id aa07060; 13 Aug 92 20:49 EDT Received: from mwunix.mitre.org by BBN.COM id aa02545; 13 Aug 92 20:46 EDT Return-Path: Received: from starbase.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA03930; Thu, 13 Aug 92 20:43:18 -0400 Received: from drake.mitre.org by starbase.mitre.org (4.1/SMI-4.1) id AA13161; Thu, 13 Aug 92 19:57:01 EDT Date: Thu, 13 Aug 92 19:57:01 EDT From: sims@starbase.MITRE.ORG (Jim Sims) Message-Id: <9208132357.AA13161@starbase.mitre.org> Received: by drake.mitre.org (4.1/SMI-4.1) id AA04150; Thu, 13 Aug 92 20:05:44 EDT To: clim@bbn.com Subject: DW->CLIM question I have an implemenation of sliders used to set global values, that are linked together by arbitrary formulae. In my old DW code, I used a presentation action to call a method so that while the user held down the left button, the "knob" of the slider would track the mouse up and down, setting the value of the affected variable (and all the others linked to it by formulae). It seems to work OK under CLIM, except that new presentations dont get drawn for the "knob". Under DW, I used the following snippet inside the method that tracks the mouse motion. How do I get the effect of the :with-normal-presentation-state in CLIM? ;;Output recording is disabled inside translators. ;;(scl:send window :with-normal-presentation-state ;; #'(lambda() (update-slider s window)))) Also, the old (original) presentation seems to no longer exist either... Do I need to do something like remove-output-record on it to get rid of it or is it really gone? thanks, jim (sims@starbase.mitre.org)   Received: from BBN.COM by LABS-N.bbn.COM id aa07058; 13 Aug 92 20:48 EDT Received: from mwunix.mitre.org by BBN.COM id aa02546; 13 Aug 92 20:46 EDT Return-Path: Received: from starbase.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA03944; Thu, 13 Aug 92 20:44:00 -0400 Received: from drake.mitre.org by starbase.mitre.org (4.1/SMI-4.1) id AA13204; Thu, 13 Aug 92 20:23:05 EDT Date: Thu, 13 Aug 92 20:23:05 EDT From: sims@starbase.MITRE.ORG (Jim Sims) Message-Id: <9208140023.AA13204@starbase.mitre.org> Received: by drake.mitre.org (4.1/SMI-4.1) id AA04193; Thu, 13 Aug 92 20:32:50 EDT To: clim@bbn.com Subject: correction in my last post, I remarked that the (original) presentation seemed to be gone after the tracking-pointer method was used. It actually is still there, so the other two problems remain: How to get rid of the original presentation How to replace it with a new presentation (somewhere else) inside that translation (a define-presentation-action) since, apparently like DW, presentations are disabled inside translators. In DW, the way to handle this (at least I did) was to use: ;;Output recording is disabled inside translators. ;;(scl:send window :with-normal-presentation-state ;; #'(lambda() (update-slider s window)))) ideas? thanks, jim   Received: from BBN.COM by LABS-N.BBN.COM id aa07786; 13 Aug 92 22:19 EDT Received: from chesapeake.ads.com by BBN.COM id aa05174; 13 Aug 92 22:15 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA03526; Thu, 13 Aug 92 22:16:26 EDT Date: Thu, 13 Aug 92 22:16:26 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9208140216.AA03526@chesapeake.ads.com> To: sims@starbase.mitre.org Cc: clim@bbn.com In-Reply-To: Jim Sims's message of Thu, 13 Aug 92 19:57:01 EDT <9208132357.AA13161@starbase.mitre.org> Subject: Re: DW->CLIM question Reply-To: jclose@ads.com Date: Thu, 13 Aug 92 20:23:05 EDT From: Jim Sims How to get rid of the original presentation How to replace it with a new presentation (somewhere else) inside that translation (a define-presentation-action) since, apparently like DW, presentations are disabled inside translators. In DW, the way to handle this (at least I did) was to use: ;;Output recording is disabled inside translators. ;;(scl:send window :with-normal-presentation-state ;; #'(lambda() (update-slider s window)))) Jim, I believe you need to use clim:erase-output-record to get rid of the original presentation. Replace it within the pres-action using dragging-output-record, dragging-output, or by erasing and recreating the presentation, if you're just using tracking-pointer. Be VERY careful with variable-name choices within these macros, since they are implemented such that your own variables, including slot names, may be masked (I found this recently). Hope this helps. Jeffrey   Received: from BBN.COM by LABS-N.BBN.COM id aa10963; 14 Aug 92 5:29 EDT Received: from noc.BelWue.DE by BBN.COM id aa10763; 14 Aug 92 5:11 EDT Received: from adler.ims.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA28380 (5.65c/BelWue-M2.03 for ); Fri, 14 Aug 1992 11:11:18 +0200 Received: from milan.ims.uni-stuttgart.de by adler.ims.uni-stuttgart.de id AA23035; Fri, 14 Aug 92 11:11:16 +0200 Date: Fri, 14 Aug 92 11:11:16 +0200 From: Oliver Christ Message-Id: <9208140911.AA23035@adler.ims.uni-stuttgart.de> Received: by milan.ims.uni-stuttgart.de id AA03354; Fri, 14 Aug 92 11:11:14 +0200 To: clim@bbn.com Subject: [MCL-CLIM] Gestures Reply-To: oli@ims.uni-stuttgart.de [working with MCL 2.0 Final & CLIM on MAC] Just a short and silly question: how can I get the gestures :describe and :menu (and the other predefined ones) on the Mac? To which events are they bound? Thanks for any help, Oli   Received: from BBN.COM by LABS-N.BBN.COM id aa14348; 14 Aug 92 11:07 EDT Received: from gmdzi.gmd.de by BBN.COM id aa21113; 14 Aug 92 10:55 EDT Received: from localhost by gmdzi.gmd.de with SMTP id AA19431 (5.65c/IDA-1.4.4 for clim@BBN.COM); Fri, 14 Aug 1992 16:54:51 +0200 Message-Id: <199208141454.AA19431@gmdzi.gmd.de> To: clim@BBN.COM Subject: rubber-band lines ? Date: Fri, 14 Aug 92 16:54:50 +0200 From: Ralph.Hensel@gmd.de X-Mts: smtp Hi, I am using CLIM 1.0 and AllegroCL 4.01 on a SUN. I like to have a rubber-band line in my application, i.e. to have a line (a presentation) and a possibility to "bend" this line by clicking on a point of that line (or on a kind of handle) and dragging it. Does someone have an example of something like that ? Thanks Ralph Hensel German National Research Center for Computer Science (GMD-FIT.KI) P.O. Box 1316, D-5205 Sankt Augustin, Germany mail:hensel@gmdzi.gmd.de fax:+49-2241-14-2889 phone:+49-2241-14-1   Received: from BBN.COM by LABS-N.BBN.COM id aa15182; 14 Aug 92 12:26 EDT Received: from lucid.com by BBN.COM id aa25119; 14 Aug 92 12:19 EDT Received: from kuwait.lucid ([192.31.212.118]) by heavens-gate.lucid.com id AA24850g; Fri, 14 Aug 92 09:09:02 PDT Received: by kuwait.lucid (4.1/SMI-4.1) id AA04713; Fri, 14 Aug 92 09:16:29 PDT Date: Fri, 14 Aug 92 09:16:29 PDT From: kern%kuwait@lucid.com (John Kern) Message-Id: <9208141616.AA04713@kuwait.lucid> To: Ralph.Hensel@gmd.de Cc: clim@BBN.COM Subject: rubber-band lines ? Reply-To: kern@lucid.com Howdy Mr. Hensel, The following short program does this with a straight line. While it isn't quite what you asked for, I hope it helps. Sincerely, John S. Kern Lucid, Inc =============== (in-package :clim-user) (define-application-frame test () () (:panes ((main :application :incremental-redisplay nil :default-size :rest :display-function 'display-main) (test-menu :command-menu))) (:command-table (test-menu :inherit-from (user-command-table) :menu (("EXIT" :command cmd-exit) ("rubber" :command cmd-rubberband) )))) (defmethod display-main ((frame test) stream) (cmd-rubberband) ) (defun ctest (root) (let (frame) (setq *frame* (make-application-frame 'test :parent root :left 0 :top 0 :right 500 :bottom 500)) (run-frame-top-level *frame*) )) (defun cmd-exit () (frame-exit *application-frame*) ) (defun cmd-rubberband () (let ((x1 0) ;; x1, y1 represents the fix point (y1 0) (x2 0) ;; x2,y2 represents the point that is changing (y2 0) (mouse-button-press nil) ;; set to T when mouse button has ;; press to select pivot (stream (get-frame-pane *application-frame* 'main))) (tracking-pointer (stream) (:pointer-button-press (event x y ) (setf x1 x y1 y x2 x y2 y) (draw-line* stream x1 y1 x2 y2 :ink +flipping-ink+) (setf mouse-button-press t)) (:pointer-motion (window x y) (when Mouse-button-press ;;erase (draw-line* stream x1 y1 x2 y2 :ink +flipping-ink+) ;; draw (draw-line* stream x1 y1 x y :ink +flipping-ink+) (setf x2 x y2 y))) (:pointer-button-release (event x y ) (cond ((eq mouse-button-press t) (return (list x1 y1 x2 y2)))))) ) )   Received: from BBN.COM by LABS-N.BBN.COM id aa14996; 14 Aug 92 12:03 EDT Received: from [129.197.134.99] by BBN.COM id aa24159; 14 Aug 92 11:58 EDT Received: from jade.rdd.lmsc.lockheed.com by dipl.rdd.lmsc.lockheed.com (4.0/SMI-4.1) id AA00381; Fri, 14 Aug 92 08:59:02 PDT Received: from stetson.lmsc.com by jade.rdd.lmsc.lockheed.com (4.1/SMI-4.0) id AA11351; Fri, 14 Aug 92 08:58:00 PDT Date: Fri, 14 Aug 92 08:58:00 PDT From: casim@jade.rdd.lmsc.lockheed.com (CASIM Account) Message-Id: <9208141558.AA11351@jade.rdd.lmsc.lockheed.com> To: clim@bbn.com Subject: draw-arrow and answer I tried the draw-arrow routine on Allegro 4.1 Clim 1.1 and it does not work.. B. Leigh Lockheed Missiles.... Palo Alto, Ca   Received: from BBN.COM by LABS-N.BBN.COM id ab15568; 14 Aug 92 12:56 EDT Received: from chesapeake.ads.com by BBN.COM id aa26172; 14 Aug 92 12:51 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA11120; Fri, 14 Aug 92 12:53:25 EDT Date: Fri, 14 Aug 92 12:53:25 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9208141653.AA11120@chesapeake.ads.com> To: casim@jade.rdd.lmsc.lockheed.com Cc: clim@bbn.com In-Reply-To: CASIM Account's message of Fri, 14 Aug 92 08:58:00 PDT <9208141558.AA11351@jade.rdd.lmsc.lockheed.com> Subject: Re: draw-arrow and answer Reply-To: jclose@ads.com Date: Fri, 14 Aug 92 08:58:00 PDT From: CASIM Account I tried the draw-arrow routine on Allegro 4.1 Clim 1.1 and it does not work.. B. Leigh It had one bug on my machine. I'll mail you the fixed version with one other modification I made. Jeffrey   Received: from BBN.COM by LABS-N.BBN.COM id aa10152; 17 Aug 92 6:15 EDT Received: from ifi.informatik.uni-stuttgart.de by BBN.COM id aa11279; 17 Aug 92 6:01 EDT Received: from is.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Mon, 17 Aug 92 11:58:08 +0200 From: Peter Forster Date: Mon, 17 Aug 92 11:59:10 +0200 Message-Id: <9208170959.AA04411@is.informatik.uni-stuttgart.de> Received: by is.informatik.uni-stuttgart.de; Mon, 17 Aug 92 11:59:10 +0200 To: clim@bbn.com Subject: CLIM-MCL(final) Date: Fri, 14 Aug 1992 15:49:17 -0500 From: bill@cambridge.apple.com (Bill St. Clair) >>There is a fully functional demo version of CLIM 1.0 (binaries) >>on the MCL 2.0 CD-ROM - maybe this will be helpful in the interim. > >Sadly ;-) this is a true demo version and not fully functional. >These guys want to sell CLIM. Macros like DEFINE-APPLICATION-FRAME >or DEFINE-PRESENTATION-METHOD are not working. You might try asking about CLIM for MCL 2.0 on the main CLIM mailing list: clim@bbn.com When is a new CLIM upgrade for MCL(final) available? The delivery strategy for CLIM is confusing - the MCL documentation contains a reference to Lucid - I have bought CLIM from ILA and think that ILA has to deliver the upgrade. Peter _____________________________________________________________________________ Peter Forster forster@informatik.uni-stuttgart.de Institut fuer Informatik Universitaet Stuttgart Breitwiesenstr. 20/22 Tel.: (+49 711) 7816-435 D - 7000 Stuttgart 80 FAX : (+49 711) 780 1045 ______________________________________________________________________________   Received: from BBN.COM by LABS-N.BBN.COM id ab11190; 17 Aug 92 7:19 EDT Received: from mcsun.EU.net by BBN.COM id aa12668; 17 Aug 92 7:12 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA14371 (5.65b/CWI-2.173); Mon, 17 Aug 1992 13:11:58 +0200 Received: from nrb.UUCP by ub4b.buug.be (5.65c/ub4b_02) id AA25956; Mon, 17 Aug 1992 13:11:59 +0200 Received: from nrbmi1.ia.nrb.be by scosysv.nrb.be with SMTP (5.59/NRB25-f-eef-ev@nrb) id AA07133; Mon, 17 Aug 92 18:26:18 +0100 Date: Mon, 17 Aug 1992 12:16+0200 From: Vincent Keunen Reply-To: nrb!keunen@relay.EU.net Subject: Re: FAQ: Lisp Frequently Asked Questions 1/5 [Monthly posting] To: barmar@Think.COM Cc: clim@nrbmi2.ia.nrb.be, york@lucid.com, doughty@ileaf.com In-Reply-To: <9208140802.AA05828@gandalf.think.com> Message-Id: <19920817101633.8.KEUNEN@nrbmi1.ia.nrb.be> Date: Fri, 14 Aug 1992 10:02+0200 From: Barry Margolin The entry on MCL needs to be updated. At AAAI and LUV-92, Lucid announced that they have entered an agreement to distribute MCL 2.0, although APDA will also still sell it. And Lucid, not ILA, is now the exclusive source of CLIM for MCL. -- Barry Margolin System Manager, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar How about the clim mailing list at bbn.com? Is it still the right place to ask technical questions about clim? Vincent =============================================================== Keunen Vincent Network Research Belgium R&D, Software Engineer Parc Industriel des Hauts-Sarts keunen@nrb.be 2e Avenue, 65 tel: +32 41 407282 B-4040 Herstal fax: +32 41 481170 BELGIUM ===============================================================   Received: from BBN.COM by LABS-N.BBN.COM id aa14971; 17 Aug 92 12:25 EDT Received: from mcsun.EU.net by BBN.COM id aa00815; 17 Aug 92 12:11 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA26423 (5.65b/CWI-2.173); Mon, 17 Aug 1992 18:11:31 +0200 Received: from nrb.UUCP by ub4b.buug.be (5.65c/ub4b_02) id AA06243; Mon, 17 Aug 1992 18:11:33 +0200 Received: from nrbmi1.ia.nrb.be by scosysv.nrb.be with SMTP (5.59/NRB25-f-eef-ev@nrb) id AA07587; Mon, 17 Aug 92 23:20:58 +0100 Received: from scosysv.nrb.be by nrbmi1.ia.nrb.be via INTERNET with SMTP id 10737; 17 Aug 1992 17:11:19+0200 Received: from Think.COM by scosysv.nrb.be with UUCP (5.59/NRB25-f-eef-ev@nrb) id AA07581; Mon, 17 Aug 92 23:20:54 +0100 Received: from Mail.Think.COM by ub4b.buug.be (5.65c/ub4b_02) id AA03941; Mon, 17 Aug 1992 17:19:37 +0200 Return-Path: Received: from Think.COM by mail.think.com; Mon, 17 Aug 92 11:18:40 -0400 Received: from OCCAM.THINK.COM by Early-Bird.Think.COM; Mon, 17 Aug 92 11:18:37 EDT Date: Mon, 17 Aug 1992 11:18-0400 From: Barry Margolin Subject: Re: FAQ: Lisp Frequently Asked Questions 1/5 [Monthly posting] To: keunen!nrbmi1.ia.nrb.be:barmar@Think.COM Cc: clim@nrbmi2.ia.nrb.be, york@lucid.com, doughty@ileaf.com In-Reply-To: <19920817101633.8.KEUNEN@nrbmi1.ia.nrb.be> Message-Id: <19920817151829.9.BARMAR@occam.think.com> Date: Mon, 17 Aug 1992 06:16 EDT From: Vincent Keunen Date: Fri, 14 Aug 1992 10:02+0200 From: Barry Margolin The entry on MCL needs to be updated. At AAAI and LUV-92, Lucid announced that they have entered an agreement to distribute MCL 2.0, although APDA will also still sell it. And Lucid, not ILA, is now the exclusive source of CLIM for MCL. How about the clim mailing list at bbn.com? Is it still the right place to ask technical questions about clim? I can't think of any reason why that would have changed as a result of the above marketing changes. The mailing list is run by and for users. barmar   Received: from BBN.COM by LABS-N.BBN.COM id aa22262; 17 Aug 92 22:50 EDT Received: from lucid.com by BBN.COM id aa27889; 17 Aug 92 22:42 EDT Received: from oakland-hills.lucid ([192.31.212.153]) by heavens-gate.lucid.com id AA05889g; Mon, 17 Aug 92 16:56:36 PDT Received: by oakland-hills.lucid (4.1/SMI-4.1) id AA02917; Mon, 17 Aug 92 17:02:32 PDT Date: Mon, 17 Aug 92 17:02:32 PDT From: york%oakland-hills@lucid.com (Bill York) Message-Id: <9208180002.AA02917@oakland-hills.lucid> To: Forster@informatik.uni-stuttgart.de Cc: clim@BBN.COM In-Reply-To: Peter Forster's message of Mon, 17 Aug 92 11:59:10 +0200 <9208170959.AA04411@is.informatik.uni-stuttgart.de> Subject: CLIM-MCL(final) Reply-To: York@lucid.com From: Peter Forster Date: Mon, 17 Aug 92 11:59:10 +0200 Date: Fri, 14 Aug 1992 15:49:17 -0500 From: bill@cambridge.apple.com (Bill St. Clair) >>There is a fully functional demo version of CLIM 1.0 (binaries) >>on the MCL 2.0 CD-ROM - maybe this will be helpful in the interim. > >Sadly ;-) this is a true demo version and not fully functional. >These guys want to sell CLIM. Macros like DEFINE-APPLICATION-FRAME >or DEFINE-PRESENTATION-METHOD are not working. You might try asking about CLIM for MCL 2.0 on the main CLIM mailing list: clim@bbn.com When is a new CLIM upgrade for MCL(final) available? The delivery strategy for CLIM is confusing - the MCL documentation contains a reference to Lucid - I have bought CLIM from ILA and think that ILA has to deliver the upgrade. I am forwarding a message that was recently sent to Info-MCL regarding the status of CLIM for the Mac. ---------------- begin forward ---------------- From: doughty@daffy-duck.HQ.Ileaf.COM (Dennis Doughty) Subject: CLIM-MCL(final) Date: 15 Aug 92 17:20:46 GMT Original-To: Forster@informatik.uni-stuttgart.de (Peter Forster) Original-Cc: info-mcl@cambridge.apple.com Date: 13 Aug 92 14:35:06 GMT From: Forster@informatik.uni-stuttgart.de (Peter Forster) A half year ago we got CLIM 1.0 from ILA for our MAC. This week we installed the MAC 2.0 (final version) and recognize that CLIM 1.0 could not be installed with MAC 2.0, because the binary type of the clim files is different of the binary type of MAC 2.0 (final version). Where can we get the new CLIM upgrade for MCL 2.0? Bill York and I (the original MCL CLIM developers) have acquired the MCL CLIM product from ILA. Under the name Illudium Software, we will continue to develop and distribute MCL CLIM. Our first task is the completion of MCL CLIM 1.1 for MCL 2.0 final, which we expect to deliver shortly (this means a small integer number of weeks, not months). MCL CLIM 1.1 will be equivalent to the CLIM 1.1 available from Symbolics, Lucid, and Franz for their platforms. Once MCL CLIM 1.1 is shipping, we will turn our attentions to MCL CLIM 2.0, in conjunction with the CLIM 2.0 efforts of the other vendors. If you have any other questions, or would like to place an order for MCL CLIM, please contact me or Bill via direct email or by phone. We're having some email distribution problems (isn't that always how it is?), so for the near term you can reach us at: Dennis Doughty: doughty@ileaf.com Bill York: york@lucid.com or you may call us at 1-415-968-3656. -- Dennis Doughty ---------------- end forward ---------------- In addition, we are currently pursuing an arrangement under which Lucid will assume distribution and support for the MCL CLIM product(s). (In case you didn't know, Lucid will soon begin distribution and support of MCL 2.0 itself, so the addition of MCL CLIM seemed like a natural.)   Received: from BBN.COM by LABS-N.BBN.COM id aa00855; 18 Aug 92 12:42 EDT Received: from aerospace.aero.org by BBN.COM id aa09388; 18 Aug 92 10:03 EDT Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT) id AA22488 for clim@bbn.com; Tue, 18 Aug 1992 07:03:27 -0700 Posted-Date: Tue, 18 Aug 92 07:03:25 PDT Message-Id: <199208181403.AA22488@aerospace.aero.org> Received: from reify.aero.org by antares.aero.org (4.1/AMS-1.0) id AA01202 for clim@bbn.com; Tue, 18 Aug 92 07:03:25 PDT Date: Tue, 18 Aug 92 07:03:25 PDT From: abbott@aero.org To: clim@bbn.com Subject: File change as gesture I'd like to have my program activated not only when the user performs a gesture but also when a file changes. In effect, I'd like a change to a file to function as a gesture. Is there a way to do that in CLIM? -- Russ Abbott   Received: from BBN.COM by LABS-N.BBN.COM id aa00880; 18 Aug 92 12:43 EDT Received: from chesapeake.ads.com by BBN.COM id aa16416; 18 Aug 92 12:16 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA25546; Tue, 18 Aug 92 12:19:10 EDT Date: Tue, 18 Aug 92 12:19:10 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9208181619.AA25546@chesapeake.ads.com> To: jclose@ads.com Cc: clim@bbn.com In-Reply-To: Jeff Close's message of Tue, 18 Aug 92 11:42:18 EDT <9208181542.AA25171@chesapeake.ads.com> Subject: Re: Nested accepting-values, and ANOTHER question Reply-To: jclose@ads.com Also while I'm on it, is there a way to control text styles within the "own-window" of accepting-values without creating a new accept-window flavor -- whoops, class? Thanks more, lots, Jeff   Received: from BBN.COM by LABS-N.BBN.COM id aa00357; 18 Aug 92 11:54 EDT Received: from chesapeake.ads.com by BBN.COM id aa14534; 18 Aug 92 11:39 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA25171; Tue, 18 Aug 92 11:42:18 EDT Date: Tue, 18 Aug 92 11:42:18 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9208181542.AA25171@chesapeake.ads.com> To: clim@bbn.com Subject: Nested accepting-values Reply-To: jclose@ads.com greetings, I posted this awhile back and got no response, but we were having mail problems, so I'll try again. I've done this a thousand times in DW but it was too long ago: I'm trying to get several nested accepting-values to work so that when I hit a on an inner accept, it doesn't interpret it as terminating the outer one. I'd appreciate any suggestions. jeffrey   Received: from BBN.COM by LABS-N.BBN.COM id ab01946; 18 Aug 92 14:12 EDT Received: from lucid.com by BBN.COM id aa25530; 18 Aug 92 13:59 EDT Received: from oakland-hills.lucid ([192.31.212.153]) by heavens-gate.lucid.com id AA07581g; Tue, 18 Aug 92 10:48:49 PDT Received: by oakland-hills.lucid (4.1/SMI-4.1) id AA03298; Tue, 18 Aug 92 10:54:44 PDT Date: Tue, 18 Aug 92 10:54:44 PDT From: york%oakland-hills@lucid.com (Bill York) Message-Id: <9208181754.AA03298@oakland-hills.lucid> To: jclose@ads.com Cc: clim@BBN.COM In-Reply-To: Jeff Close's message of Tue, 18 Aug 92 11:42:18 EDT <9208181542.AA25171@chesapeake.ads.com> Subject: Nested accepting-values Reply-To: York@lucid.com Date: Tue, 18 Aug 92 11:42:18 EDT From: Jeff Close Reply-To: jclose@ads.com I've done this a thousand times in DW but it was too long ago: I'm trying to get several nested accepting-values to work so that when I hit a on an inner accept, it doesn't interpret it as terminating the outer one. Do you really mean nested ACCEPTING-VALUES calls, or nested calls to ACCEPT? For example, do you have a presentation type parser that calls ACCEPT recursively on another type? If so, you should probably use WITH-ACTIVATION-CHARACTERS (with the :OVERRIDE option) around the inner call to ACCEPT to remove Newline and/or Return from the activation list. You then may also have to use WITH-BLIP-CHARACTERS to add Newline back as a delimiter. Sorry I'm not being very specific. I don't have time to test this out right now. If you have a simple code example of the nested calling that you are trying to do, send it along and I'll look at it.   Received: from BBN.COM by LABS-N.BBN.COM id aa05206; 18 Aug 92 18:16 EDT Received: from chesapeake.ads.com by BBN.COM id aa08844; 18 Aug 92 18:10 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA29351; Tue, 18 Aug 92 18:12:41 EDT Date: Tue, 18 Aug 92 18:12:41 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9208182212.AA29351@chesapeake.ads.com> To: York@lucid.com Cc: clim@bbn.com In-Reply-To: Bill York's message of Tue, 18 Aug 92 10:54:44 PDT <9208181754.AA03298@oakland-hills.lucid> Subject: Re: Nested accepting-values Reply-To: jclose@ads.com Do you really mean nested ACCEPTING-VALUES calls, or nested calls to ACCEPT? For example, do you have a presentation type parser that calls ACCEPT recursively on another type? If so, you should probably use WITH-ACTIVATION-CHARACTERS (with the :OVERRIDE option) around the inner call to ACCEPT to remove Newline and/or Return from the activation list. You then may also have to use WITH-BLIP-CHARACTERS to add Newline back as a delimiter. ... Bill, Thanks for the response. What I need is the best way to define an accept for a structure (instance) with several fields, then use that accept within another similar accept call. E.g.: Accept for type X includes several accept calls -- need those be sequential accepts within the accept method for X, could they be in an accepting-values? -- anyways, I then want to define an accept for type Y that includes multiple accepts of type X. Is this specific enough? If not, I'll send you some code. Jeffrey   Received: from BBN.COM by LABS-N.bbn.COM id aa11371; 19 Aug 92 5:10 EDT Received: from iraun1.ira.uka.de by BBN.COM id aa19107; 19 Aug 92 4:51 EDT Received: from gate.fzi.de by iraun1.ira.uka.de with SMTP (PP) id <29356-0@iraun1.ira.uka.de>; Wed, 19 Aug 1992 10:49:58 +0200 Received: from negro.fzi.de by gate.fzi.de.fzi.de id aa04391; 19 Aug 92 8:52 GMT Received: by negro (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA00380; Wed, 19 Aug 92 10:49:53 GMT+0100 Date: Wed, 19 Aug 92 10:49:53 GMT+0100 From: Bernd Wild Message-Id: <9208190949.AA00380@negro> Original-Received: by NeXT Mailer (1.63) PP-warning: Illegal Received field on preceding line To: clim@bbn.com Subject: Problem to print from one application into other applications Hi, I want print inside one application into a window of another application. If I send an output to a window of the other application, the output is shown on this window correctly but the receiving application dies at this moment (i.e. no further mouse-interactions are possible). Is there any trick to restart the application or to allow such output operations. Details: - Symbolics Ivory, Genera 8.1, CLIM 1.1. - Every application has its own root-window because all of them have to be active simultaneously. - my function (define-command test (com-test :menu test) () (let ((output *standard-output*)) (setf output (get-frame-pane *another-application* 'output-window)) (describe xyz) (setf *standard-output* output))) Bernd Wild =============================================== Bernd Wild Forschungszentrum Informatik FZI Dept. Technical Expert Systems and Robotics Haid-und-Neu-Strasse 10-14 D-7500 Karlsruhe GERMANY Tel: +49-721-9654-310 Fax: +49-721-9654-309 email: bwild@fzi.de ===============================================   Received: from BBN.COM by LABS-N.bbn.COM id aa16114; 19 Aug 92 11:41 EDT Received: from aplcen.apl.jhu.edu by BBN.COM id aa03936; 19 Aug 92 11:25 EDT Received: by aplcen.apl.jhu.edu (5.57/Ultrix2.4-XDccg) id AA10328; Wed, 19 Aug 92 11:25:46 -0400 Date: Wed, 19 Aug 92 11:25:46 -0400 From: lien@aplcen.apl.jhu.edu (Duong lien t) Message-Id: <9208191525.AA10328@aplcen.apl.jhu.edu> X-Mailer: Mail User's Shell (6.1 4/26/88) To: clim@bbn.com Subject: remove existing colors I use MAKE-COLOR-RGB to make new colors, but I exceed the color limit. How do I remove existing colors so I can create a new one? thanks.   Received: from BBN.COM by LABS-N.BBN.COM id aa21953; 19 Aug 92 20:47 EDT Received: from lucid.com by BBN.COM id ac27592; 19 Aug 92 20:43 EDT Received: from oakland-hills.lucid ([192.31.212.153]) by heavens-gate.lucid.com id AA12389g; Wed, 19 Aug 92 17:33:01 PDT Received: by oakland-hills.lucid (4.1/SMI-4.1) id AA05020; Wed, 19 Aug 92 17:38:58 PDT Date: Wed, 19 Aug 92 17:38:58 PDT From: york%oakland-hills@lucid.com (Bill York) Message-Id: <9208200038.AA05020@oakland-hills.lucid> To: jclose@ads.com Cc: clim@bbn.com In-Reply-To: Jeff Close's message of Tue, 18 Aug 92 18:12:41 EDT <9208182212.AA29351@chesapeake.ads.com> Subject: Nested accepting-values Reply-To: York@lucid.com Date: Tue, 18 Aug 92 18:12:41 EDT From: jclose@chesapeake.ads.com (Jeff Close) Reply-To: jclose@ads.com Do you really mean nested ACCEPTING-VALUES calls, or nested calls to ACCEPT? Thanks for the response. What I need is the best way to define an accept for a structure (instance) with several fields, then use that accept within another similar accept call. E.g.: Accept for type X includes several accept calls -- need those be sequential accepts within the accept method for X, could they be in an accepting-values? -- anyways, I then want to define an accept for type Y that includes multiple accepts of type X. Is this specific enough? If not, I'll send you some code. Here is some sample code that may do what you want. It defines a presentation type called TICKET. The ACCEPT method has two recursive calls to ACCEPT, one to read a president name and another for the vice-president. There are two versions of the ACCEPT method (you will have to incrementally compile the one you want to contrast them). The first reads the two names separated by a comma on the same line. The second reads the two names on separate lines, delimited by Return. They both do completion within the field. That is, if you do (accept 'ticket :stream win) with the first ACCEPT method, and type "Bu,Qu" the screen appearance will be "Bush,Quayle" and the return value will be (BUSH QUAYLE). If you use the second ACCEPT method and type "Cl Go " The window will contain "Clinton Gore" and the return value will be (CLINTON GORE). This example also demonstrates simple cross-field constraints by insisting that the two candidates be of the same party. For key implementation details, read the comments in the code. (in-package :clim-user) (define-presentation-type ticket ()) (setf (get 'bush 'party) 'republican) (setf (get 'quayle 'party) 'republican) (setf (get 'clinton 'party) 'democrat) (setf (get 'gore 'party) 'democrat) ;;; separated by comma version (define-presentation-method accept ((type ticket) stream view &key &allow-other-keys) (declare (ignore view)) (let ((president (accept '(member bush clinton) :stream stream :prompt nil ;; add comma as a completing delimiter :blip-characters '(#\,)))) ;; Make sure that they names were separated by comma (unless (eql (read-gesture :stream stream) #\,) (simple-parse-error "Ticket members must be separated by commas")) (let ((veep (accept '(member quayle gore) :stream stream :prompt nil))) ;; Validate party affiliations (unless (eql (get president 'party) (get veep 'party)) (simple-parse-error "Ticket members must be of the same party")) (list president veep)))) ;;; Separated by Return version (define-presentation-method accept ((type ticket) stream view &key &allow-other-keys) (declare (ignore view)) (let ((president (accept '(member bush clinton) :stream stream :prompt nil ;; Remove Newline from activation characters ;; (can't say NIL here due to stupid bug, so pick some ;; character we aren't likely to type) :activation-characters `(~) ;; Add Newline as a delimiter, so that we get completion ;; and move-to-next-field behavior when Return is typed. :blip-characters `(#\Return #\Newline)))) (unless (eql (read-gesture :stream stream) #\Newline) (simple-parse-error "Ticket members must be entered on separate lines ")) (let ((veep (accept '(member quayle gore) :stream stream :prompt nil))) ;; Validate party affiliations (unless (eql (get president 'party) (get veep 'party)) (simple-parse-error "Ticket members must be of the same party")) (list president veep))))   Received: from BBN.COM by LABS-N.bbn.COM id aa29528; 20 Aug 92 11:04 EDT Received: from chesapeake.ads.com by BBN.COM id aa17096; 20 Aug 92 10:48 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA22065; Thu, 20 Aug 92 10:50:52 EDT Date: Thu, 20 Aug 92 10:50:52 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9208201450.AA22065@chesapeake.ads.com> To: York@lucid.com Cc: clim@bbn.com In-Reply-To: Bill York's message of Wed, 19 Aug 92 17:38:58 PDT <9208200038.AA05020@oakland-hills.lucid> Subject: Re: Nested accepting-values Reply-To: jclose@ads.com (Nota Bene: For anyone who didn't read my previous question -- this regards nested accept calls. I'm posting this for the benefit of those who weren't aware of what, to me, was a crucial discovery.) AHAAAA! The key is that :activation-characters cannot be NIL! I was trying to determine what the difference was between some of the things I've tried and some things I was sent. Some of them were very close to what I'd already tried. Thanks much for the suggestions. Jeffrey   Received: from BBN.COM by LABS-N.bbn.COM id aa01409; 20 Aug 92 13:03 EDT Received: from crdgw1.GE.COM by BBN.COM id aa22593; 20 Aug 92 12:55 EDT Received: by crdgw1.ge.com (5.57/GE 1.141) id AA17960; Thu, 20 Aug 92 12:40:30 EDT Received: from procyon.crd.Ge.Com by sol.crd.Ge.Com (4.0/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA22921; Thu, 20 Aug 92 12:40:17 EDT Date: Thu, 20 Aug 92 12:40:17 EDT From: halvers@sol.crd.ge.com (peter c halverson) Message-Id: <9208201640.AA22921@sol.crd.Ge.Com> Received: by procyon.crd.Ge.Com (4.1/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA07520; Thu, 20 Aug 92 12:40:09 EDT To: clim@bbn.com Subject: Repairing damaged application panes Reply-To: Pete Halverson Organization: GE Corporate R&D Center, Schenectady NY Sun-Distance: 151336430 kilometers (1.012 AU) Context: CLIM 1.1, Allegro on a Sparc 2, openwin2.0, olwm We've got an application frame with several graphics panes whose :RECORD-P and :INCREMENTAL-REDISPLAY are both NIL (since the overhead in going through output recording is currently soooooo slow that it's actually faster to redraw everything every refresh cycle). Unfortunately, when the application frame is obscured or iconified and subsequently re-exposed, these panes are not refreshed correctly. Similar problems also result from changing configurations---panes are not always redrawn in the new configuration. So, does anyone know why my display-function isn't being called as part of the exposure event handling, or what the appropriate approach should be? pete halverson p.s. As a quick hack, I tried setf'ing XLIB:WINDOW-BACKING-STORE of the frame's XLIB window to :ALWAYS before mapping, but to no avail. It wouldn't have been a robust fix anyway, since it's only a suggested optimization.   Received: from BBN.COM by LABS-N.bbn.COM id aa03424; 20 Aug 92 16:23 EDT Received: from chesapeake.ads.com by BBN.COM id aa03949; 20 Aug 92 16:13 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA25747; Thu, 20 Aug 92 16:16:13 EDT Date: Thu, 20 Aug 92 16:16:13 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9208202016.AA25747@chesapeake.ads.com> To: coulman@skdad.usask.ca Cc: clim@bbn.com In-Reply-To: Randy Coulman's message of Thu, 20 Aug 92 13:23:09 CST <9208201923.AA25639@skdad.USask.ca> Subject: Re: Minor bounding box problem Reply-To: jclose@ads.com problem is that when they are highlighted, the box that surrounds the node is at least one pixel too low. This is a minor detail. However, when the node is erased, part of the ellipse remains on the display, because it is outside the bounding box. The bounding box should run tangent to the ellipse, but actually cuts through it on my display. Is this a known problem? Does it have an easy fix? BTW, I'm running Allegro Thanks, Randy Randy- This is a known problem. As far as I know it has nothing to do with defining your own border. It's a "1+" problem. I don't know if I have the source code to the patch -- I have a fasl -- anyone else? Jeff   Received: from BBN.COM by LABS-N.bbn.COM id aa03051; 20 Aug 92 15:47 EDT Received: from sask.usask.ca by BBN.COM id aa29921; 20 Aug 92 15:23 EDT Received: from access.USask.Ca by SASK.USask.CA (PMDF #12333) id <01GNT14P9DVK0031Y3@SASK.USask.CA>; Thu, 20 Aug 1992 13:26 CST Received: by access.USask.Ca (5.57/GLH-1.0); Thu, 20 Aug 92 13:23:15 -0600 id AA02417 for clim@bbn.com Received: from skaries.USask.ca by skdad.USask.ca (4.1/SMI-4.1) id AA25639; Thu, 20 Aug 92 13:23:11 CST Date: Thu, 20 Aug 92 13:23:09 CST From: coulman@skdad.usask.ca (Randy Coulman) Subject: Minor bounding box problem To: clim@bbn.com (Clim Users Mailing List) Message-id: <9208201923.AA25639@skdad.USask.ca> X-Envelope-to: clim@bbn.com X-Mailer: ELM [version 2.3 PL11] I have defined a new border type with the following: (clim:define-border-type :ellipse (stream left top right bottom) (let ((cx (/ (+ left right) 2)) (cy (/ (+ top bottom) 2)) (rx (+ 8 (/ (- right left) 2))) (ry (+ 8 (/ (- bottom top) 2))) ) (clim:draw-ellipse* stream cx cy rx 0 0 ry :filled nil)) ) I use this border type to draw some nodes in a graph (using surrounding-output-with-border). These nodes are later selectable. The problem is that when they are highlighted, the box that surrounds the node is at least one pixel too low. This is a minor detail. However, when the node is erased, part of the ellipse remains on the display, because it is outside the bounding box. The bounding box should run tangent to the ellipse, but actually cuts through it on my display. Is this a known problem? Does it have an easy fix? BTW, I'm running Allegro CLIM 1.1 on a Sparc 1+. Thanks, Randy -- Randy A. Coulman | ARIES Laboratory | Department of Computational Science coulman@cs.Usask.ca | University of Saskatchewan | Saskatoon, SK S7N 0W0   Received: from BBN.COM by LABS-N.BBN.COM id aa12520; 21 Aug 92 11:11 EDT Received: from chesapeake.ads.com by BBN.COM id aa04749; 21 Aug 92 10:44 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA06309; Fri, 21 Aug 92 10:47:31 EDT Date: Fri, 21 Aug 92 10:47:31 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9208211447.AA06309@chesapeake.ads.com> To: clim@bbn.com Subject: Anyone know George@boeing.com? Reply-To: jclose@ads.com I'm trying to mail to George at atc.boeing.com. I'm not sure of his address, and also we don't have boeing in our hosts file. Anyone know an IP number for them? Jeff   Received: from BBN.COM by LABS-N.BBN.COM id aa13236; 21 Aug 92 12:20 EDT Received: from mwunix.mitre.org by BBN.COM id aa09150; 21 Aug 92 12:11 EDT Return-Path: Received: from starbase.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA14933; Fri, 21 Aug 92 12:09:18 -0400 Received: by starbase.mitre.org (4.1/SMI-4.1) id AA25039; Fri, 21 Aug 92 12:02:58 EDT Date: Fri, 21 Aug 92 12:02:58 EDT From: duff@starbase.MITRE.ORG (David A. Duff) Message-Id: <9208211602.AA25039@starbase.mitre.org> To: jclose@ads.com Cc: clim@BBN.COM In-Reply-To: <9208211447.AA06309@chesapeake.ads.com> (message from Jeff Close on Fri, 21 Aug 92 10:47:31 EDT) Subject: Anyone know George@boeing.com? Reply-To: duff@mitre.org 130.42.28.80 atc.boeing.com   Received: from BBN.COM by LABS-N.BBN.COM id ac15468; 21 Aug 92 15:21 EDT Received: from Mail.Think.COM by BBN.COM id aa19070; 21 Aug 92 15:15 EDT Return-Path: Received: from Think.COM by mail.think.com; Fri, 21 Aug 92 15:15:19 -0400 Received: from OCCAM.THINK.COM by Early-Bird.Think.COM; Fri, 21 Aug 92 15:15:13 EDT Date: Fri, 21 Aug 1992 15:15-0400 From: Barry Margolin Subject: Common Lisp is a dpANS in Public Review! To: clim@bbn.com Supersedes: <19920819195218.5.BARMAR@occam.think.com> Message-Id: <19920821191503.9.BARMAR@occam.think.com> My apologies to those of you who are getting lots of copies of this (both from me and Kent Pitman). I wanted to make sure that it reaches all the people to whom it should be relevant, and there's naturally quite a bit of overlap. Common Lisp is now a draft proposed American National Standard (dpANS) and is in a period of public review that extends until November 23, 1992. It's -not- an ANSI standard yet, but this is a major milestone in the standardization process. A press release from X3 containing further details, including ordering information, follows at the end of this message. Although review comments are not required to be in any particular form, we plan to publish a template which people can voluntarily comply with if they have comments to make. Information about that template will be distributed soon over this same communication channel. This message is a broadcast distribution to a very large number of recipients. PLEASE DO NOT REPLY TO THE FULL RECIPIENT LIST. If you have questions, please direct them to a smaller audience. ==================== Accredited Standards Committee (*) X3, Information Processing Systems Doc No.: X3/92-1710-X S Date: July 23, 1992 Proj. No.: 574-D Reply To: Lynn Barra (202) 626-5738 NEWS RELEASE X3 ANNOUNCES THE PUBLIC REVIEW AND COMMENT PERIOD ON X3.226-199X, PROGRAMMING LANGUAGE COMMON LISP Washington, D.C.--Accredited Standards Committee X3, Information Processing Systems announces the four-month public review and comment period on X3.226, 199x, Programming Language Common Lisp. THE COMMENT PERIOD EXTENDS FROM JULY 24, 1992 THROUGH NOVEMBER 23, 1992. The specification set forth in this document is designed to promote the portability of Common Lisp programs among a variety of data processing systems. It is a language specification aimed at an audience of implementors and knowledgeable programmers. It is neither a tutorial nor an implementation guide. The X3 Secretariat is investigating the possibility of making these files available in electronic format, on disk as well as on CompuServe. If you have a need for either or both, please contact Dan Arnold at (202) 626-5747 (email address from CompuServe "75300,2354" or if from Internet or another source: "75300.2354@compuserve.com"). THE COMMENT PERIOD ENDS ON NOVEMBER 23, 1992. Public review comments must be submitted (to this office and ANSI) in hard copy format. Please send all comments to: X3 Secretariat, Attn.: Lynn Barra, 1250 Eye Street NW, Suite 200, Washington, DC 20005-3922. Send a copy to: American National Standards Institute, Attn: BSR Center, 11 West 42nd St. 13th Floor, New York, NY 10036. Purchase this standard in hard copy from: Global Engineering Documents, Inc. 2805 McGaw Ave Irvine, CA 92714 1-800-854-7179 (within USA) 714-261-1455 (outside USA) Single Copy Price: $80.00 International Price: $104.00 # # # # # (*) Operating under the procedures of the American National Standards Institute X3 Secretariat, Computer and Business Equipment Manufacturer's Association (CBEMA) 1250 Eye Street NW Suite 200 Washington DC 20005-3922 Telephone: (202) 737-8888 (Press 1 twice) FAX: (202) 638-4922   Received: from BBN.COM by LABS-N.BBN.COM id aa25823; 22 Aug 92 14:58 EDT Received: from Mail.Think.COM by BBN.COM id aa16962; 22 Aug 92 14:54 EDT Return-Path: Received: from Gandalf.Think.COM by mail.think.com; Sat, 22 Aug 92 14:53:55 -0400 From: Barry Margolin Received: by gandalf.think.com (4.1/Think-1.2) id AA08871; Sat, 22 Aug 92 14:53:55 EDT Date: Sat, 22 Aug 92 14:53:55 EDT Message-Id: <9208221853.AA08871@gandalf.think.com> To: info-mcl@cambridge.apple.com, allegro-cl@ucbvax.berkeley.edu, clim@bbn.com, kcl@cli.com, lispworks@harlqn.co.uk, lucites@mailbox.src.cs.cmu.edu Subject: [KMP@STONY-BROOK.SCRC.Symbolics.COM: Details of online access to dpANS Common Lisp spec] As with the previous announcement of the public review status of dpANS Common Lisp, this message is being sent to a very wide audience. Please don't reply to all the recipients. Date: Sat, 22 Aug 1992 02:11-0400 From: Kent M Pitman Subject: Details of online access to dpANS Common Lisp spec To: Common-Lisp@ai.sri.com Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM The administrative issues are now resolved and the dpANS Common Lisp spec is now accessible online by anonymous ftp. How to Obtain Your Copy The files are on the machine named BETA.XEROX.COM in "/pub/cl/document/*", and can be retrieved by anonymous ftp. You may or may not want all of these files. The file Reviewer-Notes.text in that directory contains IMPORTANT INFORMATION that EVERYONE should read BEFORE ftp'ing the other files, especially since the document is quite large and the information contained in Reviewer-Notes.text might cause you to realize you only need a subset of the other files. Among other things, it tells you - The nature of the files in the directory. - What the formal status of these files is. - Important caveats for those who choose to go with online rather than hardcopy access. - How to make Public Review comments. - Who to contact with administrative questions. Background Information about the Administrative Issues Numerous people have inquired about why there were delays in announcing the FTP address for this data. It was suggested by some that it was an economic issue (e.g., that CBEMA receives royalties on the hardcopy sold by Global Engineering Documents, Inc.). I have been in direct discussion with the people at X3 and they tell me that it is true that they do receive such royalties, but they were basically willing to overlook that issue in order to satisfy our needs. The real reasons for the delay were the following, which I consider quite legitimate and was glad to see being addressed: - There was an issue of making sure that people understood which sources of data are reliable. Standards bodies make their living on being a standard source of information, and that is somewhat at odds with the fact that data can be modified (both accidentally and deliberately) as it moves about the net. They were not concerned with suppressing access; rather, they were concerned that people who had access should understand the difference between getting random bits off of the net and getting a known-to-be-official copy. - The normal procedure for standards is that if you order a standard (in hardcopy) or you make a review comment, then you are automatically registered to receive future notifications about the progress of that standard--in particular, whether there are future public review periods. Anonymous online access by its nature doesn't provide for registering yourself, so people getting online access need to know they won't be provided with this service. After discussing these matters with the X3 folks, we've arrived at what we think is a proper compromise, which is to just make full disclosure of these caveats and let people decide what's the best solution for themselves. The disclosure information is in the file Reviewer-Notes.text mentioned above, so you can see that file for further details. The people I spoke to at X3 mentioned that this is their first experiment with this issue of online access and they were somewhat unprepared to deal with the onslaught of requests they received. It's a learning experience for them, and I've been quite impressed with the way they've been handling it thus far. They do have a lot to learn, but compared to a lot of bureaucracies I've seen, I think they're being remarkably open minded in the ways they're looking at things. Their primary concerns have not been blind adherence to established policies for policy's sake, but rather thoughtful concern about principles of fairness and quality--the things a good standards organization should be about. So if you have interactions with them, please show proper amounts of patience, courtesy, and thanks for the professionalism and hard work they've put in to cut through a lot of red tape for us in a very short time. After all, we want online access to happen increasingly in the future, and one way to help assure that is to try where possible to make it a pleasant experience for them. Note that they are still not prepared to handle e-mail public comments and want all Public Review comments in hardcopy. I know they have additional legitimate concerns relating to use of e-mail for Public Review and I strongly suggest we leave that entire issue alone for this round, and let them cope with that as a separate experiment another time in the future. Happy reviewing. -kmp   Received: from BBN.COM by LABS-N.BBN.COM id aa27898; 22 Aug 92 23:48 EDT Received: from sask.usask.ca by BBN.COM id aa00276; 22 Aug 92 23:45 EDT Received: from access.USask.Ca by SASK.USask.CA (PMDF #12333) id <01GNWB96CUDS0005NG@SASK.USask.CA>; Sat, 22 Aug 1992 21:48 CST Received: by access.USask.Ca (5.57/GLH-1.0); Sat, 22 Aug 92 21:45:39 -0600 id AA18694 for clim@bbn.com Received: from skaries.USask.ca by skdad.USask.ca (4.1/SMI-4.1) id AA13889; Sat, 22 Aug 92 21:45:36 CST Date: Sat, 22 Aug 92 21:45:35 CST From: coulman@skdad.usask.ca (Randy Coulman) Subject: Strange (to me) behavior with define-command To: clim@bbn.com (Clim Users Mailing List) Message-id: <9208230345.AA13889@skdad.USask.ca> X-Envelope-to: clim@bbn.com X-Mailer: ELM [version 2.3 PL11] I just ran into something a little odd today. Consider the following example (assuming the appropriate supporting code): (defclass A () ((slot-1 ...) (slot-2 ...)) ) (defclass B (A) ((slot-3 ...)) ) (clim:define-presentation-type A ()) (clim:define-presentation-type B () :inherit-from 'A) (clim:define-command (edit-A :command-table edit) ((Aobj 'A :gesture :edit)) ...) (clim:define-command (edit-B :command-table edit) ((Bobj 'B :gesture :edit)) ...) If an instance of class B is presented, then which command is accessible by the :edit gesture depends on the order that the commands are defined. If edit-A is defined first, then edit-B is never accessible. If edit-B is defined first, then everything is OK. It doesn't explicitly say so in the documentation, but I would (and did) assume that the translator for the most specific presentation type would be accessible before any others. I can always explicitly define the translators manually with the right priority values, or use a tester for edit-A to make sure that the objects are not B's, but I think this should be handled automatically. Comments? Thanks, Randy -- Randy A. Coulman | ARIES Laboratory | Department of Computational Science coulman@cs.Usask.ca | University of Saskatchewan | Saskatoon, SK S7N 0W0   Received: from BBN.COM by LABS-N.BBN.COM id aa05013; 23 Aug 92 22:04 EDT Received: from Mail.Think.COM by BBN.COM id aa25915; 23 Aug 92 21:52 EDT Return-Path: Received: from Gandalf.Think.COM by mail.think.com; Sun, 23 Aug 92 21:52:26 -0400 From: Barry Margolin Received: by gandalf.think.com (4.1/Think-1.2) id AA11802; Sun, 23 Aug 92 21:52:25 EDT Date: Sun, 23 Aug 92 21:52:25 EDT Message-Id: <9208240152.AA11802@gandalf.think.com> To: info-mcl@cambridge.apple.com, allegro-cl@ucbvax.berkeley.edu, clim@bbn.com, kcl@cli.com, lispworks@harlqn.co.uk Subject: Correction to dpANS Common Lisp FTP instructions The previous announcement of anonymous FTP access to the dpANS for Common Lisp gave the host name Beta.Xerox.COM. Please correct that to PARCFTP.Xerox.COM. At the moment these are synonyms, but if Xerox were to move their FTP server the latter name would move with it. We're sorry for the confusion.   Received: from BBN.COM by LABS-N.BBN.COM id aa07769; 24 Aug 92 4:17 EDT Received: from mcsun.EU.net by BBN.COM id aa09322; 24 Aug 92 4:11 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA27384 (5.65b/CWI-2.173); Mon, 24 Aug 1992 10:11:22 +0200 Received: from nrb.UUCP by ub4b.buug.be (5.65c/ub4b_02) id AA24381; Mon, 24 Aug 1992 10:11:26 +0200 Received: from nrbmi1.ia.nrb.be by scosysv.nrb.be with SMTP (5.59/NRB25-f-eef-ev@nrb) id AA06757; Mon, 24 Aug 92 16:05:21 +0100 Received: from scosysv.nrb.be by nrbmi1.ia.nrb.be via INTERNET with SMTP id 11729; 24 Aug 1992 10:01:32+0200 Received: by scosysv.nrb.be (5.59/NRB25-f-eef-ev@nrb) id AA03721; Sat, 22 Aug 92 12:35:01 +0100 Message-Id: <9208220935.AA03721@scosysv.nrb.be> From: nrb!uucp@relay.EU.net (UUCP administrator) X-Mailer: SCO System V Mail (version 3.2) To: clim@nrbmi2.ia.nrb.be Subject: UUCP Accounting for clim@nrbmi2.ia.nrb.be Date: Sat, 22 Aug 92 12:34:59 MET Accounting information for clim@nrbmi2.ia.nrb.be, please feel free to ignore it: 08/17 17:19 RX 1255 bytes from barmar@think.com Summary for user clim@nrbmi2.ia.nrb.be Total for Belgium sites = 0 byte(s) = 0 BEF Total for European sites = 0 byte(s) = 0 BEF Total for Other sites = 1255 byte(s) = 7 BEF Grand-total 1255 bytes = 7 BEF New version of accounting. Please mail to vyncke@nrb.be in case of problems   Received: from BBN.COM by LABS-N.BBN.COM id aa12256; 24 Aug 92 10:55 EDT Received: from chesapeake.ads.com by BBN.COM id aa25109; 24 Aug 92 10:36 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA02443; Mon, 24 Aug 92 10:39:13 EDT Date: Mon, 24 Aug 92 10:39:13 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9208241439.AA02443@chesapeake.ads.com> To: coulman@skdad.usask.ca Cc: clim@bbn.com In-Reply-To: Randy Coulman's message of Sat, 22 Aug 92 21:45:35 CST <9208230345.AA13889@skdad.USask.ca> Subject: Re: Strange (to me) behavior with define-command Reply-To: jclose@ads.com ... If an instance of class B is presented, then which command is accessible by the :edit gesture depends on the order that the commands are defined. If edit-A is defined first, then edit-B is never accessible. If edit-B is defined first, then everything is OK. It doesn't explicitly say so in the documentation, but I would (and did) assume that the translator for the most specific presentation type would be accessible before any others. I can always explicitly define the translators manually with the right priority values, or use a tester for edit-A to make sure that the objects are not B's, but I think this should be handled automatically. Comments? Randy, I had exactly the same behavior in some of my code. I had explicitly defined presentation translators, though. I didn't ask about it at the time, and I solved it by doing what you described -- using type testers in the translators. Anyone have a comment about why this is necessary? jffry   Received: from BBN.COM by LABS-N.BBN.COM id aa15562; 24 Aug 92 15:26 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa08998; 24 Aug 92 15:18 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1129736; 24 Aug 1992 15:19:07-0400 Date: Mon, 24 Aug 1992 15:19-0400 From: Scott McKay Subject: clim 2.0 color dialog code To: pchu@ptolemy.arc.nasa.gov, SWM@STONY-BROOK.SCRC.Symbolics.COM cc: clim@BBN.COM In-Reply-To: <9208110343.AA16604@ptolemy.arc.nasa.gov> Message-ID: <19920824191906.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 10 Aug 1992 23:43 EDT From: Philip Chu-Summer 92 Thanks, I found your color demo helpful in clearing up a lot of points. I am still puzzled by one aspect of slider callbacks. Originally, I defined a method on DRAG-CALLBACK, but that didn't seem to have any effect, so I switched to VALUE-CHANGED-CALLBACK. I noticed in your example that you define identical methods on both. Are they both called when the slider is dragged, or is one supposed to supersede the other? VALUE-CHANGED-CALLBACK gets invoked when the "final" value of the slider is set. On most toolkits, this happens when you release the mouse button. DRAG-CALLBACK gets invoked as you drag the slider indicator around with the mouse button pressed. Obviously, the very last DRAG-CALLBACK and the VALUE-CHANGED-CALLBACK will probably have the same value.   Received: from BBN.COM by LABS-N.BBN.COM id aa16334; 24 Aug 92 16:12 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa11069; 24 Aug 92 16:07 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1129815; 24 Aug 1992 16:08:39-0400 Date: Mon, 24 Aug 1992 16:08-0400 From: Scott McKay Subject: [MCL-CLIM] Gestures To: oli@ims.uni-stuttgart.de, clim@BBN.COM In-Reply-To: <9208140911.AA23035@adler.ims.uni-stuttgart.de> Message-ID: <19920824200838.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 14 Aug 1992 05:11 EDT From: Oliver Christ [working with MCL 2.0 Final & CLIM on MAC] Just a short and silly question: how can I get the gestures :describe and :menu (and the other predefined ones) on the Mac? To which events are they bound? Thanks for any help, Oli They are default bound to "mouse middle" and "mouse right". You can use CLIM:DEFINE-GESTURE-NAME to redefine the gestures to something else. Presumably, the efforts aimed at producing CLIM 1.1 for MCL will do something more satisfactory...   Received: from BBN.COM by LABS-N.BBN.COM id aa16730; 24 Aug 92 16:43 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa12697; 24 Aug 92 16:38 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1129869; 24 Aug 1992 16:38:54-0400 Date: Mon, 24 Aug 1992 16:38-0400 From: Scott McKay Subject: Nested accepting-values To: jclose@ads.com, clim@BBN.COM In-Reply-To: <9208181542.AA25171@chesapeake.ads.com> Message-ID: <19920824203853.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 18 Aug 1992 11:42 EDT From: Jeff Close greetings, I posted this awhile back and got no response, but we were having mail problems, so I'll try again. I've done this a thousand times in DW but it was too long ago: I'm trying to get several nested accepting-values to work so that when I hit a on an inner accept, it doesn't interpret it as terminating the outer one. I'd appreciate any suggestions. jeffrey Use WITH-ACTIVATION-CHARACTERS to disable #\Return as an activation character. Or use the :ACTIVATION-CHARACTERS arg to ACCEPT.   Received: from BBN.COM by LABS-N.BBN.COM id aa16756; 24 Aug 92 16:46 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa12764; 24 Aug 92 16:39 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1129871; 24 Aug 1992 16:40:08-0400 Date: Mon, 24 Aug 1992 16:40-0400 From: Scott McKay Subject: Re: Nested accepting-values, and ANOTHER question To: jclose@ads.com cc: clim@BBN.COM In-Reply-To: <9208181619.AA25546@chesapeake.ads.com> Message-ID: <19920824204005.9.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 18 Aug 1992 12:19 EDT From: Jeff Close Also while I'm on it, is there a way to control text styles within the "own-window" of accepting-values without creating a new accept-window flavor -- whoops, class? Thanks more, lots, Jeff Just wrapping with-text-style around the body of the dialog, but inside the accepting-values, might work.   Received: from BBN.COM by LABS-N.BBN.COM id aa15987; 24 Aug 92 15:52 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa10040; 24 Aug 92 15:46 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1129772; 24 Aug 1992 15:47:11-0400 Date: Mon, 24 Aug 1992 15:47-0400 From: Scott McKay Subject: accepting-values and exit-boxes To: chyde@chesapeake.ads.com, clim@BBN.COM In-Reply-To: <9208112319.AA00675@pecos.ads.com> Message-ID: <19920824194711.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 11 Aug 1992 19:19 EDT From: Clinton Hyde is Accepting-values only allowed to have the two exit-boxes :exit and :abort? I'd really like to have three, and attach some behavior to them. CLIM 2.0 allows you to extend the types of exit boxes. The typical types are :exit, :abort, and :help.   Received: from BBN.COM by LABS-N.BBN.COM id aa16900; 24 Aug 92 17:01 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa13747; 24 Aug 92 16:54 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1129890; 24 Aug 1992 16:55:46-0400 Date: Mon, 24 Aug 1992 16:55-0400 From: Scott McKay Subject: Problem to print from one application into other applications To: bwild@fzi.de, clim@BBN.COM In-Reply-To: <9208190949.AA00380@negro> Message-ID: <19920824205545.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 19 Aug 1992 05:49 EDT From: Bernd Wild Hi, I want print inside one application into a window of another application. If I send an output to a window of the other application, the output is shown on this window correctly but the receiving application dies at this moment (i.e. no further mouse-interactions are possible). Is there any trick to restart the application or to allow such output operations. CLIM does not presently have any locks associated with output histories, so multiple processes doing output into one window can damage CLIM's datastructures. You should do this locking yourself. Details: - Symbolics Ivory, Genera 8.1, CLIM 1.1. - Every application has its own root-window because all of them have to be active simultaneously. This should not require multiple root windows. - my function (define-command test (com-test :menu test) () (let ((output *standard-output*)) (setf output (get-frame-pane *another-application* 'output-window)) (describe xyz) (setf *standard-output* output))) Bernd Wild =============================================== Bernd Wild Forschungszentrum Informatik FZI Dept. Technical Expert Systems and Robotics Haid-und-Neu-Strasse 10-14 D-7500 Karlsruhe GERMANY Tel: +49-721-9654-310 Fax: +49-721-9654-309 email: bwild@fzi.de ===============================================   Received: from BBN.COM by LABS-N.BBN.COM id aa16970; 24 Aug 92 17:07 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa13881; 24 Aug 92 16:56 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1129892; 24 Aug 1992 16:58:03-0400 Date: Mon, 24 Aug 1992 16:58-0400 From: Scott McKay Subject: remove existing colors To: lien@aplcen.apl.jhu.edu, clim@BBN.COM In-Reply-To: <9208191525.AA10328@aplcen.apl.jhu.edu> Message-ID: <19920824205802.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 19 Aug 1992 11:25 EDT From: Duong lien t I use MAKE-COLOR-RGB to make new colors, but I exceed the color limit. How do I remove existing colors so I can create a new one? In CLIM 1.1, you can't. Some of us are working on a proposal for CLIM 2.0 to handle this, which we call "color palettes".   Received: from BBN.COM by LABS-N.BBN.COM id aa17103; 24 Aug 92 17:17 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa14534; 24 Aug 92 17:13 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1129919; 24 Aug 1992 17:14:14-0400 Date: Mon, 24 Aug 1992 17:14-0400 From: Scott McKay Subject: Re: Nested accepting-values To: jclose@ads.com, York@lucid.com cc: clim@BBN.COM In-Reply-To: <9208201450.AA22065@chesapeake.ads.com> Message-ID: <19920824211414.1.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 20 Aug 1992 10:50 EDT From: Jeff Close (Nota Bene: For anyone who didn't read my previous question -- this regards nested accept calls. I'm posting this for the benefit of those who weren't aware of what, to me, was a crucial discovery.) AHAAAA! The key is that :activation-characters cannot be NIL! I was trying to determine what the difference was between some of the things I've tried and some things I was sent. Some of them were very close to what I'd already tried. Thanks much for the suggestions. I think it is a bug that :ACTIVATION-CHARACTERS NIL does not do what you expect. I will investigate.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa17295; 24 Aug 92 17:32 EDT Received: by KARIBA.BBN.COM id aa07072; 24 Aug 92 17:23 EDT To: Scott McKay cc: clim@BBN.COM Subject: Re: accepting-values and exit-boxes In-reply-to: Scott McKay's message of Mon, 24 Aug 92 15:47:00 -0400. <19920824194711.2.SWM@SUMMER.SCRC.Symbolics.COM> Reply-To: jmorrill@BBN.COM Date: Mon, 24 Aug 92 17:21:51 -0400 Message-ID: <4483.714691311@bbn.com> From: Jeff Morrill Date: Mon, 24 Aug 1992 15:47-0400 From: Scott McKay Subject: accepting-values and exit-boxes To: chyde@chesapeake.ads.com, clim@BBN.COM Date: Tue, 11 Aug 1992 19:19 EDT From: Clinton Hyde is Accepting-values only allowed to have the two exit-boxes :exit and :abort? I'd really like to have three, and attach some behavior to them. CLIM 2.0 allows you to extend the types of exit boxes. The typical types are :exit, :abort, and :help. Can you elaborate a bit? For example, I can imagine wanting to: 1. have just one choice, :exit 2. associate an arbitrary function call with an exit button (I presume that's what :help would do, rather than being a true "exit" button) 3. associate a drawing function, rather than a string name, with an exit button, so that the button is graphical rather than textual 4. assign the button a pointer documentation string 5. put the buttons somewhere else besides the bottom (yikes!) 6. I would also like to make the kind of dialog box that is merely a couple of exit boxes, as in: Wait! You are about to cause a nuclear meltdown. Do it anyway? OK Cancel And have the #\Return character activate a default choice. I don't know if accepting values is the right way to do this or not. jeff morrill   Received: from BBN.COM by LABS-N.BBN.COM id aa17739; 24 Aug 92 18:06 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa16310; 24 Aug 92 18:02 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1130010; 24 Aug 1992 18:03:37-0400 Date: Mon, 24 Aug 1992 18:03-0400 From: Scott McKay Subject: Re: accepting-values and exit-boxes To: jmorrill@BBN.COM, SWM@STONY-BROOK.SCRC.Symbolics.COM cc: clim@BBN.COM In-Reply-To: <4483.714691311@bbn.com> Message-ID: <19920824220337.9.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 24 Aug 1992 17:21 EDT From: Jeff Morrill Date: Mon, 24 Aug 1992 15:47-0400 From: Scott McKay Subject: accepting-values and exit-boxes To: chyde@chesapeake.ads.com, clim@BBN.COM Date: Tue, 11 Aug 1992 19:19 EDT From: Clinton Hyde is Accepting-values only allowed to have the two exit-boxes :exit and :abort? I'd really like to have three, and attach some behavior to them. CLIM 2.0 allows you to extend the types of exit boxes. The typical types are :exit, :abort, and :help. Can you elaborate a bit? For example, I can imagine wanting to: 1. have just one choice, :exit 2. associate an arbitrary function call with an exit button (I presume that's what :help would do, rather than being a true "exit" button) 3. associate a drawing function, rather than a string name, with an exit button, so that the button is graphical rather than textual 4. assign the button a pointer documentation string 5. put the buttons somewhere else besides the bottom (yikes!) 6. I would also like to make the kind of dialog box that is merely a couple of exit boxes, as in: Wait! You are about to cause a nuclear meltdown. Do it anyway? OK Cancel And have the #\Return character activate a default choice. I don't know if accepting values is the right way to do this or not. jeff morrill The default methods are the following. They can all be specialized to do whatever you want, really. (I realize this is kind of a vague answer, but I', trying to catch up on all my mail, etc.) (defmethod frame-manager-default-exit-boxes ((framem standard-frame-manager)) '((:abort) (:exit))) (defmethod frame-manager-exit-box-labels ((framem standard-frame-manager) frame view) (declare (ignore frame view)) '((:exit "Exit") (:abort "Cancel"))) (defmethod display-exit-boxes ((frame accept-values) stream (view view)) ;; Do the fresh-line *outside* of the updating-output so that it ;; doesn't get repositioned relatively in the X direction if the ;; previous line gets longer. Maybe there should be some better ;; way of ensuring this. (fresh-line stream) (let ((labels (frame-manager-exit-box-labels (frame-manager frame) frame view))) (updating-output (stream :unique-id stream :cache-value 'exit-boxes) (with-slots (exit-boxes) frame (dolist (exit-box exit-boxes) (let* ((value (if (consp exit-box) (car exit-box) exit-box)) (label (or (and (consp exit-box) (second exit-box)) (second (assoc value labels))))) (with-output-as-presentation (stream value 'accept-values-exit-box) #-CCL-2 (write-string label stream) #+CCL-2 (if (eq value ':abort) ;; Kludge to print the cloverleaf char in MCL. ;; Needs an accompanying kludge in STREAM-WRITE-CHAR so that ;; #\CommandMark doesn't get lozenged. (progn (with-text-style (stream '(:mac-menu :roman :normal)) (write-char #\CommandMark stream)) (write-string "-. aborts" stream)) (write-string label stream))) (write-string " " stream)))))))   Received: from BBN.COM by LABS-N.BBN.COM id aa18273; 24 Aug 92 19:21 EDT Received: from ptolemy-arclan.arc.nasa.gov by BBN.COM id aa17980; 24 Aug 92 19:18 EDT Received: from jung.arc.nasa.gov by ptolemy.arc.nasa.gov (4.1/) id ; Mon, 24 Aug 92 16:17:49 PDT Date: Mon, 24 Aug 92 16:17:49 PDT From: Philip Chu-Summer 92 Message-Id: <9208242317.AA29870@ptolemy.arc.nasa.gov> Received: by jung.arc.nasa.gov (4.1/SMI-4.1) id AA20935; Mon, 24 Aug 92 16:17:58 PDT To: jmorrill@BBN.COM Cc: clim@BBN.COM In-Reply-To: Jeff Morrill's message of Mon, 24 Aug 92 17:21:51 -0400 <4483.714691311@bbn.com> Subject: accepting-values and exit-boxes Sender: jmorrill@BBN.COM Reply-To: jmorrill@BBN.COM Date: Mon, 24 Aug 92 17:21:51 -0400 From: Jeff Morrill Date: Mon, 24 Aug 1992 15:47-0400 From: Scott McKay Subject: accepting-values and exit-boxes To: chyde@chesapeake.ads.com, clim@BBN.COM Date: Tue, 11 Aug 1992 19:19 EDT From: Clinton Hyde is Accepting-values only allowed to have the two exit-boxes :exit and :abort? I'd really like to have three, and attach some behavior to them. CLIM 2.0 allows you to extend the types of exit boxes. The typical types are :exit, :abort, and :help. Can you elaborate a bit? For example, I can imagine wanting to: 1. have just one choice, :exit 2. associate an arbitrary function call with an exit button (I presume that's what :help would do, rather than being a true "exit" button) 3. associate a drawing function, rather than a string name, with an exit button, so that the button is graphical rather than textual 4. assign the button a pointer documentation string 5. put the buttons somewhere else besides the bottom (yikes!) 6. I would also like to make the kind of dialog box that is merely a couple of exit boxes, as in: Wait! You are about to cause a nuclear meltdown. Do it anyway? OK Cancel And have the #\Return character activate a default choice. I don't know if accepting values is the right way to do this or not. jeff morrill For what it's worth, I'm using CLIM 2.0 alpha from Franz, and I've been avoiding the use of ACCEPTING-VALUES and instead explicitly defining button panes with the appropriate callbacks in the application frame definition. As for number 6 above, I'm using NOTIFY-USER as a confirmation dialog, even though it's not exactly documented for that: (defmethod quit ((frame collage)) "" (when (notify-user frame "Do you really want to quit this session?" :title "Confirm") (mp:process-kill (collage-process frame)) (kill-displays frame) (setf *collage-frame* nil) (frame-exit frame))) Phil Chu Artificial Intelligence Research Branch NASA Ames Research Center pchu@ptolemy.arc.nasa.gov   Received: from BBN.COM by LABS-N.BBN.COM id aa27168; 25 Aug 92 11:34 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa10835; 25 Aug 92 11:29 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1130342; 25 Aug 1992 11:30:12-0400 Date: Tue, 25 Aug 1992 11:30-0400 From: Scott McKay Subject: Re: Minor bounding box problem To: jclose@ads.com, coulman@skdad.usask.ca cc: clim@BBN.COM In-Reply-To: <9208202016.AA25747@chesapeake.ads.com> Message-ID: <19920825153017.9.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 20 Aug 1992 16:16 EDT From: Jeff Close problem is that when they are highlighted, the box that surrounds the node is at least one pixel too low. This is a minor detail. However, when the node is erased, part of the ellipse remains on the display, because it is outside the bounding box. The bounding box should run tangent to the ellipse, but actually cuts through it on my display. Is this a known problem? Does it have an easy fix? BTW, I'm running Allegro This is a known problem. As far as I know it has nothing to do with defining your own border. It's a "1+" problem. I don't know if I have the source code to the patch -- I have a fasl -- anyone else? I would say that the CLX back-end is drawing the ellipse a little too big, rather than that the bounding box is too small.   Received: from BBN.COM by LABS-N.BBN.COM id aa27176; 25 Aug 92 11:35 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa10861; 25 Aug 92 11:30 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1130343; 25 Aug 1992 11:31:03-0400 Date: Tue, 25 Aug 1992 11:31-0400 From: Scott McKay Subject: Re: Minor bounding box problem To: jclose@ads.com, coulman@skdad.usask.ca cc: clim@BBN.COM In-Reply-To: <9208202016.AA25747@chesapeake.ads.com> Supersedes: <19920825153017.9.SWM@SUMMER.SCRC.Symbolics.COM> Message-ID: <19920825153108.0.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 20 Aug 1992 16:16 EDT From: Jeff Close I have defined a new border type with the following: (clim:define-border-type :ellipse (stream left top right bottom) (let ((cx (/ (+ left right) 2)) (cy (/ (+ top bottom) 2)) (rx (+ 8 (/ (- right left) 2))) (ry (+ 8 (/ (- bottom top) 2))) ) (clim:draw-ellipse* stream cx cy rx 0 0 ry :filled nil)) ) I use this border type to draw some nodes in a graph (using surrounding-output-with-border). These nodes are later selectable. The problem is that when they are highlighted, the box that surrounds the node is at least one pixel too low. This is a minor detail. However, when the node is erased, part of the ellipse remains on the display, because it is outside the bounding box. The bounding box should run tangent to the ellipse, but actually cuts through it on my display. Is this a known problem? Does it have an easy fix? BTW, I'm running Allegro This is a known problem. As far as I know it has nothing to do with defining your own border. It's a "1+" problem. I don't know if I have the source code to the patch -- I have a fasl -- anyone else? I would say that the CLX back-end is drawing the ellipse a little too big, rather than that the bounding box is too small.   Received: from BBN.COM by LABS-N.BBN.COM id aa27179; 25 Aug 92 11:35 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa10913; 25 Aug 92 11:31 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1130346; 25 Aug 1992 11:32:37-0400 Date: Tue, 25 Aug 1992 11:32-0400 From: Scott McKay Subject: Repairing damaged application panes To: halverson@crd.ge.com, clim@BBN.COM In-Reply-To: <9208201640.AA22921@sol.crd.Ge.Com> Message-ID: <19920825153242.1.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 20 Aug 1992 12:40 EDT From: peter c halverson We've got an application frame with several graphics panes whose :RECORD-P and :INCREMENTAL-REDISPLAY are both NIL (since the overhead in going through output recording is currently soooooo slow that it's actually faster to redraw everything every refresh cycle). Unfortunately, when the application frame is obscured or iconified and subsequently re-exposed, these panes are not refreshed correctly. Similar problems also result from changing configurations---panes are not always redrawn in the new configuration. So, does anyone know why my display-function isn't being called as part of the exposure event handling, or what the appropriate approach should be? Question: does everybody think that display functions should be called as part of exposure and refresh event handling? I can argue both ways.   Received: from BBN.COM by LABS-N.BBN.COM id aa27337; 25 Aug 92 11:44 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa11073; 25 Aug 92 11:37 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1130354; 25 Aug 1992 11:38:11-0400 Date: Tue, 25 Aug 1992 11:38-0400 From: Scott McKay Subject: DW->CLIM question To: sims@starbase.mitre.org, clim@BBN.COM In-Reply-To: <9208132357.AA13161@starbase.mitre.org> Message-ID: <19920825153816.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 13 Aug 1992 19:57 EDT From: Jim Sims I have an implemenation of sliders used to set global values, that are linked together by arbitrary formulae. In my old DW code, I used a presentation action to call a method so that while the user held down the left button, the "knob" of the slider would track the mouse up and down, setting the value of the affected variable (and all the others linked to it by formulae). It seems to work OK under CLIM, except that new presentations dont get drawn for the "knob". Under DW, I used the following snippet inside the method that tracks the mouse motion. How do I get the effect of the :with-normal-presentation-state in CLIM? ;;Output recording is disabled inside translators. ;;(scl:send window :with-normal-presentation-state ;; #'(lambda() (update-slider s window)))) Also, the old (original) presentation seems to no longer exist either... Do I need to do something like remove-output-record on it to get rid of it or is it really gone? thanks, jim (sims@starbase.mitre.org) By the way, CLIM 2.0 will support sliders "natively", even for moldy old Genera. And if you want to roll your own, it will be easier to use the "son of Silica" substrate. So at least this problem will go away for you.   Received: from BBN.COM by LABS-N.BBN.COM id aa27377; 25 Aug 92 11:50 EDT Received: from sask.usask.ca by BBN.COM id aa11354; 25 Aug 92 11:43 EDT Received: from access.USask.Ca by SASK.USask.CA (PMDF #12333) id <01GNZSWG3Q1S000GWK@SASK.USask.CA>; Tue, 25 Aug 1992 09:46 CST Received: by access.USask.Ca (5.57/GLH-1.0); Tue, 25 Aug 92 09:43:05 -0600 id AA00654 for SWM@stony-brook.scrc.symbolics.com Received: from skaries.USask.ca by skdad.USask.ca (4.1/SMI-4.1) id AA16960; Tue, 25 Aug 92 09:42:59 CST Date: Tue, 25 Aug 92 9:42:57 CST From: coulman@skdad.usask.ca (Randy Coulman) Subject: Re: Strange (to me) behavior with define-command In-reply-to: <19920825152604.8.SWM@SUMMER.SCRC.Symbolics.COM>; from "Scott McKay" at Aug 25, 92 11:26 am To: SWM@STONY-BROOK.SCRC.Symbolics.COM (Scott McKay) Cc: clim@bbn.com (Clim Users Mailing List) Message-id: <9208251542.AA16960@skdad.USask.ca> X-Envelope-to: clim@bbn.com X-Mailer: ELM [version 2.3 PL11] > > >@begin(obligatory_scolding) >Nobody said what version of CLIM they are using, or on what platform. >@end(obligatory_scolding) > @begin(obligatory_whining_defence) I usually do, but I forgot this time. Franz CLIM 1.1 on a Sparc 1+. @end(obligatory_whining_defence) >It's just a bug, which has been fixed in CLIM 2.0. The bug was that >CLIM failed to search the translators in class precedence order; now >it does. > Is there an easy fix for 1.1? 2.0 seems so far away for some (most?) of us. Randy -- Randy A. Coulman | ARIES Laboratory | Department of Computational Science coulman@cs.Usask.ca | University of Saskatchewan | Saskatoon, SK S7N 0W0   Received: from BBN.COM by LABS-N.BBN.COM id aa27414; 25 Aug 92 11:53 EDT Received: from sask.usask.ca by BBN.COM id aa11501; 25 Aug 92 11:47 EDT Received: from access.USask.Ca by SASK.USask.CA (PMDF #12333) id <01GNZT0WIZ00000II8@SASK.USask.CA>; Tue, 25 Aug 1992 09:49 CST Received: by access.USask.Ca (5.57/GLH-1.0); Tue, 25 Aug 92 09:46:38 -0600 id AA00792 for SWM@stony-brook.scrc.symbolics.com Received: from skaries.USask.ca by skdad.USask.ca (4.1/SMI-4.1) id AA17009; Tue, 25 Aug 92 09:46:31 CST Date: Tue, 25 Aug 92 9:46:30 CST From: coulman@skdad.usask.ca (Randy Coulman) Subject: Re: Minor bounding box problem In-reply-to: <19920825153108.0.SWM@SUMMER.SCRC.Symbolics.COM>; from "Scott McKay" at Aug 25, 92 11:31 am To: SWM@STONY-BROOK.SCRC.Symbolics.COM (Scott McKay) Cc: clim@bbn.com (Clim Users Mailing List) Message-id: <9208251546.AA17009@skdad.USask.ca> X-Envelope-to: clim@bbn.com X-Mailer: ELM [version 2.3 PL11] > > Date: Thu, 20 Aug 1992 16:16 EDT > From: Jeff Close > > I have defined a new border type with the following: > > (clim:define-border-type :ellipse (stream left top right bottom) > (let ((cx (/ (+ left right) 2)) > (cy (/ (+ top bottom) 2)) > (rx (+ 8 (/ (- right left) 2))) > (ry (+ 8 (/ (- bottom top) 2))) ) > (clim:draw-ellipse* stream cx cy rx 0 0 ry :filled nil)) > ) > Actually, changing the "/"s above to "truncate"s got the bounding box to line up correctly. However, all bounding boxes still seem to be off a bit. The top and left edges will line up exactly, while the bottom and left edges will be about 1 pixel outside of the object. That's not a big deal, however. > >I would say that the CLX back-end is drawing the ellipse a little too >big, rather than that the bounding box is too small. > -- Randy A. Coulman | ARIES Laboratory | Department of Computational Science coulman@cs.Usask.ca | University of Saskatchewan | Saskatoon, SK S7N 0W0   Received: from BBN.COM by LABS-N.BBN.COM id aa27088; 25 Aug 92 11:30 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa10709; 25 Aug 92 11:25 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1130339; 25 Aug 1992 11:26:02-0400 Date: Tue, 25 Aug 1992 11:26-0400 From: Scott McKay Subject: Re: Strange (to me) behavior with define-command To: jclose@ads.com, coulman@skdad.usask.ca cc: clim@BBN.COM In-Reply-To: <9208241439.AA02443@chesapeake.ads.com> Message-ID: <19920825152604.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 24 Aug 1992 10:39 EDT From: Jeff Close ... If an instance of class B is presented, then which command is accessible by the :edit gesture depends on the order that the commands are defined. If edit-A is defined first, then edit-B is never accessible. If edit-B is defined first, then everything is OK. It doesn't explicitly say so in the documentation, but I would (and did) assume that the translator for the most specific presentation type would be accessible before any others. I can always explicitly define the translators manually with the right priority values, or use a tester for edit-A to make sure that the objects are not B's, but I think this should be handled automatically. Comments? I had exactly the same behavior in some of my code. I had explicitly defined presentation translators, though. I didn't ask about it at the time, and I solved it by doing what you described -- using type testers in the translators. Anyone have a comment about why this is necessary? @begin(obligatory_scolding) Nobody said what version of CLIM they are using, or on what platform. @end(obligatory_scolding) It's just a bug, which has been fixed in CLIM 2.0. The bug was that CLIM failed to search the translators in class precedence order; now it does.   Received: from BBN.COM by LABS-N.BBN.COM id aa28027; 25 Aug 92 12:40 EDT Received: from mwunix.mitre.org by BBN.COM id aa13394; 25 Aug 92 12:34 EDT Return-Path: Received: from starbase.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA10694; Tue, 25 Aug 92 12:32:02 -0400 Received: from magellan.mitre.org by starbase.mitre.org (4.1/SMI-4.1) id AA10030; Tue, 25 Aug 92 12:25:20 EDT Date: Tue, 25 Aug 92 12:25:20 EDT From: sims@starbase.MITRE.ORG (Jim Sims) Message-Id: <9208251625.AA10030@starbase.mitre.org> Received: by magellan.mitre.org (4.1/SMI-4.1) id AA11134; Tue, 25 Aug 92 12:36:29 EDT To: SWM@STONY-BROOK.SCRC.Symbolics.COM Cc: clim@BBN.COM In-Reply-To: Scott McKay's message of Tue, 25 Aug 1992 11:38-0400 <19920825153816.3.SWM@SUMMER.SCRC.Symbolics.COM> Subject: DW->CLIM question Thanks for the speedy (after you returned; how was the trip?) reply... I was wondering if you can easily tell a bit more about the 'new, native' sliders for 2.0. THe sliders I have a re very general, and have a coupla features that I kinda doubt the CLIM sliders will have. So, I'm wondering if I should fix mine or try to use the CLIM 2.0 ones: Each slider has: an associated global variable name that gets set by manipulating the slider an associated equations, that may link it to other variables and/or sliders upper and lower limits (that are dynamic) potential to have a finitie set of discrete values (which need not be numbers) arbitrary setup fn to be called when it's created Changing a slider value: updates the global variable propagates changes to other sliders via any mention of the (first) slider's associated variable in the equations of the other sliders rescales the axes if the min and max for the slider weren't already the min and max associated with it's drawn representation redraws the value underneath the slider and there's probably a coupla things I left out... jim   Received: from BBN.COM by LABS-N.BBN.COM id aa28273; 25 Aug 92 13:00 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa14094; 25 Aug 92 12:56 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1130423; 25 Aug 1992 12:56:58-0400 Date: Tue, 25 Aug 1992 12:57-0400 From: Scott McKay Subject: Re: Strange (to me) behavior with define-command To: coulman@skdad.usask.ca, SWM@STONY-BROOK.SCRC.Symbolics.COM cc: clim@bbn.com In-Reply-To: <9208251542.AA16960@skdad.USask.ca> Message-ID: <19920825165704.9.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 25 Aug 1992 11:42 EDT From: coulman@skdad.usask.ca (Randy Coulman) >It's just a bug, which has been fixed in CLIM 2.0. The bug was that >CLIM failed to search the translators in class precedence order; now >it does. > Is there an easy fix for 1.1? 2.0 seems so far away for some (most?) of us. Unfortunately not.   Received: from BBN.COM by LABS-N.BBN.COM id aa28409; 25 Aug 92 13:07 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa14361; 25 Aug 92 13:02 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1130435; 25 Aug 1992 13:03:54-0400 Date: Tue, 25 Aug 1992 13:03-0400 From: Scott McKay Subject: DW->CLIM question To: sims@starbase.MITRE.ORG, SWM@STONY-BROOK.SCRC.Symbolics.COM cc: clim@BBN.COM In-Reply-To: <9208251625.AA10030@starbase.mitre.org> Message-ID: <19920825170359.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 25 Aug 1992 12:25 EDT From: sims@starbase.MITRE.ORG (Jim Sims) Thanks for the speedy (after you returned; how was the trip?) reply... I was wondering if you can easily tell a bit more about the 'new, native' sliders for 2.0. THe sliders I have a re very general, and have a coupla features that I kinda doubt the CLIM sliders will have. So, I'm wondering if I should fix mine or try to use the CLIM 2.0 ones: Each slider has: an associated global variable name that gets set by manipulating the slider Sliders have callbacks, which are responsible for hacking the value of any global state. an associated equations, that may link it to other variables and/or sliders See above. upper and lower limits (that are dynamic) Yes. potential to have a finitie set of discrete values (which need not be numbers) No. arbitrary setup fn to be called when it's created Specialize the slider class, use INITIALIZE-INSTANCE Changing a slider value: updates the global variable propagates changes to other sliders via any mention of the (first) slider's associated variable in the equations of the other sliders See above. rescales the axes if the min and max for the slider weren't already the min and max associated with it's drawn representation No. redraws the value underneath the slider Yes. and there's probably a coupla things I left out... You can certainly use your own implementation of sliders, but the "son of Silica" substrate provides a more natural way to implement them than presentation actions, which are really at too high a level.   Received: from BBN.COM by LABS-N.BBN.COM id aa29488; 25 Aug 92 14:15 EDT Received: from chesapeake.ads.com by BBN.COM id aa17341; 25 Aug 92 14:09 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA18750; Tue, 25 Aug 92 14:12:05 EDT Date: Tue, 25 Aug 92 14:12:05 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9208251812.AA18750@chesapeake.ads.com> To: coulman@skdad.usask.ca Cc: SWM@stony-brook.scrc.symbolics.com, clim@bbn.com In-Reply-To: Randy Coulman's message of Tue, 25 Aug 92 9:42:57 CST <9208251542.AA16960@skdad.USask.ca> Subject: Re: Strange (to me) behavior with define-command Reply-To: jclose@ads.com Date: Tue, 25 Aug 92 9:42:57 CST From: Randy Coulman X-Envelope-To: clim@bbn.com X-Mailer: ELM [version 2.3 PL11] > > >@begin(obligatory_scolding) >Nobody said what version of CLIM they are using, or on what platform. >@end(obligatory_scolding) > @begin(obligatory_whining_defence) I usually do, but I forgot this time. Franz CLIM 1.1 on a Sparc 1+. @end(obligatory_whining_defence) @begin(spineless_cowering_and_pointing) Yeah, what he said -- same here. @end(spineless_cowering_and_pointing) >It's just a bug, which has been fixed in CLIM 2.0. The bug was that >CLIM failed to search the translators in class precedence order; now >it does. > Is there an easy fix for 1.1? 2.0 seems so far away for some (most?) of us. @begin(whiny_complaint) Yeah, we don't have it either. @end(whiny_complaint)   Received: from BBN.COM by LABS-N.BBN.COM id aa29740; 25 Aug 92 14:38 EDT Received: from lucid.com by BBN.COM id aa18304; 25 Aug 92 14:31 EDT Received: from oakland-hills.lucid ([192.31.212.153]) by heavens-gate.lucid.com id AA25573g; Tue, 25 Aug 92 11:20:07 PDT Received: by oakland-hills.lucid (4.1/SMI-4.1) id AA06005; Tue, 25 Aug 92 11:24:42 PDT Date: Tue, 25 Aug 92 11:24:42 PDT From: york%oakland-hills@lucid.com (Bill York) Message-Id: <9208251824.AA06005@oakland-hills.lucid> To: SWM@stony-brook.scrc.symbolics.com Cc: halverson@crd.ge.com, clim@BBN.COM In-Reply-To: Scott McKay's message of Tue, 25 Aug 1992 11:32-0400 <19920825153242.1.SWM@SUMMER.SCRC.Symbolics.COM> Subject: Repairing damaged application panes Reply-To: York@lucid.com Date: Tue, 25 Aug 1992 11:32-0400 From: Scott McKay Date: Thu, 20 Aug 1992 12:40 EDT From: peter c halverson Question: does everybody think that display functions should be called as part of exposure and refresh event handling? I can argue both ways. I say yes. I think that in general the model should be that damage gets noticed by the event loop, and each pane is asked to repaint its damaged area. Panes with output recording satisfy this request via REPLAY. Panes with display functions invoke the display function. Of course, this requires distinguishing running display functions for initial effect (or full redisplay) from running them for "repaint" purposes. Also, ideally you would like to pass the "damage region" for the pane to the display function. Fortunately, the CLIM 2 architecture will provide better support for this. You can define a pane with a HANDLE-REPAINT method that invokes explicit display code. The EXTENDED-STREAM-PANE just defines a method for this that calls REPLAY. The damage region is already being passed around as well. For CLIM 1, I think that the only work-around is to define your own class of pane and write a window-process-update-region method for it that invokes the display function. Scott? (defmethod window-process-update-region ((stream my-pane)) ...)   Received: from BBN.COM by LABS-N.BBN.COM id aa01835; 25 Aug 92 17:02 EDT Received: from dipl.rdd.lmsc.lockheed.com by BBN.COM id aa27240; 25 Aug 92 16:55 EDT Received: from jade.rdd.lmsc.lockheed.com by dipl.rdd.lmsc.lockheed.com (4.0/SMI-4.1) id AA18638; Tue, 25 Aug 92 13:54:31 PDT Received: from cluso.lmsc.com by jade.rdd.lmsc.lockheed.com (4.1/SMI-4.0) id AA14013; Tue, 25 Aug 92 13:54:30 PDT Date: Tue, 25 Aug 92 13:54:30 PDT From: ttrinko@dipl.rdd.lmsc.lockheed.com (Tom Trinko) Message-Id: <9208252054.AA14013@jade.rdd.lmsc.lockheed.com> To: clim@bbn.com Subject: selective accepts This is probably a simple question but I'm having trouble with accept using genera 8.1 and clim 1.1. I have a number of different objects displayed which all use the same presentation type. When I start a certain activity, which allows the user to select a series of nodes in a graph, I want to have only those nodes which are directly connected to the last node be mouse sensative. I also don't want the lines which connect the nodes to be mouse sensitve even though they use the same presentation type as the nodes. The accept statement looks like this` (accept '((class :connected-with last-node)... The parameters are used correctly because when you've been prompted to make a selection if you hit the help key you get a list of only the directly connected nodes. Unfortunetly all of the objects are mouse sensitive if you move the mouse over them. I checked and determined that both presentation-typep and presentation-subtypep are returning the correct values, ie when the mouse moves over an object other than the nearest nodes presentation-typep returns nil and presentation subtypep returns (nil,t). I'd appreciate any help, also I'd like to know what I can modify to control which objects are hightlited when the mouse moves over them. I thought that was partially controlled by accept and presentation-typep but I guess I was wrong. thanks for any help.   Received: from BBN.COM by LABS-N.BBN.COM id aa03335; 25 Aug 92 18:36 EDT Received: from Sunset.AI.SRI.COM by BBN.COM id aa00322; 25 Aug 92 18:33 EDT Received: from rockaway.ai.sri.com by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA00695 for clim@BBN.COM; Tue, 25 Aug 92 15:33:35 PDT Received: by rockaway.ai.sri.com (4.1/SMI-4.1) id AA25435 for clim@BBN.COM; Tue, 25 Aug 92 15:34:23 PDT Date: Tue, 25 Aug 92 15:34:23 PDT From: Peter Karp To: York@lucid.com Cc: SWM@stony-brook.scrc.symbolics.com, halverson@crd.ge.com, clim@BBN.COM Subject: Re: Repairing damaged application panes In-Reply-To: Your message of Tue, 25 Aug 92 11:24:42 PDT Message-Id: I would like to argue for a mechanism that allows repair of damaged panes, that is independent of the event loop. People here complain that if an application prompts the user with a menu, then computes for a while, then goes back to the event loop, that a damaged region persists during that computation and looks ugly. If you know a large amount of computation is about to occur, it would be nice if you could force repairs to occur. Peter   Received: from BBN.COM by LABS-N.BBN.COM id aa12034; 26 Aug 92 10:29 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa21557; 26 Aug 92 10:21 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1131081; 26 Aug 1992 10:21:29-0400 Date: Wed, 26 Aug 1992 10:21-0400 From: Scott McKay Subject: Re: Repairing damaged application panes To: pkarp@ai.sri.com, York@lucid.com cc: SWM@STONY-BROOK.SCRC.Symbolics.COM, halverson@crd.ge.com, clim@BBN.COM In-Reply-To: Message-ID: <19920826142140.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 25 Aug 1992 18:34 EDT From: Peter Karp I would like to argue for a mechanism that allows repair of damaged panes, that is independent of the event loop. People here complain that if an application prompts the user with a menu, then computes for a while, then goes back to the event loop, that a damaged region persists during that computation and looks ugly. If you know a large amount of computation is about to occur, it would be nice if you could force repairs to occur. Call REDISPLAY-FRAME-PANE, or (in CLIM 2.0) REPAINT-SHEET.   Received: from BBN.COM by LABS-N.BBN.COM id aa11952; 26 Aug 92 10:21 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa21239; 26 Aug 92 10:14 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1131076; 26 Aug 1992 10:15:30-0400 Date: Wed, 26 Aug 1992 10:15-0400 From: Scott McKay Subject: selective accepts To: ttrinko@dipl.rdd.lmsc.lockheed.com, clim@BBN.COM In-Reply-To: <9208252054.AA14013@jade.rdd.lmsc.lockheed.com> Message-ID: <19920826141542.5.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 25 Aug 1992 16:54 EDT From: Tom Trinko This is probably a simple question but I'm having trouble with accept using genera 8.1 and clim 1.1. I have a number of different objects displayed which all use the same presentation type. When I start a certain activity, which allows the user to select a series of nodes in a graph, I want to have only those nodes which are directly connected to the last node be mouse sensative. I also don't want the lines which connect the nodes to be mouse sensitve even though they use the same presentation type as the nodes. Why are the edges the same presentation type as the nodes? That doesn't seem right to me. The accept statement looks like this` (accept '((class :connected-with last-node)... The parameters are used correctly because when you've been prompted to make a selection if you hit the help key you get a list of only the directly connected nodes. Unfortunetly all of the objects are mouse sensitive if you move the mouse over them. I checked and determined that both presentation-typep and presentation-subtypep are returning the correct values, ie when the mouse moves over an object other than the nearest nodes presentation-typep returns nil and presentation subtypep returns (nil,t). I'd appreciate any help, also I'd like to know what I can modify to control which objects are hightlited when the mouse moves over them. I thought that was partially controlled by accept and presentation-typep but I guess I was wrong. There is also a bug in IDENTITY-TRANSLATOR-APPLICABLE-P, which has been discussed here before. Try this definition for it instead: (defun identity-translator-applicable-p (presentation context-type) (let* ((type (presentation-type presentation)) (type-name (presentation-type-name type)) (object (presentation-object presentation))) (with-presentation-type-decoded (context-name context-parameters) context-type (if (eq type-name 'blank-area) (eq context-name 'blank-area) ;; Let MENU-ITEM-IDENTITY take care of pure menu items (unless (and (eq type-name 'menu-item) (eq context-name 'menu-item)) ;; Either the types definitely match, or the types nominally match ;; and the object must be validated. (or (presentation-subtypep type context-type) (and (not (null context-parameters)) (presentation-typep object context-type))))))))   Received: from BBN.COM by LABS-N.BBN.COM id aa13247; 26 Aug 92 12:02 EDT Received: from noc.msc.edu by BBN.COM id aa25557; 26 Aug 92 11:56 EDT Received: from uc.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA01460; Wed, 26 Aug 92 10:56:23 -0500 Received: from [129.230.11.2] by uc.msc.edu (5.65/MSC/v3.0z(901212)) id AA21822; Wed, 26 Aug 92 10:56:25 -0500 Received: from trc.amoco.com (apctrc.trc.amoco.com) by netserv2 (4.1/SMI-4.0) id AA08124; Wed, 26 Aug 92 10:56:20 CDT Received: from spirit.trc.amoco.com by trc.amoco.com (4.1/SMI-4.1) id AA16506; Wed, 26 Aug 92 10:56:18 CDT Received: from trc.amoco.com (skeptic) by spirit.trc.amoco.com (4.1/SMI-4.1) id AA14326; Wed, 26 Aug 92 10:56:16 CDT Date: Wed, 26 Aug 1992 10:56-0500 From: Donald H. Mitchell Reply-To: dmitchell@trc.amoco.com Subject: accepting-values pane (CLIM 1.1 Genera 8.2) To: clim@bbn.com, customer-reports@stony-brook.scrc.symbolics.com Cc: jtompkins@APCTRC.trc.amoco.com Message-Id: <19920826155615.1.DON@trc.amoco.com> UX1038 We're having difficulty with accepting-values panes. The fields blank out whenever the user does any activity outside the avv pane. The presentations still appear to be there because the spots are still hot and the user can edit (with-blindfold-attached). When the user changes a value, then that value and its prompt show back up. We've tried :resynchronize and :incremental-redisplay to no avail. We're using the :display-function as per the documentation. Can someone send us a working example or tell us a workaround? Don Mitchell dmitchell@trc.amoco.com Amoco Production Company (918) 660-4270 Tulsa Research Center P.O. Box 3385, Tulsa, OK 74102   Received: from BBN.COM by LABS-N.BBN.COM id aa12744; 26 Aug 92 11:29 EDT Received: from [129.197.134.99] by BBN.COM id aa24198; 26 Aug 92 11:22 EDT Received: from jade.rdd.lmsc.lockheed.com by dipl.rdd.lmsc.lockheed.com (4.0/SMI-4.1) id AA00468; Wed, 26 Aug 92 08:21:53 PDT Received: from cluso.lmsc.com by jade.rdd.lmsc.lockheed.com (4.1/SMI-4.0) id AA26730; Wed, 26 Aug 92 08:21:50 PDT Date: Wed, 26 Aug 92 08:21:50 PDT From: ttrinko@dipl.rdd.lmsc.lockheed.com (Tom Trinko) Message-Id: <9208261521.AA26730@jade.rdd.lmsc.lockheed.com> To: clim@bbn.com Subject: selective accept i tried the patch you sent There is also a bug in IDENTITY-TRANSLATOR-APPLICABLE-P, which has been discussed here before. Try this definition for it instead: (defun identity-translator-applicable-p (presentation context-type) (let* ((type (presentation-type presentation)) (type-name (presentation-type-name type)) (object (presentation-object presentation))) (with-presentation-type-decoded (context-name context-parameters) context-type (if (eq type-name 'blank-area) (eq context-name 'blank-area) ;; Let MENU-ITEM-IDENTITY take care of pure menu items (unless (and (eq type-name 'menu-item) (eq context-name 'menu-item)) ;; Either the types definitely match, or the types nominally match ;; and the object must be validated. (or (presentation-subtypep type context-type) (and (not (null context-parameters)) (presentation-typep object context-type)))))))) but it doesn't seem to work. It seems to be called twice for every object the mouse moves over. For the objects that should be selected it returns a non-nil value the first time and a nil value the second time. For the objects that shouldn't be mouse sensitive it returns nil both times. Unfortunetly even when it returns nil the object highlites. I'm a little confused about why the object highlites when this method returns nil. Thanks for any further help.   Received: from BBN.COM by LABS-N.BBN.COM id aa13860; 26 Aug 92 12:55 EDT Received: from chesapeake.ads.com by BBN.COM id aa27529; 26 Aug 92 12:50 EDT Received: by chesapeake.ads.com (4.1/1.34v1.3) id AA01233; Wed, 26 Aug 92 12:53:32 EDT Date: Wed, 26 Aug 92 12:53:32 EDT From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9208261653.AA01233@chesapeake.ads.com> To: clim@bbn.com Subject: Re: accepting-values pane (CLIM 1.1 Genera 8.2) Reply-To: jclose@ads.com We're having difficulty with accepting-values panes... Boy, does this describe my recent experience with them. I have had problems with what Don describes, as well as the following: When a value is entered into an AV field that is the wrong type, the error message scrolls across the AV window and covers it with garbage, making both the error message and the original field labels unreadable. What can I do to prevent this? Also, what can I use to make both the default AND the description of the type to appear? I want the default, but I still want the helpful "a string" or whatever to appear. Thanks as always. Jeffrey   Received: from BBN.COM by LABS-N.BBN.COM id aa14180; 26 Aug 92 13:42 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa29242; 26 Aug 92 13:37 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1131239; 26 Aug 1992 13:38:27-0400 Date: Wed, 26 Aug 1992 13:38-0400 From: Scott McKay Subject: accepting-values pane (CLIM 1.1 Genera 8.2) To: dmitchell@trc.amoco.com, clim@BBN.COM, customer-reports@STONY-BROOK.SCRC.Symbolics.COM cc: jtompkins@apctrc.trc.amoco.com In-Reply-To: <19920826155615.1.DON@trc.amoco.com> Message-ID: <19920826173837.2.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 26 Aug 1992 11:56 EDT From: "Donald H. Mitchell" UX1038 We're having difficulty with accepting-values panes. The fields blank out whenever the user does any activity outside the avv pane. The presentations still appear to be there because the spots are still hot and the user can edit (with-blindfold-attached). When the user changes a value, then that value and its prompt show back up. We've tried :resynchronize and :incremental-redisplay to no avail. We're using the :display-function as per the documentation. Can someone send us a working example or tell us a workaround? Please reduce this to a simple failing test case. I have never seen this mode of failure with AVV panes.   Received: from BBN.COM by LABS-N.BBN.COM id aa14646; 26 Aug 92 14:07 EDT Received: from jasmine.tc.pw.com by BBN.COM id aa00296; 26 Aug 92 13:59 EDT Received: from pwtc.tc.pw.com by tc.pw.com (4.1/SMI-4.1) id AA22788; Wed, 26 Aug 92 10:59:56 PDT Received: from yen.tc.pw.com by pwtc.tc.pw.com (4.1/SMI-3.2) id AA05198; Wed, 26 Aug 92 10:57:22 PDT Date: Wed, 26 Aug 1992 10:59-0700 From: Jefferson DeLisio Subject: presentations outside of frame panes To: clim@BBN.COM Message-Id: <19920826175912.3.DELISIO@yen.tc.pw.com> I would like to pop up a temporary window over one of my application frame panes and display active presentations associated with that frame. I tried this once in the past with no success - i.e. the presentations were not mouse-sensitive - and resorted to using TRACKING-POINTER. Now I really need the functionality of a large set of my presentations and don't wish to duplicate the effort. Any pointers? Details, details, details - (GENERA 8.1 CLIM 1.0) (CLOE 3.1 CLIM 1.0) (ALLEGRO 4.1 CLIM 1.1) Jeff DeLisio | Price Waterhouse DeLisio@tc.pw.com | | Technology Centre | | 68 Willow Rd (415) 688-6674| | Menlo Park, Ca. 94025 fax (415) 321-5543|   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa15114; 26 Aug 92 14:42 EDT To: jclose@ads.com cc: clim@BBN.COM Subject: Re: accepting-values pane (CLIM 1.1 Genera 8.2) In-reply-to: Your message of Wed, 26 Aug 92 12:53:32 -0400. <9208261653.AA01233@chesapeake.ads.com> Date: Wed, 26 Aug 92 14:03:08 -0400 From: kanderso@BBN.COM Date: Wed, 26 Aug 92 12:53:32 EDT From: Jeff Close To: clim@BBN.COM Subject: Re: accepting-values pane (CLIM 1.1 Genera 8.2) Reply-To: jclose@ads.com We're having difficulty with accepting-values panes... Boy, does this describe my recent experience with them. I have had problems with what Don describes, as well as the following: When a value is entered into an AV field that is the wrong type, the error message scrolls across the AV window and covers it with garbage, making both the error message and the original field labels unreadable. What can I do to prevent this? Also, what can I use to make both the default AND the description of the type to appear? I want the default, but I still want the helpful "a string" or whatever to appear. I have a solution to this in CLIM 0.9 that pops up a window with the error message to the right or left of the window you are working in. I'll be glad to send it to someone who might get it working in a more recent CLIM. k   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id ab15114; 26 Aug 92 14:43 EDT To: Scott McKay cc: pkarp@ai.sri.com, York@lucid.com, halverson@crd.ge.com, clim@BBN.COM Subject: Re: Repairing damaged application panes In-reply-to: Your message of Wed, 26 Aug 92 10:21:00 -0400. <19920826142140.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 26 Aug 92 14:09:36 -0400 From: kanderso@BBN.COM Date: Wed, 26 Aug 1992 10:21-0400 From: Scott McKay Subject: Re: Repairing damaged application panes To: pkarp@ai.sri.com, York@lucid.com cc: SWM@stony-brook.scrc.symbolics.com, halverson@crd.ge.com, clim@BBN.COM Date: Tue, 25 Aug 1992 18:34 EDT From: Peter Karp I would like to argue for a mechanism that allows repair of damaged panes, that is independent of the event loop. People here complain that if an application prompts the user with a menu, then computes for a while, then goes back to the event loop, that a damaged region persists during that computation and looks ugly. If you know a large amount of computation is about to occur, it would be nice if you could force repairs to occur. Call REDISPLAY-FRAME-PANE, or (in CLIM 2.0) REPAINT-SHEET. When, where? This problem has plagued us on certain x servers. The x event loop queues the repaint event for after the command is over, as described above. This makes a hardcopy-window command impossible. If you forcefully do the repaint while the window is drawing for the first time, you can get very strange results. The x event process and the frame process need better coordianton. k   Received: from BBN.COM by LABS-N.BBN.COM id aa15141; 26 Aug 92 14:43 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa02205; 26 Aug 92 14:38 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1131289; 26 Aug 1992 14:38:59-0400 Date: Wed, 26 Aug 1992 14:39-0400 From: Scott McKay Subject: Re: accepting-values pane (CLIM 1.1 Genera 8.2) To: jclose@ads.com, clim@BBN.COM In-Reply-To: <9208261653.AA01233@chesapeake.ads.com> Message-ID: <19920826183912.5.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 26 Aug 1992 12:53 EDT From: Jeff Close We're having difficulty with accepting-values panes... Boy, does this describe my recent experience with them. I have had problems with what Don describes, as well as the following: When a value is entered into an AV field that is the wrong type, the error message scrolls across the AV window and covers it with garbage, making both the error message and the original field labels unreadable. What can I do to prevent this? This is fixed in CLIM 2.0. Also, what can I use to make both the default AND the description of the type to appear? I want the default, but I still want the helpful "a string" or whatever to appear. I don't think there is any way to do this, if want you are asking is what I think it is. I will investigate.   Received: from BBN.COM by LABS-N.BBN.COM id aa16175; 26 Aug 92 16:26 EDT Received: from pecos.ads.com by BBN.COM id aa08331; 26 Aug 92 16:13 EDT Received: by pecos.ads.com (4.1/1.34v1.3) id AA01061; Wed, 26 Aug 92 16:16:09 EDT Date: Wed, 26 Aug 92 16:16:09 EDT From: chyde@chesapeake.ads.com (Clinton Hyde) Message-Id: <9208262016.AA01061@pecos.ads.com> To: clim@bbn.com Subject: special keys I'm using CLIM on a Sparc 2, Allegro CL. the sparc 2 kbd has a LOT of special function keys, etc., L1-10, HELP, F1-12, R1-15, ENTER... how can I arrange to receive keystrokes from them? I'd like to be able to use them for lots of commands. -- clint Clint Hyde "Give me a LispM or give me death!" -- anonymous Advanced Decision Systems Internet: chyde@chesapeake.ads.com 2111 Wilson Blvd #800 Arlington, VA 22201 (703) 875-0327   Received: from BBN.COM by LABS-N.BBN.COM id aa15978; 26 Aug 92 16:08 EDT Received: from lucid.com by BBN.COM id aa07467; 26 Aug 92 16:00 EDT Received: from oakland-hills.lucid ([192.31.212.153]) by heavens-gate.lucid.com id AA29488g; Wed, 26 Aug 92 12:49:20 PDT Received: by oakland-hills.lucid (4.1/SMI-4.1) id AA06678; Wed, 26 Aug 92 12:55:26 PDT Date: Wed, 26 Aug 92 12:55:26 PDT From: york%oakland-hills@lucid.com (Bill York) Message-Id: <9208261955.AA06678@oakland-hills.lucid> To: delisio@tc.pw.com Cc: clim@BBN.COM In-Reply-To: Jefferson DeLisio's message of Wed, 26 Aug 1992 10:59-0700 <19920826175912.3.DELISIO@yen.tc.pw.com> Subject: presentations outside of frame panes Reply-To: York@lucid.com Date: Wed, 26 Aug 1992 10:59-0700 From: Jefferson DeLisio I would like to pop up a temporary window over one of my application frame panes and display active presentations associated with that frame. I tried this once in the past with no success - i.e. the presentations were not mouse-sensitive - and resorted to using TRACKING-POINTER. Now I really need the functionality of a large set of my presentations and don't wish to duplicate the effort. I think that all you have to do is to set the input-buffer of the newly-created window to be the same as one of the frame's panes. That is, (setf (stream-input-buffer new-win) (stream-input-buffer (get-frame-pane frame 'foo))) This will allow the new window to participate in presentation sensitivity and selection just as if it were one of the panes.   Received: from BBN.COM by LABS-N.BBN.COM id aa17118; 26 Aug 92 17:33 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa12141; 26 Aug 92 17:26 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1131411; 26 Aug 1992 17:26:54-0400 Date: Wed, 26 Aug 1992 17:27-0400 From: Scott McKay Subject: presentations outside of frame panes To: delisio@tc.pw.com, clim@BBN.COM In-Reply-To: <19920826175912.3.DELISIO@yen.tc.pw.com> Message-ID: <19920826212708.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 26 Aug 1992 13:59 EDT From: Jefferson DeLisio I would like to pop up a temporary window over one of my application frame panes and display active presentations associated with that frame. I tried this once in the past with no success - i.e. the presentations were not mouse-sensitive - and resorted to using TRACKING-POINTER. Now I really need the functionality of a large set of my presentations and don't wish to duplicate the effort. Any pointers? Details, details, details - (GENERA 8.1 CLIM 1.0) (CLOE 3.1 CLIM 1.0) (ALLEGRO 4.1 CLIM 1.1) I think that if you make the temporary window share the same input with the application frame (all of whose panes share a single input buffer), then the right thing should just magically happen. Try SETFing CLIM:STREAM-INPUT-BUFFER of the temp window to CLIM:STREAM-INPUT-BUFFER of one of the application's panes, and see what happens.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa17493; 26 Aug 92 17:58 EDT Received: by KARIBA.BBN.COM id aa26179; 26 Aug 92 17:49 EDT To: clim@BBN.COM cc: faes-dev@BBN.COM, bugs@franz.com Subject: clim contrasting colors Date: Wed, 26 Aug 92 17:51:04 -0400 Message-ID: <4743.714865864@bbn.com> From: Jeff Morrill (clim 1.1, allegro 4.1) We recently borrowed an interior decorator to decorate our windows. He decided, for color screens, that the window background should be clim:+royal-blue+ and the window foreground should be clim:+white+. I have discovered that these two inks are identical ("white") on a B&W Sun OpenWindows display. This makes it rather difficult to use the program. The colors are specified as the :stream-foreground and :stream-background :panes options to define-application-frame. These options are evaluated at compile time as far as I can tell, which is obviously too early for me to examine the characteristics of the stream or the display and then select an appropriate ink. I suppose clim:make-contrasting-inks was invented to solve this problem. But it does not do as good of a job as our decorator in choosing snazzy colors. Does clim 1 have a way around this problem? jeff morrill   Received: from BBN.COM by LABS-N.BBN.COM id aa24811; 27 Aug 92 9:41 EDT Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa27997; 27 Aug 92 9:26 EDT Received: from LILIKOI.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 893238; 27 Aug 1992 09:27:46-0400 Date: Thu, 27 Aug 1992 09:42-0400 From: Mark Nahabedian Subject: clim contrasting colors To: jmorrill@BBN.COM, clim@BBN.COM cc: faes-dev@BBN.COM, bugs@franz.com In-Reply-To: <4743.714865864@bbn.com> Message-ID: <19920827134218.0.NAHA@LILIKOI.SCRC.Symbolics.COM> Date: Wed, 26 Aug 1992 17:51 EDT From: Jeff Morrill (clim 1.1, allegro 4.1) We recently borrowed an interior decorator to decorate our windows. He decided, for color screens, that the window background should be clim:+royal-blue+ and the window foreground should be clim:+white+. I have discovered that these two inks are identical ("white") on a B&W Sun OpenWindows display. This makes it rather difficult to use the program. The colors are specified as the :stream-foreground and :stream-background :panes options to define-application-frame. These options are evaluated at compile time as far as I can tell, which is obviously too early for me to examine the characteristics of the stream or the display and then select an appropriate ink. I suppose clim:make-contrasting-inks was invented to solve this problem. But it does not do as good of a job as our decorator in choosing snazzy colors. Does clim 1 have a way around this problem? jeff morrill Couldn't you initialize the foreground and background inks in an initialize-instance :after method?   Received: from BBN.COM by LABS-N.BBN.COM id aa26563; 27 Aug 92 10:57 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa02978; 27 Aug 92 10:52 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1131780; 27 Aug 1992 10:52:32-0400 Date: Thu, 27 Aug 1992 10:52-0400 From: Scott McKay Subject: clim contrasting colors To: jmorrill@BBN.COM, clim@BBN.COM cc: faes-dev@BBN.COM, bugs@franz.com In-Reply-To: <4743.714865864@bbn.com> Supersedes: <19920827145244.3.SWM@SUMMER.SCRC.Symbolics.COM> Message-ID: <19920827145250.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 26 Aug 1992 17:51 EDT From: Jeff Morrill (clim 1.1, allegro 4.1) We recently borrowed an interior decorator to decorate our windows. He decided, for color screens, that the window background should be clim:+royal-blue+ and the window foreground should be clim:+white+. IMHO, your interior decorator should read (or re-read) the books by Edward Tufte (especially the parts on typographic design) and the book called "Ogilvie on Advertising". Both of these people make fairly clear cases for why light letters on dark backgrounds are a typographic mistake. I agree with them, even though I seem to be increasingly in the minority in this area. I have discovered that these two inks are identical ("white") on a B&W Sun OpenWindows display. This makes it rather difficult to use the program. Huh? This is very odd. The colors are specified as the :stream-foreground and :stream-background :panes options to define-application-frame. These options are evaluated at compile time as far as I can tell, which is obviously too early for me to examine the characteristics of the stream or the display and then select an appropriate ink. Are medium-foreground and medium-background of the streams in question really clim:+royal-blue+ and clim:+white+? If they are, something bad is happening in the decoding of inks... I don't have a color X screen in front of me, so I guess someone at Franz Inc will have to look at this. I suppose clim:make-contrasting-inks was invented to solve this problem. But it does not do as good of a job as our decorator in choosing snazzy colors. It's not meant to do a snazzy job, just a "loud" job. Does clim 1 have a way around this problem? It should work, barring bugs.   Received: from BBN.COM by LABS-N.BBN.COM id aa26531; 27 Aug 92 10:57 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa02965; 27 Aug 92 10:51 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1131779; 27 Aug 1992 10:52:26-0400 Date: Thu, 27 Aug 1992 10:52-0400 From: Scott McKay Subject: clim contrasting colors To: jmorrill@BBN.COM, clim@BBN.COM cc: faes-dev@BBN.COM, bugs@franz.com In-Reply-To: <4743.714865864@bbn.com> Message-ID: <19920827145244.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 26 Aug 1992 17:51 EDT From: Jeff Morrill (clim 1.1, allegro 4.1) We recently borrowed an interior decorator to decorate our windows. He decided, for color screens, that the window background should be clim:+royal-blue+ and the window foreground should be clim:+white+. IMHO, your interior decorator should read (or re-read) the books by Edward Tufte (especially the parts on typographic design) and the book called "Ogilvie on Advertising". Both of these people make fairly clear cases for why light letters on dark backgrounds are a typographic mistake. I agree with them, even though I seem to be increasingly in the minority in this area. I have discovered that these two inks are identical ("white") on a B&W Sun OpenWindows display. This makes it rather difficult to use the program. Huh? This is very odd. The colors are specified as the :stream-foreground and :stream-background :panes options to define-application-frame. These options are evaluated at compile time as far as I can tell, which is obviously too early for me to examine the characteristics of the stream or the display and then select an appropriate ink. Are medium-foreground and medium-background of the streams in question really clim:+royal-blue+ and clim:+white+? If they are, something bad is happening in the decoding of inks... I don't have a color X screen in front of me, so I guess someone at Franz Inc will have to look at this. I suppose clim:make-contrasting-inks was invented to solve this problem. But it does not do as good of a job as our decorator in choosing snazzy colors. It's not meant to do a snazzy job, just a "loud" job. Does clim 1 have a way around this problem? It should work.   Received: from BBN.COM by LABS-N.BBN.COM id aa27282; 27 Aug 92 11:49 EDT Received: from [129.197.134.99] by BBN.COM id aa05514; 27 Aug 92 11:43 EDT Received: from jade.rdd.lmsc.lockheed.com by dipl.rdd.lmsc.lockheed.com (4.0/SMI-4.1) id AA01418; Thu, 27 Aug 92 08:41:54 PDT Received: from cluso.lmsc.com by jade.rdd.lmsc.lockheed.com (4.1/SMI-4.0) id AA11104; Thu, 27 Aug 92 08:41:48 PDT Date: Thu, 27 Aug 92 08:41:48 PDT From: ttrinko@dipl.rdd.lmsc.lockheed.com (Tom Trinko) Message-Id: <9208271541.AA11104@jade.rdd.lmsc.lockheed.com> To: clim@bbn.com Subject: output records and presentations I'm converting a dw application to clim, genera 8.1 clim 1.1, and I'm having a problem with changing the display. I represent an object as a text string with an outline rectangle around it. The length of the string can change depending upon the underlying state of the object. Under dw I used erase-displayed- presentation in a before method associated with the display method for the object. This erased the old display prior to drawing the new display. Question whats the right way to do this in clim? I tried using erase-output-record on the presentation but it turns out that the presentation is not a displayed-output-record-element. It is an output-record though. The parent of the objects presentation is the history record. I don't understand how the presentation can not be a displayed-output-record element since the objects display is on the screen and mouse sensitive. Thanks of any help. By the way i strongly recommend that a manual of example translations be published showing how to go from dw to clim. It'd make porting, and hence using symbolics machines as development platforms, a lot easier.   Received: from BBN.COM by LABS-N.BBN.COM id aa28014; 27 Aug 92 12:48 EDT Received: from iraun1.ira.uka.de by BBN.COM id aa08112; 27 Aug 92 12:42 EDT Received: from gate.fzi.de by iraun1.ira.uka.de with SMTP (PP) id <28567-0@iraun1.ira.uka.de>; Thu, 27 Aug 1992 18:42:29 +0200 Received: from negro.fzi.de by gate.fzi.de.fzi.de id aa25043; 27 Aug 92 16:46 GMT Received: by negro (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA02129; Thu, 27 Aug 92 18:42:09 GMT+0100 Date: Thu, 27 Aug 92 18:42:09 GMT+0100 From: res Message-Id: <9208271742.AA02129@negro> Original-Received: by NeXT Mailer (1.63) PP-warning: Illegal Received field on preceding line To: clim@bbn.com Subject: Incompatibility of ctv-menu and CLIM 1.1 After installing CLIM 1.1 (incl. sources) under Genera 8.1.1 we ran into an CLX error when calling MENU-CHOOSE from the (unsupported, I know) package CTV-MENU. The bug consisted in a method call for setting window manager size hints which was applied to nil. As we hadn't encountered this problem in CLIM 1.0 we traced the bug down to the method clim::with-menu-as-popup-internal in the file CLX-IMPLEMENTATION.LISP. There the SIZE-HINTS object of the menu window is accessed and size hint values for the window manager under CLX are set. Obviously, the menu window doesn't ususally have this size hints object, thus leading to the bug. We fixed this by checking first if SIZE-HINTS is non-nil before accessing slot values of it. Is this a known bug or does it depend on our version of CTV-MENU? Bernd Wild =============================================== Bernd Wild Forschungszentrum Informatik FZI Dept. Technical Expert Systems and Robotics Haid-und-Neu-Strasse 10-14 D-7500 Karlsruhe GERMANY Tel: +49-721-9654-310 Fax: +49-721-9654-309 email: bwild@fzi.de ===============================================   Received: from BBN.COM by LABS-N.BBN.COM id aa28807; 27 Aug 92 13:59 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa11125; 27 Aug 92 13:53 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1131919; 27 Aug 1992 13:06:11-0400 Date: Thu, 27 Aug 1992 13:06-0400 From: Scott McKay Subject: output records and presentations To: ttrinko@dipl.rdd.lmsc.lockheed.com, clim@BBN.COM In-Reply-To: <9208271541.AA11104@jade.rdd.lmsc.lockheed.com> Message-ID: <19920827170616.9.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 27 Aug 1992 11:41 EDT From: Tom Trinko I'm converting a dw application to clim, genera 8.1 clim 1.1, and I'm having a problem with changing the display. I represent an object as a text string with an outline rectangle around it. The length of the string can change depending upon the underlying state of the object. Under dw I used erase-displayed- presentation in a before method associated with the display method for the object. This erased the old display prior to drawing the new display. One quick question: did you try using the DW->CLIM conversion tools in Genera? Question whats the right way to do this in clim? I tried using erase-output-record on the presentation but it turns out that the presentation is not a displayed-output-record-element. It is an output-record though. The parent of the objects presentation is the history record. I don't understand how the presentation can not be a displayed-output-record element since the objects display is on the screen and mouse sensitive. Thanks of any help. By the way i strongly recommend that a manual of example translations be published showing how to go from dw to clim. It'd make porting, and hence using symbolics machines as development platforms, a lot easier.   Received: from BBN.COM by LABS-N.BBN.COM id aa29643; 27 Aug 92 14:58 EDT Received: from harvard.harvard.edu by BBN.COM id aa13308; 27 Aug 92 14:53 EDT Received: by harvard.harvard.edu (5.54/a0.25) (for clim@bbn.com) id AA01671; Thu, 27 Aug 92 14:53:21 EDT Received: by gensym.com (4.0/SMI-3.2) id AA28047; Thu, 27 Aug 92 13:30:37 EDT Date: Thu, 27 Aug 92 13:30:37 EDT From: gensym!bhyde@harvard.harvard.edu (Ben A. Hyde) Message-Id: <9208271730.AA28047@gensym.com> To: clim@bbn.com Subject: updating-output CLIM 2.0 I'm reading the CLIM Release 2.0 Specification, May 6, 92. While I'm not a CLIM user, I've built a huge amount of UI over the years and I'm finding it very interesting. Lots of questions come to mind, but let me start with one. Updating-output is very like a construct I've used in other programs, i.e. you write a routine that displays your output. Then you discover that you want that same routine to do other things, like update the screen when the underlying document changes. The operations enabled by having a path of unique-ids, and a cached-value (aka update tick) are also a UI trick I've seen in many programs. It is hard to tell in CLIM what features are excess junk piled on to please the ivory tower, and verses the stuff added to clarify the performance and interface. For example I'm am not surprized that designs are a superclass of regions. This more of a problem for people who haven't actually built a complex UI. In anycase, my question. Is it necessary to entangle the rich output records with the concept of updating-output. In system's I've built it is cheap to generate the output. That building, maintaining, walking, etc. any backing store is expensive and slow. In system's I've built the concept of updating output use the screen bits as it's only output cache. I'm having trouble developing an affection for CLIM's rich backing store. Most programs I've been involved in do not maintain an output cache (other that the screen bits), and I'm having trouble seeing that it is necessary. Couldn't the routine captured by updating-output provide all the services that the output record is? I've always it asked to. - ben hyde, Gensym Inc. Cambridge   Received: from BBN.COM by LABS-N.BBN.COM id aa00821; 27 Aug 92 16:27 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa16921; 27 Aug 92 16:20 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1132080; 27 Aug 1992 16:20:53-0400 Date: Thu, 27 Aug 1992 16:21-0400 From: Scott McKay Subject: updating-output CLIM 2.0 To: gensym!bhyde@harvard.harvard.edu, clim@BBN.COM In-Reply-To: <9208271730.AA28047@gensym.com> Message-ID: <19920827202106.6.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 27 Aug 1992 13:30 EDT From: "Ben A. Hyde" I'm reading the CLIM Release 2.0 Specification, May 6, 92. While I'm not a CLIM user, I've built a huge amount of UI over the years and I'm finding it very interesting. Lots of questions come to mind, but let me start with one. Updating-output is very like a construct I've used in other programs, i.e. you write a routine that displays your output. Then you discover that you want that same routine to do other things, like update the screen when the underlying document changes. The operations enabled by having a path of unique-ids, and a cached-value (aka update tick) are also a UI trick I've seen in many programs. It is hard to tell in CLIM what features are excess junk piled on to please the ivory tower, and verses the stuff added to clarify the performance and interface. For example I'm am not surprized that designs are a superclass of regions. This more of a problem for people who haven't actually built a complex UI. In anycase, my question. Is it necessary to entangle the rich output records with the concept of updating-output. In system's I've built it is cheap to generate the output. That building, maintaining, walking, etc. any backing store is expensive and slow. In system's I've built the concept of updating output use the screen bits as it's only output cache. I'm having trouble developing an affection for CLIM's rich backing store. Most programs I've been involved in do not maintain an output cache (other that the screen bits), and I'm having trouble seeing that it is necessary. Couldn't the routine captured by updating-output provide all the services that the output record is? I've always it asked to. - ben hyde, Gensym Inc. Cambridge UPDATING-OUTPUT is a relatively straight-forward extension on top of the rest of output recording. So are presentations, which require more than "just bits" to do their work. So are the other high-level formatted output tools. So I am not sure how exactly to answer your questions. But the fact that some UI systems have only the screen bits as what you call an "output cache" is one of the problems with those UI systems. Even raw X Windows has more than that -- there are all those window-ish things floating around. CLIM output recording provides the ability to retain the *intention* of the program output, not just the bits. When used for presentations, this frees the programmer from having to manage all of the usual application-specific bookkeeping himself (especially the stuff related to using the mouse to point to stuff on the screen). It is simple to either turn of output recording if you don't need it, or special output recording to take advantage of application-specific knowledge, too. But ultimately, if your applications do not require what CLIM has to offer, you shouldn't use CLIM. (That's not meant to be a sour grapes statement -- for some things, CLIM is just too much.) BTW, there is basically nothing in CLIM to please anybody in any ivory tower. Almost everything is there to solve a real-world need, although some things are more specialized and/or less successful than others.   Received: from BBN.COM by LABS-N.BBN.COM id aa05663; 28 Aug 92 3:48 EDT Received: from ptolemy-arclan.arc.nasa.gov by BBN.COM id aa27046; 28 Aug 92 3:44 EDT Received: from mcc2.arc.nasa.gov by ptolemy.arc.nasa.gov (4.1/) id ; Fri, 28 Aug 92 00:44:22 PDT Date: Fri, 28 Aug 92 00:44:22 PDT From: Philip Chu-Summer 92 Message-Id: <9208280744.AA27237@ptolemy.arc.nasa.gov> Received: by mcc2.arc.nasa.gov (4.1/SMI-4.1) id AA01007; Fri, 28 Aug 92 00:44:51 PDT To: clim@bbn.com Subject: clim contrib I've placed some code for a file chooser and dialogs for selecting color and line and text styles on cambridge.apple.com:/pub/clim. A brief description on how to use the code is at the head of the file. The code was written with CLIM 2.0alpha and Franz Allegro Common Lisp. Good luck, should you decide to use it. Phil Chu Artificial Intelligence Research Branch NASA Ames Research Center pchu@ptolemy.arc.nasa.gov   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa09441; 28 Aug 92 10:40 EDT Received: by KARIBA.BBN.COM id aa11085; 28 Aug 92 10:31 EDT To: "Ben A. Hyde" cc: clim@BBN.COM Subject: Re: updating-output CLIM 2.0 In-reply-to: "Ben A. Hyde"'s message of Thu, 27 Aug 92 13:30:37 -0400. <9208271730.AA28047@gensym.com> Reply-To: jmorrill@BBN.COM Date: Fri, 28 Aug 92 10:26:47 -0400 Message-ID: <5144.715012007@bbn.com> From: Jeff Morrill Date: Thu, 27 Aug 92 13:30:37 EDT From: "Ben A. Hyde" I'm reading the CLIM Release 2.0 Specification, May 6, 92. While I'm not a CLIM user, I've built a huge amount of UI over the years and I'm finding it very interesting. Lots of questions come to mind, but let me start with one. Updating-output is very like a construct I've used in other programs, i.e. you write a routine that displays your output. Then you discover that you want that same routine to do other things, like update the screen when the underlying document changes. The operations enabled by having a path of unique-ids, and a cached-value (aka update tick) are also a UI trick I've seen in many programs. It is hard to tell in CLIM what features are excess junk piled on to please the ivory tower, and verses the stuff added to clarify the performance and interface. For example I'm am not surprized that designs are a superclass of regions. This more of a problem for people who haven't actually built a complex UI. In anycase, my question. Is it necessary to entangle the rich output records with the concept of updating-output. In system's I've built it is cheap to generate the output. That building, maintaining, walking, etc. any backing store is expensive and slow. In system's I've built the concept of updating output use the screen bits as it's only output cache. I'm having trouble developing an affection for CLIM's rich backing store. Most programs I've been involved in do not maintain an output cache (other that the screen bits), and I'm having trouble seeing that it is necessary. Couldn't the routine captured by updating-output provide all the services that the output record is? I've always it asked to. - ben hyde, Gensym Inc. Cambridge Output recording can be turned off if you don't think you need it. In that case, I have found that you get nearly the same performance as the underlying window system. The default kind of output recording is indeed expensive, but unless you exceed hundreds of output records, the expense is not noticeable. I believe that if someone profiled its performance, the main expense would be in calling MAKE-INSTANCE for each output record (and later collecting all of the instances as garbage). Once constructed, however, replaying the output history should be at least as fast as generating output with output recording disabled. In my experience, displays that exceed hundreds of output records tend to be displaying a structure for which there is a corresponding data structure maintained by the programmer. In that case, it is possible to specialize clim's output-recording protocol to use the programmer's data structure to represend both itself and the output history of the window. For example, drawing a graph of 100,000 individually mouse-sensitive data points is important to me. With some help (from SWM) I was able to construct the graph data once and then hand it to the window saying "here is your output history". Replaying the data was as fast as generating the output with output recording disabled, but this way each data point is a presentation. [In the next round of CLIM documentation, it would be nice to see an example of something like this!] I'm not sure the jury is in on updating-output. You need it most when the display is NOT CHEAP to generate. Suppose for my 100,000 point graph I want to change the units from "Fortnights" to "Furlongs". Walking the output history is not expensive as long as there is a caching-point that encapsulates the entire 100,000 points of data, so that clim doesn't have to inspect each point. Although updating-output works OK for relatively simple displays, when you don't really need it, I have had terrible luck with complicated displays. In my opinion it is too slow and too buggy. Nevertheless, I find myself using it (though not for graphs). In defense of the implementors, it is a hard thing to do for the general case. I think everyone feels that there is "excess junk" in clim, but nobody seems to agree about which parts are the junk. Each feature makes some constituency happy. If the specification is not going to get smaller, then I would like to see CLIM broken into libraries. For example, all those color symbols (+white+ etc) should probably be put into a file that can be loaded if you need it, but if you don't need it your lisp image will be that much smaller. jeff morrill   Received: from BBN.COM by LABS-N.BBN.COM id aa09392; 28 Aug 92 10:34 EDT Received: from aerospace.aero.org by BBN.COM id aa08947; 28 Aug 92 10:18 EDT Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT) id AA20855 for clim@bbn.com; Fri, 28 Aug 1992 07:17:53 -0700 Posted-Date: Fri, 28 Aug 92 07:17:51 PDT Message-Id: <199208281417.AA20855@aerospace.aero.org> Received: from reify.aero.org by antares.aero.org (4.1/AMS-1.0) id AA01928 for clim@bbn.com; Fri, 28 Aug 92 07:17:52 PDT Date: Fri, 28 Aug 92 07:17:51 PDT From: abbott@aero.org To: clim@bbn.com Subject: Updating the screen from a separate process I have a multi-process clim application. The main process uses clim to interact with the user. A second process accepts data from an external source and updates the internal data structures that the first process uses to paint the screen. Whenever the second process gets new data, I would like it to call the display-function that the first process uses. Unfortunately, such a call is apparently incompatible with the normal call to the display-function from the first process; the screen gets completely messed up. An alternative would be for the second process to have some way of triggering a display cycle in the first process. I don't know how to do that. Does anyone? Thanks. -- Russ Abbott   Received: from BBN.COM by LABS-N.BBN.COM id aa10429; 28 Aug 92 12:12 EDT Received: from harvard.harvard.edu by BBN.COM id aa14138; 28 Aug 92 12:08 EDT Received: by harvard.harvard.edu (5.54/a0.25) (for clim@bbn.com) id AA21497; Fri, 28 Aug 92 12:08:19 EDT Received: by gensym.com (4.0/SMI-3.2) id AA00727; Fri, 28 Aug 92 11:54:44 EDT Date: Fri, 28 Aug 92 11:54:44 EDT From: gensym!bhyde@harvard.harvard.edu (Ben A. Hyde) Message-Id: <9208281554.AA00727@gensym.com> To: clim@bbn.com Subject: Required standard gesture names. Why are these required standard gesture names? :clear-input :complete :possibilities :describe :menu :edit :delete It seems to me that these are not found in most main stream graphic applications. Requiring them pulls CLIM based applications in a direction that the main stream of graphic applications have choosen (usually for good reason) not to head. - ben   Received: from BBN.COM by LABS-N.BBN.COM id aa10524; 28 Aug 92 12:24 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa14514; 28 Aug 92 12:20 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1132540; 28 Aug 1992 12:20:43-0400 Date: Fri, 28 Aug 1992 12:21-0400 From: Scott McKay Subject: Re: clim contrasting colors To: jmorrill@BBN.COM, clim@BBN.COM cc: moon@CAMBRIDGE.APPLE.COM, faes-dev@BBN.COM, bugs@franz.com In-Reply-To: <9208281544.AA09153@cambridge.apple.com> Message-ID: <19920828162102.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 28 Aug 1992 11:45 EDT From: moon@cambridge.apple.com (David A. Moon) [other recipients deleted] [Added back again] > Date: Thu, 27 Aug 1992 10:52-0400 > From: Scott McKay > Subject: clim contrasting colors > To: jmorrill@BBN.COM, clim@BBN.COM > Cc: faes-dev@BBN.COM, bugs@franz.com > In-Reply-To: <4743.714865864@bbn.com> > > Date: Wed, 26 Aug 1992 17:51 EDT > From: Jeff Morrill > > (clim 1.1, allegro 4.1) > > We recently borrowed an interior decorator to decorate our windows. > He decided, for color screens, that the window background should > be clim:+royal-blue+ and the window foreground should be clim:+white+. > > I have discovered that these two inks are identical ("white") on a B&W Sun > OpenWindows display. This makes it rather difficult to use the program. > > Huh? This is very odd. You may have missed the three key letters "B&W". It's true on other platforms, probably all platforms, that some colors that contrast on a color display map to the same color on a monochrome display. This is just unavoidable as long as absolute colors are used by applications, rather than some kind of logical specifications with some semantics to them that can be mapped with knowledge of the specific display. Although another set of recent mail in my bloated mailbox seems to indicate that some third party Macintosh display controllers lie when you ask them what their color palette is. Grr. Dave just pointed out that I misread this message, omitted that key "B&W". Sorry about that. What happens when you draw with a color on B&W screen, is that CLIM generates a stipple that corresponds to the "luminosity" of the color. Unfortunately, CLIM 1.1 uses a bogus formula for figuring out the luminosity. The thing shafting you (Jeff) in this case is that the CLIM actually stipples (1- luminosity), so that inks that should be dark come out light! Anyway, this has been fixed in CLIM 2.0. You can either work around this by picking a different background on B&W screens, or I can try to get a fix to you. (I'm frantically trying to put together a CLIM 2.0 beta release, so I would obviously prefer for you to work around the problem for the time being...)   Received: from BBN.COM by LABS-N.BBN.COM id aa10024; 28 Aug 92 11:41 EDT Received: from elroy.jpl.nasa.gov by BBN.COM id aa12608; 28 Aug 92 11:33 EDT Received: from eraserhead.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA03487; Fri, 28 Aug 92 08:33:00 PDT Received: by eraserhead.Jpl.Nasa.Gov (4.1/SMI-3.4+DXR+sub) id AA01539; Fri, 28 Aug 92 08:25:09 PDT Date: Fri, 28 Aug 92 08:25:09 PDT From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer) Message-Id: <9208281525.AA01539@eraserhead.Jpl.Nasa.Gov> To: clim@bbn.com Subject: CLIM updating-output echo I wish to echo Jeff Morrill sentiments (especially the bit about an example of implementation of custom output-record protocols). In my particular case my data representation emulates precisely the way I wish to maintain my own output-record history. But ... boy was it a TE (trial and error) experience in getting it to work without any documented examples for creating your own history tree. The output-record clim docs were basically like a description of various food ingredients without a much needed recipe describing how you put it together to get your desired gourmet dish.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa10733; 28 Aug 92 12:54 EDT Received: by KARIBA.BBN.COM id aa12486; 28 Aug 92 12:44 EDT To: Scott McKay cc: clim@BBN.COM, faes-dev@BBN.COM, bugs@franz.com Subject: Re: clim contrasting colors In-reply-to: Scott McKay's message of Fri, 28 Aug 92 12:21:00 -0400. <19920828162102.4.SWM@SUMMER.SCRC.Symbolics.COM> Reply-To: jmorrill@BBN.COM Date: Fri, 28 Aug 92 12:37:08 -0400 Message-ID: <6034.715019828@bbn.com> From: Jeff Morrill Anyway, this has been fixed in CLIM 2.0. Can't wait. You can either work around this by picking a different background on B&W screens, or I can try to get a fix to you. I already worked around it. I didn't really want stippled windows anyway. In clim 2 it's not even an issue for me because I prefer using my .Xdefaults file to set the colors. (I'm frantically trying to put together a CLIM 2.0 beta release, so I would obviously prefer for you to work around the problem for the time being...) I am frantically waiting for it.   Received: from BBN.COM by LABS-N.BBN.COM id aa11040; 28 Aug 92 13:28 EDT Received: from Sunset.AI.SRI.COM by BBN.COM id aa16731; 28 Aug 92 13:24 EDT Received: from rockaway.ai.sri.com by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA20789 for clim@BBN.COM; Fri, 28 Aug 92 10:24:22 PDT Received: by rockaway.ai.sri.com (4.1/SMI-4.1) id AA02420 for clim@BBN.COM; Fri, 28 Aug 92 10:24:21 PDT Date: Fri, 28 Aug 92 10:24:20 PDT From: Peter Karp To: res Cc: clim@BBN.COM Subject: Re: Incompatibility of ctv-menu and CLIM 1.1 In-Reply-To: Your message of Thu, 27 Aug 92 18:42:09 GMT+0100 Message-Id: There's some chance that the problem you see is due to a bug in CTV-MENU where I was calling clim:open-window-stream with the wrong keyword argument names. You might try the new version that is now available for FTP on ai.sri.com. There are a few other minor bug fixes as well. Peter   Received: from BBN.COM by LABS-N.BBN.COM id aa12423; 28 Aug 92 15:11 EDT Received: from ptolemy-arclan.arc.nasa.gov by BBN.COM id aa20981; 28 Aug 92 15:04 EDT Received: from erebus.arc.nasa.gov by ptolemy.arc.nasa.gov (4.1/) id ; Fri, 28 Aug 92 12:03:41 PDT Date: Fri, 28 Aug 92 12:03:41 PDT From: Philip Chu-Summer 92 Message-Id: <9208281903.AA29567@ptolemy.arc.nasa.gov> Received: by erebus.arc.nasa.gov (4.1/SMI-4.1) id AA00445; Fri, 28 Aug 92 12:04:01 PDT To: gmw@cypress.mitre.org Cc: clim@bbn.com In-Reply-To: Gregory M. Whittaker's message of Fri, 28 Aug 92 08:21:45 EDT <9208281221.AA01986@cypress.mitre.org> Subject: clim contrib Date: Fri, 28 Aug 92 08:21:45 EDT From: gmw@cypress.mitre.org (Gregory M. Whittaker) Phil, I've downloaded your contributions, but do not have BinHex 4.0. Can you describe its functionality. The .hqx file looks like its been uucp'd. If there isn't a standard decompression sequence could you inform me of the whereabouts of BinHex 4.0? -------- Cordially, Gregory M. Whittaker, The MITRE Corporation Center for Advanced Aviation System Development Internet: greg@mitre.org 7525 Colshire Drive Phone: (703) 883-5549 McLean Virginia 22102-3481 FAX: (703) 883-1226 Mail Stop: W215 Sorry, I forgot to mention that the file is "chooser.lisp", not the .hqx file. Phil Chu Artificial Intelligence Research Branch NASA Ames Research Center pchu@ptolemy.arc.nasa.gov   Received: from BBN.COM by LABS-N.BBN.COM id aa13465; 28 Aug 92 16:24 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa27406; 28 Aug 92 16:15 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1132710; 28 Aug 1992 16:16:45-0400 Date: Fri, 28 Aug 1992 16:17-0400 From: Scott McKay Subject: Updating the screen from a separate process To: abbott@aero.org, clim@BBN.COM In-Reply-To: <199208281417.AA20855@aerospace.aero.org> Message-ID: <19920828201706.6.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 28 Aug 1992 10:17 EDT From: abbott@aero.org I have a multi-process clim application. The main process uses clim to interact with the user. A second process accepts data from an external source and updates the internal data structures that the first process uses to paint the screen. Whenever the second process gets new data, I would like it to call the display-function that the first process uses. Unfortunately, such a call is apparently incompatible with the normal call to the display-function from the first process; the screen gets completely messed up. Are you calling the pane's display function directly, or calling CLIM:REDISPLAY-FRAME-PANE? Are you using incremental redisplay? Do the two processes compete for a lock that prevents CLIM's internal datastructures from getting messed up? You can use CLIM-UTILS::INITIAL-LOCK-VALUE to create a lock, and CLIM-UTILS::WITH-LOCKF to hold it. In CLIM 2.0, these will be exported (under different names) from the CLIM-SYS package. An alternative would be for the second process to have some way of triggering a display cycle in the first process. I don't know how to do that. Does anyone? Thanks. -- Russ Abbott   Received: from BBN.COM by LABS-N.BBN.COM id aa13388; 28 Aug 92 16:15 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa26998; 28 Aug 92 16:09 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1132707; 28 Aug 1992 16:10:16-0400 Date: Fri, 28 Aug 1992 16:10-0400 From: Scott McKay Subject: Re: updating-output CLIM 2.0 To: jmorrill@BBN.COM, gensym!bhyde@harvard.harvard.edu cc: clim@BBN.COM In-Reply-To: <5144.715012007@bbn.com> Message-ID: <19920828201037.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 28 Aug 1992 10:26 EDT From: Jeff Morrill [In the next round of CLIM documentation, it would be nice to see an example of something like this!] Indeed, JGA and I plan to do this. I'm not sure the jury is in on updating-output. You need it most when the display is NOT CHEAP to generate. Suppose for my 100,000 point graph I want to change the units from "Fortnights" to "Furlongs". Walking the output history is not expensive as long as there is a caching-point that encapsulates the entire 100,000 points of data, so that clim doesn't have to inspect each point. Although updating-output works OK for relatively simple displays, when you don't really need it, I have had terrible luck with complicated displays. In my opinion it is too slow and too buggy. Nevertheless, I find myself using it (though not for graphs). In defense of the implementors, it is a hard thing to do for the general case. Without trying to defend any of us implementors, it really is hard to get UPDATING-OUTPUT to work really well, really fast. UPDATING-OUTPUT is presently worse than it should be in both respects, but I just don't know how we are ever going to get it to be as good as we would all like it to be. I think everyone feels that there is "excess junk" in clim, but nobody seems to agree about which parts are the junk. Each feature makes some constituency happy. If the specification is not going to get smaller, then I would like to see CLIM broken into libraries. For example, all those color symbols (+white+ etc) should probably be put into a file that can be loaded if you need it, but if you don't need it your lisp image will be that much smaller. This is all true. The folks at Franz Inc have been thinking about this.   Received: from BBN.COM by LABS-N.BBN.COM id aa14094; 28 Aug 92 17:32 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa01089; 28 Aug 92 17:27 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1132827; 28 Aug 1992 17:28:18-0400 Date: Fri, 28 Aug 1992 17:28-0400 From: Scott McKay Subject: Required standard gesture names. To: gensym!bhyde@harvard.harvard.edu, clim@BBN.COM In-Reply-To: <9208281554.AA00727@gensym.com> Message-ID: <19920828212838.7.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 28 Aug 1992 11:54 EDT From: "Ben A. Hyde" Why are these required standard gesture names? :clear-input :complete :possibilities :describe :menu :edit :delete It seems to me that these are not found in most main stream graphic applications. Requiring them pulls CLIM based applications in a direction that the main stream of graphic applications have choosen (usually for good reason) not to head. All applications want to be able to count on a few standard gesture names. These are particularly useful ones. The first three are intended as hooks for applications that have keyboard interfaces, which some of us still like. The others are canonical names for pointer gestures. Those four, plus :SELECT, are reasonable names for a broad class of typical application commands. Also, I don't see how these gesture names pull CLIM-based applications out of any direction, mainstream or otherwise. Nothing says what the mappings have to be, just that the gestures be there. Furthermore, nothing requires that CLIM applications use these gestures, just that CLIM support them in a useful way.   Received: from BBN.COM by LABS-N.BBN.COM id aa14751; 28 Aug 92 18:58 EDT Received: from aerospace.aero.org by BBN.COM id aa03350; 28 Aug 92 18:55 EDT Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT) id AA01503 for clim@bbn.com; Fri, 28 Aug 1992 15:55:45 -0700 Posted-Date: Fri, 28 Aug 92 15:55:43 PDT Message-Id: <199208282255.AA01503@aerospace.aero.org> Received: from reify.aero.org by antares.aero.org (4.1/AMS-1.0) id AA11725 for SWM@stony-brook.scrc.symbolics.com; Fri, 28 Aug 92 15:55:44 PDT Date: Fri, 28 Aug 92 15:55:43 PDT From: abbott@aero.org To: SWM@stony-brook.scrc.symbolics.com Cc: clim@bbn.com In-Reply-To: Scott McKay's message of Fri, 28 Aug 1992 16:17-0400 <19920828201706.6.SWM@SUMMER.SCRC.Symbolics.COM> Subject: Updating the screen from a separate process | | I have a multi-process clim application. The main process uses clim to | interact with the user. A second process accepts data from an external | source and updates the internal data structures that the first process | uses to paint the screen. | | Whenever the second process gets new data, I would like it to call the | display-function that the first process uses. Unfortunately, such a | call is apparently incompatible with the normal call to the | display-function from the first process; the screen gets completely | messed up. | | Are you calling the pane's display function directly, or calling | CLIM:REDISPLAY-FRAME-PANE? Are you using incremental redisplay? Do | the two processes compete for a lock that prevents CLIM's internal | datastructures from getting messed up? I'm calling the display-function directly. I'm using incremental redisplay. The two processes do not compete for a lock. When I ran it, there was no overlap in when the two processes wrote to the pane. The input process wrote to the pane while the main process was waiting for user input. Is a lock needed in this case? If so, the main process must give up the lock while it is waiting for input, so I don't understand how such a lock would eliminate the problem. I understand that at the recent Lisp conference you and Chris Richardson acknowledged that there was a problem with multiple processes and Clim. I assumed that this was a symptom. Was that a wrong assumption? -- Russ Abbott   Received: from BBN.COM by LABS-N.BBN.COM id aa07982; 31 Aug 92 10:27 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id ab10249; 31 Aug 92 10:08 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1133437; 31 Aug 1992 10:08:46-0400 Date: Mon, 31 Aug 1992 10:09-0400 From: Scott McKay Subject: Updating the screen from a separate process To: abbott@aero.org, SWM@STONY-BROOK.SCRC.Symbolics.COM cc: clim@BBN.COM In-Reply-To: <199208282255.AA01503@aerospace.aero.org> Message-ID: <19920831140925.0.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 28 Aug 1992 18:55 EDT From: abbott@aero.org | | I have a multi-process clim application. The main process uses clim to | interact with the user. A second process accepts data from an external | source and updates the internal data structures that the first process | uses to paint the screen. | | Whenever the second process gets new data, I would like it to call the | display-function that the first process uses. Unfortunately, such a | call is apparently incompatible with the normal call to the | display-function from the first process; the screen gets completely | messed up. | | Are you calling the pane's display function directly, or calling | CLIM:REDISPLAY-FRAME-PANE? Are you using incremental redisplay? Do | the two processes compete for a lock that prevents CLIM's internal | datastructures from getting messed up? I'm calling the display-function directly. I'm using incremental redisplay. You definitely need to use CLIM:REDISPLAY-FRAME-PANE. Calling the display function directly when you are using incremental redisplay is sure to lose. The two processes do not compete for a lock. When I ran it, there was no overlap in when the two processes wrote to the pane. The input process wrote to the pane while the main process was waiting for user input. Is a lock needed in this case? If so, the main process must give up the lock while it is waiting for input, so I don't understand how such a lock would eliminate the problem. Suppose both processes are trying to do output at the same time. If this can never happen, you're OK. Otherwise your display function should take a lock during the time it is doing output. I understand that at the recent Lisp conference you and Chris Richardson acknowledged that there was a problem with multiple processes and Clim. I assumed that this was a symptom. Was that a wrong assumption? -- Russ Abbott   Received: from BBN.COM by LABS-N.BBN.COM id aa10986; 31 Aug 92 14:05 EDT Received: from eola.cs.ucf.edu by BBN.COM id aa22742; 31 Aug 92 13:57 EDT Received: by eola.cs.ucf.edu (5.61/1.34) id AA28290; Mon, 31 Aug 92 13:58:03 EDT Date: Mon, 31 Aug 92 13:58:03 EDT From: hull@eola.cs.ucf.edu (Richard Hull) Message-Id: <9208311758.AA28290@eola.cs.ucf.edu> To: clim@BBN.COM Subject: Symbolics Machine for sale We are selling a Symbolics 3653. The 3653 is a 3650 cabinet that contains 3 cpu cards and 3 harddrive cards. These cards are connected to three separate Symbolics terminals. So each terminal can be logically seen as its own machine but there really is only one cabinet. Each of the three has 9 Mbytes of memory and a 380 Mbyte ESDI hard drive. The system also has an Ethernet card for attaching one of the three (which acts as the file server), to an Ethernet network. Through the server, each terminal may access the network. The terminals are the standard Symbolics grayscale large screen terminals with keyboard and mouse. We are currently running Genera 8.0 on two of the machines and 8.1.1 (with CLIM) on the other. The system also includes a Symbolics tape drive. This system is in excellent condition and has been under a maintenance contract since they were purchased in 1990. We have had very little problems with them (one of the video displays went bad and was replaced that afternoon by a Symbolics technician). No reasonable offer will be refused. Anyone interested should direct inquiry to: Richard Hull Artificial Intelligence Lab University of Central Florida Orlando, FL 32816 (407) 823-3081 (407) 823-2341 hull@cs.ucf.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa23794; 1 Sep 92 9:57 EDT Received: from [129.197.134.99] by BBN.COM id aa09240; 1 Sep 92 9:51 EDT Received: from jade.rdd.lmsc.lockheed.com by dipl.rdd.lmsc.lockheed.com (4.0/SMI-4.1) id AA00508; Tue, 1 Sep 92 06:49:40 PDT Received: from cluso.lmsc.com by jade.rdd.lmsc.lockheed.com (4.1/SMI-4.0) id AA12104; Tue, 1 Sep 92 06:49:25 PDT Date: Tue, 1 Sep 92 06:49:25 PDT From: ttrinko@dipl.rdd.lmsc.lockheed.com (Tom Trinko) Message-Id: <9209011349.AA12104@jade.rdd.lmsc.lockheed.com> To: clim@bbn.com Subject: locks I have an application which uses two processes. Since converting to CLIM i have a new problem which might be related to the fact that both processes can be simultaneousely effecting the panes output history--yes this could be changed but it would require a great deal more work than i presently have budget for--. I saw the messages about using locks when interacting with the screen. Could someone provide a short snippet of code showing how one would use those unexported clim calls initial-lock-values and with-lockf? I understand how locks work but I don't have the foggiest which resources I need to associate with the lock in order to insure that one process doesn't change the output history record while the other process is trying to access it. Thanks.   Received: from BBN.COM by LABS-N.BBN.COM id aa24255; 1 Sep 92 10:41 EDT Received: from aerospace.aero.org by BBN.COM id aa11250; 1 Sep 92 10:34 EDT Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT) id AA21482 for clim@bbn.com; Tue, 1 Sep 1992 07:34:20 -0700 Posted-Date: Tue, 1 Sep 92 07:34:18 PDT Message-Id: <199209011434.AA21482@aerospace.aero.org> Received: from reify.aero.org by antares.aero.org (4.1/AMS-1.0) id AA27109 for ttrinko@dipl.rdd.lmsc.lockheed.com; Tue, 1 Sep 92 07:34:19 PDT Date: Tue, 1 Sep 92 07:34:18 PDT From: abbott@aero.org To: ttrinko@dipl.rdd.lmsc.lockheed.com Cc: clim@bbn.com In-Reply-To: Tom Trinko's message of Tue, 1 Sep 92 06:49:25 PDT <9209011349.AA12104@jade.rdd.lmsc.lockheed.com> Subject: locks | | I have an application which uses two processes. Since converting to CLIM i have | a new problem which might be related to the fact that both processes can | be simultaneousely effecting the panes output history--yes this could be changed | but it would require a great deal more work than i presently have budget for--. | I saw the messages about using locks when interacting with the screen. Could | someone provide a short snippet of code showing how one would use those | unexported clim calls initial-lock-values and with-lockf? I understand how | locks work but I don't have the foggiest which resources I need to associate | with the lock in order to insure that one process doesn't change the output | history record while the other process is trying to access it. Thanks. | I wrote the question to which locks were the answer. I had the same problem you do. Instead of using Clim locks, I used the locks in Allegro's multi-processing system. Since you have a multi-process application, your lisp must have some sort of lock mechanism. My code is very simple. In Allegro, mp is the multiprocess package. ;; This creates a globally accessible lock. (defvar display-lock (mp:make-process-lock)) In one process: ;; This waits until the lock is available before executing the body. ;; It then grabs the lock, locking out any other process that needs ;; this lock. (display-line write to the 'messages pane in IDM-frame.) (mp:with-process-lock (display-lock) (mapc #'(lambda(L) (display-line L Stream)) Lines)) In the other process: ;; Same here. (mp:with-process-lock (display-lock) (redisplay-frame-pane IDM-frame (get-frame-pane IDM-frame 'messages))) It seems to work! -- Russ   Received: from BBN.COM by LABS-N.BBN.COM id aa23678; 1 Sep 92 9:54 EDT Received: from mwunix.mitre.org by BBN.COM id aa08665; 1 Sep 92 9:40 EDT Return-Path: Received: from cypress.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA19020; Tue, 1 Sep 92 09:38:29 -0400 Received: by cypress.mitre.org (4.1/SMI-4.1) id AA02700; Tue, 1 Sep 92 09:46:14 EDT Date: Tue, 1 Sep 92 09:46:14 EDT From: gmw@cypress.mitre.org (Gregory M. Whittaker) Message-Id: <9209011346.AA02700@cypress.mitre.org> To: clim@BBN.COM Subject: Scale problems with-output-to-postscript-stream Some time ago I tried a with-scaling call in the middle of generating postscript output from the clim grapher, but could not find any way to coordinate the text label positions with the scaled node positions, in fact I couldn't even get the multi-page output to coordinate the graph lines very well. Using the following code fragment usually does a fair job (in this case of printing a tree-based view of class hierarchies) but is not accurate for more connected, (eg., non-tree) hierarchies. (defmethod print-subclass-tree ((name symbol) &optional (size :tiny)) (let* ((class (find-class name)) (filename (concatenate 'string (string (class-name class)) "-subclass-tree.ps"))) (with-open-file (file filename :direction :output :if-exists :supersede) (clim:with-output-to-postscript-stream (stream file :multi-page t) (clim:with-text-size (size stream) (clim:format-graph-from-root class #'(lambda (object s) (write-string (string (class-name object)) s)) #'clos:class-direct-subclasses :stream stream)))) (excl:run-shell-command (concatenate 'string "lpr " filename)))) I understand that CLIM 2.0 will provide true graph formatting, not just trees, but will CLIM 2.0 work properly with the with-scaling macro and format-graph-from-root combined? -------- Cordially, Gregory M. Whittaker, The MITRE Corporation Center for Advanced Aviation System Development Internet: greg@mitre.org 7525 Colshire Drive Phone: (703) 883-5549 McLean Virginia 22102-3481 FAX: (703) 883-1226 Mail Stop: W215   Received: from BBN.COM by LABS-N.BBN.COM id aa25285; 1 Sep 92 11:42 EDT Received: from adler.ims.uni-stuttgart.de by BBN.COM id aa14029; 1 Sep 92 11:36 EDT Received: from milan.ims.uni-stuttgart.de by adler.ims.uni-stuttgart.de (4.1/IMS-1.1) id AA02614; Tue, 1 Sep 92 17:36:01 +0200 Date: Tue, 1 Sep 92 17:36:01 +0200 From: Oliver Christ Message-Id: <9209011536.AA02614@adler.ims.uni-stuttgart.de> X-Message: The domain philosophie.uni-stuttgart.de is no longer valid. Please use the name IMS.UNI-STUTTGART.DE instead ! Received: by milan.ims.uni-stuttgart.de id AA03755; Tue, 1 Sep 92 17:36:01 +0200 To: clim@bbn.com Subject: Asynchronous Interrupts/Abort Reply-To: oli@ims.uni-stuttgart.de Dear CLIM Community, working with CLIM 1.1/Allegro v4.1, I've got the problem that I need something like asynchronous interrupts. Suppose an infinite loop is running (for example, in the clim listener of the clim demo package) and you want to interrupt this loop [try a (dotimes (i 1000) (print i)) ]. The abort character in CLIM with Allegro is bound to C-z. Pressing C-z in the listener window during the evaluation of the statement above has no effect and is read after dotimes terminates. It seems that CLIM (or CLX/XLIB) pushes key events (and, for example, resize events which are also evaluated after execution of the loop) on a queue, which is processed when CLIM comes to a read-gesture again. Tracing clim:stream-event-handler, it seems that CLIM isn't informed about these events, so it can't process them (for example, by immediately signalling clim:abort-gesture and not pushing the event on the queue). You could argue that I may interrupt the whole CLIM top-level-loop with a C-c in the shell the CLIM application was started from. But this is not acceptable, since after an abort command in a CLIM window I want to return to the top level loop running in that window, not to return to Lisp. In case of the CLIM listener, I would expect that C-z returns flow of control back to the lisp-listener-top-level. I would expect that CLIM provides a concept for the immediate processing of abort or break commands. Otherwise, many applications (the simplest of which is something like a lisp listener) may become useless -- the user has to kill the whole process if (s)he isn't able to interrupt an infinite loop or a time-expensive evaluation. Furthermore, when the CLIM application is dumped in an image and this image is started as a background process on a unix system, I don't even have a *terminal-io* on which I can enter a C-c. 'kill -9' does the job. I know that this problem could be solved with multi processing, but this would destroy the portability of the application (which is the reason why we use CLIM at the moment). Anyway, aborting the current evaluation without leaving the application is something which must be possible in any user interface (when necessary). Does anyone have similiar problems? Has anyone a 'portable' hack? I *don't* want to do a stream-peek or a 'listen' during the evaluation. Oli PS: Interrupting may work on *Symbolics* machines. Lucky guys. But it doesn't help me.   Received: from BBN.COM by LABS-N.BBN.COM id aa25555; 1 Sep 92 12:05 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa15152; 1 Sep 92 12:00 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1134251; 1 Sep 1992 12:00:19-0400 Date: Tue, 1 Sep 1992 12:01-0400 From: Scott McKay Subject: locks To: abbott@aero.org, ttrinko@dipl.rdd.lmsc.lockheed.com cc: clim@BBN.COM In-Reply-To: <199209011434.AA21482@aerospace.aero.org> Message-ID: <19920901160105.7.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 1 Sep 1992 10:34 EDT From: abbott@aero.org | | I have an application which uses two processes. Since converting to CLIM i have | a new problem which might be related to the fact that both processes can | be simultaneousely effecting the panes output history--yes this could be changed | but it would require a great deal more work than i presently have budget for--. | I saw the messages about using locks when interacting with the screen. Could | someone provide a short snippet of code showing how one would use those | unexported clim calls initial-lock-values and with-lockf? I understand how | locks work but I don't have the foggiest which resources I need to associate | with the lock in order to insure that one process doesn't change the output | history record while the other process is trying to access it. Thanks. | I wrote the question to which locks were the answer. I had the same problem you do. Instead of using Clim locks, I used the locks in Allegro's multi-processing system. Since you have a multi-process application, your lisp must have some sort of lock mechanism. My code is very simple. This doesn't do you any good for CLIM 1.0/1.1, but you should use CLIM-SYS:MAKE-LOCK and CLIM-SYS:WITH-LOCK-HELD in CLIM 2.0, since they are portable across all platforms that implement CLIM. In Allegro, mp is the multiprocess package. ;; This creates a globally accessible lock. (defvar display-lock (mp:make-process-lock)) In one process: ;; This waits until the lock is available before executing the body. ;; It then grabs the lock, locking out any other process that needs ;; this lock. (display-line write to the 'messages pane in IDM-frame.) (mp:with-process-lock (display-lock) (mapc #'(lambda(L) (display-line L Stream)) Lines)) In the other process: ;; Same here. (mp:with-process-lock (display-lock) (redisplay-frame-pane IDM-frame (get-frame-pane IDM-frame 'messages))) It seems to work! -- Russ   Received: from BBN.COM by LABS-N.BBN.COM id aa25636; 1 Sep 92 12:11 EDT Received: from aerospace.aero.org by BBN.COM id aa15560; 1 Sep 92 12:08 EDT Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT) id AA23092 for clim@bbn.com; Tue, 1 Sep 1992 09:07:59 -0700 Posted-Date: Tue, 1 Sep 92 09:07:56 PDT Message-Id: <199209011607.AA23092@aerospace.aero.org> Received: from reify.aero.org by antares.aero.org (4.1/AMS-1.0) id AA28489 for SWM@stony-brook.scrc.symbolics.com; Tue, 1 Sep 92 09:07:58 PDT Date: Tue, 1 Sep 92 09:07:56 PDT From: abbott@aero.org To: SWM@stony-brook.scrc.symbolics.com Cc: clim@bbn.com In-Reply-To: Scott McKay's message of Tue, 1 Sep 1992 12:01-0400 <19920901160105.7.SWM@SUMMER.SCRC.Symbolics.COM> Subject: locks | Date: Tue, 1 Sep 1992 12:01-0400 | From: Scott McKay | | Date: Tue, 1 Sep 1992 10:34 EDT | From: abbott@aero.org | | | ... | | I saw the messages about using locks when interacting with the screen. Could | | someone provide a short snippet of code showing how one would use those | | unexported clim calls initial-lock-values and with-lockf? | | I wrote the question to which locks were the answer. I had the same | problem you do. Instead of using Clim locks, I used the locks in | Allegro's multi-processing system. Since you have a multi-process | application, your lisp must have some sort of lock mechanism. My code | is very simple. ... | | This doesn't do you any good for CLIM 1.0/1.1, but you should use | CLIM-SYS:MAKE-LOCK and CLIM-SYS:WITH-LOCK-HELD in CLIM 2.0, since | they are portable across all platforms that implement CLIM. | 1) Since it protects the processes from accessing the screen simultaneously, why doesn't it do me any good? 2) I'm using CLIM 1.1, and I still don't know what calls to use. I can't find any documentation in the CLIM 1.0 manual, the only one I have. What are they? -- Russ Abbott   Received: from BBN.COM by LABS-N.BBN.COM id aa26338; 1 Sep 92 13:04 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa17548; 1 Sep 92 12:59 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1134291; 1 Sep 1992 13:00:12-0400 Date: Tue, 1 Sep 1992 13:00-0400 From: Scott McKay Subject: locks To: abbott@aero.org, SWM@STONY-BROOK.SCRC.Symbolics.COM cc: clim@bbn.com In-Reply-To: <199209011607.AA23092@aerospace.aero.org> Message-ID: <19920901170059.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 1 Sep 1992 12:07 EDT From: abbott@aero.org | Date: Tue, 1 Sep 1992 12:01-0400 | From: Scott McKay | | Date: Tue, 1 Sep 1992 10:34 EDT | From: abbott@aero.org | | | ... | | I saw the messages about using locks when interacting with the screen. Could | | someone provide a short snippet of code showing how one would use those | | unexported clim calls initial-lock-values and with-lockf? | | I wrote the question to which locks were the answer. I had the same | problem you do. Instead of using Clim locks, I used the locks in | Allegro's multi-processing system. Since you have a multi-process | application, your lisp must have some sort of lock mechanism. My code | is very simple. ... | | This doesn't do you any good for CLIM 1.0/1.1, but you should use | CLIM-SYS:MAKE-LOCK and CLIM-SYS:WITH-LOCK-HELD in CLIM 2.0, since | they are portable across all platforms that implement CLIM. | My suggestion doesn't do you any good for CLIM 1.0/1.1 1) Since it protects the processes from accessing the screen simultaneously, why doesn't it do me any good? 2) I'm using CLIM 1.1, and I still don't know what calls to use. I can't find any documentation in the CLIM 1.0 manual, the only one I have. What are they? -- Russ Abbott   Received: from BBN.COM by LABS-N.BBN.COM id ab27751; 1 Sep 92 15:01 EDT Received: from turtle.mcc.com by BBN.COM id aa23183; 1 Sep 92 14:53 EDT Received: from hippo (hippo.mcc.com) by turtle.mcc.com (4.1/isd-master_920825_17:05) id AA07950; Tue, 1 Sep 92 13:53:52 CDT Received: by hippo (5.57/isd-other_920827_14:53) id AA02971; Tue, 1 Sep 92 13:53:48 -0500 Date: Tue, 1 Sep 1992 13:53-0500 From: David Gadbois Subject: Re: locks To: abbott@aero.org Cc: clim@bbn.com In-Reply-To: <19920901170059.8.SWM@SUMMER.SCRC.Symbolics.COM> Message-Id: <19920901185348.9.GADBOIS@CLIO.MCC.COM> Here's what I do for locks. --David Gadbois ;;; The locking primitives here provide for simple exclusion locks. To do ;;; anything fancier, you'll have to build up from here. A basic no-op scheme ;;; is provided for implementations without multitasking. We assume that the ;;; locks provided may be locked recursively -- locking a lock already held is a ;;; no-op. ;;; Any implementation that can meaningfully and usefully implement the ;;; following macros should add this feature. #+(or Genera Lucid Allegro) (pushnew :locks *features*) ;;; Lucid lets you use any old SETF location as a lock, sort of like the ;;; old-style Genera locks. #+Lucid (defstruct (lock (:constructor make-lock-internal (name))) (location nil) (name "No name")) (defun make-lock (name) "Makes a lock called NAME, suitable for use with WITH-LOCK-HELD." #-(or Genera Allegro Lucid) (declare (ignore name)) #-(or Genera Allegro Lucid) nil #+Genera (process:make-lock name :recursive t) #+Allegro (mp:make-process-lock :name name) #+Lucid (make-lock-internal name) ) (defun lock-idle-p (lock) "Returns NIL unless LOCK has been seized by someone." #-(or Genera Allegro Lucid) (declare (ignore lock)) #-(or Genera Allegro Lucid) t #+Genera (process:lock-idle-p lock) #+Allegro (mp:process-lock-locker lock) #+Lucid (lock-location lock) ) (defmacro with-lock-held (lock &body body) "Waits for and then seizes LOCK. Then executes BODY. Releases the lock upon exit, unless the lock was already held by this process." #-(or Allegro Genera Lucid) (declare (ignore lock)) #-(or Genera Allegro Lucid) `(progn ,@body) #+Genera `(process:with-lock (,lock) ,@body) #+Allegro `(mp:with-process-lock (,lock) ,@body) #+Lucid `(lcl:with-process-lock ((lock-location ,lock)) ,@body) )   Received: from BBN.COM by LABS-N.BBN.COM id aa27743; 1 Sep 92 14:59 EDT Received: from [129.197.134.99] by BBN.COM id aa23138; 1 Sep 92 14:53 EDT Received: from jade.rdd.lmsc.lockheed.com by dipl.rdd.lmsc.lockheed.com (4.0/SMI-4.1) id AA00694; Tue, 1 Sep 92 11:52:05 PDT Received: from cluso.lmsc.com by jade.rdd.lmsc.lockheed.com (4.1/SMI-4.0) id AA10646; Tue, 1 Sep 92 11:51:52 PDT Date: Tue, 1 Sep 92 11:51:52 PDT From: ttrinko@dipl.rdd.lmsc.lockheed.com (Tom Trinko) Message-Id: <9209011851.AA10646@jade.rdd.lmsc.lockheed.com> To: clim@bbn.com Subject: locks In our discussion of locks I thought someone said that there were unexported clim lock routines available--I assumed in 1.0 or 1.1--. Is this incorrect? If they are present in clim-utils:: could someone post the syntax so those of us who don't have 2.0 can use them as an interim measure? I hate to use a system dependent approach because our application has to run on both sun and symbolics and it will be difficult to partition the code that uses locks. thanks for any help.   Received: from BBN.COM by LABS-N.BBN.COM id aa00817; 1 Sep 92 18:05 EDT Received: from everest.den.mmc.com by BBN.COM id aa06387; 1 Sep 92 17:54 EDT Received: from jarrett (jarrett.den.mmc.com) by everest.den.mmc.com (4.1/1.34.a) id AA02789; Tue, 1 Sep 92 15:53:57 MDT Received: by jarrett (4.1/1.34.a) id AA13758; Tue, 1 Sep 92 15:53:56 MDT Date: Tue, 1 Sep 92 15:53:56 MDT From: robin@jarrett.den.mmc.com (Robin Kladke (303-977-9760)) Message-Id: <9209012153.AA13758@jarrett> To: clim@bbn.com Subject: accepting-values I am having some infuriating problems with clim:accepting-values. I'm not sure what version i am running, but it is the one that comes with Genera 8.1. I am trying to pop up a simple dialog box each time my program receives an Operator Information Message from the outside. The box will contain the source of the message, the message, and must accept a response string, if the message indicates that a response is required. If no response is required, the operator will simply select OK or EXIT and the popup window should go away. If a response is required, the user MUST supply a string response (i don't care what he responds, but at least one character would be required) then pick OK. THe response message will then be sent to the source. My problems are two-fold: (1) I would like to use :own-window, but don't know what to use for stream. You must provide stream as the first argument and *query-io*, t, etc. don't work (no method error). I finally used the root window as stream. That worked, but i don't know if it is the *correct* way. (2) ABORT is NEVER an acceptable response to this window; how do i define accepting-values so that it will only print one exit box? I've tried defining only :exit in the :exit-boxes option, i've tried defining the string associated with :abort as NIL, all to no avail. How do i get rid of ABORT? -- the only solution i've come up with is to redisplay the popup if abort is chosen, but this is a major yucky solution. --Robin   Received: from BBN.COM by LABS-N.BBN.COM id aa02576; 1 Sep 92 20:43 EDT Received: from everest.den.mmc.com by BBN.COM id aa09910; 1 Sep 92 20:39 EDT Received: from jarrett (jarrett.den.mmc.com) by everest.den.mmc.com (4.1/1.34.a) id AA10047; Tue, 1 Sep 92 18:39:21 MDT Received: by jarrett (4.1/1.34.a) id AA14098; Tue, 1 Sep 92 18:39:20 MDT Date: Tue, 1 Sep 92 18:39:20 MDT From: robin@jarrett.den.mmc.com (Robin Kladke (303-977-9760)) Message-Id: <9209020039.AA14098@jarrett> To: clim@bbn.com Subject: Trouble with accepting values I am having some infuriating problems with clim:accepting-values. I'm not sure what version i am running, but it is the one that comes with Genera 8.1. I am trying to pop up a simple dialog box each time my program receives an Operator Information Message from the outside. The box will contain the source of the message, the message, and must accept a response string, if the message indicates that a response is required. If no response is required, the operator will simply select OK or EXIT and the popup window should go away. If a response is required, the user MUST supply a string response (i don't care what he responds, but at least one character would be required) then pick OK. THe response message will then be sent to the source. My problems are two-fold: (1) I would like to use :own-window, but don't know what to use for stream. You must provide stream as the first argument and *query-io*, t, etc. don't work (no method error). I finally used the root window as stream. That worked, but i don't know if it is the *correct* way. (2) ABORT is NEVER an acceptable response to this window; how do i define accepting-values so that it will only print one exit box? I've tried defining only :exit in the :exit-boxes option, i've tried defining the string associated with :abort as NIL, all to no avail. How do i get rid of ABORT? -- the only solution i've come up with is to redisplay the popup if abort is chosen, but this is a major yucky solution. --Robin   Received: from BBN.COM by LABS-N.BBN.COM id aa02931; 1 Sep 92 21:50 EDT Received: from lucid.com by BBN.COM id aa11968; 1 Sep 92 21:47 EDT Received: from oakland-hills.lucid ([192.31.212.153]) by heavens-gate.lucid.com id AA15318g; Tue, 1 Sep 92 18:36:19 PDT Received: by oakland-hills.lucid (4.1/SMI-4.1) id AA24680; Tue, 1 Sep 92 18:41:05 PDT Date: Tue, 1 Sep 92 18:41:05 PDT From: york%oakland-hills@lucid.com (Bill York) Message-Id: <9209020141.AA24680@oakland-hills.lucid> To: abbott@aero.org Cc: SWM@stony-brook.scrc.symbolics.com, clim@BBN.COM In-Reply-To: Scott McKay's message of Tue, 1 Sep 1992 13:00-0400 <19920901170059.8.SWM@SUMMER.SCRC.Symbolics.COM> Subject: locks Reply-To: York@lucid.com Date: Tue, 1 Sep 1992 13:00-0400 From: Scott McKay Date: Tue, 1 Sep 1992 12:07 EDT From: abbott@aero.org | Date: Tue, 1 Sep 1992 12:01-0400 | From: Scott McKay | | Date: Tue, 1 Sep 1992 10:34 EDT | From: abbott@aero.org | | | ... | | I saw the messages about using locks when interacting with the screen. Could | | someone provide a short snippet of code showing how one would use those | | unexported clim calls initial-lock-values and with-lockf? | | This doesn't do you any good for CLIM 1.0/1.1, but you should use | CLIM-SYS:MAKE-LOCK and CLIM-SYS:WITH-LOCK-HELD in CLIM 2.0, since | they are portable across all platforms that implement CLIM. | 1) Since it protects the processes from accessing the screen simultaneously, why doesn't it do me any good? 2) I'm using CLIM 1.1, and I still don't know what calls to use. I can't find any documentation in the CLIM 1.0 manual, the only one I have. What are they? You could try using the undocumented, unsupport CLIM internal functions clim-utils::make-lock and clim-utils::with-lock-held. I'm not even sure that these are in all the vendors' versions of CLIM, but you can try. As usual, there are many risks in using unsupported code, not the least of which is that it can be removed without warning in future releases. However, in this case Scott has already pointed out that these functions will be documented and supported (albeit in another package) in CLIM 2.   Received: from BBN.COM by LABS-N.BBN.COM id aa03367; 1 Sep 92 22:57 EDT Received: from noc.msc.edu by BBN.COM id aa16360; 1 Sep 92 22:51 EDT Received: from uc.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA20415; Tue, 1 Sep 92 21:51:50 -0500 Received: from [129.230.11.2] by uc.msc.edu (5.65/MSC/v3.0z(901212)) id AA21406; Tue, 1 Sep 92 21:51:55 -0500 Received: from trc.amoco.com (apctrc.trc.amoco.com) by netserv2 (4.1/SMI-4.0) id AA12574; Tue, 1 Sep 92 21:51:44 CDT Received: from spirit.trc.amoco.com by trc.amoco.com (4.1/SMI-4.1) id AA25984; Tue, 1 Sep 92 21:51:39 CDT Received: from trc.amoco.com (skeptic) by spirit.trc.amoco.com (4.1/SMI-4.1) id AA21795; Tue, 1 Sep 92 21:51:38 CDT Date: Tue, 1 Sep 1992 21:51-0500 From: Donald H. Mitchell Reply-To: dmitchell@trc.amoco.com Subject: *complet(e|ion)-characters* To: clim@bbn.com, customer-reports@stony-brook.scrc.symbolics.com Message-Id: <19920902025141.2.DON@trc.amoco.com> UX1038 Genera 8.1, Clim 1.1 On the Symbolics, there is no *completion-characters* but there is *complete-characters*. Is the documentation wrong or ahead of the implementation? binding *complete-characters* and declaring it special does not seem to affect completing-from-suggestions. Is it only to affect complete-input? Do I have to bind it outside of my accept method? Don Mitchell dmitchell@trc.amoco.com Amoco Production Company (918) 660-4270 Tulsa Research Center P.O. Box 3385, Tulsa, OK 74102   Received: from BBN.COM by LABS-N.BBN.COM id aa03158; 1 Sep 92 22:36 EDT Received: from noc.msc.edu by BBN.COM id aa15064; 1 Sep 92 22:31 EDT Received: from uc.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA19338; Tue, 1 Sep 92 21:31:12 -0500 Received: from [129.230.11.2] by uc.msc.edu (5.65/MSC/v3.0z(901212)) id AA10214; Tue, 1 Sep 92 21:31:18 -0500 Received: from trc.amoco.com (apctrc.trc.amoco.com) by netserv2 (4.1/SMI-4.0) id AA12525; Tue, 1 Sep 92 21:31:07 CDT Received: from spirit.trc.amoco.com by trc.amoco.com (4.1/SMI-4.1) id AA25773; Tue, 1 Sep 92 21:31:03 CDT Received: from trc.amoco.com (skeptic) by spirit.trc.amoco.com (4.1/SMI-4.1) id AA21500; Tue, 1 Sep 92 21:31:03 CDT Date: Tue, 1 Sep 1992 21:31-0500 From: Donald H. Mitchell Reply-To: dmitchell@trc.amoco.com Subject: Accept with '(or...) types that have accept methods To: clim@bbn.com Message-Id: <19920902023105.1.DON@trc.amoco.com> CLIM 1.1 Genera 8.1 I noticed something odd and was wondering whether anyone has a fix. I define two presentation types and give each an accept method (using completing-from-suggestions), and then do an accept on '(or one-type the-other). If I type sufficient to uniquely identify an object from the first type (one-type) and hit , it completes. If I try for an object from the second type (the-other), the first time I hit nothing happens; if I immediately hit it again, then it completes. After hitting it twice, it keeps working for either type (within the same accept call). (I can send a simple example code to anyone who wants it.) Don Mitchell dmitchell@trc.amoco.com Amoco Production Company (918) 660-4270 Tulsa Research Center P.O. Box 3385, Tulsa, OK 74102   Received: from BBN.COM by LABS-N.BBN.COM id aa09363; 2 Sep 92 9:44 EDT Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa26827; 2 Sep 92 9:35 EDT Received: from LILIKOI.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 896955; 2 Sep 1992 09:36:06-0400 Date: Wed, 2 Sep 1992 09:50-0400 From: Mark Nahabedian Subject: *complet(e|ion)-characters* To: dmitchell@trc.amoco.com, clim@BBN.COM, customer-reports@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <19920902025141.2.DON@trc.amoco.com> Message-ID: <19920902135043.3.NAHA@LILIKOI.SCRC.Symbolics.COM> Date: Tue, 1 Sep 1992 22:51 EDT From: "Donald H. Mitchell" UX1038 Genera 8.1, Clim 1.1 On the Symbolics, there is no *completion-characters* but there is *complete-characters*. Is the documentation wrong or ahead of the implementation? binding *complete-characters* and declaring it special does not seem to affect completing-from-suggestions. Is it only to affect complete-input? Do I have to bind it outside of my accept method? COMPLETING-FROM-SUGGESTIONS calls COMPLETE-INPUT to do the work. CLIM:*COMPLETE-CHARACTERS* should already be declared special (it's defined with DEFVAR). If it gave you a special variable warning for it then perhaps you got the package wrong?   Received: from BBN.COM by LABS-N.BBN.COM id ab09561; 2 Sep 92 9:57 EDT Received: from noc.msc.edu by BBN.COM id aa27539; 2 Sep 92 9:46 EDT Received: from uc.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA28576; Wed, 2 Sep 92 08:46:34 -0500 Received: from [129.230.11.2] by uc.msc.edu (5.65/MSC/v3.0z(901212)) id AA19813; Wed, 2 Sep 92 08:46:40 -0500 Received: from trc.amoco.com (apctrc.trc.amoco.com) by netserv2 (4.1/SMI-4.0) id AA14858; Wed, 2 Sep 92 08:46:23 CDT Received: from spirit.trc.amoco.com by trc.amoco.com (4.1/SMI-4.1) id AA06297; Wed, 2 Sep 92 08:46:22 CDT Received: from trc.amoco.com (skeptic) by spirit.trc.amoco.com (4.1/SMI-4.1) id AA23936; Wed, 2 Sep 92 08:46:20 CDT Date: Wed, 2 Sep 1992 08:46-0500 From: Donald H. Mitchell Reply-To: dmitchell@trc.amoco.com Subject: *complet(e|ion)-characters* To: naha@RIVERSIDE.SCRC.Symbolics.COM Cc: dmitchell@trc.amoco.com, clim@BBN.COM, customer-reports@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <19920902135043.3.NAHA@LILIKOI.SCRC.Symbolics.COM> Message-Id: <19920902134628.3.DON@trc.amoco.com> Date: Wed, 2 Sep 1992 08:50 CDT From: Mark Nahabedian Date: Tue, 1 Sep 1992 22:51 EDT From: "Donald H. Mitchell" UX1038 Genera 8.1, Clim 1.1 On the Symbolics, there is no *completion-characters* but there is *complete-characters*. Is the documentation wrong or ahead of the implementation? binding *complete-characters* and declaring it special does not seem to affect completing-from-suggestions. Is it only to affect complete-input? Do I have to bind it outside of my accept method? COMPLETING-FROM-SUGGESTIONS calls COMPLETE-INPUT to do the work. CLIM:*COMPLETE-CHARACTERS* should already be declared special (it's defined with DEFVAR). If it gave you a special variable warning for it then perhaps you got the package wrong? No. It just didn't seem to pay any attention to the additional characters that I put into it. I did the clean, non-pervasive (define-presentation-method accept (...) (let ((CLIM:*COMPLETE-CHARACTERS* (append '(#\a #\u) CLIM:*COMPLETE-CHARACTERS*))) (declare (special CLIM:*COMPLETE-CHARACTERS*)) (complete-input...))) Maybe CLIM:*COMPLETE-CHARACTERS* have to be whitespace? The documentation doesn't say. Everyone who has used this part of my interface says it should automatically complete as soon as it can. Don Mitchell dmitchell@trc.amoco.com Amoco Production Company (918) 660-4270 Tulsa Research Center P.O. Box 3385, Tulsa, OK 74102   Received: from BBN.COM by LABS-N.BBN.COM id aa10428; 2 Sep 92 11:01 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa01195; 2 Sep 92 10:50 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1134963; 2 Sep 1992 10:50:57-0400 Date: Wed, 2 Sep 1992 10:51-0400 From: Scott McKay Subject: *complet(e|ion)-characters* To: dmitchell@trc.amoco.com, clim@BBN.COM, customer-reports@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <19920902025141.2.DON@trc.amoco.com> Message-ID: <19920902145151.6.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 1 Sep 1992 22:51 EDT From: "Donald H. Mitchell" UX1038 Genera 8.1, Clim 1.1 On the Symbolics, there is no *completion-characters* but there is *complete-characters*. Is the documentation wrong or ahead of the implementation? Use *COMPLETE-CHARACTERS*. One or the other is wrong, but it doesn't matter because the name has been change in CLIM 2.0 anyway. binding *complete-characters* and declaring it special does not seem to affect completing-from-suggestions. Is it only to affect complete-input? Do I have to bind it outside of my accept method? Sigh, there's an optimization in CLIM in the form of a variable called *MAGIC-COMPLETION-CHARACTERS*. If you bind *COMPLETE-CHARACTERS*, you will also need to bind *MAGIC-COMPLETION-CHARACTERS* to (append *complete-characters* *help-characters* *possibilities-characters*)   Received: from BBN.COM by LABS-N.BBN.COM id aa10616; 2 Sep 92 11:09 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa01524; 2 Sep 92 10:57 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1134971; 2 Sep 1992 10:57:42-0400 Date: Wed, 2 Sep 1992 10:58-0400 From: Scott McKay Subject: Accept with '(or...) types that have accept methods To: dmitchell@trc.amoco.com, clim@BBN.COM In-Reply-To: <19920902023105.1.DON@trc.amoco.com> Message-ID: <19920902145836.7.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 1 Sep 1992 22:31 EDT From: "Donald H. Mitchell" CLIM 1.1 Genera 8.1 I noticed something odd and was wondering whether anyone has a fix. I define two presentation types and give each an accept method (using completing-from-suggestions), and then do an accept on '(or one-type the-other). If I type sufficient to uniquely identify an object from the first type (one-type) and hit , it completes. If I try for an object from the second type (the-other), the first time I hit nothing happens; if I immediately hit it again, then it completes. After hitting it twice, it keeps working for either type (within the same accept call). It doesn't surprise me that, in the second case, hitting doesn't complete from the second completion set. It surprised me at first that hitting a second time completed from the second set, but then I realized that this is the "expected" behavior. It really surpises me that hitting after that completes from either set; I don't see how that can happen. Background: the OR type is implemented by looping over the component types and running the ACCEPT method for each of components. If one type "fails" (by signalling a parse-error), the next type is tried. So it's pretty easy to see what hitting twice uses the second completion set -- the first signals a parse-error, and the second completes from the next completion set. (I can send a simple example code to anyone who wants it.) Don Mitchell dmitchell@trc.amoco.com Amoco Production Company (918) 660-4270 Tulsa Research Center P.O. Box 3385, Tulsa, OK 74102   Received: from BBN.COM by LABS-N.BBN.COM id aa10256; 2 Sep 92 10:52 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa00515; 2 Sep 92 10:36 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1134948; 2 Sep 1992 10:36:28-0400 Date: Wed, 2 Sep 1992 10:37-0400 From: Scott McKay Subject: accepting-values To: robin@jarrett.den.mmc.com, clim@BBN.COM In-Reply-To: <9209012153.AA13758@jarrett> Message-ID: <19920902143722.3.SWM@SUMMER.SCRC.Symbolics.COM> Date: Tue, 1 Sep 1992 17:53 EDT From: "Robin Kladke (303-977-9760" I am having some infuriating problems with clim:accepting-values. I'm not sure what version i am running, but it is the one that comes with Genera 8.1. I am trying to pop up a simple dialog box each time my program receives an Operator Information Message from the outside. The box will contain the source of the message, the message, and must accept a response string, if the message indicates that a response is required. If no response is required, the operator will simply select OK or EXIT and the popup window should go away. If a response is required, the user MUST supply a string response (i don't care what he responds, but at least one character would be required) then pick OK. THe response message will then be sent to the source. My problems are two-fold: (1) I would like to use :own-window, but don't know what to use for stream. You must provide stream as the first argument and *query-io*, t, etc. don't work (no method error). I finally used the root window as stream. That worked, but i don't know if it is the *correct* way. Using the root window is a bit of a hack, but in CLIM 1.0/1.1 it's really perfectly OK to do so. (2) ABORT is NEVER an acceptable response to this window; how do i define accepting-values so that it will only print one exit box? I've tried defining only :exit in the :exit-boxes option, i've tried defining the string associated with :abort as NIL, all to no avail. How do i get rid of ABORT? -- the only solution i've come up with is to redisplay the popup if abort is chosen, but this is a major yucky solution. In CLIM 1.0/1.1, you're sort of stuck (but see below). In CLIM 2.0, the :EXIT-BOXES option to ACCEPTING-VALUES does the right thing. In CLIM 1.0/1.1, you could specialize this method for your own class of ACCEPT-VALUES, and then use the :FRAME-CLASS option to ACCEPTING-VALUES. (defmethod display-exit-boxes ((frame accept-values) stream) ;; Do the fresh-line *outside* of the updating-output so that it ;; doesn't get repositioned relatively in the X direction if the ;; previous line gets longer. Maybe there should be some better ;; way of ensuring this. (fresh-line stream) (with-slots (exit-boxes) frame (let ((exit (or (second (assoc :exit exit-boxes)) " uses these values")) (abort (or (second (assoc :abort exit-boxes)) " aborts"))) (updating-output (stream :unique-id stream :cache-value 'exit-boxes) (with-output-as-presentation (:stream stream :type 'accept-values-exit-box :object ':abort) #-CCL-2 (write-string abort stream) ;; Kludge to print the cloverleaf char in MCL. ;; Needs an accompanying kludge in STREAM-WRITE-CHAR so that ;; #\CommandMark doesn't get lozenged. #+CCL-2 (progn (with-text-style ('(:mac-menu :roman :normal) stream) (write-char #\CommandMark stream)) (write-string "-. aborts" stream))) (write-string ", " stream) (with-output-as-presentation (:stream stream :type 'accept-values-exit-box :object ':done) (write-string exit stream)))))) --Robin   Received: from BBN.COM by LABS-N.BBN.COM id aa11677; 2 Sep 92 12:22 EDT Received: from Relay.Prime.COM by BBN.COM id aa05215; 2 Sep 92 12:18 EDT Received: from flora.ccs.northeastern.edu by Relay.Prime.COM; 02 Sep 92 12:23:04 EST Received: from damon (damon.ccs.northeastern.edu) by flora.ccs.northeastern.edu (4.0/SMI-4.1) id AA09764; Wed, 2 Sep 92 12:17:00 EDT Received: by damon (5.57/SMI-3.2+CCS-subsidiary-2.2) id AA13662; Wed, 2 Sep 92 12:18:23 -0400 Date: Wed, 2 Sep 92 12:18:23 -0400 From: sgauch@damon.ccs.northeastern.edu (Susan Gauch) Message-Id: <9209021618.AA13662@damon> To: clim@bbn.com Subject: Output-recording for fast word wrap I am displaying text in a CLIM window on the Macintosh. When I use indenting-output and filling-output to position the text in the window, complete with wordwrap, the performance is unacceptable (4 seconds versus < 1 second without filling-output/indenting-output for 20 lines of text). So, I'm thinking of a 2 phase operation. Phase 1. Read text from file. Calculate the required linefeeds. Store result of this computation, including explicitly indicated linefeeds. This is essentially a pre-processing phase. Phase 2. Read formatted text from file. Write to screen. This will be done "live" when the user asks to see the text. I can think of 3 ways to get the formatted information I want 1) Use with-output-to-postscript to create a postscript representation of the text. Can this be read into CLIM later? If so, how? 2) Use with-output-to-output-record to get the formatted version. Is there a way to store the resulting output record in a file for reading/replaying in a later session? As an aside, a mini-test I tried didn't work: (defmethod display ((abstract abstract) stream) (with-slots (lmargin) *application-frame* (let ((line-length (- (window-inside-width stream) (* 2 lmargin)))) (with-output-to-output-record (stream 'clim::linear-output-record new-record) (indenting-output (stream lmargin) (filling-output (stream :fill-width line-length) ;; do a bunch of writing (mapc #'(lambda (obj) (display obj stream)) (seq abstract)))) (replay new-record stream) ) Nothing was ever displayed in the pane. Without the (with-output-to-output- record.....(replay...)) code, this works. Why doesn't this work? 3) Use my own wrapping code. I've done this in the past, but would like to use CLIM's output records, if possible, since they capture change in fonts as well as just wrapping information. I'm open to any other suggestions to improve speed. Susan Gauch sgauch@flora.ccs.northeastern.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa12568; 2 Sep 92 13:44 EDT Received: from jupiter.risc.rockwell.com by BBN.COM id aa08696; 2 Sep 92 13:38 EDT Received: from magrathea.risc.rockwell.com by jupiter.risc.rockwell.com (4.1/SMI-4.1) id AA08545; Wed, 2 Sep 92 10:38:24 PDT Date: Wed, 2 Sep 92 10:38:24 PDT From: bss@jupiter.risc.rockwell.com (Bruce Seely) Message-Id: <9209021738.AA08545@jupiter.risc.rockwell.com> To: clim@BBN.COM Subject: Commands with the same name In CLIM 0.9 it was possible to have different commands that had the same name in different command tables, but not in 2.0 alpha (I don't know about 1.0/1.1). Were commands were implemented as methods in 0.9, but as functions now? Is there a reason for the change? I liked using the same name for commands that did the same things in different frames.   Received: from BBN.COM by LABS-N.BBN.COM id aa13122; 2 Sep 92 14:28 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa10682; 2 Sep 92 14:24 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1135202; 2 Sep 1992 14:25:07-0400 Date: Wed, 2 Sep 1992 14:26-0400 From: Scott McKay Subject: Commands with the same name To: bss@jupiter.risc.rockwell.com, clim@BBN.COM In-Reply-To: <9209021738.AA08545@jupiter.risc.rockwell.com> Message-ID: <19920902182602.0.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 2 Sep 1992 13:38 EDT From: Bruce Seely In CLIM 0.9 it was possible to have different commands that had the same name in different command tables, but not in 2.0 alpha (I don't know about 1.0/1.1). Were commands were implemented as methods in 0.9, but as functions now? Is there a reason for the change? I liked using the same name for commands that did the same things in different frames. Some of us didn't think that implementing commands as methods bought you very much, and in some cases actually makes things more difficult rather than less difficult. I myself take this position, but am certainly sympathetic with the other point of view. You could separate your applications into different packages, too.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa13420; 2 Sep 92 14:50 EDT Received: by KARIBA.BBN.COM id aa14489; 2 Sep 92 14:41 EDT To: dmitchell@trc.amoco.com cc: clim@BBN.COM Subject: Re: Accept with '(or...) types that have accept methods In-reply-to: "Donald H. Mitchell"'s message of Tue, 01 Sep 92 21:31:00 -0500. <19920902023105.1.DON@trc.amoco.com> Reply-To: jmorrill@BBN.COM Date: Wed, 02 Sep 92 14:33:26 -0400 Message-ID: <263.715458806@bbn.com> From: Jeff Morrill Date: Tue, 1 Sep 1992 21:31-0500 From: "Donald H. Mitchell" Reply-To: dmitchell@trc.amoco.com Subject: Accept with '(or...) types that have accept methods To: clim@BBN.COM CLIM 1.1 Genera 8.1 I noticed something odd and was wondering whether anyone has a fix. I define two presentation types and give each an accept method (using completing-from-suggestions), and then do an accept on '(or one-type the-other). If I type sufficient to uniquely identify an object from the first type (one-type) and hit , it completes. If I try for an object from the second type (the-other), the first time I hit nothing happens; if I immediately hit it again, then it completes. After hitting it twice, it keeps working for either type (within the same accept call). (I can send a simple example code to anyone who wants it.) Don Mitchell dmitchell@trc.amoco.com Amoco Production Company (918) 660-4270 Tulsa Research Center P.O. Box 3385, Tulsa, OK 74102 This sure sounds familiar. I was just working on exactly this problem. I suggest that the "fix" is to change your approach. OR simply does: (accept 'one-type) if that generates a parse-error, then reset and (accept 'the-other) if that generates a parse-error, then generate a parse-error So you see that the first TAB gets consumed by the ONE-TYPE parser, and the second TAB gets consumed by THE-OTHER parser. The easiest thing would be a presentation-type like ONE-TYPE-OR-THE-OTHER that completes over the union of the completions of ONE-TYPE and THE-OTHER. If there is only one or two cases where this problem occurs, then this is probably the easiest thing. My own problem in this area is that there are many possible pairings (groupings) of presentation-types. A combinatorial explosion results. I have written my own version of completing-from-suggestions to do the job; its surprisingly easy to do using READ-TOKEN and REPLACE-INPUT. In my case the completion character is a SPACE, and the completion parser does not consume it unless there is a valid completion. Given this approach, (accept '(or one-type the-other)) works fine. jeff morrill P.S. Here is some example code from a recent debugging session of mine. It is a little too simple because it should complain when there is more than one completion, but you get the idea. (in-package :clim-user) (defun simple-completion-parser (stream presentation-type completions) (with-blip-characters ('(#\space)) (let* ((loc (clim::input-position stream)) (token (read-token stream)) (answer (choose-one token completions))) (cond (answer (replace-input stream (string answer) :buffer-start loc) (values answer presentation-type)) (t (input-not-of-required-type token presentation-type)))))) (defun choose-one (hint choices) (let ((l (length hint))) (dolist (choice choices) (when (string-equal hint (string choice) :end1 l :end2 l) (return-from choose-one choice))) nil))   Received: from BBN.COM by LABS-N.BBN.COM id aa13457; 2 Sep 92 14:52 EDT Received: from aplcen.apl.jhu.edu by BBN.COM id aa11711; 2 Sep 92 14:48 EDT Received: by aplcen.apl.jhu.edu (5.57/Ultrix2.4-XDccg) id AA11793; Wed, 2 Sep 92 14:48:01 -0400 Date: Wed, 2 Sep 92 14:48:01 -0400 From: lien@aplcen.apl.jhu.edu (Duong lien t) Message-Id: <9209021848.AA11793@aplcen.apl.jhu.edu> X-Mailer: Mail User's Shell (6.1 4/26/88) To: clim@bbn.com Subject: clim questions I can not figure out how to do the following in Lucid CLIM 1.1 (on a Sparc 2): 1) How to make a pattern's background color opaque? make-pattern requires ink(s) as arguments. 2) I am using CLIM windows directly instead of application frames. Each time anything is drawn to the CLIM window, force-output is required in order to see the drawing, but even so the object does not always appear. What do I need to do so that drawn objects will always appear on the screen? (Note I don't have this problem on Symbolics?) 3) How to change the mouse icon on a CLIM window or application frame? 4) How can I attach a function to a mouse click on a CLIM window or application frame? Thanks.   Received: from BBN.COM by LABS-N.BBN.COM id aa13724; 2 Sep 92 15:01 EDT Received: from noc.msc.edu by BBN.COM id aa12084; 2 Sep 92 14:56 EDT Received: from uc.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA18054; Wed, 2 Sep 92 13:56:28 -0500 Received: from [129.230.11.2] by uc.msc.edu (5.65/MSC/v3.0z(901212)) id AA16982; Wed, 2 Sep 92 13:56:30 -0500 Received: from trc.amoco.com (apctrc.trc.amoco.com) by netserv2 (4.1/SMI-4.0) id AA16101; Wed, 2 Sep 92 13:56:11 CDT Received: from spirit.trc.amoco.com by trc.amoco.com (4.1/SMI-4.1) id AA24282; Wed, 2 Sep 92 13:56:07 CDT Received: from trc.amoco.com (skeptic) by spirit.trc.amoco.com (4.1/SMI-4.1) id AA27990; Wed, 2 Sep 92 13:56:05 CDT Date: Wed, 2 Sep 1992 13:56-0500 From: Donald H. Mitchell Reply-To: dmitchell@trc.amoco.com Subject: Accept with '(or...) types that have accept methods To: SWM@STONY-BROOK.SCRC.Symbolics.COM Cc: clim@BBN.COM, jtompkins@APCTRC.trc.amoco.com, bdavis@APCTRC.trc.amoco.com, jveezhinathan@APCTRC.trc.amoco.com In-Reply-To: <19920902145836.7.SWM@SUMMER.SCRC.Symbolics.COM> Message-Id: <19920902185614.6.DON@trc.amoco.com> Date: Wed, 2 Sep 1992 09:58 CDT From: Scott McKay Date: Tue, 1 Sep 1992 22:31 EDT From: "Donald H. Mitchell" CLIM 1.1 Genera 8.1 I noticed something odd and was wondering whether anyone has a fix. I define two presentation types and give each an accept method (using completing-from-suggestions), and then do an accept on '(or one-type the-other). If I type sufficient to uniquely identify an object from the first type (one-type) and hit , it completes. If I try for an object from the second type (the-other), the first time I hit nothing happens; if I immediately hit it again, then it completes. After hitting it twice, it keeps working for either type (within the same accept call). It doesn't surprise me that, in the second case, hitting doesn't complete from the second completion set. It surprised me at first that hitting a second time completed from the second set, but then I realized that this is the "expected" behavior. It really surpises me that hitting after that completes from either set; I don't see how that can happen. Mea culpa, it doesn't today but I could swear it did yesterday. Background: the OR type is implemented by looping over the component types and running the ACCEPT method for each of components. If one type "fails" (by signalling a parse-error), the next type is tried.... Why not try the second and so on right away? That is, before the next event? It seems to continually retry the first one: i.e., I can't get it to require two tabs no matter whether I make it fail at first or not. Please consider making it try each accept method in turn for or's in CLIM 2.0. I suppose no matter what you do it will always complete the input according to the first type before checking to see if the input is truly unique by comparison to the other types. That is, if one-type = "One" "Two" "Four" and the-other = "Own" "The" "Floor", then typing the first character followed by will complete according to possibilities for one-type. I don't know that I'd change this behavior but I certainly would make it known in the documentation for 'or. Don Mitchell dmitchell@trc.amoco.com Amoco Production Company (918) 660-4270 Tulsa Research Center P.O. Box 3385, Tulsa, OK 74102   Received: from BBN.COM by LABS-N.BBN.COM id aa14772; 2 Sep 92 16:16 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa15756; 2 Sep 92 16:08 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1135332; 2 Sep 1992 16:09:17-0400 Date: Wed, 2 Sep 1992 16:10-0400 From: Scott McKay Subject: Output-recording for fast word wrap To: sgauch@damon.ccs.northeastern.edu, clim@BBN.COM In-Reply-To: <9209021618.AA13662@damon> Message-ID: <19920902201008.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 2 Sep 1992 12:18 EDT From: Susan Gauch I am displaying text in a CLIM window on the Macintosh. When I use indenting-output and filling-output to position the text in the window, complete with wordwrap, the performance is unacceptable (4 seconds versus < 1 second without filling-output/indenting-output for 20 lines of text). So, I'm thinking of a 2 phase operation. Phase 1. Read text from file. Calculate the required linefeeds. Store result of this computation, including explicitly indicated linefeeds. This is essentially a pre-processing phase. Phase 2. Read formatted text from file. Write to screen. This will be done "live" when the user asks to see the text. I can think of 3 ways to get the formatted information I want 1) Use with-output-to-postscript to create a postscript representation of the text. Can this be read into CLIM later? If so, how? CLIM doesn't understand PostScript, it just knows how to generate it. 2) Use with-output-to-output-record to get the formatted version. Is there a way to store the resulting output record in a file for reading/replaying in a later session? No, not really. Output records are somewhat device dependent. It is possible that this will work by sheer good luck. As an aside, a mini-test I tried didn't work: (defmethod display ((abstract abstract) stream) (with-slots (lmargin) *application-frame* (let ((line-length (- (window-inside-width stream) (* 2 lmargin)))) (with-output-to-output-record (stream 'clim::linear-output-record new-record) (indenting-output (stream lmargin) (filling-output (stream :fill-width line-length) ;; do a bunch of writing (mapc #'(lambda (obj) (display obj stream)) (seq abstract)))) (replay new-record stream) ) Nothing was ever displayed in the pane. Without the (with-output-to-output- record.....(replay...)) code, this works. Why doesn't this work? I think you mean to use LET to bind NEW-RECORD to the result of the call to WITH-OUTPUT-TO-OUTPUT-RECORD, and then replay that. Inside of WITH-OUTPUT-TO-OUTPUT-RECORD, drawing is turned off, so REPLAY will have no effect. 3) Use my own wrapping code. I've done this in the past, but would like to use CLIM's output records, if possible, since they capture change in fonts as well as just wrapping information. I'm open to any other suggestions to improve speed. FILLING-OUTPUT is slow because it's completely incremental in nature. It can't assume anything in advance, and so has to be prepared to deal with single characters, whole lines, etc. I just hacked it a bit and got a speed improvement of about 35%. If CLIM took 2.5 seconds to do the output, would that be fast enough? (If the answer is no, then even the improved FILLING-OUTPUT isn't going to meet your speed requirements.)   Received: from BBN.COM by LABS-N.BBN.COM id aa15026; 2 Sep 92 16:35 EDT Received: from [129.197.134.99] by BBN.COM id aa17095; 2 Sep 92 16:30 EDT Received: from jade.rdd.lmsc.lockheed.com by dipl.rdd.lmsc.lockheed.com (4.0/SMI-4.1) id AA01436; Wed, 2 Sep 92 13:29:39 PDT Received: from cluso.lmsc.com by jade.rdd.lmsc.lockheed.com (4.1/SMI-4.0) id AA05150; Wed, 2 Sep 92 13:29:23 PDT Date: Wed, 2 Sep 92 13:29:23 PDT From: ttrinko@dipl.rdd.lmsc.lockheed.com (Tom Trinko) Message-Id: <9209022029.AA05150@jade.rdd.lmsc.lockheed.com> To: clim@bbn.com Subject: multiple processes Our application uses two processes. One process runs the interface and the other does a bunch of calculations. Both processes write out to the same pane.` Occasionally we get output that overwrites existing text in the scrolling pane. Some quick testing seems to indicate that the problem occurs when the pane seems to be unaware of the text the background process has written to the pane when it writes some new text from the foreground application to the pane. Before we spend a lot of time working on this I was wondering if anyone knew if CLIM is supposed to support multiple processes writing to the same window? If it does then I'll have to search elsewhere for the bug but if it doesn't then I have to implement a new approach anyway. Thanks for any help.   Received: from BBN.COM by LABS-N.BBN.COM id aa25669; 3 Sep 92 11:38 EDT Received: from life.ai.mit.edu by BBN.COM id aa18941; 3 Sep 92 11:20 EDT Received: from OMEGA.AI.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA23047; Thu, 3 Sep 92 11:20:33 EDT Date: Thu, 3 Sep 1992 11:21-0400 From: John C. Mallery Subject: format directives To: clim@bbn.com Message-Id: <19920903152137.3.JCMA@OMEGA.AI.MIT.EDU> The Lisp machine has open and close horseshoe as format directives to make text style specifications easy. Is there any thought on this subject for CLIM? I am about to use ~+ and ~- because they are about the only unused characters that make any menonic sense.   Received: from BBN.COM by LABS-N.BBN.COM id aa26368; 3 Sep 92 12:22 EDT Received: from aerospace.aero.org by BBN.COM id aa21445; 3 Sep 92 12:14 EDT Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT) id AA03437 for clim@bbn.com; Thu, 3 Sep 1992 09:14:05 -0700 Posted-Date: Thu, 3 Sep 92 09:13:57 PDT Message-Id: <199209031614.AA03437@aerospace.aero.org> Received: from reify.aero.org by antares.aero.org (4.1/AMS-1.0) id AA04110 for clim@bbn.com; Thu, 3 Sep 92 09:13:59 PDT Date: Thu, 3 Sep 92 09:13:57 PDT From: abbott@aero.org To: clim@aero.org, clim@bbn.com Subject: Returning to a line in a window I have a pane that displays a scrolling sequence of lines. How can I scroll the pane to a particular line, e.g., 40 lines up/down from its current position. -- Russ Abbott   Received: from BBN.COM by LABS-N.BBN.COM id aa27095; 3 Sep 92 13:15 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa23812; 3 Sep 92 13:11 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1135978; 3 Sep 1992 13:11:37-0400 Date: Thu, 3 Sep 1992 13:12-0400 From: Scott McKay Subject: format directives To: jcma@reagan.ai.mit.edu, clim@BBN.COM In-Reply-To: <19920903152137.3.JCMA@OMEGA.AI.MIT.EDU> Message-ID: <19920903171238.5.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 3 Sep 1992 11:21 EDT From: "John C. Mallery" The Lisp machine has open and close horseshoe as format directives to make text style specifications easy. Is there any thought on this subject for CLIM? Not to my knowledge. I hope that we CLIM implementors all resist the temptation to mess around with FORMAT directives. This is certainly good material for a CLIM library contribution, though. I am about to use ~+ and ~- because they are about the only unused characters that make any menonic sense.   Received: from BBN.COM by LABS-N.BBN.COM id aa27085; 3 Sep 92 13:14 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa23758; 3 Sep 92 13:10 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1135974; 3 Sep 1992 13:10:08-0400 Date: Thu, 3 Sep 1992 13:11-0400 From: Scott McKay Subject: Returning to a line in a window To: abbott@aero.org, clim@aero.org, clim@BBN.COM In-Reply-To: <199209031614.AA03437@aerospace.aero.org> Message-ID: <19920903171109.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 3 Sep 1992 12:13 EDT From: abbott@aero.org I have a pane that displays a scrolling sequence of lines. How can I scroll the pane to a particular line, e.g., 40 lines up/down from its current position. If the lines are the same height, you can just scroll to the Y position that is (* n (+ (STREAM-LINE-HEIGHT stream) (STREAM-VERTICAL-SPACING stream)))   Received: from BBN.COM by LABS-N.BBN.COM id aa28654; 3 Sep 92 14:52 EDT Received: from life.ai.mit.edu by BBN.COM id aa29142; 3 Sep 92 14:44 EDT Received: from MORRISON.AI.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA27404; Thu, 3 Sep 92 14:43:16 EDT Date: Thu, 3 Sep 1992 14:43-0400 From: John C. Mallery Subject: format directives To: SWM@stony-brook.scrc.symbolics.com Cc: clim@bbn.com In-Reply-To: <19920903171238.5.SWM@SUMMER.SCRC.Symbolics.COM> Message-Id: <19920903184329.8.JCMA@MORRISON.AI.MIT.EDU> Date: Thu, 3 Sep 1992 13:12 EDT From: Scott McKay Date: Thu, 3 Sep 1992 11:21 EDT From: "John C. Mallery" The Lisp machine has open and close horseshoe as format directives to make text style specifications easy. Is there any thought on this subject for CLIM? Not to my knowledge. I hope that we CLIM implementors all resist the temptation to mess around with FORMAT directives. This is certainly good material for a CLIM library contribution, though. The definition is pretty trivial but cleans up code radically. See, I've got to do something useful with all the ~ and ~ that I have (Sorry not lispm folks!). I am about to use ~+ and ~- because they are about the only unused characters that make any menonic sense.   Received: from BBN.COM by LABS-N.BBN.COM id aa28108; 3 Sep 92 14:34 EDT Received: from hyper.franz.com by BBN.COM id aa27850; 3 Sep 92 14:23 EDT Return-Path: Received: from vapor.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA09335; Thu, 3 Sep 92 11:22:00 PDT Received: by vapor.Franz.COM (4.1/FI-2.0) id AA03423; Thu, 3 Sep 92 11:20:56 PDT Date: Thu, 3 Sep 92 11:20:56 PDT From: smh@Franz.COM (Steve Haflich) Message-Id: <9209031820.AA03423@vapor.Franz.COM> To: SWM@stony-brook.scrc.symbolics.com Cc: jcma@reagan.ai.mit.edu, clim@BBN.COM In-Reply-To: Scott McKay's message of Thu, 3 Sep 1992 13:12-0400 <19920903171238.5.SWM@SUMMER.SCRC.Symbolics.COM> Subject: format directives From: Scott McKay The Lisp machine has open and close horseshoe as format directives to make text style specifications easy. Is there any thought on this subject for CLIM? Not to my knowledge. I hope that we CLIM implementors all resist the temptation to mess around with FORMAT directives. This is certainly good material for a CLIM library contribution, though. I am about to use ~+ and ~- because they are about the only unused characters that make any menonic sense. There's no portable way for CLIM or a library contribution portably to extend format string syntax. The strategy of shadowing format with an extended version might make other implementation-dependent extensions unavailable. There is a portable way to approximate what's wanted using the `new' ~/.../ format directive -- something like ~/clim:push-font/ -- but it would be syntactically turgid in practice.   Received: from BBN.COM by LABS-N.BBN.COM id aa29199; 3 Sep 92 15:24 EDT Received: from Sunset.AI.SRI.COM by BBN.COM id aa00976; 3 Sep 92 15:18 EDT Received: from ELCAPITAN.AI.SRI.COM by Sunset.AI.SRI.COM (4.1/SMI-4.1) id AA13567 for clim@BBN.COM; Thu, 3 Sep 92 12:18:07 PDT Date: Thu, 3 Sep 1992 12:21-0700 From: Mabry Tyson Subject: Re: format directives To: smh@franz.com, SWM@stony-brook.scrc.symbolics.com Cc: jcma@reagan.ai.mit.edu, clim@BBN.COM In-Reply-To: <9209031820.AA03423@vapor.Franz.COM> Message-Id: <19920903192142.4.TYSON@ELCAPITAN.AI.SRI.COM> Date: Thu, 3 Sep 1992 11:20 PDT From: Steve Haflich From: Scott McKay The Lisp machine has open and close horseshoe as format directives to make text style specifications easy. Is there any thought on this subject for CLIM? Not to my knowledge. I hope that we CLIM implementors all resist the temptation to mess around with FORMAT directives. This is certainly good material for a CLIM library contribution, though. I am about to use ~+ and ~- because they are about the only unused characters that make any menonic sense. There's no portable way for CLIM or a library contribution portably to extend format string syntax. The strategy of shadowing format with an extended version might make other implementation-dependent extensions unavailable. There is a portable way to approximate what's wanted using the `new' ~/.../ format directive -- something like ~/clim:push-font/ -- but it would be syntactically turgid in practice. (with-font-face (:italic) (format t "Turgid? ")) (format "How about ") (with-font-face (:bold) (format t "something")) (format "for people who want to use fonts?") Now, that's turgid! (And because it is so turgid, I bet you didn't notice the problem with a missing space.) One of my biggest frustrations from converting some Symbolics systems to CLIM (on Suns) was the loss of just printing text that had fonts in it already. Well, someday these other systems will eventually catch up to Symbolics (and Xerox before them). But, if I at least had a format directive directive to switch faces (or whatever), then the code would only be somewhat bloated but still mostly readable. As far as portability is concerned, all that should be hidden in CLIM:FORMAT. (I'm guessing that all implementations of CLIM require you to use CLIM:FORMAT since the first arg might not be a CL:STREAM.)   Received: from BBN.COM by LABS-N.BBN.COM id aa29227; 3 Sep 92 15:28 EDT Received: from cs.utexas.edu by BBN.COM id aa01253; 3 Sep 92 15:24 EDT Received: from sage.cs.utexas.edu by cs.utexas.edu (5.64/1.136) with SMTP id AA23959; Thu, 3 Sep 92 14:24:03 -0500 Received: by sage.cs.utexas.edu (5.64/Client-v1.3) id AA18599; Thu, 3 Sep 92 14:23:45 -0500 Message-Id: <9209031923.AA18599@sage.cs.utexas.edu> From: eilerts@cs.utexas.edu (Erik Eilerts) Date: Thu, 3 Sep 1992 14:23:45 -0500 X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: clim@bbn.com Subject: Animation Cc: eilerts@cs.utexas.edu Could anyone tell me if Clim 2.0 will provide any support for animation? Also, what kind of format will Clim 2.0 bitmaps be stored in, ie. TIFF? Thanks, Erik Eilerts University of Texas at Austin eilerts@cs.utexas.edu   Received: from BBN.COM by LABS-N.BBN.COM id aa29568; 3 Sep 92 15:54 EDT Received: from everest.den.mmc.com by BBN.COM id aa02455; 3 Sep 92 15:48 EDT Received: from jarrett (jarrett.den.mmc.com) by everest.den.mmc.com (4.1/1.34.a) id AA28321; Thu, 3 Sep 92 13:48:14 MDT Received: by jarrett (4.1/1.34.a) id AA15012; Thu, 3 Sep 92 13:48:14 MDT Date: Thu, 3 Sep 92 13:48:14 MDT From: robin@jarrett.den.mmc.com (Robin Kladke (303-977-9760)) Message-Id: <9209031948.AA15012@jarrett> To: CLIM@bbn.com Subject: CLIM 2.0 How would a company get hold of CLIM 2.0? I assume that there will be a beta version available well before it is released along with Genera (8.3?). Robin Kladke Martin Marietta (Denver, CO) robin@jarrett.den.mmc.com   Received: from nic.near.net by LABS-N.BBN.COM id aa29054; 3 Sep 92 15:20 EDT Received: from noc.near.net by nic.near.net id aa27142; 3 Sep 92 15:17 EDT Received: from adi.analog.com by noc.near.net id aa13452; 3 Sep 92 15:17 EDT Received: from nwd2sun1.analog.com ([137.71.22.41]) by adi.analog.com Received: from spdn.spdnorth.analog.com by nwd2sun1.analog.com (4.1/SMI-4.1) Received: from lenny.spdn_domain (lenny.spdnorth.analog.com) by spdn.spdnorth.analog.com (4.1/SMI-4.1) id AA19331; Thu, 3 Sep 92 15:16:43 EDT Date: Thu, 3 Sep 92 15:16:43 EDT From: Donal Murphy Message-Id: <9209031916.AA19331@spdn.spdnorth.analog.com> To: clim@noc.near.net Subject: mail address change Please change martin.mallinson@analog.com to martin@cmt.dialnet.symbolics.com in your clim user group mailing list. i am no longer with analog devices, but am still interested in clim. Thanks, Martin Mallinson   Received: from BBN.COM by LABS-N.BBN.COM id aa01192; 3 Sep 92 17:25 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa09496; 3 Sep 92 17:19 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1136295; 3 Sep 1992 17:20:07-0400 Date: Thu, 3 Sep 1992 17:21-0400 From: Scott McKay Subject: Animation To: eilerts@cs.utexas.edu, clim@BBN.COM In-Reply-To: <9209031923.AA18599@sage.cs.utexas.edu> Message-ID: <19920903212109.0.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 3 Sep 1992 15:23 EDT From: Erik Eilerts Could anyone tell me if Clim 2.0 will provide any support for animation? No, not really. You wil be able to do "bitblt" animation by copying out of pixmaps, but that's just a hack. Also, what kind of format will Clim 2.0 bitmaps be stored in, ie. TIFF? CLIM does not specify the representation of bitmaps or pixmaps. It is simple enough to write code the reads in an external-format bitmap and converts it to a CLIM pattern object (which is device independent), and from a pattern into a device-dependent pixmap. This is an area that is ripe for contributions to the nearly empty CLIM library.   Received: from BBN.COM by LABS-N.BBN.COM id aa01587; 3 Sep 92 18:01 EDT Received: from lucid.com by BBN.COM id aa10758; 3 Sep 92 17:57 EDT Received: from oakland-hills.lucid ([192.31.212.153]) by heavens-gate.lucid.com id AA22052g; Thu, 3 Sep 92 14:46:03 PDT Received: by oakland-hills.lucid (4.1/SMI-4.1) id AA03525; Thu, 3 Sep 92 14:47:52 PDT Date: Thu, 3 Sep 92 14:47:52 PDT From: york%oakland-hills@lucid.com (Bill York) Message-Id: <9209032147.AA03525@oakland-hills.lucid> To: TYSON@ai.sri.com Cc: smh@franz.com, SWM@stony-brook.scrc.symbolics.com, jcma@reagan.ai.mit.edu, clim@BBN.COM In-Reply-To: Mabry Tyson's message of Thu, 3 Sep 1992 12:21-0700 <19920903192142.4.TYSON@ELCAPITAN.AI.SRI.COM> Subject: format directives Reply-To: York@lucid.com Date: Thu, 3 Sep 1992 12:21-0700 From: Mabry Tyson As far as portability is concerned, all that should be hidden in CLIM:FORMAT. (I'm guessing that all implementations of CLIM require you to use CLIM:FORMAT since the first arg might not be a CL:STREAM.) Actually, the ultimate goal is for there to be no CLIM:FORMAT. This can happen once all the Lisps follow the same CLOS-based stream prototocl, and all the FORMATs are purified to use only the standard stream protocol to do their output. This may not ever happen, but its a good theory, and I'm loath to invent a new reason to keep CLIM:FORMAT around.   Received: from BBN.COM by LABS-N.BBN.COM id aa01900; 3 Sep 92 18:50 EDT Received: from cs.utexas.edu by BBN.COM id aa12063; 3 Sep 92 18:47 EDT Received: from sage.cs.utexas.edu by cs.utexas.edu (5.64/1.136) with SMTP id AA13318; Thu, 3 Sep 92 17:47:21 -0500 Received: by sage.cs.utexas.edu (5.64/Client-v1.3) id AA19307; Thu, 3 Sep 92 17:47:14 -0500 Message-Id: <9209032247.AA19307@sage.cs.utexas.edu> From: eilerts@cs.utexas.edu (Erik Eilerts) Date: Thu, 3 Sep 1992 17:47:13 -0500 X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: clim@bbn.com Subject: Accept problem I'm having trouble getting the following code to work. What I want is to have an input field where I can enter text or click on an object and have a text description of that object inserted into the field. The problem is that whenever I click on the object, the input immediately terminates, saving only the text that was translated from the object. Any text that was in the input field before the click is lost. What I'd rather happen is that the text from the translated object gets inserted as if it was just typed in. Also, I'd prefer that the input field only terminates when the user hits . Any help is appreciated. Thanks, Erik Eilerts University of Texas at Austin eilerts@cs.utexas.edu The following code is my attempt to get this to work. I've tried many types in the accept call, including some or's, but nothing seems to work. ---------------------------------------------------------------------------- (defclass SLOT-VALUE () ((svalue :initarg :svalue :accessor svalue :initform nil))) (clim::define-presentation-type slot-value ()) (clim::define-presentation-method clim:present (sv-object (type slot-value) stream (view clim:textual-view) &key) (format *terminal-io* "~% presenting ~a (~a)" sv-object (svalue sv-object)) (write-string (format nil "~a" (svalue sv-object)) stream)) (clim:define-presentation-translator right-stuff-value-item (slot-value clim:string clim:global-command-table :documentation "Stuff into buffer." :gesture :select) (object) (let ((str (format nil "~a" (svalue object)))) (format *terminal-io* "~%Left-Mouse for ~a (~a)" object str) str)) (defun do-choose-menu (&optional (host (environment-variable "DISPLAY"))) (let ((stream (if host (clim:open-root-window :clx :host host) (clim:open-root-window :clx))) (slot (make-instance 'slot-value :svalue '(plant has-part leaf))) (result nil)) (multiple-value-bind (x y) (clim:stream-pointer-position* stream) (with-simple-restart (abort nil) (clim:accepting-values (stream :own-window '(:right-margin 200 :bottom-margin 30) :label "Choose Value Input Window" :resynchronize-every-pass nil :x-position (- x 50) :y-position (- y 50)) (terpri stream) (clim:present slot 'slot-value :stream stream) (terpri stream) (terpri stream) (setf result (clim:accept '(clim:null-or-type string) :prompt "Enter a Value" :stream stream))))) result))   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa02234; 3 Sep 92 19:28 EDT To: York@lucid.com cc: TYSON@ai.sri.com, smh@franz.com, SWM@stony-brook.scrc.symbolics.com, jcma@reagan.ai.mit.edu, clim@BBN.COM Subject: Re: format directives In-reply-to: Your message of Thu, 03 Sep 92 14:47:52 -0700. <9209032147.AA03525@oakland-hills.lucid> Date: Thu, 03 Sep 92 19:20:28 -0400 From: kanderso@BBN.COM Date: Thu, 3 Sep 92 14:47:52 PDT From: Bill York To: TYSON@ai.sri.com Cc: smh@franz.com, SWM@stony-brook.scrc.symbolics.com, jcma@reagan.ai.mit.edu, clim@BBN.COM Subject: format directives Reply-To: York@lucid.com Date: Thu, 3 Sep 1992 12:21-0700 From: Mabry Tyson As far as portability is concerned, all that should be hidden in CLIM:FORMAT. (I'm guessing that all implementations of CLIM require you to use CLIM:FORMAT since the first arg might not be a CL:STREAM.) Actually, the ultimate goal is for there to be no CLIM:FORMAT. This can happen once all the Lisps follow the same CLOS-based stream prototocl, and all the FORMATs are purified to use only the standard stream protocol to do their output. This may not ever happen, but its a good theory, and I'm loath to invent a new reason to keep CLIM:FORMAT around. I agree. For performance reasons, when i'm not dealing directly with a CLIM stream, i use (gross) LISP:FLOORMAT. Personally, i'm not as opposed to the "liturgical" (with-mumbling (mumble) (do-mumbly-something)) style, as i am with the (draw-mumble* :do :amazing :things :at :runtime :with :an :extra :gazillion :keywords :you :dont-need) style. Sure, a sufficiently smart compiler can compile them both away, but only your LISP knows for sure. On the other hand, i'm not opposed to a few good variants of FLOORMAT that many people find useful for font bashing, or earcon mumbling. k   Received: from BBN.COM by LABS-N.BBN.COM id aa05693; 4 Sep 92 4:41 EDT Received: from [192.44.1.1] by BBN.COM id aa17439; 4 Sep 92 4:29 EDT Received: by fhg.de (fhg1.fhg.de) with PRESMTP; Fri, 4 Sep 92 10:28:51 +0200 from FHG-GATEWAY Received: by fhg.de (fhg1.fhg.de) with UUCP; Fri, 4 Sep 92 10:28:20 +0200 from imldo Received: by iml.fhg.de with SMTP; Fri, 4 Sep 92 10:20:39 +0200 Date: Fri, 4 Sep 1992 09:18+0100 From: Stefan Bernemann Subject: Re: Accept with '(or...) types that have accept methods To: SWM@STONY-BROOK.SCRC.Symbolics.COM Cc: clim@bbn.com Message-Id: <19920904081817.1.STEFAN@DARK-STAR.iml.fhg.de> [...] >Background: the OR type is implemented by looping over the component >types and running the ACCEPT method for each of components. If one type >"fails" (by signalling a parse-error), the next type is tried. So it's >pretty easy to see what hitting twice uses the second completion >set -- the first signals a parse-error, and the second >completes from the next completion set. > > (I can send a simple example code to anyone who wants it.) > > Don Mitchell dmitchell@trc.amoco.com > Amoco Production Company (918) 660-4270 > Tulsa Research Center > P.O. Box 3385, Tulsa, OK 74102 As Jeff Morill has pointed out, this simple aproach doesn't deal correctly with completions - they should be merged for the or-type to prevent a too early completion. However, can't this simple or-parser be somewhat more user-friendly by pushing the gesture that caused the parse-error back on the stream (via unread-gesture or something) before trying the next type? No user will understand (nor want's to understand) why he should press TAB two times to complete the second type (He even doesn't know of a "second one"). Guess what he thinks if he completes the 23rd type? Stefan B. berni@iml.fhg.de   Received: from BBN.COM by LABS-N.BBN.COM id aa07269; 4 Sep 92 7:36 EDT Received: from life.ai.mit.edu by BBN.COM id aa20063; 4 Sep 92 7:25 EDT Received: from MORRISON.AI.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA13954; Fri, 4 Sep 92 07:25:43 EDT Date: Fri, 4 Sep 1992 07:25-0400 From: John C. Mallery Subject: 2.0 To: clim@bbn.com Message-Id: <19920904112552.6.JCMA@MORRISON.AI.MIT.EDU> Does anyone have a document lying around that details the differences between CLIM 1.1 and 2.0 that they could forward to me?   Received: from BBN.COM by LABS-N.BBN.COM id aa07134; 4 Sep 92 6:58 EDT Received: from mwunix.mitre.org by BBN.COM id aa19530; 4 Sep 92 6:53 EDT Return-Path: Received: from starbase.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA11742; Fri, 4 Sep 92 06:50:54 -0400 Received: by starbase.mitre.org (4.1/SMI-4.1) id AA24412; Fri, 4 Sep 92 06:52:11 EDT Date: Fri, 4 Sep 92 06:52:11 EDT From: chris@starbase.MITRE.ORG (Chris Elsaesser) Message-Id: <9209041052.AA24412@starbase.mitre.org> To: clim@bbn.com Subject: Beta for CLIM 2.0? Any vendors need another beta site for CLIM 2.0? We will! We will! "We" are the MITRE AI Center in McLean VA. We use CLIM on three internally-developed Symbolics Genera systems and an externally-developed Lucid application on Sun unix. We need the Symbolics-developed applications to work on Genera, Lucid (HP and Sun) and MCL. We also have folks who want to develop on MCL. Our applications require color, simple animation, menus, graphs, presentations, etc. Some of our older systems we'd like to convert use Symbolics TV package stuff for some menus. We got bit maps, icons, and home-grown sliders. We need widgets like those available in Mac Smalltalk and Garnet. Anyway, we like CLIM and need some of the 2.0 capability ASAP. Anyone at Symbolics, Franz, Apple, or Lucid like to read bug reports? chris   Received: from BBN.COM by LABS-N.BBN.COM id aa08451; 4 Sep 92 9:37 EDT Received: from life.ai.mit.edu by BBN.COM id aa24438; 4 Sep 92 9:28 EDT Received: from OMEGA.AI.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA15156; Fri, 4 Sep 92 09:28:29 EDT Date: Fri, 4 Sep 1992 09:29-0400 From: John C. Mallery Subject: Fat Strings To: clim@bbn.com Message-Id: <19920904132930.4.JCMA@OMEGA.AI.MIT.EDU> I take it that CLIM does not and will not support fat strings, style bits on characters in strings. That means, writing styled characters to a string will either generate an error or lose the style bits.   Received: from BBN.COM by LABS-N.BBN.COM id aa09566; 4 Sep 92 10:57 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa27833; 4 Sep 92 10:47 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1136651; 4 Sep 1992 10:47:17-0400 Date: Fri, 4 Sep 1992 10:48-0400 From: Scott McKay Subject: Fat Strings To: jcma@reagan.ai.mit.edu, clim@BBN.COM In-Reply-To: <19920904132930.4.JCMA@OMEGA.AI.MIT.EDU> Message-ID: <19920904144824.0.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 4 Sep 1992 09:29 EDT From: "John C. Mallery" I take it that CLIM does not and will not support fat strings, style bits on characters in strings. That means, writing styled characters to a string will either generate an error or lose the style bits. Since dpANS Common Lisp doesn't say anything about the semantics of "fat strings", CLIM's hands are tied. CLIM currently just generates an error, although it might be reasonable for Genera CLIM to either strip out the style bits or do something useful with them if people think that would be a useful "favor" that does not sacrifice portability.   Received: from BBN.COM by LABS-N.BBN.COM id aa09119; 4 Sep 92 10:21 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa26769; 4 Sep 92 10:14 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1136618; 4 Sep 1992 10:14:40-0400 Date: Fri, 4 Sep 1992 10:15-0400 From: Scott McKay Subject: 2.0 To: jcma@reagan.ai.mit.edu, clim@BBN.COM In-Reply-To: <19920904112552.6.JCMA@MORRISON.AI.MIT.EDU> Message-ID: <19920904141548.5.SWM@SUMMER.SCRC.Symbolics.COM> Date: Fri, 4 Sep 1992 07:25 EDT From: "John C. Mallery" Does anyone have a document lying around that details the differences between CLIM 1.1 and 2.0 that they could forward to me? One of the appendices of the CLIM 2.0 spec describes the incompatibilities between CLIM 1.0/1.1 and CLIM 2.0. The other main difference is that CLIM 2.0 uses a different window and event management model so that "native" gadgets can be properly supported. Also, a lot of bugs have been fixed. Presently, CLIM 2.0 runs on Franz Allegro using Motif and OpenLook and on Genera and raw CLX using a bunch of home-grown gadgets. Lucid is working on an OpenLook (I think) for for LCL, and will be distributing a version for MCL 2.0. Symbolics will also be doing a Windows implementation running under Cloe.   Received: from BBN.COM by LABS-N.BBN.COM id aa09039; 4 Sep 92 10:16 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa26547; 4 Sep 92 10:09 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1136608; 4 Sep 1992 10:09:15-0400 Date: Fri, 4 Sep 1992 10:10-0400 From: Scott McKay Subject: format directives To: York@lucid.com, TYSON@ai.sri.com cc: smh@franz.com, SWM@STONY-BROOK.SCRC.Symbolics.COM, jcma@reagan.ai.mit.edu, clim@BBN.COM In-Reply-To: <9209032147.AA03525@oakland-hills.lucid> Message-ID: <19920904141021.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 3 Sep 1992 17:47 EDT From: Bill York Date: Thu, 3 Sep 1992 12:21-0700 From: Mabry Tyson As far as portability is concerned, all that should be hidden in CLIM:FORMAT. (I'm guessing that all implementations of CLIM require you to use CLIM:FORMAT since the first arg might not be a CL:STREAM.) Actually, the ultimate goal is for there to be no CLIM:FORMAT. This can happen once all the Lisps follow the same CLOS-based stream prototocl, and all the FORMATs are purified to use only the standard stream protocol to do their output. This may not ever happen, but its a good theory, and I'm loath to invent a new reason to keep CLIM:FORMAT around. I second that. The idea of reimplementing FORMAT for CLIM is really pretty loathesome.   Received: from BBN.COM by LABS-N.BBN.COM id aa10568; 4 Sep 92 12:26 EDT Received: from [129.197.2.20] by BBN.COM id aa02043; 4 Sep 92 12:22 EDT Received: by eagle.is.lmsc.lockheed.com (5.57/Ultrix3.0-C) id AA06595; Fri, 4 Sep 92 09:21:28 -0700 Received: from RDD_SERVER (QM 2.5) by qm.is.lmsc.lockheed.com (SMTP\QM 1.1.3) id AA04097; Fri, 4 Sep 1992 9:27:32 PST Message-Id: <00073.2798443652.4097@qm.is.lmsc.lockheed.com> Organization: Lockheed Missiles & Space Co. X-Charset: MACINTOSH To: clim@bbn.com (internet a clim-request) From: T._Trinko@qm.is.lmsc.lockheed.com (T. Trinko) Date: Fri, 4 Sep 1992 9:24:07 PST Subject: Re: Fat Strings Reply to: RE>Fat Strings Date: Fri, 4 Sep 1992 09:29 EDT From: "John C. Mallery" I take it that CLIM does not and will not support fat strings, style bits on characters in strings. That means, writing styled characters to a string will either generate an error or lose the style bits. Since dpANS Common Lisp doesn't say anything about the semantics of "fat strings", CLIM's hands are tied. CLIM currently just generates an error, although it might be reasonable for Genera CLIM to either strip out the style bits or do something useful with them if people think that would be a useful "favor" that does not sacrifice portability. >>>>>>>Given this is so I'd appreciate it if anyone can help me with this problem. Our application was structured so that objects generated various text items. The objects know what sort of formating the text should have. The text was then sent to a generic function for printing. Now it seems that we have to duplicate the generic functions capabilities in every method which needs to print text if we want to continue to use text styles. Is there any way around this? Thanks.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa11681; 4 Sep 92 13:58 EDT From: Dan Cerys Reply-To: CLIM-Request@BBN.COM Organization: Bolt Beranek and Newman Inc. To: clim@BBN.COM Subject: Administrivia Date: Fri, 4 Sep 92 13:45:39 EDT Sender: cerys@BBN.COM Just a reminder about adding/deleting yourself from the CLIM mailing list (and most other mailing lists). For adminstrative matters that don't need to be shared with everyone on the mailing list, send mail to: CLIM-Request@bbn.com. The mailing list convention is: For the mailing list named @, send requests to -request@. Thanks, Dan   Received: from BBN.COM by LABS-N.BBN.COM id aa14758; 4 Sep 92 18:31 EDT Received: from lucid.com by BBN.COM id aa19732; 4 Sep 92 18:25 EDT Received: from campeau.lucid (campeau.lucid.com) by heavens-gate.lucid.com id AA25443g; Fri, 4 Sep 92 15:14:26 PDT Received: by campeau.lucid (4.1/SMI-4.1) id AA17206; Fri, 4 Sep 92 15:20:59 PDT Date: Fri, 4 Sep 92 15:20:59 PDT From: pw@lucid.com (Paul Wieneke) Message-Id: <9209042220.AA17206@campeau.lucid> To: SWM@stony-brook.scrc.symbolics.com Cc: jcma@reagan.ai.mit.edu, clim@BBN.COM In-Reply-To: Scott McKay's message of Fri, 4 Sep 1992 10:15-0400 <19920904141548.5.SWM@SUMMER.SCRC.Symbolics.COM> Subject: 2.0 Date: Fri, 4 Sep 1992 10:15-0400 From: Scott McKay Date: Fri, 4 Sep 1992 07:25 EDT From: "John C. Mallery" Does anyone have a document lying around that details the differences between CLIM 1.1 and 2.0 that they could forward to me? One of the appendices of the CLIM 2.0 spec describes the incompatibilities between CLIM 1.0/1.1 and CLIM 2.0. The other main difference is that CLIM 2.0 uses a different window and event management model so that "native" gadgets can be properly supported. Also, a lot of bugs have been fixed. Presently, CLIM 2.0 runs on Franz Allegro using Motif and OpenLook and on Genera and raw CLX using a bunch of home-grown gadgets. Lucid is working on an OpenLook (I think) for for LCL, and will be distributing a version for MCL 2.0. Symbolics will also be doing a Windows implementation running under Cloe. One minor correction. Lucid is also working on a Motif backend based on a Motif FFI toolkit. OpenLook and CLX versions will follow.   Received: from BBN.COM by LABS-N.BBN.COM id aa06131; 7 Sep 92 19:43 EDT Received: from life.ai.mit.edu by BBN.COM id aa26754; 7 Sep 92 19:38 EDT Received: from OMEGA.AI.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA01628; Mon, 7 Sep 92 19:38:05 EDT Date: Mon, 7 Sep 1992 19:39-0400 From: John C. Mallery Subject: MULTIPLE-MENU-CHOOSE To: clim@bbn.com Message-Id: <19920907233907.2.JCMA@OMEGA.AI.MIT.EDU> How come CLIM does not provide a facility analogous to tv:MULTIPLE-MENU-CHOOSE on the Lisp Machine? This addresses a common choice situation and everyone will just have to write their own anyway.   Received: from KARIBA.BBN.COM by LABS-N.BBN.COM id aa13544; 8 Sep 92 10:33 EDT Received: by KARIBA.BBN.COM id aa19517; 8 Sep 92 10:23 EDT To: "John C. Mallery" cc: clim@BBN.COM Subject: Re: MULTIPLE-MENU-CHOOSE In-reply-to: "John C. Mallery"'s message of Mon, 07 Sep 92 19:39:00 -0400. <19920907233907.2.JCMA@OMEGA.AI.MIT.EDU> Reply-To: jmorrill@BBN.COM Date: Tue, 08 Sep 92 10:17:53 -0400 Message-ID: <1534.715961873@bbn.com> From: Jeff Morrill Date: Mon, 7 Sep 1992 19:39-0400 From: "John C. Mallery" How come CLIM does not provide a facility analogous to tv:MULTIPLE-MENU-CHOOSE on the Lisp Machine? This addresses a common choice situation and everyone will just have to write their own anyway. This antique could easily be implemented on top of accepting-values. If you want to use all those old genera-6 style menu-choose types, however, you'll have to throw in some code that maps them to existing presentation-types. This is the kind of thing that ought to be in the user-contributed library. Any volunteers?   Received: from BBN.COM by LABS-N.BBN.COM id aa14525; 8 Sep 92 11:33 EDT Received: from RIVERSIDE.SCRC.Symbolics.COM by BBN.COM id aa17364; 8 Sep 92 11:26 EDT Received: from SEVERN.SLTD.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 900671; 8 Sep 1992 11:26:59-0400 Received: from PORTER.ASL.DIALNET.SYMBOLICS.COM by SEVERN.sltd.dialnet.symbolics.com via DIAL with SMTP id 97301; 8 Sep 1992 16:05:38-0000 Received: from K.ASL.dialnet.symbolics.com by porter.asl.dialnet.symbolics.com via INTERNET with SMTP id 41533; 4 Sep 1992 23:19:15-0000 Date: Fri, 4 Sep 1992 23:19-0000 From: Peter Paine Subject: 2.0 To: clim%BBN.COM@Severn.SLTD.dialnet.symbolics.com In-Reply-To: <19920904141548.5.SWM@SUMMER.SCRC.Symbolics.COM> Message-ID: <19920904231917.1.P2@K.ASL.dialnet.symbolics.com> Date: Fri, 4 Sep 1992 14:15-0000 From: Scott McKay Date: Fri, 4 Sep 1992 07:25 EDT From: "John C. Mallery" Does anyone have a document lying around that details the differences between CLIM 1.1 and 2.0 that they could forward to me? One of the appendices of the CLIM 2.0 spec describes the incompatibilities between CLIM 1.0/1.1 and CLIM 2.0. The other main difference is that CLIM 2.0 uses a different window and event management model so that "native" gadgets can be properly supported. Also, a lot of bugs have been fixed. Presently, CLIM 2.0 runs on Franz Allegro using Motif and OpenLook and on Genera and raw CLX using a bunch of home-grown gadgets. Lucid is working on an OpenLook (I think) for for LCL, and will be distributing a version for MCL 2.0. Symbolics will also be doing a Windows implementation running under Cloe. What sort of Cloe?   Received: from BBN.COM by LABS-N.BBN.COM id aa14661; 8 Sep 92 11:36 EDT Received: from adler.ims.uni-stuttgart.de by BBN.COM id aa17525; 8 Sep 92 11:29 EDT Received: from milan.ims.uni-stuttgart.de by adler.ims.uni-stuttgart.de (4.1/IMS-1.1) id AA20462; Tue, 8 Sep 92 17:29:18 +0200 Date: Tue, 8 Sep 92 17:29:18 +0200 From: Oliver Christ Message-Id: <9209081529.AA20462@adler.ims.uni-stuttgart.de> X-Message: The domain philosophie.uni-stuttgart.de is no longer valid. Please use the name IMS.UNI-STUTTGART.DE instead ! Received: by milan.ims.uni-stuttgart.de id AA17248; Tue, 8 Sep 92 17:29:19 +0200 To: jcma@reagan.ai.mit.edu, clim@BBN.COM Subject: MULTIPLE-MENU-CHOOSE Reply-To: oli@ims.uni-stuttgart.de Why don't you use the CTV-MENU package (info below)? There are some pretty useful functions in it... It's obtainable by anonymous ftp from ai.sri.com in the directory /pub/pkarp/lisp/ctv-menu/. Greetings, Oli ====================================================================== ;;;; CLIM Emulation of Symbolics Menu Functions ;;;; ;;;; This package emulates a number of Symbolics menu functions from the TV: ;;;; package to faciliate porting of Symbolics code to CLIM. Wherever possible ;;;; the original parameters and parameter formats have been maintained. In ;;;; some cases, additional parameters have been added to enhance a particular ;;;; function. ;;;; ;;;; Authors: ;;;; Peter Karp ;;;; Mabry Tyson ;;;; David Wilkins ;;;; Scott McKay ;;;; ;;;; Please report bugs, bug fixes, and enhancements to Peter Karp ;;;; -- pkarp@ai.sri.com ;;;; ;;;; You are free to copy and redistribute this code, but anyone receiving ;;;; this code from a source other than SRI should report bugs to that source. ;;;; ;;;; This is not supported software -- use at your own risk. SRI ;;;; International does not warrant the performance or results that may be ;;;; obtained by using this software. SRI International disclaims all ;;;; warranties as to performance or fitness of this software for any ;;;; particular purpose.   Received: from BBN.COM by LABS-N.BBN.COM id aa13345; 8 Sep 92 10:22 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa13486; 8 Sep 92 10:06 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1138044; 8 Sep 1992 10:06:57-0400 Date: Tue, 8 Sep 1992 10:07-0400 From: Scott McKay Subject: MULTIPLE-MENU-CHOOSE To: jcma@reagan.ai.mit.edu, clim@BBN.COM In-Reply-To: <19920907233907.2.JCMA@OMEGA.AI.MIT.EDU> Message-ID: <19920908140732.5.SWM@SUMMER.SCRC.Symbolics.COM> Date: Mon, 7 Sep 1992 19:39 EDT From: "John C. Mallery" How come CLIM does not provide a facility analogous to tv:MULTIPLE-MENU-CHOOSE on the Lisp Machine? This addresses a common choice situation and everyone will just have to write their own anyway. Try these for CLIM 1.1. I'll probably install some form of this stuff in CLIM 2.0. Could somebody at BBN please install this in the "CLIM library" as multiple-menus.lisp? Thanks. -------- cut here -------- ;;; -*- Mode: LISP; Syntax: Common-Lisp; Package: CLIM; Base: 10; Lowercase: Yes -*- "Copyright (c) 1991, 1992 Symbolics, Inc. All rights reserved." (in-package "CLIM") (export '(clim::menu-multiple-choose) 'clim) (define-presentation-type menu-multiple-choose-selection ()) (define-presentation-type menu-multiple-choose-button ()) ;; Menu interface for choosing a (possibly empty) subset of items. ;; ITEMS is as for MENU-CHOOSE. (defun menu-multiple-choose (items &key (associated-window (frame-top-level-window *application-frame*)) default-style label (printer #'print-menu-item) max-width max-height n-rows n-columns inter-column-spacing inter-row-spacing (cell-align-x ':left) (cell-align-y ':top) all-button none-button) (with-menu (stream associated-window) (setf (window-label stream) label) (with-end-of-page-action (:allow stream) (with-end-of-line-action (:allow stream) (with-text-style (default-style stream) (let ((selections (map 'list #'(lambda (x) (list x nil)) items)) (selection-pieces ()) ;;--- Need this first-piece kludge to work around a redisplay ;;--- bug that causes the first item to be erased whenever ;;--- any other item is redisplayed. (first-piece nil)) ;; Display all the selections, collecting redisplay pieces as we go (formatting-item-list (stream :max-width max-width :max-height max-height :n-rows n-rows :n-columns n-columns :inter-column-spacing inter-column-spacing :inter-row-spacing inter-row-spacing) (dolist (selection selections) (formatting-cell (stream :align-x cell-align-x :align-y cell-align-y) (let ((piece (let ((selection selection)) (updating-output (stream) (updating-output (stream :unique-id selection :cache-value (second selection)) (with-output-as-presentation (:stream stream :object selection :type 'menu-multiple-choose-selection) (if (second selection) (with-text-face (:bold stream) (funcall printer (first selection) stream)) (funcall printer (first selection) stream)))))))) (when (null first-piece) (setq first-piece piece)) (push (list selection piece) selection-pieces)))) (when all-button (when (eql all-button 't) (setq all-button "All")) (formatting-cell (stream :align-x cell-align-x :align-y cell-align-y) (with-output-as-presentation (:stream stream :object ':all :type 'menu-multiple-choose-button) (with-text-face (:italic stream) (write-string all-button stream))))) (when none-button (when (eql none-button 't) (setq none-button "None")) (formatting-cell (stream :align-x cell-align-x :align-y cell-align-y) (with-output-as-presentation (:stream stream :object ':none :type 'menu-multiple-choose-button) (with-text-face (:italic stream) (write-string none-button stream)))))) ;; Display the exit boxes (let ((exit " uses these values") (abort " aborts")) (terpri stream) (updating-output (stream :unique-id stream :cache-value 'exit-boxes) (with-output-as-presentation (:stream stream :type 'accept-values-exit-box :object ':abort) (write-string abort stream)) (write-string ", " stream) (with-output-as-presentation (:stream stream :type 'accept-values-exit-box :object ':exit) (write-string exit stream))) (terpri stream)) ;; Size and expose the multiple-choice menu (size-menu-appropriately stream) (multiple-value-bind (x y) (stream-pointer-position-in-window-coordinates (window-parent stream)) (position-window-near-carefully stream x y)) (window-expose stream) ;; Now read from the menu (with-input-focus (stream) (loop (with-input-context ('(or menu-multiple-choose-selection menu-multiple-choose-button accept-values-exit-box) :override t) (object) (read-gesture :stream stream) (menu-multiple-choose-selection (setf (second object) (not (second object))) (let ((piece (second (assoc object selection-pieces)))) (when piece (redisplay piece stream) (unless (eql piece first-piece) (replay first-piece stream))))) (menu-multiple-choose-button (ecase object (:all (dolist (selection-piece selection-pieces) (let ((selection (first selection-piece)) (piece (second selection-piece))) (unless (second selection) (setf (second selection) t) (redisplay piece stream) (unless (eql piece first-piece) (replay first-piece stream)))))) (:none (dolist (selection-piece selection-pieces) (let ((selection (first selection-piece)) (piece (second selection-piece))) (when (second selection) (setf (second selection) nil) (redisplay piece stream) (unless (eql piece first-piece) (replay first-piece stream)))))))) (accept-values-exit-box (ecase object (:abort (return-from menu-multiple-choose nil)) (:exit (return-from menu-multiple-choose (mapcan #'(lambda (selection) (and (second selection) (list (menu-item-value (first selection))))) selections)))))))))))))) #|| () (menu-multiple-choose (loop for i below 40 collect (cons (format nil "~R" i) i))) ||# (export '(clim::multiple-choice-menu-choose) 'clim) (defclass multiple-choice-check-box () ((value :accessor check-box-value :initarg :value) (item :reader check-box-item :initarg :item)c (choice :reader check-box-choice :initarg :choice) (presentation :accessor check-box-presentation) (prompt :accessor check-box-prompt))) ;;--- This should be in CLIM itself, no? (define-presentation-method presentation-typep (object (type accept-values-exit-box)) (or (eq object :exit) (eq object :abort))) (define-presentation-method highlight-presentation ((type multiple-choice-check-box) record stream state) (declare (ignore state)) (let* ((check-box (presentation-object record)) (prompt (check-box-prompt check-box))) (with-bounding-rectangle* (left top right bottom) prompt (declare (ignore top)) (multiple-value-bind (xoff yoff) (convert-from-relative-to-absolute-coordinates stream (output-record-parent prompt)) (draw-line-internal stream xoff yoff left bottom right bottom +flipping-ink+ +highlighting-line-style+))))) (defun menu-item-choices (menu-item) (menu-item-getf menu-item :choices)) ;; Menu interface for selecting among a number of possibilities for some items. ;; ITEMS is as for MENU-CHOOSE, with a new :CHOICES option that specifies a list ;; of choices for one item. Each choice is a list of a choice name (a symbol) ;; and its initial value (true or false). If the choice is a symbol instead of ;; a list, the initial value is false. ;; CHOICES is a list of the possible choices, (SYMBOL NAME . IMPLICATIONS). ;; SYMBOL names the choice (used in the item's choices), NAME is a string of its ;; name, and IMPLICATIONS is a list of on-positive, on-negative, off-positive, and ;; off-negative implications for when the choice is selected, each one either a ;; list of (other) keywords or T for all other keywords. IMPLICATIONS defaults ;; to (NIL T NIL NIL). ;; The returned value is a list of (ITEM-VALUE . CHOICE-VALUES), where ITEM-VALUE ;; is a value from ITEMS and CHOICE-VALUES are all of the choices selected for ;; that item. (defun multiple-choice-menu-choose (items choices &key (associated-window (frame-top-level-window *application-frame*)) default-style label) (let ((hash-table (make-hash-table :test #'equal))) (with-menu (stream associated-window) (labels ((draw-check-box (check-box x y) (let ((radius 5)) (draw-rectangle* stream x y (+ x 10) (+ y 10) :filled nil) (draw-circle* stream (+ x radius) (+ y radius) (- radius 3) :ink (if (check-box-value check-box) +foreground+ +background+) :filled t))) (redraw-check-box (check-box presentation new-value) (multiple-value-bind (x y) (bounding-rectangle-position* presentation) (multiple-value-bind (xoff yoff) (convert-from-relative-to-absolute-coordinates stream (output-record-parent presentation)) (translate-positions xoff yoff x y)) (setf (check-box-value check-box) new-value) (draw-check-box check-box x y)))) (declare (dynamic-extent #'draw-check-box #'redraw-check-box)) (macrolet ((choice-name (choice) `(if (consp ,choice) (second ,choice) ,choice)) (choice-value (choice) `(if (consp ,choice) (first ,choice) ,choice)) (choice-implications (choice) `(if (consp ,choice) (or (rest (rest ,choice)) '(nil t nil nil)) '(nil t nil nil))) (check-box (item choice) `(gethash (cons (menu-item-value ,item) (choice-value ,choice)) hash-table))) (setf (window-label stream) label) (with-end-of-page-action (:allow stream) (with-end-of-line-action (:allow stream) (with-text-style (default-style stream) ;; Initialize hash table (dolist (item items) (dolist (choice choices) (block no-choice (let ((value (dolist (ch (menu-item-choices item) (return-from no-choice)) (if (consp ch) (and (eq (choice-value choice) (first ch)) (return (second ch))) (and (eq (choice-value choice) ch) (return nil)))))) (setf (check-box item choice) ;; Make new instance, and transfer the (maybe) ;; preset value in this location into the button (make-instance 'multiple-choice-check-box :value value :item item :choice choice)))))) (formatting-table (stream :equalize-column-widths t) ;; Generate heading (formatting-row (stream) (dolist (choice (cons " " choices)) (formatting-cell (stream :align-x :center) (let ((choice-name (choice-name choice))) (present choice-name (presentation-type-of choice-name) :stream stream))))) (fresh-line) ;; Generate the check boxes for each item (dolist (item items) (formatting-row (stream) (let ((prompt (formatting-cell (stream :align-y :center) (print-menu-item item stream)))) (dolist (choice choices) (formatting-cell (stream :align-x :center :align-y :center) (let ((check-box (check-box item choice))) (cond (check-box (setf (check-box-presentation check-box) (with-output-as-presentation (:stream stream :object check-box :type 'multiple-choice-check-box :single-box t) (draw-check-box check-box 0 0))) (setf (check-box-prompt check-box) prompt)) (t (write-string " " stream)))))))))) (terpri stream) ;; Generate exit boxes (let ((exit " uses these values") (abort " aborts")) (terpri stream) (with-output-as-presentation (:stream stream :type 'accept-values-exit-box :object ':abort) (write-string abort stream)) (write-string ", " stream) (with-output-as-presentation (:stream stream :type 'accept-values-exit-box :object ':exit) (write-string exit stream)) (terpri stream))) ;; Size and expose the multiple-choice menu (size-menu-appropriately stream) (multiple-value-bind (x y) (stream-pointer-position-in-window-coordinates (window-parent stream)) (position-window-near-carefully stream x y)) (window-expose stream) ;; Now handle user input (let ((button-pressed-p nil) (last-check-box nil) (highlighted-presentation nil) (highlighted-type nil)) (flet ((handle-presentation (presentation) ;; Called for side effect (toggle button) and returned ;; value return value is a symbol when exit box clicked, ;; otherwise NIL (let ((object (presentation-object presentation)) (type (presentation-type presentation))) (case (presentation-type-name type) (accept-values-exit-box (setq last-check-box nil) object) (multiple-choice-check-box ;; Don't toggle this button unless we have been ;; somewhere else in the interim (unless (eql object last-check-box) (let ((new-value (not (check-box-value object))) (implications (choice-implications (check-box-choice object)))) (redraw-check-box object presentation new-value) ;; Process the implications (let ((on (if new-value (nth 0 implications) (nth 2 implications))) (off (if new-value (nth 1 implications) (nth 3 implications)))) (dolist (choice choices) (unless (eql choice (check-box-choice object)) (let ((other-box (check-box (check-box-item object) choice))) (when other-box (when (or (eql on 't) (member choice on)) (redraw-check-box other-box (check-box-presentation other-box) t)) (when (or (eql off 't) (member choice off)) (redraw-check-box other-box (check-box-presentation other-box) nil))))))))) (setq last-check-box object) nil)))) (handle-exit () (let ((results nil)) (dolist (item items) (let ((result nil)) (dolist (choice choices) (let* ((check-box (check-box item choice)) (value (and check-box (check-box-value check-box)))) (when (and check-box value) (push (choice-value choice) result)))) (push (cons (menu-item-value item) (nreverse result)) results))) (return-from multiple-choice-menu-choose (nreverse results))))) (declare (dynamic-extent #'handle-presentation #'handle-exit)) (macrolet ((highlight (presentation) `(progn (setq highlighted-presentation ,presentation highlighted-type (presentation-type ,presentation)) (highlight-presentation highlighted-presentation highlighted-type stream :highlight))) (unhighlight () `(when highlighted-presentation (highlight-presentation highlighted-presentation highlighted-type stream :unhighlight) (setq highlighted-presentation nil)))) (with-output-recording-options (stream :record-p nil) (tracking-pointer (stream :context-type '(or multiple-choice-check-box accept-values-exit-box) :multiple-window nil :highlight nil) (:pointer-motion () (unhighlight) (setq last-check-box nil)) (:presentation-button-press (presentation) (setq button-pressed-p t) (let ((exit (handle-presentation presentation))) (case exit (:exit (handle-exit)) (:abort (return-from multiple-choice-menu-choose nil))))) (:pointer-button-release () (setq button-pressed-p nil) (setq last-check-box nil)) (:presentation (presentation) (unless (eql presentation highlighted-presentation) (unhighlight) (highlight presentation)) (when button-pressed-p ;; Don't handle the exit boxes unless the user ;; clicks on one of them explicitly (handle-presentation presentation))) (:keyboard (character) (when (member character '(#+Genera #\End)) (handle-exit))))))))))))))) #|| () (multiple-choice-menu-choose '(("Buffer1" :value buffer1 :choices ((:save t) :kill :not-modified :hardcopy)) ("Buffer2" :value buffer2 :choices ((:save t) :kill :not-modified :hardcopy)) ("Buffer3" :value buffer3 :choices ((:save t) :kill :not-modified :hardcopy)) ("Buffer4" :value buffer4 :choices (:save :kill :not-modified :hardcopy)) ("Buffer5" :value buffer5 :choices ((:save t) :kill :not-modified :hardcopy))) '((:save "Save" nil (:not-modified) nil nil) (:kill "Kill" nil (:not-modified) nil nil) (:not-modified "UnMod" nil (:save) nil nil) (:hardcopy "Hardcopy" nil nil nil nil))) ||#   Received: from BBN.COM by LABS-N.BBN.COM id aa26208; 9 Sep 92 6:22 EDT Received: from mcsun.EU.net by BBN.COM id aa21700; 9 Sep 92 6:09 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA18670 (5.65b/CWI-2.174); Wed, 9 Sep 1992 12:09:14 +0200 Received: from nrb.UUCP by ub4b.buug.be (5.65c/ub4b_02) id AA28750; Wed, 9 Sep 1992 12:09:19 +0200 Received: from nrbmi1.ia.nrb.be by scosysv.nrb.be with SMTP (5.59/NRB25-f-eef-ev@nrb) id AA04055; Wed, 9 Sep 92 18:06:04 +0100 Date: Wed, 9 Sep 1992 12:06+0200 From: Vincent Keunen Reply-To: nrb!keunen@relay.EU.net Subject: Animation To: clim@nrbmi2.ia.nrb.be In-Reply-To: <19920903212109.0.SWM@SUMMER.SCRC.Symbolics.COM> Message-Id: <19920909100622.2.KEUNEN@nrbmi1.ia.nrb.be> Date: Thu, 3 Sep 1992 23:21+0200 From: Scott McKay Date: Thu, 3 Sep 1992 15:23 EDT From: Erik Eilerts Could anyone tell me if Clim 2.0 will provide any support for animation? No, not really. You wil be able to do "bitblt" animation by copying out of pixmaps, but that's just a hack. Also, what kind of format will Clim 2.0 bitmaps be stored in, ie. TIFF? CLIM does not specify the representation of bitmaps or pixmaps. It is simple enough to write code the reads in an external-format bitmap and converts it to a CLIM pattern object (which is device independent), and from a pattern into a device-dependent pixmap. This is an area that is ripe for contributions to the nearly empty CLIM library. ...which is available thru anonymous ftp at cambridge.apple.com/pub/clim. Just a reminder. vk -- Keunen Vincent Network Research Belgium R&D, Software Engineer Parc Industriel des Hauts-Sarts keunen@nrb.be 2e Avenue, 65 tel: +32 41 407282 B-4040 Herstal fax: +32 41 481170 BELGIUM   Received: from BBN.COM by LABS-N.BBN.COM id aa01720; 9 Sep 92 13:05 EDT Received: from aerospace.aero.org by BBN.COM id aa08921; 9 Sep 92 12:53 EDT Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT) id AA29770 for clim@bbn.com; Wed, 9 Sep 1992 09:53:25 -0700 Posted-Date: Wed, 9 Sep 92 09:53:20 PDT Message-Id: <199209091653.AA29770@aerospace.aero.org> Received: from reify.aero.org by antares.aero.org (4.1/AMS-1.0) id AA28494 for cer@franz.com; Wed, 9 Sep 92 09:53:22 PDT Date: Wed, 9 Sep 92 09:53:20 PDT From: abbott@aero.org To: cer@franz.com Cc: clim@bbn.com, clim@aero.org In-Reply-To: Chris Richardson's message of Tue, 18 Aug 92 10:25:14 -0700 <9208181725.AA10390@vapor.Franz.COM> Subject: accept-values-command-button fails to appear When the code at the bottom is loaded, and I run CLIM-USER(x): (create-W) CLIM-USER(x+1): (test) my window displays: call: function-call return from: function-call ... But it fails to display the accept-values-command-button "Button". Also, the only mouse-sensitive spots on the screen are the exit boxes. My Lisp window displays: enter: accepting-values enter: function-call exit: function-call exit: accepting-values ;; When I exit the accepting-values. Why isn't the Button displayed? -- Russ Abbott P.S. This is Clim 1.1 in Allegro Lisp on a SPARC Sun. ----------------------------------------------------------------------- (defvar *clim-root* (open-root-window :clx)) (defvar W ()) (defvar *so* *standard-output*) (defun create-W () (setq W (open-window-stream :parent *clim-root* :height 100 :width 500)) (window-expose W) (window-stack-on-top W) (force-output W) ) (defun test () (window-clear W) (window-stack-on-top W) (accepting-values (W) (format *so* "~%enter: accepting-values") (format W "~%call: function-call") (function-call W) (format W "~%return: function-call") ) (format *so* "~%exit: accepting-values") (window-clear W) (force-output W)) (defun function-call (W) (format *so* "~%enter: function-call") (accept-values-command-button (W) 'Button (format *so* "~%Click") ) (format *so* "~%exit: function-call") )   Received: from BBN.COM by LABS-N.BBN.COM id aa01812; 9 Sep 92 13:11 EDT Received: from hyper.franz.com by BBN.COM id aa09356; 9 Sep 92 13:06 EDT Return-Path: Received: from vapor.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA21537; Wed, 9 Sep 92 10:05:11 PDT Received: by vapor.Franz.COM (4.1/FI-2.0) id AA11075; Wed, 9 Sep 92 10:04:19 PDT Message-Id: <9209091704.AA11075@vapor.Franz.COM> To: abbott@aero.org Cc: clim@bbn.com, clim@aero.org Subject: Re: accept-values-command-button fails to appear In-Reply-To: Your message of Wed, 09 Sep 92 09:53:20 PDT. <199209091653.AA29770@aerospace.aero.org> Date: Wed, 09 Sep 92 10:04:18 -0700 From: Chris Richardson In (accept-values-command-button (stream) prompt . body ) the prompt is either a string or a form that sends output to stream. You had written 'button which was treated as form and since it did not generate any output you ended up with a rather small button.   Received: from BBN.COM by LABS-N.BBN.COM id aa05453; 9 Sep 92 17:39 EDT Received: from mwunix.mitre.org by BBN.COM id aa24253; 9 Sep 92 17:32 EDT Return-Path: Received: from cypress.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA06756; Wed, 9 Sep 92 17:29:46 -0400 Received: by cypress.mitre.org (4.1/SMI-4.1) id AA00612; Wed, 9 Sep 92 17:37:44 EDT Date: Wed, 9 Sep 92 17:37:44 EDT From: gmw@cypress.mitre.org (Gregory M. Whittaker) Message-Id: <9209092137.AA00612@cypress.mitre.org> To: lwolf@franz.com Subject: postscript output with scaling and draw-text* in CLIM 1.1 Cc: CLIM@bbn.com, cl-bugs@franz.com, gmw@cypress.mitre.org Dear Lois, I'm re-sending my current version of a postscript grapher for class hierarchies. I have dropped the with-scaling macro and gone to the with-drawing-options equivalent since I need to explicitly pass the transform to the draw-text* function as well. Unfortunately the entire combination results in no improvement over the original. It appears that draw-text* generic-function ignores the passed in transform after checking that it is indeed a transform. Text is identical in size and placement no matter what I supply for a size. The tree links only match up with the textual node positions when the size = 1.0. I'm back to using CLIM 1.1 because with-output-to-postscript-stream is not yet supported in CLIM 2.0.alpha. I'm using the Franz version on a SPARCstation 2. Surely someone out there has done this before! What am I doing wrong? Here is the code: (defmethod print-scaled-subclass-tree ((name symbol) &optional (size 1.0)) (let* ((class (find-class name)) (filename (concatenate 'string (string (class-name class)) "-subclass-tree.ps"))) (with-open-file (file filename :direction :output :if-exists :supersede) (clim:with-output-to-postscript-stream (stream file :multi-page t) (let ((transform (clim:make-scaling-transformation size size))) (clim:with-drawing-options (stream :transformation transform) (clim:format-graph-from-root class #'(lambda (object s) (multiple-value-call #'clim:draw-text* s (string (class-name object)) (clim:stream-cursor-position* s) :align-y :center :transformation transform)) #'clos:class-direct-subclasses :stream stream)))) ))) ;;;(excl:run-shell-command (concatenate 'string "lpr " filename))))) ;;; if you actually want to print out the results, uncomment the above ;;; line and delete the preceding three close-parens. I've been simply ;;; using pageview to examine the results of the tests, and only print- ;;; hardcopy when necesary for documentation. -------- Cordially, Gregory M. Whittaker, The MITRE Corporation Center for Advanced Aviation System Development Internet: greg@mitre.org 7525 Colshire Drive Phone: (703) 883-5549 McLean Virginia 22102-3481 FAX: (703) 883-1226 Mail Stop: W215   Received: from BBN.COM by LABS-N.BBN.COM id aa05088; 9 Sep 92 17:15 EDT Received: from life.ai.mit.edu by BBN.COM id aa23133; 9 Sep 92 17:06 EDT Received: from OMEGA.AI.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA26537; Wed, 9 Sep 92 17:06:39 EDT Date: Wed, 9 Sep 1992 17:07-0400 From: John C. Mallery Subject: :LABEL-STYLE ? To: clim@bbn.com Message-Id: <19920909210741.1.JCMA@OMEGA.AI.MIT.EDU> There are numerous functions accepting the LABEL argument. Since there are no fat strings in CLIM (even though you can do present-to-string), how is one supposed to get the LABEL into a particular text-style? I haven't been finding any LABEL-STYLE arguments -- which would be the obvious thing in the absence of encoding styles directly in fat strings passed through the LABEL argument.   Received: from BBN.COM by LABS-N.BBN.COM id aa06031; 9 Sep 92 18:27 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa25680; 9 Sep 92 18:20 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1139173; 9 Sep 1992 18:20:55-0400 Date: Wed, 9 Sep 1992 18:21-0400 From: Scott McKay Subject: :LABEL-STYLE ? To: jcma@reagan.ai.mit.edu, clim@BBN.COM In-Reply-To: <19920909210741.1.JCMA@OMEGA.AI.MIT.EDU> Message-ID: <19920909222142.4.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 9 Sep 1992 17:07 EDT From: "John C. Mallery" There are numerous functions accepting the LABEL argument. Since there are no fat strings in CLIM (even though you can do present-to-string), how is one supposed to get the LABEL into a particular text-style? I haven't been finding any LABEL-STYLE arguments -- which would be the obvious thing in the absence of encoding styles directly in fat strings passed through the LABEL argument. CLIM 2.0 does a more consistent job of handling this, but the underlying toolkit may sometimes decline to put text styles everywhere you want.   Received: from BBN.COM by LABS-N.BBN.COM id aa12436; 10 Sep 92 7:07 EDT Received: from life.ai.mit.edu by BBN.COM id aa06531; 10 Sep 92 7:00 EDT Received: from OMEGA.AI.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA19656; Thu, 10 Sep 92 07:00:18 EDT Date: Thu, 10 Sep 1992 07:01-0400 From: John C. Mallery Subject: FQUERY To: CLIM@bbn.com Message-Id: <19920910110121.2.JCMA@OMEGA.AI.MIT.EDU> Does CLIM provide a facility accepting single characters from the user, along the lines of FQUERY in the Lisp Machine?   Received: from BBN.COM by LABS-N.BBN.COM id aa12466; 10 Sep 92 7:11 EDT Received: from life.ai.mit.edu by BBN.COM id aa06688; 10 Sep 92 7:06 EDT Received: from OMEGA.AI.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA19875; Thu, 10 Sep 92 07:06:01 EDT Date: Thu, 10 Sep 1992 07:07-0400 From: John C. Mallery Subject: TYPEOUT-WINDOWS To: clim@bbn.com Message-Id: <19920910110703.3.JCMA@OMEGA.AI.MIT.EDU> Does CLIM have the concept of TYPEOUT-WINDOWS, or roll down windows for exceptional output? If so, how do I get it via define-application-frame? If not, how long do I have to wait for it?   Received: from BBN.COM by LABS-N.BBN.COM id aa11654; 10 Sep 92 6:30 EDT Received: from mcsun.EU.net by BBN.COM id aa05894; 10 Sep 92 6:19 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA21881 (5.65b/CWI-2.174); Thu, 10 Sep 1992 12:19:14 +0200 Received: from nrb.UUCP by ub4b.buug.be (5.65c/ub4b_02) id AA22458; Thu, 10 Sep 1992 12:19:17 +0200 Received: from nrbmi1.ia.nrb.be by scosysv.nrb.be with SMTP (5.59/NRB25-f-eef-ev@nrb) id AA06183; Thu, 10 Sep 92 17:43:04 +0100 Date: Thu, 10 Sep 1992 11:43+0200 From: Vincent Keunen Reply-To: nrb!keunen@relay.EU.net Subject: contents of clim-library as of 92/09/09 To: clim@nrbmi2.ia.nrb.be Message-Id: <19920910094335.9.KEUNEN@nrbmi1.ia.nrb.be> Here are the contents of the clim-library at cambridge.apple.com in /pub/clim as of 92/09/09: -rw-rw-rw- 1 ftp camb 537 Sep 9 15:54 ABSTRACTS.clim-library -rw-rw-rw- 1 ftp camb 1072 Aug 26 14:37 README.clim-library -rw-rw-rw- 1 ftp camb 15332 Aug 28 07:39 chooser.lisp -rw-rw-rw- 1 ftp camb 728071 Jun 3 19:09 clim-demo.sit.hqx drwxrwxrwx 2 ftp camb 512 Sep 9 12:43 ctv-menu -rw-rw-rw- 1 ftp camb 17086 Sep 9 15:12 multiple-menus.lisp Here are the contents of the file ABSTRACTS.clim-library (slightly reformatted): # 1. Please add one-line descriptions sorted alphabetically. # 2. Format is : file-name description date-contributed (in iso: YY/MM/DD) README explains what this directory is for 92/08/26 chooser.lisp This package contains a set of modal dialogs that return a value 92/08/28 clim-demo.sit.hqx demo version of CLIM 1.0 for Mac Common Lisp 2.0 (MCL) 92/06/03 ctv-menu CLIM Emulation of Symbolics Menu Functions (3 files) 92/09/09 multiple-menus.lisp a facility analogous to tv:MULTIPLE-MENU-CHOOSE on the Lisp Machine 92/09/09 At your service... vk -- Keunen Vincent Network Research Belgium R&D, Software Engineer Parc Industriel des Hauts-Sarts keunen@nrb.be 2e Avenue, 65 tel: +32 41 407282 B-4040 Herstal fax: +32 41 481170 BELGIUM   Received: from BBN.COM by LABS-N.BBN.COM id aa14338; 10 Sep 92 10:21 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa14909; 10 Sep 92 10:15 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1139498; 10 Sep 1992 10:15:43-0400 Date: Thu, 10 Sep 1992 10:16-0400 From: Scott McKay Subject: FQUERY To: jcma@reagan.ai.mit.edu, CLIM@BBN.COM In-Reply-To: <19920910110121.2.JCMA@OMEGA.AI.MIT.EDU> Message-ID: <19920910141634.7.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 10 Sep 1992 07:01 EDT From: "John C. Mallery" Does CLIM provide a facility accepting single characters from the user, along the lines of FQUERY in the Lisp Machine? No, but some simple form of it would probably be useful.   Received: from BBN.COM by LABS-N.BBN.COM id aa14374; 10 Sep 92 10:24 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa15019; 10 Sep 92 10:17 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1139500; 10 Sep 1992 10:17:44-0400 Date: Thu, 10 Sep 1992 10:18-0400 From: Scott McKay Subject: TYPEOUT-WINDOWS To: jcma@reagan.ai.mit.edu, clim@BBN.COM In-Reply-To: <19920910110703.3.JCMA@OMEGA.AI.MIT.EDU> Message-ID: <19920910141835.8.SWM@SUMMER.SCRC.Symbolics.COM> Date: Thu, 10 Sep 1992 07:07 EDT From: "John C. Mallery" Does CLIM have the concept of TYPEOUT-WINDOWS, or roll down windows for exceptional output? If so, how do I get it via define-application-frame? If not, how long do I have to wait for it? No. Only Genera provides anything like this. In CLIM 2.0, you can use NOTIFY-USER which pops up some kind of alert box. If you need something more interactive than an alert box, then you will have to create your own window (check out WITH-MENU) and use that. The likelihood of CLIM supporting Genera-like typeout windows is near 0.   Received: from BBN.COM by LABS-N.BBN.COM id aa14096; 10 Sep 92 10:01 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by BBN.COM id aa13976; 10 Sep 92 9:57 EDT Received: from SUMMER.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1139470; 10 Sep 1992 09:58:14-0400 Date: Thu, 10 Sep 1992 09:59-0400 From: Scott McKay Subject: postscript output with scaling and draw-text* in CLIM 1.1 To: gmw@cypress.mitre.org, lwolf@franz.com cc: CLIM@BBN.COM, cl-bugs@franz.com In-Reply-To: <9209092137.AA00612@cypress.mitre.org> Message-ID: <19920910135905.1.SWM@SUMMER.SCRC.Symbolics.COM> Date: Wed, 9 Sep 1992 17:37 EDT From: "Gregory M. Whittaker" Dear Lois, I'm re-sending my current version of a postscript grapher for class hierarchies. I have dropped the with-scaling macro and gone to the with-drawing-options equivalent since I need to explicitly pass the transform to the draw-text* function as well. Unfortunately the entire combination results in no improvement over the original. It appears that draw-text* generic-function ignores the passed in transform after checking that it is indeed a transform. Text is identical in size and placement no matter what I supply for a size. The tree links only match up with the textual node positions when the size = 1.0. I'm back to using CLIM 1.1 because with-output-to-postscript-stream is not yet supported in CLIM 2.0.alpha. I'm using the Franz version on a SPARCstation 2. Surely someone out there has done this before! What am I doing wrong? CLIM:DRAW-TEXT* is defined to obey transformations only insofar as the placement of the glyphs along a particular baseline, and then only when you suppy TOWARDS-X/Y. Furthermore, it is allowed to ignore size and rotation information. This restricted behavior is specified because most ports do not support general fonts (i.e., created from mathematical descriptions descibing the path that outlines each glyph). PostScript is the only port general enough to support this, but the necessary work has not been done to make it work properly. In the meanwhile, you should choose a font size (which you can specify in printer's points) that matches the desired scaling transformation. Here is the code: (defmethod print-scaled-subclass-tree ((name symbol) &optional (size 1.0)) (let* ((class (find-class name)) (filename (concatenate 'string (string (class-name class)) "-subclass-tree.ps"))) (with-open-file (file filename :direction :output :if-exists :supersede) (clim:with-output-to-postscript-stream (stream file :multi-page t) (let ((transform (clim:make-scaling-transformation size size))) (clim:with-drawing-options (stream :transformation transform) (clim:format-graph-from-root class #'(lambda (object s) (multiple-value-call #'clim:draw-text* s (string (class-name object)) (clim:stream-cursor-position* s) :align-y :center :transformation transform)) #'clos:class-direct-subclasses :stream stream)))) ))) ;;;(excl:run-shell-command (concatenate 'string "lpr " filename))))) ;;; if you actually want to print out the results, uncomment the above ;;; line and delete the preceding three close-parens. I've been simply ;;; using pageview to examine the results of the tests, and only print- ;;; hardcopy when necesary for documentation. -------- Cordially, Gregory M. Whittaker, The MITRE Corporation Center for Advanced Aviation System Development Internet: greg@mitre.org 7525 Colshire Drive Phone: (703) 883-5549 McLean Virginia 22102-3481 FAX: (703) 883-1226 Mail Stop: W215   Received: from BBN.COM by LABS-N.BBN.COM id aa15157; 10 Sep 92 11:27 EDT Received: from mcsun.EU.net by BBN.COM id aa18451; 10 Sep 92 11:20 EDT Received: from ub4b.buug.be by mcsun.EU.net with SMTP id AA05779 (5.65b/CWI-2.174); Thu, 10 Sep 1992 17:20:11 +0200 Received: from nrb.UUCP by ub4b.buug.be (5.65c/ub4b_02) id AA03177; Thu, 10 Sep 1992 17:20:17 +0200 Received: from nrbmi1.ia.nrb.be by scosysv.nrb.be with SMTP (5.59/NRB25-f-eef-ev@nrb) id AA06720; Thu, 10 Sep 92 22:45:32 +0100 Date: Thu, 10 Sep 1992 16:46+0200 From: Vincent Keunen Reply-To: nrb!keunen@relay.EU.net Subject: [oli@adler.ims.uni-stuttgart.de: contents of clim-library as of 92/09/09] To: clim@nrbmi2.ia.nrb.be Included-Msgs: <9209101114.AA24996@adler.ims.uni-stuttgart.de>, The message of 10 Sep 1992 13:14+0200 from oli@adler.ims.uni-stuttgart.de, The message of 10 Sep 1992 13:14+0200 from Oliver Christ Included-References: <19920910094335.9.KEUNEN@nrbmi1.ia.nrb.be>, The message of 10 Sep 1992 11:43+0200 from Vincent Keunen Message-Id: <19920910144606.8.KEUNEN@nrbmi1.ia.nrb.be> Return-path: Received: from scosysv.nrb.be by nrbmi1.ia.nrb.be via INTERNET with SMTP id 1002; 10 Sep 1992 14:44:43+0200 Received: from adler.ims.uni-stuttgart.de by scosysv.nrb.be with UUCP (5.59/NRB25-f-eef-ev@nrb) id AA06406; Thu, 10 Sep 92 20:27:13 +0100 Received: from adler.ims.uni-stuttgart.de by ub4b.buug.be (5.65c/ub4b_02) id AA25236; Thu, 10 Sep 1992 13:14:41 +0200 Received: from milan.ims.uni-stuttgart.de by adler.ims.uni-stuttgart.de (4.1/IMS-1.1) id AA24996; Thu, 10 Sep 92 13:14:21 +0200 Date: Thu, 10 Sep 92 13:14:21 +0200 From: Oliver Christ Message-Id: <9209101114.AA24996@adler.ims.uni-stuttgart.de> X-Message: The domain philosophie.uni-stuttgart.de is no longer valid. Please use the name IMS.UNI-STUTTGART.DE instead ! Received: by milan.ims.uni-stuttgart.de id AA21517; Thu, 10 Sep 92 13:14:22 +0200 To: keunen@nrb.be In-Reply-To: Vincent Keunen's message of Thu, 10 Sep 1992 11:43+0200 <19920910094335.9.KEUNEN@nrbmi1.ia.nrb.be> Subject: contents of clim-library as of 92/09/09 Reply-To: oli@ims.uni-stuttgart.de Dear Mr Keunen, thanks a lot for your work on the CLIM archive. I just received your message on the actual contents of the archive. Looking at the 'chooser.lisp' directory entry, I remember that it only runs with CLIM 2.0. I think that somewhere it should be said that some of the software (ctv-menus, for example) is running with 1.1 and that chooser requires 2.0. Perhaps by introducing subdirectories clim-1.1 and clim-2.0? At least in the README.clim-library there should be some information about the CLIM version the respective software requires. Thank you again for the maintenance of the archive! All the best, Oli ----------------------------------------------------- oli@ims.uni-stuttgart.de christ@is.informatik.uni-stuttgart.de Oliver Christ, Student of Computer Science at the University of Stuttgart, Germany ----------------------------------------------------- Following this suggestion of Oli, the library has been rearranged in two folders (clim-1 and clim-2). Please specify in the abstracts file which version of clim is required for your contribution. Thanks Vincent -- Keunen Vincent Network Research Belgium R&D, Software Engineer Parc Industriel des Hauts-Sarts keunen@nrb.be 2e Avenue, 65 tel: +32 41 407282 B-4040 Herstal fax: +32 41 481170 BELGIUM