perm filename CLWIND.MSG[COM,LSP]20 blob sn#846077 filedate 1987-09-21 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00315 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00046 00002	Introduction
C00049 00003	∂23-Sep-84  1610	RPG  	Introduction  
C00052 00004	∂02-Oct-84  1311	RPG  	Chairman 
C00053 00005	∂13-Oct-84  1440	RPG  	Chairman 
C00054 00006	∂25-Oct-84  0944	FILE-SERVER%WHITE.SWW.Symbolics@SCRC-RIVERSIDE.ARPA 	Chairman    
C00057 00007	∂27-Oct-84  2148	RPG  	Hello folks   
C00060 00008	∂28-Oct-84  1054	DDYER@USC-ISIB.ARPA 	Initial questions  
C00062 00009	∂29-Oct-84  0917	DDYER@USC-ISIB.ARPA 	Initial Answer
C00067 00010	∂29-Oct-84  1045	boetje@DEC-HUDSON 	some initial answers(?)   
C00081 00011	∂30-Oct-84  0711	dzg@cmu-cs-spice.arpa 	Terminology, etc.
C00087 00012	∂31-Oct-84  0723	STENGER%ti-csl.csnet@csnet-relay.arpa 	re: inital answers   
C00090 00013	∂02-Nov-84  2330	DDYER@USC-ISIB.ARPA 	Real devices (mainly)   
C00095 00014	∂03-Nov-84  0747	FAHLMAN@CMU-CS-C.ARPA 	Goals  
C00101 00015	∂04-Nov-84  1816	JW-PETERSON@UTAH-20.ARPA 	Some responses...  
C00104 00016	∂19-Nov-84  0019	DDYER@USC-ISIB.ARPA 	Proposals and questions 
C00108 00017	∂19-Nov-84  2035	WHOLEY@CMU-CS-C.ARPA 	Proposals and questions
C00116 00018	∂19-Nov-84  2220	FAHLMAN@CMU-CS-C.ARPA 	Proposals and questions    
C00120 00019	∂20-Nov-84  0736	boetje@DEC-HUDSON 	documenting implementations    
C00125 00020	∂20-Nov-84  0850	WHOLEY@CMU-CS-C.ARPA 	Virtual Displays  
C00133 00021	∂21-Nov-84  0724	FAHLMAN@CMU-CS-C.ARPA 	Virtual Displays 
C00139 00022	∂21-Nov-84  0914	DDYER@USC-ISIB.ARPA 	Implementation strategy 
C00143 00023	∂21-Nov-84  1048	KACZMAREK@USC-ISIF.ARPA 	Re: Virtual Displays
C00146 00024	∂21-Nov-84  1250	greek@DEC-HUDSON 	Terminal features and graphic functions   
C00149 00025	∂21-Nov-84  1434	@MIT-MC:MONTALVO@MIT-OZ 	Re: Virtual Displays
C00151 00026	∂26-Nov-84  0717	boetje@DEC-HUDSON 	graphics, virtual displays, and terminals
C00157 00027	∂08-Dec-84  1642	DDYER@USC-ISIB.ARPA 	Easy Questions
C00159 00028	∂08-Dec-84  1927	FAHLMAN@CMU-CS-C.ARPA 	Easy Questions   
C00163 00029	∂11-Dec-84  1207	DDYER@USC-ISIB.ARPA 	Re: Easy questions 
C00171 00030	∂12-Dec-84  2201	RAM@CMU-CS-C.ARPA 	Easy Questions  
C00177 00031	∂09-Jan-85  0110	DDYER@USC-ISIB.ARPA 	This space intentionally left blank    
C00179 00032	∂09-Jan-85  1001	KACZMAREK@USC-ISIF.ARPA 	Dire Dyer Prediction
C00182 00033	∂09-Jan-85  1117	DDYER@USC-ISIB.ARPA 	Re: This space intentionally left blank
C00184 00034	∂09-Jan-85  1322	boetje@DEC-HUDSON 	here's something to make up for the long silence... Jerry    
C00287 00035	∂09-Jan-85  1420	@MIT-MC:Henry%MIT-OZ@SCRC-RIVERSIDE 	Silence breaker   
C00290 00036	∂20-Mar-85  2048	DDYER@USC-ISIB.ARPA 	ANSI windows  
C00293 00037	∂20-Mar-85  2113	DDYER@USC-ISIB.ARPA 	ANSI windows (II)  
C00295 00038	∂29-Jul-85  1235	Fischer.pa@Xerox.ARPA 	RE: Clearing the screen and other such things. 
C00297 00039	∂29-Jul-85  2307	DDYER@USC-ISIB.ARPA 	Clearing the screen etc.
C00300 00040	∂30-Jul-85  0915	STENGER%ti-csl.csnet@csnet-relay.arpa 	Re: Clearing the screen etc.   
C00306 00041	∂17-Dec-85  2157	sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA 
C00307 00042	∂16-Dec-86  1905	RICHER@SUMEX-AIM.STANFORD.EDU 	CL-WINDOWS mailing list 
C00313 00043	∂16-Dec-86  2254	RICHER@SUMEX-AIM.STANFORD.EDU 	purpose of mailing list 
C00316 00044	∂17-Dec-86  0556	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	X server implementors? 
C00318 00045	∂17-Dec-86  2251	RICHER@SUMEX-AIM.STANFORD.EDU 	a bunch of messages on X/News & Commonlisp  
C00344 00046	∂26-Dec-86  1428	RICHER@SUMEX-AIM.STANFORD.EDU 	[Ralph R. Swick <swick@ATHENA.MIT.EDU>: User Interface Toolkit proposal]  
C00349 00047	∂26-Dec-86  1437	RICHER@SUMEX-AIM.STANFORD.EDU 	[kddlab!elis03@vc.sra.junet (Ken Seo): x-window in lisp]   
C00353 00048	∂26-Dec-86  1753	gabriel@vaxa.isi.edu 	cl-windows mailing list
C00354 00049	∂27-Dec-86  0958	ho@ucbarpa.Berkeley.EDU 	CL-windows
C00355 00050	∂27-Dec-86  1556	wanginst!ulowell!ulowell.ULOWELL.EDU!grinstei@harvard.HARVARD.EDU 	please add me to the list   
C00357 00051	∂28-Dec-86  0917	UEJIOWH%CADVAX.decnet@ge-crd.arpa 	cl-window mailing list   
C00358 00052	∂29-Dec-86  0634	PB80@A.CS.CMU.EDU 	Add to mailing list please
C00359 00053	∂29-Dec-86  0839	spe@cad.cs.cmu.edu 	Please add me  
C00360 00054	∂29-Dec-86  0946	@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU 	X in lisp  
C00363 00055	∂29-Dec-86  1129	RICHER@SUMEX-AIM.STANFORD.EDU 	Re: CL-WINDOWS mailing list  
C00365 00056	∂30-Dec-86  0719	pyramid!pyramid.UUCP!bein@hplabs.HP.COM 	mailing list request..  
C00366 00057	∂30-Dec-86  1028	rw@cad.cs.cmu.edu 	mailing list    
C00367 00058	∂30-Dec-86  1312	ekberg%home%ti-csl.csnet@RELAY.CS.NET 	CL-WINDOWS request   
C00369 00059	∂05-Jan-87  0153	yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET 	CL-WINDOWS   
C00371 00060	∂05-Jan-87  0328	mcvax!inria!devin@seismo.CSS.GOV 	mailing list    
C00373 00061	∂06-Jan-87  1246	RICHER@SUMEX-AIM.STANFORD.EDU 	discussion items   
C00383 00062	∂06-Jan-87  1437	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	toolkits
C00385 00063	∂07-Jan-87  1822	sdcrdcf!stephen@LOCUS.UCLA.EDU 	request 
C00386 00064	∂18-Jan-87  1653	MMcM@STONY-BROOK.SCRC.Symbolics.COM 	discussion items  
C00394 00065	∂18-Jan-87  1726	STEINBERG@RED.RUTGERS.EDU 	Access to Sun windows from CL    
C00396 00066	∂18-Jan-87  1753	dcmartin@ingres.berkeley.edu 	Re: Access to Sun windows from CL  
C00399 00067	∂20-Jan-87  1200	RAM@C.CS.CMU.EDU 	X interface standard  
C00406 00068	∂21-Jan-87  1328	RICHER@SUMEX-AIM.STANFORD.EDU 	X/Lisp from ailist 
C00410 00069	∂21-Jan-87  1419	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	random thoughts   
C00414 00070	∂21-Jan-87  1458	@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU 	X Version 11 protocol document 
C00416 00071	∂22-Jan-87  1431	RAM@C.CS.CMU.EDU 	random thoughts  
C00423 00072	∂22-Jan-87  1530	MMcM@STONY-BROOK.SCRC.Symbolics.COM 	random thoughts   
C00428 00073	∂23-Jan-87  1319	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	random thoughts   
C00433 00074	∂23-Jan-87  1423	@ZERMATT.LCS.MIT.EDU,@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU 	random thoughts
C00442 00075	∂25-Jan-87  0823	RAM@C.CS.CMU.EDU 	random thoughts  
C00450 00076	∂25-Jan-87  1355	MMcM@STONY-BROOK.SCRC.Symbolics.COM 	random thoughts   
C00454 00077	∂27-Jan-87  0346	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	random thoughts   
C00461 00078	∂27-Jan-87  0407	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	random thoughts   
C00465 00079	∂27-Jan-87  0450	Freburger.ULC@BCO-MULTICS.ARPA 	Mailing list 
C00466 00080	∂27-Jan-87  0920	Skef@think.com 	Window system psychomysticism
C00468 00081	∂27-Jan-87  1739	RICHER@SUMEX-AIM.STANFORD.EDU 	Lisp interfaces to X    
C00471 00082	∂28-Jan-87  0827	dcmartin@ingres.berkeley.edu 	Re: Lisp interfaces to X 
C00477 00083	∂28-Jan-87  0902	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	Re: Lisp interfaces to X    
C00479 00084	∂28-Jan-87  0953	dcmartin@ingres.berkeley.edu 	Re: Lisp interfaces to X 
C00483 00085	∂28-Jan-87  1242	RICHER@SUMEX-AIM.STANFORD.EDU 	Re: Lisp interfaces to X
C00489 00086	∂28-Jan-87  1246	primerd!doug@enx.prime.pdn 	Re: Lisp window systems standardization   
C00492 00087	∂28-Jan-87  1356	FAHLMAN@C.CS.CMU.EDU 	Lisp interfaces to X   
C00498 00088	∂28-Jan-87  1429	TAYLOR%PLU@ames-io.ARPA 	Window Systems Survey    
C00516 00089	∂28-Jan-87  1430	RICHER@SUMEX-AIM.STANFORD.EDU 	Re: Lisp interfaces to X
C00520 00090	∂29-Jan-87  1114	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	Me 'n X (ignore if you like)
C00523 00091	∂29-Jan-87  1114	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	foreign function interfaces 
C00525 00092	∂29-Jan-87  1114	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	X interface  
C00530 00093	∂29-Jan-87  1212	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	foreign function interfaces 
C00532 00094	∂30-Jan-87  1325	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: Lisp interfaces to X   
C00534 00095	∂31-Jan-87  0956	meltsner@athena.MIT.EDU 	Vendors and X + LISP
C00536 00096	∂04-Feb-87  1547	Ehrlich@YUKON.SCRC.Symbolics.COM 	Window Systems Survey     
C00541 00097	∂06-Feb-87  1311	BATALI@SPAR-20.ARPA 	please add me 
C00542 00098	∂11-Feb-87  1658	DON%atc.bendix.com@RELAY.CS.NET 	Bulletin board subscription
C00544 00099	∂13-Feb-87  0636	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	X atoms, a poll   
C00548 00100	∂13-Feb-87  0808	FAHLMAN@C.CS.CMU.EDU 	X atoms, a poll   
C00553 00101	∂13-Feb-87  0859	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	X atoms, a poll   
C00557 00102	∂13-Feb-87  0959	RAM@C.CS.CMU.EDU 	X atoms, a poll  
C00560 00103	∂13-Feb-87  1221	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	underscores  
C00562 00104	∂13-Feb-87  1228	FAHLMAN@C.CS.CMU.EDU 	X atoms, a poll   
C00567 00105	∂13-Feb-87  1249	Moon@STONY-BROOK.SCRC.Symbolics.COM 	X atoms, a poll   
C00569 00106	∂13-Feb-87  1345	RAM@C.CS.CMU.EDU 	underscores 
C00572 00107	∂19-Feb-87  1401	SPIRKOV%PLU@ames-io.ARPA 	please add me to the mailing list.
C00573 00108	∂20-Feb-87  1555	TAYLOR%PLU@ames-io.ARPA 	CW Standard Status  
C00575 00109	∂20-Feb-87  1944	FAHLMAN@C.CS.CMU.EDU 	CW Standard Status
C00579 00110	∂20-Feb-87  2354	edsel!bhopal!jonl@navajo.stanford.edu 	CW Standard Status   
C00583 00111	∂21-Feb-87  0833	CS.WERTH@R20.UTEXAS.EDU 	please add me to the mailing list  
C00584 00112	∂21-Feb-87  1523	RICHER@SUMEX-AIM.STANFORD.EDU 	CL-WINDOWS standards    
C00592 00113	∂22-Feb-87  0846	FAHLMAN@C.CS.CMU.EDU 	CL-WINDOWS standards   
C00601 00114	∂22-Feb-87  1741	FAHLMAN@C.CS.CMU.EDU 	CW Standard Status
C00604 00115	∂23-Feb-87  0333	mcvax!inria!inria.inria.fr!devin@seismo.CSS.GOV 	change me  
C00606 00116	∂23-Feb-87  0813	dcmartin@ingres.berkeley.edu 	X/Common LISP interface  
C00609 00117	∂23-Feb-87  1305	RICHER@SUMEX-AIM.STANFORD.EDU 	Re: X/Common LISP interface  
C00612 00118	∂23-Feb-87  1852	mqb@cive.ri.cmu.edu 	Re: X/Common LISP interface  
C00614 00119	∂24-Feb-87  1733	wanginst!ulowell!grinstei@harvard.harvard.edu 	Re:  X/Common LISP interface
C00616 00120	∂25-Feb-87  1637	rochester!tropix!dls@seismo.CSS.GOV 	Re:  CW Standard Status
C00624 00121	∂02-Mar-87  2124	WELCH%OSU-20@ohio-state.ARPA 	X in CL   
C00626 00122	∂09-Mar-87  1201	KASTNER@IBM.COM
C00627 00123	∂10-Mar-87  1215	pierce@rd1632 	Common Lisp Windows 
C00629 00124	∂10-Mar-87  1221	AKBARI@CS.COLUMBIA.EDU 	please add me   
C00631 00125	∂12-Mar-87  1405	dcmartin@ingres.Berkeley.EDU 	X/Common LISP interface  
C00633 00126	∂21-Mar-87  1733	RICHER@SUMEX-AIM.STANFORD.EDU 	[gabriel@vaxa.isi.edu (Gabriel Robins): Re: ISI grapher]   
C00642 00127	∂02-Apr-87  1533	MMcM@STONY-BROOK.SCRC.Symbolics.COM 	Window systems standardization   
C00657 00128	∂03-Apr-87  0603	@ZERMATT.LCS.MIT.EDU,@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU 	CLX proposal: cover message   
C00663 00129	∂03-Apr-87  0606	@ZERMATT.LCS.MIT.EDU,@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU 	CLX: a proposal
C00756 00130	∂03-Apr-87  0632	AVELLIS%IBACSATA.BITNET@forsythe.stanford.edu 	subscription 
C00758 00131	∂03-Apr-87  0839	dcmartin@ingres.berkeley.edu 	X/Common LISP library package (Beta release) 
C00761 00132	∂09-Apr-87  0703	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	revisions to CLX proposal   
C00766 00133	∂09-Apr-87  0745	RAM@C.CS.CMU.EDU 	revisions to CLX proposal  
C00768 00134	∂09-Apr-87  0803	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	plist revisions to CLX proposal  
C00770 00135	∂09-Apr-87  0843	FAHLMAN@C.CS.CMU.EDU 	plist revisions to CLX proposal  
C00773 00136	∂09-Apr-87  1135	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	Re: what package is the CLX stuff in? 
C00775 00137	∂09-Apr-87  1213	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	plist revisions to CLX proposal  
C00778 00138	∂09-Apr-87  1354	FAHLMAN@C.CS.CMU.EDU 	plist revisions to CLX proposal  
C00784 00139	∂09-Apr-87  1443	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	plist revisions to CLX proposal  
C00789 00140	∂09-Apr-87  1701	FAHLMAN@C.CS.CMU.EDU 	plist revisions to CLX proposal  
C00793 00141	∂09-Apr-87  2327	unido!gmdzi!jc@seismo.CSS.GOV 	plist revisions to CLX proposal   
C00797 00142	∂10-Apr-87  1055	DALY@IBM.COM 	passing structures to be destructively modified    
C00798 00143	∂10-Apr-87  1821	ibuki!weaver@labrea.stanford.edu 	Berkeley CL X windows 10 available for KCL    
C00800 00144	∂11-Apr-87  0826	RAM@C.CS.CMU.EDU 	plist revisions to CLX proposal 
C00804 00145	∂12-Apr-87  1011	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	latest X11 protocol document
C00806 00146	∂12-Apr-87  1308	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	plist revisions to CLX proposal  
C00814 00147	∂12-Apr-87  1313	Gumby%AI.AI.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	passing structures to be destructively modified
C00816 00148	∂13-Apr-87  0852	rochester!tropix!dls@seismo.CSS.GOV 	Re:  passing structures to be destructively modified 
C00819 00149	∂13-Apr-87  1305	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	Re:  passing structures to be destructively modified 
C00823 00150	∂13-Apr-87  1354	Oren%Tilde%ti-csl.csnet@RELAY.CS.NET 	CLX With-Display speed hack
C00828 00151	∂13-Apr-87  1427	carter%silicon@cs.utah.edu 	de-subscription  
C00829 00152	∂13-Apr-87  2109	janson@ATHENA.MIT.EDU 	common lisp X interface    
C00831 00153	∂14-Apr-87  0826	FAHLMAN@C.CS.CMU.EDU 	common lisp X interface
C00833 00154	∂14-Apr-87  0906	RAM@C.CS.CMU.EDU 	XCL comments
C00842 00155	∂14-Apr-87  1131	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	CLX With-Display speed hack 
C00852 00156	∂14-Apr-87  1351	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	XCL [sic] comments
C00864 00157	∂14-Apr-87  1410	burdorf@rand-unix.ARPA 	Re: plist revisions to CLX proposal 
C00865 00158	∂14-Apr-87  1611	RAM@C.CS.CMU.EDU 	XCL [sic] comments    
C00875 00159	∂14-Apr-87  2143	Moon@STONY-BROOK.SCRC.Symbolics.COM 	plist revisions to CLX proposal  
C00882 00160	∂15-Apr-87  0701	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	keyword args and consing    
C00885 00161	∂15-Apr-87  0734	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	XCL [sic] comments
C00890 00162	∂15-Apr-87  0809	larus@paris.Berkeley.EDU 	Re: keyword args and consing 
C00892 00163	∂15-Apr-87  0831	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	plist revisions to CLX proposal  
C00898 00164	∂15-Apr-87  0834	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	another try at CLX "lots of result values" 
C00908 00165	∂15-Apr-87  0901	FAHLMAN@C.CS.CMU.EDU 	keyword args and consing    
C00913 00166	∂15-Apr-87  1038	Moon@STONY-BROOK.SCRC.Symbolics.COM 	keyword args and consing    
C00918 00167	∂15-Apr-87  1116	RAM@C.CS.CMU.EDU 	keyword args and consing   
C00920 00168	∂15-Apr-87  1629	MMcM@YUKON.SCRC.Symbolics.COM 	XCL [sic] comments 
C00925 00169	∂15-Apr-87  1854	edsel!bhopal!jonl@navajo.stanford.edu 	keyword args and consing  
C00927 00170	∂15-Apr-87  1936	FAHLMAN@C.CS.CMU.EDU 	Consing &key args 
C00928 00171	∂16-Apr-87  0857	Oren%Tilde%ti-csl.csnet@RELAY.CS.NET 	Re: plist revisions to CLX proposal  
C00931 00172	∂16-Apr-87  0944	lowry%bizet.DEC@decwrl.DEC.COM 	X interface  
C00934 00173	∂16-Apr-87  1041	ibuki!weaver@labrea.stanford.edu 	Re:  keyword args and consing  
C00936 00174	∂17-Apr-87  0820	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	minor correction to CLX event-case    
C00938 00175	∂22-Apr-87  0551	RWS@ZERMATT.LCS.MIT.EDU 	WITH-GC semantics in CLX 
C00940 00176	∂22-Apr-87  2012	Moon@STONY-BROOK.SCRC.Symbolics.COM 	another try at CLX "lots of result values" 
C00949 00177	∂23-Apr-87  0953	Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET 	Re: another try at CLX "lots of result values"   
C00953 00178	∂23-Apr-87  1139	Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET 	Re: another try at CLX "lots of result values"   
C00957 00179	∂23-Apr-87  1513	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: another try at CLX "lots of result values"  
C00960 00180	∂23-Apr-87  1521	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	another try at CLX "lots of result values"   
C00967 00181	∂23-Apr-87  1547	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: another try at CLX "lots of result values"    
C00971 00182	∂23-Apr-87  2102	dcmartin@postgres 	Re: another try at CLX "lots of result values"     
C00974 00183	∂23-Apr-87  2139	Moon@STONY-BROOK.SCRC.Symbolics.COM 	another try at CLX "lots of result values" 
C00977 00184	∂24-Apr-87  0741	decvax!cvbnet!admin!tbardasz@decwrl.DEC.COM 	Mailing List   
C00979 00185	∂24-Apr-87  1024	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	CLX change summary  
C00985 00186	∂24-Apr-87  1232	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	CLX issues
C00993 00187	∂24-Apr-87  1701	moshell%ucf.csnet@RELAY.CS.NET
C00995 00188	∂27-Apr-87  1814	Moon@STONY-BROOK.SCRC.Symbolics.COM 	CLX issues   
C00999 00189	∂27-Apr-87  2033	ACUFF@SUMEX-AIM.STANFORD.EDU 	CLX Issues attribute interfaces   
C01001 00190	∂28-Apr-87  0858	Oren%Tilde%ti-csl.csnet@RELAY.CS.NET 	Re: CLX issues   
C01007 00191	∂28-Apr-87  1054	rfb@h.cs.cmu.edu 	CLX issues  
C01009 00192	∂29-Apr-87  1331	Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET 	Comments on CLX proposal
C01026 00193	∂30-Apr-87  0835	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: "GC"  
C01028 00194	∂30-Apr-87  1130	primerd!doug@enx.prime.pdn 	GC means Garbage Collection
C01030 00195	∂30-Apr-87  1231	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	[Masinter.pa@Xerox.COM: Re: CLX issues] 
C01033 00196	∂30-Apr-87  1422	harris%hplwhh@hplabs.HP.COM 	Re: GC means Garbage Collection     
C01035 00197	∂30-Apr-87  1606	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Comments on CLX proposal 
C01051 00198	∂01-May-87  0537	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: CLX issues 
C01053 00199	∂01-May-87  0628	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	attribute/geometry one more time   
C01059 00200	∂01-May-87  0747	DLW@ALDERAAN.SCRC.Symbolics.COM 	Comments on CLX proposal   
C01062 00201	∂01-May-87  1305	Moon@STONY-BROOK.SCRC.Symbolics.COM 	attribute/geometry one more time 
C01068 00202	∂01-May-87  1705	Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET 	Re: Comments on CLX proposal 
C01084 00203	∂01-May-87  2109	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Comments on CLX proposal
C01086 00204	∂02-May-87  0808	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	NIL in CLX
C01091 00205	∂04-May-87  1218	Oren%Tilde%ti-csl.csnet@RELAY.CS.NET 	Re: NIL in CLX   
C01094 00206	∂04-May-87  1819	Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET 	Re: NIL in CLX
C01096 00207	∂04-May-87  1820	Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET 	Re: attribute/geometry one more time   
C01099 00208	∂05-May-87  1223	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: Comments on CLX proposal  
C01109 00209	∂05-May-87  1255	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: NIL in CLX 
C01111 00210	∂06-May-87  0911	Oren%Tilde%ti-csl.csnet@RELAY.CS.NET 	Re: NIL in CLX   
C01114 00211	∂06-May-87  0916	Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET 	send-event: one function or three?
C01117 00212	∂06-May-87  1205	unido!gmdzi!LISPM-2.GMD!@lispm-1.gmd.hws 	Info about CLX and X   
C01120 00213	∂06-May-87  1329	dcmartin@postgres 	Re: Info about CLX and X  
C01123 00214	∂08-May-87  0611	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	change-pointer-control rational argument
C01125 00215	∂08-May-87  1258	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	setf'ing device mappings 
C01128 00216	∂08-May-87  1307	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: NIL in CLX 
C01130 00217	∂08-May-87  1327	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	timeout in event-case    
C01133 00218	∂09-May-87  0538	RAM@C.CS.CMU.EDU 	timeout in event-case 
C01135 00219	∂11-May-87  1651	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	CLX draft 3 revisions    
C01143 00220	∂11-May-87  1655	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	it really was version 3 ...   
C01144 00221	∂12-May-87  0506	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	CLX 3: part 1 of 2 [First attempt bounced with "message too large"]   
C01195 00222	∂12-May-87  0507	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	CLX 3: part 2 of 2  
C01251 00223	∂13-May-87  1626	Oren%Tilde%ti-csl.csnet@RELAY.CS.NET 	RE: CLX draft 3 revisions  
C01253 00224	∂13-May-87  1901	harris%hplwhh@hplabs.HP.COM 	Re: CLX draft 3 revisions 
C01257 00225	∂13-May-87  2117	Gregor.pa@Xerox.COM 	Re: CLX draft 3 revisions    
C01261 00226	∂14-May-87  0854	cperdue@Sun.COM 	Re: CLX draft 3 revisions   
C01263 00227	∂14-May-87  0900	harris%hplwhh@hplabs.HP.COM 	Re: CLX draft 3 revisions 
C01266 00228	∂14-May-87  1054	Gregor.pa@Xerox.COM 	Re: CLX draft 3 revisions    
C01270 00229	∂14-May-87  1031	CARNESE@SPAR-20.ARPA 	Re: CLX draft 3 revisions   
C01275 00230	∂14-May-87  1207	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	re: geometry accessors   
C01279 00231	∂14-May-87  1216	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: CLX draft 3 revisions  
C01282 00232	∂14-May-87  1354	harris%hplwhh@hplabs.HP.COM 	Re: geometry accessors    
C01286 00233	∂14-May-87  1359	CARNESE@SPAR-20.ARPA 	Re: CLX draft 3 revisions   
C01291 00234	∂14-May-87  1439	schultz@nrl-aic.ARPA 	Please remove...  
C01293 00235	∂18-May-87  0456	RWS@ZERMATT.LCS.MIT.EDU 	geometry accessors and etc.   
C01296 00236	∂18-May-87  1256	MMcM@STONY-BROOK.SCRC.Symbolics.COM 	Re: geometry accessors 
C01302 00237	∂21-May-87  1437	harris%hplwhh@hplabs.HP.COM 	Re: geometry accessors    
C01306 00238	∂22-May-87  1333	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: geometry accessors   
C01310 00239	∂25-May-87  1503	MMcM@STONY-BROOK.SCRC.Symbolics.COM 	Re: geometry accessors 
C01318 00240	∂25-May-87  1927	@Riverside.SCRC.Symbolics.COM,@DIAL|16177312506,@NUMBER-2.MMCM.Symbolics.COM:MMcM@NUMBER-2.MMCM.Symbolics.COM 	Re: geometry accessors  
C01338 00241	∂02-Jun-87  1238	@RELAY.CS.NET:Oren%Tilde@TI-CSL.CSNET 	font-char-info  
C01342 00242	∂03-Jun-87  0126	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: [LaMott Oren <Oren@Tilde.ti>:  font-char-info]   
C01344 00243	∂03-Jun-87  0729	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	font-char-info 
C01352 00244	∂03-Jun-87  1215	@RELAY.CS.NET:Oren%Tilde@TI-CSL.CSNET 	Re: font-char-info   
C01357 00245	∂03-Jun-87  1316	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: font-char-info  
C01363 00246	∂03-Jun-87  1550	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: font-char-info
C01369 00247	∂04-Jun-87  1530	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: font-char-info
C01375 00248	∂04-Jun-87  2132	RWK@YUKON.SCRC.Symbolics.COM 	Re: font-char-info  
C01379 00249	∂05-Jun-87  0527	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: font-char-info  
C01383 00250	∂05-Jun-87  0904	FAHLMAN@C.CS.CMU.EDU 	font-char-info    
C01387 00251	∂05-Jun-87  1142	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: font-char-info  
C01392 00252	∂05-Jun-87  1206	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	font-char-info 
C01397 00253	∂05-Jun-87  1946	RWK@YUKON.SCRC.Symbolics.COM 	Not about font-char-info 
C01404 00254	∂05-Jun-87  1947	RWK@YUKON.SCRC.Symbolics.COM 	Re: font-char-info  
C01409 00255	∂08-Jun-87  1637	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	wither characters   
C01412 00256	∂08-Jun-87  1724	RAM@C.CS.CMU.EDU 	wither characters
C01415 00257	∂09-Jun-87  1038	Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET 	Re: font-char-info 
C01419 00258	∂09-Jun-87  1358	@RELAY.CS.NET:Oren%Tilde@TI-CSL.CSNET 	Re: wither characters
C01424 00259	∂09-Jun-87  1705	RWK@YUKON.SCRC.Symbolics.COM 	wither modularity   
C01429 00260	∂09-Jun-87  1739	MMcM@STONY-BROOK.SCRC.Symbolics.COM 	Higher levels
C01431 00261	∂09-Jun-87  1803	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: wither characters  
C01435 00262	∂09-Jun-87  1810	RWK@YUKON.SCRC.Symbolics.COM 	Re: wither characters    
C01440 00263	∂09-Jun-87  2122	RAM@C.CS.CMU.EDU 	Higher levels    
C01443 00264	∂09-Jun-87  2304	Masinter.pa@Xerox.COM 	multi-byte characters and Japanese   
C01445 00265	∂10-Jun-87  1553	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	the character of characters   
C01448 00266	∂10-Jun-87  2125	MMcM@STONY-BROOK.SCRC.Symbolics.COM 	Higher levels
C01452 00267	∂10-Jun-87  2126	Moon@STONY-BROOK.SCRC.Symbolics.COM 	the character of characters 
C01457 00268	∂11-Jun-87  0808	sas@bfly-vax.bbn.com 	Re: the character of characters  
C01461 00269	∂12-Jun-87  1221	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	the character of characters   
C01471 00270	∂12-Jun-87  1516	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	font and character metrics    
C01477 00271	∂12-Jun-87  2047	RWK@YUKON.SCRC.Symbolics.COM 	multi-byte characters and Japanese 
C01480 00272	∂13-Jun-87  1434	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	more concrete font proposal   
C01496 00273	∂15-Jun-87  0912	@RELAY.CS.NET:Oren%Tilde@TI-CSL.CSNET 	Re: more concrete font proposal
C01501 00274	∂15-Jun-87  1435	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: more concrete font proposal  
C01505 00275	∂17-Jun-87  1300	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
C01511 00276	∂17-Jun-87  1310	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
C01514 00277	∂17-Jun-87  1341	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	re: pseudo fonts    
C01517 00278	∂18-Jun-87  0652	sas@bfly-vax.bbn.com 	Re: more concrete font proposal  
C01520 00279	∂18-Jun-87  0940	@RELAY.CS.NET:Oren%Tilde@TI-CSL.CSNET 	Re: more concrete font proposal
C01530 00280	∂19-Jun-87  0325	RWK@YUKON.SCRC.Symbolics.COM 	Re: more concrete font proposal    
C01560 00281	∂19-Jun-87  0339	RWK@YUKON.SCRC.Symbolics.COM 	Re: more concrete font proposal    
C01565 00282	∂24-Jun-87  0723	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
C01575 00283	∂24-Jun-87  0844	@EDDIE.MIT.EDU,@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU 	Re: more concrete font proposal
C01585 00284	∂24-Jun-87  1056	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	CLX beta changes    
C01590 00285	∂24-Jun-87  1236	RWK@YUKON.SCRC.Symbolics.COM 	Re: more concrete font proposal    
C01608 00286	∂24-Jun-87  1351	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
C01611 00287	∂25-Jun-87  0813	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
C01629 00288	∂25-Jun-87  1028	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
C01647 00289	∂25-Jun-87  1143	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
C01665 00290	∂25-Jun-87  1255	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
C01683 00291	∂25-Jun-87  1309	CS.WERTH@R20.UTEXAS.EDU 	Re: more concrete font proposal    
C01684 00292	∂25-Jun-87  1357	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: CLX beta changes   
C01691 00293	∂25-Jun-87  1438	CS.WERTH@R20.UTEXAS.EDU 	Re: more concrete font proposal    
C01692 00294	∂25-Jun-87  1505	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
C01710 00295	∂25-Jun-87  1438	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: CLX beta changes   
C01717 00296	∂28-Jun-87  1456	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: CLX beta changes
C01725 00297	∂29-Jun-87  0702	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: type confusion  
C01728 00298	∂29-Jun-87  1040	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	with-gcontext question   
C01733 00299	∂29-Jun-87  1122	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: CLX beta changes   
C01737 00300	∂29-Jun-87  1149	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: CLX beta changes
C01742 00301	∂29-Jun-87  1201	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: draw-image-glyph(s)  
C01746 00302	∂29-Jun-87  2112	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: draw-image-glyph(s)
C01750 00303	∂30-Jun-87  1023	@RELAY.CS.NET:Oren%Home@TI-CSL.CSNET 	Re: more concrete font proposal 
C01753 00304	∂30-Jun-87  1117	@RELAY.CS.NET:Oren%Home@TI-CSL.CSNET 	Re: more concrete font proposal 
C01755 00305	∂30-Jun-87  1431	RWS@ZERMATT.LCS.MIT.EDU 	Re: why sequences?  
C01758 00306	∂30-Jun-87  1450	RWS@ZERMATT.LCS.MIT.EDU 	Re: more concrete font proposal    
C01761 00307	∂16-Jul-87  0708	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	CLX  
C01764 00308	∂23-Jul-87  1410	@ZERMATT.LCS.MIT.EDU,@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU 	Some points on CLX. 
C01769 00309	∂23-Jul-87  1711	RAM@C.CS.CMU.EDU 	Some points on CLX.   
C01772 00310	∂24-Jul-87  1433	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Some points on CLX.    
C01777 00311	∂27-Jul-87  1810	skh@spice.cs.cmu.edu 	Event-case is ungood.  
C01780 00312	∂28-Jul-87  0738	RWS@ZERMATT.LCS.MIT.EDU 	Event-case is ungood.    
C01785 00313	∂28-Jul-87  1423	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: Event-case is ungood.   
C01788 00314	∂03-Aug-87  1410	RWS@ZERMATT.LCS.MIT.EDU 	[snyder%hplsny@hplabs.HP.COM: CLX "objects" proposal]  
C01798 00315	∂14-Aug-87  0642	@RELAY.CS.NET:AGHVAMI%ORION@TI-CSL.CSNET 	Common Lisp windows standards    
C01800 ENDMK
C⊗;
Introduction
Welcome to the Common Lisp Window Subgroup.
In order to mail to this group, send to the address:

		CL-Windows@su-ai.arpa

Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:

			   CLWIND.MSG[COM,LSP]

You can read this file or FTP it away without logging in to SAIL.

To communicate with the moderator, send to the address:

		CL-Windows-request@su-ai.arpa

Here is a list of the people who are currently on the mailing list:

Person			Affiliation	Net Address

Kent Pitman		MIT		kmp@mc
Dick Gabriel		Stanford/Lucid	rpg@sail
Carl Hewitt		MIT		hewitt-windows@mc
Don Allen		BBN		allen@bbnf
Dan Oldman		Data General	not established
Larry Stabile		Apollo		not established
Tom Kaczuarek		ISI		kaczuarek@isi
Dave Matthews		HP		matthews.hplabs@csnet-relay (I hope)
Dan Stenger		TI		stenger.ti-csl@csnet-relay
Gary Brown		DEC		gbrown@dec-marlboro
Joe Ginder		PERQ		Joseph.Ginder@cmu-cs-spice
Thomas Gruber		Univ. of Mass.	gruber.UMass-CS@csnet-relay

The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.

Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete. 

∂23-Sep-84  1610	RPG  	Introduction  
To:   cl-windows@SU-AI.ARPA 
Welcome to the Common Lisp Window Subgroup.
In order to mail to this group, send to the address:

		CL-Windows@su-ai.arpa

Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:

			   CLWIND.MSG[COM,LSP]

You can read this file or FTP it away without logging in to SAIL.

To communicate with the moderator, send to the address:

		CL-Windows-request@su-ai.arpa

Here is a list of the people who are currently on the mailing list:

Person			Affiliation	Net Address

Kent Pitman		MIT		kmp@mc
Dick Gabriel		Stanford/Lucid	rpg@sail
Carl Hewitt		MIT		hewitt-windows@mc
Don Allen		BBN		allen@bbnf
Dan Oldman		Data General	not established
Larry Stabile		Apollo		not established
Tom Kaczuarek		ISI		kaczuarek@isi
Dave Matthews		HP		matthews.hplabs@csnet-relay (I hope)
Dan Stenger		TI		stenger.ti-csl@csnet-relay
Gary Brown		DEC		gbrown@dec-marlboro
Joe Ginder		PERQ		Joseph.Ginder@cmu-cs-spice
Thomas Gruber		Univ. of Mass.	gruber.UMass-CS@csnet-relay

The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.

Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete. 

∂02-Oct-84  1311	RPG  	Chairman 
To:   cl-windows@SU-AI.ARPA 
Now that we've basically got most everyone who is interested on the mailing
list, let's pick a chairman. I suggest that people volunteer for chairman.

The duties are to keep the discussion going, to gather proposals and review
them, and to otherwise administer the needs of the mailing list. I will
retain the duties of maintaining the list itself and the archives, but
otherwise the chairman will be running the show. 

Any takers?
			-rpg-

∂13-Oct-84  1440	RPG  	Chairman 
To:   cl-windows@SU-AI.ARPA 

No one has been nominated as chairman of the Windows subgroup.  I
suggest Howard Cannon of Symbolics. If he is willing, and no one else
volunteers, he will become chairman. Please respond by October 24. At the
end of this month I want to see some ideas and proposals coming in on this
mailing list.

			-rpg-

∂25-Oct-84  0944	FILE-SERVER%WHITE.SWW.Symbolics@SCRC-RIVERSIDE.ARPA 	Chairman    
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 25 Oct 84  09:43:40 PDT
Received: from SWW-WHITE by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 94510; Tue 23-Oct-84 23:01:25-EDT
Date: Tue, 23 Oct 84 20:06 PDT
From: hic%SWW-WHITE@SCRC-RIVERSIDE.ARPA
Sender: FILE-SERVER%SWW-WHITE@SCRC-RIVERSIDE.ARPA
Subject: Chairman 
To: RPG@SU-AI.ARPA, cl-windows@SU-AI.ARPA
In-reply-to: The message of 13 Oct 84 14:40-PDT from Dick Gabriel <RPG at SU-AI>

    Received: from SCRC-STONY-BROOK by SWW-WHITE via CHAOS with CHAOS-MAIL id 47648; Sat 13-Oct-84 15:37:52-PDT
    Received: from MIT-MC by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 107864; Sat 13-Oct-84 18:32:38-EDT
    Date: 13 Oct 84  1440 PDT
    From: Dick Gabriel <RPG@SU-AI.ARPA>
    Subject: Chairman 
    To:   cl-windows@SU-AI.ARPA 


    No one has been nominated as chairman of the Windows subgroup.  I
    suggest Howard Cannon of Symbolics. If he is willing, and no one else
    volunteers, he will become chairman. Please respond by October 24. At the
    end of this month I want to see some ideas and proposals coming in on this
    mailing list.

			    -rpg-

Ah, I see I received this message.  I was worried that this mail wasn't
getting through, or was stuck at MC, or...

In any case, I respectfully decline the offer, not because I don't want
to do it but because of extensive traveling I don't feel I could be
reliable enough.  I do hope to participate actively, though.

I suggest that DDYER would do a fine job as chairman.

--Howard

∂27-Oct-84  2148	RPG  	Hello folks   
To:   cl-windows@SU-AI.ARPA 

We now have a chairman of the windows subgroup:  Dave Dyer of Symbolics. I
think he will make an excellent chairman.  For your information I am
including the current members of the mailing list.

I will now let Dave Dyer take over responsibility for the discussion.

David Matthews		HP		"hpfclp!windows%hplabs"@csnet-relay,
Jerry Boetje		DEC		Boetje@dec-hudson
John Foderaro		Berkeley	jkf@ucbmike.arpa
Steve Muchnick		SUN		"ucbvax!sun!muchnick"@berkeley
Howard Cannon		Symbolics 	"hic%scrc"@mc
Dave Dyer		Symbolics	ddyer@isib
Skef Wholey		CMU		Wholey@cmuc
Richard Zippel		MIT		rz@mc
Ron MacLachlan		CMU		RAM@cmu-cs-c
John Peterson		Univ of Utah	jw-peterson@utah-20
Kent Pitman		MIT		kmp@mc
Dick Gabriel		Stanford/Lucid	rpg@sail
Carl Hewitt		MIT		hewitt-windows@mc
Don Allen		BBN		allen@bbnf
Dan Oldman		Data General	not established
Larry Stabile		Apollo		not established
Tom Kaczmarek		ISI		kaczmarek@isi
Dan Stenger		TI		stenger.ti-csl@csnet-relay
Gary Brown		DEC		brown@dec-hudson
Joe Ginder		PERQ		Joseph.Ginder@cmu-cs-spice
Thomas Gruber		Univ. of Mass.	gruber.UMass-CS@csnet-relay
Ron Fischer		Rutgers		fischer@rutgers
Dario Giuse		CMU		dzg@cmu-cs-spice
Neal Feinberg		Symbolics	feinberg@scrc-stony-brook

∂28-Oct-84  1054	DDYER@USC-ISIB.ARPA 	Initial questions  
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 28 Oct 84  10:53:57 PST
Date: 28 Oct 1984 10:52:38 PST
Subject: Initial questions
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA


Ok, since I have no idea what I'm supposed to do, I'll
just do what comes naturally.   What is the scope of
this discussion?  These questions come to mind:


What kinds of window hardware are we talking about?  Plain
glass ttys?  Bitmapped?  Vector?  Color?

What implementation technology?  Particularly, will we use
whatever the CL standard for objects becomes, or structures.

Fonts?  Text formatting?   What is the boundary between 
this mailing list and what "graphics" will discuss.

What about pointing devices?
-------

∂29-Oct-84  0917	DDYER@USC-ISIB.ARPA 	Initial Answer
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 29 Oct 84  09:17:19 PST
Date: 29 Oct 1984 09:12:53 PST
Subject: Initial Answer
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA

[ Editors Note:  Since this reply came to me rather than the mailing list,
  I am reminded of the perpetual question;  "To Digest or not to Digest"
  For now, I will package any replies that come directly to me, and send
  them to the mailing list from time to time.   Messages sent to 
  cl-windows@su-ai will continue to be redistributed immediately.
						DDyer@isib]

Return-Path: <KACZMAREK@USC-ISIF.ARPA>
Date: 29 Oct 1984 07:47:00 PST
Subject: Re: Initial questions
From: Tom Kaczmarek <KACZMAREK@USC-ISIF.ARPA>

Regarding interaction with the graphics group, I think we ought to try to 
build on top of what they supply.  I suspect that there is enough cross-
membership to insure that we have sufficient influence.  (I haven't compared
the mailing lists so I could be wrong about that.)

[ddyer: I tend to look at it the other way; Graphics is an additional
 behavior of windows, and graphics capabilities will be built out of
 whatever we supply.]

As far as display hardware goes there seems to be two interesting classes--
"graphics" and glass ttys.  Color is an orthogonal issue, isn't it?
Number of bit planes for black and white graphics falls in this same
category.  Both graphic devices and ttys come in black and white (with
intensity levels) or color.  Graceful degradation seems to be the
appropriate way to handle these issues.  I believe the graphics people
having been looking at this issue for some time and have solutions for this
problem.  

I would guess that if the graphics group does its job well, vector versus
bitmapped graphics should not be an issue.  The resolution of the graphics
may be an issue however.  Low resolution graphics devices seem a lot like
glass ttys as far as windows go.  Storage vector graphics hardware (ala
old Tektronix stuff) does not lend itself to the kind of interaction one
expects from a window system so I think we can eliminate it.  I believe the
graphics group also should make pointing devices less of a problem since
graphics standards have abstracted actions like "picking."  I believe that
complex mouse buttoning will still be something of a problem.

Structures versus objects seems to be a difficult decision.  Perhaps having
to wait for a object standard will be the best argument for structures.
Conceptually, objects are nice for the kind of interactions that occur in
the window world.  Is efficiency an issue here?  Object-oriented
implementations seems to rely on interpretation rather than compilation.
Is that because nobody has done it differently or is it too hard?  Or
impossible?  Or am I wrong about that?

[ddyer: flavors are compiled]
Tom
-------
-------

∂29-Oct-84  1045	boetje@DEC-HUDSON 	some initial answers(?)   
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 Oct 84  10:43:09 PST
Date: Mon, 29 Oct 84 13:39:39 EST
From: boetje@DEC-HUDSON
Subject: some initial answers(?)
To: cl-windows@su-ai.arpa

Ok, it's Monday morning and I'm ready to take on windows. This note is in 
direct reply to Dave Dyer's set of questions over the weekend. 

Let's take the terminology question first. I have a strong feeling that we 
need to get this handled before much else can happen. One of the major 
difficulties in this area is that there seem to be two different views of what 
the term "window" refers to. Most everyone working on bitmapped screens these 
days calls the funny rectangular areas (with borders and labels, in which you 
can put text or draw lines) windows. The graphics community uses "window" in a 
very different way. A window is really a way to specify a set of coordinate 
transformations and a set of bounding coordinates for clipping purposes. You 
can't ever see a graphics window. It takes a viewport to make that happen. 
Viewports are potentially viewable objects. But of course in that graphics 
world, there isn't a firm concept of borders and labels.

I will put forth the following radical suggestion: the graphics folks were 
here first, so their terminology should take precedence. Windows and viewports 
are strictly defined in the world of real graphics. A window is a set of 
limiting coordinates (x-y min and max values) in some arbitrary system
(usually the coordinate system of the data values to be plotted). This defines 
the aspect ratio of the eventual display of data. A viewport is another set of 
limiting coordinates which are used to map the data plotted in coordinates of 
the window to a displayable rectangle (this provides for clipping, 
magnification, and transformation to the physical device).So we won't do 
windows (sorry about the marketing slogan). We need to call those funny 
rectangles on the screen something else.

Before I unveil my terms, let me introduce a concept into this arena. In both 
the graphics world and whatever-we-call-the-current-thing world, there is the 
idea of a displayable object. In the graphics world, viewports can be 
displayable objects (when they map things from NDC space for example). They 
can also be previously created "pictures" which can be used to make composite 
images (for example, the symbol for a NAND gate in a CAD system). The common 
term for this object is "segment". Segments can be replicated and scaled ad 
nauseum to make a larger displayable object. The graphics world thus has a 
model of composition by using displayable objects as well as basic line 
drawing primitives.

In the bitmapped world, "windows"  are considered displayable objects. In the
case of Symbolics, they also  provide the idea of decomposition of their window
into "panes" (which can be  treated as individual windows for many purposes).
Another way of looking at  their system is that they treat their "window" as a
displayable object which can be composed of other windows. Their composition 
process also involves a particular contraint system on the interaction between 
the parts of a composed displayable object (resize one and the others adjust).

With all that said, I now introduce my own terms (liberally borrowed from 
unnamed sources):

1. Virtual Display. This is what most folks think of as a "window" or perhaps
a bitmap (depending on whether it's visible or not). You may see it (touch it
and taste it if it's late enough at night) on the screen. It's a  rectangular
area which may be made to appear on a physical display (hence the term virtual
display) which  can have a border, a label, etc. Primitive operations can put
information into  the display (like writing characters or drawing lines). If
they are not currently visible on the physical display, their current state is
kept and  modified by primitive operations. 

They can also be  composed of other virtual displays with appropriate
constraints at the whim of the implemectation. It may or may not be on the
physical display and it may or  may not be hidden obscured by other visible
displays). It can function as an I/O device for CL streams. And if you're into
the graphics side of the world, viewports map directly into the non-border
portion of virtual displays.  

2. Windows and viewports retain (and will only be used for describing) their 
traditional meanings in the world of graphics (which among other things means 
that windows and viewports operate in coordinate systems other than that of 
the physical display device).

3. Displayable object. Well, I gave the sense of it above. If we want to 
strictly define it for CL, then we'll need to do some work on it. I'm inclined 
to leave it alone for now and just use it by way of introducing concepts of 
composition. We'd need to be very closely tied to the graphics folks if we 
want to define it in the language.

Ok, enough on terms. Hardware... hmm... Curiously, the most limiting hardware 
is the vector drawing equipment, because it's hard to change once you've put 
it on the screen. My thought is that we should at least define operations that 
can be done on a cell-oriented screen. We can define optional capabilities for 
displays, but that gets us into the serious business of specifying how the 
user program determines the capabilities that can be used on the runtime 
device and what the error mechanism is for operations that can't be supported 
on the current device. The GKS graphics folks have done this and the inquiry 
functions outnumber the primitive operations.

On the software implementation, we should go for the least disruptive and 
commonly implemented features (GCLISP has some nice display stuff on a small 
machine). I think this means structures, not objects. We might want to define 
an optional object interface to the displays, but I think we need the simple 
level as well. Also, I don't want to wait around for the religious wars over 
objects. We'll have enough of our own...

Fonts, et al. Ok, we need some optional ways to specify font information and 
it's not clear that font bits are the best way to go. VAX LISP would probably 
have a difficult time handling font information in strings (efficient strings 
for us are one byte per character). Font information should be an ignoreable 
parameter (VT200's don't do well when commanded to go into Times Roman). 
Having a function that computes the actual screen size of a string in a 
specified font is a must.

Text formatting. We need text primitives to write, erase and insert 
characters. But I'm not anxious to get into the business of putting Scribe 
into CL. But there should be enough functionality for the cottage industries 
to write a formatting system on top of the CL primitives.

Boundary between this group and graphics. Ok, I've got a foot in both, so I'll 
jump in. We should stick to the ideas of virtual displays and composition of 
virtual displays. They should always operate in the coordinate system of the 
device. The graphics world should get windows, viewports and segments and 
operate in non-device coordinates. Our major interface then becomes a mapping 
of viewport to virtual display with the graphics side worrying about the 
scaling and clipping into the device (virtual display) coordinates.

Last topic for now... pointing devices. hmmm. They're needed for two purposes,
at least. One is to do operations on entire virtual displays (like popping
them to the surface). They other is to indicate a point or segment within a
virtual display. These operations can be handled with mouses and tablets and
can be simulated with cursor keys. We have to be careful not to get into the
business of defining a user interface to CL (pointing at a label brings a
display to the surface). But it would be nice to have some simple functions to
let users roll their own. 

Indicating a point or segment is a bit more interesting and gets us involved 
with the graphics group. Points within a virtual display need to be returned 
in some coordinate system. Most bitmap systems give back a point in raster 
coordinates. That's probably limiting. The graphics world likes them returned 
in the original coordinates used to draw the picture. And picking graphics 
segments has a close counterpart in defining/selecting a sensitive region.
Topic for next time.

Oh yes, color. Pick and stick to one of the international standards. There's 
RGB (red, green, blue) and HLS (hue, lightness and saturation). Any of you 
VideoText folks probably have yet another way. I have no real preference (just 
a minor leaning to HLS) but I haven't figured out if I should grind an ax on 
this or not. Issue deferred...

	Jerry

∂30-Oct-84  0711	dzg@cmu-cs-spice.arpa 	Terminology, etc.
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 30 Oct 84  07:10:20 PST
Date: Tuesday 30 October 1984 09:33:00am-EST
From: dzg@CMU-CS-SPICE.ARPA
To: cl-windows@su-ai.arpa
Subject: Terminology, etc.
Message-ID: <0.0.dzg>

I mostly agree with Jerry Boetje. Let's use "window" for a set of bounding
coordinates; the confusion in the bitmap world is hopeless anyway. As an
example, on the Perq a 'viewport' is a rectangular portion of a display, and
a 'window' is essentially a viewport embellished with borders and a
'title'; on the Symbolics, a 'window' is essentially a viewport that may or
may not have borders and a 'label' (title).

I have a little problem with the term "segment", just because it is so
overloaded. I would try and suggest "symbol", a' la Newman & Sproull, just
because it's nice to talk about a symbol and a symbol instance. I realize,
though, that the word "symbol" is also overloaded...
One related question is transformations: can you only specify a
transformation (rotation, scale, offset) for symbols|segments, or can you
transform any graphical object in place?  Do you want to be able to say
"This is an arc of a circle, center and radius such and such, and by the
way it is scaled up 3.2 and rotated pi radians"?  Or do you always have to
wrap the arc in a symbol|segment to achieve the same effect? 

I also agree that we should use the universally available Structures for
the software implementation, given that no universally accepted (or
implemented!) notion of object seems to be around the corner. The BIG
problem, here, is that if you are not very careful your structures turn out
to be a "display list" that the system maintains, and so you have to
duplicate them all to put the interesting stuff you want to deal with. One
of the ideas I am trying to work on is to SHARE your data structures with
the system, so that you can have all the nice slots you want in there that
are not graphical at all, while the system can store all its internal cute
optimization things in it. This is unfortunately difficult to do with
structures a' la DefStruct, since the slots are defined once and for all.
An object system would be much nicer, since the system can define all its
nasty things and you never need to know about them.

Fonts: the "best approximation" paradigm should apply. My approach would be
to have a very generic font definition (family name, face, size, rotation)
which would be mapped into whatever the system provides. Font names are
totally hopeless (What's a CPT10? Is it 10 points or 10 pixels? Or is it
the 10th font in the file CPT? And what's a CPT anyway?), so I think one
would end up having a device-dependent mapping between an "abstract font"
and whatever the system provides. The mapping would be very dull on the
VT200, for instance, but one should use an abstract specification
nonetheless.

I very strongly oppose any notion of text formatting. Only the very minimal
level of support, including obviously the ability to get device-dependent
font information (IN WORLD COORDINATES, not in device coordinates!), should
be present. More complex text formatting is A) highly dependent on personal
taste, and B) extremely difficult to do right for sophisticated
applications. I certainly don't want a window system at this level to have
to deal with kerning and italic corrections.

  - Dario -

∂31-Oct-84  0723	STENGER%ti-csl.csnet@csnet-relay.arpa 	re: inital answers   
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 31 Oct 84  07:23:51 PST
Received: from ti-csl by csnet-relay.csnet id ad00735; 31 Oct 84 10:18 EST
Date: 31 Oct 1984 0625-CST
From: Dan Stenger <STENGER%ti-csl.csnet@csnet-relay.arpa>
Subject: re: inital answers
To: cl-windows%su-ai.arpa@csnet-relay.arpa
Received: from csl60 by ti-csl; Wed, 31 Oct 84 09:13 CST

On terminology:
I agree with Jerry Boetje's proposal on the terminology that we should use.
We should settle on something so that we all understand each other.  The
main problem I see with this is that the terms "windows" and "panes" are
well established in the Lisp community and we may just cause confusion.

On bounds of this group:
I am also in the graphics group.  My view is that we should limit the
efforts of the windows group to virtual displays and other things that
need to work in device coordinates.  The graphics group should handle
what is shown in the virtual displays.

On the software implementation:
I agree that structures are the way to go.  Some implementations may not
want the object oriented programming system but may want windows.  Also
the wait may just put us too far behind.

On display hardware:
It would be nice if what we come up with is compatible with vector refresh
and storage tube hardware but I do not think that we should concern ourselves
with it.  The types of hardware which we do need to address are black/white
and color bitmaped terminals, and text only terminals.

In general I think we should try to design something that is concise, simple,
but very general.  It should be implementable on small machines but be easily
extended (not restrictive) for larger machines.

		Dan Stenger
-------

∂02-Nov-84  2330	DDYER@USC-ISIB.ARPA 	Real devices (mainly)   
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 2 Nov 84  23:30:41 PST
Date:  2 Nov 1984 23:26:10 PST
Subject: Real devices (mainly)
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA


There seems to be consensus that vector displays are outside
our domain.  If there are no devotees of vector displays out
out there, I'll consider it official.

I liked "virtual display", but one term isn't a complete glossary.


  Several messages have cast a word in favor of supporting ordinary
terminals; but I wonder just how much one can do, especially if
"virtual display" is taken to imply "multiple virtual displays".
In practice, won't terminals be restricted to one or two virtual
displays, all the same width as the screen?   I've done quite
a bit of display hacking on ordinary terminals, and found anything
fancier to be aesthtically awful, even if technically possible.

  There simply isn't enough real estate to distinguish more than
a few windows, aren't display capabilities to provide margins
and borders, and the devices themselves don't operate fast or
reliably enough to allow manipulation of arbitrary blocks of
characters in a way that is acceptable to users.   Shouldn't we
take this ugly bit of reality into account? 

  I'm not necessarily proposing we punt terminals entirely, but
we should at least consider defining a limited set of primitives 
for terminals sufficient for input editing and (maybe) emacs style
editing.




  I also have doubts about several mentions of "device coordinates"
as the appropriate substrate for virtual displays.   One at least
needs to be able to speak of either "characters" or "pixels", to
accommodate ordinary terminals and bitmaps, but once pixels are
introduced, a whole nest of other problems surface; such as
aspect ratio, variable width and height of fonts, and the variable
size of pixels on different displays.  

  For a particular display, one could of course tweak things into
the right device coordinates to give the desired effect, but we
are speaking "portable" here, so need to at least address the question
of transmitting the author's intent to foreign systems.   

  Just to finish on a concrete point, consider Symbolic's color
displays, where the "same size" characters (in device coordinates)
border on unreadable compared to the same text on the B&W screen.   
Also, consider that a single pixel height horizontal line on a
noninterlaced screen is fine, but on an interlaced screen it is
probably unacceptable due to excess flicker.

  No program that operates in "device" coordinates can ignore facts
of life such as these.  We need to strike a balance between providing 
access to the raw facts, and hoping programs cope with all the possible
implications, and attempting to abstract intent into our specs and letting
the implementation cope with the ramifications.



-------

∂03-Nov-84  0747	FAHLMAN@CMU-CS-C.ARPA 	Goals  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Nov 84  07:47:49 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 3 Nov 84 10:47:55-EST
Date: Sat, 3 Nov 1984  10:47 EST
Message-ID: <FAHLMAN.12060631562.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   cl-windows@SU-AI.ARPA
Subject: Goals


In my opinion, the window group is really in the business of developing
one or more optional semi-standards.  What I mean by that is that I
don't think that the Common Lisp specification should require any
particular sort of display or window system in order for something to be
called Common Lisp.  Display technology is moving pretty fast, and we
wouldn't want to rule out a Common Lisp in a wristwatch or a Common Lisp
running on a brute-force machine with no display of its own.
Furthermore, each machine running Common Lisp will have a few
specialized high-performance tricks available that users will want to
access for the most demanding applications: one machine might have a
hardware font and vector generator, another might have an incredibly
smart rasterop, and so on.  

But what we can and should do is to develop one or more clean interfaces
for doing some collection of popular things on certain popular families
of display technologies.  Implementors will be encouraged to provide
these standard interfaces on their machines wherever they make sense,
and people developing display-oriented code will then have the option of
writing it using the portable interface, for easy portability across a
class of machines, or of writing it to make the best possible use of a
given machine using whatever tense non-standard mechanisms may be
available.

It seems to me that three families of display device are going to be
important in the near future: 24x80 character terminals with varying
degrees of crude graphics support, high-resolution (at least 600 x
800) monochrome bit-mapped displays with some sort of pointing device,
and high-res bit-mapped displays with color.  Rather than ruin the
interface we develop for bit-mapped displays by trying too hard to make
it all work on ASCII terminals, I propose that we define three separate
interfaces:

Level 1: Can be implemented on the majority of ASCII termianls.
Level 2: Assumes bit-mapped graphics, reasonable resolution, and a
         pointer.
Level 3: Same as above, but with color.

Software developers can target their software to raw common Lisp or to
any of these levels, depending on the capability they need and the
market they wish to address, or they can go native on a single
machine/system.  Maybe levels 2 and 3 can be collapsed into one.
This is set up as a sort of hierarchy, since I am assuming that any
machine providing level 2 support will also provide level 1 support and
so on.  But the situation is really not hierarchical -- one might
imagine vector displays as wanting a different kind of interface
altogether.

The most important need right now is to come up with something for level
2, since the vast majority of Common Lisp implementations (not weighted
by number of users) is on machines of this class.

-- Scott

∂04-Nov-84  1816	JW-PETERSON@UTAH-20.ARPA 	Some responses...  
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 4 Nov 84  18:16:37 PST
Date: Sun 4 Nov 84 19:16:54-MST
From: John W. Peterson <JW-Peterson@UTAH-20.ARPA>
Subject: Some responses...
To: cl-windows@SU-AI.ARPA


VT100's.  The 24x80 terminal may not be dead, but is quickly dying.  A
reasonably intelligent bitmapped terminal with a mouse runs around $2K, and
will shortly drop to the VT100 [& clones] price range - this seems like a
good "lowest common denominator" level.

Fonts.  The discussion of fonts and formatting brings up an interesting
analogy: When the world migrated from TTY's to CRT's, many programs broke
(or just "looked ugly") because they couldn't deal with lower case input or
output.  The same sort of thing appears to be happening again, only this
time things are breaking (or just not looking right) because they can't deal
with multiple fonts - particularly ones with proportional spacing.  Having
at least some formatting facilities inherent in the window system (e.g., tab
stops that work correctly with proportional spaced fonts) would make the
programmer's life noticeably easier.

Units of measure.  Is anything wrong with measuring things in Pixels?  It
makes life much, much simpler (both conceptually and pragmatically) to
define screen coordinates in pixel units.  There is nothing very "display
specific" about pixel units of measure, particularly when you consider
"Virtual Displays" are usually of various sizes on the same screen.  As long
as we use digital computers, screens will be measured in discrete units -
both graphics and window packages might as well behave the same way.
(An interesting discussion of this is presented in "A Language for Bitmap
Manipulation" by Guibas & Stolfi in the July '82 Transactions on Graphics.)
-------

∂19-Nov-84  0019	DDYER@USC-ISIB.ARPA 	Proposals and questions 
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 19 Nov 84  00:19:31 PST
Date: 19 Nov 1984 00:18:26 PST
Subject: Proposals and questions
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA

I like Scott Fahlman's notion of defining two sets
of protocols, one for simple terminals and the other
for rasters.  Presumably the terminal protocol would
use characters and lines as its units, while the
raster protocol would use either characters or pixels.

Are there any existing standards we might use as a
starting point?   I'm hoping for something more abstract
than the lisp machine window system manual!  The first 
proposal circulated is likely to become the de facto standard.


In accordance with the above, I suggest the following
framework:

Each virtual display divides the world into three parts,
INSIDE, BORDERS, and OUTSIDE.  

INSIDE a virtual display, two protocol sets are defined,
a "character oriented set" and a "raster oriented set".
The character oriented set deals with size, positioning,
font and other characteristics of characters.  The
raster oriented protocol also addresses characters,
but also any other graphics and display primitives.
It is permitted for an implementation to implement only
the character oriented protocol.


OUTSIDE a virtual display, protocols deal with its
size, position, visibility and so on with respect to
its superior.


I'm not sure how to encapsulate the notion of BORDERS
succinctly.  The best I can think of at the moment
is that borders are a specialization of the more general
notion of "clipping region"; that a window is defined
by a clipped region within its superior, and may
in turn define an inferior clipping region.



		 ANOTHER NEW QUESTION

I'm personally a little worried by the consensus to implement
virtual displays using structures.  By way of bringing my
concerns to the surface, I'll pose a question:

 How much user extensibility to window system behavior will be
expected/permitted, and how will the data structure and procedural
hooks for that extensibility be supported?


 I think it is important that extensibility be a goal, and that
"extended" windows (oops! virtual displays!) be as well integrated
and as efficiently implemented as the system's supplied windows.
I know how to do this in an object oriented window system.  Tell me
how you'll do it in a structure based system.


-------

∂19-Nov-84  2035	WHOLEY@CMU-CS-C.ARPA 	Proposals and questions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Nov 84  20:34:25 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Mon 19 Nov 84 23:33:14-EST
Date: Mon, 19 Nov 1984  23:33 EST
Message-ID: <WHOLEY.12064965182.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   Cl-Windows@SU-AI.ARPA
CC:   Dave Dyer <DDYER@USC-ISIB.ARPA>
Subject: Proposals and questions
In-reply-to: Msg of 19 Nov 1984  03:18-EST from Dave Dyer <DDYER at USC-ISIB.ARPA>

Here are some of my thoughts on "virtual displays," both their specification
and their implementation (via structures).

There are (currently) about three coarse levels in virtual display fanciness
that a virtual display system should try to support:
	Glass TTY with at least an addressable cursor (e.g. ADM-3A)
	"Smart" CRT terminal (e.g. Concept-100, VT-200)
	Bitmapped displays

I believe that any virtual display should support all operations (we have yet
to decide on the operations, but my point is that something like DELETE-CHAR
can be performed on any of the above, albeit with different performance).  Non-
bitmapped terminals could be treated as having 24 by 80 (or whatever) pixels,
and a 1 by 1 font.

The redisplay module of a text editor will want to use different screen update
algorithms depending on the sort of virtual display it is writing to.  Thus, a
virtual display should be able to provide information about the relative
efficiency of its operations.  At the very least, a programmer should be able
to find out in which of the three categories listed above a virtual display
belongs.  The editor's redisplay algorithm can then be tuned to the particular
output device.  The casual programmer could of course opt to ignore this extra
information.  The virtual display machinery could do all kinds of redisplay
optimization itself, but I believe that certain decisions are best made in the
client program.

Thus, the different "protocols" that Scott suggests would be kept at a level
below the virtual display operations, but programmers that wanted to could
easily figure out useful things about the implementation of a particular
virtual display.

We at CMU have had a good deal of success implementing streams with structures,
which leads me to believe that they'll be sufficient for implementing virtual
displays as well.  Our stream structures store both functions ("methods") and
data ("instance variables").  Common Lisp DEFSTRUCT provides inheritance
through the :INCLUDE option, which makes streams (somewhat) easily extensible.
I realize that this system is less flexible than one built on flavors (or any
other real object-oriented programming system), but it is highly portable, and
gives you 90% of the extensibility you'd ever want.

Thus, we might define a virtual display like this:

	(defstruct vd
	  "The root Virtual Display structure."
	  ;; Methods:
	  display-char				; Method for Display-char
	  display-string			; Method for Display-string
	  delete-char				; Method for Delete-Char
	  ...
	  ;; Instance variables:
	  width					; Width in pixels
	  height				; Height in pixels
	  cursor-row				; Row that the cursor's on
	  cursor-column				; Column the cursor's on
	  ...)

	(defun display-char (vd char)
	  "Displays the Char at the current cursor position of the VD,
	   moving the cursor appropriately."
	  (funcall (vd-display-char vd) char))

	...

Then we could define a particular kind of virtual display like this:

	(defstruct (c100-vd
		    (:include vd
			      (display-char c100-vd-display-char)
			      (display-string c100-vd-display-string)
			      ...))
	  "The VD for Concept-100 terminals."
	  ;; Additional instance variables:
	  stream)

	(defun c100-vd-display-char (vd char)
	  (write-char (c100-vd-stream vd) char)
	  (cond ((char= char #\newline)
		 (setf (vd-cursor-column vd) 0)
		 (incf (vd-cursor-row vd)))
		(t
		 (incf (vd-cursor-column vd)))))

	...

That's just an example of the sort of thing one can do, and none of the
particular operations should be taken as suggestions for how a virtual display
should work.

Yes, it's more verbose than flavors, but it is portable and perhaps more
efficient than a flavor-based system would be.  Such a system CAN be extended
by the user.  Do you still think we'd be too constrained by implementing a
virtual display system with structures?

--Skef

∂19-Nov-84  2220	FAHLMAN@CMU-CS-C.ARPA 	Proposals and questions    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Nov 84  22:17:38 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 20 Nov 84 01:16:25-EST
Date: Tue, 20 Nov 1984  01:16 EST
Message-ID: <FAHLMAN.12064983964.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Cl-Windows@SU-AI.ARPA
Subject: Proposals and questions
In-reply-to: Msg of 19 Nov 1984  23:33-EST from Skef Wholey <Wholey>


I agree with much of what Skef Wholey says -- especially the part about
being able to find out which class of display device you have -- but I
don't think I agree that "any virtual display should support all
operations".  The problem is that there are some things you want to do
on a bitmap that just have no counterpart on a 24x80 ASCII terminal
(smart or not).  If we throw all of these things out, we get an interface
for bit-mapped displays that is less powerful than it should be, which
means that more users will write their code using non-standard calls to
get at the display's real power.

Probably the right move is to make the operations for the feeble
displays a subset of those available on the more powerful ones.  In some
cases, we might want the operations for more powerful displays to
recognize additional keywords (such as :COLOR).  We should try to keep
the number of distinct levels fairly small, however.

On the issue of whether to use objects, I think that we cannot define an
object-orineted interface until the Common Lisp community settles on
some particular object-oriented system as being required on all
implementations (though other object systems might co-exist with this).
I don't expect to see this any time soon -- if a standard is to emerge
at all, it will only be AFTER people have had a chance to play with
portable Flavors and Loops and assorted other things and decide what
they like.  I think that we can define a reasonable set of
somewhat-extensible interfaces in a portable non-flavorish way; if we
have to sacrifice some extensibility, that's better than having no
common window interface at all.

-- Scott

∂20-Nov-84  0736	boetje@DEC-HUDSON 	documenting implementations    
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 20 Nov 84  07:35:44 PST
Date: Tue, 20 Nov 84 10:36:01 EST
From: boetje@DEC-HUDSON
Subject: documenting implementations
To: cl-windows@su-ai.arpa

I think the discussion of structures vs object implementation is getting a
little off track. The issues (it seems to me) revolve around the form of the
creation, accessing and setting functions for virtual displays and the method
by which the user can extend the functionality of the virtual display system
Let me address some high level considerations of each issue.

When I say that I prefer a structure implementation for the CL standard, I'm 
not saying that I intend that the DEFSTRUCT for various things be defined in 
the standard. My intention is that we document and standardize creation, 
accessing and setting functions that look like

	(setq display-1 (make-virtual-display ...))
	(virtual-display-label display-1)
	(setf (virtual-display-label display-1) ...)

as opposed to instancing of objects and sending messages to the instances. I 
think that under no circumstances should we document a particular DEFSTRUCT 
implementation and require all Common LISPs to have this. I think that the 
only reason to do this (and it's part of the example Skef gives) is to allow 
users to support output devices not explicitly supported by the vendor. This 
will get us rapidly down a rat hole of terminal support issues. Support of 
"non-vendor" terminals should be an issue for the vendor to address in 
whatever way is most efficient on his system. On the other hand, functions 
such as SET-CURSOR-POSITION should exist in all the CL implementations and do 
the right thing on all supported terminals. If the vendor provides an 
implementation dependent way to define support for other terminals, then the 
positioning function will do the right thing on these other terminals as well. 

Extending the capabilities of operations on virtual displays is a real issue. 
On the other hand, it's not clear that we have to address this right now. I 
propose that we investigate defining a fairly "complete" range of 
functionality which assumes the availability of a nice (color, bitmapped) 
display and then look at subsetting this functionality to cell-oriented 
terminals. A part of this may be defining a number of inquiry functions which 
let the program tailor itself to the capabilities of the run-time device. This 
means that we're likely to end up in the same place as the GKS standard which 
has more inquiry functions than all the other kinds of function combined. 

We can probably have some high level inquiry functions that let the user know
the general category of device (bitmapped, color, vector, cell, etc). Each
category would have a certain level of functionality that's required (by the
standard) for that device and a certain set that's optional and up to the
implementation (eg, narrow virtual displays on a VT100).

∂20-Nov-84  0850	WHOLEY@CMU-CS-C.ARPA 	Virtual Displays  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Nov 84  08:49:57 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Tue 20 Nov 84 11:48:43-EST
Date: Tue, 20 Nov 1984  11:48 EST
Message-ID: <WHOLEY.12065099060.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   CL-Windows@SU-AI.ARPA
Subject: Virtual Displays

    From: Scott E. Fahlman <Fahlman>

    I don't think I agree that "any virtual display should support all
    operations".  The problem is that there are some things you want to do
    on a bitmap that just have no counterpart on a 24x80 ASCII terminal
    (smart or not).  If we throw all of these things out, we get an interface
    for bit-mapped displays that is less powerful than it should be, which
    means that more users will write their code using non-standard calls to
    get at the display's real power.

I believe that the sorts of things you're talking about are in the domain of
CL-Graphics.  I could be wrong.  Could you give me an example of such
operations?  I have a feeling that either they should be hidden by something
very high level (e.g. HALFTONE-RECTANGLE could really halftone a portion of a
raster display, but put a portion of a Concept-100's screen into half-bright
mode), or that they can be implemented by mashing vanilla CRT's into 24x80
raster displays using 1x1 fonts (MOVE-RECTANGLE could do a BITBLT on a raster
display, but actually copy stuff around on other terminals (actually, for dumb
termiansl this would require the VD system to maintain a screen image, which
may or may not be a good idea (but Concept-LNZ's DO have such an operation))).

Perhaps we need to decide on operations before we determine if there needs to
be the distinction that Scott suggests there ought to be.  I think a virtual
display should try its best to perform an operation, but quietly ignore the
request if it can't hack it.  It could bum someone out if a nifty piece of
software didn't run on her computer just because she had a dumb terminal.  If
instead, the display just didn't look as nifty on an ADM-3A as it does on a
Lisp Machine, then the user will probably be forgiving.

    From: boetje at DEC-HUDSON

    I think the discussion of structures vs object implementation is getting a
    little off track.

I was attempting to show that the niceness of an object-oriented approach could
still be had within the Common Lisp language, and with structures.  Perhaps I
should have said "Object oriented programming is a style, and one can write
stylized Common Lisp," and left out all the code in my last message.

    My intention is that we document and standardize creation, accessing and
    setting functions that look like
    ...
    as opposed to instancing of objects and sending messages to the instances.

Sure.  Note that the Display-Char function (intended to be the user-level call)
in my example hid the object oriented implementation.  Streams are the done the
same way, for us.

    I think that under no circumstances should we document a particular
    DEFSTRUCT implementation and require all Common LISPs to have this. I think
    that the only reason to do this (and it's part of the example Skef gives)
    is to allow users to support output devices not explicitly supported by the
    vendor.

So we're just working on a spec here, and not a portable implementation.  Ok.
I think a portable implementation or two will come out of this, though.  The
people doing those implementations probably want to think hard about
extensibility for the sake of porting to new environments in addition to
supporting new devices.

    We can probably have some high level inquiry functions that let the user
    know the general category of device (bitmapped, color, vector, cell, etc).
    Each category would have a certain level of functionality that's required
    (by the standard) for that device and a certain set that's optional and up
    to the implementation (eg, narrow virtual displays on a VT100).

I have a feeling that trying to do things in explicit levels is going to let
capabilities of some terminals fall through the cracks.  I claim that the
problem Scott brought up in the first paragraph quoted above can work in
reverse -- some character-oriented CRT's can do operations like
raster-oritented displays, and others can do different ones.  Maybe this isn't
a problem, but we can't tell for sure until we get into specifics.  Anyone up
for that?

--Skef

∂21-Nov-84  0724	FAHLMAN@CMU-CS-C.ARPA 	Virtual Displays 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Nov 84  07:23:14 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 21 Nov 84 10:22:01-EST
Date: Wed, 21 Nov 1984  10:21 EST
Message-ID: <FAHLMAN.12065345435.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Skef Wholey <Wholey@CMU-CS-C.ARPA>
Cc:   CL-Windows@SU-AI.ARPA
Subject: Virtual Displays
In-reply-to: Msg of 20 Nov 1984  11:48-EST from Skef Wholey <Wholey>


I'm not sure if my view of the dividing line between CL-WINDOWS and
CL-GRAPHICS matches other people's.  I had been assuming that such
things as the primitive calls to display characters in a window at
arbitrary places, draw lines, color in rectangles, and so on were the
provine of the window package, and that any graphics standard is more
concerned with higher-level software to help decide which lines to draw
where.  (If graphic means anything that is written into a virtual
display at all, then we have to consider graphics and windows together
because at that level they are inseparable.)

If my view of the division is correct, then there are several examples
of things that a raster-scan display could do that would have no
immediate counterpart on a dumb terminal: draw lines from one point to
another, display an arbitrary character from an arbitrary font at a
specific location specified in pixels, rotate a chunk of the screen,
return a mouse-click (or some other kind of pointer-selection) in window
coordinates, etc.

I think that it is a terrible mistake to rule out any of these
operations for raster displays just because there is no good equivalent
on an 24x80 character terminal.  I also think that it is not in general
possible to have the built-in window-based software fake all of these
things in "the best way possible" on the dumb terminal.  There's just no
good way to fake a drawing program on an Adm-3A, and I'd rather have the
software fail cleanly than waste a lot of time trying.  Maybe a clever
application programmer can figure out some way to fake his particular
drawing program on a dumb terminal, using the impoverished set of
operations available there, but that should be his problem and not the
Lisp implementor's problem.

So, revised proposal:

We divide features that a diplay might have into broad classes that tend
to go together: Multiple windows, Advanced cursor commands, Pixel
operations, Pointing device, Color, Multiple Fonts, etc.  Some of these
have parameters, such as the X and Y dimensions of the screen in
characters or pixels.  Each display/implemenation is required to
indicate which of these things it has and the values of its parameters,
and therefore what operations it supports.  Software will be written to
assume some set of these feature groups, and the necessary support will
be advertised with the documentation for the software.  If I want my
package to run on ANYTHING, I assume a very minimal set of support; if I
don't want to live with those restrictions, then I assume more.  The
best software providers will conditionalize their code so that if some
feature like color is present, it is used, but if it is not present they
compensate for this in some other way; others may choose not to bother
trying to cope with dumb displays.

-- Scott

∂21-Nov-84  0914	DDYER@USC-ISIB.ARPA 	Implementation strategy 
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 21 Nov 84  09:14:26 PST
Date: 21 Nov 1984 09:13:20 PST
Subject: Implementation strategy
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA


Now that I've lighted the fire, I'll add my contribution to the fuel.

We have to define virtual display operations in a way that is acceptable
to the major implementations, or else the definition will simply be
rejected as brain damaged and ignored.  In particular, it should be
obvious that Symbolics isn't going to re-implement their window system
using structures.  It's just as obvious, as was pointed out, none
of the other CL implementations will have a robust and portable object
oriented system for an indeterminate time.   Therefore, we must define
something compatible with either strategy, and preferably, one that
will permit the underlying implementation to change, as object
systems become available.

What this amounts to is defining a limited object oriented system,
which maximizes information hiding but makes no commitment about
implementation.  The last time I implemented such a system, my
basic primitives looked like this.

(SCREENOP <<window>> <<operation>> &rest args)

Honest Injun, I came up with it before I ever wrote my first DEFFLAVOR!

This was implemented by a hairy macro, which expanded to structure
manipulations appropriate to the operation.  To hack efficiency,
one "operation" was :GET-HANDLER-FOR and another was :INVOKE-HANDLER-FOR.
We might also want an environment macro like 
  (WITH-SCREEN-ENVIRONMENT (VAR WINDOW) --)
Where WINDOW would be decoded (whatever that means) so that references
to VAR would know the exact type of the operand.  


The advantages of this approach are that it is easy to transform
into efficient code for most any implementation, it avoids embedding
implementation details in user code, it makes screen manipulations
easily identifiable, and it avoids polluting the global environment
with arbitrarily many names of operations.   I strongly favor this
kind of surface structure for invoking display operations.


The problem of creating an abstract syntax for defining window types
is stickier.



-------

∂21-Nov-84  1048	KACZMAREK@USC-ISIF.ARPA 	Re: Virtual Displays
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 21 Nov 84  10:48:12 PST
Date: 21 Nov 1984 10:45:02 PST
Subject: Re: Virtual Displays
From: Tom Kaczmarek <KACZMAREK@USC-ISIF.ARPA>
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
cc: cl-windows@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12065345435.BABYL@CMU-CS-C.ARPA>

Typical graphic standards provide a great deal of functionality regarding
the display of lines, circles, points, raster images, and characters.  They
also provide for clipping regions, rotation of images, panning, zooming, and
scaling.  I think that a window package should be built on top of graphic
support.  We should assume the existence of font support (including producing 
bitmaps for text strings), clipping, line drawing, shading, texturing,
coloration, etc..  We should also presume high level primitives for
pointing devices ala GKS and the Siggraph Core standard.

I suggested this in an earlier message but no one seemed to pick up on it
other than to say they wanted to do all the low-level stuff.  I would like
to get a measure on how many people think that windows are at a higher
level than graphics.  I see windows as graphic structures with fairly
restrictive constraints--they are a major component of the user interface
with highly stylized behavior.  They have to be flexible enough to allow an
application programmer to mold the user interface to his liking, yet
restrictive enough so that the user is not overwhelmed by inconsistencies.
I think we ought to check with the graphics group also to get their
feelings to make sure we are not duplicating efforts.

Tom
-------

∂21-Nov-84  1250	greek@DEC-HUDSON 	Terminal features and graphic functions   
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 21 Nov 84  12:49:51 PST
Date: Wed, 21 Nov 84 15:50:10 EST
From: greek@DEC-HUDSON
Subject: Terminal features and graphic functions
To: cl-windows@su-ai

I basically agree with what Scott says about categories of features.
Perhaps we might even end up with some standard symbols in *FEATURES*
for testing by programs.  However, I'm dubious as to the patience
of developers as they try to write code that uses as many features
as possible but avoids ones not on the current terminal.  This kind
of code is difficult to write, and people just tend to write
for the lowest common denominator, or say "screw" to all but the
smartest terminals.

I think we can define virtual displays that will work pretty well
on many kinds of terminals.  If we said that all, or almost all,
operations had to work on all terminals, and forced implementors
to think of ways to do these on dumb terminals (or noop them), we
would be doing the world a favor.  As for complex graphics, that
have no counterpart on dumb terminals, perhaps we shouldn't be
treading on that ground.  Graphics is not a solved problem.

Dave - I don't understand why your statements about window 
compatibility with existing implementations leads you to believe
that the operations must be object-oriented.  What's wrong with
50 functions?  If Symbolics implements these as macros that turn
into flavorful things, no problem.  Streams are object-oriented,
structures aren't, hash tables aren't, arrays aren't.  Why start
now, when we haven't agreed on object-oriented features for CL?
(Read that as "streams aren't object...").

- Paul

∂21-Nov-84  1434	@MIT-MC:MONTALVO@MIT-OZ 	Re: Virtual Displays
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Nov 84  14:34:23 PST
Date: Wed 21 Nov 84 17:31:34-EST
From: Fanya S. Montalvo <MONTALVO%MIT-OZ@MIT-MC.ARPA>
Subject: Re: Virtual Displays
To: KACZMAREK@USC-ISIF.ARPA
cc: Fahlman@CMU-CS-C.ARPA, cl-windows@SU-AI.ARPA, MONTALVO%MIT-OZ@MIT-MC.ARPA
In-Reply-To: Message from "Tom Kaczmarek <KACZMAREK@USC-ISIF.ARPA>" of Wed 21 Nov 84 10:45:02-EST

I think a lot of the issues being raised by cl-windows are relevant to
cl-graphics, and that the relationship between windows and graphics
should be discussed by cl-graphics, also.

I see windows as a subset of graphics.  Support for windows is a
specific kind of functionality that a graphics package may or may not
have.  As a subset, it's neither higher nor lower than graphics.  It
may rely on low-level primitives, but in turn, some even higher level
functionality may rely on it.

And by the way, I'm on cl-graphics also, and may have missed the
discussion of how the division was being made.  If it was already
discussed just forward the relevant messages (not too many please).

Fanya
-------

∂26-Nov-84  0717	boetje@DEC-HUDSON 	graphics, virtual displays, and terminals
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 26 Nov 84  07:16:27 PST
Date: Mon, 26 Nov 84 10:13:21 EST
From: boetje@DEC-HUDSON
Subject: graphics, virtual displays, and terminals
To: cl-windows@su-ai.arpa

On categories of features, here's one suggestion for a basic division...

Take some dumb terminals of the VT100 class. These have the ability to
position a cursor to an arbitrary cell location and write ASCII characters
This is sufficient capability support virtual displays which can have a border
and a label. The set of operations has to be restricted to manipulating text
on a cell-oriented terminal (ie, no proportional fonts). There is a suprising
amount that can be implemented on such a terminal: show arbitrary sized
displays, insert and delete characters (easier on a cell terminal), scroll
lines of text in a display, occlude displays, pick and point via cursor
manipulation and even draw horizontal and vertical lines. For a dumb terminal,
that ain't bad.

The other category then becomes the bitmapped tubes. Let's just assume they 
can do whatever we think up (although character insertion and deletion is 
harder on these terminals). It's up to us to establish a reasonable set of 
operations that should be supported.

So I'd choose two categories: the kitchen sink and the text only. The text 
only terminal is required to be cell-oriented and have the capability to 
position the terminal cursor at an arbitrary cell position. It can support all 
the capabilities needed for a screen editor. The kitchen sink terminal is 
bitmapped and can support an arbitrary level of complexity in its display 
operations. 

On the division of virtual displays and graphics...

The more I've thought about it, they really are fairly separate topics which 
have one area of overlap. Each topic has a number of basic operations and 
concepts which don't relate at all to the other. For example, a discussion of 
virtual displays gets into issues of display management which includes ideas 
such as stacking, occlusion and selection. Graphics deals a lot with 
coordinate transformation, line drawing, graphical objects and area fill. 

The one area of overlap can be neatly defined if we define the picture area of 
a virtual display to be that portion of a display inside of things like labels, 
borders and margins. The picture area is where most everything of interest 
happens in a virtual display. The picture area is also allowed to be a 
graphics viewport onto some data space (such as NDC for you GKS fans). If we 
accept this definition, then the tasks of the display committee and the 
graphics committee become a bit easier. We need to refine things such as the 
coordinate system of the virtual display. Once this is done, the graphics 
committee can concern itself with coordinate transformations, composition, 
basic operations and picking. The display committee can be concerned with 
management of virtual displays, use of a virtual display in place of a CL 
stream, and the definition of what surrounds a virtual display (labels, 
borders, margins, etc).

	Jerry

∂08-Dec-84  1642	DDYER@USC-ISIB.ARPA 	Easy Questions
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 8 Dec 84  16:42:42 PST
Date:  8 Dec 1984 16:41:41 PST
Subject: Easy Questions
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA


I'd like to gauge the "real world" concerns of the members of this
list regarding portable windows.   Feel free to editorialize.  The
questions are:

	What existing, under development, or planned programs
	would use common lisp's window system if it had one?

	What existing, under development, or planned programs
	would NOT use common lisp's window system, even if
	it had one?  Why?
-------

∂08-Dec-84  1927	FAHLMAN@CMU-CS-C.ARPA 	Easy Questions   
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Dec 84  19:27:18 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 8 Dec 84 22:27:55-EST
Date: Sat, 8 Dec 1984  22:27 EST
Message-ID: <FAHLMAN.12069934029.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Dave Dyer <DDYER@USC-ISIB.ARPA>
Cc:   cl-windows@SU-AI.ARPA
Subject: Easy Questions
In-reply-to: Msg of 8 Dec 1984  19:41-EST from Dave Dyer <DDYER at USC-ISIB.ARPA>


This question is not so easy.  The answer depends totally on what the
standard Common Lisp window system ends up looking like.  In the Spice
Lisp system (on the Perq, at present) we now have a simple set of Lisp
function calls that gives us efficient access to the window and graphics
operations available in the system: window creation and deletion, what
appears in the title line and progress bar, what appears in the icon
associated with the window, line drawing, character moves, raster ops,
reading from the screen bitmap, and so on.  Actually, all of these
services are provided outside of the Lisp process, and the calls turn
into messages to the system kernel or to the screen-manager process, but
the user doesn't need to know that.

If the window/graphics standard turns out to be a set of function calls
that gives us access to all of the same kinds of operations, then we
would probably use it for most of our graphics-oriented applications and
possibly even for the Hemlock editor.  This would become the standard
set of screen-oriented function calls in our Lisp system.

If the standard provides access only to a small subset of the Spice
display facilities, or enforces a substantially different view of the
display abstractions than our system supports, or if it is grossly
inefficient for some reason, then we would probably use the native Spice
calls for all of our local programming, but would occasionally translate
certain vanilla applications or utilities into the Common Lisp
graphics/window standard for export.

If, in the interest of extensibility or whatever, the standard window
system ends up being object-oriented and ultra-hairy like the current
Zetalisp window system, I don't think it will be used at all at CMU,
except by the one or two people who have been writing graphics code on
our Lisp machines and have somehow manged to figure this stuff out.

-- Scott

∂11-Dec-84  1207	DDYER@USC-ISIB.ARPA 	Re: Easy questions 
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 11 Dec 84  12:07:22 PST
Date: 11 Dec 1984 12:02:13 PST
Subject: Re: Easy questions
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA

Replies from: 
            8-Dec Kent M Pitman        easy questions? (1327)
            8-Dec John W. Peterson     Re: Easy Questions (3632)

			------

Date: 8 December 1984 19:54-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: easy questions?

Actually, the second question is quite hard. It's easy to say
"Oh, yeah, if you provided me a window system, I'd use it for ..."
without knowing what it offered because it's a "friendly" thing to
say and people will be willing to suppose your window system will
"meet their needs". Saying I wouldn't use a window system even
if you gave it to me is to say you don't believe it would meet your
needs no matter what, which either says you strongly believe that 
there are two different viable theories of window systems and that
you want one but believe CL will provide the other, or that you 
believe there's only one such system and CL doesn't stand a chance
in hell of going the right direction.

Anyway, it occurs to me that you might ammend the second question, or
add a third, to find out what features that if a window system lacked
would make it useless, or what features that if a window system had
would make it useless. eg, you might have said:
  "What kind of window system would not suit some existing, under
   development, or planned program?"

-kmp

Date: Sat 8 Dec 84 18:25:06-MST
From: John W. Peterson <JW-Peterson@UTAH-20.ARPA>
Subject: Re: Easy Questions

        What existing, under development, or planned programs
        would use common lisp's window system if it had one?

I'm currently working on a CAGD (Computer Aided Geometric Design) system under
lisp.  It is extensivly window based, and designed to be portable to some
degree (versions currently run on devices such as Apollo domains and Evans &
Sutherland PS300 Vector engins).  The system is "different" from most CAD
environments in that a program (a "procedural model") is written to describe
the part you are constructing.  These programs "emit" B-Spline surfaces, which
are then used to generate shaded images, N/C toolpaths, etc.  We use 
interactive (3-Dimensional) graphics to view the model as it is constructed.
This is coupled with a special version of SETF that displays the graphics
representation of an entity (point, line, arc, curve, surface, etc) in a
graphics window when it's value is assigned.  Multiple graphics windows can
be used to view differnt (or different views of the same) geometric 
constructions.  At any time you can grab a knob and rotate the geometry in
a 3D window to get a better view (this happens in real time on the E&S tubes,
step-by-step on less powerful displays).

Since the model is built from a lisp program, a text editor (usually a full-
featured EMACS) window is used to write the program in.  You evaluate your
program step-by-step in the emacs window; and see the geometric results in
the graphics window as you go along.  

A current (and very tricky!) research issue is to be able to interactivly
modify the graphics representation of the model (in the graphics window) and
have these changes reflected in your program.  Thus, the textual representation
of the model in your EMACS window would get automaticly updated, much like
the graphics is updated now when you change the text.  [A master's student
here has done some preliminary work with this].

Currently this is all done with, well, a lot of masking tape.  We have a
PSL (Portable Standard Lisp) process running under the control of Gosling's
emacs.  The PSL process in turn drives the several graphics windows, updating
them whenever a SETF occurs on a geometric object.  In my ideal universe,
this would be running as a single Lisp program on a powerful Lisp Machine.
But these weren't readily available to us when we started (80-81), and
many of our contractors would still balk at an $80K/User workstation.

Hmmm, that's probably a longer discription than you bargianed for, but I guess
it's a useful example of a -complex- application for a Lisp-based window 
system.  After all, I want these windows to do everything from powerful
text editing to real-time 3D graphics...

PS
I would find a summary of the applications you here about interesting.  And
as to your other question:
        What existing, under development, or planned programs
        would NOT use common lisp's window system, even if
        it had one?  Why?

About the only code I can think of that falls into this catagory are 
ones that aren't interactive (i.e, rendering programs that take a long time
to run).  But even then, I STILL want those windows for debugging and editing
it!
-------
-------

∂12-Dec-84  2201	RAM@CMU-CS-C.ARPA 	Easy Questions  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Dec 84  22:01:46 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 13 Dec 84 01:02:24-EST
Date: Thu, 13 Dec 1984  01:02 EST
Message-ID: <RAM.12071010731.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   Dave Dyer <DDYER@USC-ISIB.ARPA>
Cc:   cl-windows@SU-AI.ARPA
Subject: Easy Questions


    I have a suspicion that the Hemlock text editor will not use any
window standard which may be agreed upon.  Hemlock is currently in use
in the CMU community, and a much mutilated early version forms the
basis of the DEC VAX Lisp editor.  It is about 20k lines of largely
portable Common Lisp code.  The current Hemlock screen manager is
inadequate, and one of my current projects is to design a new one.
The main functions of the screen manager will be the following:
 1] Allocate windows in a manner culturally compatible with EMACS.
 2] Provide primitives for drawing strings and copying and clearing
    screen areas.
 3] Provide some sort of abstract interface to multiple fonts of
    varying heights and widths.  I have something in mind along the
    lines of Scribe font-families.
 4] Deal with demultiplexing keyboard and mouse input.
 5] Provide some sort of abstract interface to the software interrupts
    generated by our window system when windows are exposed or
    resized.
 6] Have some sort of support for highlighting.

    Some reasons I don't think that a portable window manager is likely to be
usable:
 A] Some of things that need low-level support in the window system
    (4, 5) probably cannot be resolved to everyone's satisfaction.
 B] Efficiency is important, thus it may be desirable to add special
    primitives to make the drawing primities provided more closely
    correspond to those actually supported.

Other comments:

    I am not very impressed by environment query functions, or rather
the programming style they seem to encourage.  Redisplay, which is the
level above the screen manger, needs to have a very good idea of what
the device can and cannot do.  What I intend to do is have several
different versions of redisplay which are selected on the basis of the
general class of device driven, e.g. bit-mapped screen, windowing
terminal, smart terminal, dumb terminal.  If it is necessary to have
significant procedural knowledge about the device at a level above the
window system to attain good performance across a wide range of
devices, it is futile for the window system to attempt to hide the
fundamental characteristics of the device.

    If graphics includes such things as scaling, symbols, rotation and
arbitrary coordinate transforms, then I think that it is wrong to
think of "Windows" as being a layer above "Graphics".  It is true that
any window system will be based on some set of graphical primitives
for doing things such as rasterop and drawing lines, but these things
will operate in device units, and thus will not be the primitives of
the graphics system.  I suspect that it is much more probable that the
graphics system be built on the window system, since graphics will
probably be done on the windows or "virtual displays" provided by the
window system, while the window system will have no use for any of the
hair provided by the graphics package.

  Rob

∂09-Jan-85  0110	DDYER@USC-ISIB.ARPA 	This space intentionally left blank    
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 9 Jan 85  01:10:32 PST
Date:  9 Jan 1985 01:07:31 PST
Subject: This space intentionally left blank
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA


 I've been impressed by both the high quality and the low volume
of discussion on this mailing list.  I think this is indicative
of an unfortunate state of affairs.  We collectively appreciate 
the nuaces of and appreciate the magnitude of "the window problem",
hence the high quality.  We collectively agree on most issues of
substance, hence the low volume.

 This would be fine, except there is no CL window system, and
at this rate, there never will be!   Why this paralysis?  I suspect
we also share the resigned realization that a combination of
vested interests and inertia will defeat any effort to establish
a standard.

-------

∂09-Jan-85  1001	KACZMAREK@USC-ISIF.ARPA 	Dire Dyer Prediction
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 9 Jan 85  10:01:43 PST
Date:  9 Jan 1985 08:02:54 PST
Subject: Dire Dyer Prediction
From: Tom Kaczmarek <KACZMAREK@USC-ISIF.ARPA>
To: cl-windows@SU-AI.ARPA
In-Reply-To: (Message from "Dave Dyer <DDYER@USC-ISIB.ARPA>" of 9 Jan 1985 01:07:31 PST)


I think that the dire Dyer prediction is premature.

I take the volume of messages for this group as a positive sign.  It has
been considerably higher for this group than for the two other groups I
know about.  The volume of messages has reduced lately indicating, as Dave
points out, agreement on the issues.  (Should the volume be seasonally
adjusted?  We have all probably had more vacation days/holidays recently
than normal.)  I think any drop in volume indicates that we are at a
critical point--we are ready to start the process of design.  I would
suggest that we need someone, preferably who already has a design for a
window system, to step forward and propose it as the standard.  (If more
than one volunteer steps forward we ought to consider multiple proposals.)
Published proposals followed by a several day workshop to discuss them
seems appropriate to me.

The proposals are sure to cause controversy and vested interests are
certainly going to play a part in the negotiations that follow.  Some
groups will decide not to follow the standard and others will.  That is
nothing new.  I don't think we ought to admit defeat just yet.

Tom

-------

∂09-Jan-85  1117	DDYER@USC-ISIB.ARPA 	Re: This space intentionally left blank
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 9 Jan 85  11:17:08 PST
Return-Path: <JW-PETERSON@UTAH-20.ARPA>
Received: FROM UTAH-20.ARPA BY USC-ISIB.ARPA WITH TCP ; 9 Jan 85 01:33:45 PST
Date: Wed 9 Jan 85 02:35:55-MST
From: John W. Peterson <JW-Peterson@UTAH-20.ARPA>
Subject: Re: This space intentionally left blank
To: DDYER@USC-ISIB.ARPA
cc: JW-Peterson@UTAH-20.ARPA
In-Reply-To: Message from "Dave Dyer       <DDYER@USC-ISIB.ARPA>" of Wed 9 Jan 85 01:07:31-MST
ReSent-Date:  9 Jan 1985 11:16:59 PST
ReSent-From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
ReSent-To: cl-windows@SU-AI.ARPA, cl-graphics@SU-AI.ARPA

A related question.  I thought (or at least was under the impression) that
I was tuned into the CL-GRAPHICS list as well.  I have not heard a *peep* out
of that list, do you know if it's active?

This is somewhat relavent to CL-Windows, since I am from the school of thought
that the window system should know about (and perhaps be based on) the
graphics support.  To some extent, I've been "waiting" to see what that list
says  (This may hold true for others as well, e.g., the "units of measurement"
discussion a while back).

Cheers.
-------

∂09-Jan-85  1322	boetje@DEC-HUDSON 	here's something to make up for the long silence... Jerry    
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 9 Jan 85  12:59:45 PST
Date: Wed, 09 Jan 85 15:10:33 EST
From: boetje@DEC-HUDSON
Subject: here's something to make up for the long silence... Jerry
To: cl-windows@su-ai.arpa, cl-graphics@su-ai.arpa







                                                        9 January 1985










                             COMMON LISP

                           Graphics Models
!
                                                               Page ii


                                   CONTENTS

        1       INTRODUCTION . . . . . . . . . . . . . . . . . . . . 1
        1.1       Purpose  . . . . . . . . . . . . . . . . . . . . . 1
        1.2       Terms  . . . . . . . . . . . . . . . . . . . . . . 1
        2       GENERAL CONCEPTS . . . . . . . . . . . . . . . . . . 2
        3       COORDINATE SYSTEMS . . . . . . . . . . . . . . . . . 4
        3.1       Application, World, User Coordinates . . . . . . . 5
        3.2       Master, Object Coordinates . . . . . . . . . . . . 5
        3.3       Physical Device Coordinates  . . . . . . . . . . . 5
        3.4       Logical Device Coordinates . . . . . . . . . . . . 6
        3.5       Virtual Display Coordinates  . . . . . . . . . . . 6
        3.6       Normalized Device Coordinates (NDC)  . . . . . . . 7
        4       TRANSFORMATION . . . . . . . . . . . . . . . . . . . 8
        4.1       Rotation . . . . . . . . . . . . . . . . . . . . . 8
        4.2       Scaling  . . . . . . . . . . . . . . . . . . . . . 8
        4.3       Translation  . . . . . . . . . . . . . . . . . . . 8
        5       TRANSFORMATION OPERATIONS  . . . . . . . . . . . . . 9
        5.1       Matrix Representation  . . . . . . . . . . . . . . 9
        5.2       Window-Viewport Transformation . . . . . . . . . . 9
        5.3       Active Transformation  . . . . . . . . . . . . .  10
        6       CLIPPING RECTANGLE . . . . . . . . . . . . . . . .  10
        7       COMPOSITION  . . . . . . . . . . . . . . . . . . .  11
        7.1       Composition Space  . . . . . . . . . . . . . . .  11
        7.2       Segments . . . . . . . . . . . . . . . . . . . .  12
        7.3       Virtual Display Composition  . . . . . . . . . .  12
        7.4       COMMON LISP Composition Levels . . . . . . . . .  13
        8       ATTRIBUTES . . . . . . . . . . . . . . . . . . . .  13
        8.1       Attribute Descriptions . . . . . . . . . . . . .  13
        8.2       Attribute Inheritance  . . . . . . . . . . . . .  16
        9       VIRTUAL DISPLAYS . . . . . . . . . . . . . . . . .  17
        9.1       Composition Space  . . . . . . . . . . . . . . .  18
        9.2       Picture Area . . . . . . . . . . . . . . . . . .  18
        9.3       Banner Area  . . . . . . . . . . . . . . . . . .  18
        9.4       Border . . . . . . . . . . . . . . . . . . . . .  19
        9.5       Margin . . . . . . . . . . . . . . . . . . . . .  19
        9.6       Virtual Display Window . . . . . . . . . . . . .  19
        9.7       Device Viewport  . . . . . . . . . . . . . . . .  19
        9.8       LISP Terminal Streams To Virtual Devices . . . .  19
        9.9       Input Cursor . . . . . . . . . . . . . . . . . .  20
        10      POINTING AND PICKING . . . . . . . . . . . . . . .  20
        10.1      Pointing   . . . . . . . . . . . . . . . . . . .  21
        10.2      Picking  . . . . . . . . . . . . . . . . . . . .  21
        11      DISPLAY MANAGEMENT . . . . . . . . . . . . . . . .  21
        11.1      Visibility And Stacking  . . . . . . . . . . . .  22
        11.2      Sensitive Regions  . . . . . . . . . . . . . . .  23
        11.3      Menus  . . . . . . . . . . . . . . . . . . . . .  23
        11.4      Pointer And Selection  . . . . . . . . . . . . .  23
        12      BITMAPS  . . . . . . . . . . . . . . . . . . . . .  24
!
COMMON LISP Graphics Models                                     Page 1
INTRODUCTION


1  INTRODUCTION

1.1  Purpose

This somewhat ambitious document is an attempt to establish  a  common
framework  for discussions of graphics, windows, virtual displays, and
all the supporting concepts that go along with them.  It  specifically
doesn't define LISP functions yet.  My claim is that without agreement
at the level of concepts and terminology, we can't possbly get started
on defining LISP functions.

The material presented here covers concepts and terms  which  properly
belong  to  both  the graphics and windows committees.  The reason for
this is to present a unified view  toward  video  displays  before  we
define  functions.   I  believe that when we start defining functions,
we'll find a fairly neat partition of functions between  graphics  and
virtual  display  creation  and  management.  But we're less likely to
have functional incompatibilities if we can agree on some  high  level
ideas.

A section missing from this document is  a  discussion  of  levels  of
capabilities  that  can  be supported by various hardware and software
implementations.  I'd welcome ideas on this.  As  a  first  cut,  I'll
propose three levels:

     1.  That which you can do on a cell-oriented  character  terminal
         such  as a VT100 (text editor capabilities, multiple displays
         and simple menus).

     2.  Add basic graphics operations but without composition.  Level
         2  might  include  restricted composition of virtual displays
         (no additional scaling or rotation) much like the  frame/pane
         systems around.

     3.  Full multi-level composition  capability  and  allowance  for
         user-written N-dimensional processing.

With some luck, this should start a new flood  of  discussion.   Happy
reading.



1.2  Terms

Terms will be defined in this document by  establishing  the  concepts
they  represent.   This  will not only provide context and explanation
but show the functional interrelationships among  the  various  terms.
Where  possible,  "established" terms will be used.  A difficulty with
the  current  industry  environment  is  that  the  same  word   (e.g.
"window")  is  often  used to represent very different concepts.  Such
industry discrepancies will be noted.

At least the following terms will be defined:
!
COMMON LISP Graphics Models                                     Page 2
INTRODUCTION


     Attribute
     Clipping rectangle
     Composition
     Display management
     Picking 
     Pointing
     Segment
     Transformation
     Viewport
     Virtual display
     Window

The presentation of conceptual  models  is  designed  to  explain  and
illustrate  both the generalization of certain techniques, such as the
window-viewport transformation, and the methods by which  COMMON  LISP
integrates  the  various  objects  and  operations  that  support  the
workstation.



2  GENERAL CONCEPTS

This paper deals with the concepts used in displaying data on a  video
terminal.   Such  a  display might be as simple as placing consecutive
lines of text on a screen.   It  might  also  involve  drawing  lines,
shading  figures,  and overlapping independent displays.  This process
can be made arbitrarily complex.  Certain conventions  and  techniques
have  evolved  for defining and managing this process.  Unfortunately,
different conventions and terminology have evolved  in  the  different
worlds  of  display  management  and  graphics.   Much  of  this paper
describes a system of terminology and concepts which attempts to unify
the different approaches taken by display management and graphics.

The remainder of this section will describe  the  display  process  in
general (and not always immediately defined) terms.

The basic displayable  object  is  a  "virtual  display."  This  is  a
rectangular  area  which  can be associated with (made visible on) the
screen of a video display  device.   A  virtual  display  can  have  a
"banner"   (identifying  information),  a  "border"  (a  pattern  that
outlines the virtual display), a "picture area"  (the  inside  of  the
display  where  information  can  be  shown), and up to four "margins"
(space between the border and the picture area).

The simplest kind of information display involves creating  a  virtual
display  and  writing  text  into its picture area by using the normal
COMMON LISP stream output operations.

The next level of complexity involves doing  graphical  operations  to
the picture area of a virtual display.  Graphical operations are those
which (loosely  speaking)  produce  non-text  images  in  the  virtual
display.   They include operations such as drawing lines and polygons,
filling areas with some pattern,  and  putting  graphical  symbols  at
points.
!
COMMON LISP Graphics Models                                     Page 3
GENERAL CONCEPTS


Graphical operations usually require one or more pairs of  coordinates
to  give  the  location(s) of the output.  A virtual display's picture
area has a coordinate system with its origin  (location  0,0)  at  the
lower  left corner.  The location of points in the picture area can be
given by specifying offsets into the picture area along the horizontal
(X)  and  vertical  (Y) axes.  These offsets, as well as the bounds of
the picture area, are expressed in centimeters.

All supported graphics operations can be done directly  in  a  virtual
display,  as long as the coordinates are restricted to those that fall
roughly within the bounds of the picture area.  However, not all  data
in  the  world  falls numerically within the bounds of a picture area.
For example, a physicist might want to graph pion production rate  vs.
impact energy in furlongs per fortnight.  In order to present a visual
depiction, the data (in both axes) must be scaled  and  translated  in
order to fit into the bounded coordinate system of a picture area.  It
may also need to be rotated about some axis.  This process is known as
"coordinate transformation." What is required is a method that defines
the appropriate transformation and thus allows the user to express his
data  in  the  most convenient units.  The commonly selected method is
called the "window-viewport transformation."

A "window" is a rectangular area usually specified in  the  coordinate
system  of  the  user data.  This user coordinate system is called the
"application data space." The specification of a window  is  really  a
statement that says "all data of interest to me falls in this range."

A "viewport" is a rectangular area defined in the coordinate system in
which  the  graphical  representation  of  the  data  will  be kept or
displayed.  Such a coordinate  system  might  be  that  of  a  virtual
display,  with  the  viewport defined to be all or part of the virtual
display's  picture  area.   The  specification  of  a  viewport  is  a
statement  that  "this is where I want to see the pictorial view of my
data."

At the simplest level, a window-viewport transformation might  involve
the  definition  of a window in a user's application data space and an
associated viewport which is the picture area of  a  virtual  display.
Now  the  user is free to draw lines and do other graphical operations
in the coordinate system of his data.  The results will appear in  the
picture area of the virtual display.

Now  that  the  transformation  operation  is   defined,   a   further
complication   can   be  introduced:   the  notion  of  "composition."
Composition means the building up of a graphical object in a  separate
coordinate  system  (the  "composition space").  In the previous case,
the picture area of a virtual display was used as a composition space.

There is no reason that the notion of composition cannot  be  combined
with  transformation  to  enable  production  of  arbitrarily  complex
graphical systems.  For example,  the  Graphics  Kernel  System  (GKS)
defines  two levels of composition and transformation.  GKS comes with
a predefined composition space called  Normalized  Device  Coordinates
(NDC)  which  has  bounds  at (0.0,0.0) and (1.0,1.0).  The user first
!
COMMON LISP Graphics Models                                     Page 4
GENERAL CONCEPTS


specifies a transformation from application data space into NDC.  Then
additional transformations are created which map portions of NDC space
onto  the  physical  device  screen  (which  is  treated  as   another
composition space).

This complexity can be increased since this  process  can  go  to  any
level if the user is allowed to create independent composition spaces.
The graphics world has created the concept of "segments" to  represent
independent   composition   spaces.    These  composition  spaces  are
typically mapped onto multiple viewports so that  a  single  graphical
object  may be viewed simultaneously in many places.  For example, the
symbol for a NAND gate is drawn in an  independent  composition  space
which is then mapped into multiple places in a circuit diagram.

"Display management" refers to the means supplied to position  virtual
displays  on  the  screen  and  to  determine  which shall be visible.
Virtual displays are made visible on the screen  by  associating  them
with the screen.  Since virtual displays are opaque, they can hide, or
"occlude," other virtual displays.  The display management system must
therefore  determine  which  virtual display will be occluded when two
overlap on the  screen.   The  system  does  this  by  consulting  the
"stacking  order"  to  see  when  each display was associated with the
device.  The position of a virtual display in the stacking  order  can
be  altered,  or  the virtual display can be removed from the stacking
order altogether.

The display management system must also provide means to move  virtual
displays on the screen and to change their shape and size.

A pointing system allows the user to move a cursor around  the  screen
in  order  to indicate positions where operations should take place or
to choose some object (such as a menu selection) from a display.   The
positioning  operation  is  called "pointing" and the process of using
the pointing system to choose an object is called  "picking."  Certain
areas  of  the  display can be made sensitive to the pointing system's
cursor so that an action can be triggered when the  cursor  enters  or
leaves the sensitive area.

With this introduction, the remainder of the paper  goes  on  to  more
rigorously  define  these and other concepts of a possible COMMON LISP
graphics and display model.



3  COORDINATE SYSTEMS

Much of the confusion around displays, graphics, bitmaps, etc.  has to
do   with   the   use   of   different   coordinate  systems  and  the
transformations between them.  Several coordinate systems will be used
in later discussions.  Some of the important ones are defined here.
!
COMMON LISP Graphics Models                                     Page 5
COORDINATE SYSTEMS


3.1  Application, World, User Coordinates

These terms all loosely refer  to  the  same  idea  of  an  unbounded,
N-dimensional  space of floating-point numbers, where N is typically 2
or 3.  As used in graphics systems, these terms really  refer  to  the
coordinate system in which some particular set of graphical operations
(draw line, draw point, etc.) is performed.  Another  way  of  stating
this is that these are the most convenient coordinates in which a user
can graphically describe his data.

For example, for a graph  of  volume  of  sales  by  year,  it's  most
convenient  for  the  user  to give the data to the graphics system as
number pairs representing millions per year.  The graphics  system  is
then   responsible  for  eventually  transforming  this  data  to  the
coordinates of the display device and displaying it.

There is no  composition  implied  by  the  specification  of  several
graphical   objects   in  overlapping  application  coordinates.   For
example, several objects may be drawn in a range of  coordinates  from
(1.0,1000.0)  to (5.0,1000.5) and yet they will not appear together in
the display if they are directed to different composition spaces.

All output operations are specified in application data space and  are
transformed  into  a  composition  space.  This implies that there can
only be a single "active transformation" in effect at any given  time.
(See  Transformation  Operations  for  more  information on the active
transformation.)

This paper will use the term "application data space"  when  referring
to  the  coordinate  system  in  which  the  user  performs  the basic
graphical operations that build an object.



3.2  Master, Object Coordinates

These terms refer to the coordinate system defined by some composition
space  used  to  describe  a  particular  object.  The coordinates are
expressed as floating-point numbers.  This new object may be a part of
a larger drawing in one or more different composition spaces.

This paper will use  the  term  "master  coordinates"  for  coordinate
systems used in this way.



3.3  Physical Device Coordinates

Physical  device   coordinates   consist   of   a   bounded   set   of
two-dimensional  integer  coordinates  that  specify  the  addressable
positions of an output device's display area.  The device  coordinates
themselves  do  not  specify the absolute size of an addressable unit.
The unit may be a pixel on a bitmap terminal, or a character cell on a
character  terminal.   Each implementation must supply functions which
!
COMMON LISP Graphics Models                                     Page 6
COORDINATE SYSTEMS


give the physical size of the addressable units  of  the  device,  for
example,  the height and width of a pixel.  This allows users who wish
to work in the physical units of the device to scale their coordinates
appropriately.

The numeric range of each axis  is  defined  by  the  physical  device
itself,  as  are  the  location of the origin and the direction of the
axes.  For example, a character terminal may have an origin  at  (1,1)
in  the  upper left corner of the screen with the X bound of 80 or 132
and the Y bound of 24.  A  particular  bitmap  terminal  may  have  an
origin  at  (0,0)  in the lower left corner with X and Y ranges of 767
and 468.



3.4  Logical Device Coordinates

Logical  device  coordinates  are  two-dimensional  coordinates   with
floating-point   values.    Logical  device  coordinates  specify,  in
centimeters, locations on a "logical device" which is  independent  of
the   particular   physical   display  device.   Furthermore,  logical
coordinates always have a (0,0) origin at the lower left corner of the
display  screen.   The  logical display screen thus corresponds to the
upper right quadrant of a conventional X-Y coordinate system.

Since  logical  device  coordinates  always  specify  measurements  in
centimeters,  an  object  or  display  that is described using logical
device coordinates will have the same size and  shape  on  any  output
device.  Users who wish to work in physical device coordinates can use
the functions that give the size of a physical device unit to  control
the size and shape of their images.  (See Physical Device Coordinates,
above.)

This paper will always use the term "device coordinates" in the  sense
of "logical device coordinates" unless otherwise stated.



3.5  Virtual Display Coordinates

Virtual  display  coordinates   are   two-dimensional   floating-point
coordinates  that  specify  locations  within  a virtual display.  The
units of the virtual display coordinates are the same as the units  of
the logical device coordinates, that is, centimeters.

Since virtual display coordinates and logical device coordinates share
the  same  units and since both have origins in the lower left corner,
the position of a point in a virtual display on the logical display is
a  pure  translation  of  that  point  from  the origin of the logical
display coordinate  system.   In  other  words,  only  translation  is
required  when  placing  or  shifting a virtual display on the logical
device; no scaling or rotation is needed.
!
COMMON LISP Graphics Models                                     Page 7
COORDINATE SYSTEMS


3.6  Normalized Device Coordinates (NDC)

This is a term  commonly  defined  by  the  implementors  of  graphics
systems.    Normalized   Display  Coordinates  describe  an  idealized
graphics display device that has a square display and an aspect  ratio
of  1  (meaning that a mathematical square is "displayed" as a square,
not  a  rectangle).   Locations  in  this  display  are  specified  by
coordinates  whose X and Y values can be floating-point numbers in the
range of 0.0 to 1.0, inclusive.  The origin in the NDC  system  is  at
the lower left of the display.

By using Normalized Device Coordinates, all graphics  data  is  mapped
into NDC space before mapping to the physical device.  In the Graphics
Kernel System (GKS), NDC  space  provides  both  a  device-independent
coordinate mapping and a graphical composition layer.
!
COMMON LISP Graphics Models                                     Page 8
TRANSFORMATION


4  TRANSFORMATION

Transformation  (or  coordinate  transformation)  is  the   one-to-one
mathematical  mapping  of  points in one coordinate system to those in
another.  In the current context, transformation is limited to  linear
operations of scaling, rotation, and translation.  Projection (mapping
of an N-dimensional space onto N-1 or fewer dimensions) is not treated
in  this document.  The remaining discussions are therefore limited to
two dimensions, although nothing in the design should prohibit a  user
from  defining  N-dimensional transformations and implementing his own
projection algorithms for treating higher dimensional graphics.

See Chapter 7  of  "Fundamentals  of  Interactive  Computer  Graphics"
(Foley   and   Van  Dam)  for  a  thorough  discussion  of  coordinate
transformations in graphics systems.



4.1  Rotation

Rotation is the mapping of points  (x,y)  to  points  (x',y')  by  the
equations

     x' = x * cos(a) - y * sin(a)
     y' = x * sin(a) + y * cos(a)

where a is the angle  of  counterclockwise  rotation.   Visually,  the
entire picture is rotated by the angle a.  Rotation is always computed
around the coordinate origin.  Aspect ratio is always preserved  under
a rotation transformation.



4.2  Scaling

Scaling is a  mapping  of  points  (x,y)  to  points  (x',y')  by  the
equations

     x' = x * x←factor
     y' = y * y←factor

where x←factor and y←factor are  constant  terms.   Visually,  scaling
produces  an  enlargement  or  diminishment  of the plotted data along
either axis.  Aspect ratio (the ratio of the sizes  of  the  x  and  y
axes) is preserved only when x←factor = y←factor.



4.3  Translation

Translation is the mapping of points (x,y) to points  (x',y')  by  the
equations

!
COMMON LISP Graphics Models                                     Page 9
TRANSFORMATION


     x' = x + x←offset
     y' = y + y←offset

where x←offset and y←offset are constant terms.  Visually, the  entire
picture is moved intact to another location.



5  TRANSFORMATION OPERATIONS

5.1  Matrix Representation

All points in the  graphics  system  are  represented  in  homogeneous
coordinates.   Therefore,  all  transformations in N-dimensional space
may be represented by an (N+1)-dimensional square matrix.  The  actual
mapping of points (x,y) to points (x',y') may be carried out using the
following equation:

     [x', y', 1] = [x, y, 1] *  | r11 r12  0 |
                                | r21 r22  0 |
                                | t1  t2   1 |

which reduces to two equations involving a total of four multiply  and
four add operations.

Transformations in COMMON LISP will be treated as LISP  objects  which
may    contain    these   specialized   N-dimensional   matrices.    A
transformation object can be created by specifying  a  window-viewport
pair  and  adding rotation information, if any.  The user will also be
allowed to create transformation objects to suit his own needs.   This
latter    capability   is   important,   since   the   window-viewport
transformation only  produces  scaling  and  translation  without  any
rotation  capability.  Also, the transformation manipulation functions
will accept N-dimensional transformation objects and are likely to  be
more efficient than user-written matrix multiplication code.

A  transformation  object  may  also  be  defined  which  involves   a
user-written  function  that  will  be called when a transformation is
required.   This  feature  may  be  used  to  allow  users  to   write
3-dimensional projection and clipping transformations.



5.2  Window-Viewport Transformation

A window is a rectangle whose limits (vertices) are defined in  a  set
of  coordinates  which  may  lie  in application data space or in some
defined composition space.  Conceptually, a window  functions  like  a
"window"   in  the  real  world  (the  glass  variety).   It  opens  a
rectangular area in some coordinate space so that any data which falls
within  the  limits  of the window may be made visible to the user.  A
window may specifically delete data that falls outside its limits;  in
this  case it is a clipping rectangle (see Clipping Rectangle, below).
If clipping is not enabled, data that falls  outside  the  window  may
!
COMMON LISP Graphics Models                                    Page 10
TRANSFORMATION OPERATIONS


still be visible.

In conjunction with a viewport, a window is used to provide a  scaling
and  translation  transformation.   This  is  a conventional method in
graphics to specify a coordinate transformation.

A viewport is a rectangle whose limits are  defined  in  a  coordinate
system  that must lie in some defined composition space.  The viewport
serves two functions:

      o  It defines where in the composition space the data  or  other
         information will appear.

      o  When associated  with  a  window,  it  defines  a  coordinate
         transformation  specification  and  also  indicates that data
         "seen through" that particular  window  will  appear  in  the
         viewport.



5.3  Active Transformation

All  graphics  operations  must  be  applied  with  respect  to   some
transformation.   For  example,  a line is drawn by specifying the end
points  of  the  line.   The  coordinates  of  these  points  may   be
transformed  into the master system of some object which is being used
in a composite display, or directly into the picture area of a virtual
display.   In  the  first case, the transformation may be an elaborate
one which includes multiple  levels  of  scaling  and  rotation.   The
latter may only involve a simple translation of points relative to the
origin of the logical device coordinates.

All of the output functions  which  require  positioning  information,
such  as  line  drawing and character insertion, will take an optional
transformation argument.  The default value of this argument  will  be
the   currently   specified   active   transformation.    The   active
transformation is no different from any  other  transformation  except
that  it  has  been  designated  to  be the default transformation for
output operations.  The system should provide a  function  similar  to
the  COMMON LISP IN-PACKAGE function which sets the value of a special
variable which is the active transformation.  In addition, the  system
may  have  a  macro (WITH-TRANSFORMATION) which binds the value of the
current transformation within some scope.



6  CLIPPING RECTANGLE

A clipping rectangle is a rectangle defined  as  a  window  either  in
application data space or in a composition space.  Clipping is part of
the transformation operation.  It is usually done in  the  originating
coordinate  system.   The  purpose  of  clipping is to remove from the
display any portions  of  a  graphical  image  that  lie  outside  the
clipping rectangle.  Thus, if the user specification of a line has end
!
COMMON LISP Graphics Models                                    Page 11
CLIPPING RECTANGLE


points which are outside the rectangle and clipping is  enabled,  only
the portion of the line that falls within the rectangle will be mapped
onto the destination composition space.  If clipping is  not  enabled,
the entire line will be mapped.

In the destination coordinate system, clipping is  performed  only  at
the  boundaries  of  the physical device.  (A viewport cannot define a
clipping rectangle.) Since physical device coordinates are  a  bounded
coordinate  system,  any  points  which  lie outside the bounds of the
physical device will be unconditionally clipped.

Clipping can be enabled or disabled on a  global  basis  or  for  each
graphical output operation.



7  COMPOSITION

Composition is the process of building complex graphical objects  from
(potentially)  a  number  of different objects and coordinate systems.
Conceptually, composition is akin to placing various graphical objects
onto some flat surface in a particular arrangement.  This flat surface
is termed a composition space.  Windows can then  select  portions  of
this  flat  space either for viewing on the screen or for use in other
composition spaces.

A simple example of composition is the definition of the symbol for  a
NAND  gate.   The symbol is created in its own master coordinates.  It
is then mapped onto various parts of  another  composition  space  and
lines are drawn using a different transformation into that composition
space to connect the symbols into a circuit diagram.



7.1  Composition Space

A composition space is an independent data  space  which  has  certain
special characteristics:

      o  It can store graphical objects.

      o  It can optionally  define  a  rectangle  which  may  be  used
         simultaneously  as  a  window,  a  viewport,  and  a clipping
         rectangle.

Mapping from application data space or from a composition  space  onto
another  composition  space  is  accomplished  by  specifying either a
window-viewport pair (plus rotation) or by explicitly providing source
and  destination  spaces  plus  a transformation matrix and a clipping
rectangle.

Portions of a composition space  can  be  further  mapped  onto  other
composition  spaces  to an arbitrary depth; and composition spaces can
be recursively mapped to themselves.   When  a  composition  space  is
!
COMMON LISP Graphics Models                                    Page 12
COMPOSITION


mapped  onto  other  composition  spaces, changes made in the original
composition space appear in all the composition spaces  it  is  mapped
onto.   By contrast, the contents of a composition space can be copied
to other composition spaces.   Any  subsequent  changes  made  in  the
original composition space will not be reflected in the copies.



7.2  Segments

"Segment" is a term used in conventional graphics systems to denote an
independently  specified  graphical  object.   Segments  are  built in
independent composition spaces.  Segments may be  used  together  with
other  graphical  objects  and  primitive  operations to create a more
complex graphical object.

The creation  and  use  of  segments  is  entirely  analogous  to  the
segmentation of programs into subroutines which may be used repeatedly
by different code segments.  The building process is not confined to a
single  level.   Segments  may  be  composed of other segments and the
entire object then used  as  a  portion  of  a  larger  diagram.   The
graphics   system   handles   the  nested  coordinate  transformations
necessary to produce the levels of graphical object.

A significant feature of a segment is that it is created once and  may
then  be  mapped  (via additional transformations) any number of times
into different composition spaces.  An example of  a  segment  is  the
symbol  for  a  NAND gate.  This symbol need only be defined once.  It
can then be mapped any number of times to create  a  circuit  diagram.
Note  that  if  the  original  NAND  gate  symbol  is changed, all the
mappings of it automatically change.  Furthermore,  any  change  to  a
transformation  between  one  space  and  another  propagates into any
further mappings.  For example, if the  window  surrounding  the  NAND
gate  segment  is  made larger, the NAND gate will appear to shrink in
each viewport mapped to that window.  The graphics system handles  all
intermediate  levels  of  coordinate  transformation needed to map the
segments.

Segments may be copied rather than mapped, in  which  case  they  lose
their  reference to the original object.  Changes in the original will
not affect any copies made from it.

Segments may be returned as  the  result  of  a  pick  operation  (see
Pointing and Picking).



7.3  Virtual Display Composition

Since virtual displays are themselves composition spaces (see  Virtual
Displays),  they can be mapped onto other composition spaces.  This is
particularly useful when making a virtual display that is a  composite
of other virtual displays.  Such a composite display can be treated as
a single display for display management purposes, and yet each display
!
COMMON LISP Graphics Models                                    Page 13
COMPOSITION


can  retain  its  own identity for all other operations.  Some systems
call this a "pane" system with the final composite  display  called  a
"frame."



7.4  COMMON LISP Composition Levels

COMMON  LISP  should  allow  for  creation  of  arbitrary  levels   of
composition.  One that will be provided by default is:

      o  Virtual display space (allowing virtual displays to be mapped
         into the picture area of another virtual display)



8  ATTRIBUTES

Attributes are parameters that affect  the  visual  representation  of
output  operations.   They  can, for example, determine the background
color of a composition space, the width and pattern  of  a  line,  the
font  and  spacing  of  text,  or the visibility of a graphical object
mapped onto some composition space.

Some attributes are inherently "static" while  others  are  inherently
"dynamic."  When dynamic attributes are changed, the visual results of
previous  operations  that  used  those  attributes  will  immediately
change.  Operations done with static attributes must be re-executed in
order to change the visual appearance of their results.

Some attributes are naturally  associated  with  types  of  operations
(such as graphics primitives) while others are associated with objects
(such as composition  spaces).   Some  can  be  associated  with  both
objects  and operations.  For example, a composition space can have an
attribute that specifies the default color of all operations that take
place  within  it,  and an individual graphics operation can specify a
color attribute to override the default.

Attributes are also organized in blocks.  (GKS calls attribute  blocks
"bundles.")   Attribute  blocks  can  be  associated  with  individual
operations,  transformations,  or  composition  spaces.   Nesting   of
transformations implies some form of attribute nesting as well.



8.1  Attribute Descriptions

Attributes can be categorized by the type of operation or object  they
affect,   although   this   categorization   is  more  for  conceptual
convenience than  to  suggest  a  meaningful  difference  between  the
attributes.   The  following  is  a  suggested  list of categories for
COMMON LISP attributes:

     Composition space
!
COMMON LISP Graphics Models                                    Page 14
ATTRIBUTES


     Graphics
     Text

Attributes associated with a composition space  serve  two  functions:
they  describe  attributes  of  the composition space itself, and they
also provide a complete set of default attributes for any graphics  or
text   operations  done  into  that  space.   These  defaults  can  be
overridden by  attributes  applied  to  individual  graphics  or  text
operations.

The  following  possible  attributes  which  will  be  considered  for
inclusion  in  a  possible COMMON LISP graphics model are listed under
the categories described above.  These attributes are all described in
terms  of  bitmapped  terminals.   Some of the attributes may function
differently - or not function at all - on other  types  of  terminals,
such  as character terminals.  The specific behavior of each attribute
on various terminals is implementation-dependent.

      o  Composition Space  Attributes  -  the  first  two  attributes
         determine  characteristics  of  the composition space itself,
         while the second two establish defaults for graphics or  text
         operations done in the space.

          -  Visibility - specifies whether operations done into  this
             space  (when  it  is  mapped  into some other composition
             space) will be immediately visible or  deferred  until  a
             later time.

          -  Background Color - specifies the background color of  the
             composition space.

          -  Drawing Color - specifies the default color to be applied
             to all output operations into this space.

          -  Writing Mode - specifies the relationship applied  to  an
             output  operation  and  the  existing  bitmap  pattern to
             produce the resulting display rendition:

                  NIL - operation is performed (information is kept in
                  the  display  list)  but  the  output display is not
                  changed.

                  :XOR,  :OR,  :ORC1,  :AND,  :ANDC1  -  the   Boolean
                  operation  that  is applied to the bitmap pattern of
                  the operation and the  existing  bitmap  pattern  to
                  produce  the  displayed  result.   The C1 forms mean
                  that the bitmap produced by the operation  is  first
                  complemented   before   the   logical  operation  is
                  performed with the existing bitmap.

                  :REPLACE, :COMPLEMENT-REPLACE - the  result  of  the
                  operation  (or  its  complement) completely replaces
                  the affected contents of the display.
!
COMMON LISP Graphics Models                                    Page 15
ATTRIBUTES


                  :ERASE,  :COMPLEMENT-ERASE  -  the  result  of   the
                  operation is completely replaced with the background
                  color (or its complement) of the composition space

      o  Graphics  Attributes  -  these  attributes   are   associated
         specifically  with  graphics  operations.   They  can also be
         applied to a composition  space  to  determine  defaults  for
         graphics operations in that space.

          -  Line Width - specifies the  width  of  a  displayed  line
             expressed  as  a (floating-point) multiple of the minimum
             width that the device can draw.

          -  Line Style - specifies the particular visual style of the
             line  to  be drawn.  The following are suggested although
             implementations may vary in the types available:

                           :SOLID
                           :DASHED
                           :DOTTED
                           :DASHED-DOTTED


          -  Fill - specifies whether or not objects are to be filled,
             the fill pattern to use, and the fill reference point.

          -  Marker Symbol - specifies the visual symbol used  by  the
             graphics operations which place marker symbols at points.
             The symbol is centered on the specified point.   Supplied
             symbols are implementation dependent.

      o  Text   Attributes   -   these   attributes   are   associated
         specifically  with text operations.  They can also be applied
         to  a  composition  space  to  determine  defaults  for  text
         operations in that space.

          -  Font - specifies the font set to  be  used  when  writing
             text.  Values are implementation dependent.

          -  Character  Spacing  -  alters  the  normal   spacing   of
             character  writing.   This  attribute  is  expressed as a
             floating-point number that is multiplied by the character
             height to produce additional space to be inserted between
             characters.  The number can be negative,  in  which  case
             characters may be forced closer together or overlapped.

          -  Character Slant - slants fonts to produce  italics.   The
             slant  is expressed in degrees and should be in the range
             of -45 to +45.

          -  Base  Line  Angle  -  specifies  the  angle  of   writing
             characters.    This   attribute   is   expressed   as   a
             floating-point number representing  degrees  of  rotation
             from  the  normal  horizontal.  Unslanted characters will
!
COMMON LISP Graphics Models                                    Page 16
ATTRIBUTES


             always appear to be vertical when viewed  from  an  angle
             parallel to the base line.

          -  Text Path - specifies the direction of character  writing
             in  relation  to  the base line.  There are four possible
             values:

                  :FORWARD - this is the normal left-to-right  display
                  of  characters  in  a direction parallel to the base
                  line.

                  :BACKWARD - this is  the  reverse  of  the  :FORWARD
                  direction  and  is  used,  for example, when writing
                  Hebrew text.

                  :UP - characters are displayed sequentially  "above"
                  each other in relation to the base line.

                  :DOWN - the reverse of :UP; characters are displayed
                  sequentially  "below"  each other in relation to the
                  base line.


          -  Texture - a bitmap pattern which is logically ANDed  with
             a character bitmap before writing to the display.

An implementation is free to designate  supported  attributes  and  to
categorize any supported attributes as static or dynamic.



8.2  Attribute Inheritance

Every composition space has a default attribute block associated  with
it.   This  block  must  contain  a  complete specification of all the
supported  attributes  for  an  implementation.   In  general,   these
attributes may be overridden on a per-operation basis.

A set of operations into some composition space may be performed  with
respect  to some other attribute block.  This block may be incomplete.
Any required attribute values will be taken either  from  an  explicit
value in a specific operation or from the default attribute block.

Attribute  inheritance  in  the  presence  of   multiple   levels   of
composition  is not well understood.  Static attributes may be treated
easily since the visual results of a  performed  operation  cannot  be
changed  without  re-executing  the  operation.  Proper inheritance of
dynamic attributes, however, is more difficult to determine.  At  this
point,   the  inheritance  of  dynamic  attributes  is  implementation
dependent.
!
COMMON LISP Graphics Models                                    Page 17
VIRTUAL DISPLAYS


9  VIRTUAL DISPLAYS

A virtual display is a specialized graphical object  used  to  display
graphics  or  text  information  on a physical device.  It is the only
type of graphics object which can be displayed on a device.

A virtual display is made visible on a device by associating  it  with
that  device,  although  a  virtual  display  can  exist without being
associated with any device.  Associating  a  virtual  display  with  a
device  is  similar  to,  but  not  the  same operation as, creating a
mapping from one composition space to another.  A major difference  is
that  virtual  displays  are opaque; that is, the order of association
affects the visible result on the device.   If  two  virtual  displays
overlap on the screen, the portion of the first which is overlapped by
the second will not be  visible.   Normal  mappings  onto  composition
spaces  are  transparent,  that  is, all operations are always visible
(see Display Management).

Creation of a virtual display creates a composition space onto which a
number  of  graphical  objects are mapped.  These objects have default
spatial relationships which can be altered at  the  time  the  virtual
display  is created.  The following diagram illustrates the objects of
a virtual display in a typical configuration.  All objects except  the
picture area are optional.


     Banner  +--------------------------+
     area    |    Banner area           |
     origin->+--------------------------+
             ============================<--+
             =                          =   |
             = +----------------------+ =<--Borders
             = |                      | =
             = |    Picture area      | =
             = |                      | =
             = |                      | =
             = | Picture area         | =
             = | origin               | =
             = |/                     | <--Margins
             = +----------------------+ =  |
             =                          <--+
          +->+===========================
          |
     Virtual display origin


Each of the objects shown will be discussed in greater detail later in
this section.

The mapping of a virtual display's objects into its composition  space
produce  transformations  which  can  be  used  during I/O operations.
Additional arbitrary transformations into this composition  space  can
be created as needed.
!
COMMON LISP Graphics Models                                    Page 18
VIRTUAL DISPLAYS


To create a virtual display, one specifies the  size  of  its  picture
area  along  with  the  size  and spatial relationship of any optional
parts.  The total size of the virtual  display  is  the  size  of  the
picture area as extended by the optional parts.



9.1  Composition Space

The creation of a  virtual  display  results  in  the  creation  of  a
composition  space  within  which  the virtual display is built.  This
space may be used in all respects  as  any  other  composition  space;
users can do arbitrary graphical operations within it.



9.2  Picture Area

The picture area of a virtual display is the  rectangular  area  where
data is normally displayed.  It is a window-viewport pair which maps a
portion of application data space into the composition  space  of  the
virtual  display.  The size of the viewport is the size specified when
the virtual display was created.  By default, the window is  the  same
size  and  has  the  same coordinate system as the viewport; thus, the
transformation is trivial.  A different window may be  specified  when
the  display is created.  Unless otherwise specified, the picture area
viewport has a coordinate origin at the lower left corner and  a  size
expressed  in  virtual  display units (centimeters).  The picture area
has  a  transformation  object  which  may  be  used  as  the   active
transformation in any graphics operation.

The other objects of a virtual display are placed in a  fixed  spatial
relationship  to  the  sides of the picture area.  If the picture area
grows or shrinks, the margins, border, and banner  area  move  on  the
screen to maintain this relationship.



9.3  Banner Area

The banner area is an optional part  of  a  virtual  display.   It  is
similar to the picture area in that it is defined as a window-viewport
pair.  The  viewport  is  mapped  into  the  composition  space  in  a
particular  spatial  relation  to  the picture area.  It may be above,
below, or to the right or left of the picture area.  It  is  separated
from  the  picture area by the width of the margin and border.  Unless
otherwise specified, the banner area viewport has a coordinate  origin
at  the  lower  left corner.  Its width (or height if the banner is to
the right or left) is, by  default,  the  width  (or  height)  of  the
picture  area viewport plus the width of any margins and borders.  The
banner area has a transformation object  which  may  be  used  as  the
active transformation in any graphical operation.
!
COMMON LISP Graphics Models                                    Page 19
VIRTUAL DISPLAYS


9.4  Border

A virtual display may optionally have a  border.   The  border  is  an
outline  of  the  picture area, separated from the picture area by the
margins.  Its width is specified in virtual  display  units.   In  its
most  basic  form,  the  border  may  be  a line of some default width
surrounding the picture area.  If supporting hardware permits, it  may
have  an  arbitrary  thickness  and  tile  pattern (see Bitmaps).  The
border may be designated as a sensitive area for the pointing system.



9.5  Margin

The margin is the space between the border and the picture area; there
can  be  four  margins associated with a virtual display.  Its size is
measured in virtual display units.  The default size of any margin  is
implementation dependent.

Margins are  most  often  used  to  separate  text  from  the  border.
However,  some  set of implementation dependent operations may also be
performed in the margins of a  display,  such  as  drawing  lines  for
scroll  bars.   The  margins  lie outside the coordinate system of the
picture area; they must be accessed by using the coordinate system  of
the virtual display composition space.



9.6  Virtual Display Window

The entire rectangle encompassing the picture area, banner, border and
margins  of  a  virtual display is enclosed in a window in the virtual
display composition space.  This window may be used to map the display
onto a physical device or into some other composition space.  The size
of this window tracks the "size" of the virtual display, such that if,
for example, the picture area viewport is changed, the virtual display
window is automatically adjusted.



9.7  Device Viewport

A device viewport is a specification, in logical  device  coordinates,
of  the  size  and location of a virtual display on a physical device.
Unless otherwise specified, the size of a device viewport is the  same
size as the virtual display window.  The transformation is then a pure
translation.  An arbitrary transformation may be applied to scale  and
rotate the appearance of the virtual display on the screen.



9.8  LISP Terminal Streams To Virtual Devices

A virtual display may be used as an argument to the various  varieties
!
COMMON LISP Graphics Models                                    Page 20
VIRTUAL DISPLAYS


of MAKE-STREAM functions that exist in COMMON LISP.  Such a stream can
be input, output, or both.  A virtual display stream opened for output
means  that  printed  LISP  output  will  be  directed to that virtual
display.  An input stream designation means that a LISP read operation
on that stream will get input from the keyboard device attached to the
terminal.  An input-output stream reads characters from  the  keyboard
and  echoes those characters in that virtual display.  All designation
of font, spacing,  color,  etc.   is  specified  in  attribute  blocks
associated with that virtual display.

The physical device need not be  a  keyboard,  although  that  is  the
normal  device.   It may be any device capable of responding correctly
to the COMMON LISP input operations.  This allows, for example, a file
to  be associated with one display and the keyboard with another.  The
resulting effects on the screen (and to the program)  depend  only  on
the choice of virtual display used in the input operation.



9.9  Input Cursor

Each virtual display which has an associated virtual input device will
have   an  input  cursor  defined.   The  nature  of  this  cursor  is
implementation dependent but it must at least provide  an  indication,
when  this  display  is  being used for input, of the current location
where echoed input will appear.  This cursor is  often  distinct  from
the pointing (or mouse) cursor.



10  POINTING AND PICKING

In a virtual display and graphics environment, it is  often  necessary
to  translate a visually perceived location on the display device into
information  useful  to  the  running  program.   Operations  such  as
selecting  an  item from a menu, indicating a virtual display to bring
to the top of the stacking order, and selecting a gate connection in a
circuit diagram are all examples of pointing or picking.

Pointing and picking are input operations that require a certain level
of  physical device support.  The device must be capable of generating
a visual indicator (cursor) which indicates a screen position, and  it
must have a means of manipulating the position of this indicator.  The
manipulation need not be independent from  the  host  processor.   For
example, the arrow keys on a character-oriented terminal might be used
to request the host processor to move the cursor to different spots on
the  screen.   Other supporting devices can be various forms of mouse,
light pen, tablet and cross-hair.

The distinction between pointing and picking is in the nature  of  the
object  returned  as  a  result  of  the  operation.   The result of a
pointing operation is always an N-dimensional (usually 2)  coordinate.
The  result  of  a picking operation is a previously defined graphical
object.  This might be a simple object such as a line or it might be a
!
COMMON LISP Graphics Models                                    Page 21
POINTING AND PICKING


composition space which makes up a part of the display.

A pointing or picking operation is always performed  with  respect  to
some  transformation.  This transformation is used to specify both the
coordinate system in which the results are expressed and the level  of
detail  required of the operation.  For example, a pick might return a
particular mapping of a NAND gate symbol, the  NAND  gate  composition
space,  or  a portion of the NAND gate symbol, depending on the chosen
transformation.

Both pointing and picking are primarily input operations but may  also
involve  placement  of  the  position  cursor  using  the  appropriate
coordinate  system.   The  input  operations  are   completed   in   a
device-dependent  fashion, such as clicking a mouse button or pressing
a function key on the terminal.

Rectangular sections of the  screen  can  be  made  sensitive  to  the
pointing cursor.  Section 11.2 discusses this concept.



10.1  Pointing

Pointing is an input operation  that  returns  a  coordinate  in  some
N-dimensional  space.   The  space  must  be  previously defined.  For
example, the  coordinate  may  be  an  X-Y  pair  of  physical  device
coordinates.   It  may  also  be a coordinate in the master coordinate
system of some defined graphical object.



10.2  Picking

Picking is an  input  operation  that  returns  a  previously  defined
graphical  object.  Such an object might be an entire virtual display,
for instance, when selecting a display to bring  to  the  top  of  the
stacking  order.   It  might  also  be  some  component of a graphical
object, such as a point, a line, or a segment.



11  DISPLAY MANAGEMENT

"Display  management"  refers  to   the   facilities   available   for
controlling  the  appearance of the physical screen and making virtual
displays visible to the user.  Since virtual displays are opaque  when
placed  onto  a  physical  screen, they behave like cards stacked on a
table.  Portions of the screen that are covered by the rectangle of  a
virtual  display are not visible while that display is visible.  Thus,
a virtual display may hide (or "occlude") portions  of  other  virtual
displays  which  were  already  on the screen.  The display management
system must have the capability  to  place  virtual  displays  on  the
screen  and remove them from the screen.  The system must also be able
to move virtual displays on  the  screen  and  change  their  stacking
!
COMMON LISP Graphics Models                                    Page 22
DISPLAY MANAGEMENT


order.

Other display management capabilities  arise  from  the  necessity  to
provide  a  flexible  and  powerful user interface.  Since the display
system  should  have  some  type  of  pointing  device,  the   display
management  system must allow the programmer to define all or portions
of a virtual display as being sensitive to the pointing device.   This
means  the the user's software can detect whenever the pointing device
enters or leaves some selected area of a virtual display.  The  system
must  also provide for normal terminal I/O to be performed to and from
a virtual display.



11.1  Visibility And Stacking

A virtual display is a graphical object which may become visible on  a
terminal  screen.   It  can  exist  without  being associated with any
device or it may be associated with several devices simultaneously.

The display management system remembers the order  in  which  displays
are  associated with each device.  Associating several displays with a
device is called "stacking" since it is analogous to stacking up cards
on  a  flat surface; the order in which displays are associated with a
particular device  is  called  that  device's  "stacking  order."  The
position of a display in the stacking order can be altered.  It can be
brought to the top, pushed to the bottom, or  placed  above  or  below
another  virtual display in the stacking order.  If a display is moved
on the display screen, it  maintains  its  position  in  the  stacking
order.

The stacking order is important  to  the  appearance  of  the  screen,
because  it helps determine which displays can hide other displays.  A
virtual display is said to be "occluded"  on  some  device  if  it  is
beneath  another virtual display in the stacking order for that device
and if some or all of its area is within the screen area  occupied  by
the other virtual display.

A virtual display, in addition to being associated with a device,  may
also   be   "exposed"  (rendered  visible)  or  "unexposed"  (rendered
invisible) on that device.  In order  for  a  virtual  display  to  be
visible  to  the  user on some device, it must be associated with that
device, be exposed, and not be  entirely  occluded  by  other  exposed
virtual  displays.   A  display can be made invisible but preserve its
position in the stacking order by making it unexposed.  In this state,
it cannot occlude other virtual displays.

Exposure is a property of an element (virtual display) in a particular
stacking  order,  not  a  property  of the element itself.  Since each
display device has its own stacking order, a display may be associated
with more than one device but be exposed on only some of the devices.
!
COMMON LISP Graphics Models                                    Page 23
DISPLAY MANAGEMENT


11.2  Sensitive Regions

Rectangular areas of a virtual display may be made  sensitive  to  the
pointing  device.   A  sensitive  region is defined in virtual display
coordinates by specifying the lower left corner  and  the  height  and
width of the rectangle.

Designating a region as sensitive provides the programmer with several
capabilities for creating a user interface to the display system:

      o  The visual appearance of the sensitive region can be  altered
         either  automatically  when  the  pointing  device  enters or
         leaves the region,  or  under  program  control  without  the
         pointer moving at all.

      o  A LISP  function  can  be  invoked  asynchronously  when  the
         pointing device enters or leaves the region.

      o  The sensitive region can be returned as the result of a  user
         selection among a list of sensitive regions.



11.3  Menus

All display management systems should provide for a  special  type  of
virtual display called a "menu." There can be many types of menus, but
one kind should be provided with all Common LISP systems.  This  is  a
simple  choice  menu.   The  display  appears  as  a  vertical list of
options.  The pointing device is used to point to a desired  item  and
the  item  is  selected in an implementation-dependent fashion.  There
must be LISP functions which allow the programmer to create  the  menu
(providing both the selectable items and the value to be returned from
selection of each item) and to display the menu and query the user for
an  item  selection.   All  of  the usual display management functions
operate correctly on menus.



11.4  Pointer And Selection

Each implementation must provide a method for the user to "point" at a
particular location on the physical screen.  This might be implemented
with a mouse, light pen, cross hairs, or the cursor movement keys of a
simple  video  terminal.   This pointer should be able to indicate all
visible areas of the screen.

There must be a defined method of indicating  to  the  display  system
that  some  selection  has  been made relative to the pointing device.
The most common of these is the buttons on a mouse.  It  may  also  be
one or more special keys on the keyboard of the terminal device.  Each
implementation must define the number of selection  possibilities  and
the method for invoking each.
!
COMMON LISP Graphics Models                                    Page 24
DISPLAY MANAGEMENT


Each implementation must also provide some way of indicating that  the
pointing device has moved.



12  BITMAPS

Many video terminal devices operate by allocating  fixed-sized  blocks
of  display space (cells) for display of character and graphical data.
These  cells  are  individually  addressable  and  are  the   smallest
addressable  unit  from  the programmer's perspective.  Other graphics
devices  are  capable  of  doing  direct  vector  and  other   graphic
operations  on  the display.  Bitmapped terminals allow the programmer
to access individual pixels in the display directly.   The  method  of
access  is  to maintain a two-dimensional array of bits in memory that
directly controls the display of each pixel.  The array  is  called  a
bitmap.   All  operations to the terminal display are made by altering
the bitmap.

In any implementation that supports bitmapped  devices,  each  virtual
display  will have a bitmap and each device will have a device bitmap.
It will be possible to retrieve  all  or  portions  of  any  of  these
bitmaps  via  implementation-supplied  functions  as well as to create
bitmaps as  LISP  objects.   Functions  will  exist  to  do  arbitrary
operations  combining  bitmaps  (OR, AND, etc.).  These operations are
not clearly defined  at  this  time.   Suggestions  appreciated.   The
purpose of such bitmap operations is to provide special visual effects
such as shading and texturing.

∂09-Jan-85  1420	@MIT-MC:Henry%MIT-OZ@SCRC-RIVERSIDE 	Silence breaker   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 9 Jan 85  14:19:18 PST
Received: from MIT-APIARY-3 by MIT-OZ via Chaosnet; 9 Jan 85 17:17-EST
Date: Wed, 9 Jan 85 17:17 EST
From: Henry Lieberman <Henry%MIT-OZ@SCRC-RIVERSIDE.ARPA>
Subject: Silence breaker
To: Cl-Windows@SU-AI.ARPA, Cl-Object-Oriented-Programming@SU-AI.ARPA,
    Cl-Graphics@SU-AI.ARPA


As some of you may know, I am working on a kit for building menu-driven
graphical interfaces [such as document illustrators, circuit diagrammers,
etc.] called EzWin. The kit provides protocols for representing menu commands as
objects, mouse sensitivity and selection of graphical objects. It also tries to 
separate the functionality of commands from the interface techniques and allow
alternative interaction styles. It is at a level considerably above the "just
bits on the screen" one at which Boetje@Dec's proposal is aimed, but would be
complementary to such proposals. A wide range of interesting graphical interfaces
is easily specifiable using this approach. I hadn't designed it with a "language
standard" in mind, but perhaps standardizing things at this level as well might
productive, promoting portability of interfaces. 

I am currently preparing a paper on it for SigGraph '85. Interested people can
send me a message with US Mail address for a copy. It is too long for
transmission on this list and has many pictures.


∂20-Mar-85  2048	DDYER@USC-ISIB.ARPA 	ANSI windows  
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 20 Mar 85  20:48:16 PST
Date: 20 Mar 1985 20:44:48 PST
Subject: ANSI windows
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA


This tidbit is forwarded from WORKS digest

From: lef@nlm-vax.ARPA (Larry Fitzpatrick)
Subject: Alleged push for ANSI windows standard
Date: 5 Mar 85 23:28:58 GMT

Back in December, PC Week ran an article stating that several
companies(*) were banding together to push for a standard
"graphically oriented windowing environment". Standard, that is, for
the developer. My understanding (my need, in any case) is that this
would provide a basic functionality for manipulating windows, etc. so
that the developer of an application would not have to get involved
with the low-level screen manipulation.

I have heard of several packages that would act in this manner, some
of which are "coming soon" others which are out of reach(**, with the
possible exception of ALYS from Applix), none of which seem to come
close to being portable, let alone standard.

Does anyone know of:
    a) any activity in this area by the companies in *?
    b) any activity in this area by anyone not previously mentioned?


* - Microsoft, DRI, Intel, Apollo, Masscomp, Sun Micro Sys, Olivetti,
        Motorola, Nova Graphics

** - Apple's Toolkit-32; GEM; ALYS from Applix; W/X/V packages from
     groups at MIT and Stanford; does SunWindows fit the bill?; LOOPS?


        -fitz
        lef@nlm-vax

-------

∂20-Mar-85  2113	DDYER@USC-ISIB.ARPA 	ANSI windows (II)  
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 20 Mar 85  21:13:22 PST
Date: 20 Mar 1985 21:10:51 PST
Subject: ANSI windows (II)
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: cl-windows@SU-AI.ARPA


This information forwarded from WORKS digest


From: oblio!jon@topaz (Jon Steinhart)
Subject: Information on the ANSI windows work
Date: 9 Mar 85 22:41:01 GMT

ANSI X3H3 has formed a subgroup to investigate a possible window
standard.  The group is currently examining various proposals to
determine what areas a window standard would address.  The subgroup
chair is John Butler from Microsoft.

The best way to keep informed about the work on windows is to join
ANSI X3H3.  Contact Barry Shepherd at IBM in Austin.  Annual fees are
around $75.  Don't expect the committee to magically "meet your
needs" and "do the right thing" without your help and input.

                                        Jon Steinhart
                                        Counterpoint Computers, Inc.
                                        ANSI X3H3
-------

∂29-Jul-85  1235	Fischer.pa@Xerox.ARPA 	RE: Clearing the screen and other such things. 
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 29 Jul 85  12:34:34 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 29 JUL 85 12:33:27 PDT
Date: 29 Jul 85 12:30 PDT
From: Fischer.pa@Xerox.ARPA
Subject: RE: Clearing the screen and other such things.
To: Common-lisp@SU-AI.arpa
cc: CL-windows@SU-AI.arpa
Message-ID: <850729-123327-2607@Xerox>

Its pretty clear that the CL-Windows group became disheartened when it
was reported that ANSI was working on a standard.  This may not be the
case.  One can hope it was actually a mass defection to the ANSI group,
but I doubt that.

Perhaps now that the subjec thas been warmed up to, and since not much
seems to have solved the problem in the interim, perhaps we can get
someone to describe what the state of the various "standards committees"
are.

There were two mentioned just before the CL-Windows group closed its
shutters, one was a band of rowdy manufacturers (including Microsoft,
DRI, Intel, Apollo, Masscomp, Sun Micro Sys, Olivetti, Motorola, Nova
Graphics) the other of couse ANSI.

Can anyone comment immediately on the state of these committees to the
CL-windows@SU-AI.arpa mailing list?

(ron)

∂29-Jul-85  2307	DDYER@USC-ISIB.ARPA 	Clearing the screen etc.
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 29 Jul 85  23:07:02 PDT
Date: 29 Jul 1985 23:05:33 PDT
Subject: Clearing the screen etc.
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: common-lisp@SU-AI.ARPA
cc: cl-windows@SU-AI.ARPA


 Symbolics has adopted "window" in place of "screen" in its 
naming conventions.  I think this is the right thing, and is
superior to both "screen" and "terminal" except possibly in cases
where the display operation really does refer to a screen
or a terminal.


 Also, with respect to naming, let me plug my preference; rather
than add a lot of DO-THIS-OR-THAT functions, I'd rather add ONE
function, which encapsulates all screen operations.  I have in mind
the general form;

	(displayop <<displaystream>> <<operation>> &rest args)

 This general form permits all "window" operations to be
recognized trivially, permits generic and implementation specific
extensions, and permits both "flavorized" and "macroized"
implementations.  It also has the advantage of not polluting
the language with a lot more random function names.


 The CL-WINDOWS mailing list (which I theoretically moderate)
is pretty moribund, mainly from the inability to sustain a 
conversation.   I have a feeling that each of the CL 
implementations is pretty set in its own way of handling
displays, and the efficiency issues, combined with the 
extremely low-level nature of display drivers, make any
compromise agreement on "standards" for fully elaborated
displays unlikely.   As such, I support the idea of
chipping off this piece of the problem.


-------

∂30-Jul-85  0915	STENGER%ti-csl.csnet@csnet-relay.arpa 	Re: Clearing the screen etc.   
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 30 Jul 85  09:15:07 PDT
Received: from ti-csl by csnet-relay.csnet id aa16380; 30 Jul 85 12:07 EDT
Date: 30 Jul 1985 0938-CDT
From: Dan Stenger <STENGER%CSL60%ti-csl.csnet@csnet-relay.arpa>
Subject: Re: Clearing the screen etc.
To: cl-windows@su-ai.ARPA
In-Reply-To: Your message of 29-Jul-85 2305-CDT
Received: from csl60 by ti-csl; Tue, 30 Jul 85 10:01 CST

	Date: 29 Jul 1985 23:05:33 PDT
	Subject: Clearing the screen etc.
	From: Dave Dyer <DDYER@USC-ISIB>
	To: common-lisp@SU-AI
	cc: cl-windows@SU-AI


	 Symbolics has adopted "window" in place of "screen" in its
	naming conventions.  I think this is the right thing, and is
	superior to both "screen" and "terminal" except possibly in cases
	where the display operation really does refer to a screen
	or a terminal.

I agree with this.  I think the term "window" is well accepted in the
lisp community and we should not try to change the consensus.


	 Also, with respect to naming, let me plug my preference; rather
	than add a lot of DO-THIS-OR-THAT functions, I'd rather add ONE
	function, which encapsulates all screen operations.  I have in mind
	the general form;

		(displayop <<displaystream>> <<operation>> &rest args)

	 This general form permits all "window" operations to be
	recognized trivially, permits generic and implementation specific
	extensions, and permits both "flavorized" and "macroized"
	implementations.  It also has the advantage of not polluting
	the language with a lot more random function names.

I don't think I agree with this totally.  I think that windows should
be compatible with streams (maybe even a subtype of stream) and this
naming scheme doesn't fit with the currently defined stream functions.
(I would like to hear how others feel about windows as streams.)
Also I feel that we should maintain the current naming conventions
such as MAKE-WINDOW for creating a new window.  If structures are used
for implementation of windows the automatically generated functions
would all need renaming in some way.  However I do agree with your
goal of limiting the addition of a bunch of new function names.


	 The CL-WINDOWS mailing list (which I theoretically moderate)
	is pretty moribund, mainly from the inability to sustain a
	conversation.   I have a feeling that each of the CL
	implementations is pretty set in its own way of handling
	displays, and the efficiency issues, combined with the
	extremely low-level nature of display drivers, make any
	compromise agreement on "standards" for fully elaborated
	displays unlikely.   As such, I support the idea of
	chipping off this piece of the problem.

I guess I'm not quite as pessimistic.  Agreeing on a standard for the
Lisp language was probably an even tougher job.  Also after the
agreement was reached companies with existing Lisp implementations
(such as Symbolics) went to a lot of trouble and probably even
sacrificed some performance to support the standard.  I know that TI
would be willing to support a reasonable Common Lisp window standard.

		Dan Stenger


-------

∂17-Dec-85  2157	sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA 
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 17 Dec 85  21:38:11 PST
Received: from tektronix by csnet-relay.csnet id ag21296; 17 Dec 85 21:43 EST
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
To: cl-windows@su-ai.ARPA, cl-graphics@su-ai.ARPA
Received: from tekchips by tektronix with smtp ; 17 Dec 85 15:26:20 PST
Date: Tuesday, 17 Dec 85 15:16:03 PST


 PL add me to your mailing list.

sridhar%tekchips@tektronix.csnet

∂16-Dec-86  1905	RICHER@SUMEX-AIM.STANFORD.EDU 	CL-WINDOWS mailing list 
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Dec 86  18:57:41 PST
Date: Tue 16 Dec 86 18:54:34-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: CL-WINDOWS mailing list
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12263390243.65.RICHER@SUMEX-AIM.STANFORD.EDU>

You are receiving this message because you are on one of two
distribution lists, soon to be merged. The first list is
CL-WINDOWS@SU-AI.ARPA which began in Fall 1984.  I think this list was
started to discuss a Commonlisp Window Standard. Ignorant of this
list, but interested in a Commonlisp Window Standard, and more recently, 
Commonlisp implementations (on lisp machines) or interfaces (on Unix
workstations) of/to X and NeWS (servers), with application programmer
libraries done in an object-oriented language (eventually something that is
compatible with the sometime-to-come CL object standard, supposedly
some variant of Commonloops), I set out to find other interested
individuals.  There seems to be enough interest in these topics to
warrant a discussion list, but it seems appropriate to merge with the
existing CL-WINDOWS list.  Because Dick Gabriel, the maintainer of the
CL-WINDOWS list agreed to this arrangement and in particular, felt
that discussion of lisp window systems related to the X, NeWS, and
Commonloops "standards" was appropriate on CL-WINDOWS, I am forwarding
the list of addresses I have recently collected to Dick and he will
add them to his list.  Note that there have been no messages on the
list that I was thinking of starting.  However, there have been messages on
CL-WINDOWS dating back to two years ago.  (Below is a description of
CL-WINDOWS when it started.)  I FTPED the archives from SAIL (=SU-AI)
and there are quite a few messages from the past.  However, the last
message I found was Dec. 1985?  I don't know if that is really the
last message or not?  Anyhow, please contribute something stimulating and
intelligent wrt to these issues.  If you do not want to be on this
list, (so sorry), and if you think I'm the culprit, then send me a
message and I'll forward to Dick.  By the way there are other related
lists of possible interest:

xpert@athena.mit.edu
xport@athena.mit.edu
news-makers@brillig.umd.edu
cl-graphics@su-ai.arpa
common-lisp@su-ai.arpa
commonloops.pa@xerox.com

In each case, add -request and mail a request to get on (e.g.,
xpert-request@athena.mit.edu)
I do not maintain or moderate any of these lists.
Dick will maintain the CL-WINDOWS mailing list, but messages are not
filtered or digested at this point in time.

By the way I would suggest that places like Xerox and Symbolics which
have multiple addresses even on my list, set up a local redistribution
list.  If someone can do that, forward the information to
cl-windows-request@su-ai.arpa.

-----------------------------------------------------------------------------

First message in Cl-WINDOWS, Fall 1984 

			Introduction
Welcome to the Common Lisp Window Subgroup.
In order to mail to this group, send to the address:

		CL-Windows@su-ai.arpa

Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:

			   CLWIND.MSG[COM,LSP]

You can read this file or FTP it away without logging in to SAIL.

To communicate with the moderator, send to the address:

		CL-Windows-request@su-ai.arpa
-------

∂16-Dec-86  2254	RICHER@SUMEX-AIM.STANFORD.EDU 	purpose of mailing list 
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Dec 86  22:54:05 PST
Date: Tue 16 Dec 86 19:55:48-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: purpose of mailing list
To: "CLW:": ;
cc: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12263401391.16.RICHER@SUMEX-AIM.STANFORD.EDU>

I'm sorry if I haven't clarifed things well, and in case I didn't
I better make sure now before we merge the lists.  My feeling was
that a lot of people interested in some combination of X/NEWS, Commonlisp,
COmmonloops are interested in sharing information, and maybe even
code with regard to what they are doing with these things. This is 
different than the initial focus of CL-WINDOWS which was trying to iron
out a standard. I'm happy to see the info kind of list I envisioned
merged with the CL-WINDOWS "standards discussion" list, but I think we
need to make sure that's really a good idea in most people's minds.
Because the CL-WINDOWS messages seemed to have come to halt unless I
am mistaken, it sounds like some discussion about what people are
actually doing isn't a bad idea.  But that means some detailed messages
perhaps about implementation related stuff being mixed with high-level
discussion about standards.  If you think this marriage is a bad idea,
speak up now ... you should probably reply ONLY to me in most cases
since a lot of people might not care one way or the other.

Mark
-------

∂17-Dec-86  0556	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	X server implementors? 
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 86  05:56:20 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Dec 86 08:52-EST
Date: Wed, 17 Dec 86 08:50 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X server implementors?
To: xport@ATHENA.MIT.EDU, xpert@ATHENA.MIT.EDU,
    cl-windows@SAIL.STANFORD.EDU
Message-ID: <861217085012.9.RWS@KILLINGTON.LCS.MIT.EDU>

If there is anyone out there contemplating implementing an X V11 server
in a language other than C, or as multiple processes, and is willing
to admit it (at least privately to me), I would like to talk with you.

∂17-Dec-86  2251	RICHER@SUMEX-AIM.STANFORD.EDU 	a bunch of messages on X/News & Commonlisp  
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 86  22:51:23 PST
Date: Wed 17 Dec 86 17:54:24-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: a bunch of messages on X/News & Commonlisp
To: "CLW:": ;
cc: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12263641434.77.RICHER@SUMEX-AIM.STANFORD.EDU>

The messages below were received as responses to one of two enquires:
(1) information on people using X, PCL, HP-CL, and GNU emacs on HP bobcats,
(2) query to people on xpert, common-lisp, and commonloops mailing list
about their interest and activites regarding Commonlisp/Commonloops
window systems interfaced to X (or NeWS). 

I have only included responses that might be of general interest; mostly
explaining what people are doing.  You might be interested to know that
the responses I have received including the just "add-me-to-the list" ones
not printed below include people using all sorts of hardware at all sorts
of places.  

15-Nov-86 07:01:52-PST,1200;000000000001
Return-Path: <carter%silicon@utah-cs.arpa>
Received: from utah-cs.ARPA by SUMEX-AIM.ARPA with TCP; Sat 15 Nov 86 07:01:50-PST
Received: by utah-cs.ARPA (5.31/4.40.2)
	id AA03585; Sat, 15 Nov 86 08:03:18 MST
Received: by silicon.ARPA (4.30/4.40.2)
	id AA01102; Sat, 15 Nov 86 08:10:36 mst
Date: Sat, 15 Nov 86 08:10:36 mst
From: carter%silicon@utah-cs.arpa (Tony M. Carter)
Message-Id: <8611151510.AA01102@silicon.ARPA>
To: richer@sumex-aim.arpa
Subject: X and CommonLisp
Cc: hucka@utah-cs.arpa, kessler%orion@utah-cs.arpa

We currently use hp-cl running as a subshell under gnu and are having good
success --- it is MUCH less painful than using NMODE.  We are also in the
process of interfacing to the X library so that cl can handle windows, etc.

Some students are undertaking a project to construct a user-interface package
with mouse-sensitive objects.  Unfortunately, we don't have CommonLoops yet,
so we are implementing on top of a local package we call frobs (frame objects)
which will permit us to do intelligent reasoning about objects as well.  We
believe that frobs can be brought up on top of CommonLoops when it becomes
available.
Tony Carter (carter@utah-cs)
 15-Nov-86 13:22:13-PST,1203;000000000001
Return-Path: <kessler%utah-orion@utah-cs.arpa>
Received: from utah-cs.ARPA by SUMEX-AIM.ARPA with TCP; Sat 15 Nov 86 13:22:11-PST
Received: by utah-cs.ARPA (5.31/4.40.2)
	id AA12899; Sat, 15 Nov 86 14:23:44 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
	id AA26810; Sat, 15 Nov 86 14:23:41 MST
Date: Sat, 15 Nov 86 14:23:41 MST
From: kessler%utah-orion@utah-cs.arpa (Robert Kessler)
Message-Id: <8611152123.AA26810@utah-orion.ARPA>
To: RICHER@sumex-aim.arpa
Subject: X, GNU, and HPCL

That is exactly the configuration that we are running on most of our systems.
We usually run GNU with HPCL in GNU window and other windows with shells and
RLOGIN's to various machines.  It works quite well.  We also have a project
developing an combined objects and frame system called (FROBS).  A group is
interfacing X window operations to FROBS.

Anyway, we have a new shell.el that makes gnu run the HPCL with gnu better.
Also, we have made a number of hacks to X to fix them (you might have seen
the messages).  If you want further information, contact thomas@utah-gr.arpa
for X information, stoller@utah-orion.arpa for GNU information and maybe
mjb@utah-orion.arpa for HPCL help.

Bob.
 16-Nov-86 10:51:14-PST,957;000000000001
Return-Path: <hearn%hilbert@rand-unix.ARPA>
Received: from rand-unix.ARPA by SUMEX-AIM.ARPA with TCP; Sun 16 Nov 86 10:51:09-PST
Received: from hilbert.arpa (hilbert) by rand-unix.ARPA; Sun, 16 Nov 86 09:33:17 pst
Received: by hilbert.arpa; Sun, 16 Nov 86 09:26:50 pst
From: Tony Hearn <hearn%hilbert@rand-unix.ARPA>
Message-Id: <8611161726.AA00250@hilbert.arpa>
To: Mark Richer <RICHER@sumex-aim.arpa>
Cc: hpai%hilbert@rand-unix.ARPA
Subject: Re: X and Commonlisp
In-Reply-To: Your message of Fri 14 Nov 86 14:05:56-PST.
             <12254949090.12.RICHER@SUMEX-AIM.ARPA>
Date: Sun, 16 Nov 86 09:26:47 PST

We'd certainly like to share such information with you. As a matter of fact,
we are using PSL for most of our research rather than Common LISP, but the
X - GNU - lisp model remains the same.

If you make up a mailing list, add "hpai%hilbert@rand-unix.arpa" to it.
That reaches all interested parties here.

Thanks,
Tony Hearn
20-Nov-86 14:19:42-PST,925;000000000001
Return-Path: <sundar@hermes.ai.mit.edu>
Received: from hermes.ai.mit.edu by SUMEX-AIM.ARPA with TCP; Thu 20 Nov 86 14:19:29-PST
Received: by hermes.ai.mit.edu; Thu, 20 Nov 86 17:19:38 EST
Date: Thu, 20 Nov 86 17:19:38 EST
From: sundar@hermes.ai.mit.edu (Sundar Narasimhan)
Message-Id: <8611202219.AA05039@hermes.ai.mit.edu>
To: RICHER@sumex-aim.arpa
In-Reply-To: Mark Richer's message of Thu 20 Nov 86 11:57:55-PST
Subject: X and lisp graphics

Hi:
I would be grateful if you could forward to me any replies you get in
response to your query of integrating X and Lisp graphics. I started
on something like this some time ago, but have had to shelve it for a
while owing to other time constraints. What I have working is an
interface between X and Lucid lisp using Lucid's foreign call
interface but with a layer of flavors inbetween. I plan to finish it
sometime when I get the time to do it. 

-Sundar. 
20-Nov-86 15:24:28-PST,783;000000000001
Return-Path: <chris@columbia.edu>
Received: from columbia.edu by SUMEX-AIM.ARPA with TCP; Thu 20 Nov 86 15:24:23-PST
Received: by columbia.edu (5.54/1.14) 
	id AA02942; Thu, 20 Nov 86 18:25:19 EST
Date: Thu, 20 Nov 86 18:25:19 EST
From: Chris Maio <chris@columbia.edu>
Message-Id: <8611202325.AA02942@columbia.edu>
To: richer@sumex-aim.arpa
In-Reply-To: Mark Richer's message of Thu 20 Nov 86 11:57:55-PST
Subject: X and lisp graphics

Mark,

  I'm glad to hear about the Utah effort to add X compatibility to the HP
Common Lisp, since I'm interested in doing the same thing for NeWS on the
Bobcat.  I have no idea at this point whether we'll get beta-test status for
NeWS or how much help HP will provide us, but I'll let you know if I get
anywhere.
							Chris
21-Nov-86 11:48:04-PST,1640;000000000001
Return-Path: <tsf@theory.cs.cmu.edu>
Received: from THEORY.CS.CMU.EDU by SUMEX-AIM.ARPA with TCP; Fri 21 Nov 86 11:47:57-PST
Date: Friday, 21 November 1986 14:48:01 EST
From: Timothy.Freeman@theory.cs.cmu.edu
To: Mark Richer <RICHER@sumex-aim.arpa>
Subject: Re: X and lisp graphics
Message-ID: <1986.11.21.18.58.41.Timothy.Freeman@theory.cs.cmu.edu>
In-Reply-To: <12256498649.76.RICHER@SUMEX-AIM.ARPA>

We have some code that uses X from Lucid (er, Sun) Lisp.  However, it
only does characters, lines, and rectangles.  It was written to be
downward compatible with another equally anemic, poorly-written piece
of code that ran on another machine.  I can send it to you if you
want, but you should definitely use it as an example of working code
instead of as a foundation for code that you actually intend to use
for a long time.

I discovered documentation for X in the subdirectory doc of the X
distribution.  It describes what routines to call from C to pop up
windows, draw lines, characters, and so forth.  To get things other
than boring text from xterm, you have to deal with X directly.  I will
mail you the documentation too, if you want, but you are probably
better off getting it directly from MIT.

If you do get a nice piece of code up and running, I would certainly
be interested in seeing it.

There has been some work on defining a standard graphics interface for
common lisp.  You may want to post to the common lisp mailing list
asking for information about that sort of thing so you don't wind up
reinventing the wheel in such a way that your wheels are incompatible
with everyone else's.
 9-Dec-86 17:25:48-PST,556;000000000001
Return-Path: <klee@ads.ARPA>
Received: from grape.ads.ARPA (ADS.ARPA.#Internet) by SUMEX-AIM.ARPA with TCP; Tue 9 Dec 86 17:25:45-PST
Date: Tue, 9 Dec 86 17:24:30 pst
From: klee@ads.ARPA (Ken Lee)
To: richer@sumex-aim.arpa
Subject: Re: X window system

Mark,
I am interested in CommonLisp interfaces to SunNEWS.  Please add me
to your mailing lisp.  I am doing applied research in the area of 
object-oriented (flavors) interactive graphics tools for user interfaces
to LISP AI systems.

Ken Lee
Advanced Decision Systems
Mountain View, CA
 9-Dec-86 19:31:38-PST,1627;000000000001
Return-Path: <FAHLMAN@C.CS.CMU.EDU>
Received: from C.CS.CMU.EDU by SUMEX-AIM.ARPA with TCP; Tue 9 Dec 86 19:31:30-PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 9 Dec 86 22:33:45-EST
Date: Tue, 9 Dec 1986  22:33 EST
Message-ID: <FAHLMAN.12261562345.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Mark Richer <RICHER@SUMEX-AIM.ARPA>
Cc:   slisp@C.CS.CMU.EDU
Subject: X window system
In-reply-to: Msg of 9 Dec 1986  19:03-EST from Mark Richer <RICHER at SUMEX-AIM.ARPA>

Mark,

It looks like the standard workstation configuration around CMU is going
to be the Mach operating system, X, and Common Lisp -- our own Common
Lisp on the IBM RT's, and Lucid's Common Lisp on the microVaxen and
Suns.  We will be developing a Common Lisp to X interface for our own
use, and would like to participate in any discussions leading toward the
standardization of this interface.

The whole Spice Lisp group here will be involved in this in one way or
another, so for now it is probably best just to add "slisp@c.cs.cmu.edu"
to your mailing list.  If this becomes unwieldy, we'll change the
arrangements later.

We're probably not as far along in our knowledge of X as other groups --
we only received a version of X for the IBM RT this week, and don't yet
have it running under Mach.  We do have some experience in building
hairy Common Lisp interfaces to other things, however.

Thanks for taking the initiative in setting this up.  The sooner people
start talking, the less has to be undone in order to make everyone's
system compatible.

-- Scott
 9-Dec-86 21:57:03-PST,726;000000000001
Return-Path: <ehl%cogsci.Berkeley.EDU@BERKELEY.EDU>
Received: from cogsci.berkeley.edu ([128.32.130.5].#Internet) by SUMEX-AIM.ARPA with TCP; Tue 9 Dec 86 21:56:50-PST
Received: by cogsci.berkeley.edu (5.57/1.17)
	id AA22770; Tue, 9 Dec 86 21:57:39 PST
Date: Tue, 9 Dec 86 21:57:39 PST
From: ehl%cogsci.Berkeley.EDU@berkeley.edu (Edward H. Lay)
Message-Id: <8612100557.AA22770@cogsci.berkeley.edu>
To: richer@sumex-aim.stanford.edu
Subject: X & PCL

I am interested in being on your mailing list about X and PCL etc.
I am currently involved in porting the Boxer System to a Sun running 
Common Lisp, PCL and possible X (we are still evaluating different 
window systems.)

edward lay (ehl@cogsci.berkeley.edu)
10-Dec-86 08:24:27-PST,845;000000000001
Return-Path: <cagan%hplmrc@hplabs.HP.COM>
Received: from hplabs.HP.COM by SUMEX-AIM.ARPA with TCP; Wed 10 Dec 86 08:24:11-PST
Received: from hplms1 by hplabs.HP.COM ; Wed, 10 Dec 86 07:44:08 pst
Received: from hplmrc (hplmrc) by hplms1; Wed, 10 Dec 86 07:43:50 pst
Return-Path: <cagan@hplmrc>
Received: from hplmrc by hplmrc ; Wed, 10 Dec 86 07:43:20 pst
Message-Id: <8612101543.AA08480@hplmrc>
To: richer@sumex-aim.ARPA
X-Mailer: mh
Subject: CommonLisp/X Mailing List
Date: Wed, 10 Dec 86 07:42:06 PST
From: Marty Cagan <cagan%hplmrc@hplabs.HP.COM>


Mark,

We've implemented both a CL interface to Xlib, and a Common Objects
interface to the Xray lib.  We've also been experimenting with 
a CommonLoops (Classes) interface to Xlib.  Can you put me on the
new mailing list please?

Thanks,

Marty Cagan (cagan@hplabs)
 10-Dec-86 08:50:54-PST,677;000000000003
Return-Path: <rfb@h.cs.cmu.edu>
Received: from H.CS.CMU.EDU by SUMEX-AIM.ARPA with TCP; Wed 10 Dec 86 08:50:50-PST
Date: 10 Dec 1986 11:08-EST 
From: Rick.Busdiecker@h.cs.cmu.edu
To: Mark Richer <RICHER@SUMEX-AIM.ARPA>
Subject: Re: Windows in COmmonloops?
Message-Id: <534614920/rfb@h.cs.cmu.edu>
In-Reply-To: Mark Richer's mail message of Tue, 9 Dec 86 16:08:12 PST

I'm developing a customizable graphics editor in CommonLoops.  Once the
SpiceLisp (now CMU CommonLisp) hooks to X are made (real soon) I will
be including X as one of the window managers that I support.  It should
become the primary window manager for my development work before long.

			Rick
 10-Dec-86 21:12:03-PST,766;000000000001
Return-Path: <Rao.pa@Xerox.COM>
Received: from Xerox.COM by SUMEX-AIM.ARPA with TCP; Wed 10 Dec 86 21:11:55-PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 DEC 86 19:16:01 PST
Date: 10 Dec 86 19:15 PST
Sender: Rao.pa@Xerox.COM
To: RICHER@SUMEX-AIM.ARPA 
From: RAO.pa@Xerox.COM 
Subject: Re: Windows in COmmonloops? 
Message-ID: <861210-191601-5020@Xerox>

Message type: Message
Topic:  
Text: 
Re: Message of Tue, 9 Dec 86 16:08:12 PST from Mark Richer
<RICHER@SUMEX-AIM.ARPA>


I'm doing my masters thesis  at MIT on building a window system in
CommonLoops for Xerox Commonlisp.  One of my goals is to be able to
build X easily on top of this window system.  

Please add me to your distribution list.

ramana
rao.pa@xerox.com
 15-Dec-86 12:15:18-PST,1299;000000000001
Return-Path: <cerys@XX.LCS.MIT.EDU>
Received: from XX.LCS.MIT.EDU by SUMEX-AIM.ARPA with TCP; Mon 15 Dec 86 12:14:32-PST
Received: from RTS-12.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Dec 86 15:18-EST
REPLY-TO:       cerys@XX
FCC:            vx:/usr/cerys/outgoing-mail
FROM:           Dan Cerys <cerys@XX>
TO:             Mark Richer <RICHER@SUMEX-AIM.ARPA>
SUBJECT:        Re: X window system
DATE:           15-Dec-86 15:15:58
SENDER:         cerys@XX
MESSAGE-ID:     <cerys.2744050557@RTS-12>

Please add me to this list.   Bob Scheifler has already done a V10 X
windows implementation for LISPM's.  I've been talking to him about an
implementation for V11 of X windows on Explorers and Symbolics.

Dan
16-Dec-86 11:42:44-PST,811;000000000001
Return-Path: <lowry%bizet.DEC@decwrl.DEC.COM>
Received: from decwrl.dec.com by SUMEX-AIM.STANFORD.EDU with TCP; Tue 16 Dec 86 11:42:34-PST
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
	id AA20897; Tue, 16 Dec 86 11:45:26 PST
Message-Id: <8612161945.AA20897@decwrl.dec.com>
Date: Tuesday, 16 Dec 1986 11:39:20-PST
From: lowry%bizet.DEC@decwrl.DEC.COM  (DAVID LOWRY 225-6290 BIZET::LOWRY)
To: richer@sumex-aim.ARPA
Subject: X window system

	Hi, I'm writing the X window routines that will be included in
the next release of Vax Lisp.  I would like to be put on your mailing
list for the common lisp X window distribution.

Who am I?

David Lowry

lowry%bach.dec@decwrl.dec.com

Digital Equipment Corporation
77 Reed Road  HL02-3/C10
Hudson, MA 01749

Many Thanks.
 DDL


    


17-Dec-86 06:07:47-PST,829;000000000001
Return-Path: <@SAIL.STANFORD.EDU:RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU>
Received: from SAIL.STANFORD.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Wed 17 Dec 86 06:07:46-PST
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 86  05:56:20 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Dec 86 08:52-EST
Date: Wed, 17 Dec 86 08:50 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X server implementors?
To: xport@ATHENA.MIT.EDU, xpert@ATHENA.MIT.EDU,
    cl-windows@SAIL.STANFORD.EDU
Message-ID: <861217085012.9.RWS@KILLINGTON.LCS.MIT.EDU>

If there is anyone out there contemplating implementing an X V11 server
in a language other than C, or as multiple processes, and is willing
to admit it (at least privately to me), I would like to talk with you.

-------

∂26-Dec-86  1428	RICHER@SUMEX-AIM.STANFORD.EDU 	[Ralph R. Swick <swick@ATHENA.MIT.EDU>: User Interface Toolkit proposal]  
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Dec 86  14:27:53 PST
Date: Fri 26 Dec 86 14:27:42-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: [Ralph R. Swick <swick@ATHENA.MIT.EDU>: User Interface Toolkit proposal]
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12265963100.15.RICHER@SUMEX-AIM.STANFORD.EDU>

If you are on the xpert mailing list you have seen the message forwarded
below.  I am forwarding to cl-windows because I believe any proposed
user interface toolkit for X might be of interest to readers here
(that are not on xpert) and particularly because it can impact lisp
window systems to the degree that they support or are interfaced to X.  

                ---------------

Return-Path: <swick@ATHENA.MIT.EDU>
Received: from ATHENA by SUMEX-AIM.STANFORD.EDU with TCP; Wed 24 Dec 86 09:29:56-PST
Received: by ATHENA (5.45/4.7)
	id AA27342; Wed, 24 Dec 86 11:55:44 EST
Received: by LYRE (5.45/4.7)
	id AA16343; Wed, 24 Dec 86 11:55:14 EST
Message-Id: <8612241655.AA16343@LYRE>
To: xpert
Subject: User Interface Toolkit proposal
Date: Wed, 24 Dec 86 11:55:02 -0500
From: Ralph R. Swick <swick@ATHENA.MIT.EDU>

A draft proposal for a user interface toolkit is available for ftp in
the pub directory on zap.mit.edu [18.72.0.126].

This document has resulted from an intensive effort on the part of
Digital Equipment Corporation and Hewlett-Packard Company to merge the
better features of the toolkits in the X.V10R4 distribution and
extract a common foundation upon which a variety of application
environments may be built.  Their stated goal is to provide the next
higher level of common (portable) interfaces above Xlib.

M.I.T. has a goal to have available at least a preliminary version of
a user interface toolkit and one or more application environments (UIMS)
to be distributed with the first general distribution of X version 11.

The document "X Toolkit, A Proposed Architecture" is distributed for your
comment and to let you know one of the directions in which we are headed.
If we are to achieve the availability date as stated, the period during
which comments can be expected to have major impact on the implementation
is unfortunately very short.  We do, however, invite those comments.

The list of individual contributors to this draft is already very long;
a future revision of a specification will give them the recognition
they deserve.

I hope that applications developers who need to use one of the
applications environments distributed with X version 10 release 4 will be
able to use this draft proposal to prioritize and partition their
development effort.



					Ralph R. Swick
					M.I.T. Project Athena
					Swick@Athena.MIT.EDU
-------

∂26-Dec-86  1437	RICHER@SUMEX-AIM.STANFORD.EDU 	[kddlab!elis03@vc.sra.junet (Ken Seo): x-window in lisp]   
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Dec 86  14:37:14 PST
Date: Fri 26 Dec 86 14:37:00-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: [kddlab!elis03@vc.sra.junet (Ken Seo): x-window in lisp]
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12265964795.15.RICHER@SUMEX-AIM.STANFORD.EDU>

Those of you on xpert will probably vote to have me shot but here is
another forwarded message (I think the xpert msgs. of interest to cl-windows
will be very small in number so bear with this please):
                ---------------

Return-Path: <kddlab!titcca!vc!elis03@titcca.cc.titech.junet>
Received: from ATHENA by SUMEX-AIM.STANFORD.EDU with TCP; Fri 26 Dec 86 00:18:34-PST
Received: by ATHENA (5.45/4.7)
	id AA06733; Fri, 26 Dec 86 02:33:11 EST
Received: from kddlab.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP 
	id AA14489; Fri, 26 Dec 86 02:31:42 EST
Received:  by kddlabs.junet ; Thu, 25 Dec 86 21:40:15+0900 
Received:  by kddlabs.junet ; Thu, 25 Dec 86 21:40:07+0900 
Received: by titcca.cc.titech.junet (4.12/6.2Junet)
	id AA23323; Thu, 25 Dec 86 09:27:22 jst
Received: from vc.sra.junet by srava.sra.junet (4.13/6.2Junet)
	id AA16646; Thu, 25 Dec 86 09:08:56 jst
Received: by vc.sra.junet (4.13/6.1Junet)
	id AA05683; Thu, 25 Dec 86 09:07:39 jst
Date: Thu, 25 Dec 86 09:07:39 jst
From: kddlab!elis03@vc.sra.junet (Ken Seo)
Return-Path: <elis03@vc.sra.junet>
Message-Id: <8612250007.AA05683@vc.sra.junet>
To: kddlabs!xpert%athena.mit.edu@seismo.CSS.GOV
Subject: x-window in lisp

						Dec. 25,1986


	To whom it may concern,

	In August of 1986, Jim Gettys posted the proposed revisions for
 	version 11 of X window on the net.  I got it through the University
	of Tokyo relay (here in Japan).

 	In the prologue, he added the fact that a lisp version of
 	X window would be finished in March of 1987.

	I would like to know the present status of the lisp version of
 	X window.  Also, which lisp dialog it is being written in.

	Please send your answers to the following address;

		elis03@sravc.sra.junet (via the u-tokyo.junet relay)

	Thank you very much.

						Yours truly,
						Harlan Seo

						address:
							c/o SRA
							Hirakawacho 1-1-1
							Chiyoda-ku, Tokyo
							Japan	105

						Tel:    (03)234-2623

						e-mail: elis03@sravc.sra.junet

-------

∂26-Dec-86  1753	gabriel@vaxa.isi.edu 	cl-windows mailing list
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 26 Dec 86  17:53:13 PST
Received: by vaxa.isi.edu (4.12/4.7)
	id AA05858; Fri, 26 Dec 86 17:39:34 pst
From: gabriel@vaxa.isi.edu (Gabriel Robins)
Message-Id: <8612270139.AA05858@vaxa.isi.edu>
Date: 26 Dec 1986 1739-PST (Friday)
To: cl-windows@sail.stanford.edu
Subject: cl-windows mailing list


Please add me to the list.  Thanks,

Gabe

∂27-Dec-86  0958	ho@ucbarpa.Berkeley.EDU 	CL-windows
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 27 Dec 86  09:58:24 PST
Received: by ucbarpa.Berkeley.EDU (5.57/1.18)
	id AA06079; Sat, 27 Dec 86 09:58:46 PST
Date: Sat, 27 Dec 86 09:58:46 PST
From: ho@ucbarpa.Berkeley.EDU (Kinson Ho)
Message-Id: <8612271758.AA06079@ucbarpa.Berkeley.EDU>
To: cl-windows@sail.stanford.edu
Subject: CL-windows

Please put me on the cl-windows mailing list.  Thank you.

Kinson Ho (ho@ucbarpa.Berkeley.edu)

∂27-Dec-86  1556	wanginst!ulowell!ulowell.ULOWELL.EDU!grinstei@harvard.HARVARD.EDU 	please add me to the list   
Received: from HARVARD.HARVARD.EDU by SAIL.STANFORD.EDU with TCP; 27 Dec 86  15:56:37 PST
Received: by harvard.HARVARD.EDU; Sat, 27 Dec 86 18:56:52 EST
Received: by wanginst.EDU (4.12/5.8.WangInst)
	id AA03867; Sat, 27 Dec 86 17:54:44 est
Posted-Date: Sat, 27 Dec 86 15:21:00 EST
Received: by ulowell.ULOWELL.EDU (5.51/UUCP-Project/rel-1.0/12-23-86)
	id AA18548; Sat, 27 Dec 86 15:21:00 EST
Date: Sat, 27 Dec 86 15:21:00 EST
From: wanginst!grinstei@ulowell.ULOWELL.EDU (Georges Grinstein)
Message-Id: <8612272021.AA18548@ulowell.ULOWELL.EDU>
To: cl-windows@sail.stanford.edu
Subject: please add me to the list
Cc: grinstein@harvard.HARVARD.EDU

UUCP: wanginst!ulowell!grinstein           Dr. Georges Grinstein
ARPA: grinstein@ulowell.CSNET              University of Lowell
VOX:  +1 617 452 5000 x2681                Lowell MA 01854 USA

∂28-Dec-86  0917	UEJIOWH%CADVAX.decnet@ge-crd.arpa 	cl-window mailing list   
Received: from GE-CRD.ARPA by SAIL.STANFORD.EDU with TCP; 28 Dec 86  09:17:00 PST
Date: 28 Dec 86 12:16 EST
From: UEJIOWH%CADVAX.decnet@ge-crd.arpa
Subject: cl-window mailing list
To: CL-WINDOWS@SAIL.STANFORD.EDU


Please add me to the cl-window mailing list

thanks,

wayne uejio
ge cr&d
bldg 37/rm 523
one river road
schenectady, ny 12345

518-387-6770

∂29-Dec-86  0634	PB80@A.CS.CMU.EDU 	Add to mailing list please
Received: from A.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 86  06:33:57 PST
Date: Mon, 29 Dec 86 09:38 EST
From: Paul.Birkel@A.CS.CMU.EDU
To: cl-windows@SU-AI.ARPA
Subject: Add to mailing list please
Message-Id: <29Dec86.093851.PB80@A.CS.CMU.EDU>

Please add my name/address to the cl-windows mailing list.
Thank you.

	Paul Birkel
	pab@K.CS.CMU.EDU

∂29-Dec-86  0839	spe@cad.cs.cmu.edu 	Please add me  
Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 86  08:39:15 PST
Date: 29 Dec 1986 11:37-EST 
From: Sean.Engelson@cad.cs.cmu.edu
To: cl-windows@sail.stanford.edu
Subject: Please add me
Message-Id: <536258226/spe@cad.cs.cmu.edu>

Please add me to the Common Lisp Windows mailing group.

Thanks,
	-Sean-
	spe@cad.cs.cmu.edu

∂29-Dec-86  0946	@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU 	X in lisp  
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 86  09:41:46 PST
Received: by ATHENA (5.45/4.7)
	id AA09426; Mon, 29 Dec 86 10:39:54 EST
Date: Mon, 29 Dec 86 10:40 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X in lisp
To: elis03@sravc.sra.junet, xpert@ATHENA.MIT.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <8612250007.AA05683@vc.sra.junet>
Message-Id: <861229104019.5.RWS@KILLINGTON.LCS.MIT.EDU>

I am the guilty party claiming to do a lisp implementation of X.
I cannot guarantee when it will be done.  My current expectation
is to have V11 server implementations for both 3600s and Explorers.
I have informal agreements with people at both Symbolics and TI
for them to provide some of the necessary code.  The implementation
will be in CL, but using extended facilities (e.g., LOOP).  The
level of dependence on Flavors has not yet been determined.

The expected form of the implementation is a multi-process server
(one process per client connection, plus a few others).  The
"screen" will be a vanilla window in the native window system;
that is, this will be a window system within a window system,
a "virtual console" approach.

I also hope to have a V11 client end implemented on both systems,
but in a quite different form than most other people seem to
be hacking.  The idea is to implement a flavor obeying the
screen protocol of the native window system.  In this way,
applications written to the native window system can run
transparently across the net.  I already have a V10 implementation
of this mostly running on 3600s.  This also follows the
virtual console model; what pops up on the remote screen is
a single X window, inside of which is a complete lispm window
system.

∂29-Dec-86  1129	RICHER@SUMEX-AIM.STANFORD.EDU 	Re: CL-WINDOWS mailing list  
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 86  11:29:08 PST
Date: Mon 29 Dec 86 11:28:50-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: Re: CL-WINDOWS mailing list
To: commonloops.pa@XEROX.COM, common-lisp@SAIL.STANFORD.EDU,
    xpert@ATHENA.MIT.EDU, news-makers@BRILLIG.UMD.EDU,
    RICHER@SUMEX-AIM.STANFORD.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <12265972863.15.RICHER@SUMEX-AIM.STANFORD.EDU>
Message-ID: <12266716971.39.RICHER@SUMEX-AIM.STANFORD.EDU>

I apologize to people on cl-windows for saying that you get on the list
by mailing to CL-WINDOWS@SAIL.STANFORD.EDU ....  I meant to type
CL-WINDOWS-REQUEST@.....  As many of you know adding -REQUEST is a convention
for mailing adminstrative requests such as getting added to a list
(so everyone doesn't have to see those messages). Sorry. This proves I
am only human afterall,

Mark
-------

∂30-Dec-86  0719	pyramid!pyramid.UUCP!bein@hplabs.HP.COM 	mailing list request..  
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 30 Dec 86  07:17:49 PST
Received: by hplabs.HP.COM ; Mon, 29 Dec 86 02:44:33 pst
Received: by pyramid.UUCP (5.52/UUCP-Project/rel-1.0/09-16-86)
	id AA28898; Mon, 29 Dec 86 02:03:45 PST
Date: 29 Dec 1986 01:58-PST
From: David Bein <pyramid!bein@hplabs.HP.COM>
Subject: mailing list request..
To: hplabs!cl-windows@sail.stanford.edu@hplabs.HP.COM
Message-Id: <536234323/bein@pyramid>

  Please add me to the list.

  Thanks in advance.

--David

∂30-Dec-86  1028	rw@cad.cs.cmu.edu 	mailing list    
Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Dec 86  10:25:40 PST
Date: 30 Dec 1986 13:25-EST 
From: Rob.Woodbury@cad.cs.cmu.edu
To: cl-windows@sail.stanford.edu
Subject: mailing list
Message-Id: <536351112/rw@cad.cs.cmu.edu>

Please put me on the windows mailing list.

-rob woodbury-

∂30-Dec-86  1312	ekberg%home%ti-csl.csnet@RELAY.CS.NET 	CL-WINDOWS request   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 30 Dec 86  13:12:44 PST
Received: from ti-csl by csnet-relay.csnet id ac00367; 30 Dec 86 16:06 EST
Received: from  (home.ARPA) by tilde id AA05445; Tue, 30 Dec 86 13:10:45 cst
Received: by  id AA05911; Tue, 30 Dec 86 13:11:10 cst
Date: Tue, 30 Dec 86 13:11:10 cst
From: Tom Ekberg <ekberg%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8612301911.AA05911@>
To: cl-windows@SU-AI.ARPA
Subject: CL-WINDOWS request

Please add ekberg@ti-csl to the CL-WINDOWS mailing list.

  -- tom (aisle C-7)

∂05-Jan-87  0153	yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET 	CL-WINDOWS   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Jan 87  01:53:24 PST
Received: from utokyo-relay by csnet-relay.csnet id ab00650; 5 Jan 87 4:44 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
	id AA01237; Mon, 5 Jan 87 17:19:23+0900
Received: by nttlab.ntt.junet (4.12/5.0N) with TCP; Mon, 5 Jan 87 15:26:23 jst
Received: by kuis.kuis.kyoto-u.junet (2.0/6.2Junet)
	id AA02230; Mon, 5 Jan 87 13:31:10 jst
Received: by kurims.kurims.kyoto-u.junet (2.0/6.2Junet)
	id AA00482; Mon, 5 Jan 87 13:21:25+0900
Date: Mon, 5 Jan 87 13:21:25+0900
From: Taiichi Yuasa <yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <yuasa@kurims.kurims.kyoto-u.junet>
Message-Id: <8701050421.AA00482@kurims.kurims.kyoto-u.junet>
To: cl-windows%sail.stanford.edu%u-tokyo.junet@RELAY.CS.NET
Subject: CL-WINDOWS


Please add my name on the CL-WINDOWS mailing list.  Thanks.

Taiichi Yuasa
Research Institute for Mathemetical Sciences
Kyoto University, Kyoto 606, Japan
tel: Japan 075-751-2111 ext 7238 or 7209


∂05-Jan-87  0328	mcvax!inria!devin@seismo.CSS.GOV 	mailing list    
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 5 Jan 87  03:27:34 PST
Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP 
	id AA26645; Mon, 5 Jan 87 06:27:31 EST
Received: by mcvax.cwi.nl; Mon, 5 Jan 87 10:10:25 +0100 (MET)
Received: by inria.UUCP; Mon, 5 Jan 87 09:19:09 -0100 (MET)
Received: by inria.UUCP; Mon, 5 Jan 87 09:19:02 -0100 (MET)
Date: Mon, 5 Jan 87 09:19:02 -0100
From: mcvax!inria!devin@seismo.CSS.GOV (Matthieu Devin)
Message-Id: <8701050819.AA02962@inria.UUCP>
To: cl-windows@sail.stanford.edu
Subject: mailing list

Would you mind adding me to the cl-windows mailing list?
best regards
   Matthieu Devin   mcvax!inria!devin

∂06-Jan-87  1246	RICHER@SUMEX-AIM.STANFORD.EDU 	discussion items   
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87  12:45:57 PST
Date: Tue 6 Jan 87 12:46:26-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: discussion items
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12268828250.51.RICHER@SUMEX-AIM.STANFORD.EDU>

    Because I am the instigator that is trying to get this list going
again, I feel I should make some effort to start some discussion. But
it really depends on everyone to keep things going. Please comment,
disagree, or raise completely different issues. I know many of you
have more to contribute than I do so please do. 

    I think there are at least two broad categories of messages
appropriate for the lisp: one is to discuss the standardization of
window systems in Commonlisp, the other to disseminate or obtain
information (I have a --- that does ---; Has anyone done ---?  There
is a [paper, conference, workshop, etc.] that might be of interest.)

     I have a few comments that are a "reaction" to what I read in the
cl-windows archives.Those messages are 1-2 years old so it's not
surprising that they are dated now.

(1) There was some discussion about whether to use objects for a
window standard.  The issue was resolved then in favor of NO objects
because an object standard did not exist.  Now there is lots of hope
that some variant of Commonloops will be accepted as a Commonlisp
standard this year. So the issue cannot be dismissed so easily now.
I'd like to hear your opinions on this.  One thing to consider though
is whether or not a standard could satisfy both camps. Given that
Commonloops uses function-calling and lisp syntax would both camps be
satisfied if the standard included a set of operators and accessfns
that could be implemented with either standard functional programming
or with object-oriented programming?

    Beyond a base level standard there is the need for toolkits.
Should they be done with objects? A lot of folks find that very
attractive.

(2) Earlier discussions on this list seemed to feel that a CL window
standard must support all kinds of terminals including CRTs or worse.
Personally, I think it would make things a lot simpler to concentrate
on bitmap displays and not worry about what would happen on CRTs. Only
in those cases where it really makes sense to add something t for
CRTs, etc. should this be a concern.  Otherwise, I think that there
will be too much compromise, too much complexity, or time taken to
agree on anything.

    I also feel that you should design different interfaces if you
expect the program to run on different kinds of displays. I don't
think that you will get the optimal interface for either a bitmap
display or a CRT if you write one piece of code for both. Therefore, I
don't see a big win in having all operations do something "reasonable"
on all displays even if possible.

;(3) There was some discussion as to whether there really should be a
separate group for a graphics standard. I think the emergence of
network-based window systems such as X and NeWS suggest that there is
a need to deal with both somewhat simulataneously.  If you look at X
then you see the graphics stuff must be part of the protocol or there
must be a good way to add extensions (e.g., for 3-d graphics which are
not included in X at present).  With NeWS you see that the graphics
primitives need be part of Postscript. So I think the coupling must be
tighter than some may have suggested.

(4) Finally, the emergence of X and NeWS adds a completely new
dimension to CL-WINDOWS discussions.  Now we are in the position of
talking about adopting other standards and agreeing on a graceful
integration with CL that will serve people's needs for a long time.

    IN the short run I don't think that any one standard (i.e., X or
NeWS) can be chosen as the one for the Commonlisp language. This
raises two sets of issues:

-Can we at least agree on standard Lisp/[X, NeWS] interfaces? Is there
a level above the low-level primitives that can be standardized so
that it doesn't matter to the application programmer whether X, NeWS,
or whatever is being used? And you can really run programs on
different systems?

-Is there a set of really low-level primitives that would allow one to
efficiently implement X, NeWS, or some future window system? And are
we ready to do this?

With regard to standarding Lisp/[X,NeWS] interfaces:

    It seems that there are several routes to go. On UNIX workstations
people are using the X or NeWS server that is written in C and
communicating with the server process.  However, in some cases people
are using foreign function call mechanisms (which I assume are
non-standard) to define lisp functions equivalent to some existing X
function written in C. Other people are using unix pipes. On lisp
machines people are taking the approach of writing the server in Lisp.
I think we have to allow for various implementation approaches.
However, I think we want to make sure that the application programmer
does NOT have to know which implementation approach has been taken,
and furthermore code is fully compatible across hardware systems.
Otherwise, what's the point of pretending you have a standard.

    Regardless of what happens in the future I think there will be X
servers available (and usually supported) on lots of hardware
configurations. Anyhow that seems to be the trend now. If NeWS catches
on then a similar thing may happen. I feel confident I will soon find
Commonlisp and X on most hardware systems, but will my Lisp
window/graphics stuff work without modification (assuming display
capabilities are similar, i.e., Vanilla X let's say) concerns me.

Mark
-------

∂06-Jan-87  1437	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	toolkits
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87  14:37:08 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 6 Jan 87 17:39-EST
Date: Tue, 6 Jan 87 17:38 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: toolkits
To: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <12268828250.51.RICHER@SUMEX-AIM.STANFORD.EDU>
Message-ID: <870106173842.4.RWS@KILLINGTON.LCS.MIT.EDU>

For what it's worth, a toolbox/toolkit proposal for X
(mostly for C) has recently been floated by DEC/HP/MIT.
Copy can be obtained via anonymous FTP to zap.mit.edu
(18.72.0.126) as /pub/proposal.out (file output) or
/pub/proposal.ps (postscript).  Might be useful for
people to evaluate its overall structure in relation
to lisp, and I'm sure the people involved would be
interested in any comments.

∂07-Jan-87  1822	sdcrdcf!stephen@LOCUS.UCLA.EDU 	request 
Received: from LOCUS.UCLA.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 87  18:22:15 PST
From: sdcrdcf!stephen@LOCUS.UCLA.EDU
Received: by sdc.uucp (4.12/sdcrdcf)
        id AA00697; Wed, 7 Jan 87 16:40:28 pst
Message-Id: <8701080040.AA00697@sdc.uucp>
Received: from BIRDY by sdcrdcf with PUP; Wed, 7 Jan 87 16:40 PST
Date:  7 Jan 87 16:40 PST (Wednesday)
Subject: request
To: cl-windows%sail.stanford.edu
Cc: 

please include me on the Commonlisp window system list.

stephen russell
sdcrdcf!stephen@locus.ucla.edu

∂18-Jan-87  1653	MMcM@STONY-BROOK.SCRC.Symbolics.COM 	discussion items  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 Jan 87  16:49:27 PST
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 46021; Sun 18-Jan-87 19:37:53 EST
Date: Sun, 18 Jan 87 19:35 EST
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: discussion items
To: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <12268828250.51.RICHER@SUMEX-AIM.STANFORD.EDU>
Message-ID: <870118193506.4.MMCM@OWL.SCRC.Symbolics.COM>

I find it better to think of X Windows as a virtual console specification,
rather than a window system specification.  In the first place, window
systems often deal with issues of window management, which are expressively
a client of X.  In the second place, I think that the concepts presented by
the low-levels of X are really not those that an application programmer of
an advanced LISP system should have to deal with when programming the
window system.  For instance, the methods of implementing higher level
interfaces such as scrolling viewports or asymmetrical program controlled
out of band information (like borders and labels) require the interposition
of more than one X window for what is naturally a single object to the
application programmer.

A fortiori, NewS is a graphical imaging specification.  I do not expect
that given the choice, programmers of LISP systems would program directly
in the PostScript stack language.

I see no reason not to move forward toward adopting X, for instance, as the
standard, or a standard, at the right level of modularity.  I sincerely
hope that programs that are written entirely in the standard language that
we produce are not fettered by having only this level.  That is to say, I
hope that we can have a window system standard that is higher level than
either X or NewS.

I would not propose that this time that we attempt to standardize all the
way to the User Interface Management System level.  But we can hope that
such systems as would be provided by different vendors and as part of
different libraries would themselves be written using the standard.  This
would greatly increase the likelihood that they would be portable, whenever
their supplier chose to unbundle them.

I must agree that it is only natural to design the window system standard
with the emerging object orientated programming standard in mind.  I would
go even further and say that it should be designed around an extension of
an integration of the existing output stream primitives with such a class
standard.  We should recognize the overlap and interleaving of character
and graphical I/O in the window objects provided by the standard.  Note
that I am not at this time proposing equality of stream objects and
windows.

As to the relationship between this effort and that of graphics, the
situation is pretty complicated.  First off, it's obvious that the
implementation of any window system requires certain very-low-level
interfaces to hardware drivers and such for going the actual bit shuffling
that it requires.  Sometimes that's known as graphics.  Second, there are
those graphical operations that one performs in a window, such as drawing
lines and so on.  These must be recognized by the virtual console and
imaging specifications, so there must be a way through the window system to
them.  And finally, there is the very high level graphics operations that
truly graphically oriented programs, such as animation or design systems,
deal in.

I have found a data-oriented set of generic procedures to be a pretty
easily managed interface to that middle level of graphics that the window
system standard should deal with.  By this I mean not a purely procedural
interface, such as PostScript provides, in as much as that locks out
low-level assistance for high-level operations, to which generic functions
are otherwise ideally suited.  Nor a set of actual data entities directly
modelling the graphical output.  Of course, these are invaluable when one
wishes to move past just output and deal with geometrical constraint
systems.  But we are not in my opinion ready for a standardization here.
And in any case, this is the part of the system that I feel is outside the
province of window system standardization.  What I am talking about, then,
is a set of functions for drawing primitive graphical output, such as
polygons, circles, lines and so on.  Plus special forms for interacting
with the dynamic aspects of graphical state, such as scaling or line
thickness, in a LISP-like way.  I'm sure it's obvious that either X or NewS
is well suited to the implementation of such a standard set.

To proceed, I think we should attempt to itemize those objects and concepts
with which we do expect the application programmer who is well treated by
his or her LISP system to be dealing.

∂18-Jan-87  1726	STEINBERG@RED.RUTGERS.EDU 	Access to Sun windows from CL    
Received: from RED.RUTGERS.EDU by SAIL.STANFORD.EDU with TCP; 18 Jan 87  17:25:53 PST
Date: 18 Jan 87 20:26:04 EST
From: Louis Steinberg <STEINBERG@RED.RUTGERS.EDU>
Subject: Access to Sun windows from CL
To: cl-windows@SAIL.STANFORD.EDU
cc: steinberg@RED.RUTGERS.EDU
Message-ID: <12272024883.36.STEINBERG@RED.RUTGERS.EDU>

Rather than discussing standards and future directions, this message
is a request for pointers to code available here-and-now.  I teach a
course on AI Programming.  We use Franz Common Lisp on Suns (running
release 3.2 of the Sun Unix).  I would like to have my students write
code that can create and access windows and the mouse.  (Cursor
positioning is needed but not graphics.)  It would be nice if this
code worked with the SunTools package, but not necessary.

Does anyone have any pointers to packages that might help?

Thank you.

		Louis Steinberg
		Department of Computer Science
		Rutgers University
-------

∂18-Jan-87  1753	dcmartin@ingres.berkeley.edu 	Re: Access to Sun windows from CL  
Received: from INGRES.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 18 Jan 87  17:52:53 PST
Received: by ingres.Berkeley.EDU (5.57/1.14)
	id AA18611; Sun, 18 Jan 87 17:52:07 PST
Message-Id: <8701190152.AA18611@ingres.Berkeley.EDU>
From: "David C. Martin" <dcmartin@ingres.berkeley.edu>
Office: 440 Evans - x2-9585
Home: 2441 Haste St #37, Berkeley, CA 94704 - (415) 843-6470
Fortran: is not backward, NARTROF is backwards.
To: Louis Steinberg <STEINBERG@red.rutgers.edu>
Cc: cl-windows@sail.stanford.edu
Precedence: priority-mail
In-Reply-To: Your message of 18 Jan 87 20:26:04 EST
Subject: Re: Access to Sun windows from CL
Date: 18 Jan 87 17:52:05 PST (Sun)
Sender: dcmartin@ingres.berkeley.edu

I am building such a package and have most of the X functionality available
from ExCL.  This package is also interfaced to Portable CommonLoops which
supplies the object oriented extensions.  If you would like the code, it
is available by anonymous ftp from ingres.berkeley.edu in ~ftp/pub/bool.

It doesn't work completely, but it does provide most of the functionality.

Franz Inc may be able to provide you with more information about the
availability of other windowing systems for ExCL.

Franz Incorporated
1141 Harbor Bay Parkway
Alameda, CA 94501
(415) 769-5656
..!ucbvax!franz!info or info%franz@berkeley.edu

dcm

∂20-Jan-87  1200	RAM@C.CS.CMU.EDU 	X interface standard  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Jan 87  09:59:24 PST
Received: ID <RAM@C.CS.CMU.EDU>; Tue 20 Jan 87 12:55:51-EST
Date: Tue, 20 Jan 1987  12:55 EST
Message-ID: <RAM.12272467201.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   cl-windows@SAIL.STANFORD.EDU
Subject: X interface standard


    I think that coming up with an X interface standard is a
worthwhile near-term goal for this group.  The main reason I think
that we should concentrate on an X interface is that I can conceive of
something coming out of it.  The reason is that two fundamental things
needed for convergence on a stardard are present in the case of X:
 1] A baseline proposal that establishes a common ground for
    discussion and resolves many of the necessary arbitrary decisions
    in a necessarily arbitrary way.
 2] A group of people who care enough about the result to provide the
    necessary manpower and feedback.

    It seems that X has become something of a de-facto stardard.  Here
at CMU, we are planning to use X as the standard basis for our user
environment and user interface work.  We are at this moment working on
coming up with a basic interface to X.  Other messages indicate that
other groups have already done this.  I get the impression that these
interfaces are mostly "quick and dirty"; what we need to do is get
some of the people who have been involved in these efforts to think
about proposals for interfaces that are reasonable clean and portable,
yet stay close enough to X so that we don't get lost.

    I suggest these priorities in an X interface design:
 1] Portability and consistency with general Common Lisp design
    philosophy.
 2] Access to full X functionality.
 3] Generalization of design to admit use of other window systems and
    to allow for future extensions.

    Initially, I was opposed to the idea of using Common Loops in the
X interface, but I now see some major advantages.

Pro:
 1] Objects provide a clean solution to the input event
    demultiplexing/dispatching problem.  Non-trivial applications need
    to be able to respond to various kinds of things happening to any
    of a number of screen objects.  The best solution to this problem
    seems to be to use an event driven, object oriented structure for
    the application.  Although the doesn't require the use of an
    object oriented programming system per-se, it makes sense to use
    the one that we have already standardized on.
 2] Using an object oriented approach provides an easy path toward
    more ambitious window management standards.

Con:
 1] Since an object oriented approach would resemble hairy proposals
    that "solve all the world's problems", it might be more difficult
    to converge on a standard, since the crinophiles would complain
    that it impeded the ultimate hairy apothesis.
 2] There is an efficiency penalty.  Perhaps we could reduce this
    problem by making the basic output operations non-generic.
    We might also consider making the set of non-generic operations
    large enough so that an interface could support everything but
    event-driven input without having an object system at all.

Whether we use objects or not, we have a significant task in coming up
with lispy interfaces to the basic X operations.  I encourage people
to send proposals discussing how these interfaces are to be done.

Rather than simply describing the interface to each routine, a
proposal should:

 -- Describe general rules for generating the interfaces to "easy"
    routines.
 -- Describe specific solutions to problems with particular routines,
    together with the rationale for the proposed solution.  This will
    mostly involve the few routines that accept or return complex
    data structures.

Well, now you all have your assignments.  Go to it, but remember that
points will be taken off for exhibiting bad attitude by disagreeing
with me.  :-)

  Rob

∂21-Jan-87  1328	RICHER@SUMEX-AIM.STANFORD.EDU 	X/Lisp from ailist 
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Jan 87  13:28:49 PST
Date: Wed 21 Jan 87 13:11:59-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: X/Lisp from ailist
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12272765061.66.RICHER@SUMEX-AIM.STANFORD.EDU>

The following was extracted from ailist digest:

Date: Thu, 15 Jan 87 09:58:16 PST
From: TAYLOR%PLU@ames-io.ARPA
Subject: Request for Info on Lisp Machine Window Systems

We have been developing a user interface for a planning/scheduling
application on the Symbolics, using Version 6.1 windows and flavors.
For future long term development of the user interface, we are
considering a possible change of the window system, before converting
to Genera 7.0 Dynamic windows and Presentation types.  We have heard
mention of XWINDOWS and are interested in knowing about it and other
"generic" window systems and the trade-offs between specialized
features and portability.
Issues we are looking at:
        o will window system be compatible with a future Common
          lisp window standard
        o will window system be portable between lisp machines and
          AI work stations, e.g. Symbolics, TI, LMI, Xerox, Sun, ..
        o how much conversion will be required to go from current
          implementation, now running under Genera 7.0, to a new
          window system
        o what are advantages/disadvantages of potential window
          systems as far as ease of implementation, facilities
          available to present information to user, use of object
          oriented techniques, etc
        ow availability of potential window systems on the Symbolics

Opinions and recommendations are solicited from Lisp machine users
as to their experience and preferences.  Please respond by e-mail.
I will summarize for this bboard if requested and sufficient responses
are received.

        Thanks - Will


   Will Taylor - Sterling Software, MS 244-7,
                 NASA-Ames Research Center, Moffett Field, CA 94035
   arpanet: taylor%plu@ames-io.ARPA
  uusenet: ..!ames!pluto.decnet!taylor
   phone  : (415)694-6525

------------------------------
-------

∂21-Jan-87  1419	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	random thoughts   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 Jan 87  14:18:48 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 21 Jan 87 17:15-EST
Date: Wed, 21 Jan 87 17:17 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: random thoughts
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870121171715.3.RWS@KILLINGTON.LCS.MIT.EDU>

A significant characteristic of the TI and Symbolics window systems is
that output (and most window management functions) are synchronous; if
you call DRAW-LINE, then when the function returns, you know the line
has been drawn.  Thus, you needn't worry about forcing output when you
go off to do something else (like wait for input).

A significant characteristic of the X protocol (and also NeWS) is that
output is inherently asynchronous, and that it is important to buffer
multiple requests into a single IPC segment.  Thus, someone or something
has to be responsible for forcing output.

I believe buffering and asynchrony must be explicit at the application
level.  The application must be responsible for forcing output.

In the TI and Symbolics worlds, the view for the most part is invoking
functions on a window object, or on a stream connected to a window
object.  With the X protocol, one should think of implementing using a
single IPC channel between an address space and an X server, not an IPC
channel per window.  How should this be abstracted?  Is there a virtual
channel per lisp process [we ought to be thinking about multi
process(or) worlds] such that forcing one isn't abstractly defined to
force the others, or if there is a single channel, is the
synchronization implicit or explicit?  Similar synchronization questions
arise at every object abstraction level.

Are operations performed on windows (or streams), or on consoles (with a
window passed as an argument), or on graphics contexts (as they exist in
X, with a window passed as an argument)?  If performed on other than a
console, is "force output" abstracted to per window or context, or is it
simply per console?  Should a graphics operation be defined by a
(graphics context, window) pair as in X, or is one element of the pair
embedded inside the other?  Is the graphics context explicit as object
state, or is it embedded in control context (e.g., with-character-style,
with-line-width)?

∂21-Jan-87  1458	@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU 	X Version 11 protocol document 
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 Jan 87  14:54:25 PST
Received: by ATHENA (5.45/4.7)
	id AA12834; Wed, 21 Jan 87 14:56:52 EST
Date: Wed, 21 Jan 87 14:58 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X Version 11 protocol document
To: xpert@ATHENA.MIT.EDU, xport@ATHENA.MIT.EDU, cl-windows@SAIL.STANFORD.EDU
Message-Id: <870121145815.4.RWS@KILLINGTON.LCS.MIT.EDU>

The "nearly final" document describing the Version 11 protocol of the
X Window System is now available via anonymous ftp (i.e., use login
"anonymous", any password) to zap.mit.edu (18.72.0.126) as the text file
	/pub/x11.spec
The file is 171510 bytes long.  Those without ftp access can send mail
to me requesting a personal copy, and I will respond as time permits.
I cannot reasonably cope with requests for postal service.

Note that this document (still) does not give precise formats or bit
encodings.  Such information of course exists, and will be published
eventually as a separate document.

∂22-Jan-87  1431	RAM@C.CS.CMU.EDU 	random thoughts  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Jan 87  12:00:55 PST
Received: ID <RAM@C.CS.CMU.EDU>; Thu 22 Jan 87 15:00:24-EST
Date: Thu, 22 Jan 1987  15:00 EST
Message-ID: <RAM.12273014149.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: random thoughts
In-reply-to: Msg of 21 Jan 1987  17:17-EST from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>

    Date: Wednesday, 21 January 1987  17:17-EST
    From: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
    To:   cl-windows at SAIL.STANFORD.EDU
    Re:   random thoughts

    A significant characteristic of the X protocol (and also NeWS) is
    that output is inherently asynchronous, and that it is important
    to buffer multiple requests into a single IPC segment. [...]  I
    believe buffering and asynchrony must be explicit at the
    application level.  The application must be responsible for
    forcing output.

    [...] With the X protocol, one should think of implementing using
    a single IPC channel between an address space and an X server, not
    an IPC channel per window. [...]

It isn't clear to me that this follows.  I think that the single IPC
connection can be regarded as an unimportant quirk of the current X
implementation.  I would favor an implementation which admits the
possibility of separate buffering for each object, and then provide
operations for flushing large sets of buffers, such as all buffers or
all buffers for a subtree of the window hierarchy.

There should also be some automatic buffer flushing, such as flushing
buffers before going into an input wait.  This will eliminate most of
the need for explicit buffer flushing.

A per-object connection implies that there is no guaranteed ordering
of operations that are done on distinct objects unless explicit
synchronization is done.

If we allow per-object communication channels, then it is potentially
expensive to synchronize with the server and verify that preceding
operations have actually been done, since it could require doing a
handshake on many connections.  I think that requiring syncronization
is sufficiently rare that it is reasonable to require explicit
synchronization on each object.

Allowing a per-object communication channel is basically a worst case;
code which assumes a per-object channel will work on implementations
with fewer channels, but not the other way around.

I have extensively used the Sapphire window system on the CMU Spice
system.  Sapphire uses the Accent IPC to implement a partially
asynchronous RPC system with an implicit per-object communication
channel.  Since the object knows everything necessary for
communication with the server, the application can operate on windows
on different machines without knowing it.

    [...] Are operations performed on windows (or streams), or on
    consoles (with a window passed as an argument), or on graphics
    contexts (as they exist in X, with a window passed as an
    argument)?  [...]  Should a graphics operation be defined by a
    (graphics context, window) pair as in X, or is one element of the
    pair embedded inside the other?  Is the graphics context explicit
    as object state, or is it embedded in control context (e.g.,
    with-character-style, with-line-width)?

I don't know enough about how X graphic contexts are supposed to be
used to be sure, but I think the correct solution is to embed the
graphics context within the window object.  We then need some sort of
rule for choosing the correct graphics context when performing a
multi-window operation.  I think that the correct solution is to use
the context for the destination.

Basically, I think the window is the "real object" and should somehow
implicitly provide any other necessary context such as the server
connection or graphics context.  The main reason I believe this is
that it seems much more useful to think of input events as happening
on windows, rather than happening on some less specific object, with
the window as extra information.

  Rob

∂22-Jan-87  1530	MMcM@STONY-BROOK.SCRC.Symbolics.COM 	random thoughts   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Jan 87  15:29:02 PST
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49563; Thu 22-Jan-87 18:20:29 EST
Date: Thu, 22 Jan 87 18:17 EST
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: random thoughts
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870121171715.3.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870122181745.2.MMCM@OWL.SCRC.Symbolics.COM>

I agree that the virtual console and probably window system layers must
expect asynchrony and deal with forcing output.  I would contend that a
good UIMS wouldn't require an application to deal with this.  I guess
that means my UIMS is an application in your domain.  Fine.

A multiplexed IPC channels to a server is certainly a good
implementation.  However, I feel that application programmers should act
as if there were separate channels to the server for each window.  They
should not be burdened with worrying about the multiplexing.  This might
mean that a force from any window forces output to all windows, which I
don't see as a priori wrong.  Or it might mean that there is an
intermediate buffering layer between window output and the network
channel, such that any subset can be forced.  I do not feel that
per process is the right level of abstraction.  Processes basically
should be separate from collections of windows that make up an activity.

I believe all operations should be performed on streams.  A window is
represented by a stream.  A pair of graphics context and window is also
a stream.  It is my experience that the problems with bundling together
such behaviors arise from a system's reluctance to let you create
children streams, rather than a fundamental good reason to deal with
separate objects.  I will remind everyone that classes make it easy to
get this combining and keep good modularity.

I have found that having the graphics context as object state is a good
implementation technique, but that dynamic extent is almost always what
an application programmer wants.  I might point out that your
with-line-width can be implemented via setf and unwind-protect in those
environments in which multiprocess access to the stream is not an issue.

I have also found it enormously convenient to have keyword arguments to
all output functions that provide single operation access to this
dynamic binding.  For example, draw-ellipse takes a rotation argument
which works by executing the meat of draw-ellipse inside a with-rotation.

∂23-Jan-87  1319	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	random thoughts   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Jan 87  13:18:06 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 23 Jan 87 16:17-EST
Date: Fri, 23 Jan 87 16:18 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: random thoughts
To: RAM@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12273014149.BABYL@C.CS.CMU.EDU>
Message-ID: <870123161813.9.RWS@KILLINGTON.LCS.MIT.EDU>

    Message-ID: <RAM.12273014149.BABYL@C.CS.CMU.EDU>
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

					     I think that the single IPC
    connection can be regarded as an unimportant quirk of the current X
    implementation.  I would favor an implementation which admits the
    possibility of separate buffering for each object, and then provide
    operations for flushing large sets of buffers, such as all buffers or
    all buffers for a subtree of the window hierarchy.

Viewing each window as a separate sequencing entity only works when you
use windows as large-grain objects.  If you start to use lots of windows
for lots of little things (e.g., menu items, button boxes), with
abstraction levels completely hiding the number of windows involved, as
is often done in X, then the ability to control the order of execution
across an arbitrary set of windows becomes quite important.  It is not
sufficient to "flush large sets of buffers", the total order is
significant.

    There should also be some automatic buffer flushing, such as flushing
    buffers before going into an input wait.  This will eliminate most of
    the need for explicit buffer flushing.

Depends on your system structure.  If you look at the current Symbolics
world, you wait on an "io-buffer", which has no explicit back-link to
any window/screen/console (indeed, multiple windows can share a single
io-buffer).  This is indeed one of the difficulties I ran into in trying
to slip X in underneath the current Symbolics interface.

    If we allow per-object communication channels, then it is potentially
    expensive to synchronize with the server and verify that preceding
    operations have actually been done, since it could require doing a
    handshake on many connections.

Absolutely true.

				    I think that requiring syncronization
    is sufficiently rare that it is reasonable to require explicit
    synchronization on each object.

Absolutely false.  I think there is a large body of X code that represents
a strong counter-argument.

    I don't know enough about how X graphic contexts are supposed to be
    used to be sure, but I think the correct solution is to embed the
    graphics context within the window object.

If you really mean "embed the window and graphics context in a stream",
I might agree with you.  Certainly, two distinct processes ought to be
able to manipulate the same window with distinct graphics contexts.

∂23-Jan-87  1423	@ZERMATT.LCS.MIT.EDU,@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU 	random thoughts
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Jan 87  14:20:57 PST
Received: from KILLINGTON.LCS.MIT.EDU (KILLINGTON.LCS.MIT.EDU) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 26870; 23 Jan 87 17:12:50 EST
Date: Fri, 23 Jan 87 17:12 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: random thoughts
To: MMcM@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870122181745.2.MMCM@OWL.SCRC.Symbolics.COM>
Message-ID: <870123171256.1.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Thu, 22 Jan 87 18:17 EST
    From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>

    Processes basically should be separate from collections of windows
    that make up an activity.

I agree that an activity is not defined by a collection of windows, but
I believe it is extremely desirable to hold that, for a single execution
thread, all requests issued to a single console are executed in the
order the were issued.  Interleaving among threads should certainly be
undefined except possibly via explicit synchronization; at that point
the notion of an activity and sequencing of requests from a single
activity might be useful.

    I have found that having the graphics context as object state is a good
    implementation technique, but that dynamic extent is almost always what
    an application programmer wants.  I might point out that your
    with-line-width can be implemented via setf and unwind-protect in those
    environments in which multiprocess access to the stream is not an issue.

Dynamic extent is a nice idea, but (I would claim) one has to be very
careful about performance penalties, and the same holds true for the
meaning of context as object state.  If you look at high-performance
display hardware being built today, much of the graphics state is stored
in hardware.  By graphics state I mean such things as the line-width,
source pixel, tile pattern, font, clipping region, etc.  The more "all
singing, all dancing" the hardware, the more state stored.  Typically
the hardware will support some fixed number of context blocks that you
can switch between rapidly, because reloading all the state on every
operation would be enormously expensive.  In fact, even CHECKing if the
desired state matches the current state would be very expensive, so it
is imperative that there be some way to check that fast.  The
manifestation of this in X is that there is an explicit resource, called
a graphics context, with an independent identity.  This makes checking
whether the state is loaded trivial.  So, point number one is that the
graphics context must be more than the sum of its parts.  Now, one might
be tempted to associate the state with the window itself, or with a
stream to the window; both approaches have real limitations.  If you
associate it with the window, then independent processes can't
manipulate the window with independent graphics state.  If you associate
the state with a stream to the window, then you can't apply a single
graphics context to an arbitrary number of windows.  If you view windows
as a cheap resource to be used in abundance, as is done in X, then the
ability to apply a graphics context uniformly to a collection of windows
is important.  Note that for a given graphics context, switching windows
is essentially a matter of switching the clipping region, just one
component of the state, and one for which there is a quick check for
equality (namely, window identity).  If there is no independent identity
for the graphics context, then switching windows with equivalent
embedded state will require an expensive check.

Summing, I believe the model of a stream containing both a window and a
graphics context, with the ability for streams to share both windows and
graphics contexts, is important.  This means window and context are
instance variables of the stream, not component objects, and this has
implications for determining "who is in control".  It may also be
important to be able to change both the window and the graphics context
of a stream.  I believe dynamic extent for graphics state is important,
but I also believe that object state is vital for high performance.

    I have also found it enormously convenient to have keyword arguments to
    all output functions that provide single operation access to this
    dynamic binding.  For example, draw-ellipse takes a rotation argument
    which works by executing the meat of draw-ellipse inside a with-rotation.

For absolute performance there should be a direct interface that simply
uses the stream state.  There should be a "reduced operator" interface
that allows keyword override for at least the graphics state more
commonly changed.  Having only a full-blown keyword interface would seem
to me to force to much of a performance penalty.  Also, if one wants the
graphics context to be extensible (e.g., adding a coordinate transform
if one isn't initially provided, or adding 3-D state), one would prefer
an interface that doesn't necessarily require explicit code modification
for each extension.  In the case of keywords, this would seem to mean
you have to define the generic function with &allow-other-keys, and it
must call on the graphics context to process the keywords.


∂25-Jan-87  0823	RAM@C.CS.CMU.EDU 	random thoughts  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Jan 87  08:23:02 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 25 Jan 87 11:22:59-EST
Date: Sun, 25 Jan 1987  11:22 EST
Message-ID: <RAM.12273761005.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: random thoughts

    Date: Friday, 23 January 1987  16:18-EST
    From: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
    cc:   cl-windows at SAIL.STANFORD.EDU
    Re:   random thoughts

        Message-ID: <RAM.12273014149.BABYL@C.CS.CMU.EDU>
        From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

    					     I think that the single IPC
        connection can be regarded as an unimportant quirk of the current X
        implementation.  I would favor an implementation which admits the
        possibility of separate buffering for each object, and then provide
        operations for flushing large sets of buffers, such as all buffers or
        all buffers for a subtree of the window hierarchy.

    Viewing each window as a separate sequencing entity only works when you
    use windows as large-grain objects.  If you start to use lots of windows
    for lots of little things (e.g., menu items, button boxes), with
    abstraction levels completely hiding the number of windows involved, as
    is often done in X, then the ability to control the order of execution
    across an arbitrary set of windows becomes quite important.

Could you provide an example please?  I'm having difficulty thinking
of any common situations where the relative sequencing of operations
on two screen objects is very important.  I think that this is
actually a fairly basic property of window systems, since their entire
purpose is to prevent interactions between windows by giving them
logically distinct bits.  The only examples that I can think of
involve operations on two windows with a nesting relationship.  For
example, you might need to make sure that an outer window had been
resized before you resize its subwindows.

    				    I think that requiring syncronization
        is sufficiently rare that it is reasonable to require explicit
        synchronization on each object.

    Absolutely false.  I think there is a large body of X code that represents
    a strong counter-argument.

I don't think that existing X code has direct relevance to this issue
since X *does* have implicit synchronization between hierarchically
related windows.  Because this synchronization is automatic, the
programmers probably have no idea of what explicit synchronization
would be necessary in a system that required it.

        I don't know enough about how X graphic contexts are supposed to be
        used to be sure, but I think the correct solution is to embed the
        graphics context within the window object.

    If you really mean "embed the window and graphics context in a stream",
    I might agree with you.  Certainly, two distinct processes ought to be
    able to manipulate the same window with distinct graphics contexts.

No, I certainly don't mean that.  First, let me say that I object to
this use of the term "stream" in this discussion.  We have not yet
established that there is any relationship between the Common Lisp
stream concept and any window system proposal.  I object to the role
that you seem to be assigining to streams for two reasons:
 1] Many systems have highly tuned stream implementations not based
    object systems that will not mesh well with an object based window
    system.
 2] I think that there is little gain in encorporating streams
    directly into the window system, since most operations will make
    no use of the stream protocol.  It is obviously useful to be able
    to implement a text I/O stream using a window, but I don't think
    that this is a good fundamental unifying principle for a window
    system.  A Make-Window-Stream function would be entirely adequate.

My idea is that there is a single level in the window system, with the
default graphics context being specified by a slot in the Window
object.  It seems to be that this scheme is simpler and more efficient
than having a separate "stream" object that relays the message to the
window, supplying the graphics context.

We can allow for applications that need to use multiple contexts in
the same window simultaneously by having the graphics context be an
optional, or having separate operations that accept the graphics
context.  Of course, the default graphics context can also be set.

Given this level of access, you can define "stream" to do whatever you
want, and it won't bother me as long as I don't have to implement it.

  Rob

∂25-Jan-87  1355	MMcM@STONY-BROOK.SCRC.Symbolics.COM 	random thoughts   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jan 87  13:54:51 PST
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51287; Sun 25-Jan-87 16:52:59 EST
Date: Sun, 25 Jan 87 16:54 EST
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: random thoughts
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870123171256.1.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870125165439.1.MMCM@OWL.SCRC.Symbolics.COM>

I believe your concerns and suggestions about state based interfaces
belong in implementation notes, not in the standard.

That there need be a significant penalty for keyword arguments is at
least in part superstition.  I assume that most production compilers
apply reasonable optimization for the keyword arguments to the standard
sequence functions, although no such requirement is given in the
specification, and no version of those functions that does not take
keyword arguments is provided.

Your example graphics engine is not the only possible hardware
assistance.  I could well imagine a more symbolic processor in which
dynamic creation of linked state blocks on a control stack is much
faster than a full write through to a state in main memory, which might
require multi-processor synchronization, or who knows what.  I see no
reason to suppose such a processor could not have a graphics engine
following the same architecture principals.

Given that we agree that dynamic binding is the right interface for
application programmers, I do not believe the specifcation should
require either shallow or deep binding implementation.

In other words, the issue is whether well tuned implementations can give
a high performance program quick access to state control without
distortion of good modularity.  I contend they can.

∂27-Jan-87  0346	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	random thoughts   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Jan 87  03:45:47 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 27 Jan 87 09:45-EST
Date: Tue, 27 Jan 87 09:47 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: random thoughts
To: RAM@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12273761005.BABYL@C.CS.CMU.EDU>
Message-ID: <870127094700.7.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Sun, 25 Jan 1987  11:22 EST
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

	Date: Friday, 23 January 1987  16:18-EST
	From: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>

	... the ability to control the order of execution
	across an arbitrary set of windows becomes quite important.

    Could you provide an example please?  I'm having difficulty thinking
    of any common situations where the relative sequencing of operations
    on two screen objects is very important.

I contend that we should preserve sequentiality, and (as much as
possible) maintain the illusion of synchronicity, because it greatly
simplifies reasoning about programs and the structure of programs.  A
few examples:

1. The visual appearance of display update is an important
consideration.  Just to say that "the quiescent-state bits are the same"
is not sufficient to capture dynamic visual desires.  Given reasonable
abstractions, the application will have relatively little knowledge of
how many and what structure of windows are used in a given composite
object, and disjoint composite objects will have little knowledge about
how they should relate to each other, making application-level
synchronization painful.  The tie that binds (I claim) is the sequential
execution order of the process; things should be performed in the order
they are requested.

2. Say I want to "map all children of window W", and then immediately
draw into the children (which don't have backing stores).  The map
operation is on the parent window; it is important for performance that
this not be done as separate operations on each child.  Unless the map
operation actually gets executed before the graphics on the children,
some graphics will be lost.

3. If an application performs output on two windows, and also frequently
bitblts between them, the cost of round-trip synchronization for the
bitblts will be totally unacceptable.

4. Drawing "through" subwindow boundaries seems to be an (unpleasant)
reality.  An example is rubber-banding a rectangular outline for placing
objects in an overlapped environment, where the objects are implemented
with (sub)windows.  Again, synchronizing with all inferior windows seems
painfully complicated.

5. Let's say I want to open a font, and then use it in painting text to
a window.  Fonts (I claim) should be associated with consoles, not with
individual windows.  You certainly don't want to force synchronization
on all possible windows every time you create a window-independent
resource.  You also certainly don't want the resource creation itself to
require a round-trip; that's the way it works in Version 10 of X, and it
was a BIG mistake, resulting in very noticeable delays and ugly
programatic interfaces to kludge around the problem.  (Version 11 of X
does not require a handshake for resource creation.)

6. In general, a real window system is likely to have numerous
operations that can't be easily associated with a single window, and yet
the application will desire the ability to trivially achieve sequencing.


    I don't think that existing X code has direct relevance to [per-object synchronization]
    since X *does* have implicit synchronization between hierarchically
    related windows.  Because this synchronization is automatic, the
    programmers probably have no idea of what explicit synchronization
    would be necessary in a system that required it.

I claim that maintaining sequential reasoning has been extremely
beneficial in X.  I also point out that in Version 10 of X, I (naively)
assumed that round-trip synchronization at resource creation wouldn't be
a problem; it turned out to be a very significant problem.  As such, I
am very wary of any vague claims that synchronization won't be required
"that often".

∂27-Jan-87  0407	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	random thoughts   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Jan 87  04:04:33 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 27 Jan 87 10:04-EST
Date: Tue, 27 Jan 87 10:05 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: random thoughts
To: MMcM@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870125165439.1.MMCM@OWL.SCRC.Symbolics.COM>
Message-ID: <870127100539.8.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Sun, 25 Jan 87 16:54 EST
    From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>

    Your example graphics engine is not the only possible hardware
    assistance.  I could well imagine a more symbolic processor in which
    dynamic creation of linked state blocks on a control stack is much
    faster than a full write through to a state in main memory, which might
    require multi-processor synchronization, or who knows what.

(Careful, or you will start to argue that stack-based languages are
inherently superior to object-based languages. :-)

								I see no
    reason to suppose such a processor could not have a graphics engine
    following the same architecture principals.

Sure, but you seem to sidestep my point, which is that much existing
(and near future) graphics hardware works essentially as I described,
and I believe it is important to perform well on that hardware.  Also,
you seem to assume in your proposed architecture that the application
process and the graphics engine are tightly-coupled in hardware, rather
than being potentially separated by a network.  I claim the design
should be predicated on the assumption that a remote console will likely
be implemented as a single thread, multiplexing requests from many
applications.  Assuming a multi-threaded server, much less a server that
has a thread with a mirrored dynamic context for every remote
application thread, is unrealistic.

    Given that we agree that dynamic binding is the right interface for
    application programmers, I do not believe the specification should
    require either shallow or deep binding implementation.

I agree that dynamic binding is an important interface to support, but I
believe that there will be applications for which dynamic binding alone
is inadequate; an explicit notion of graphics state should be possible.

∂27-Jan-87  0450	Freburger.ULC@BCO-MULTICS.ARPA 	Mailing list 
Received: from BCO-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 27 Jan 87  04:50:02 PST
Date:  Tue, 27 Jan 87 10:07 EST
From:  Freburger@BCO-MULTICS.ARPA
Subject:  Mailing list
To:  cl-windows@SU-AI.ARPA
Message-ID:  <870127150751.674800@BCO-MULTICS.ARPA>

Please add me to your mailing list.  My address is:

          freburger@bco-multics.arpa

Thanks.
          - Karl Freburger

∂27-Jan-87  0920	Skef@think.com 	Window system psychomysticism
Received: from ZARATHUSTRA.THINK.COM by SAIL.STANFORD.EDU with TCP; 27 Jan 87  09:17:19 PST
Received: from Godot.Think.COM by zarathustra.think.com; Tue, 27 Jan 87 12:17:24 EST
Received: from wenceslas by Godot.Think.COM via CHAOS; Tue, 27 Jan 87 12:17:15 EST
Date: Tue, 27 Jan 87 12:18 EST
From: Skef Wholey <Skef@think.com>
Subject: Window system psychomysticism
To: RWS@zermatt.lcs.mit.edu, RAM@c.cs.cmu.edu
Cc: cl-windows@sail.stanford.edu
In-Reply-To: <870127094700.7.RWS@KILLINGTON.LCS.MIT.EDU>
Message-Id: <870127121803.1.SKEF@WENCESLAS.THINK.COM>

    Date: Tue, 27 Jan 87 09:47 EST
    From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>

    ...I contend that we should preserve sequentiality, and (as much as
    possible) maintain the illusion of synchronicity...

It seems to me that synchronicity lies somewhat outside the domain of
a window system, a Lisp system, or even an advanced AI system.

Synchronization, on the other hand, is another issue.

(-: Skef :-)

∂27-Jan-87  1739	RICHER@SUMEX-AIM.STANFORD.EDU 	Lisp interfaces to X    
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Jan 87  17:39:35 PST
Date: Tue 27 Jan 87 17:38:57-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: Lisp interfaces to X
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12274386526.33.RICHER@SUMEX-AIM.STANFORD.EDU>

	Now that I understand some of the ways in which Commonlisp interfaces
to X can vary, I'd like to make a strong plea that "we" agree on a
standard Commonlisp interface for version 11 of X. What I think is needed is 
that the vendors (HP, DEC, etc.) that have endorsed X somehow come to agreement
with each other as well as the lisp software vendors (franz, lucid, etc.),
people on the list, and the CL committee.  It should be relatively easy
to standardize this. IF someone disagrees, then they should point out
the areas of interfacing with X where decisions are not arbitrary and have
interesting consequences. Admittedly, I am a (new) consumer of X so I'm
experssing what I assume is the hope of the general user community ("please
standardize"). Those of you that have built lisp interfaces to X either
by using a foreign function-call interface to X or by implementing the
server and Xlib in lisp totally should be the ones to propose a standard
interface. Any volunteers?  

Mark
-------

∂28-Jan-87  0827	dcmartin@ingres.berkeley.edu 	Re: Lisp interfaces to X 
Received: from INGRES.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87  08:26:48 PST
Received: by ingres.Berkeley.EDU (5.57/1.14)
	id AA19091; Wed, 28 Jan 87 08:26:02 PST
Message-Id: <8701281626.AA19091@ingres.Berkeley.EDU>
From: "David C. Martin" <dcmartin@ingres.berkeley.edu>
Office: 440 Evans - x2-9585
Home: 2441 Haste St #37, Berkeley, CA 94704 - (415) 843-6470
Fortran: is not backward, NARTROF is backwards.
To: Mark Richer <RICHER@sumex-aim.stanford.edu>
Cc: cl-windows@sail.stanford.edu
Precedence: priority-mail
In-Reply-To: Your message of Tue 27 Jan 87 17:38:57-PST
Subject: Re: Lisp interfaces to X
Date: 28 Jan 87 08:25:59 PST (Wed)
Sender: dcmartin@ingres.berkeley.edu

I agree with Mark Richter in that some sort of CL interface w/ X version 11
as the support base should be the standard of choice.  Seeing how much
publicity CommonWindow's has received, and after reviewing the document, there
appears to be quite a number of things that Xv11 will provide which 
CommonWindows will not exploit.

I have built a 60% complete interface between X (version 10) and Common LISP 
using the foreign function system from Franz, Inc.  This code has some 
improvements over the standard C library (e.g. allowing non-blocking reads 
from the event stream) and some extensions particular to UNIX (e.g. allowing
the programmer to get the DISPLAY environment variable).  However, there are
some major problems that I have encountered in using the C libraries as the
support mechanism for my CL.  Most notably the pain involved in allocating
and deallocating the necessary C data structures and maintaining these
structures in some coherent fashion.

There is also the major problem of the sheer size of CL.  Since the ExCL
binary requires over 4MB of memory after my X stuff is loaded, I can only
run one application under each CL.  Another member of the group has built
a portable scheduler for CL which allows "sub-processes" to run on an event
driven priority (i.e. the scheduler gets an event from the X server, starts
the appropriate sub-process, which runs until it decides to stop, then the 
scheduler repeats).  It would seem that some notion of context switching 
still needs to be addressed as a standard extension to CL.

The method that I have used in building my X package is to provide the
same basic names as the C library functions for X.  In some cases the
arguments are optionalized, or have been extended to provide more 
functionality, but the basic naming scheme and calling conventions remain
pretty much the same.  There is no standard for the naming or arguments for
the library functions per se, in either X version 10 or version 11, and perhaps
that is something that the people at MIT should think about.  There is a
specification of that the protocol will support and what the arguments and
types are, but there is nothing in the specification (unless I totally
missed it).

Since people may be wanting to use either X or NeWS, and since the X 11
protocol seems to allow almost everything you ever wanted to do with
a window (but were afraid to ask), I propose that the basic X version 11
protocol become the base standard for CL.  Then the only question to figure
out is what are the standard extensions.  The "problem" of naming could be
easily rectified by simply adopting the protocol naming scheme.

Comments?

dcm
-----
David C. Martin
-----
Computer Science Division
University of California
Berkeley, CA 94720
-----
arpa: dcmartin@ingres.Berkeley.EDU
uucp: {ihnp4,decvax}!ucbvax!dcmartin
at&t: 415/642-9585 (O)

∂28-Jan-87  0902	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	Re: Lisp interfaces to X    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87  09:02:02 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 28 Jan 87 11:59-EST
Date: Wed, 28 Jan 87 12:00 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: Lisp interfaces to X
To: dcmartin@INGRES.Berkeley.EDU, RICHER@SUMEX-AIM.STANFORD.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <8701281626.AA19091@ingres.Berkeley.EDU>
Message-ID: <870128120042.3.RWS@KILLINGTON.LCS.MIT.EDU>

I think a vanilla translation of the V11 C library into Lisp
is almost certainly the wrong thing.  Certainly implementing
via a foreign function interface to the C library is the wrong
thing.  Some attempt at making a rational OOP interface is
called for, as well as deciding things like keyword arguments
and dynamic binding models.  I would agree that an X-specific
interface is a useful first step towards something more
general, and will satisfy immediate needs at numerous sites.

∂28-Jan-87  0953	dcmartin@ingres.berkeley.edu 	Re: Lisp interfaces to X 
Received: from INGRES.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87  09:51:40 PST
Received: by ingres.Berkeley.EDU (5.57/1.14)
	id AA19796; Wed, 28 Jan 87 09:49:02 PST
Message-Id: <8701281749.AA19796@ingres.Berkeley.EDU>
From: "David C. Martin" <dcmartin@ingres.berkeley.edu>
Office: 440 Evans - x2-9585
Home: 2441 Haste St #37, Berkeley, CA 94704 - (415) 843-6470
Fortran: is not backward, NARTROF is backwards.
To: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Cc: RICHER@sumex-aim.stanford.edu, cl-windows@sail.stanford.edu
Precedence: priority-mail
In-Reply-To: Your message of Wed, 28 Jan 87 12:00 EST
Subject: Re: Lisp interfaces to X
Date: 28 Jan 87 09:48:59 PST (Wed)
Sender: dcmartin@ingres.berkeley.edu

True, a vanilla translation would buy you nothing, but some sort of lowest
level implementation should be decided upon for the library interface.  As
for an OOP system, that is what I am working on using Common LOOPS.  Currently
I have about 60% of the X system OOified and am working on more as the needs
of the application people in my group increase.  I don't think that an OOP
interface is necessarily the end result of any work done, since some people
will not wish to use an OO system.

I would like to know what you (specifically) and others want to see in an
initial, low level, X Common LISP library.  I am not a LISPer of long standing,
so my guidelines have come from the LMI Window spec and input from people here
at Berkeley (and Franz).  Currently all I am doing is a vanilla X/CL interface 
with some new functions (which take keywords).  Granted that the foreign 
function stuff is gross and a pain to work with, but it has so far been hidden 
from the application level.

Some of the questions I have are regarding things like stream based windows,
the UNIX interface (getenv, etc...) and what additional functionality a LISP
programmer wants beyond what a C programmer wants.  I know that latter, but
not the former.

Thanks.

dcm

∂28-Jan-87  1242	RICHER@SUMEX-AIM.STANFORD.EDU 	Re: Lisp interfaces to X
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87  12:41:07 PST
Date: Wed 28 Jan 87 12:40:35-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: Re: Lisp interfaces to X
To: dcmartin@INGRES.BERKELEY.EDU
cc: cl-windows@SAIL.STANFORD.EDU, RICHER@SUMEX-AIM.STANFORD.EDU
In-Reply-To: <8701281626.AA19091@ingres.Berkeley.EDU>
Message-ID: <12274594352.81.RICHER@SUMEX-AIM.STANFORD.EDU>

One thing David didn't mention in regard to a Lisp/X interface was brought
to my attention by Marty Cagan of HP. I believe he told me that there
are cases where it's not unambiguous what the Lisp version of an XLib
function returns (i.e., there is a somewhat arbitrary decision as to what
kind of value the lisp function returns). Anyhow this should be standardized
as far as I can see. My goal is that I can move source code to any CL
environment without any modifications to the code (Isn't that an obvious
goal!) so I want every necessary detail standardized.

I definitely agree with David's comments about Intellicorp's Commonwindows.
I don't think their proposal should be accepted as a Commonlisp standard,
but I do support the idea that all the vendors provide it. Obviously X
has many advantages as a standard, but I don't think that it should be
an official extension to the language. I view it like GKS .. I think there
should be standard language bindings for things like X, and even standard
user interface toolkits based on X (and COmmonloops). As far as I know
there is no official lisp language binding for GKS. I am not a GKS user so I 
don't want to get into that specifically, but I think that it's important
that the Commonlisp world adopt industry standards and establish official
language bindings. Because X is probably going to be very widespread now,
I think this is crucial. I guess I should mention for those of you that
didn't hear the announcement, X has been endorsed as a standard by 11
companies including HP and DEC. Adobe also plans to make postscript extensions.
ALthough IBM and SUN were absent from the announcement, X is already
available on the IBM-RT and SUN workstations anyhow. SO there is no question
that X is here to stay for awhile. I think we should endorse it, though I
feel comfortable with SUN's position of not exclusively endorsing X. I
don't think we are ready for that and I don't think it's necessary. The
important thing is that it's available on most hardware and that all
commonlisp users have access to the standard version. Let's face it
de-facto standards work fairly well. At the same time, we should continue
exploring future directions wrt windowing environments and standards.

Finally, I think that Commonwindows can be implemented in X as one high-level
interface (both programmer and end-user interface as I see it). THis
should satisfy INtellicorp. ANd it buys everyone network-based and
remote graphics capabilities as well via X's functionality which is absent
in COmmonwindows as far as I know (As an aside I'm not an expert on the
Commonwindows proposal as IC refused to send me the document! That's a
good way to establish a standard. But  I was told by a reliable source that
it's basically the same as the Interlisp window system which I am
intimately familiar with. No surprise if you have seen KEE demos on non-Xerox
hardware.)

Mark
-------

∂28-Jan-87  1246	primerd!doug@enx.prime.pdn 	Re: Lisp window systems standardization   
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87  12:45:53 PST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA20941; Wed, 28 Jan 87 15:32:42 EST
Received: by prime.uucp (1.1/SMI-3.0DEV3)
	id AA27090; Wed, 28 Jan 87 14:19:09 EST
Message-Id: <8701281919.AA27090@prime.uucp>
Received: (from user DOUG) by ENX.Prime.PDN; 28 Jan 87 13:31:34 EDT
Subject: Re: Lisp window systems standardization
To: cl-windows@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 28 Jan 87 13:31:35 EDT

I believe that it is far too early to standardize a window system for
CommonLISP.  Some progress has been made in the general window arena
in that X has been accepted by a large audience as a good window
server.  This actually doesn't affect the kind of window system that
people want to use from a language like LISP. 

A LISP window system would provide higher level concepts for the programmer
to use in the presentation of data and the processing of input from the
user.   The programmer in such a system would generally want insulation
from the details of the implementation.  Hopefully such a system could
exist equally well on X or some other system such as NEWS with minimal
changes to representation of basic objects (icons, fonts, etc.).  

As RWS points out such a system would probably use object programming
(as indicated by Symbolics' success in this area).

It seems that this is a ripe area for experimentation and that folks
like David Martin (BOOL) are doing just that sort of experimentation.  
This isn't a time where the experimentation has yielded the kind
of results where one can produce a standard.

Cheers,

Doug 
(dougr@eddie.mit.edu <- Despite my apparent return address).

∂28-Jan-87  1356	FAHLMAN@C.CS.CMU.EDU 	Lisp interfaces to X   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87  13:55:46 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 28 Jan 87 16:55:03-EST
Date: Wed, 28 Jan 1987  16:54 EST
Message-ID: <FAHLMAN.12274607897.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: Lisp interfaces to X
In-reply-to: Msg of 28 Jan 1987  15:40-EST from Mark Richer <RICHER at SUMEX-AIM.STANFORD.EDU>


Let's be careful with this word "standard".

There is no chance whatsoever that Common Lisp is going to require X, or
anything like it, in the forseeable future.  Common Lisp runs on all
sorts of machines: mainframes, PC-oids, and machines that have never
heard of graphics, let alone X.  Also, X is very new, X11 is not out
yet, the Common Lisp Object Standard is not out yet, and I don't think
any of us has enough experience with this to know what kind of
high-level interface we really want on multiple-process,
multiple-language workstations.  Before you can even think about a
standard, you've got to have a consensus.

On the other hand, a lot of Common Lisp work will be done on unix-based
machines that support X, interfaces to X will be built, and it would be
too bad if each of these Common-Lisp-to-X interfaces were gratuitously
different.  So it is worthwhile to try to coordinate our efforts here;
by so doing, we can minimize duplication of effort and maximize the
portability of code between these X-based systems.

Something like the following sequence of events might make sense:

1. We try to agree among ourselves on what the lowest-level X11
interface should look like, for those systems that have one.  We try to
get our respective Lisp systems to implement this agreement.  This
interface may or may not involve object-oriented stuff, but it should
not get into uncharted and controversial territory.  Code will be
portable on top of this interface.  If successful, this will eventually
become an informal de facto standard for low-level Common-Lisp-to-X
interface, but not a required part of the Common Lisp standard.

2. We should experiment with higher-level abstractions and packages on
top of this common base, sharing code as much as possible.  Probably one
approach will eventually emerge as "the right thing"; maybe a couple of
competing systems will emerge.  In order to gain acceptance, such
systems must be readily available on a lot of machines; if people can't
get the sources to a system and run it on their own machines, that
system will contribute very little to any emerging consensus.

3. If a consensus emerges on higher-level window and graphics concepts,
and some portable code is available to implement these concepts, then we
can start talking about a standard in this area.  It may be that, at
some suitable level of abstraction, the specific dependence on X will
disappear.  But this will not happen soon, and arguing about the shape
of this ultimate window/graphics systems is probably not fruitful right
now.

-- Scott

∂28-Jan-87  1429	TAYLOR%PLU@ames-io.ARPA 	Window Systems Survey    
Received: from AMES-IO.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jan 87  14:28:21 PST
Received: from PLU by IO with VMS ;
          Wed, 28 Jan 87 12:55:21 PST
Date:    Wed, 28 Jan 87 12:55:21 PST
From:     TAYLOR%PLU@ames-io.ARPA
Subject: Window Systems Survey
To:       @w_survey

The following request was posted to AILIST & SLUG bulletin boards:

***************>>>>>

We have been developing a user interface for a planning/scheduling
application on the Symbolics, using Version 6.1 windows and flavors.
For future long term development of the user interface, we are
considering a possible change of the window system, before converting
to Genera 7.0 Dynamic windows and Presentation types.  We have heard
mention of XWINDOWS and are interested in knowing about it and other
"generic" window systems and the trade-offs between specialized
features and portability.
Issues we are looking at:
	o will window system be compatible with a future Common
	  lisp window standard
	o will window system be portable between lisp machines and
	  AI work stations, e.g. Symbolics, TI, LMI, Xerox, Sun, ..
	o how much conversion will be required to go from current
	  implementation, now running under Genera 7.0, to a new
	  window system
	o what are advantages/disadvantages of potential window
	  systems as far as ease of implementation, facilities
	  available to present information to user, use of object
	  oriented techniques, etc
	o availability of potential window systems on the Symbolics

Opinions and recommendations are solicited from Lisp machine users
as to their experience and preferences.  Please respond by e-mail.
I will summarize for this bboard if requested and sufficient responses
are received.  

**********<<<<<<<<<

Below are the significant responses (total responses were 10). This
summary is being posted to SLUG, Common-windows, Xpert (XWINDOWS) and
those who specifically requested it.

	--------------------------------------------------------


From: James J Dempsey <jjd@ALEXANDER.BBN.COM>
 
Do you ask about X windows because you have heard of someone porting X
windows to the Symbolics?  
 
If it were up to me, I would always use a portable standard (like X
windows) instead of a propriatary system (like Symbolics Window
system).  Right now our application is tied to symbolics machines and
can't be ported, mainly because of our use of the window system.
 
Intellicorp wrote their own window system so that KEE would be
portable across machines, including the window system.
 
If you have heard of X being available (or under development) for the
Symbolics, I would appreciate hearing about it.
 
		--Jim Dempsey--
		BBN Communications

[ I did not hear of X being available on the Symbolics and I imagine the
  largest stumbling block to be that X is written in the C language and
  no C compiler exists for the Symbolics (correct ?)- Will]

------*******

From: Connie K. Brede <BREDE@SRI-STRIPE.ARPA>
 
I have no info to offer concerning your query, but am very much interested in
the recommendations you recieve.  I have been working on user interface
facilities for applications on Symbolics release 6.x and Xerox/InterLisp-D, and
i would really like to find a common base to work from.
 
------*******

From: mike@etl-ai.ARPA (Mike McDonnell)
 
As far as I know, the window system of the Symbolics is the part of the system
that is *least* likely to be compatible with some future Common-Lisp standard.
The single point of compatibility that is forseeable is that any window
standard will almost certainly be based on the yet-to-be-decided object-
based CL standard.  A good bet is that this object standard will much resemble
the Genera 7 "new flavors", but since Symbolics has not yet implemented their
window system in new flavors, any future standard will almost certainly be
incompatible with the present Symbolics window system.
 
So, then, is there a portable window system that is good on the Symbolics and
on other machines?  In particular, what about X windows?  Sorry, but as far 
as I know (and I don't know much) there are too many differences in the whole
philosophy and design of flavor-based window systems and other kinds of
windows, such as X windows, for there to be a means of changing one into the
other.  Because of this bleak situation, there are several more-or-less heroic
attempts to bridge this yawning gap.  Typical is Intellicorp's [usual
disclaimer] implementation of their own window system on top of whatever is
available on the host system so that they can port their products to various
systems while still programming to a consistent interface.  This is hardly
ideal though, since the extra layer slows things down and adds complexity.  And
developers still have to master each of the underlying window systems anyway.
 
My prejudice is that objects are the ideal paradigm for window systems since
inheritance allows you to easily extend and tailor the functionality of
windows.  I do most of my programming on a Symbolics [disclaimer], but I have
done a lot of Unix programming too and do understand the differences between
the methods used on these systems.  Because of this, I would stay with
flavor-based windows with the vastly increased programmer productivity in that
environment, and take my chances with the future.  Immediate commercial
considerations would make me change my mind, but we don't have commercial
considerations in the government :-).
 
------*******

From: Arun Welch <Welch%OSU-20@ohio-state.ARPA>
Lisp Systems Programmer, Lab for AI Research, Ohio State University

 We've been looking at pretty much the same issues here, and it looks
pretty bad.  Most of our software has been written on Xerox
d-machines, and we're in the process of re-writing it with portability
in mind. From my experience, here are some answers to your questions:  
 
>
>	o will window system be compatible with a future Common
>	  lisp window standard
Last I heard, the work on a window system standard (Common-Windows)
was bogged down.  If you want to get on the mailing list, the address
is CL-WINDOWS-REQUEST@SAIL.STANFORD.EDU.  Otherwise, I haven't seen
any compatibility between any of the window systems.  The Lucid and
the Xerox windows share a windowing philosophy which is different from
that shared by the TI and Symbolics worlds, but that's about as far as
it goes.  The TI and Symbolics are fairly close, as of version 6, but
were diverging fast...
 
>	o will window system be portable  between lisp machines and
>	  AI work stations, e.g. Symbolics, TI, LMI, Xerox, Sun, ..
Nope.
>	o how much conversion will be required to go from current
>	  implementation, now running under Genera 7.0, to a new
>	  window system
I don't know about this one.
>	o what are advantages/disadvantages of potential window
>	  systems as far as ease of implementation, facilities
>	  available to present information to user, use of object
>	  oriented techniques, etc
I'm a fanatic about the Interlisp window philosophy, myself, so I'm
warning you that I'm biased towards them as far as ease of use, etc. goes.  
>	o availability of potential window systems on the Symbolics
>
Once again, I don't know.
 
I wish I could help you more.  We're in the *early* development stages
of developing our own portable window system, overlaid on the inherent
window systems of the target machines, using either CommonLoops or a
reasonable subset thereoff. However, since CommonLoops itself is in a
fair state of flux, even that is up in the air. Hopefully I'll have
something more in 6-9 months (I better :-).
 
Intellicorp has done some work in this area,  but aren't releasing
anything. I have a copy of their draft manual, dated June 1986, but
haven't heard about any updates, nor is it complete.  I don't know
about the availability of the manual, either (As I said, I got a draft
copy). I don't know how much has been implemented, either.
 
I'd be interested in any info you get.  I hope it doesn't end up that
a lot of people are duplicating work all over the place.
 
------*******

From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
 
There is a mailing list on commonlisp windows that discusses issues
such as the ones you raise and a bunch of people that use or are interestsed
in X windows are on the list. I have remailed your message, perhaps you will
get a response from someone there.  It would be appropriate if this
discussion moved there.
 
The list is cl-windows@sail.stanford.edu  To get on send a request to
cl-windows-request@sail.stanford.edu.
 
There is also a list on X called xpert@athena.mit.edu. Send to xpert-request
to get on that one.
 
------*******

Phone call from Ken Tidwell, Intellicorp (415)965-5500

[ If there are any inaccuracies in the following condensation of
  the conversation, I apologize to Ken and would appreciate being
  corrected - Will]

Ken is one of the designers of Intellicorp's Common Windows (CW).
CW is a part of KEE 3.0 (Relase 6.1 Symbolics).
KEE 3.0300 (Genera 7.0 Symbolics) will be out in 2-3 months.
NeWS (Sun) & XWINDOWS are C based. XWINDOWS is very basic, has no tool
kit facilities - is available on HP, Sun, Dec.  CW is common
lisp based & is proposed as a standard for common lisp windows.  CW is not 
currently sold separately from KEE 3.  KEE 3 is available on Symbolics,
LMI, TI, Xerox, Sun, Vaxstation and IBM/PC-VAX.

Franz, Inc. and Lucid are working on common lisp based window systems
which may be available by the end of 1987. Sun is also working on a
window system, based on NeWS.

Requests to Intellicorp for possible unbundling of CW from KEE should
be directed to Dan Gottlieb - (415)965-5500

------*******

From: ihnp4!mmm!rouner@ucbvax.Berkeley.EDU (Bill Rouner)
Organization: Software & Electronics Resource Center/3M
Bill Rouner, SERC SW R&D, 3M Company (612)733-9086
 
We have the same concerns as you do.  An additional concern is legal
protection (copyright or patent).  One proposal I encountered was the
development of the APPLE Macintosh window toolbox calls in Common Lisp.
While the Macintosh interface is widely accepted among the user community,
we shied away because of the potential legal liability.
 
There are two window facilities that are being promoted:  SUN windowing
facility and the recently introduced KEE Pictures window facility from
Intellicorp.  At this time neither appear to be making headway.  It seems
unlikely that any window system will get firmly established until a "standard"
object oriented facility (e.g. CommonLOOPS, Symbolics new FLAVOR) is adopted.
 
------*******

Feedback on this information would be appreciated - Will

--------------------------------------------------------------------------
   Will Taylor - Sterling Software, MS 244-7,
		 NASA-Ames Research Center, Moffett Field, CA 94035
   arpanet: taylor%plu@ames-io.ARPA 
   usenet: ..!ames!plu.decnet!taylor
   phone  : (415)694-6525

∂28-Jan-87  1430	RICHER@SUMEX-AIM.STANFORD.EDU 	Re: Lisp interfaces to X
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87  14:30:25 PST
Date: Wed 28 Jan 87 14:30:09-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: Re: Lisp interfaces to X
To: Fahlman@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12274607897.BABYL@C.CS.CMU.EDU>
Message-ID: <12274614300.81.RICHER@SUMEX-AIM.STANFORD.EDU>

I agree with Scott 100%. If I didn't make it clear: I DO NOT THINK THAT
CL SHOULD REQUIRE X. But I do think there should be a standard
programmer interface on all hardware. And I want the code portable not
just to unix machines but to lisp machines and VMS on the Vax, etc. I
think that is what SCott is saying also(I hope).

Hopefully, we can reach consensus on this list wrt this matter, but I'd
really like to see the hardware and software vendors endorse and support
this also .. otherwise it's a drag. For example, let's say company A
supports X and provides a lisp interface. They also provide some neat
tools. Meanwhile, someone offers me some neat CL/X stuff they have done,
but they are working on top of a slightly different X interface. It
would be a senseless pain to have to figure out and make the modifications.
Obviously it wouldn't be a great intellectual challenge to do this, but
it's the kind of time-consuming and tedious work I think we all want to
avoid. By the way, I wouldn't be bringing the issue up if I didn't see that
different interfaces are being developed independently already.

After we standardize on a low-level interface to X, I agree then we can
take more time to discuss higher-level interfaces. BUt even for a low-level
interface we need to consider what Scheifler said: perhaps, corresponding
lisp functions for every C function in Xlib may not be a good idea as
the low-level interface.  However, I think we should proceed and agree
on a foreign function call interface for V11/unix people in the meantime,
but we need to resolve the issue Bob raised soon.

Mark
-------

∂29-Jan-87  1114	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	Me 'n X (ignore if you like)
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jan 87  06:31:12 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jan 87 09:30-EST
Date: Thu, 29 Jan 87 09:32 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Me 'n X (ignore if you like)
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870129093237.6.RWS@KILLINGTON.LCS.MIT.EDU>
Comment: Remailed at SU-AI after delay caused by mailing list error.

    From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
    My understanding is that you are implementing X11 on a lisp machine ...

Just to set the record straight, I am engaged (as time permits) in building
a Version 11 server in (extended) CL, initially targeted at running on Symbolics
and TI lispms executing inside one of their system's windows.  I have also
been experimenting with slipping X in under the covers of the existing Symbolics
window system, so that "native" applications can be used across a network
without any application modifications.  I am NOT engaged in building a programming
interface to X.

    From: "David C. Martin" <dcmartin@ingres.berkeley.edu>
    I would like to know what you (specifically) and others want to see ...

There are about 37 other aspects of X (plus my "real" research) keeping me busy;
I don't have the time to design a Lisp interface (but I would like to stay tuned
in and offer my two cents when I can), and I believe there are people out there
who can do a better job of it than me anyway.

∂29-Jan-87  1114	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	foreign function interfaces 
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jan 87  06:58:20 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jan 87 09:58-EST
Date: Thu, 29 Jan 87 09:59 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: foreign function interfaces
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870129095954.8.RWS@KILLINGTON.LCS.MIT.EDU>

I will repeat myself: I don't really understand why people think a ffi
is either "the easy thing" or "the right thing".  Most of the C Xlib is
stupid repetitive packet formatting, which can be almost completely
replaced in Lisp with a few well-chosen macros.  If you just want a
straight native Lisp equivalent of Xlib, it could easily be put together
in a week (I assert, having crufted lots of it together for V10, and
having done the equivalent on the V11 server side "for real" recently),
and you end up with something that is FAR more portable.

∂29-Jan-87  1114	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	X interface  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jan 87  07:47:17 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jan 87 10:46-EST
Date: Thu, 29 Jan 87 10:48 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X interface
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870129104842.9.RWS@KILLINGTON.LCS.MIT.EDU>

The C Xlib was designed without any thought given to multiple execution
threads.  I hope a Lisp interface will be designed with concurrency in
mind (but without requiring multiple threads); I would hate to see two
different interfaces evolve.

Just as one example, note that X has asynchronous errors; will the
interface undertake to dispatch errors back to the appropriate thread?

In the Unix world one is almost forced to think of IPC as the only link
to an X server (console).  In a lispm world (which is what we all
desire, right? :-) , it is natural to assume that (eventually) the most
commonly accessed X server will be just another collection of objects
and threads in your address space.  One would like clients to have
direct access to the server objects, without imposing a (shared-memory)
channel between the client and some server thread.  This certainly has
implications for the structure of the server, but it would seem to
affect the structure of a programming interface as well.  For example,
will you want local clients to pay the overhead of the resource-id to
server-object translation, or of packet formatting?  If you believe the
local case should be have more "direct" links, then it would seem you
want the programming interface to present some sort of (object)
abstraction to resources, since resource ids alone won't be the only
coin for communication.

However, there are some problems with defining an interface in terms of
anything but resource ids.  (These same problems came up in early C Xlib
discussions, which is why Xlib looks the way it does.)  Resource id
transmission is not a one way street; there are various ways in which
the server can hand them back to you.  For example, device events are
reported not only with the "event" window id but also with a child
window id.  If you try to hide resource ids from the application, then
any ids coming back from the server should also be hidden, which means
you need a reverse mapping.  How is this mapping maintained?  How is it
garbage collected?  If the application-level manifestation of the
resource has embedded state, how do you decide which thread's or
activity's manifestation to reverse map to?

This in part depends on your point of view about how event dispatching
should work.  Is there a single event queue that threads pull things off
of, or are events automatically dispatched to per-window or per-thread
queues, or does each window have associated with it a "call-back"
function for each event type (and what thread is that function called
within?)

∂29-Jan-87  1212	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	foreign function interfaces 
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jan 87  06:58:20 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jan 87 09:58-EST
Date: Thu, 29 Jan 87 09:59 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: foreign function interfaces
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870129095954.8.RWS@KILLINGTON.LCS.MIT.EDU>

I will repeat myself: I don't really understand why people think a ffi
is either "the easy thing" or "the right thing".  Most of the C Xlib is
stupid repetitive packet formatting, which can be almost completely
replaced in Lisp with a few well-chosen macros.  If you just want a
straight native Lisp equivalent of Xlib, it could easily be put together
in a week (I assert, having crufted lots of it together for V10, and
having done the equivalent on the V11 server side "for real" recently),
and you end up with something that is FAR more portable.

∂30-Jan-87  1325	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: Lisp interfaces to X   
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 30 Jan 87  12:59:21 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 44459; Wed 28-Jan-87 17:11:09 EST
Date: Wed, 28 Jan 87 17:08 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Lisp interfaces to X
To: RICHER@SUMEX-AIM.STANFORD.EDU, dcmartin@INGRES.BERKELEY.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <12274594352.81.RICHER@SUMEX-AIM.STANFORD.EDU>
Message-ID: <870128170819.5.DLW@CHICOPEE.SCRC.Symbolics.COM>

Is it possible to get an up-to-date specification of Intellicorp's
"Commonwindows" interface?

∂31-Jan-87  0956	meltsner@athena.MIT.EDU 	Vendors and X + LISP
Received: from CHARON.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Jan 87  09:56:47 PST
Received: by CHARON (5.45/4.7)
	id AA03272; Sat, 31 Jan 87 11:57:28 EST
Message-Id: <8701311657.AA03272@CHARON>
To: cl-windows@sail.stanford.edu
Subject: Vendors and X + LISP
Date: Sat, 31 Jan 87 11:57:24 -0500
From: meltsner@athena.MIT.EDU


One should not ignore the fact that Common LISP vendors may wish to 
support X only as part of their existing window system.  For example,
Lucid's sales rep told me they do plan to make an X version of their 
window system as soon as their current backlog of work is completed.
Unfortunately, I gather this will be simply their generic window system
(same on Apollos, RT/AIX, Suns, etc.) rather than a true X port.  Now,
while the former means more transportability of code for Lucid customers,
the latter would be more what (I think) people on this list want.

			Ken

∂04-Feb-87  1547	Ehrlich@YUKON.SCRC.Symbolics.COM 	Window Systems Survey     
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 4 Feb 87  15:46:56 PST
Received: from SWAN.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 158862; Wed 4-Feb-87 18:43:14 EST
Date: Wed, 4 Feb 87 18:42 EST
From: Kate Ehrlich <Ehrlich@YUKON.SCRC.Symbolics.COM>
Subject: Window Systems Survey 
To: cl-windows@SU-AI.ARPA, slug@UTEXAS-20.ARPA
cc: TAYLOR%PLU@AMES-IO.ARPA, ehrlich@YUKON.SCRC.Symbolics.COM
Supersedes: <870204154907.1.EHRLICH@SWAN.SCRC.Symbolics.COM>
Message-ID: <870204184256.2.EHRLICH@SWAN.SCRC.Symbolics.COM>


	From:  TAYLOR%PLU@ames-io.ARPA

	We have been developing a user interface for a planning/scheduling
	application on the Symbolics, using Version 6.1 windows and flavors.
	For future long term development of the user interface, we are
	considering a possible change of the window system, before converting
	to Genera 7.0 Dynamic windows and Presentation types.  We have heard
	mention of XWINDOWS and are interested in knowing about it and other
	"generic" window systems and the trade-offs between specialized
	features and portability.

In order to evaluate various window systems, specifically the Genera 7.0
Window System and X-Windows, it is necessary for you to appreciate that
X-Windows operates at a much lower level of abstraction than the Genera
7.0 Window System.  This means that far from the various systems being
antagonistic, they can actually work together, albeit at different
levels.  In the current Genera 7.0 Window System the lower levels are
handled by sheets.

The Genera 7.0 Window System is specifically designed to allow the
application program to be written at a higher level of abstraction,
insulating a programmer from changes to the substrate. That is, changes
to the substrate should have minimal or no effect on your existing
window system code. Symbolics intends to support its higher level window
system on top of any Common Lisp standard or a Common Lisp standard
built on top of an X virtual console specification.

We are working with people from Xerox and Lucid on what is now called
the "Common Lisp Object System", a proposed object-oriented programming
standard based on ideas from both "CommonLoops" and New Flavors. We are
also carefully monitoring work on X-Windows and Common Lisp standard
window systems.  Symbolics has a long history of actively promoting and
contributing to standards.  Programmers using the Genera 7.0 Window
System will not be locked out of future window systems standards.

Incidentally, the issue of C raised by one of your respondents is
largely irrelevant. X is a standard, for which there is an
implementation in C.  Any Symbolics support for X would be in Lisp.

∂06-Feb-87  1311	BATALI@SPAR-20.ARPA 	please add me 
Received: from [128.58.1.2] by SAIL.STANFORD.EDU with TCP; 6 Feb 87  13:03:10 PST
Date: Fri, 6 Feb 1987  11:28 PST
From: John Batali <BATALI at FLAIR-20>
To:   cl-windows at sail
subject: please add me
reply-to: batali@mit-mc

to the cl-windows mailing list.

	John Batali
	BATALI@MIT-MC

∂11-Feb-87  1658	DON%atc.bendix.com@RELAY.CS.NET 	Bulletin board subscription
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 11 Feb 87  16:57:45 PST
Received: from relay2.cs.net by RELAY.CS.NET id cl00964; 11 Feb 87 15:37 EST
Received: from atc.bendix.com by csnet-relay.csnet id aa09198;
          11 Feb 87 13:45 EST
Date:     Wed, 11 Feb 87 08:30 EST
From:     DON%atc.bendix.com@RELAY.CS.NET
To:       common-lisp-request%su-ai.arpa@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU, 
          works%rutgers.arpa@RELAY.CS.NET
Subject:  Bulletin board subscription
X-VMS-To: IN%"common-lisp-request@su-ai.arpa",IN%"cl-windows@sail.stanford.edu", IN%"works@rutgers.arpa"

Please add

	aisubscriber@atc.bendix.com
or	aisubscriber%atc.bendix.com@csnet-relay.csnet

to your bulletin board list.  (Use whichever address your site supports.)

Don Mitchell

∂13-Feb-87  0636	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	X atoms, a poll   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87  06:35:55 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 13 Feb 87 09:35-EST
Date: Fri, 13 Feb 87 09:38 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X atoms, a poll
To: cl-windows@SAIL.STANFORD.EDU
cc: xpert@ATHENA.MIT.EDU
Message-ID: <870213093807.6.RWS@KILLINGTON.LCS.MIT.EDU>

X Version 11 has a concept of "atoms", which act somewhat like
symbols in Lisp.  Atoms get used to name various things, like
window properties.  The protocol specifies that upper/lower
case matters when interning an atom.  The protocol also gives
numerous predefined atoms that are expected to be commonly
used, to avoid needless queries from clients to discover their
interned numeric value.

X/V11 is going into alpha test with the following sorts of atoms:
	Bitmap  PointSize  StrikeoutAscent
Note the use of case.

It has been suggested that in the Lisp interface to X it would
be natural and useful to use (or at least allow) real keyword
symbols everywhere, and to hide the existence of atoms "inside"
the Xlib-equivalent interface by maintaing a (hash) table mapping
between keywords and X numeric atom values.  For this to be "natural",
I assume that keywords like:
	:bitmap  :point-size  :strikeout-ascent
would be preferable to:
	:|Bitmap|  :|PointSize|  :|StrikeoutAscent|
meaning the more "natural" atom names would be:
	BITMAP  POINT-SIZE  STRIKEOUT-ASCENT
or
	bitmap  point-size  strikeout-ascent

The problem is that C programmers want their #define names to
match the corresponding string values, and you can't use hyphens
in C names, and on the Lisp side the mapping needs to be 1-to-1 and
reversible.  A suggested compromise was to use underscore, which is
legal in C, but the problem is that underscore is left open to
reinterpretation in CL.  However, in Lisp we could use a reversible
mapping of always replacing hyphens with underscores when converting
from keyword to atom, and replacing underscores with hyphens when
converting from atom to keyword.

It is not too late to change the pre-defined atoms in X.  All
suggestions and comments on the proposed underscore/hyphen
solution, or alternate proposals, would be extremely welcome.

∂13-Feb-87  0808	FAHLMAN@C.CS.CMU.EDU 	X atoms, a poll   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87  08:08:02 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 13 Feb 87 11:06:43-EST
Date: Fri, 13 Feb 1987  11:06 EST
Message-ID: <FAHLMAN.12278738788.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU, xpert@ATHENA.MIT.EDU
Subject: X atoms, a poll
In-reply-to: Msg of 13 Feb 1987  09:38-EST from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>


This is a special case of the problem of building Lisp-to-C interfaces
in general.  We've been doing this at CMU for a while, using a variety
of tools, collectively called "Matchmaker".

X11 is being designed with some consideration for Lisp built-in, but the
overwhelming majority of C programs are not.  So automatic
interface-building tools need some automated way of handling the
"BiteTheBag" naming convention that is common among users of C and
Pascal.  We can't depend in general on C programmers to use
"Bite_The_Bag", so none of our tools assume this.

Our solution on name conversion has been to use the C names as is,
though case information is lost, rather than getting into the game of
hacking hyphens and underscores.  So the C symbols named "BitMap",
"PointSize", and "StrikeoutAscent" become ":bitmap", ":pointsize", and
":strikeoutascent".  That's a bit ugly, but workable, and less confusing
than using underscores on the C side and hyphens on the Lisp side.

The one strong assumption here is that the C people will not depend on
case for anything more than decoration.  If the C program has two
distinct symbols named "Foobar" and FooBar", then we lose.  The best we
can do is to catch these cases and ask the user what Lisp-side names he
wants to use for the two conflicting symbols.  I hope that, whatever is
decided about naming conventions, the X11 designers will not define
distinct symbols that differ in case only.

An alternative approach is to automatically insert a hyphen whenever the
C version has an upper-case character that is not at the start of the
word.  So "IgnoreThisObject" becomes ":ingore-this-object".  That's a
bit more readable, is a reversible transformation, and doesn't require
the C people to alter their naming conventions.  It does require the C
people to be totally consistent in their use of the "FooBarBarf" naming
style.  Something like "README" causes b-i-g trouble.  We considered
doing this in our own Lisp-to-C interfaces, but decided it wasn't worth
putting Matchmaker to the extra trouble.

-- Scott

∂13-Feb-87  0859	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	X atoms, a poll   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87  08:59:00 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 13 Feb 87 11:48-EST
Date: Fri, 13 Feb 87 11:51 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X atoms, a poll
To: Fahlman@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU, xpert@ATHENA.MIT.EDU
In-Reply-To: <FAHLMAN.12278738788.BABYL@C.CS.CMU.EDU>
Message-ID: <870213115105.3.RWS@KILLINGTON.LCS.MIT.EDU>

    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

						I hope that, whatever is
    decided about naming conventions, the X11 designers will not define
    distinct symbols that differ in case only.

All of the pre-defined atoms will be consistent, but we can't control
what users will use in addition.

					So the C symbols named "BitMap",
    "PointSize", and "StrikeoutAscent" become ":bitmap", ":pointsize", and
    ":strikeoutascent".  That's a bit ugly, but workable ...

    An alternative approach is to automatically insert a hyphen whenever the
    C version has an upper-case character that is not at the start of the
    word.  So "IgnoreThisObject" becomes ":ignore-this-object".  That's a
    bit more readable, is a reversible transformation, and doesn't require
    the C people to alter their naming conventions.

The first approach is not only ugly, but doesn't work, and I'm not sure
the second is reversible in the sense I had in mind.  Note there is no
static interface between C and Lisp here, as there is in Matchmaker.
When a Lisp programmer wants to store a property, s/he doesn't want to
have to declare a binding to some C programmer's naming convention; the
whole point is to reduce the burden, not increase it.  When reading a
list of window properties out of a server, you don't know what language
created them.  For an automatic keyword<->atom mapping to work, every
distinct X atom must have a distinct Lisp keyword, and which also means
every distinct Lisp keyword must have a distinct X atom.

∂13-Feb-87  0959	RAM@C.CS.CMU.EDU 	X atoms, a poll  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87  09:58:57 PST
Received: ID <RAM@C.CS.CMU.EDU>; Fri 13 Feb 87 12:59:19-EST
Date: Fri, 13 Feb 1987  12:59 EST
Message-ID: <RAM.12278759272.BABYL@>
From: Rob MacLachlan <RAM@λλ>
To:   Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU, xpert@ATHENA.MIT.EDU
Subject: X atoms, a poll
In-reply-to: Msg of 13 Feb 1987  09:38-EST from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>


I would say use underscores and single case, but I agree with Scott
that it isn't a make or break issue since an interface isomorphic to a
non-lisp system is going to be ugly anyway.  For example, in the case
of properties, you are already going to have to explicitly declare a
to-lisp translation for each property so that the system knows how to
lispify the property value.

I don't see why you say that underscores are "subject to
reinterpretation", and thus unsuitable for use in symbols.  It is true
that underscores may appear in potential numbers (which cannot be read
without escapes) but that doesn't stop you from interning them.  The
whole idea behind specifying potential numbers is that chops off a
piece of syntax for future use with the understanding that anything
else will always be symbol.

Although it would surely be amusing explaining the potential number
rules to C programmers, I believe that if you stick to legal C
identifiers, then the only way that you could come up with a potential
number is if you began the name with an underscore and followed it by
letters and digits without any two adjacent letters.  C programmers
will screw us without trying nearly that hard.

  Rob

∂13-Feb-87  1221	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	underscores  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87  12:21:35 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 13 Feb 87 15:21-EST
Date: Fri, 13 Feb 87 15:23 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: underscores
To: RAM@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12278759272.BABYL@>
Message-ID: <870213152325.5.RWS@KILLINGTON.LCS.MIT.EDU>

    From: Rob MacLachlan <RAM@c.cs.cmu.edu>

    I don't see why you say that underscores are "subject to
    reinterpretation", and thus unsuitable for use in symbols.

CLtL (p. 21) states "↑ and _ are not yet used in Common Lisp, but are
part of the syntax reserved for tokens, and are reserved to implementors".
I take this to mean that they are not necessarily valid as symbol
characters without quoting.  For example, in Symbolics Genera 7.0,
I can type in :foo_bar but it prints as :|FOO_BAR|.  Is there some
change that I don't know about, or am I misinterpreting something?

∂13-Feb-87  1228	FAHLMAN@C.CS.CMU.EDU 	X atoms, a poll   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87  12:27:46 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 13 Feb 87 15:27:47-EST
Date: Fri, 13 Feb 1987  15:27 EST
Message-ID: <FAHLMAN.12278786314.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU, xpert@ATHENA.MIT.EDU
Subject: X atoms, a poll
In-reply-to: Msg of 13 Feb 1987  11:51-EST from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>


    					So the C symbols named "BitMap",
        "PointSize", and "StrikeoutAscent" become ":bitmap", ":pointsize", and
        ":strikeoutascent".  That's a bit ugly, but workable ...

        An alternative approach is to automatically insert a hyphen whenever the
        C version has an upper-case character that is not at the start of the
        word...

    The first approach is not only ugly, but doesn't work, and I'm not sure
    the second is reversible in the sense I had in mind.  Note there is no
    static interface between C and Lisp here, as there is in Matchmaker.
    When a Lisp programmer wants to store a property, s/he doesn't want to
    have to declare a binding to some C programmer's naming convention; the
    whole point is to reduce the burden, not increase it.  When reading a
    list of window properties out of a server, you don't know what language
    created them.  For an automatic keyword<->atom mapping to work, every
    distinct X atom must have a distinct Lisp keyword, and which also means
    every distinct Lisp keyword must have a distinct X atom.

I don't understand this.  Why does it matter whether the interface is
static or dynamic?  When a new "atom" is created, both the Lisp and C
spellings are registered in a hash table somewhere. (Under either of my
proposals, you could register the C spelling and generate the Lisp
spelling automatically from it.)  In a Lisp program you will always see
the Lisp version; in a C program, you will always see the C version.  If
an "atom" is passed across the Lisp-to-C interface, part of that process
is name-conversion of any atoms.

Are you suggesting that programmers will want to make up new atom-names
on the fly and then pass them back and forth between Lisp and C without
first registering these atoms somewhere?  If atoms must be registered
with C (in order to be assigned a canonical identifier), the Lisp
version of the name can be created and registered at that time.

As seen from the Lisp side, it would be something like

(register-x-atom "FooBar" "BiteTheBaggie" "FlyingWombat")
  => (:foobar :bitethebaggie :flyingwombat)

(call-some-x-routine :foobar :bitethebaggie)
  => :flyingwombat

... or ...

(register-x-atom "FooBar" "BiteTheBaggie" "FlyingWombat")
  => (:foo-bar :bite-the-baggie :flying-wombat)

(call-some-x-routine :foo-bar :bite-the-baggie)
  => :flying-wombat

-- Scott

∂13-Feb-87  1249	Moon@STONY-BROOK.SCRC.Symbolics.COM 	X atoms, a poll   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 Feb 87  12:49:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 70517; Fri 13-Feb-87 15:46:36 EST
Date: Fri, 13 Feb 87 15:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: X atoms, a poll
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU, xpert@ATHENA.MIT.EDU
In-Reply-To: <870213093807.6.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870213154626.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

I don't see any strong reason to think that using Lisp keywords to
represent X atoms would be more efficient or more desirable than
using Lisp strings.  There is a hash-table-based translation between
the Lisp and X worlds in either case.  If you use strings, you don't
have to worry about mapping between two different casing/punctuating
conventions.

∂13-Feb-87  1345	RAM@C.CS.CMU.EDU 	underscores 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87  13:41:14 PST
Received: ID <RAM@C.CS.CMU.EDU>; Fri 13 Feb 87 16:41:40-EST
Date: Fri, 13 Feb 1987  16:41 EST
Message-ID: <RAM.12278799760.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: underscores
In-reply-to: Msg of 13 Feb 1987  15:23-EST from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>


Well, this getting a bit off track for this list, but I think that the
answer is that the statement on page 21 is wrong or at least
misleading.  I suspect that it predates the formalized notion of a
potential number, since that was a rather late addition.  In any case,
many of the statements in the data types chapter are only partial
truths that serve as forward definitions so that we can give code
examples without precisely describing the reader and other parts of
the system first.

On 343, after saying that potential numbers and all-dots symbols are
unreadable symbols, it says "In all other cases the token is construed
as a symbol."  This means that the reader can't complain if you type
:foo_bar, so it is perfectly legit in code.

The Symbolics printer may be correct, since on 367 where it is
discussing symbol printing rules, it requires that potential numbers
be escaped, but does not forbid gratuitous escaping.  The fact that
some printers may escape unnecessarily shouldn't affect the semantics
of programs.  Our printer only escapes potential numbers or symbols
that are otherwise unreadable.

  Rob

∂19-Feb-87  1401	SPIRKOV%PLU@ames-io.ARPA 	please add me to the mailing list.
Received: from AMES-IO.ARPA by SAIL.STANFORD.EDU with TCP; 19 Feb 87  14:01:26 PST
Received: from PLU by IO with VMS ;
          Thu, 19 Feb 87 13:58:24 PST
Date:    Thu, 19 Feb 87 13:58:24 PST
From:     SPIRKOV%PLU@ames-io.ARPA
Subject: please add me to the mailing list.
To:       cl-windows@sail.stanford.edu


thank you.

Lilly Spirkovska
(spirkov@ames-pluto.arpa)

∂20-Feb-87  1555	TAYLOR%PLU@ames-io.ARPA 	CW Standard Status  
Received: from AMES-IO.ARPA by SAIL.STANFORD.EDU with TCP; 20 Feb 87  15:55:22 PST
Received: from PLU by IO with VMS ;
          Fri, 20 Feb 87 15:51:41 PST
Date:    Fri, 20 Feb 87 15:51:41 PST
From:     TAYLOR%PLU@ames-io.ARPA
Subject: CW Standard Status
To:       cl-windows@sail.stanford.edu

I am interested in knowing the current status of selecting/defining
the Common Lisp Window standard; which of the following are in the 
running for the standard: Symbolics Dynamic windows, Xerox Common
Loops/windows, Intellicorp Common Windows, X windows; how soon might
there be a decision ?

	Thanks
--------------------------------------------------------------------------
   Will Taylor - Sterling Software, MS 244-17,
		 NASA-Ames Research Center, Moffett Field, CA 94035
   arpanet: taylor%plu@ames-io.ARPA 
   usenet: ..!ames!plu.decnet!taylor
   phone  : (415)694-6525

∂20-Feb-87  1944	FAHLMAN@C.CS.CMU.EDU 	CW Standard Status
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Feb 87  19:44:30 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 20 Feb 87 22:45:30-EST
Date: Fri, 20 Feb 1987  22:45 EST
Message-ID: <FAHLMAN.12280701008.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   cl-windows@SAIL.STANFORD.EDU
Subject: CW Standard Status
In-reply-to: Msg of 20 Feb 1987  18:51-EST from TAYLOR%PLU at ames-io.ARPA


In reply to: TAYLOR%PLU at ames-io.ARPA

Someone can correct me if this is wrong, but I believe it is the case
that nobody is currently working on a Common Lisp Window Standard.  It
is my own belief that there will never be a single window standard for
all of the Common Lisp world.  Such a thing would have to assume such a
low level of functionality that it would be worthless to most of us.
Not every machine running Common Lisp has a 2000x2000 24-plane color
display with real-time animation processor and 6-D 5-button bat (a
flying mouse); some machines still think they are talking to a teletype
or a deck of punched cards.  It's hard to imagine any window standard
that can successfully span that kind of range.

What we might see sometime soon is an agreement -- maybe even an
official standard, but separate from the Common Lisp standard itself --
that specifies how Common Lisp talks to X if that's what you want to do.

In a couple of years, we might conceivably see a standard for connecting
Common Lisp to bit-mapped displays in general.  This would have to be
defined at an abstract level that hides the details of the underlying
window manager.  I don't think anyone knows how to do that right now,
without throwing out too much performance and flexibility in the
process.

The one thing that is absolutely certain is that no window system can
become any kind of standard for a large segment of the Common Lisp
community as long as it is proprietary or it is not easily portable to
other manufacturers' machines.  I think the Symbolics and Intellicorp
window systems are ruled out on these grounds.  I'm not sure about NEWS.
Is Sun passing out sources?  

-- Scott

∂20-Feb-87  2354	edsel!bhopal!jonl@navajo.stanford.edu 	CW Standard Status   
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Feb 87  23:54:33 PST
Received: by navajo.stanford.edu; Fri, 20 Feb 87 23:52:09 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
	id AA10673; Fri, 20 Feb 87 23:46:09 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
	id AA04446; Fri, 20 Feb 87 23:43:36 PST
Date: Fri, 20 Feb 87 23:43:36 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8702210743.AA04446@bhopal.edsel.com>
To: navajo!Fahlman%C.CS.CMU.EDU@navajo.stanford.edu
Cc: navajo!cl-windows%SAIL@navajo.stanford.edu
In-Reply-To: "Scott E. Fahlman"'s message of Fri, 20 Feb 1987  22:45 EST
Subject: CW Standard Status


One possibility for standardization in the Common Lisp world is merely
on a user-interface to a window system.  Having seen the sentiment on
this list, and others, it seems that folks clearly want
   (1) some sort of object-oriented interface
   (2) and one which doesn't require research-project-level effort
       to understand and use.
I guess that is why the disussions often tie together a potential window 
system candidate with an o-o candidate.  

Let us very-hypothetically suppose that some o-o standard emerges within 
the next year; then what do you think? can a reasonable subset of window
capability be described in o-o terms?  This would not be the kind of 
standard where everybody had to implement the features described in the 
interface, or were restricted to it; but rather it would say "if you 
provide capability Z, then the user interface to it should look like ....".

I'd expect that over time, there would come to be a certain minimum
set of required capabilities that everyone agreed would have to be 
implemented in order for a candidate to call itself a window system.  
I think we can rule out the ASR/35 and friends as being any part of 
a "window" system.


-- JonL --

∂21-Feb-87  0833	CS.WERTH@R20.UTEXAS.EDU 	please add me to the mailing list  
Received: from R20.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 21 Feb 87  08:17:06 PST
Date: Sat 21 Feb 87 10:18:11-CST
From: CS.WERTH@R20.UTEXAS.EDU
Subject: please add me to the mailing list
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12280838041.8.CS.WERTH@R20.UTEXAS.EDU>


-------

∂21-Feb-87  1523	RICHER@SUMEX-AIM.STANFORD.EDU 	CL-WINDOWS standards    
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Feb 87  15:23:39 PST
Date: Sat 21 Feb 87 15:22:49-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: CL-WINDOWS standards
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12280915344.21.RICHER@SUMEX-AIM.STANFORD.EDU>

There is a cl-windows subcommittee as well as one on graphics, but it doesn't
seem if much progress has been made over the years.  I assume that
there are people on this mailing list that are on those committees so
this discussion is probably being tracked and may have an impact. 

I think we need to examine why we want standards. I can think of at
least four reasons all of which concern me as a direct result of
personal experiences:

(1) I have written code that I either want to move to another machine or
give away to someone who has a different machine. 

(2) I want to obtain code that was written for another machine.

(3) I want to ask someone for advice on doing something, but they use
a different machine (or they want to ask me for help but I don't know
the details of their window system).

(4) For students it is very advantageous that textbooks, etc. all
refer to the same standard. 

Obviously, there are tradeoffs. Standards also cause problems because
they become entrenched and make fundamental changes in the future
difficult on a widespread level. But contrary to how some people make
it out to be standards do NOT PREVENT language research. Just because
Commonlisp exists does not mean that research on lisp languages cannot
continue, i.e., anyone still has the right to develop an uncommonlisp.

However, I do agree we are not ready to define a commonlisp window
standard.  And I'm  not sure that window systems or graphics systems
should be designed at the language level. However, when they are
designed using a specific language the influence is often obvious
(e.g., unix and X being written in C). ALthough I would really like to
see a standard lisp interface to X, I think the issues are more
complicated than I anticipated. On the one hand, X solves a lot of
problems. It's available, it's public domain, it's been widely
adopted, and it does not require the adoption of the CL standard. X in lisp
addresses my concerns 1-4 for the most part and it will give us the
experience we need to work on future standards.  The problem is that
there are some issues with regard to a lisp interace to X that remain
to be resolved:

(1) there is no Xlib written in Commonlisp that is widely available
(if one exists at all).  Most people are using XLib written in C on
their unix workstations with a foreign function-call interface (ffi).
I agree with SCheifler and others that argue that this is not a great
way to go because an equivalent library can be written in Lisp that
may be more appropriate for lispers. Furthermore, lisp machine vendors
will follow a different course anyhow. What should Xlisplib look like?
If we don't want to just copy Xlib in C we have some things to
discuss. But I believe we should aim for a Portable Commonlisp (w/o
COmmonloops) Xlib that is public domain.


(2) What about objects? Do we all really agree on the idea that an oop
interface should be in the standard interface to X? I won't complain
personally, but is there anyone out there who objects (sorry for the
pun) to this? (a year or two ago there were people on this list who
found objects objectionable, and I know other lispers that still feel
that way). If we introduce objects into the interface at what level?
the library? the toolkit? Can we have a low-level interface to X that
can be implemented with or without objects? THis seems reasonable
given that Commonloops uses lisp function syntax. If the low-level
interface is all functions, why not?  Perhaps we want two XLibs that
are functionally equivalent, one in pure CL and one in COmmonloops?

(3) What about a tool-kit or standard user-interface tools? THis is
going to take a while and personally I would object to not having
objects at this level. This tool-kit would be optional, i.e., you
could use the low-level lisp interface to X without using this
toolkit.  How should the lisp toolkit relate to the C toolkit MIT,
DEC, HP, etc. are trying to agree on? One thing I do know is that this
toolkit needs to be easy to program and easy to customize. Or as ALan
Kay said (well I think he said this about programming languages, in
particular Smalltalk-72): "Simple things should be easy to
do and difficult things should be possible." Actually re-configuring
the interface to have a different look and feel should be relatively
easy for some known set of user-interface styles. We need to describe
an interface at an abstract level (e.g., highlighting is an
abstraction as opposed to inverting or boxing  a text region which are
techniques). 

Mark
-------

∂22-Feb-87  0846	FAHLMAN@C.CS.CMU.EDU 	CL-WINDOWS standards   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Feb 87  08:46:12 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 22 Feb 87 11:47:12-EST
Date: Sun, 22 Feb 1987  11:47 EST
Message-ID: <FAHLMAN.12281105456.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: CL-WINDOWS standards
In-reply-to: Msg of 21 Feb 1987  18:22-EST from Mark Richer <RICHER at SUMEX-AIM.STANFORD.EDU>


Some opinions on the issues that Mark Richer raises:

1. Should we write a mostly-portable Xlib in Common Lisp, or should we
talk to the existing C-based Xlib via some foreign function call
interface?  I would argue that we don't all need to do this the same
way.  If we define a low-level Lisp interface that is analogous to the
Xlib interface that C provides (but with Lisp syntax and apropriate
mapping of data types into Lisp equivalents), then it can be left to
each implementor to decide whether this is done by calling linked-in C
routines, by calling Lisp equivalents to the C routines, or by packaging
up an IPC message and sending it to a remote server written in whatever
language.  There has to be a server so that requests from distinct
processes can be coordinated, but the user doesn't need to know which
things are done in the server and which are done in his own process.
Nor does he have to know when some Lisp function that he has called
surreptitiously drops down into C or aseembler or microcode.

Since X is still evolving, and since the canonical implementation is
being done in C, the approach of linking in the C version of Xlib has
certain advantages to the implementor, at least on unix-based systems:
it becomes easy to track any changes with just a bit of fiddling with
the interfaces, and unintentional incompatibility is avoided.

In defining the lowest-level Lisp interface to X, there will be a great
temptation to break away from a straightforward mapping of the C calls
and to make the Lisp version nicer.  This temptation will be especially
strong where the shortcomings of the C language make it necessary to do
something in a particularly ugly way.  I think we should probably resist
this temptation.  By mapping even the really dumb things in a
straightforward way, we make it possible to generate (much of) the
Lisp-to-X interface by some sort of mechanical translation from the C,
and we also lessen the burden on people who must move their code or
themselves back and forth between the two systems.

If this lowest-level "raw" interface between Lisp and X is not to our
liking, we can easily provide a body of portable Common Lisp code that
hides the C-derived ugliness and implements a nicer window-system
interface for most Lisp users.  But I think that it is very important to
provide that lowest-level interface that maps the C calls very closely.
That will prevent the Lisp and C worlds from diverging, and it will make
it possible for some implementors to link in the C code in a
straightforward way.

2. What about objects?  As long as there was no standard set of
object-oriented facilities within Common Lisp, no consensus on what
those facilities should look like, and no easy way to port the leading
contender (Flavors, at that time) to most Common Lisp workstations, it
seemed quite insane to propose a graphics standard that made significant
use of some object-oriented programming system.  A consensus is now
developing around the new proposal for a Common Lisp Object System.  It
seems clear that this will become part of the standard at some time in
the not-too-distant future and that implementations developed today in
PCL (Portable Common Loops) will be easy to port to the new standard,
once it is in place.  So I no longer see any good reason to avoid making
use of objects in the graphics/windows area.

If the lowest-level interface is a nearly straightforward mapping of the
Xlib calls, as I have suggested above, then objects may be useful there
only in a degenerate defstruct-like sense.  But for all the stuff built
on top of this layer, a complete object system will make a big diference
and it would make no sense to avoid using it.

3. What about toolkits?  Upon reading the proposal for the
MIT/DEC/HP/whoever toolkit, what struck me was that about 80% of the
content of that proposal was an attempt to provide the C user with the
kind of flexible programming constructs that the Lisp user gets for free
-- especially the Lisp user who has an object system in his Lisp.  The
spec proposes a few bits of user-level functionality that are worth
ripping off -- radio buttons, for example -- but to try to recreate in
Lisp the awkward way in which these things are provided would certainly
be counter-productive.

I think that the right goal here is to build a comprehensive, portable,
widely available Common Lisp toolkit on top of the primitive Lisp-to-X
interface, and to make sure that all of the popular user-level facilities
available in the C/X world have their counterparts in Lisp.  Since we have
fewer low-level problems than the C people, and since we Lispers believe
that we have a much superior programming environment, we may soon find
that most of the innovation at the toolkit level is occurring on the
Lisp side, and it is the C people who are struggling to keep up.

-- Scott

∂22-Feb-87  1741	FAHLMAN@C.CS.CMU.EDU 	CW Standard Status
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Feb 87  17:41:49 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 22 Feb 87 20:42:06-EST
Date: Sun, 22 Feb 1987  20:42 EST
Message-ID: <FAHLMAN.12281202834.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   edsel!bhopal!jonl@λnavajo.stanford.edu (Jon L White)λ
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: CW Standard Status
In-reply-to: Msg of 21 Feb 1987  02:43-EST from edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)


Sure, given an object-oriented standard, it's just a matter of figuring
out what higher-level abstractions are most appropriate and convenient
for a graphics/windows interface.  If a consensus emerges about that,
then it's just a small matter of turning that consensus into a formal
standard.  In order for this consensus to develop, we need some
experience, some good ideas, someone to work out a coherent proposal,
and someone to implement that proposal in reasonably portable
public-domain code.

I think that this may eventually happen.  I don't know how long it will
take.  Most of the groups I know about are just starting to experiment
with this stuff.  Maybe there are segments of the Lisp community that
already have enough experience with objects and graphics to understand
what a really good set of abstractions would look like.  If that same
set of people have the time and motivation to produce a proposal and
supporting code, then we could make very fast progress; if not, then
we're in for a couple of years of experimentation.  If most of us can
work on a shared low-level substrate such as X, then the experimentation
will go more quickly because we can share what we develop.

-- Scott

∂23-Feb-87  0333	mcvax!inria!inria.inria.fr!devin@seismo.CSS.GOV 	change me  
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 23 Feb 87  03:33:41 PST
Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP 
	id AA17292; Mon, 23 Feb 87 06:34:19 EST
Received: by mcvax.cwi.nl; Mon, 23 Feb 87 12:25:58 +0100 (MET)
Received: by inria.inria.fr; Mon, 23 Feb 87 12:03:50 +0100 (MET)
Date: Mon, 23 Feb 87 12:03:50 +0100
From: mcvax!inria!inria.inria.fr!devin@seismo.CSS.GOV (Matthieu Devin)
Message-Id: <8702231103.AA06752@inria.inria.fr>
To: cl-windows@sail.stanford.edu
Subject: change me

could you please change inria!devin to inria!cl-windows in the mailinglist
please?

∂23-Feb-87  0813	dcmartin@ingres.berkeley.edu 	X/Common LISP interface  
Received: from INGRES.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 23 Feb 87  08:13:30 PST
Received: by ingres.Berkeley.EDU (5.57/1.14)
	id AA28193; Sun, 22 Feb 87 18:07:28 PST
Message-Id: <8702230207.AA28193@ingres.Berkeley.EDU>
From: "David C. Martin" <dcmartin@ingres.berkeley.edu>
Office: 440 Evans - x2-9585
Home: 2441 Haste St #37, Berkeley, CA 94704 - (415) 843-6470
Fortran: is not backward, NARTROF is backwards.
To: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
Cc: cl-windows@sail.stanford.edu
Precedence: priority-mail
In-Reply-To: Your message of Sun, 22 Feb 1987  20:42 EST
Subject: X/Common LISP interface
Date: 22 Feb 87 18:07:26 PST (Sun)
Sender: dcmartin@ingres.berkeley.edu

Speaking of low-level X interfaces for Common LISP... that is exactly what
I am finishing up right now.  I have about 80% of the functionality done
(or I hope it is 80% :-).  The die-hard lispers will hate me, 'cause I use
a foreign function interface to the C language X libraries, but, hey, it was 
there.

Anyway, I hope to have this done by the end of the month (including a 
descriptive document much stolen from MIT's Xlib document).  If anyone would
care to get an alpha release of the document/software in about 10 days, send
me mail and let me know.

BTW: This low-level interface is being used in conjuction w/ PCL to build an
object oriented X interface, which is no nearly so close to being done, but
someday...

dcm

∂23-Feb-87  1305	RICHER@SUMEX-AIM.STANFORD.EDU 	Re: X/Common LISP interface  
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Feb 87  13:04:56 PST
Date: Mon 23 Feb 87 13:03:25-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: Re: X/Common LISP interface
To: dcmartin@INGRES.BERKELEY.EDU
cc: Fahlman@C.CS.CMU.EDU, cl-windows@SAIL.STANFORD.EDU,
    RICHER@SUMEX-AIM.STANFORD.EDU
In-Reply-To: <8702230207.AA28193@ingres.Berkeley.EDU>
Message-ID: <12281414254.35.RICHER@SUMEX-AIM.STANFORD.EDU>

I agree with what SCott in a message that may have been addressed to me
personally (I can't remember):

Whether you use a ffi is an implementation issue as long as we agree that
the low-level lisp interface to X is going to be pretty close to XLib in C.
Scott seems to think that is a good idea and apparently David does also.
I'm not 100% committed on that issue, but I agree that the low-level interface
should be defined in such a way that one could choose to either use a ffi,
a native lisp implementation or a combination of both in a way that is
completely transparent to the user of the library.  All of the ugliness or
awkwardness that appears in the ffi should obviously be hidden from the 
standard interface definition and the user.

If we can agree on this first at least we will start out from the same base,
we can exchange code, etc. Ultimately it will be much more useful if we
can agree on a higher-level interface also, but we need to start somewhere.

mark
-------

∂23-Feb-87  1852	mqb@cive.ri.cmu.edu 	Re: X/Common LISP interface  
Received: from CIVE.RI.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Feb 87  18:52:52 PST
Date: Monday, 23 February 1987 21:51:36 EST
From: Monique.Barbanson@cive.ri.cmu.edu
To: "David C. Martin" <dcmartin@ingres.berkeley.edu>
cc: cl-windows@sail.stanford.edu
Subject: Re: X/Common LISP interface
Message-ID: <1987.2.24.2.46.57.Monique.Barbanson@cive.ri.cmu.edu>
In-Reply-To: <8702230207.AA28193@ingres.Berkeley.EDU>

i would be extremely interested in getting such an interface as
i am currently working on a user interface that i'd like to use
with a minimum of modifications on an Explorer and a Sun.
-Monique.
<< Put body of message here. >>

∂24-Feb-87  1733	wanginst!ulowell!grinstei@harvard.harvard.edu 	Re:  X/Common LISP interface
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 24 Feb 87  17:32:32 PST
Received: by seismo.CSS.GOV (5.54/1.14) 
	id AA19713; Tue, 24 Feb 87 20:32:13 EST
Received: by harvard.harvard.edu; Tue, 24 Feb 87 20:31:56 EST
Received: by wanginst.EDU (4.12/5.8.WangInst)
	id AA01274; Tue, 24 Feb 87 08:43:37 est
Posted-Date: Tue, 24 Feb 87 08:22:42 EST
Received: by ulowell.cs.ulowell.edu (5.51/smail2.3/18-Feb-87)
	id AA17716; Tue, 24 Feb 87 08:22:42 EST
Date: Tue, 24 Feb 87 08:22:42 EST
From: ulowell.cs.ulowell.edu!wanginst!grinstei@harvard.harvard.edu (Georges Grinstein)
Message-Id: <8702241322.AA17716@ulowell.cs.ulowell.edu>
To: Fahlman@c.cs.cmu.edu, dcmartin@ingres.berkeley.edu
Subject: Re:  X/Common LISP interface
Cc: cl-windows@sail.stanford.edu

I am interested in being an alpha site.  thanks.

UUCP: wanginst!ulowell!grinstein           Dr. Georges Grinstein
ARPA: grinstein@ulowell.CSNET              University of Lowell
VOX:  +1 617 452 5000 x2681                Lowell MA 01854 USA

∂25-Feb-87  1637	rochester!tropix!dls@seismo.CSS.GOV 	Re:  CW Standard Status
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 25 Feb 87  16:36:17 PST
Received: from rochester.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP 
	id AA15917; Wed, 25 Feb 87 19:36:27 EST
Received: by ur-seneca.arpa id AA08295 (4.12z); Wed, 25 Feb 87 19:25:40 est
Received: by tropix.UUCP (4.12/4.7)
	id AA23453; Wed, 25 Feb 87 19:15:10 est
Date: Wed, 25 Feb 87 19:15:10 est
From: rochester!tropix!dls@seismo.CSS.GOV (David L. Snyder )
Message-Id: <8702260015.AA23453@tropix.UUCP>
To: fahlman@c.cs.cmu.edu, cl-windows@sail.stanford.edu
Subject: Re:  CW Standard Status
Cc: rochester!ttropix!dls@seismo.CSS.GOV

Fahlman says in reply to a previous message about CL Window Standards...
	
	Someone can correct me if this is wrong, but I believe it is the case
	that nobody is currently working on a Common Lisp Window Standard.  It
	is my own belief that there will never be a single window standard for
	all of the Common Lisp world.  Such a thing would have to assume such a
	low level of functionality that it would be worthless to most of us.
	Not every machine running Common Lisp has a 2000x2000 24-plane color
	display with real-time animation processor and 6-D 5-button bat (a
	flying mouse); some machines still think they are talking to a teletype
	or a deck of punched cards.  It's hard to imagine any window standard
	that can successfully span that kind of range...

I couldn't disagree more with what I understand him to mean.  Perhaps
this is because my concept of "window standard" is not standard?  I
consider a window standard to:

	(1) define a minimum functionality that exists on any
	implementation of the standard.

	(2) allow for individual vendor to provide supersets of the
	minimum functionality.

	(3) allow the functionality to be provided in any way that
	gets the job done.

Furthermore, I perceive two layers for the window implementation.
The first specifies a bunch of lisp routines, variables, macros, and so on,
that any application can invoke.  This bunch of stuff might be exactly
what Xerox D machines provides for building menus and windows,
tracking a mouse, &tc., or it might be IntelliCorp's CommonWindows.
It would *NOT* be anything X-like.  The names of these lisp functions,
&tc. would be things like
	(CreateWindow x-top-left y-top-left ...),
	(CreateMenu name entries ...),
	(WindowTitle window newtitle ...),
	(DrawObject object line-width coords ...),
and so on.

[I've never hacked Symbolics interfaces, so I can't speak to the o-o
issues.]

The second layer of the window standard is much more controversial,
might just be the "RasterOps on wheels" upon which the first layer is
implemented.  What I think Scott is missing here is that these routines
could play on an underlying standard for still lower level cruft, like
X.  So, on a Vax they might have similar names to X routines,
and just be foreign calls to X routines written in C.  Or the X
routines might (less intelligently but maybe more efficiently) be
written in lisp and call more primitive BitBlt routines.  Or Sun/Lucid
might have these routines hook into NewS, even though X can run on top
of NewS, for efficiency or to provide nicer functionality.

The point here is that there are several levels of win.  On the one
hand, all the code I run on my Vax will *look* (and run) exactly the
same on my Sun; I'll get similar looking windows, graphics, menus,
&tc. (assuming I stick to the standard, of course).  If I move code
from a windowing machine to one that only supports ASR 33 interfaces
that's tough cookies for me.  If I use color on one system and move
code to a system that doesn't have it I can't complain about the
standard breaking down.

I win at a lower level too, since all I have to do is implement the X
standard on my particular hardware.  For *lots* of hardware that will
have already been done; if it hasn't I'll probably have to do it
anyway to satisfy other applications (assuming it isn't special
purpose hardware).

There's absolutely no reason this window standard business has to be
as intractable as some make it out to be.  Agreeing on the top layer
of functionality isn't that hard!  There aren't *really* that many
diffences between the existing approaches.  And since X is becoming so
ubiquituous, it's the logical choice for a second support layer.
(Although I personally think NewS is superior--Teitelman and Gosling
(I think) deserve a lot of credit for developing the idea of having
the same graphics description language for all display devices.)
Most machines will already have it written in C so you're all done.
The only real problem I forsee is that performance might suffer, but
only experimentation will tell for sure.

David

∂02-Mar-87  2124	WELCH%OSU-20@ohio-state.ARPA 	X in CL   
Received: from OHIO-STATE.ARPA by SAIL.STANFORD.EDU with TCP; 2 Mar 87  21:24:36 PST
Return-Path: <WELCH@OSU-20>
Received: from OSU-20 (osu-20.ARPA) by ohio-state.ARPA (4.12/6.1.OSU-CIS)
	id AA04603; Mon, 2 Mar 87 16:35:50 est
Message-Id: <8703022135.AA04603@ohio-state.ARPA>
Date: Mon 2 Mar 87 16:31:15-EST
From: Arun <Welch%OSU-20@ohio-state.ARPA>
Subject: X in CL
To: cl-windows@sail.stanford.edu

It looks like some people are developing Lisp interfaces to X, or in some
cases Lisp implementations of X.  For someone starting a new port, it would
be usefull if one didn't have to reinvent the wheel, or get halfway through
a port only to discover that someone else has already done one.  So, I'd
like to take a poll to see who has done a port, and if you're willing to
share code. Which machine have you done it on,  which implementation of 
Lisp if its not a pure-lisp machine, and if you've got PCL hooks into it
would be really usefull information.  

...arun
-------

∂09-Mar-87  1201	KASTNER@IBM.COM
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 9 Mar 87  12:01:25 PST
Date: 9 March 1987, 14:42:32 EST
From: "John K. Kastner"  <KASTNER@ibm.com>
To:   cl-windows@sail.stanford.edu
cc:   kastner@ibm.com

Please add me (KASTNER@IBM.COM) to the CL-WINDOWS@SAIL.STANFORD.EDU
mailing list.

Thank you,
   John Kastner

∂10-Mar-87  1215	pierce@rd1632 	Common Lisp Windows 
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 10 Mar 87  12:15:28 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab22682; 10 Mar 87 15:01 EST
Received: from ncr by RELAY.CS.NET id ab18334; 10 Mar 87 14:02 EST
Subject:   Common Lisp Windows
To: CL-WINDOWS@SAIL.STANFORD.EDU
From: pierce@rd1632
Date: Tue, 10 Mar 87 13:37:37 -0500 (at ncrlnk.Dayton.NCR.COM)

From:      Gene Pierce
Location:  NCR CORP. WHQ/5E Dayton, Ohio 45479

To:        To  whom it may concern



Please add my name to the Common Lisp Windows Discussion list.

                                              Thank You
                                              Gene Pierce

∂10-Mar-87  1221	AKBARI@CS.COLUMBIA.EDU 	please add me   
Received: from CS.COLUMBIA.EDU by SAIL.STANFORD.EDU with TCP; 10 Mar 87  12:20:33 PST
Date: Tue 10 Mar 87 15:19:44-EST
From: John C. Akbari <AKBARI@CS.COLUMBIA.EDU>
Subject: please add me
To: works-request@RUTGERS.RUTGERS.EDU, cl-windows@SAIL.STANFORD.EDU,
    common-lisp@SAIL.STANFORD.EDU
Message-ID: <12285338462.45.AKBARI@CS.COLUMBIA.EDU>

to your list.

	ad...THANKS...vance!

john c akbari

    ARPANET & Internet  	akbari@CS.COLUMBIA.EDU
    BITnet			akbari%CS.COLUMBIA.EDU@WISCVM.WISC.EDU
    uucp & usenet               ...!seismo!columbia!cs!akbari
    DECnet			akbari@cs
    PaperNet			380 riverside drive, no. 7d
				new york, new york  10025   usa
    SoundNet			212.662.2476
-------

∂12-Mar-87  1405	dcmartin@ingres.Berkeley.EDU 	X/Common LISP interface  
Received: from INGRES.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 12 Mar 87  14:05:34 PST
Received: by ingres.Berkeley.EDU (5.57/1.14)
	id AA14094; Thu, 12 Mar 87 13:40:35 PST
Date: Thu, 12 Mar 87 13:40:35 PST
From: dcmartin@ingres.Berkeley.EDU (David C. Martin)
Message-Id: <8703122140.AA14094@ingres.Berkeley.EDU>
To: cl-windows@sail.stanford.edu
Subject: X/Common LISP interface

There is now a X/Common LISP interface available for alpha release.  You
may acquire it via public ftp from ingres.Berkeley.EDU.

This release currently only works under Extended Common LISP from Franz, Inc.

Please read the README file and send mail to xcl-users-request if you
acquire the software.

dcm
-----
David C. Martin
-----
Computer Science Division
University of California
Berkeley, CA 94720
-----
arpa: dcmartin@ingres.Berkeley.EDU
uucp: {ihnp4,decvax}!ucbvax!dcmartin
at&t: 415/642-9585 (O)

∂21-Mar-87  1733	RICHER@SUMEX-AIM.STANFORD.EDU 	[gabriel@vaxa.isi.edu (Gabriel Robins): Re: ISI grapher]   
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Mar 87  17:32:58 PST
Date: Sat 21 Mar 87 17:33:48-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: [gabriel@vaxa.isi.edu (Gabriel Robins): Re: ISI grapher]
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12288279220.19.RICHER@SUMEX-AIM.STANFORD.EDU>

Some of you may be interested in this grapher package available from ISI.
Please contact Gabriel Robbins, not me, because I cannot help you in any
way. In fact I do not have the package myself yet! I had thoughts of porting
the graphics layer to work under X, but for various reasons I doubt that
will happen. At this point it may pay to get it working under V11 rather
than V10.  

                ---------------

Return-Path: <gabriel@vaxa.isi.edu>
Received: from vaxa.isi.edu by SUMEX-AIM.STANFORD.EDU with TCP; Fri 6 Feb 87 17:45:15-PST
Received: by vaxa.isi.edu (4.12/4.7)
	id AA26261; Fri, 6 Feb 87 17:44:04 pst
From: gabriel@vaxa.isi.edu (Gabriel Robins)
Message-Id: <8702070144.AA26261@vaxa.isi.edu>
Date:  6 Feb 1987 1744-PST (Friday)
To: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: Re: ISI grapher
In-Reply-To: Your message of Thu 5 Feb 87 20:30:20-PST.
             <12276777021.13.RICHER@SUMEX-AIM.STANFORD.EDU>


Mark,

   I am now working at 30% of full-time, but it is exclusively on the ISI 
Grapher.  I am trying to put out a complete manual for it and really shake the 
code down.  

   I just ported it to Genera version 7, but I don't have the time right now
to port it to HP's; the bottom graphics layer is localized, both logically and 
physically, so it should not take more than a few days in any case.  I'd love
for your people to do it if you can manage it; I'll give you any advice and 
phone consultation you might need.

   Feel free to point people in my direction if my package could help them.  
I also noticed that several people on the CL-WINDOWS list could benefit from 
it.  You may want to post a message about it to the list itself.  I leave it
up to you.  For the record, I enclose a short description of my system.

Gabe

----------------------------------------------------------------------

              The ISI Grapher: Its Current State and Its Future
                              Gabriel Robins
                              January, 1987


   The ISI Grapher is a set of functions that convert an arbitrary graph 
structure (or relation) into an equivalent pictorial representation and 
displays the resulting diagram.  Nodes and edges in the graph become boxes and 
lines on the workstation screen, and the user may then interact with the 
Grapher in various ways via the mouse and the keyboard.

   The fundamental motivation which gave birth to the ISI Grapher is the
observation that graphs are very basic and common structures, and the belief 
that the ability to quickly display, manipulate, and browse through graphs  may
greatly enhance the productivity of a researcher, both quantitatively and
qualitatively.  This seems especially true in knowledge representation and
natural language research.  

   The ISI Grapher is both powerful and versatile, allowing an 
application-builder to easily build other tools on top of it.  The ISI NIKL 
Browser is an example of one such tool.  The salient features of the ISI 
Grapher are its portability, speed, versatility, and extensibility.  Several
additional applications were already built on top of the ISI Grapher, 
providing the ability to graph lists, flavors, packages, divisors, functions,
and Common-Loops classes.

  Several basic Grapher operations may be user-controlled via the specification
of alternate functions for performing these tasks.  These operations include 
the drawing of nodes and edges, the selection of fonts, the determination of
print-names, pretty-printing, and highlighting operations.  Standard 
definitions are already provided for these operations and are used by default 
if the application-builder does not override them by specifying his own funti 
ons for performing the same tasks.

   The ISI Grapher now spans almost 100 pages of CommonLisp code.   The ISI
Grapher manual is currently 55 pages long, and it is two-thirds finished.  The
manual describes the general ideas, the interface, the application-builder's
back-end, the algorithms, the implementation, and the data structures.  Until
the full manual is ready, a temporary less detailed document is available upon
request.  Several minor bugs still plague the code, but are being fixed
currently.  Further testing and bullet-proofing is planned.  The ISI Grapher 
presently runs on both Symbolics (6 & 7) and TI Explorer workstations.  

   The ISI Grapher has already drawn considerable interest; external parties 
that have requested the code include Teknowledge, BBN, Inference, & JPL.  
It is projected that the ISI Grapher would attain production-quality by
the beginning of the summer. 

   We welcome comments and suggestions; please direct all feedback to 
gabriel at vaxa.isi.edu and lmiller at venera.isi.edu.

----------------------------------------------------------------------
-------

∂02-Apr-87  1533	MMcM@STONY-BROOK.SCRC.Symbolics.COM 	Window systems standardization   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Apr 87  15:33:03 PST
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 108011; Thu 2-Apr-87 18:33:01 EST
Date: Thu, 2 Apr 87 18:33 EST
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Window systems standardization
To: cl-windows@sail.stanford.edu
Message-ID: <870402183306.7.MMCM@OWL.SCRC.Symbolics.COM>

Any window system standard should be carefully designed to be properly
layered.  Naturally, application programmers will want to use the
uppermost layers whenever possible.  By doing so, not only do they
increase their productivity by achieving a higher level of abstraction,
but they also insulate themselves from differences in the lower levels.
On the negative side, these upper layers are most often proprietary and
most dependent on the host operating system and window management
paradigms.  For this reason, it is vital that each layer be well
organized and that as many as possible be standardized to as great a
degree as possible.

Here are some of the layers which I recognize:

Level 0.  A standardized set of lowest level graphics (that is imaging)
subprimitives, upon which a native implementation of a virtual console
layer such as X could be based.  This would be useful both for lisp
machines per se and for environments in which there was not an existing
X implementation in some other language as part of the operating system.
Such an implementation could even be public domain, or copyright MIT.
These functions would provide more or less direct access to a frame
buffer.

Level 1.  A standardized set of functions supporting a LISP
value-oriented X library, using standard Common Lisp calling sequences.
This is similar to the XLib integration of X into the C programming
environment and calling sequence.  Note that the existence of X on the
machine already implemented in C does not require a foreign function
interface to the XLib library.  Because of the nature of the X protocol,
the LISP X library could just as well interface to the local X server
via the same shared memory (or whatever) primitives that the XLib
library itself did.  Any incompatibility of calling sequences need not
be an issue.  X itself is in no way C specific.  Once again, there could
be a standard implementation in LISP of this for byte-stream access to
servers, using just host specific network/memory buffer primitives.
Separately, there could be a implementation that actually did a foreign
function call to an X library in some other language.  Or there could be
yet another implementation that directly called into existing window
system primitives, assuming they managed to correctly model X window
concepts.

It should be noted that
 a. There is no guarantee that the standard WRITE-STRING or READ-CHAR
from Steele will accept anything returned by this layer as their
optional stream argument.
 b. The application programmer visible window abstraction will often be
an encapsulation of several primitive X windows to achieve higher level
effects, such as scrolling or complex margin decoration.
 c. While it might be possible to implement a simple graphics hack like
QIX using this layer, there wouldn't really be any guarantees of
keyboard input access or synchronization.

Level 2.  An extension of the Common Lisp stream standard, based on the
emerging Common Lisp Object System standard.  The primitive I/O
operations, such as READ-CHAR, WRITE-CHAR, WRITE-STRING, FORCE-OUTPUT,
and FINISH-OUTPUT are made generic.  As much as possible, this layer
tries to avoid issues related to the window management paradigm of a
particular host, so that the program is still portable without that
window manager as an included library.

Furthermore, the implementation based on the X virtual console
specification need not be the only version of this standard.  There
could even be different implementations of different interface
paradigms, all based on X.  It would be possible to implement it on top
of another low level windowing standard, such as NewS.  More critically,
it might be possible to implement it on top of the larger existing Lisp
window systems, without necessitating wholesale replacement of console
substrate.  Such replacement, even when it is planned for the future, is
by no means a short term possibility for most vendors with large
installed bases.

This layer would provide those facilities necessary for construction of
things like a lisp listener window.  The interaction style would not
necessarily be the same on all machines, but in general terms the
program would have
 a. A READ, EVAL, PRINT command loop program, for which most but not all
the pieces are included in the Steele manual already.
 b. An input editor, that is a program that takes keystrokes and gives a
reliable stream of editing input.  This is the stream that READ talks
to.  Such an editing program's interface would be part of this standard
layer, although particular editing paradigms would be reserved to system
interface designer's whims.
 c. An asynchronous monitor of keystrokes if lisp is to be interruptible.
 d. An output exception handler that causes something worthwhile to
happen when more output than the initial size of the window has been
exceeded.  There are several possibilities for actions to take when this
occurs.  Control of which one any particular window has could be
standardized, even if there were no guarantee that all systems provided
all possibilities.

This layer is the approximately equivalent to the specification given by
IntelliCorp's Common Windows.

Level 3.  An application programmer oriented graphics output package.
Again, this is a class-based extension of the stream protocol.

Implementations would naturally be provided
 a. On top of the X based window standard (via access through the window
object to the core windows that supported the primitive graphical
imaging output).
 b. For LaserWriters and other similar high quality output devices,
based on a page layout standard like PostScript or InterPress, and not
on X.
 c. On top of other window systems, such as NewS or Zetalisp sheets, if
desired.

This layer would provide necessary application programmer interfaces
that might not be supported by the core.  Such as,
 a. Coordinate system transformations.
 b. Ratio and float coordinates.
 c. Higher level shapes, like ovals, ellipses, or cubic splines.
 d. Scaled text.
 e. Advanced color modeling, including perhaps anti-aliasing.

This level is object oriented in the sense that object oriented
programming techniques are applied to give device independence.  The
graphical shapes and any hierarchy that they might form are not objects
defined by this level.  This is because there is little point in making
them be objects until one begins to need to control their
interrelationship and mutual constraining.  All you gain is saving on
function names.  Such higher level graphics, such as might naturally be
part of the substrate for the picture editor or design system, is a
layer yet higher still.  The graphical output functions in this layer do
obey what might loosely be construed as object orientation in that the
options that control the texture of the geometrical shapes are specified
in a uniform way for different shapes.

In other words, the functions here provide for drawing of shapes,
 a. Circle
 b. Triangle
 c. Polygon
and generic control of the imaging of the mathematical shape,
 a. stroking vs. filling
 b. stroke thickness
 c. stipple patterns and colors
and so on in a standard way.

Level 4.  Application programmer access to the window manager.  This is
naturally going to be somewhat host specific, so I don't lay much hope
in standardizing it at this point.  Different systems with different
window managers have their vocally inflexible adherents.

Level 5.  A full User Interface Management System.  Since there is very
little general acceptance of any interface paradigm, either from the
user or programmer side, this is not likely to be standard either.

While these last two layers are not standard, it is possible for them to
be portable, given that they are written exclusively using the lower
layers, which are presumably designed with that aim in mind.  Thus even
if an application locks into a particular interface paradigm and/or
toolkit, it still has some chance for portability, if that is a concern.

Moreover, even though the interface paradigms cannot be standardized at
this point, a number of higher level simple interface ideas might be
identified and standard function interfaces specified for them.  For
instance, there could be a function that popped up a menu given an
association list of choices.  How the user actually did the selection
from the menu and where it appeared on the console would be up the
system.

∂03-Apr-87  0603	@ZERMATT.LCS.MIT.EDU,@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU 	CLX proposal: cover message   
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Apr 87  06:03:11 PST
Received: from KILLINGTON.LCS.MIT.EDU (KILLINGTON.LCS.MIT.EDU) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 40113; 3 Apr 87 09:04:55 EST
Date: Fri, 3 Apr 87 09:05 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX proposal: cover message
To: cl-windows@SAIL.STANFORD.EDU
File-References: LCS|MILO:/pub/clx.lisp
Message-ID: <870403090502.5.RWS@KILLINGTON.LCS.MIT.EDU>

In a follow-on message, I will send out a proposal for a standard Common
Lisp interface to X Version 11, for public review.  The proposal is also
available via anonymous ftp as /pub/clx.lisp on milo.lcs.mit.edu.  In
addition to myself, the contributors are Mike McMahon (Symbolics),
Dan Cerys (Texas Instruments), John Wroclawski (MIT), and Rich Zippel
(Symbolics).

A message about this proposal is also being sent to the xpert mailing
list, but we expect the primary discussion will take place on the
cl-windows list.  If you need to communicate "directly" with us for some
reason, please send mail to clx@zermatt.lcs.mit.edu.

The interface is intended to provide functionality equivalent to that of
the Xlib interface for C; that is, it is a relatively low-level interface,
"close" to the raw protocol (Level 1 in Mike McMahon's recent layers
message).  The interface has been designed by working directly from the
protocol documentation, and trying to provide a "natural" Lisp interface,
rather than by trying to mimic the precise routines in the C Xlib.

The proposal contains very little "documentation".  We assume that anyone
seriously interested in reviewing the proposal will have read the protocol
document and/or the C Xlib document.  From either of those documents, the
Lisp interface should be fairly obvious, and we have sprinkled a few
comments in various places.  The proposal is based on the expected "Beta
Test" version of the protocol; as such, it contains several changes from
the "Alpha Test" version, most of which should be clear to the reader.

Our intention is to provide a (public) native Common Lisp implementation
of the interface, once the design has gone through a public review.  We
would like to "close" the review on May 15, so that implementation can get
underway.  Anyone wishing to contribute to this effort should send mail to
clx@zermatt.lcs.mit.edu.  We have no intention of providing an
implementation based on a foreign-function interface to the C Xlib,
although we do not wish the design to preclude such an implementation.

It was our desire to define an interface that could be implemented
reasonably in Lisps on conventional hardware, without sacrificing user
programming convenience, but we have very little experience with, or
detailed knowledge of, such Lisp implementations.  Feedback with respect
to performance and feasibility is most welcome.

It is our intention that relatively little programming will take place
using the Xlib facilities directly.  Instead (as indicated in Mike
McMahon's recent message), it is hoped that higher level graphics and
toolkit facilities can be put in place for most programmers to use, and
further that such graphics and toolkit facilities provide sufficient
abstraction as to be relatively independent of a particular virtual
console protocol like X.  Tentative proposals and discussion along these
lines should be forthcoming in the near future.


∂03-Apr-87  0606	@ZERMATT.LCS.MIT.EDU,@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU 	CLX: a proposal
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Apr 87  06:05:45 PST
Received: from KILLINGTON.LCS.MIT.EDU (KILLINGTON.LCS.MIT.EDU) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 40114; 3 Apr 87 09:06:56 EST
Date: Fri, 3 Apr 87 09:06 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX: a proposal
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870403090652.6.RWS@KILLINGTON.LCS.MIT.EDU>

;;; -*- Mode: LISP; Syntax: Common-lisp; Package: (XLIB (CL)); Base: 10; Lowercase: Yes -*-

; Author:
;	Robert W. Scheifler
;	Laboratory for Computer Science
;	545 Technology Square, Room 418
;	Cambridge, MA 02139
;	rws@zermatt.lcs.mit.edu

; Contributors:
;	Mike McMahon, Symbolics
;	Dan Cerys, Texas Instruments
;	John Wroclawski, MIT
;	Rich Zippel, Symbolics

; Note: various perversions of the CL type system are used below.
; Examples: (list elt-type) (sequence elt-type)

(proclaim '(declaration arglist values))

; Note: if you have read the Version 11 protocol document or C Xlib manual, most of
; the relationships should be fairly obvious.  We have no intention of writing yet
; another moby document for this interface.

; Types employed: display, window, pixmap, cursor, font, gc, colormap, color.
; These types are defined solely by a functional interface; we do not specify whether
; they are implemented as structures or flavors or ...  Although functions below are
; written using DEFUN, this is not an implementation requirement (although it is a
; requirement that they be functions as opposed to macros or special forms).  It is
; unclear whether with-slots in the Common Lisp Object System must work on them.

; Windows, pixmaps, cursors, fonts, gcs, and colormaps are all represented as
; compound objects, rather than as integer resource-ids.
; This allows applications to deal with multiple displays without having
; an explicit display argument in every function.  Every function uses the
; display object indicated by the first argument that is or contains a display;
; it is an error if arguments contain different displays, and predictable results
; are not guaranteed.

; Each of window, pixmap, cursor, font, gc, and colormap have the functions:

(defun make-<mumble> (display resource-id)
  ; This function should almost never be called by applications, except in handling events.
  ; To minimize consing in some implementations, this may use a cache in the display.
  ; Make-gc creates with :cache :off.
  (declare (type display display)
	   (type integer resource-id)
	   (values <mumble>)))

(defun <mumble>-display (<mumble>)
  (declare (type <mumble> <mumble>)
	   (values display)))

(defun <mumble>-id (<mumble>)
  (declare (type <mumble> <mumble>)
	   (values integer)))

(defun <mumble>-equal (<mumble>-1 <mumble>-2)
  (declare (type <mumble> <mumble>-1 <mumble>-2)))

(defun <mumble>-p (<mumble>-1 <mumble>-2)
  (declare (type <mumble> <mumble>-1 <mumble>-2)
	   (values boolean)))

; The following functions are provided by color objects:

; The intention is that IHS and YIQ and CYM interfaces will also exist.
; Note that we are explicitly using a different spectrum representation
; than what is actually transmitted in the protocol.

(defun make-color (&key red green blue &allow-other-keys)	; for expansion
  (declare (type (number 0 1) red green blue)
	   (values color)))

(defun color-rgb (color)
  (declare (type color color)
	   (values red green blue)))

(defun color-red (color)
  ; setf'able
  (declare (type color color)
	   (values (number 0 1))))

(defun color-green (color)
  ; setf'able
  (declare (type color color)
	   (values (number 0 1))))

(defun color-blue (color)
  ; setf'able
  (declare (type color color)
	   (values (number 0 1))))

(deftype resource-id () 'integer)

(deftype drawable () '(or window pixmap))

; Atoms are accepted as strings or symbols, and are always returned as keywords.
; Protocol-level integer atom ids are hidden, using a cache in the display object.

(deftype xatom () '(or string symbol))

(deftype stringable () '(or string symbol))

(deftype fontable () '(or stringable font))

; Nil stands for CurrentTime.

(deftype timestamp () '(or null integer))

(deftype bit-gravity () '(member :forget :static :north-west :north :north-east
				 :west :center :east :south-west :south :south-east))

(deftype win-gravity () '(member :unmap :static :north-west :north :north-east
				 :west :center :east :south-west :south :south-east))

(deftype grab-status () '(member :success :already-grabbed :invalid-time :not-viewable))

(deftype boolean () '(or null (not null)))

; An association list.

(deftype alist (key-type-and-name datum-type-and-name) 'list)

; A sequence, containing zero or more repetitions of the given elements,
; with the elements expressed as (type name).

(deftype repeat-seq (&rest elts) 'sequence)

(deftype point-seq () '(repeat-seq (integer x) (integer y)))

(deftype seg-seq () '(repeat-seq (integer x1) (integer y1) (integer x2) (integer y2)))

(deftype rect-seq () '(repeat-seq (integer x) (integer y) (integer width) (integer height)))

; Note that we are explicitly using a different angle representation than what
; is actually transmitted in the protocol.

(deftype angle () `(number ,(* -2 pi) ,(* 2 pi)))

(deftype arc-seq () '(repeat-seq (integer x) (integer y) (integer width) (integer height)
				 (angle angle1) (angle angle2)))

(deftype event-mask-class ()
  '(member :key-press :key-release :owner-grab-button :button-press :button-release
	   :enter-window :leave-window :pointer-motion :pointer-motion-hint
	   :button-1-motion :button-2-motion :button-3-motion :button-4-motion
	   :button-5-motion :button-motion :exposure :visibility-change
	   :structure-notify :resize-redirect :substructure-notify :substructure-redirect
	   :focus-change :property-change :colormap-change :keymap-state))

(deftype event-mask ()
  '(or integer (list event-mask-class)))

(deftype pointer-event-mask-class ()
  '(member :button-press :button-release
	   :enter-window :leave-window :pointer-motion :pointer-motion-hint
	   :button-1-motion :button-2-motion :button-3-motion :button-4-motion
	   :button-5-motion :button-motion :keymap-state))

(deftype pointer-event-mask ()
  '(or integer (list pointer-event-mask-class)))

(deftype device-event-mask-class ()
  '(member :key-press :key-release :button-press :button-release :pointer-motion
	   :button-1-motion :button-2-motion :button-3-motion :button-4-motion
	   :button-5-motion :button-motion))

(deftype device-event-mask ()
  '(or integer (list device-event-mask-class)))

(deftype modifier-key ()
  '(member :shift :caps-lock :control :mod-1 :mod-2 :mod-3 :mod-4 :mod-5))

(deftype modifier-mask ()
  '(or (member :any) integer (list modifier-key)))

(deftype state-mask-key ()
  '(or modifier-key (member :button-1 :button-2 :button-3 :button-4 :button-5)))

(deftype gc-key ()
  '(member :function :plane-mask :foreground :background
	   :line-width :line-style :cap-style :join-style :fill-style :fill-rule
	   :arc-mode :tile :stipple :ts-x :ts-y :font :subwindow-mode
	   :graphics-exposures :clip-x :clip-y :clip-mask :clip-ordering
	   :dash-offset :dashes))

(deftype event-key ()
  '(member :key-press :key-release :button-press :button-release :motion-notify
	   :enter-notify :leave-notify :focus-in :focus-out :keymap-notify
	   :exposure :graphics-exposure :no-exposure :visibility-notify
	   :create-notify :destroy-notify :unmap-notify :map-notify :map-request
	   :reparent-notify :configure-notify :gravity-notify :resize-request
	   :configure-request :circulate-notify :circulate-request :property-notify
	   :selection-clear :selection-request :selection-notify
	   :colormap-notify :client-message))

(deftype error-key ()
  '(member :access :alloc :atom :colormap :cursor :drawable :font :gc :id-choice
	   :illegal-request :implementation :length :match :name :pixmap :property
	   :value :window))

(deftype draw-direction ()
  '(member :left-to-right :right-to-left))

(defstruct pixmap-format
  (depth <unspec> :type integer)
  (bits-per-pixel <unspec> :type (member 4 8 16 32))
  (scanline-pad <unspec> :type (member 8 16 32)))

(defstruct image-info
  (image-lsb-first-p <unspec> :type boolean)
  (bitmap-scanline-unit <unspec> :type (member 8 16 32))
  (bitmap-scanline-pad <unspec> :type (member 8 16 32))
  (bitmap-lsb-first-p <unspec> :type boolean)
  (pixmap-formats <unspec> :type (list pixmap-format)))

(defstruct visual-info
  (id <unspec> :type integer)
  (class <unspec> :type (member :static-gray :static-color :true-color
				:gray-scale :pseudo-color :direct-color))
  (red-mask <unspec> :type integer)
  (green-mask <unspec> :type integer)
  (blue-mask <unspec> :type integer)
  (bits-per-rgb <unspec> :type integer)
  (colormap-entries <unspec> :type integer))

(defstruct screen
  (root <unspec> :type window)
  (device <unspec> :type integer)
  (width <unspec> :type integer)
  (height <unspec> :type integer)
  (width-in-millimeters <unspec> :type integer)
  (height-in-millimeters <unspec> :type integer)
  (depths <unspec> :type (alist (integer depth) ((list visual-info) visuals)))
  (root-depth <unspec> :type integer)
  (root-visual <unspec> :type integer)
  (default-colormap <unspec> :type colormap)
  (white-pixel <unspec> :type integer)
  (black-pixel <unspec> :type integer)
  (min-installed-maps <unspec> :type integer)
  (max-installed-maps <unspec> :type integer)
  (backing-stores <unspec> :type (member :never :when-mapped :always))
  (save-unders-p <unspec> :type boolean)
  (event-mask-at-open <unspec> :type integer))

; To allow efficient storage representations, the type char-info is not
; required to be a structure.

(defun char-left-bearing (char-info)
  (declare (type char-info char-info)
	   (values integer)))

(defun char-right-bearing (char-info)
  (declare (type char-info char-info)
	   (values integer)))

(defun char-width (char-info)
  (declare (type char-info char-info)
	   (values integer)))

(defun char-ascent (char-info)
  (declare (type char-info char-info)
	   (values integer)))

(defun char-descent (char-info)
  (declare (type char-info char-info)
	   (values integer)))

(defun char-attributes (char-info)
  (declare (type char-info char-info)
	   (values integer)))

; alternating keywords and integers

(deftype font-props () 'list)

(defstruct font-info
  (name <unspec> :type string)
  (direction <unspec> :type draw-direction)
  (min-char <unspec> :type integer)
  (max-char <unspec> :type integer)
  (min-byte1 <unspec> :type integer)
  (max-byte1 <unspec> :type integer)
  (min-byte2 <unspec> :type integer)
  (max-byte2 <unspec> :type integer)
  (all-chars-exist-p <unspec> :type boolean)
  (min-bounds <unspec> :type char-info)
  (max-bounds <unspec> :type char-info)
  (ascent <unspec> :type integer)
  (descent <unspec> :type integer)
  (properties <unspec> :type font-props))

(defun open-display (host &key (display 0) protocol)
  ; A string must be acceptable as a host, but otherwise the possible types
  ; for host and protocol are not constrained, and will likely be very
  ; system dependent.  The default protocol is system specific.  Authorization,
  ; if any, is assumed to come from the environment somehow.
  (declare (type integer display)
	   (values display)))

(defun display-protocol-version (display)
  (declare (type display display)
	   (values major minor)))

(defun display-vendor-id (display)
  (declare (type display display)
	   (values name release)))

(defun display-image-info (display)
  (declare (type display display)
	   (values image-info)))

(defun display-roots (display)
  (declare (type display display)
	   (values (list screen))))

(defun display-keyboard (display)
  (declare (type display display)
	   (values integer)))

(defun display-pointer (display)
  (declare (type display display)
	   (values integer)))

(defun display-motion-buffer-size (display)
  (declare (type display display)
	   (values integer)))

(defun display-max-request-length (display)
  (declare (type display display)
	   (values integer)))

(defun close-display (display)
  (declare (type display display)))

(defun display-error-handler (display)
  (declare (type display display)
	   (values handler)))

(defsetf display-error-handler (display) (handler)
  ; All errors (synchronous and asynchronous) are processed by calling
  ; an error handler in the display.  If handler is a function, it is
  ; called with the error-key as its second argument; if handler is
  ; an array it is expected to contain handler functions specific to
  ; each error; the error code is used to index the array, fetching the
  ; appropriate handler. Any results returned by the handler are ignored;
  ; it is assumed the handler either takes care of the error completely,
  ; or else signals. For all core errors, additional keyword/value argument
  ; pairs are:
  ;    :major integer
  ;    :minor integer
  ;    :sequence integer
  ;    :current-sequence integer
  ; For :colormap, :cursor, :drawable, :font, :gc, :id-choice, :pixmap, and :window
  ; errors another pair is:
  ;    :resource-id integer
  ; For :atom errors, another pair is:
  ;    :atom-id integer
  ; For :value errors, another pair is:
  ;    :value integer
  (declare (type display display)
	   (type (or (array (function (display &rest key-vals)))
		     (function (display error-key &rest key-vals)))
		 handler)))

(defun default-error-handler (display error-key &rest key-vals)
  ; The default display-error-handler.
  ; It signals the conditions listed below.
  )

(defmacro define-condition (name base &body items)
  ; just a place-holder here for the real thing
  )

(define-condition request-error error
  display
  major
  minor
  sequence
  current-sequence)

(define-condition resource-error request-error
  resource-id)

(define-condition access-error request-error)

(define-condition alloc-error request-error)

(define-condition atom-error request-error
  atom-id)

(define-condition colormap-error resource-error)

(define-condition cursor-error resource-error)

(define-condition drawable-error resource-error)

(define-condition font-error resource-error)

(define-condition gc-error resource-error)

(define-condition id-choice-error resource-error)

(define-condition illegal-request-error request-error)

(define-condition implementation-error request-error)

(define-condition length-error request-error)

(define-condition match-error request-error)

(define-condition name-error request-error)

(define-condition pixmap-error resource-error)

(define-condition property-error request-error)

(define-condition value-error request-error
  value)

(define-condition window-error resource-error)

(defmacro with-display ((display) &body body)
  ; This macro is for use in a multi-process environment.
  ; It provides exclusive access to the local display object for request generation
  ; and reply processing.  Except where noted, all of the routines below should be
  ; thought of as containing an implicit with-display, so that correct synchronization
  ; is always provided at the interface level on a per-call basis.  Nested uses of this
  ; macro will work correctly.  This macro does not prevent concurrent event processing;
  ; see with-event-queue.
  )

(defun display-force-output (display)
  ; Output is normally buffered, this forces any buffered output.
  (declare (type display display)))

(defun display-finish-output (display)
  ; Forces output, then causes a round-trip to ensure that all possible
  ; errors and events have been received.
  (declare (type display display)))

(defun display-after-function (display)
  ; setf'able (setf form uses with-display)
  ; If defined, called after every protocol request is generated, even those
  ; inside multiply nested with-display's, but never called from inside the
  ; after-function itself.
  ; Default value is nil.
  ; Can be set, for example, to #'display-force-output or #'display-finish-output.
  (declare (type display display)
	   (values (or null (function (display))))))

(defun create-window (&key parent x y width height (depth 0) (border-width 0)
		      (class :copy) (visual :copy)
		      background border
		      bit-gravity win-gravity
		      backing-store backing-bit-planes backing-pixel save-under
		      event-mask do-not-propagate-mask override-redirect
		      colormap cursor)
  ; Display is obtained from parent.  Only non-nil attributes are passed on in
  ; the request: the function makes no assumptions about what the actual protocol
  ; defaults are.  Width and height are the inside size, excluding border.
  (declare (type window parent)
	   (type integer x y width height depth border-width)
	   (type (member :copy :input-output :input-only) class)
	   (type (or (member :copy) visual) visual)
	   (type (or null (member :none :parent-relative) integer pixmap) background)
	   (type (or null (member :copy) integer pixmap) border)
	   (type (or null bit-gravity) bit-gravity)
	   (type (or null win-gravity) win-gravity)
	   (type (or null (member :not-useful :when-mapped :always) backing-store))
	   (type (or null integer) backing-bit-planes backing-pixel)
	   (type (or null event-mask) event-mask)
	   (type (or null device-event-mask) do-not-propagate-mask)
	   (type (or null (member :on :off)) save-under override-redirect)
	   (type (or null (member :copy) colormap) colormap)
	   (type (or null (member :none) cursor) cursor)
	   (values window)))

(defun change-window-attributes (window &key
				 background border
				 bit-gravity win-gravity
				 backing-store backing-bit-planes backing-pixel save-under
				 event-mask do-not-propagate-mask override-redirect
				 colormap cursor)
  ; Should there be individual setfs for these as well?
  ; Rename this change-window and add configure-window args, and drop configure-window?
  (declare (type window window)
	   (type (or null (member :none :parent-relative) integer pixmap) background)
	   (type (or null (member :copy) integer pixmap) border)
	   (type (or null bit-gravity) bit-gravity)
	   (type (or null win-gravity) win-gravity)
	   (type (or null (member :not-useful :when-mapped :always)) backing-store)
	   (type (or null integer) backing-bit-planes backing-pixel)
	   (type (or null event-mask) event-mask)
	   (type (or null device-event-mask) do-not-propagate-mask)
	   (type (or null (member :on :off)) save-under override-redirect)
	   (type (or null (member :copy) colormap) colormap)
	   (type (or null (member :none) cursor) cursor)))

(defun window-attributes (window)
  ; Should there be individual accessors as well?
  ; Order of key-value pairs is not specified.
  (declare (type window window)
	   (values :visual integer
		   :class (member :input-output :input-only)
		   :bit-gravity bit-gravity
		   :win-gravity win-gravity
		   :backing-store (member :not-useful :when-mapped :always)
		   :backing-bit-planes integer
		   :backing-pixel integer
		   :save-under (member :on :off)
		   :colormap (or null colormap)
		   :colormap-installed-p boolean
		   :map-state (member :unmapped :unviewable :viewable)
		   :all-event-masks integer
		   :event-mask integer
		   :do-not-propagate-mask integer
		   :override-redirect (member :on :off))))

(defun destroy-window (window)
  (declare (type window window)))

(defun destroy-subwindows (window)
  (declare (type window window)))

(defun save-set-insert (window)
  (declare (type window window)))

(defun save-set-delete (window)
  (declare (type window window)))

(defun reparent-window (window parent x y)
  (declare (type window window parent)
	   (type integer x y)))

(defun map-window (window)
  (declare (type window window)))

(defun map-subwindows (window)
  (declare (type window window)))

(defun unmap-window (window)
  (declare (type window window)))

(defun unmap-subwindows (window)
  (declare (type window window)))

(defun configure-window (window &key x y width height border-width stack-mode sibling)
  ; Width and height are the inside size, excluding border.
  (declare (type window window)
	   (type (or null integer) x y width height border-width)
	   (type (or null (member :above :below :top-if :bottom-if :opposite)) stack-mode)
	   (type (or null window) sibling)))

(defun circulate-window (window &key up-p)
  (declare (type window window)
	   (type boolean up-p)))

(defun drawable-geometry (drawable)
  ; Width and height are the inside size, excluding border.
  ; Order of key-value pairs is not specified.
  (declare (type drawable drawable)
	   (values :root window
		   :depth integer
		   :x integer
		   :y integer
		   :width integer
		   :height integer
		   :border-width integer)))

(defun drawable-size (drawable)
  ; Width and height are the inside size, excluding border.
  (declare (type drawable drawable)
	   (values width height border-width)))

(defun drawable-rectangle (drawable)
  ; Width and height are the outside size, including border.
  (declare (type drawable drawable)
	   (values x y width height border-width)))

(defun query-tree (window &key (result-type 'list))
  (declare (type window window)
	   (type type result-type)
	   (values (sequence window) parent root)))

(defun store-property (window property data type format
		       &key (mode :replace) (start 0) end transform)
  ; Start and end affect sub-sequence extracted from data.
  ; Transform is applied to each extracted element.
  (declare (type window window)
	   (type xatom property type)
	   (type (member 8 16 32) format)
	   (type sequence data)
	   (type (member :replace :prepend :append) mode)
	   (type (or null integer) start end)
	   (type (or null (function (t) integer)) transform)))

(defun delete-property (window property)
  (declare (type window window)
	   (type xatom property)))

(defun get-property (window property
		     &key type (start 0) end delete-p (result-type 'list) transform)
  ; Transform is applied to each integer retrieved.
  (declare (type window window)
	   (type xatom property)
	   (type (or null xatom) type)
	   (type (or null integer) start end)
	   (type boolean delete-p)
	   (type type result-type)
	   (type (or null (function (integer) t)) transform)
	   (values data type format bytes-after)))

(defun rotate-properties (window properties &optional (delta 1))
  ; Postive rotates left, negative rotates right (opposite of actual protocol request).
  (declare (type window window)
	   (type (sequence xatom) properties)
	   (type integer delta)))

(defun list-properties (window &key (result-type 'list))
  (declare (type window window)
	   (type type result-type)
	   (values (sequence satom))))

(defun set-selection-owner (display selection owner &key time)
  (declare (type display display)
	   (type xatom selection)
	   (type (or null window) owner)
	   (type timestamp time)))

(defun selection-owner (display selection)
  (declare (type display display)
	   (type xatom selection)
	   (values (or null window))))

(defun convert-selection (selection type requestor &key property time)
  (declare (type xatom selection type)
	   (type window requestor)
	   (type (or null xatom) property)
	   (type timestamp time)))

(defun send-event (window event-key event-mask &rest args
		   &key propagate-p &allow-other-keys)
  ; Additional arguments depend on event-key, and are as in next-event.
  ; Should this take resource-ids or resource objects or both in other-keys?
  (declare (type window window)
	   (type event-key event-key)
	   (type event-mask event-mask)
	   (type boolean propagate-p)))

(defun send-event-to-pointer-window (display event-key event-mask &rest args
				     &key propagate-p &allow-other-keys)
  ; Additional arguments depend on event-key, and are as in next-event.
  ; Should this take resource-ids or resource objects or both in other-keys?
  (declare (type display display)
	   (type event-key event-key)
	   (type event-mask event-mask)
	   (type boolean propagate-p)))

(defun send-event-to-input-focus (display event-key event-mask &rest args
				  &key propagate-p &allow-other-keys)
  ; Additional arguments depend on event-key, and are as in next-event.
  ; Should this take resource-ids or resource objects or both in other-keys?
  (declare (type display display)
	   (type event-key event-key)
	   (type event-mask event-mask)
	   (type boolean propagate-p)))

(defun grab-pointer (window event-mask
		     &key owner-p sync-pointer-p sync-keyboard-p confine-to cursor time)
  (declare (type window window)
	   (type pointer-event-mask event-mask)
	   (type boolean owner-p sync-pointer-p sync-keyboard-p)
	   (type (or null window) confine-to)
	   (type (or null cursor) cursor)
	   (type timestamp time)
	   (values grab-status)))

(defun ungrab-pointer (&key time)
  (declare (type timestamp time)))

(defmacro with-pointer-grabbed
	  ((window event-mask
	    &key owner-p sync-pointer-p sync-keyboard-p confine-to cursor time)
	   &body body)
  ; Blocks and retries until :success or :invalid-time.
  ; The body is not executed on :invalid-time.
  ; The body is not surrounded by a with-display.
  )

(defun grab-button (window button event-mask
		    &key (modifiers 0)
			 owner-p sync-pointer-p sync-keyboard-p confine-to cursor)
  (declare (type window window)
	   (type (or (member :any) integer) button)
	   (type modifier-mask modifiers)
	   (type pointer-event-mask event-mask)
	   (type boolean owner-p sync-pointer-p sync-keyboard-p)
	   (type (or null window) confine-to)
	   (type (or null cursor) cursor)))

(defun ungrab-button (window button &key (modifiers 0))
  (declare (type window window)
	   (type (or (member :any) integer) button)
	   (type modifier-mask modifiers)))

(defun change-active-pointer-grab (display event-mask &key cursor time)
  (declare (type display display)
	   (type pointer-event-mask event-mask)
	   (type (or null cursor) cursor)
	   (type timestamp time)))

(defun grab-keyboard (window &key owner-p sync-pointer-p sync-keyboard-p time)
  (declare (type window window)
	   (type boolean owner-p sync-pointer-p sync-keyboard-p)
	   (type timestamp time)
	   (values grab-status)))

(defun ungrab-keyboard (display &key time)
  (declare (type display display)
	   (type timestamp time)))

(defmacro with-keyboard-grabbed ((window &key owner-p sync-pointer-p sync-keyboard-p time)
				 &body body)
  ; Blocks and retries until :success or :invalid-time.
  ; The body is not executed on :invalid-time.
  ; The body is not surrounded by a with-display.
  )

(defun grab-key (window key &key (modifiers 0) owner-p sync-pointer-p sync-keyboard-p)
  (declare (type window window)
	   (type boolean owner-p sync-pointer-p sync-keyboard-p)
	   (type (or (member :any) integer) key)
	   (type modifier-mask modifiers)))

(defun ungrab-key (window key &key (modifiers 0))
  (declare (type window window)
	   (type (or (member :any) integer) key)
	   (type modifier-mask modifiers)))

(defun allow-events (display mode &key time)
  (declare (type display display)
	   (type (member :async-pointer :sync-pointer :async-keyboard :sync-keyboard :replay)
		 mode)
	   (type timestamp time)))

(defun grab-server (display)
  (declare (type display display)))

(defun ungrab-server (display)
  (declare (type display display)))

(defmacro with-server-grabbed ((display) &body body)
  ; The body is not surrounded by a with-display.
  )

(defun query-pointer (window)
  ; Order of key-value pairs is not specified.
  (declare (type window window)
	   (values :x integer
		   :y integer
		   :mask integer
		   :root window
		   :child (or null window)
		   :same-screen-p boolean
		   :root-x integer
		   :root-y integer)))

(defun motion-events (window &key start stop (result-type 'list))
  (declare (type window window)
	   (type timestamp start stop)
	   (type type result-type)
	   (values (repeat-seq (integer x) (integer y) (timestamp time)))))

(defun translate-coordinates (src src-x src-y dst)
  (declare (type window src)
	   (type integer src-x src-y)
	   (type window dst)
	   (values dst-x dst-y child)))

(defun warp-pointer (dst dst-x dst-y)
  (declare (type window dst)
	   (type integer dst-x dst-y)))

(defun conditional-warp-pointer (dst dst-x dst-y src src-x src-y
				 &optional src-width src-height)
  ; Passing in a zero src-width or src-height is a no-op.
  ; A null src-width or src-height translates into a zero value in the protocol request.
  (declare (type window dst src)
	   (type integer dst-x dst-y src-x src-y)
	   (type (or null integer) src-width src-height)))

(defun set-input-focus (display focus revert-to &key time)
  (declare (type display display)
	   (type (or (member :none :pointer-root) window) focus)
	   (type (member :none :parent :pointer-root) revert-to)
	   (type timestamp time)))

(defun input-focus (display)
  (declare (type display display)
	   (values focus revert-to)))

(defun query-keymap (display)
  (declare (type display display)
	   (values (bit-vector 256))))

(defun open-font (display name)
  ; Font objects may be cached and reference counted locally within the display object.
  ; Protocol QueryFont request happens on-demand under the covers.
  ; This might not execute a with-display if the font is cached.
  (declare (type display display)
	   (type stringable name)
	   (values font)))

(defun font-font-info (font)
  (declare (type font font)
	   (values font-info)))

; For each component (<name> <unspec> :type <type>) of font-info,
; there is a corresponding function:

(defun font-<name> (font)
  (declare (type font font)
	   (values <type>)))

(defun font-property (font name)
  (declare (type font font)
	   (type keyword name)
	   (values (or null integer))))

(defun font-char-infos (font)
  (declare (type font font)
	   (values (array char-info))))

(defun font-char-info (font char)
  (declare (type font font)
	   (type integer char)
	   (values (or null char-info))))

(defun font-char16-info (font first-byte second-byte)
  (declare (type font font)
	   (type integer first-byte second-byte)
	   (values (or null char-info))))

(defun close-font (font)
  ; This might not generate a protocol request if the font is reference counted locally.
  (declare (type font font)))

(defun text-width (font string &key (cache-p t))
  ; If no font info is cached locally, and cache-p is nil, this uses the protocol request.
  ; Otherwise, the font info is obtained if necessary, and then the result is computed
  ; locally.
  (declare (type (or font gc) font)
	   (type string string)
	   (values integer)))

(defun text-extents (font string &key (cache-p t))
  ; If no font info is cached locally, and cache-p is nil, this uses the protocol request.
  ; Otherwise, the font info is obtained if necessary, and then the result is computed
  ; locally.
  ; Order of key-value pairs is not specified.
  (declare (type (or font gc) font)
	   (type string string)
	   (values :direction draw-direction
		   :font-ascent integer
		   :font-descent integer
		   :ascent integer
		   :descent integer
		   :width integer
		   :left integer
		   :right integer)))

(defun matching-fonts (display pattern &key (max-fonts 65535) (result-type 'list))
  (declare (type display display)
	   (type string pattern)
	   (type integer max-fonts)
	   (type type result-type)
	   (values (sequence string))))

(defun matching-fonts-and-properties (display pattern
				      &key (max-fonts 65535) (result-type 'list))
  (declare (type display display)
	   (type string pattern)
	   (type integer max-fonts)
	   (type type result-type)
	   (values (sequence font-info))))

(defun font-path (display &key (result-type 'list))
  (declare (type display display)
	   (type type result-type)
	   (values (sequence (or string pathname)))))

(defsetf font-path (display) (paths)
  (declare (type display display)
	   (type (sequence (or string pathname)) paths)))

(defun create-pixmap (&key width height depth drawable)
  (declare (type integer width height depth)
	   (type drawable drawable)
	   (values pixmap)))

(defun free-pixmap (pixmap)
  (declare (type pixmap pixmap)))

(defun create-gc (&key drawable function plane-mask foreground background
		  line-width line-style cap-style join-style fill-style fill-rule
		  arc-mode tile stipple ts-x ts-y font subwindow-mode
		  graphics-exposures clip-x clip-y clip-mask clip-ordering
		  dash-offset dashes
		  (cache :write-back))
  ; Only non-nil components are passed on in the request, but for effective caching
  ; assumptions have to be made about what the actual protocol defaults are.
  ; Note: use of stringable as font will cause an implicit open-font.
  ; Note: papers over protocol SetClipRectangles and SetDashes special cases.
  ; GC state is normally cached locally.  Changing a GC component will have no effect
  ; if the new value matches the cached value.  In :write-back mode, changes are not
  ; sent over the protocol until required by a local operation.  In :write-through
  ; and :off modes, changes are sent immediately.  In :off mode, state is not shadowed
  ; locally.
  ; Should there be accessors?
  (declare (type drawable drawable)
	   (type (or null boole-constant) function)
	   (type (or null integer) plane-mask foreground background line-width
				   ts-x ts-y clip-x clip-y dash-offset)
	   (type (or null (member :solid :dash :double-dash)) line-style)
	   (type (or null (member :not-last :butt :round :projecting)) cap-style)
	   (type (or null (member :miter :round :bevel)) join-style)
	   (type (or null (member :solid :tiled :opaque-stippled :stippled)) fill-style)
	   (type (or null (member :even-odd :winding)) fill-rule)
	   (type (or null (member :chord :pie-slice)) arc-mode)
	   (type (or null pixmap) tile stipple)
	   (type (or null fontable) font)
	   (type (or null (member :clip-by-children :include-inferiors)) subwindow-mode)
	   (type (or null (member :on :off)) graphics-exposures)
	   (type (or null (member :none) pixmap rect-seq) clip-mask)
	   (type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)) clip-ordering)
	   (type (or null integer (sequence integer)) dashes)
	   (type (member :off :write-back :write-through) cache)
	   (values gc)))

(defun change-gc (gc &key function plane-mask foreground background
		  line-width line-style cap-style join-style fill-style fill-rule
		  arc-mode tile stipple ts-x ts-y font subwindow-mode
		  graphics-exposures clip-x clip-y clip-mask clip-ordering
		  dash-offset dashes
		  cache)
  ; Note: papers over protocol SetClipRectangles and SetDashes special cases.
  ; Should there be individual setfs?
  (declare (type gc gc)
	   (type (or null boole-constant) function)
	   (type (or null integer) plane-mask foreground background line-width
				   ts-x ts-y clip-x clip-y dash-offset)
	   (type (or null (member :solid :dash :double-dash)) line-style)
	   (type (or null (member :not-last :butt :round :projecting)) cap-style)
	   (type (or null (member :miter :round :bevel)) join-style)
	   (type (or null (member :solid :tiled :opaque-stippled :stippled)) fill-style)
	   (type (or null (member :even-odd :winding)) fill-rule)
	   (type (or null (member :chord :pie-slice)) arc-mode)
	   (type (or null pixmap) tile stipple)
	   (type (or null fontable) font)
	   (type (or null (member :clip-by-children :include-inferiors)) subwindow-mode)
	   (type (or null (member :on :off)) graphics-exposures)
	   (type (or null (member :none) pixmap rect-seq) clip-mask)
	   (type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)) clip-ordering)
	   (type (or null integer (sequence integer)) dashes)
	   (type (or null (member :off :write-back :write-through) cache))))

(defmacro with-gc ((gc &key function plane-mask foreground background
			    line-width line-style cap-style join-style fill-style fill-rule
			    arc-mode tile stipple ts-x ts-y font subwindow-mode
			    graphics-exposures clip-x clip-y clip-mask clip-ordering
			    dash-offset dashes
			    cache)
		   &body body)
  ; Changes GC components within body, then restores them.
  ; If the cache mode is :off, this will implement save/restore by creating a
  ; temporary GC and doing a copy-gc to and from it.
  ; In a multi-process environment, this locks GC from concurrent use.
  ; The body is not surrounded by a with-display.
  )

(defun copy-gc-components (src dst &rest keys)
  (declare (type gc src dst)
	   (type (list gc-key) keys)))

(defun copy-gc (src dst)
  (declare (type gc src dst))
  ; Copies all components.
  )
	   
(defun free-gc (gc)
  (declare (type gc gc)))

(defun clear-to-background (window &key (x 0) (y 0) width height exposures-p)
  ; Passing in a zero width or height is a no-op.
  ; A null width or height translates into a zero value in the protocol request.
  (declare (type window window)
	   (type integer x y)
	   (type (or null integer) width height)
	   (type boolean exposures-p)))

(defun copy-area (src gc src-x src-y width height dst dst-x dst-y)
  (declare (type drawable src dst)
	   (type gc gc)
	   (type integer src-x src-y width height dst-x dst-y)))

(defun copy-plane (src gc plane src-x src-y width height dst dst-x dst-y)
  (declare (type drawable src dst)
	   (type gc gc)
	   (type integer src-x src-y plane width height dst-x dst-y)))

(defun draw-point (drawable gc x y)
  ; Should be clever about appending to existing buffered protocol request.
  (declare (type drawable drawable)
	   (type gc gc)
	   (type integer x y)))

(defun draw-points (drawable gc points &key relative-p)
  (declare (type drawable drawable)
	   (type gc gc)
	   (type point-seq points)
	   (type boolean relative-p)))

(defun draw-line (drawable gc x1 y1 x2 y2 &key relative-p)
  ; Should be clever about appending to existing buffered protocol request.
  (declare (type drawable drawable)
	   (type gc gc)
	   (type integer x1 y1 x2 y2)
	   (type boolean relative-p)))

(defun draw-lines (drawable gc points &key relative-p fill-p (shape :complex))
  (declare (type drawable drawable)
	   (type gc gc)
	   (type point-seq points)
	   (type boolean relative-p fill-p)
	   (type (member :complex :non-convex :convex) shape)))

(defun draw-segments (drawable gc segments)
  (declare (type drawable drawable)
	   (type gc gc)
	   (type seg-seq segments)))

(defun draw-rectangle (drawable gc x y width height &key fill-p)
  ; Should be clever about appending to existing buffered protocol request.
  (declare (type drawable drawable)
	   (type gc gc)
	   (type integer x y width height)
	   (type boolean fill-p)))

(defun draw-rectangles (drawable gc rectangles &key fill-p)
  (declare (type drawable drawable)
	   (type gc gc)
	   (type rect-seq rectangles)
	   (type boolean fill-p)))

(defun draw-arc (drawable gc x y width height angle1 angle2 &key fill-p)
  ; Should be clever about appending to existing buffered protocol request.
  (declare (type drawable drawable)
	   (type gc gc)
	   (type integer x y width height angle1 angle2)
	   (type boolean fill-p)))

(defun draw-arcs (drawable gc arcs &key fill-p)
  (declare (type drawable drawable)
	   (type gc gc)
	   (type arc-seq arcs)
	   (type boolean fill-p)))

; The following image routines are bare minimum.  It may be useful to define
; some form of "image" object to hide representation details and format
; conversions.  It also may be useful to provide stream-oriented interfaces
; for reading and writing the data.

(defun put-raw-image (drawable gc data
		      &key (start 0) depth x y width height (left-pad 0) format)
  ; Data must be a sequence of 8-bit quantities, already in the appropriate format
  ; for transmission; the caller is responsible for all byte and bit swapping and
  ; compaction.  Start is the starting index in data; the end is computed from the
  ; other arguments.
  (declare (type drawable drawable)
	   (type gc gc)
	   (type (sequence integer) data)
	   (type integer depth x y width height left-pad)
	   (type (member :bitmap :xy-pixmap :z-pixmap) format)))

(defun get-raw-image (drawable &key data (start 0) x y width height (plane-mask -1) format
				    (result-type '(vector (unsigned-byte 8))))
  ; If data is given, it is modified in place (and returned), otherwise a new sequence
  ; is created and returned, with a size computed from the other arguments and the
  ; returned depth.  The sequence is filled with 8-bit quantities, in transmission
  ; format; the caller is responsible for any byte and bit swapping and compaction
  ; required for further local use.
  (declare (type drawable drawable)
	   (type (or null (sequence integer)) data)
	   (type integer start x y width height plane-mask)
	   (type (member :xy-format z-format) format)
	   (values (sequence integer) depth visual)))

(defun draw-string (drawable gc x y string)
  ; For 8-bit indexes only.
  ; Should be clever about appending to existing buffered protocol request.
  (declare (type drawable drawable)
	   (type gc gc)
	   (type integer x y)
	   (type string string)))

(defun draw-text (drawable gc items)
  ; For 8-bit indexes only.
  ; Items is a flat sequence containing both triples and pairs of the form:
  ; (integer x) (integer y) (string string)
  ; :font (fontable font)
  (declare (type drawable drawable)
	   (type gc gc)
	   (type sequence items)))

(defun draw-string-image (drawable gc x y string)
  ; For 8-bit indexes only.
  (declare (type drawable drawable)
	   (type gc gc)
	   (type integer x y)
	   (type string string)))

(defun draw-string16 (drawable gc x y array &key bytes-p)
  ; Should be clever about appending to existing buffered protocol request.
  ; If bytes-p is nil, then array should be an array of integers to be
  ; treated as 16-bit quantities, otherwise array should be a string of
  ; even length, treated as first-byte/second-byte pairs.
  (declare (type drawable drawable)
	   (type gc gc)
	   (type integer x y)
	   (type array array)))

(defun draw-text16 (drawable gc items &key bytes-p)
  ; Items is a flat sequence containing both triples and pairs of the form:
  ; (integer x) (integer y) (array array)
  ; :font (fontable font)
  ; If bytes-p is nil, then array should be an array of integers to be
  ; treated as 16-bit quantities, otherwise array should be a string of
  ; even length, treated as first-byte/second-byte pairs.
  (declare (type drawable drawable)
	   (type gc gc)
	   (type sequence items)))

(defun draw-string-image16 (drawable gc x y array &key bytes-p)
  ; If bytes-p is nil, then array should be an array of integers to be
  ; treated as 16-bit quantities, otherwise array should be a string of
  ; even length, treated as first-byte/second-byte pairs.
  (declare (type drawable drawable)
	   (type gc gc)
	   (type integer x y)
	   (type array array)))

(defun create-colormap (visual window &key alloc-p)
  (declare (type integer visual)
	   (type window window)
	   (type boolean alloc-p)
	   (values colormap)))

(defun free-colormap (colormap)
  (declare (type colormap colormap)))

(defun copy-colormap-and-free (colormap)
  (declare (type colormap colormap)
	   (values colormap)))

(defun install-colormap (colormap)
  (declare (type colormap colormap)))

(defun uninstall-colormap (colormap)
  (declare (type colormap colormap)))

(defun installed-colormaps (window &key (result-type 'list))
  (declare (type window window)
	   (type type result-type)
	   (values (sequence colormap))))

(defun alloc-color (colormap color)
  (declare (type colormap colormap)
	   (type (or stringable color) color)
	   (values pixel screen-color exact-color)))

(defun alloc-color-cells (colormap colors &key (planes 0) contiguous-p (result-type 'list))
  (declare (type colormap colormap)
	   (type integer colors planes)
	   (type boolean contiguous-p)
	   (type type result-type)
	   (values (sequence pixel) (sequence mask))))

(defun alloc-color-planes (colormap colors
			   &key (reds 0) (greens 0) (blues 0)
				contiguous-p (result-type 'list))
  (declare (type colormap colormap)
	   (type integer colors reds greens blues)
	   (type boolean contiguous-p)
	   (type type result-type)
	   (values (sequence pixel) red-mask green-mask blue-mask)))

(defun free-colors (colormap pixels &key (plane-mask 0))
  (declare (type colormap colormap)
	   (type (sequence integer) pixels)
	   (type integer plane-mask)))

(defun store-color (colormap pixel spec &key (red-p t) (green-p t) (blue-p t))
  (declare (type colormap colormap)
	   (type integer pixel)
	   (type (or stringable color) spec)
	   (type boolean red-p green-p blue-p)))

(defun store-colors (colormap specs &key (red-p t) (green-p t) (blue-p t))
  (declare (type colormap colormap)
	   (type (repeat-seq (integer pixel) (color color)) specs)
	   (type boolean red-p green-p blue-p)))

(defun query-colors (colormap pixels &key (result-type 'list))
  (declare (type colormap colormap)
	   (type (sequence integer) pixels)
	   (type type result-type)
	   (values (sequence color))))

(defun lookup-color (colormap name)
  (declare (type colormap colormap)
	   (type stringable name)
	   (values screen-color true-color)))

(defun create-cursor (&key source mask x y foreground background)
  (declare (type pixmap source)
	   (type (or null pixmap) mask)
	   (type integer x y)
	   (type color foreground background)
	   (values cursor)))

(defun create-glyph-cursor (&key source-font source-char mask-font mask-char
			    foreground background)
  (declare (type font source-font)
	   (type integer source-char)
	   (type (or null font) mask-font)
	   (type (or null integer) mask-char)
	   (type color foreground background)
	   (values cursor)))

(defun free-cursor (cursor)
  (declare (type cursor cursor)))

(defun recolor-cursor (cursor foreground background)
  (declare (type cursor cursor)
	   (type color foreground background)))

(defun query-best-cursor (width height display)
  (declare (type integer width height)
	   (type display display)
	   (values width height)))

(defun query-best-tile (width height drawable)
  (declare (type integer width height)
	   (type drawable drawable)
	   (values width height)))

(defun query-best-stipple (width height drawable)
  (declare (type integer width height)
	   (type drawable drawable)
	   (values width height)))

(defun query-extension (display name)
  (declare (type display display)
	   (type stringable name)
	   (values major-opcode first-event first-error)))

(defun list-extensions (display &key (result-type 'list))
  (declare (type display display)
	   (type type result-type)
	   (values (sequence string))))

(defun keyboard-mapping (display &key (result-type 'list))
  (declare (type display display)
	   (type type result-type)
	   (values (sequence integer))))

(defsetf keyboard-mapping (display) (map)
  (declare (type display display)
	   (type (sequence integer) map)))

(defun change-keyboard-control (display &key key-click-percent
				bell-percent bell-pitch bell-duration
				led led-mode key auto-repeat-mode)
  (declare (type display display)
	   (type (or null (member :default) integer) key-click-percent
						     bell-percent bell-pitch bell-duration)
	   (type (or null integer) led key)
	   (type (or null (member :on :off)) led-mode)
	   (type (or null (member :on :off :default)) auto-repeat-mode)))

(defun keyboard-control (display)
  ; Order of key-value pairs is not specified.
  (declare (type display display)
	   (values :key-click-percent integer
		   :bell-percent integer
		   :bell-pitch integer
		   :bell-duration integer
		   :led-mask integer
		   :global-auto-repeat (member :on :off)
		   :auto-repeats (bit-vector 256))))

(defun bell (display &optional (percent-from-normal 0))
  ; It is assumed that an eventual audio extension to X will provide more complete control.
  (declare (type display display)
	   (type integer percent-from-normal)))

(defun pointer-mapping (display &key (result-type 'list))
  (declare (type display display)
	   (type type result-type)
	   (values (sequence integer))))

(defsetf pointer-mapping (display) (map)
  (declare (type display display)
	   (type (sequence integer) map)))

(defun change-pointer-control (display &key acceleration threshold)
  (declare (type display display)
	   (type (or null (member :default) rational) acceleration)
	   (type (or null (member :default) integer) threshold)))

(defun pointer-control (display)
  (declare (type display display)
	   (values acceleration threshold)))

(defun set-screen-saver (display timeout interval blanking exposures)
  ; Timeout and interval are in seconds, will be rounded to minutes.
  (declare (type display display)
	   (type (or (member :default) integer) timeout interval)
	   (type (member :yes :no :default) blanking exposures)))

(defun screen-saver (display)
  ; Returns timeout and interval in seconds.
  (declare (type display display)
	   (values timeout interval blanking exposures)))

(defun activate-screen-saver (display)
  (declare (type display display)))

(defun reset-screen-saver (display)
  (declare (type display display)))

(defun add-access-hosts (display hosts &key protocol)
  ; A string must be acceptable as a host, but otherwise the possible types for
  ; hosts and protocol are not constrained, and will likely be very system dependent.
  ; The default protocol is system specific.
  (declare (type display display)
	   (type sequence hosts)))

(defun rem-access-hosts (display hosts &key protocol)
  ; A string must be acceptable as a host, but otherwise the possible types for
  ; hosts and protocol are not constrained, and will likely be very system dependent.
  ; The default protocol is system specific.
  (declare (type display display)
	   (type sequence hosts)))

(defun access-hosts (display &key protocol (result-type 'list))
  ; The default protocol is system specific.
  ; The type of host objects returned is not constrained, except that the hosts must
  ; be acceptable to add-access-hosts and rem-access-hosts.
  (declare (type display display)
	   (type type result-type)
	   (values (sequence host) enabled-p)))

(defun access-control (display)
  ; setf'able
  (declare (type display display)
	   (values boolean)))

(defun close-down-mode (display)
  ; setf'able
  ; Cached locally in display object.
  (declare (type display display)
	   (values (member :destroy :retain-permanent :retain-temporary))))

(defun kill-client (display resource-id)
  (declare (type display display)
	   (type resource-id resource-id)))

(defun kill-temporary-clients (display)
  (declare (type display display)))

(defun make-event-mask (&rest keys)
  ; This is only defined for core events.
  ; Useful for constructing event-mask, pointer-event-mask, device-event-mask.
  (declare (type (list event-mask-class) keys)
	   (values integer)))

(defun make-event-keys (event-mask)
  ; This is only defined for core events.
  (declare (type integer event-mask)
	   (values (list event-mask-class))))

(defun make-state-mask (&rest keys)
  ; Useful for constructing modifier-mask, state-mask.
  (declare (type (list state-mask-key) keys)
	   (values integer)))

(defun make-state-keys (state-mask)
  (declare (type integer mask)
	   (values (list state-mask-key))))

(defmacro with-event-queue ((display) &body body)
  ; exclusive access to event queue
  )

(defun event-listen (display)
  (declare (type display display))
  ; Returns the number of events queued locally, if any, else nil.
  )

(defun next-event (display &key handler (hang-p t) peek-p discard-p flush-p)
  ; If flush-p is true, first invokes display-flush-output.
  ; Invokes handler on each queued event until handler returns non-nil,
  ; and that returned object is then returned by next-event.  If discard-p
  ; is true, then events for which handler returns nil are removed from
  ; the queue, otherwise they are left in place.  If handler is a function,
  ; it is called with the event-key as its second argument.  If handler is
  ; an array, it is expected to contain handler functions specific to each
  ; event class; the event code is used to index the array, fetching the
  ; appropriate handler.  Handler is called with raw resource-ids, not with
  ; resource objects.
  (declare (type display display)
	   (type (or (array (function (display &rest key-vals) t))
		     (function (display event-key &rest key-vals) t))
		 handler)
	   (type boolean hang-p peek-p)))

(defmacro event-case ((display &key hang-p peek-p discard-p flush-p)
		      &body clauses)
  (declare (arglist (display &key hang-p peek-p discard-p flush-p)
		    (event-or-events ((&rest args) |...|) &body body) |...|))
  ; Macro convenience for a call to next-event with a lexical closure.
  ; Event-or-events is an event-key or a list of event-keys; they need not
  ; be typed as keywords.  Args is the list of event components of interest;
  ; corresponding values (if any) are bound to variables with these names.
  )

(defmacro declare-event (event-codes &rest declares)
  ; Used to indicate the keyword arguments for handler functions in next-event.
  (declare (arglist event-key-or-keys &rest (type &rest keywords))))

(declare-event (:key-press :key-release :button-press :button-release)
	       (resource-id window root)
	       ((or null resource-id) child)
	       (boolean same-screen-p)
	       (integer x y root-x root-y state time)
	       ; for key-press and key-release, code is the keycode
	       ; for button-press and button-release, code is the button number
	       (integer code))

(declare-event :motion-notify
	       (resource-id window root)
	       ((or null resource-id) child)
	       (boolean same-screen-p)
	       (integer x y root-x root-y state time)
	       (boolean hint-p))

(declare-event (:enter-notify :leave-notify)
	       (resource-id window root)
	       ((or null resource-id) child)
	       (boolean same-screen-p)
	       (integer x y root-x root-y state time)
	       ((member :normal :grab :ungrab) mode)
	       ((member :ancestor :virtual :inferior :nonlinear :nonlinear-virtual) kind)
	       (boolean focus-p))

(declare-event (:focus-in :focus-out)
	       (resource-id window)
	       ((member :normal :while-grabbed :grab :ungrab) mode)
	       ((member :ancestor :virtual :inferior :nonlinear :nonlinear-virtual
			:pointer :pointer-root :none)
		kind))

(declare-event :keymap-notify
	       (resource-id window)
	       ((bit-vector 256) keymap))

(declare-event :exposure
	       (resource-id window)
	       (integer x y width height)
	       (boolean last-p))

(declare-event :graphics-exposure
	       (resource-id drawable)
	       (integer x y width height major minor)
	       (boolean last-p))

(declare-event :no-exposure
	       (resource-id drawable)
	       (integer major minor))

(declare-event :visibility-notify
	       (resource-id window)
	       ((member :unobscured :partially-obscured :fully-obscured) state))

(declare-event :create-notify
	       (resource-id window parent)
	       (integer x y width height border-width)
	       (boolean override-redirect-p))

(declare-event :destroy-notify
	       (resource-id event-window window))

(declare-event :unmap-notify
	       (resource-id event-window window)
	       (boolean configure-p))

(declare-event :map-notify
	       (resource-id event-window window)
	       (boolean override-redirect-p))

(declare-event :map-request
	       (resource-id parent window))

(declare-event :reparent-notify
	       (resource-id event-window window parent)
	       (integer x y)
	       (boolean override-redirect-p))

(declare-event :configure-notify
	       (resource-id event-window window)
	       (integer x y width height border-width)
	       ((or null resource-id) above-sibling)
	       (boolean override-redirect-p))

(declare-event :gravity-notify
	       (resource-id event-window window)
	       (integer x y))

(declare-event :resize-request
	       (resource-id window)
	       (integer width height))

(declare-event :configure-request
	       (resource-id parent window)
	       (integer x y width height border-width)
	       ((or null resource-id) above-sibling))

(declare-event :circulate-notify
	       (resource-id event-window window)
	       ((member :top :bottom) place))

(declare-event :circulate-request
	       (resource-id parent window)
	       ((member :top :bottom) place))

(declare-event :property-notify
	       (resource-id window)
	       (keyword atom)
	       ((member :new-value :deleted) state)
	       (integer time))

(declare-event :selection-clear
	       (resource-id window)
	       (keyword selection)
	       (integer time))

(declare-event :selection-request
	       (resource-id window requestor)
	       (keyword selection target)
	       ((or null keyword) property)
	       (integer time))

(declare-event :selection-notify
	       (resource-id window)
	       (keyword selection target)
	       ((or null keyword) property)
	       (integer time))

(declare-event :colormap-notify
	       (resource-id window)
	       ((or null resource-id) colormap)
	       (boolean new-p installed-p))

(declare-event :client-message
	       (resource-id window)
	       ((member 8 16 32) format)
	       ((sequence integer) data))

(defun event-queue-length (display)
  (declare (type display display)
	   (values length)))

(defun queue-event-locally (display event-code &rest args &key append-p &allow-other-keys)
  (declare (type display display)
	   (type integer event-code)
	   (type boolean append-p)))


∂03-Apr-87  0632	AVELLIS%IBACSATA.BITNET@forsythe.stanford.edu 	subscription 
Received: from LINDY.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Apr 87  06:32:21 PST
Received: by lindy.STANFORD.EDU; Fri, 3 Apr 87 06:34:07 PST
Date: Fri,  3 Apr 87 06:35:25 PST
From: <AVELLIS%IBACSATA.BITNET@forsythe.stanford.edu>
To: CL-WINDOWS@sail.stanford.edu
Subject: subscription

Received: by IBACSATA (Mailer X1.23b) id 5394; Fri, 03 Apr 87 16:32:02 GMT
Date:         Fri, 03 Apr 87 16:31:24 GMT
From:         Gianna Avellis <AVELLIS@IBACSATA>
Subject:      subscription
To:           CL-WINDOWS@SAIL.STANFORD.EDU


Please subscribe me to the list.
             Thank you in advance,

              GIANNA AVELLIS

∂03-Apr-87  0839	dcmartin@ingres.berkeley.edu 	X/Common LISP library package (Beta release) 
Received: from INGRES.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 3 Apr 87  08:39:40 PST
Received: by ingres.Berkeley.EDU (5.57/1.14)
	id AA29114; Fri, 3 Apr 87 08:36:24 PST
Message-Id: <8704031636.AA29114@ingres.Berkeley.EDU>
From: "David C. Martin" <dcmartin@ingres.berkeley.edu>
Office: 440 Evans - x2-9585
Home: 2441 Haste St #37, Berkeley, CA 94704 - (415) 843-6470
Fortran: is not backward, NARTROF is backwards.
To: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Cc: cl-windows@sail.stanford.edu, clx@zermatt.lcs.mit.edu
Precedence: priority-mail
In-Reply-To: Your message of Fri, 3 Apr 87 09:05 EST
Subject: X/Common LISP library package (Beta release)
Date: 03 Apr 87 08:36:21 PST (Fri)
Sender: dcmartin@ingres.berkeley.edu

Prompted by the CLX proposal...

This message is to announce the availability of a foreign function interface
CommonLISP X interface for protocol version 10.  The sources are available by
public ftp from ingres.Berkeley.EDU in the directory pub/xcl.  Documentation
is located in pub/xcl/doc and demo programs in pub/xcl/demo.

Individuals who cannot access the ARPAnet may receive the software for $100 
tape charge from the EECS Department of UCB.

The XCL package currently only has support for the Franz, Inc foreign function
interface, but a Lucid interface should be completed shortly.

If anyone has questions about this software send mail to xcl-users-request
@ ingres.berkeley.edu.

dcm
-----
David C. Martin
-----
arpa: dcmartin@ingres.Berkeley.EDU
uucp: {ihnp4,decvax}!ucbvax!dcmartin
at&t: 415/642-9585 (O)

∂09-Apr-87  0703	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	revisions to CLX proposal   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87  07:03:34 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Apr 87 10:01-EDT
Date: Thu, 9 Apr 87 10:05 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: revisions to CLX proposal
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870409100516.1.RWS@KILLINGTON.LCS.MIT.EDU>

In next-event and event-case, the flush-p argument should be
force-p, and causes display-force-output to be called.

Missing functions:

(defun force-gc-changes (gc)
  ;; Force any pending changes if the cache mode is :write-back.
  (declare (type gc gc)))

;; Although atom-ids are not visible in the normal user interface, atom-ids might
;; appear in window properties and other user data, so conversion hooks are needed.

(defun intern-atom (display name)
  (declare (type display display)
	   (type xatom name)
	   (values integer)))

(defun find-atom (display name)
  (declare (type display display)
	   (type xatom name)
	   (values (or null integer))))

(defun atom-name (display atom-id)
  (declare (type display display)
	   (type integer atom-id)
	   (values keyword)))

The multiple value keyword/value returns in the functions window-attributes,
drawable-geometry, query-pointer, text-extents, and keyboard-control
are not particularly tractable in CL, except in conjunction
with multiple-value-list or multiple-value-call.  So, these
functions are changed to return a single property list instead.
In addition, the following macro forms are provided (with implementations
designed to avoid consing):

(defmacro let-from-window-attributes (bindings window &body body))
(defmacro setq-from-window-attributes (bindings window))
(defmacro let-from-drawable-geometry (bindings drawable &body body))
(defmacro setq-from-drawable-geometry (bindings drawable)
(defmacro let-from-query-pointer (bindings window &body body))
(defmacro setq-from-query-pointer (bindings window))
(defmacro let-from-text-extents (bindings (font string &key (cache-p t)) &body body))
(defmacro setq-from-text-extents (bindings font string &key (cache-p t)))
(defmacro let-from-keyboard-control (bindings display &body body))
(defmacro setq-from-keyboard-control (bindings display))

In each case, bindings is a list with elements of the form (var keyword), where
the keyword must be one from the plist type returned by the corresponding function.
[The syntax is a mixture of let and multiple-value-bind.]  Note that the text-extents
macros are a bit different, due to the multiple arguments.  The names and syntax are
the best that I could come up with; suggestions for improvement are welcome.

∂09-Apr-87  0745	RAM@C.CS.CMU.EDU 	revisions to CLX proposal  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87  07:44:53 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 9 Apr 87 10:45:47-EDT
Date: Thu, 9 Apr 1987  10:45 EDT
Message-ID: <RAM.12293141952.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: revisions to CLX proposal
In-reply-to: Msg of 9 Apr 1987  10:05-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>


Gag me with a spoon!  The keyword values hack was on my list of things
that had to be fixed, but the cure seems even more vile.  There are
two obvious acceptable solutions:
 -- Use as many positional values as necessary.
 -- Return a structure.

Although I agree that with more than 10 or 15 positional values,
things to start to get a bit unmanagable, I have lived with interfaces
that did this sort of thing.

I also see returning a structure as acceptable in interfaces that
aren't obviously performance critical.  Returning a structure is
probably always more efficienct than a plist, and I happen to think it
is much more tasteful.

  Rob

∂09-Apr-87  0803	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	plist revisions to CLX proposal  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87  08:03:38 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Apr 87 10:59-EDT
Date: Thu, 9 Apr 87 11:03 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: plist revisions to CLX proposal
To: RAM@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12293141952.BABYL@C.CS.CMU.EDU>
Message-ID: <870409110331.7.RWS@KILLINGTON.LCS.MIT.EDU>

I'm assuming that the macro forms will get used most of the time;
do you dislike them as well, or just the plist in the function?

I don't have any particularly strong arguments for a plist over a
structure, but I think having that many positional values just isn't
manageable.  The only slight preference I had for the plist was
its possible use in an apply to change values back.  If there
is general agreement that a structure would be better, fine with me.

∂09-Apr-87  0843	FAHLMAN@C.CS.CMU.EDU 	plist revisions to CLX proposal  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87  08:42:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 9 Apr 87 11:43:48-EDT
Date: Thu, 9 Apr 1987  11:43 EDT
Message-ID: <FAHLMAN.12293152538.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: plist revisions to CLX proposal
In-reply-to: Msg of 9 Apr 1987  11:03-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>


I think that using a structure to pass these bundled values around is
the right thing.  If we go ahead and assume the existence of the Common
Lisp Object Standard (and I no longer see any reason to avoid this --
people will want to use it for their higher-level graphics hacking
anyway), then your macros aren't needed: WITH-SLOTS gives convenient
access by name to the various slots of the structure.

If there are still people out there who are fanatically CONS-averse,
neither the property list nor the structure solution will make them
happy, compared with a non-consing solution that uses positional
multiple values.  One possibility might be to return structures, but to
provide all these structure-returning forms with an optional argument by
which the user can pass in a structure of the appropriate type that is
to be destructively modified.  This avoids the need for consing up lots
of new structures, and also the need for copyingof values by the user
when the returned information is to be used outside the current dynamaic
extent.

-- Scott

∂09-Apr-87  1135	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	Re: what package is the CLX stuff in? 
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87  11:34:33 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Apr 87 14:32-EDT
Date: Thu, 9 Apr 87 14:36 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: what package is the CLX stuff in?
To: Fischer.pa@XEROX.COM
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870409-094816-2359@Xerox>
Message-ID: <870409143610.0.RWS@KILLINGTON.LCS.MIT.EDU>

I'm not sure how/why so many people are missing this, but I sure
thought the proposal I sent out had XLIB listed as the package name.

∂09-Apr-87  1213	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	plist revisions to CLX proposal  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87  12:13:02 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Apr 87 15:10-EDT
Date: Thu, 9 Apr 87 15:14 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: plist revisions to CLX proposal
To: Fahlman@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12293152538.BABYL@C.CS.CMU.EDU>
Message-ID: <870409151433.4.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Thu, 9 Apr 1987  11:43 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

		  your macros aren't needed: WITH-SLOTS gives convenient
    access by name to the various slots of the structure.

    If there are still people out there who are fanatically CONS-averse,
    neither the property list nor the structure solution will make them
    happy, compared with a non-consing solution that uses positional
    multiple values.

The macro forms I proposed can be implemented entirely without consing,
and don't require positional multiple values either.  I didn't claim
(or expect) they would be implemented on top of the plist/structure
returning function.  If that had been the case, I would indeed have
agreed that with-slots was sufficient.

		      One possibility might be to return structures, but to
    provide all these structure-returning forms with an optional argument by
    which the user can pass in a structure of the appropriate type that is
    to be destructively modified.

In most situations I would expect the functions to be called "on-the-fly",
and it would be inconvenient to squirrel away a pre-consed structure
somewhere.

∂09-Apr-87  1354	FAHLMAN@C.CS.CMU.EDU 	plist revisions to CLX proposal  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87  13:54:37 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 9 Apr 87 16:55:35-EDT
Date: Thu, 9 Apr 1987  16:55 EDT
Message-ID: <FAHLMAN.12293209297.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: plist revisions to CLX proposal


    The macro forms I proposed can be implemented entirely without consing,
    and don't require positional multiple values either.  I didn't claim
    (or expect) they would be implemented on top of the plist/structure
    returning function.  If that had been the case, I would indeed have
    agreed that with-slots was sufficient.

OK.  I misunderstood what you were proposing.

[In the following, I speak of window attributes, but the other cases
would be handled in parallel ways.]

I could live with any of the following:

1. Only define functions that return and accept all the attributes of a
window as structures.  Leave it up to the compiler to eliminate any
unneccessary structure-consing (though few compilers would bother).

2. Define functions that return and accept structures, as above, plus
another set of functions for accessing and modifying INDIVIDUAL
attributes of a window.  Implementations in which it is expensive to
cross the boundary between Lisp and wherever the window data lives could
do some cacheing, if they want to be maximally tense.

3. Define functions that return and accept structures, plus the kinds of
macros RWS proposed earlier.  This would be the way to go if we feel
that (a) these accesses occur often enough that excess consing would be
a significant load and (b) in these cases where performance matters, you
often want more than one attribute from a given window.  I kind of doubt
that we're in this situation, but I'll defer to RWS's greater experience
in such matters.

If we go with plan 3, it might be a good idea to adopt syntax that more
closely parallels that of With-Slots.  Something like the following
might work:

Define a Window-Attributes class (or structure) with slots named Visual,
Class, etc.

Define a function named Window-Attributes that takes a window and
returns a window-attributes structure, properly filled in.  This would
be setf-able: you pass in a window-attributes structure as the new
value, and the window gets updated to match this.

Define a macro With-Window-Attributes to be functionally equivalent to
the following, except that it might never cons up the structure in
question.  <W> is some anonymous internal gensym that the user can't get
at from within the body code.

(defmacro with-window-attributes ((window) &body body)
  `(let ((<w> (window-attributes ,window)))
     (with-slots ((<w> :class window-attributes))
       ,@body)
     (setf (window-attributes ,window) <w>)))

Some cleverness might be used to avoid the final setf if none of the
slots were modified by code in the body.  As in With-Slots, you could
have multiple window arguments with different prefixes so that the
body could copy attributes from one window to another, or whatever.

A similar set of widgets would be defined for drawable-geometry,
query-pointer, and so on.

-- Scott

∂09-Apr-87  1443	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	plist revisions to CLX proposal  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87  14:42:47 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Apr 87 17:40-EDT
Date: Thu, 9 Apr 87 17:44 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: plist revisions to CLX proposal
To: Fahlman@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12293209297.BABYL@C.CS.CMU.EDU>
Message-ID: <870409174401.3.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Thu, 9 Apr 1987  16:55 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    3. Define functions that return and accept structures, plus the kinds of
    macros RWS proposed earlier.  This would be the way to go if we feel
    that (a) these accesses occur often enough that excess consing would be
    a significant load and (b) in these cases where performance matters, you
    often want more than one attribute from a given window.  I kind of doubt
    that we're in this situation, but I'll defer to RWS's greater experience
    in such matters.

For most of the functions, I don't expect that calls occur often enough
to worry about consing, but I was trying to make non-consing possible to
them's that cared, while still providing convenience in general.  For
all of the functions in question, I think it more likely that one will
want two or three values, rather than one or all.  Since the interface
is really intended for use when the display is remote, making multiple
protocol requests is both expensive and prone to race conditions.
Perhaps handling all of the functions in a uniform way isn't necessary.
I would say the only potentially "critical" functions are query-pointer
and text-extents, both of which might be called fairly often, and both
of which return a fair amount of stuff that any single call probably
won't care about.  However, it might be that a few carefully selected
value subsets (as I have already done a bit of with drawable-size,
drawable-rectangle, and text-width) would be sufficient, in conjunction
with the full-structure returns for the general case, and eliminate
macro forms entirely.

    (defmacro with-window-attributes ((window) &body body)
      `(let ((<w> (window-attributes ,window)))
	 (with-slots ((<w> :class window-attributes))
	   ,@body)
	 (setf (window-attributes ,window) <w>)))

I view this as overkill.  I really consider the read-and-bind as the
important consideration; I don't think having a convenient way to change
them is at all important (and there are lots of return values involved
in the various functions for which setf isn't appropriate).

∂09-Apr-87  1701	FAHLMAN@C.CS.CMU.EDU 	plist revisions to CLX proposal  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87  17:01:39 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 9 Apr 87 20:02:32-EDT
Date: Thu, 9 Apr 1987  20:02 EDT
Message-ID: <FAHLMAN.12293243327.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: plist revisions to CLX proposal
In-reply-to: Msg of 9 Apr 1987  17:44-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>


    I would say the only potentially "critical" functions are query-pointer
    and text-extents, both of which might be called fairly often, and both
    of which return a fair amount of stuff that any single call probably
    won't care about.  However, it might be that a few carefully selected
    value subsets (as I have already done a bit of with drawable-size,
    drawable-rectangle, and text-width) would be sufficient, in conjunction
    with the full-structure returns for the general case, and eliminate
    macro forms entirely.

Seems reasonable.

        (defmacro with-window-attributes ((window) &body body)
          `(let ((<w> (window-attributes ,window)))
    	 (with-slots ((<w> :class window-attributes))
    	   ,@body)
    	 (setf (window-attributes ,window) <w>)))

    I view this as overkill.  I really consider the read-and-bind as the
    important consideration; I don't think having a convenient way to change
    them is at all important (and there are lots of return values involved
    in the various functions for which setf isn't appropriate).

Well, I don't care about the SETF part.  The point was that if it's
worth having these macros, it might be worth tracking the With-Slots
syntax.  Getting rid of them is better still.

-- Scott

∂09-Apr-87  2327	unido!gmdzi!jc@seismo.CSS.GOV 	plist revisions to CLX proposal   
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 9 Apr 87  23:27:10 PDT
Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP 
	id AA23069; Fri, 10 Apr 87 02:28:04 EDT
Received: by unido.uucp with uucp; 
	  Fri, 10 Apr 87 06:49:47 +0100
Received: by gmdzi.UUCP id AA07046; Thu, 9 Apr 87 23:18:51 -0100
Received: by gmdzi.UUCP id AA06116; Thu, 9 Apr 87 20:07:27 -0100
Received: by unido.uucp with uucp; 
	  Thu, 9 Apr 87 19:24:02 +0100
Received: by seismo.CSS.GOV (5.54/1.14) 
	id AA01426; Thu, 9 Apr 87 12:17:21 EDT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87  08:42:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 9 Apr 87 11:43:48-EDT
Date: Thu, 9 Apr 1987  11:43 EDT
Message-Id: <FAHLMAN.12293152538.BABYL@C.CS.CMU.EDU>
Sender: unido!C.CS.CMU.EDU!FAHLMAN@seismo.CSS.GOV
From: "Scott E. Fahlman" <unido!C.CS.CMU.EDU!Fahlman@seismo.CSS.GOV>
To: "Robert Scheifler" <RWS@zermatt.lcs.mit.edu>
Cc: cl-windows@sail.stanford.edu
Subject: plist revisions to CLX proposal
In-Reply-To: Msg of 9 Apr 1987  11:03-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
Status: R


I think that using a structure to pass these bundled values around is
the right thing.  If we go ahead and assume the existence of the Common
Lisp Object Standard (and I no longer see any reason to avoid this --
people will want to use it for their higher-level graphics hacking
anyway), then your macros aren't needed: WITH-SLOTS gives convenient
access by name to the various slots of the structure.

If there are still people out there who are fanatically CONS-averse,
neither the property list nor the structure solution will make them
happy, compared with a non-consing solution that uses positional
multiple values.  One possibility might be to return structures, but to
provide all these structure-returning forms with an optional argument by
which the user can pass in a structure of the appropriate type that is
to be destructively modified.  This avoids the need for consing up lots
of new structures, and also the need for copyingof values by the user
when the returned information is to be used outside the current dynamaic
extent.

-- Scott


∂10-Apr-87  1055	DALY@IBM.COM 	passing structures to be destructively modified    
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 10 Apr 87  10:55:07 PDT
Date: 10 April 1987, 11:39:32 EDT
From: Timothy Daly <DALY@ibm.com>
To:   cl-windows@sail.stanford.edu
Message-Id: <041087.113933.daly@ibm.com>
Subject: passing structures to be destructively modified

I'd like to add a vote for scott's idea of being able to pass a structure
that would be destructively modified. Besides avoiding consing (not a
concern) it maintains eq-ness (a major concern) without having to
copy.

∂10-Apr-87  1821	ibuki!weaver@labrea.stanford.edu 	Berkeley CL X windows 10 available for KCL    
Received: from LABREA by SAIL.STANFORD.EDU with TCP; 10 Apr 87  18:21:14 PDT
Received: by labrea.stanford.edu; Fri, 10 Apr 87 18:20:42 PST
Received: by ibuki.UUCP (1.4/4.7)
	id AA6160551; Fri, 10 Apr 87 17:34:02 pst
Date: Fri, 10 Apr 87 17:34:02 pst
From: ibuki!weaver@labrea.stanford.edu (Eric Weaver)
Message-Id: <8704110134.AA6160551@ibuki.UUCP>
To: labrea!cl-windows@sail.stanford.edu
Subject: Berkeley CL X windows 10 available for KCL


We have a KCL version of David Martin's "XCL", available for whomever
has the courage to try it out.  It is untested so far, except that it 
loads into a KCL without error (our machine has no X just now).

Interested persons may contact us to arrange for copies at (415) 949-1126.
Ask for Eric Weaver.

∂11-Apr-87  0826	RAM@C.CS.CMU.EDU 	plist revisions to CLX proposal 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Apr 87  08:26:47 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sat 11 Apr 87 11:26:14-EDT
Date: Sat, 11 Apr 1987  11:26 EDT
Message-ID: <RAM.12293673628.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: plist revisions to CLX proposal
In-reply-to: Msg of 9 Apr 1987  11:03-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>

    Date: Thursday, 9 April 1987  11:03-EDT
    From: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
    To:   RAM
    Re:   plist revisions to CLX proposal

    I'm assuming that the macro forms will get used most of the time;
    do you dislike them as well, or just the plist in the function?

I had a negative reaction to the macros because they seemed to be
adding a lot of conceptual complexity to an interface that seems
like it ought to be pretty simple.  I am suspicious of features that
are harder to document than implement.

As a more general comment, I think that this proposal introduces a
fair amount of complexity to make things "lispy" and easy to use.
This seems to be incompatible with the claim that this interface will
be used primarily to implement a "toolkit".  If this is really true,
then the emphasis should be on simplicity, efficiency and functional
completeness rather than on ease of use.

Do we really need to allow general sequences for all these arguments?
Do we really need all these keyword based interfaces?

I have some ideas for an object-oriented X interface, but I see very
little in CLX that would make me want to base my interface on CLX
rather than directly on our callout mechanism.  In fact, programs that
directly used CLX would tend to clash with the o-o interface, since
CLX programs assume that they can usurp the entire event stream
instead of following some kind of discipline for demultiplexing.

  Rob

∂12-Apr-87  1011	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	latest X11 protocol document
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87  10:11:03 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 12 Apr 87 13:06-EDT
Date: Sun, 12 Apr 87 13:10 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: latest X11 protocol document
To: xpert@ATHENA.MIT.EDU, cl-windows@SAIL.STANFORD.EDU
Message-ID: <870412131031.1.RWS@KILLINGTON.LCS.MIT.EDU>

The latest version (Alpha Update) of the X protocol document
is now available via anonymous ftp to zap.mit.edu (18.72.0.126)
as the file /pub/x11.spec.  A Unix script to paginate the
document and produce a table of contents and an index is in
the file /pub/x11.spec.script.  A list of the revisions from the
Alpha Test version is in the file /pub/x11.spec.update-revs.

If you do not have ftp access, and would like an email copy of
either the revisions or the complete protocol, send me mail,
and I will respond as time permits.

∂12-Apr-87  1308	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	plist revisions to CLX proposal  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87  13:08:00 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 12 Apr 87 16:04-EDT
Date: Sun, 12 Apr 87 16:08 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: plist revisions to CLX proposal
To: RAM@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12293673628.BABYL@C.CS.CMU.EDU>
Message-ID: <870412160833.3.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Sat, 11 Apr 1987  11:26 EDT
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

    I had a negative reaction to the macros because they seemed to be
    adding a lot of conceptual complexity to an interface that seems
    like it ought to be pretty simple.  I am suspicious of features that
    are harder to document than implement.

I am now in agreement, and am working on a revision along the lines
suggested in previous mail, namely a structure as the return value, with
an optionally passed in structure to avoid consing, several functions
returning a subset of the values as multiple positional values, and the
elimination of the macros.

    As a more general comment, I think that this proposal introduces a
    fair amount of complexity to make things "lispy" and easy to use.
    This seems to be incompatible with the claim that this interface will
    be used primarily to implement a "toolkit".  If this is really true,
    then the emphasis should be on simplicity, efficiency and functional
    completeness rather than on ease of use.

A toolkit is not a small piece of code, nor do I really believe we will
see standardization on just one toolkit in the near future.  I think
ease of use is fairly important, particularly when it can be had without
significant loss of efficiency.  The intent is that ease of use will
translate into simplicity at the next layer up, where (I believe) simplicity
and understandability are very important.

    Do we really need to allow general sequences for all these arguments?

I don't know; what would you specify instead?  The intent was to not preclude
particular implementations at the next level up, and there is the ubiquitous
issue of consing expense when there is a mismatch.  I don't believe allowing
general sequences has to imply loss of efficiency when the argument is of
the desired (e.g., vector) type.  Do you not believe this?  I also don't
believe it adds substantial complexity to the implementation at this layer;
as I have said before, a substantial portion of the implementation is very
repetitive encoding/decoding, and can be handled well with appropriate
macro generation.

    Do we really need all these keyword based interfaces?

Are you arguing from simplicity or efficiency grounds?  Which interfaces do
you dislike, in particular?  In general, keyword arguments are used when
there are zillions of (optional) arguments, and also I have tended to prefer
a single &key to a single &optional argument in cases where it seemed like
the addition of the keyword in the call would help readability.  If there
is general agreement that these should be &optional instead, that could be
arranged.  But it would help to have specific counter-proposals, or at
least more detailed arguments, rather than just general distaste reactions.

    I have some ideas for an object-oriented X interface, but I see very
    little in CLX that would make me want to base my interface on CLX
    rather than directly on our callout mechanism.  In fact, programs that
    directly used CLX would tend to clash with the o-o interface, since
    CLX programs assume that they can usurp the entire event stream
    instead of following some kind of discipline for demultiplexing.

This confuses me.  If the CLX layer imposes some kind of discipline, then
it preempts decisions at the next layer up, which is exactly what we want
to avoid.  I'm not attempting to propose an interface that will allow
programs using both "direct" and an "o-o" interfaces on the same connection
to coexist; I don't see any way of making that work.  The fact is that
the connection provides a single event stream, and there has to be, at
some level, something that pulls the events off the queue and does something
with them.  I'm trying to provide (just) that functionality.  An o-o interface
built on top would presumably either have a separate process dedicated to
this task, or else would impose a program structure similar to that proposed
in the C XToolkit.  Perhaps you could elaborate on what it is that is different
about your "callout mechanism"?

∂12-Apr-87  1313	Gumby%AI.AI.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	passing structures to be destructively modified
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87  13:13:24 PDT
Received: from BUDDY.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 12 Apr 87 16:09-EDT
Date: Sun, 12 Apr 87 16:13 EDT
From: David Vinayak Wallace <Gumby@AI.AI.MIT.EDU>
Subject: passing structures to be destructively modified
To: Timothy Daly <DALY@IBM.COM>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <041087.113933.daly@ibm.com>
Message-ID: <870412161326.7.GUMBY@BUDDY.AI.MIT.EDU>

    Date: 10 April 1987, 11:39:32 EDT
    From: Timothy Daly <DALY@ibm.com>

    I'd like to add a vote for scott's idea of being able to pass a structure
    that would be destructively modified. Besides avoiding consing (not a
    concern) it maintains eq-ness (a major concern) without having to
    copy.

Excuse my ignorance but I don't understand what this means.  By copying
a structure or plist you'd remove any uniqueness.  And stashing a
structure which is later modified could lead to later confusion, as the
modified structure will be eq to the saved one even though values might
not be what they were when you stashed it away.

Am I missing something obvious?

∂13-Apr-87  0852	rochester!tropix!dls@seismo.CSS.GOV 	Re:  passing structures to be destructively modified 
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 13 Apr 87  08:52:31 PDT
Received: from rochester.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP 
	id AA05079; Mon, 13 Apr 87 11:52:32 EDT
Received: by ur-seneca.arpa id AA11003 (4.12z); Mon, 13 Apr 87 10:48:39 est
Received: by tropix.UUCP (4.12/4.7)
	id AA13701; Mon, 13 Apr 87 11:19:25 est
Date: Mon, 13 Apr 87 11:19:25 est
From: rochester!tropix!dls@seismo.CSS.GOV (David L. Snyder )
Message-Id: <8704131619.AA13701@tropix.UUCP>
To: cl-windows@sail.stanford.edu
Subject: Re:  passing structures to be destructively modified
Cc: DALY@ibm.com

    Date: 10 April 1987, 11:39:32 EDT
    From: Timothy Daly <rochester!seismo!ibm.com!DALY>
    To: cl-windows@sail.stanford.edu
    Message-Id: <041087.113933.daly@ibm.com>
    Subject: passing structures to be destructively modified
    
    I'd like to add a vote for scott's idea of being able to pass a structure
    that would be destructively modified. Besides avoiding consing (not a
    concern) it maintains eq-ness (a major concern) without having to
    copy.
    
I also vote for structures, both for the sake of eq testing, and
local smashing.  Presumably there is to be some structure field with
extensible slots, to accomodate special needs, local particulars, &tc?

∂13-Apr-87  1305	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	Re:  passing structures to be destructively modified 
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Apr 87  13:05:00 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 13 Apr 87 15:52-EDT
Date: Mon, 13 Apr 87 15:56 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re:  passing structures to be destructively modified
To: rochester!tropix!dls@seismo.CSS.GOV, cl-windows@sail.stanford.edu
cc: DALY@ibm.com
In-Reply-To: <8704131619.AA13701@tropix.UUCP>
Message-ID: <870413155602.6.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Mon, 13 Apr 87 11:19:25 est
    From: rochester!tropix!dls@seismo.CSS.GOV (David L. Snyder )

	Date: 10 April 1987, 11:39:32 EDT
	From: Timothy Daly <rochester!seismo!ibm.com!DALY>
    
	I'd like to add a vote for scott's idea of being able to pass a structure
	that would be destructively modified. Besides avoiding consing (not a
	concern) it maintains eq-ness (a major concern) without having to
	copy.
    
    I also vote for structures, both for the sake of eq testing, and
    local smashing.  Presumably there is to be some structure field with
    extensible slots, to accomodate special needs, local particulars, &tc?

Since you both seem to understand each other, and I don't think I understand
either of you, perhaps one of you could restate at longer length?
Scott's basic idea was to have (e.g.) window-attributes fill in a structure
either newly consed up or optionally passed in.  That structure was NOT the
same structure as the window object itself, so I'm not sure what eq-ness
you are concerned with.  As for "special needs" and "local particulars",
the intent was to avoid imposing a requirement of either defstruct or
defclass implementation on the objects, but just define a functional
interface compatible with either implementation.  True stream and object
oriented interfaces would be provided at higher levels, as indicated
in Mike McMahon's message on layers.  If you do not think this is
appropriate, perhaps you could elucidate?

∂13-Apr-87  1354	Oren%Tilde%ti-csl.csnet@RELAY.CS.NET 	CLX With-Display speed hack
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 13 Apr 87  13:54:11 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac03849; 13 Apr 87 16:36 EDT
Received: from ti-csl by RELAY.CS.NET id aa25604; 13 Apr 87 16:32 AST
Received: from SI (si.ARPA) by tilde id AA03425; Mon, 13 Apr 87 14:15:17 cdt
Message-Id: <2754332029-1063447@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Mon, 13 Apr 87  15:13:49 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: CLX With-Display speed hack

I think that two kinds of locking would be better in CLX.  One lock for
request generation, and another lock for requests that expect a reply.
For example:

(defun draw-string (...)
  (WITH-DISPLAY-REQUEST (display)
    (send-draw-string-request ...)))

(defun get-property (...)
  (WITH-DISPLAY-REPLY (display)
    (WITH-DISPLAY-REQUEST (display)
      (send-get-property-request ...))
    ;; While waiting for the reply, other processes may
    ;; send requests that don't expect replies.
    (wait-for-reply display)
    (process-reply ...)))

Another advantage of having two kinds of locks is that since very little
happens inside the body of a WITH-DISPLAY-REQUEST, LISPM's can can expand
it into a WITHOUT-INTERRUPTS, which is faster than holding a lock within
an unwind-protect. 

I propose WITH-DISPLAY have an optional parameter specifying the type
of the lock.  Some implementations may ignore the optional parameter.

(defmacro with-display ((display &optional (FOR :reply)) &body body)
  ; This macro is for use in a multi-process environment.  It provides
  ; exclusive access to the local display object for request generation
  ; and reply processing.
  ;
  ; FOR may be :REPLY or :REQUEST :SHORT-REQUEST.  :REPLY is for locking
  ; around requests that may or may not receive replies.  :SHORT-REQUEST
  ; is a speed hack for locking around requests that don't receive
  ; replies.  :REQUEST is for locking around requests such as
  ; PUT-RAW-IMAGE that don't expect a reply, where its undesirable to
  ; lock out other processes.
  ;
  ; Except where noted, all of the routines below should be thought of as
  ; containing an implicit with-display, so that correct synchronization
  ; is always provided at the interface level on a per-call basis.
  ; Nested uses of this macro will work correctly.  This macro does not
  ; prevent concurrent event processing; see with-event-queue.
  )

  -- LaMott

∂13-Apr-87  1427	carter%silicon@cs.utah.edu 	de-subscription  
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 13 Apr 87  14:26:59 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
	id AA09733; Mon, 13 Apr 87 15:28:30 MDT
Received: by silicon.UTAH.EDU (4.30/4.40.2)
	id AA04229; Mon, 13 Apr 87 15:28:15 mdt
Date: Mon, 13 Apr 87 15:28:15 mdt
From: carter%silicon@cs.utah.edu (Tony M. Carter)
Message-Id: <8704132128.AA04229@silicon.UTAH.EDU>
To: cl-windows@sail.stanford.edu
Subject: de-subscription

Please remove me from the mailing list

carter@silicon.utah.edu OR carter@cs.utah.edu

∂13-Apr-87  2109	janson@ATHENA.MIT.EDU 	common lisp X interface    
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Apr 87  21:09:33 PDT
Received: by ATHENA (5.45/4.7)
	id AA04752; Mon, 13 Apr 87 23:08:21 EST
From: <janson@ATHENA.MIT.EDU>
Received: by POSEIDON.MIT.EDU (5.45/4.7) id AA09998; Mon, 13 Apr 87 23:07:34 EST
Message-Id: <8704140407.AA09998@POSEIDON.MIT.EDU>
To: cl-windows@sail.stanford.edu, xpert
Subject: common lisp X interface
Date: Mon, 13 Apr 87 23:07:32 EST

the recent notice re a "standard Common Lisp interface to
X Version 11" described it as an alternative (in addition to) the
Xlib interface, in that it will provide the equivalent support
but will keep as much of the implementation as possible within Lisp.

This would appear to require that CL implementations in  unix environments
be provided with a very low level (C based?) protocol interface upon
which to build.
Does anyone know what vendors like DEC, HP, and Sun are planning?

I'm actually interested to use such a foreign-function  interface from
CScheme, but the CL version would be a good base.

james anderson.
department of architecture 9-526
MIT Cambridge MA 02139
617-253-0782

∂14-Apr-87  0826	FAHLMAN@C.CS.CMU.EDU 	common lisp X interface
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87  08:26:37 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 14 Apr 87 11:24:45-EDT
Date: Tue, 14 Apr 1987  11:24 EDT
Message-ID: <FAHLMAN.12294459782.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   <janson@ATHENA.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU, xpert@ATHENA.MIT.EDU
Subject: common lisp X interface
In-reply-to: Msg of 14 Apr 1987  00:07-EDT from <janson at ATHENA.MIT.EDU>


    This would appear to require that CL implementations in  unix environments
    be provided with a very low level (C based?) protocol interface upon
    which to build.
    Does anyone know what vendors like DEC, HP, and Sun are planning?

The Common Lisp language spec (current or proposed) does not require any
sort of call-out mechansism, but all of the vendors you name have some
sort of call-out from Common Lisp to C.  I'm not sure whether all of
them are general enough to support everything in the Xlib interface in a
convenient way, however.

-- Scott

∂14-Apr-87  0906	RAM@C.CS.CMU.EDU 	XCL comments
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87  09:06:26 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 14 Apr 87 12:00:56-EDT
Date: Tue, 14 Apr 1987  12:00 EDT
Message-ID: <RAM.12294466371.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: XCL comments
In-reply-to: Msg of 12 Apr 1987  16:08-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>


A lot of my initial objection to the XCL proposal was due to by impression that
it wouldn't mesh very will with the kind of object oriented substrate that I am
interested in.  I have since realized that this is not the case.  It would be
quite reasonable for XCL windows to be CLOS objects.  I think that this
possible connection should be emphasized more, and in particular, I think that
there should be a standard way to get X events to cause messages to be sent to
the window object.

My main reservation about the current proposal is with the event handling.  The
biggest problem is with the use of keyword arguments to represent event
components.  In addition to being distasteful, this will result in hundreds of
bytes of garbage being consed for every key you type.  I suggest that events be
represented by structures, with each distinct kind of event having a distinct
structure type.  

Applications that are worried about consing can use the FREE-EVENT function
to explicitly reclaim event structures.  With NEXT-EVENT, we can't supply a
structure to be destructively modified since we don't know what type the next
event is going to be.

Using a structure to represent events also cleans up the interface to the
SEND-EVENT functions, since we don't have to pass in the components using
&ALLOW-OTHER-KEYS.

The (non-keyword) name of the event structure type should be used as a
symbolic representation of the event kind, replacing the event-keys
keywords.  It would be confusing and redundant to have keyword names
in addition to the structure type names.


Other more minor suggestions:
 -- There *must* be start and end arguments to DRAW-STRING (and presumably
    DRAW-STRING-IMAGE).  I would prefer optional args rather than keywords (as
    in SUBSEQ).  I don't really care about being able to do this in DRAW-TEXT,
    since I don't intend to use it.
 -- There should be a timeout argument to NEXT-EVENT.  This is a very useful
    thing to have, and is impossible to simulate if it doesn't exist.  If a
    non-null timeout is specified, then NEXT-EVENT will return :TIMEOUT if the
    timeout is exceeded.


I also think it is worth specifying a simple event interface using CLOS.  Each
event type will also be a specializable CLOS operation.  Methods for these
operations have one argument: the EVENT structure.  There are two functions
that provide an interface to this mechanism:

    (defun send-event-messages (window)
      (declare (type window window))
      ...)

SEND-EVENT-MESSAGES specifies that when an event on WINDOW is received, the
corresponding message will be sent to the window object.

There also needs to be some way to create a specific type of window object,
doing any necessary bookkeeping to maintain the resource-id => object
translation.  I don't know enough about CLOS to know whether this can be done
by the default constructor.


    (defun wait-for-event (&key timeout windows displays if-unknown-window)
      (declare (type (or number null) timeout))
      (declare (type list windows))
      (declare (type (member :discard :send :leave-in-queue) if-unknown-window))
      ...)

WAIT-FOR-EVENT waits for some event to arrive and then sends a message to the
appropriate window, returing the event when it is done.  If a non-null timeout
is specified, then it will return :TIMEOUT if no relavent event arrives in the
specified interval.  If a non-null windows list is specifed, then it will only
return when an event happens to one of the specified windows, although it will
still dispatch events that arrive for other windows.  

If Displays is specified, then it will only read events on the specified
displays, otherwise it reads events on all open displays.  If an event arrives
for a window that hasn't had SEND-EVENT-MESSAGES done on it, then the value of
If-Unknown-Window is used to tell what to do:
  :Discard
      The event is discarded.

  :Send
      Send the event anyway (the default).  This will presumably result in some
      kind of unknown message error.

  :Leave-In-Queue
      The event is left in the local queue, and can still be read using
      NEXT-EVENT.


I also have some questions about possible strangenesses in the interface:
 -- Why does ROTATE-PROPERTIES use the opposite meaning for Delta from the one
    in the protocol?
 -- Why allow an atom to be a string?  This makes it harder to use an EQ
    hash to maintain the atom translations, although the interface could just 
    intern the string in the keyword package and then EQ hash.  Is this to make
    mixed-case atoms (such as font properties (sigh...)) less bletcherous?
 -- Why are these names changed from the protocol spec?
      ChangeProperty => STORE-PROPERTY
      ListFonts => MATCHING-FONTS
      ListFontsWithInfo => MATCHING-FONTS-AND-PROPERTIES

∂14-Apr-87  1131	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	CLX With-Display speed hack 
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87  11:31:37 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 14 Apr 87 14:18-EDT
Date: Tue, 14 Apr 87 14:22 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX With-Display speed hack
To: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2754332029-1063447@SI>
Message-ID: <870414142255.8.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Mon, 13 Apr 87  15:13:49 CDT
    From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>

    I think that two kinds of locking would be better in CLX.  One lock for
    request generation, and another lock for requests that expect a reply.
    For example:

    (defun draw-string (...)
      (WITH-DISPLAY-REQUEST (display)
	(send-draw-string-request ...)))

    (defun get-property (...)
      (WITH-DISPLAY-REPLY (display)
	(WITH-DISPLAY-REQUEST (display)
	  (send-get-property-request ...))
	;; While waiting for the reply, other processes may
	;; send requests that don't expect replies.
	(wait-for-reply display)
	(process-reply ...)))

    Another advantage of having two kinds of locks is that since very little
    happens inside the body of a WITH-DISPLAY-REQUEST, LISPM's can can expand
    it into a WITHOUT-INTERRUPTS, which is faster than holding a lock within
    an unwind-protect. 

    I propose WITH-DISPLAY have an optional parameter specifying the type
    of the lock.  Some implementations may ignore the optional parameter.

There are both implementation and semantic issues coupled here.  The
semantic issues are 1) whether generation of the next request (by
another process) can overlap with receipt of a reply to the last
request, and 2) whether the programmer needs to be explicit in
with-display about what goes on in the body.  I don't see anything
particularly wrong with 1), although I don't think it gains you that
much in terms of concurrency in the normal case, since by far the most
common case is issuing requests for which there is no reply.  However, I
think making things visible in with-display is a bad idea.

Request generation isn't quite as simple as you seem to think.  I'm
assuming the implementation will be along the lines of having an output
buffer and a (TCP) stream.  Requests get encoded into the buffer until
the buffer fills, and then it is written to the stream.  There is always
the possibility that the output buffer will be(come) full when
generating a request, so there is always the possibility that you will
have to write data to the stream.  This write may well block (it
certainly can for a TCP stream), so it can't be done inside a
without-interrupts.  Even if the stream implementation itself provides
internal locking (and it isn't clear to me that TCP streams do in either
the TI or Symbolics systems), there will be "big" X requests (like
put-raw-image) that require more than one write to the stream.  This
means there HAS to be a "long" way of request-locking the display that
allows a process block, and so cannot be implemented using
without-interrupts.  So even if you try to use without-interrupts for
the "normal" case, you will have to both check for buffer-too-full and
for a conflicting "long" form of request-locking, and be able to wait
for such a long-form lock to be released.

The intent of with-display is to surround multiple calls, so one can
amortize the locking cost.  I see no reason why one should desire to
special-case a without-interrupts form of locking in with-display; it
ought to always use the "long" form of request-locking.  Forcing the
caller declare whether the body will use replies or not is just asking
for bugs, and is asking for the kind of knowledge the interface is
trying to hide.  Allowing the caller to semi-implicitly use
without-interrupts is even more prone to bugs.

Rather than having with-display specify the locking mode, it seems much
better to say that with-display always locks for requests, and
individual requests just additionally lock for replies as needed.
Trying to amortize the cost of reply-locking doesn't seem important; the
whole protocol is essentially geared at minimizing the use of replies
anyway.  (I suppose one could allow the specification in with-display as
an optimization, but it should be only that, it shouldn't cause bugs to
fail to specify it.)

Within the CLX internals, locking separately for request and reply is
reasonable, but if you are going to do it, it should be done "right",
meaning allowing overlap of next request and last reply, meaning locking
regions must overlap rather than nest.  Redoing your get-property
example (and ignoring unwind issues):

	(request-lock display)
	(encode-get-property-request ...)
	(force-output display)
	(reply-lock display)
	(request-unlock display)
	(wait-for-reply display)
	(process-reply ...)
	(reply-unlock display)

Does all this make sense?

While I'm close to the subject, I personally try to avoid designing
around without-interrupts whenever possible; it only gets you into
trouble.  It doesn't generalize to multi-processor architectures, and it
inevitably leads to problems down the line with either a process-block
inside a without-interrupts, or with very long critical sections where
you didn't expect them.  I think the current TI and Symbolics window
systems are a good example.  TV:SHEET locking is done using
without-interrupts, a fact you will find by browsing the documentation
(source), but not be reading the manual.  In ancient days I suppose
window operations were pretty quick, but that isn't the case any more
with many graphics operations.  Furthermore, when I came around and
tried to slip an X stream in under the covers in place of the
memory-mapped frame buffer, lo and behold a write-to-stream call might
end of blocking inside the without-interrupts.  If your normal-case
process-locking mechanisms are so expensive that you have to resort to
without-interrupts, you should rethink your architecture.

∂14-Apr-87  1351	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	XCL [sic] comments
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87  13:51:13 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 14 Apr 87 16:47-EDT
Date: Tue, 14 Apr 87 16:50 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: XCL [sic] comments
To: RAM@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12294466371.BABYL@C.CS.CMU.EDU>
Message-ID: <870414165059.1.RWS@KILLINGTON.LCS.MIT.EDU>

[I've been calling it "CLX"; David Martin calls his V10 interface "XCL".]

    Date: Tue, 14 Apr 1987  12:00 EDT
    Message-ID: <RAM.12294466371.BABYL@C.CS.CMU.EDU>

							  I think that this possible
    [CLOS] connection should be emphasized more,

You mean just in documentation (send me prose), or in interface change?

						 and in particular, I think that
    there should be a standard way to get X events to cause messages to be sent to
    the window object.

I will agree, but since I'm far from certain that such dispatching
should be the ONLY mechanism, or that we can quickly agree on all
aspects of such object-based dispatching, the intent was to push such
issues up to the next layer.  This is exactly what has been done in the
C Xlib vs. Toolkit.  Are you disagreeing with this (and if so, can you
make a concrete proposal for others to shoot at)?

									    The
    biggest problem is with the use of keyword arguments to represent event
    components.  In addition to being distasteful, this will result in hundreds of
    bytes of garbage being consed for every key you type.

Huh?  Where does the consing come from?  The whole reason we designed
the interface that way was to AVOID consing!  Please explain.

							   I suggest that events be
    represented by structures, with each distinct kind of event having a distinct
    structure type.  

Within the current proposal, one can define simply define a dispatch
array, where each function is a structure-conser, and get exactly what
you desire.  We are simply providing more flexibility than you in
particular care for, yes?  If you want us to make your case even easier,
we could certainly change the dispatch function to take in the display
and event-key by keyword argument as well, and then the functions could
directly be the appropriate make-<structure>s.

    Applications that are worried about consing can use the FREE-EVENT function
    to explicitly reclaim event structures.

This was one reason we decided on the more flexible interface;
free-event is just asking for bugs.

    Using a structure to represent events also cleans up the interface to the
    SEND-EVENT functions, since we don't have to pass in the components using
    &ALLOW-OTHER-KEYS.

Perhaps this is just personal taste; having to cons up a structure only to
have it torn down again doesn't seem particularly cleaner to me.

    Other more minor suggestions:
     -- There *must* be start and end arguments to DRAW-STRING (and presumably
	DRAW-STRING-IMAGE).

Absolutely.  This was an oversight.  Should also be in draw-string16 and
draw-string-image16.

			     I would prefer optional args rather than keywords (as
	in SUBSEQ).

I prefer keywords, in keeping with all the CL string (as opposed to sequence)
operations, as well as write-string.

		    I don't really care about being able to do this in DRAW-TEXT,
	since I don't intend to use it.

I agree start/end should not be provided for this function.

     -- There should be a timeout argument to NEXT-EVENT.  This is a very useful
	thing to have, and is impossible to simulate if it doesn't exist.  If a
	non-null timeout is specified, then NEXT-EVENT will return :TIMEOUT if the
	timeout is exceeded.

I kind of agree with you, but why is it that CL doesn't?  Why doesn't CL's listen
take a timeout, or why isn't there a general wait-with-timeout for streams, or
any sort of timeout mechanism at all besides sleep?  I am hesitant to require
something that may not be possible to implement uniformly.

    I also think it is worth specifying a simple event interface using CLOS.  Each
    event type will also be a specializable CLOS operation.  Methods for these
    operations have one argument: the EVENT structure.  There are two functions
    that provide an interface to this mechanism:

	(defun send-event-messages (window)
	  (declare (type window window))
	  ...)

    SEND-EVENT-MESSAGES specifies that when an event on WINDOW is received, the
    corresponding message will be sent to the window object.

What does this really mean?  Are you proposing this on top of the existing
interface, or within it, or instead of?  Does it imply an automatic filtering
on events as seen by processes doing next-events, or does it imply that there is
effectively a daemon process that is continually doing a next-event, and next-event
is no longer part of the interface?

    There also needs to be some way to create a specific type of window object,
    doing any necessary bookkeeping to maintain the resource-id => object
    translation.  I don't know enough about CLOS to know whether this can be done
    by the default constructor.

It is unclear to me whether a CLOS (or stream-based) window object
should include a CLX window as super-class, or as just another value in
an instance variable, but I suspect the latter is more appropriate.  To
a degree it depends on whether you want to hide or expose graphics
contexts in the interface.  Some of these issues may become clearer when
a higher-level graphics interface gets proposed.

	(defun wait-for-event (&key timeout windows displays if-unknown-window)
	  (declare (type (or number null) timeout))
	  (declare (type list windows))
	  (declare (type (member :discard :send :leave-in-queue) if-unknown-window))
	  ...)

Again, I suspect this is just one example of what one might desire at
the next level up (and you will find those that will argue about
you-call-us versus we'll-call-you).  I certainly don't want to require
CLX to be implemented using CLOS.

     -- Why does ROTATE-PROPERTIES use the opposite meaning for Delta from the one
	in the protocol?

To keep the "natural" default of one consistent with the definition of CL rotatef,
and also to be consistent with CL ash.

     -- Why allow an atom to be a string?  This makes it harder to use an EQ
	hash to maintain the atom translations, although the interface could just 
	intern the string in the keyword package and then EQ hash.  Is this to make
	mixed-case atoms (such as font properties (sigh...)) less bletcherous?

All the standard properties have been changed in the protocol spec to
uppercase with underscore, to make life simpler for Lisp.  I added
strings as atoms because I got responses from some people that they
thought strings were more natural to use than keywords.  I have no
strong feelings.  The implementation could always keep two separate hash
tables (one EQ and one EQUAL) assuming a program will tend to use just
one or the other, and pay the extra roundtrips when they mix usage.

     -- Why are these names changed from the protocol spec?
	  ChangeProperty => STORE-PROPERTY
	  ListFonts => MATCHING-FONTS
	  ListFontsWithInfo => MATCHING-FONTS-AND-PROPERTIES

No particularly good reason.  Consider them changed to agree with the
protocol spec.

∂14-Apr-87  1410	burdorf@rand-unix.ARPA 	Re: plist revisions to CLX proposal 
Received: from RAND-UNIX.ARPA by SAIL.STANFORD.EDU with TCP; 14 Apr 87  14:10:32 PDT
Received: by rand-unix.arpa; Tue, 14 Apr 87 13:47:30 PST
Message-Id: <8704142147.AA08807@rand-unix.arpa>
To: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Cc: Fahlman@c.cs.cmu.edu, cl-windows@sail.stanford.edu, burdorf@rand-unix.ARPA
Subject: Re: plist revisions to CLX proposal
In-Reply-To: Your message of Thu, 9 Apr 87 17:44 EDT.
             <870409174401.3.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Tue, 14 Apr 87 13:47:23 PST
From: burdorf@rand-unix.ARPA

∂14-Apr-87  1611	RAM@C.CS.CMU.EDU 	XCL [sic] comments    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87  16:11:42 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 14 Apr 87 19:12:37-EDT
Date: Tue, 14 Apr 1987  19:12 EDT
Message-ID: <RAM.12294544961.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: XCL [sic] comments
In-reply-to: Msg of 14 Apr 1987  16:50-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>

    14-Apr-87 17:53:06-EDT,7149;000000000000
    Date: Tuesday, 14 April 1987  16:50-EDT
    From: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
    Re:   XCL [sic] comments

	Date: Tue, 14 Apr 1987  12:00 EDT
	Message-ID: <RAM.12294466371.BABYL@C.CS.CMU.EDU>

	The biggest problem is with the use of keyword arguments to
	represent event components.  In addition to being distasteful, this
	will result in hundreds of bytes of garbage being consed for every
	key you type.

    Huh?  Where does the consing come from?  The whole reason we designed
    the interface that way was to AVOID consing!  Please explain.

In our implementation (and probably many others) keyword args are implemented
using rest args, so they cons.  I believe that there are something like 11
fields in the event you get for a key being pressed event.  11 * 2 * 8 = 176
bytes consed for every call with those event keywords.  At least at first
glance it also looked like these keys might be passed to more than one call for
each event, introducing another factor of two or so.  Even if you never
explicitly reclaim event structures you will cons four times less using a
structure.  

I am willing to concede that explicitly reclaiming event structures is more
dangerous than letting the system worry about it, but explicit storage
allocation is often necessary on conventional hardware.

        Explicit Using a structure to represent events also cleans
	up the interface to the SEND-EVENT functions, since we don't have
	to pass in the components using &ALLOW-OTHER-KEYS.

    Perhaps this is just personal taste; having to cons up a structure only to
    have it torn down again doesn't seem particularly cleaner to me.

Well, I don't really know how those functions are used, but I was guessing
that they were often used to relay an event that you read from somewhere,
rather than shoving in events that you created.


	 -- There should be a timeout argument to NEXT-EVENT. [...]

    I kind of agree with you, but why is it that CL doesn't?  Why doesn't
    CL's listen take a timeout, or why isn't there a general
    wait-with-timeout for streams, or any sort of timeout mechanism at all
    besides sleep?  I am hesitant to require something that may not be
    possible to implement uniformly.

Well, I guess you could say that it is an oversight, although there might
also be problems with doing timeouts in cretinous environments which CL
wanted to be able to run in.  It seems to me that the presence of a window
system suggests a system modern enough to allow this.  I agree that this
may be ugly to implement in some cases, but it also very useful.  One of
the routine hassles in porting Hemlock is figuring out some way to
implement EDITOR-SLEEP, which is like sleep, but is defined to return when
input is available.


        I also think it is worth specifying a simple event
        interface using CLOS.  [...]

    What does this really mean?  Are you proposing this on top of the
    existing interface, or within it, or instead of?

I guess within it, since it might be awkward to implement it on top of
next-event.  I don't have any problem with providing direct access to the
event stream, but I think that you badly need some kind of automatic
demultiplexing mechanism for even simple applications.

    Does it imply an automatic filtering on events as seen by processes
    doing next-events, or does it imply that there is effectively a daemon
    process that is continually doing a next-event, and next-event is no
    longer part of the interface?

Well, although I was to some degree making up this proposal on the fly, it
is based on the mechanism used in our implementation to do arbitrary things
when input arrives.  Since we don't have lightweight processes, it is not
possible to have a background process that does the event dispatching,
although this isn't necessarily very obvious to the input handlers.  The
function equivalent to Wait-For-Input is responsible for waiting for
something to happen and then calling the appropriate handler.
I don't have enough experience with multi-thread systems to know how this
would work in such a system, but I suspect that having a background process
doing the dispatching would be the right thing.

As to whether the NEXT-EVENT streams are being filtered, it is my idea that
when a program opens a display it will usually stick to one interface or
the other, but specifying :leave-in-queue to Wait-For-Input would have the
effect of filtering out the events on objectified windows while leaving the
rest behind.

The reason that I'm pushing for this o-o interface is that I was hoping to
get a simple o-o interface without having to wait for the ultimate toolkit
to come out.  I don't have a great deal of confidence that it will be
possible to agree on anything that complex.  The only reason that
converging on an X interface standard is tractable is that X is already
well specified.  It seems that a message based dispatching mechanism like
this provides a substrate on which you can do experimental programming
using lots of different "toolkits" without committing to any one.

  Rob

∂14-Apr-87  2143	Moon@STONY-BROOK.SCRC.Symbolics.COM 	plist revisions to CLX proposal  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Apr 87  21:42:59 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 116161; Wed 15-Apr-87 00:41:47 EDT
Date: Wed, 15 Apr 87 00:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: plist revisions to CLX proposal
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, Rob MacLachlan <RAM@C.CS.CMU.EDU>,
    Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: clx@ZERMATT.LCS.MIT.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870412160833.3.RWS@KILLINGTON.LCS.MIT.EDU>,
             <870412145724.9.RWS@KILLINGTON.LCS.MIT.EDU>,
             <RAM.12293673628.BABYL@C.CS.CMU.EDU>,
             <FAHLMAN.12293243327.BABYL@C.CS.CMU.EDU>,
             <870409174401.3.RWS@KILLINGTON.LCS.MIT.EDU>,
             <FAHLMAN.12293209297.BABYL@C.CS.CMU.EDU>,
             <870409151433.4.RWS@KILLINGTON.LCS.MIT.EDU>,
             <FAHLMAN.12293152538.BABYL@C.CS.CMU.EDU>,
             <870409110331.7.RWS@KILLINGTON.LCS.MIT.EDU>,
             <RAM.12293141952.BABYL@C.CS.CMU.EDU>,
             <870409100516.1.RWS@KILLINGTON.LCS.MIT.EDU>,
             <870406090550.3.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870415004116.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

This message is only about the part of CLX that involves functions that
return lots of values.

I've thought about this more, and I think a mid-course correction
is called for.  I think the macros I suggested were a mistake.  I think
the alternate macros discussed in the referenced mail were a mistake.
I think returning a plist is a mistake.  I think returning a structure,
which seems to be what you have converged on, is a mistake.

The more natural interface, I think, would be to provide a separate
access function for each value.  If the user wants to get several
values, he can call several access functions.  SETF of the access
functions works nicely for altering values.

Let's back off and ask -why- you need to return so many values from a
single function call.  I can think of four reasons why you might want to
use a single call that returns many values in preference to multiple
calls, each of which returns one value, and a single call that sets many
values in preference to multiple calls, each which sets one value.  Are
any of these the real reason?

(1) Tastefulness.  I think the discussion of many alternative ways
of getting the multiple values, all of which are ugly and many of
which are inefficient, has discredited this.

(2) Efficiency, because function calling is too slow.  I doubt that
this is a real problem.  More specifically, in implementations where
it is a real problem, I doubt that returning many values from one
function call makes a significant dent in the problem.

(3) Efficiency, because the X protocol wants to batch up the reads
or writes into a single request.  In my opinion, this would be better
handled by caching (for reads) and buffering (for writes), rather
than letting this network-level efficiency issue distort the structure
of the programmer's interface.  Thus if the user calls several access
functions, without calling any other CLX interfaces in between, the first
access function call does an X request to get a batch of values, waits for
the reply, saves the resulting bundle of values behind the scenes, and
returns the one desired value.  The following access function calls quickly
get their values from that behind-the-scenes cache.  The next X request
transmitted purges the cache.

(4) Synchronization, because it is necessary to set a bunch of values in
a single atomic operation, or to get a bunch of values that form a consistent
set.  I don't know whether this is a real issue.  If it is, it might be
handled by a combination of two approaches: wrap a higher level locking
operation around the sequence of calls to access functions; for common
cases where a few values must be read or written as an atomic operation,
provide a special case function that accesses just those few values.

∂15-Apr-87  0701	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	keyword args and consing    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87  07:01:19 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Apr 87 09:59-EDT
Date: Wed, 15 Apr 87 10:03 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: keyword args and consing
To: RAM@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12294544961.BABYL@C.CS.CMU.EDU>
Message-ID: <870415100313.3.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Tue, 14 Apr 1987  19:12 EDT
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

    In our implementation (and probably many others) keyword args are implemented
    using rest args, so they cons.  I believe that there are something like 11
    fields in the event you get for a key being pressed event.  11 * 2 * 8 = 176
    bytes consed for every call with those event keywords.  At least at first
    glance it also looked like these keys might be passed to more than one call for
    each event, introducing another factor of two or so.  Even if you never
    explicitly reclaim event structures you will cons four times less using a
    structure.  

Some real facts!  Your concerns were far from obvious until now.
However, I would like to know how many other implementations suffer from
this "feature", before we redesign lots of things.

∂15-Apr-87  0734	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	XCL [sic] comments
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87  07:33:57 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Apr 87 10:31-EDT
Date: Wed, 15 Apr 87 10:35 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: XCL [sic] comments
To: RAM@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12294544961.BABYL@C.CS.CMU.EDU>
Message-ID: <870415103529.6.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Tue, 14 Apr 1987  19:12 EDT
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
	    Explicit Using a structure to represent events also cleans
	    up the interface to the SEND-EVENT functions, since we don't have
	    to pass in the components using &ALLOW-OTHER-KEYS.

	Perhaps this is just personal taste; having to cons up a structure only to
	have it torn down again doesn't seem particularly cleaner to me.

    Well, I don't really know how those functions are used, but I was guessing
    that they were often used to relay an event that you read from somewhere,
    rather than shoving in events that you created.

SEND-EVENT typically won't be used much at all, and I expect will almost always
be a newly created event rather that a forwarding of some existing event.  I
agree that if NEXT-EVENT were changed to use structures, that SEND-EVENT should
be changed to match.

					 I agree that [timeout in next-event]
    may be ugly to implement in some cases, but it also very useful.  One of
    the routine hassles in porting Hemlock is figuring out some way to
    implement EDITOR-SLEEP, which is like sleep, but is defined to return when
    input is available.

I would like to hear opinions from others about this matter.  Sticking a
timeout in next-event isn't a complete solution; an application might just
as easily want to wait for a more general OR of conditions than "X event
or timeout".  Your wait-for-event is just a particular example of munging
together a particular set of conditions.

	    I also think it is worth specifying a simple event
	    interface using CLOS.  [...]

	What does this really mean?  Are you proposing this on top of the
	existing interface, or within it, or instead of?

    I guess within it, since it might be awkward to implement it on top of
    next-event.  I don't have any problem with providing direct access to the
    event stream, but I think that you badly need some kind of automatic
    demultiplexing mechanism for even simple applications.

I agree that more automatic mechanisms are needed, but I disagree that they
should be defined at this level (partly because I think agreement will
be difficult to obtain).  Someone could/should certainly propose a CLOS
object-oriented layer to put on top of CLX, and include in it an automatic
event distribution mechanism that replaces the CLX event functions (in the
sense that the CLX ones should not be called directly).  Again, opinions
from others would be useful.

∂15-Apr-87  0809	larus@paris.Berkeley.EDU 	Re: keyword args and consing 
Received: from [128.32.150.46] by SAIL.STANFORD.EDU with TCP; 15 Apr 87  08:09:50 PDT
Received: by paris.Berkeley.EDU (3.2/1.22)
	id AA03670; Wed, 15 Apr 87 08:10:22 PDT
From: larus@paris.Berkeley.EDU (James Larus)
Message-Id: <8704151510.AA03670@paris.Berkeley.EDU>
To: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Cc: RAM@c.cs.cmu.edu, cl-windows@sail.stanford.edu
Subject: Re: keyword args and consing 
In-Reply-To: Your message of Wed, 15 Apr 87 10:03:00 EDT.
             <870415100313.3.RWS@KILLINGTON.LCS.MIT.EDU> 
Date: Wed, 15 Apr 87 08:10:18 PDT

This "feature" of Spice Lisp is taking Lisp Machine envy too far.  

On systems without cdr-coding, there is no good reason to build &rest
args to parse keywords.  We changed SPUR Lisp (a Spice Lisp port) to
scan the arguments with a lexpr-like convention and got a noticable
improvement in speed and reduced garbage.  I believe that Excl does
not cons &key arguments either, but you should check with jkf.

/Jim

∂15-Apr-87  0831	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	plist revisions to CLX proposal  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87  08:31:33 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Apr 87 11:29-EDT
Date: Wed, 15 Apr 87 11:33 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: plist revisions to CLX proposal
To: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870415004116.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870415113324.0.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Wed, 15 Apr 87 00:41 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    (1) Tastefulness.  I think the discussion of many alternative ways
    of getting the multiple values, all of which are ugly and many of
    which are inefficient, has discredited this.

I have a revised proposal, seen by Moon and a few others, which
provides both structure and subset multiple-value returns, and
no macro interfaces, which I now rather like.  I will forward it
to the whole list in a separate message.

    (2) Efficiency, because function calling is too slow.

No, this isn't a concern to me.

    (3) Efficiency, because the X protocol wants to batch up the reads
    or writes into a single request.  In my opinion, this would be better
    handled by caching (for reads) and buffering (for writes), rather
    than letting this network-level efficiency issue distort the structure
    of the programmer's interface.

There is a trade-off between implementation complexity/cost and
interface complexity/cost; it isn't clear the functions in question will
be used often enough to justify a complex implementation or an optimal
interface.  Individual accessors make sense for window-attributes,
drawable-geometry, and keyboard-control; they make less sense for
text-extents, and very little sense for query-pointer.  Also, as I tried
to indicate with the subset multiple-value functions I sent out, the
caller is very likely to want more than one value at a time, which makes
individual accessors less convenient to use, and certainly a pain if you
really want everything.

    (4) Synchronization, because it is necessary to set a bunch of values in
    a single atomic operation, or to get a bunch of values that form a consistent
    set.  I don't know whether this is a real issue.  If it is, it might be
    handled by a combination of two approaches: wrap a higher level locking
    operation around the sequence of calls to access functions; for common
    cases where a few values must be read or written as an atomic operation,
    provide a special case function that accesses just those few values.

This is the real issue.  Requiring higher-level locking means using
with-server-grabbed, not with-display, because there will generally be
non-local clients as well.  Moreover, no amount of synchronization will
help for query-pointer, since you can't lock the user.  I find
higher-level locking even uglier solution, since it make it easier to
forget (leading to bugs), and requires an overkill of synchronization to
get back a semantics that was thrown away.

∂15-Apr-87  0834	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	another try at CLX "lots of result values" 
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87  08:34:21 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Apr 87 11:32-EDT
Date: Wed, 15 Apr 87 11:36 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: another try at CLX "lots of result values"
To: cl-windows@sail.stanford.edu
Message-ID: <870415113622.1.RWS@KILLINGTON.LCS.MIT.EDU>

I've followed the suggestion of defining structures for the
values, allowing an optional structure to be passed in to
avoid consing, defining various subset returning functions,
and eliminating the macro forms entirely.

Is the use of both &optional and &key in text-extents acceptable?
Should just that one be changed to &key, or would it be better to
pass the structure by keyword in all cases instead?


(defstruct window-attributes
  (visual <unspec> :type integer)
  (class <unspec> :type (member :input-output :input-only))
  (bit-gravity <unspec> :type bit-gravity)
  (win-gravity <unspec> :type win-gravity)
  (backing-store <unspec> :type (member :not-useful :when-mapped :always))
  (backing-bit-planes <unspec> :type integer)
  (backing-pixel <unspec> :type integer)
  (save-under <unspec> :type (member :on :off))
  (colormap <unspec> :type (or null colormap))
  (colormap-installed-p <unspec> :type boolean)
  (map-state <unspec> :type (member :unmapped :unviewable :viewable))
  (all-event-masks <unspec> :type integer)
  (event-mask <unspec> :type integer)
  (do-not-propagate-mask <unspec> :type integer)
  (override-redirect <unspec> :type (member :on :off)))

(defun window-attributes (window &optional attributes)
  (declare (type window window)
	   (type (or null window-attributes) attributes)
	   (values window-attributes)))

(defun window-kind (window)
  ;; Needs a better name?
  (declare (type window window)
	   (values visual class)))

(defun window-gravity (window)
  (declare (type window window)
	   (values bit-gravity win-gravity)))

(defun window-backing-store (window)
  (declare (type window window)
	   (values backing-store save-under backing-bit-planes backing-pixel)))

(defun window-colormap (window)
  (declare (type window window)
	   (values colormap colormap-installed-p)))

(defun window-map-state (window)
  (declare (type window window)
	   (values map-state)))

(defun window-event-masks (window)
  (declare (type window window)
	   (values event-mask all-event-masks do-not-propagate-mask override-redirect)))

(defstruct drawable-geometry
  (root <unspec> :type window)
  (depth <unspec> :type integer)
  (x <unspec> :type integer)
  (y <unspec> :type integer)
  ;; Width and height are the inside size, excluding border.
  (width <unspec> :type integer)
  (height <unspec> :type integer)
  (border-width <unspec> :type integer))

(defun drawable-geometry (drawable &optional geometry)
  (declare (type drawable drawable)
	   (type (or null drawable-geometry) geometry)
	   (values drawable-geometry)))

(defun drawable-size (drawable)
  ;; Width and height are the inside size, excluding border.
  (declare (type drawable drawable)
	   (values width height border-width)))

(defun drawable-rectangle (drawable)
  ;; Width and height are the outside size, including border.
  (declare (type drawable drawable)
	   (values x y width height border-width)))

(defun drawable-depth (drawable)
  (declare (type drawable drawable)
	   (values integer)))

(defun drawable-root (drawable)
  (declare (type drawable drawable)
	   (values window)))

(defstruct pointer-info
  (x <unspec> :type integer)
  (y <unspec> :type integer)
  (mask <unspec> :type integer)
  (root <unspec> :type window)
  (child <unspec> :type (or null window))
  (same-screen-p <unspec> :type boolean)
  (root-x <unspec> :type integer)
  (root-y <unspec> :type integer))

(defun query-pointer (window &optional info)
  (declare (type window window)
	   (type (or null pointer-info) info)
	   (values pointer-info)))

(defun pointer-position (window)
  (declare (type window window)
	   (values x y same-screen-p)))

(defun global-pointer-position (display)
  (declare (type display display)
	   (values root root-x root-y)))

(defstruct text-extents
  (direction <unspec> :type draw-direction)
  (font-ascent <unspec> :type integer)
  (font-descent <unspec> :type integer)
  (ascent <unspec> :type integer)
  (descent <unspec> :type integer)
  (width <unspec> :type integer)
  (left <unspec> :type integer)
  (right <unspec> :type integer))

(defun text-extents (font string &optional extents &key (cache-p t))
  ;; If no font info is cached locally, and cache-p is nil, this uses the protocol request.
  ;; Otherwise, the font info is obtained if necessary, and then the result is computed
  ;; locally.
  (declare (type (or font gc) font)
	   (type string string)
	   (type (or null text-extents) extents)
	   (type boolean cache-p)
	   (values text-extents)))

(defun text-bounds (font string &key (cache-p t))
  ;; If no font info is cached locally, and cache-p is nil, this uses the protocol request.
  ;; Otherwise, the font info is obtained if necessary, and then the result is computed
  ;; locally.
  (declare (type (or font gc) font)
	   (type string string)
	   (type boolean cache-p)
	   (values width ascent descent left right)))

(defun text-width (font string &key (cache-p t))
  ;; If no font info is cached locally, and cache-p is nil, this uses the protocol request.
  ;; Otherwise, the font info is obtained if necessary, and then the result is computed
  ;; locally.
  (declare (type (or font gc) font)
	   (type string string)
	   (type boolean cache-p)
	   (values integer)))

(defstruct keyboard-control
  (key-click-percent <unspec> :type integer)
  (bell-percent <unspec> :type integer)
  (bell-pitch <unspec> :type integer)
  (bell-duration <unspec> :type integer)
  (led-mask <unspec> :type integer)
  (global-auto-repeat <unspec> :type (member :on :off))
  (auto-repeats <unspec> :type (bit-vector 256)))

(defun keyboard-control (display &optional control)
  (declare (type display display)
	   (type (or null keyboard-control) control)
	   (values keyboard-control)))

∂15-Apr-87  0901	FAHLMAN@C.CS.CMU.EDU 	keyword args and consing    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87  09:01:13 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 15 Apr 87 11:49:16-EDT
Date: Wed, 15 Apr 1987  11:49 EDT
Message-ID: <FAHLMAN.12294726379.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: keyword args and consing
In-reply-to: Msg of 15 Apr 1987  10:03-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>


    Your concerns were far from obvious until now.
    However, I would like to know how many other implementations suffer from
    this "feature", [keyword args do lots of consing] before we redesign
    lots of things.

I think you will find that the overwhelming majority of Common Lisp
implementations build &key arguments on top of the &rest mechanism, and
that almost all implementations on stock hardware cons up the rest-arg
list (except for certain built-in &rest and &key functions, which the
compiler special-cases).  In many of these systems, the documentation
warns users not to use keywrod args in tense inner loops, precisely
because they cons.

Since it is important that CLX run on stock hardware, I would advise
against using keyword args in functions that are likely to be
inner-loop.  Since CLX must be somewhat implementation-dependent, it
would be possible for each implementation to fix up its compiler to
special-case the necessary forms, but avoiding this hassle would be
nice.

It is technically possible for the compiler to do the necessary analysis
to verify that a &rest arg is used only within the current dynamic
context, and to do stack-consing in those cases where it is legal.  I
don't know of any commercially available Common Lisp compiler that does
this at present.

The Symbolics and, I think, TI Common Lisp implementations did
stack-consing of &rest args without the benefit of such analsysis,
violating the Common Lisp standard and producing some bugs of incredible
subtlety; apparently they felt that the performance gain was worth the
hassle.  I believe that Symbolics intends to put the analsysis in and to
come into compliance with the standard that way; I don't know if this
has yet been released by Symbolics, or what TI's plans are.

I am in the process of proposing a new mechanism, &more, that might help
to eliminate most of this consing, but it might be a tough fight to get
this adopted -- nobody is eager to see another Lambda-list keyword.

-- Scott

∂15-Apr-87  1038	Moon@STONY-BROOK.SCRC.Symbolics.COM 	keyword args and consing    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Apr 87  10:37:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 116649; Wed 15-Apr-87 13:37:21 EDT
Date: Wed, 15 Apr 87 13:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: keyword args and consing
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12294726379.BABYL@C.CS.CMU.EDU>
Message-ID: <870415133655.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 15 Apr 1987  11:49 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

	However, I would like to know how many other implementations suffer from
	this "feature", [keyword args do lots of consing] before we redesign
	lots of things.

    I think you will find that the overwhelming majority of Common Lisp
    implementations build &key arguments on top of the &rest mechanism, and
    that almost all implementations on stock hardware cons up the rest-arg
    list (except for certain built-in &rest and &key functions, which the
    compiler special-cases).  In many of these systems, the documentation
    warns users not to use keywrod args in tense inner loops, precisely
    because they cons.

    Since it is important that CLX run on stock hardware, I would advise
    against using keyword args in functions that are likely to be
    inner-loop.  Since CLX must be somewhat implementation-dependent, it
    would be possible for each implementation to fix up its compiler to
    special-case the necessary forms, but avoiding this hassle would be
    nice.

I find it difficult to believe that there are any serious implementations of
Common Lisp in which it is impossible for the CLX porter to add compiler
optimizers to eliminate this consing for the things that are called often
enough that it matters.  It simply means making a non-keyword-taking version
of the function and writing a compiler optimizer (called a compiler macro
in some systems) that transforms a call to one into a call to the other.
This has to be ten times as easy as putting in the implementation-dependent
interface to the network, or other communication path to the X server, and
making that adequately efficient.

Another point is that if X and Common Lisp are each as successful as it
currently appears they are going to be, the lifetime of this CLX interface
will be far longer than the lifetimes of the particular implementation
versions that have inefficient keyword arguments.  After all, it's not
impossibly difficult to do keyword arguments without consing, and the
only reason some implementations have not done that yet is that their
implementors have had more important tasks to see to.

Thus I really don't think it's appropriate to warp the whole design to
compensate for a minor flaw in current versions of a small number of
Common Lisp implementations.

∂15-Apr-87  1116	RAM@C.CS.CMU.EDU 	keyword args and consing   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87  11:16:02 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Wed 15 Apr 87 14:09:59-EDT
Date: Wed, 15 Apr 1987  14:09 EDT
Message-ID: <RAM.12294751996.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   cl-windows@SAIL.STANFORD.EDU, "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>,
      Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: keyword args and consing
In-reply-to: Msg of 15 Apr 1987  13:36-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


We already do the optimization of transforming keyword calls to known
functions into non-keyword versions.  The problem is that in the event
interface, the functions are user supplied funargs rather than known
named function; in this case such a transformation is not possible.

  Rob

∂15-Apr-87  1629	MMcM@YUKON.SCRC.Symbolics.COM 	XCL [sic] comments 
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 15 Apr 87  16:29:34 PDT
Received: from OWL.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 194271; Wed 15-Apr-87 19:09:52 EDT
Date: Wed, 15 Apr 87 19:09 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: XCL [sic] comments
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: RAM@C.CS.CMU.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870415103529.6.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870415190932.1.MMCM@OWL.SCRC.Symbolics.COM>

    Date: Wed, 15 Apr 87 10:35 EDT
    From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>

	Date: Tue, 14 Apr 1987  19:12 EDT
	From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

	I guess within it, since it might be awkward to implement it on top of
	next-event.  I don't have any problem with providing direct access to the
	event stream, but I think that you badly need some kind of automatic
	demultiplexing mechanism for even simple applications.

    I agree that more automatic mechanisms are needed, but I disagree that they
    should be defined at this level (partly because I think agreement will
    be difficult to obtain).  Someone could/should certainly propose a CLOS
    object-oriented layer to put on top of CLX, and include in it an automatic
    event distribution mechanism that replaces the CLX event functions (in the
    sense that the CLX ones should not be called directly).  Again, opinions
    from others would be useful.

I frankly don't see the problem with implementing a function to be given
to next-event which takes event code (a keyword) and uses it to get a
generic function which is then applied to the window argument and other
arguments.

If consing of the rest arg is an issue, then the implementation can
supply a version of event-case which works directly off of event
structures as maintained by the lower levels.  The dispatching for
window functions is then done inline in a single use of this macro.  A
good enough version of this macro could even directly index the
functions from the event indices.

The real issue to my mind is whether we wish to standardize on the
demultiplexing mechanism as part of this layer.  I don't think so, since
as everyone points out, it's logically part of a higher level.
Furthermore, my own prejudice in implementing a higher level window
system would not be to pass events to window objects as the first in the
chain of command.

∂15-Apr-87  1854	edsel!bhopal!jonl@navajo.stanford.edu 	keyword args and consing  
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87  18:54:21 PDT
Received: by navajo.stanford.edu; Wed, 15 Apr 87 18:53:41 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
	id AA28250; Wed, 15 Apr 87 17:40:57 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
	id AA09310; Wed, 15 Apr 87 18:37:57 PDT
Date: Wed, 15 Apr 87 18:37:57 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704160137.AA09310@bhopal.edsel.com>
To: navajo!Fahlman%C.CS.CMU.EDU@navajo.stanford.edu
Cc: navajo!RWS%ZERMATT.LCS.MIT.EDU@navajo.stanford.edu,
        navajo!cl-windows%SAIL@navajo.stanford.edu
In-Reply-To: "Scott E. Fahlman"'s message of Wed, 15 Apr 1987  11:49 EDT
Subject: keyword args and consing

Re: I think you will find that the overwhelming majority of Common Lisp
    implementations build &key arguments on top of the &rest mechanism, ...
Oh, really?  Who all are you including?  Lucid Common Lisp certainly doesn't
use &rest, or any other consy means, to spread out the &key args.  Probably
EXcL and VAXLISP don't either.  Anyone know?

-- JonL --

∂15-Apr-87  1936	FAHLMAN@C.CS.CMU.EDU 	Consing &key args 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87  19:36:31 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 15 Apr 87 22:37:27-EDT
Date: Wed, 15 Apr 1987  22:37 EDT
Message-ID: <FAHLMAN.12294844399.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   cl-windows@SAIL.STANFORD.EDU
Subject: Consing &key args


I was indeed counting Lucid's implementation among those that consed
&key args.  I stand corrected.

-- Scott

∂16-Apr-87  0857	Oren%Tilde%ti-csl.csnet@RELAY.CS.NET 	Re: plist revisions to CLX proposal  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 16 Apr 87  08:57:36 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ab13828; 16 Apr 87 11:51 EDT
Received: from ti-csl by RELAY.CS.NET id ab15028; 16 Apr 87 11:46 AST
Received: from SI (si.ARPA) by tilde id AA01943; Wed, 15 Apr 87 17:01:34 cdt
Message-Id: <2754514800-12044628@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Wed, 15 Apr 87  18:00:00 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: clx@ZERMATT.LCS.MIT.EDU, cl-windows@SAIL.STANFORD.EDU
Subject: Re: plist revisions to CLX proposal
In-Reply-To: Msg of Wed, 15 Apr 87 00:41 EDT from "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>

>  The more natural interface, I think, would be to provide a separate
>  access function for each value.  If the user wants to get several
>  values, he can call several access functions.  SETF of the access
>  functions works nicely for altering values.

I agree!  Accessor functions are clearly the most efficient, cleanest
way to get at the large number of values returned by the
GetWindowAttributes, GetGeometry, QueryPointer, QueryTextExtents and
GetKeyBoardControl server requests.  Its nice to have a consistent
paradigm of structures with accessors allowing SETF.  This also
eliminates the need for redundant accessor functions like
drawable-geometry, drawable-size and drawable-rectangle.

  - LaMott

∂16-Apr-87  0944	lowry%bizet.DEC@decwrl.DEC.COM 	X interface  
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87  09:44:08 PDT
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
	id AA01254; Thu, 16 Apr 87 08:44:54 PST
Message-Id: <8704161644.AA01254@decwrl.dec.com>
Date: Thursday, 16 Apr 1987 09:25:25-PDT
From: lowry%bizet.DEC@decwrl.DEC.COM  (David Lowry 225-6290)
To: cl-windows@sail.stanford.edu
Subject: X interface

	VAXLISP doesn't cons up &keys either.

Here is what is going on at DEC.  VAXLISP V2.2 goes to field test soon.
In the Ultrix version, we are shipping an XLIB interface written using 
the VAXLISP callout facility, our way of calling foreign functions.
This allows us to access the functions in the /usr/lib/libX.c library 
directly from Lisp.  We implement X structures using the VAXLISP 
alien-structure mechanism, so we can read them in lisp the same as CL 
structures, and pass them to the X interface.  If X creates a structure 
and passes it back, we don't copy it into Lisp memory.  However structures
we pass that X fills in (such as events) are created in Lisp memory.

	Our basic strategy has been to supply the Lisp equivalent of the
C version of the X functions.  We provide as little extra functionality
as we can,  mostly creating and passing the alien-structures that X fills
in, and some help functions for problems between the Lisp and C version,
such as making vertices for the DRAW functions.

	This is for X10.  We are shipping the source code for the X 
callouts with VAXLISP.  We haven't decided yet how we will implement X11.
I will certainly keep up on the CLX proposals, but the decision will be 
based on those and other considerations.

David Lowry
DEC

∂16-Apr-87  1041	ibuki!weaver@labrea.stanford.edu 	Re:  keyword args and consing  
Received: from LABREA by SAIL.STANFORD.EDU with TCP; 16 Apr 87  10:41:14 PDT
Received: by labrea.stanford.edu; Thu, 16 Apr 87 10:41:51 PST
Received: by ibuki.UUCP (1.4/4.7)
	id AA6619220; Thu, 16 Apr 87 10:34:16 pst
Date: Thu, 16 Apr 87 10:34:16 pst
From: ibuki!weaver@labrea.stanford.edu (Eric Weaver)
Message-Id: <8704161834.AA6619220@ibuki.UUCP>
To: labrea!cl-windows@sail.arpa
Subject: Re:  keyword args and consing

    Date: Wed, 15 Apr 87 18:37:57 PDT
    From: labrea!edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)

    Re: I think you will find that the overwhelming majority of Common Lisp
    	implementations build &key arguments on top of the &rest mechanism, ...

    Oh, really?  Who all are you including?  Lucid Common Lisp certainly doesn't
    use &rest, or any other consy means, to spread out the &key args.  Probably
    EXcL and VAXLISP don't either.  Anyone know?

    -- JonL --

KCL doesn't; it just looks at what's on the stack.

∂17-Apr-87  0820	RWS%ZERMATT.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	minor correction to CLX event-case    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87  08:20:18 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Apr 87 11:20-EDT
Date: Fri, 17 Apr 87 11:22 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: minor correction to CLX event-case
To: cl-windows@sail.stanford.edu
Message-ID: <870417112200.7.RWS@KILLINGTON.LCS.MIT.EDU>

The proposed EVENT-CASE macro form failed to allow T or
OTHERWISE in place of the event-or-events specifier.
Clearly this should be allowed (in the last clause).
Also, if no t/otherwise clause appears, it should be
equivalent to having one that returns nil.

∂22-Apr-87  0551	RWS@ZERMATT.LCS.MIT.EDU 	WITH-GC semantics in CLX 
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Apr 87  05:51:07 PDT
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 45520; Wed 22-Apr-87 08:52:59 EDT
Date: Wed, 22 Apr 87 08:52 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: WITH-GC semantics in CLX
To: cl-windows@sail.stanford.edu
Message-ID: <870422085258.6.RWS@KILLINGTON.LCS.MIT.EDU>

The initial CLX proposal stated that WITH-GC locked the graphics context
in a multi-process system.  This means that all of the drawing functions
must also lock GCs.  Not only is this a potential performance hit, but
it introduces the possibility of deadlock.

We are revising the specification, to state that WITH-GC changes and
restores the graphics context in such a way that the changes have
dynamic scope (i.e., indefinite scope and dynamic extent) and are
per-process in a multi-process environment.  No "locking" is performed
(although a multi-process implementation will certainly make use of the
underlying with-display locking inherent in each graphics operation in
order to make the server-stored state consistent with the per-process
logical state).

∂22-Apr-87  2012	Moon@STONY-BROOK.SCRC.Symbolics.COM 	another try at CLX "lots of result values" 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Apr 87  20:12:34 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 122432; Wed 22-Apr-87 23:11:42 EDT
Date: Wed, 22 Apr 87 23:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: another try at CLX "lots of result values"
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870415113622.1.RWS@KILLINGTON.LCS.MIT.EDU>,
             <870415113324.0.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870422231121.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

This is not a transcendently important issue, but even so I'd like to open it
one more time.  The better this standard fits into the rest of Common Lisp the
more success people will have in using it, I feel.

    Date: Wed, 15 Apr 87 11:36 EDT
    From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>

    I've followed the suggestion of defining structures for the
    values, allowing an optional structure to be passed in to
    avoid consing, defining various subset returning functions,
    and eliminating the macro forms entirely.

(Eliminating the macro forms is certainly good.  The ones I suggested
were a totally bad idea!)

This will work, but this indirection through structures still doesn't seem
right to me.  For example, in Common Lisp style I would expect to be able
to say

  (window-bit-gravity window)

to obtain the bit-gravity of a window, but instead I have to say

  (window-attributes-bit-gravity (window-attributes window))

It's worse if I want to change it.  Instead of

  (setf (window-bit-gravity window) value)

I have to say [I'm guessing here, because you didn't show how to do
this at all in your message]

  (let ((wa (window-attributes window)))
    (setf (window-attributes-bit-gravity wa) value)
    (set-window-attributes window wa))

and what if I forget and write

  (setf (window-attributes-bit-gravity (window-attributes window)) value)

This compiles and runs, but doesn't have any effect on the window.

It really seems like I'm doing a lot of manual storage management
with these structures, as if I was programming in C instead of Lisp.

I think the subset-returning functions you added to try to fix this actually
make the situation worse, because now there are two ways to access some data,
but only one way to access other data, things are less consistent, and the
programmer might have to spend a lot more time with his nose buried in a
manual.

I think the fields of windows, drawables, and keyboards are fundamentally
different from text-extents and query-pointer, and trying to fit all of these
into the same mold is part of the problem.  The window, drawable, and keyboard
fields are conceptually the same as defstruct slots, except that the storage
resides in the server machine, not in Lisp memory.  One would expect to be
able to manipulate them with the same accessor-and-setf syntax that is used
for defstruct slots.  Furthermore, as far as I can tell, there are no
synchronization nor efficiency issues that would necessitate special ways to
read and write more than one field at a time.  So I really feel that this
group ought to follow the single-field accessor model rather than the
return-a-structure model.

Text-extents and query-pointer are different.  These values are not "fields"
that one could imagine changing with setf.  As you pointed to me, the values
from query-pointer are instantaneous values that must be read as a group to be
meaningful.  Text-extents doesn't seem to have a synchronization issue, but
the values still aren't useful individually.  The only choices that make sense
for these two are to return a structure or to return multiple values.  The
first approach has the advantage of using names instead of positions, but
involves more conceptual baggage, and has some risk of an efficiency cost.  I
would personally opt for the second approach, because you are only returning
eight values and I think that number is manageable.  But
text-extent/query-pointer are less clear-cut than the first three.

Two minor comments:

    Is the use of both &optional and &key in text-extents acceptable?

It is almost always asking for trouble to use &optional and &key in
the same parameter list.

    Date: Wed, 15 Apr 87 11:33 EDT
    From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>

    the caller is very likely to want more than one value at a time, which makes
    individual accessors less convenient to use, and certainly a pain if you
    really want everything.

I don't buy this.  Is

  (logxor (window-event-mask window) (window-do-not-propagate-mask window))

really less convenient than

  (let ((wa (window-attributes window)))
    (logxor (window-attributes-event-mask wa)
	    (window-attributes-do-not-propagate-mask wa)))

(The example is made-up and doesn't make sense semantically; that's not
important.)

∂23-Apr-87  0953	Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET 	Re: another try at CLX "lots of result values"   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 23 Apr 87  09:53:37 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ae17052; 23 Apr 87 12:53 EDT
Received: from ti-csl by RELAY.CS.NET id ag07248; 23 Apr 87 12:45 AST
Received: from dsg (juliett.ARPA) by tilde id AA24479; Thu, 23 Apr 87 11:45:00 cdt
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 23 Apr 87  11:46:02 CDT
Message-Id: <2755183534-3649459@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Thu, 23 Apr 87  11:45:34 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: another try at CLX "lots of result values"
In-Reply-To: Msg of Wed, 22 Apr 87 23:11 EDT from "David A. Moon" <Moon@scrc-stony-brook.arpa>

I appreciate your point concerning the importance of a smooth fit between CLX
and the Common Lisp way of life. So, I'm inclined to favor the single-field
accessor model which you propose. However, there is one snag which bothers me,
and that's the idea of individually SETF'ing the fields of a window, etc. The
implication seems to be that CLX should generate a server request for each SETF
operation. I don't see how CLX could batch these requests reliably, without
exposing the caching mechanism in its interfaces, and yet I detect an aversion
to interfaces that make control of a cache explicit. Now, I'm convinced that
updating several window attributes at a "whack" will be a common and useful X
operation. So, I'm reluctant to see an approach that will make this operation
unnecessarily costly.

All of the issues and alternatives here have been thoroughly discussed.  My only
contribution to the debate is the following bit of philosophy: that the client
and the server are in different address spaces is a fundamental fact of X
reality, and any CLX model that "pretends" that this is not so is probably a
mistake. Specifically, the single-field accessor model tries to cover up this
fundamental fact, and while it may be possible for CLX to jump through its own
earlobe trying to preserve such a model, it's probably not worth it. 

To me, Scheifler's latest proposal, based on defstructs, strikes the best
balance between ease-of-use and efficiency of implementation, in a model that
recognizes the reality of network packets in an undistorted fashion.

∂23-Apr-87  1139	Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET 	Re: another try at CLX "lots of result values"   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 23 Apr 87  09:53:37 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ae17052; 23 Apr 87 12:53 EDT
Received: from ti-csl by RELAY.CS.NET id ag07248; 23 Apr 87 12:45 AST
Received: from dsg (juliett.ARPA) by tilde id AA24479; Thu, 23 Apr 87 11:45:00 cdt
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 23 Apr 87  11:46:02 CDT
Message-Id: <2755183534-3649459@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Thu, 23 Apr 87  11:45:34 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: another try at CLX "lots of result values"
In-Reply-To: Msg of Wed, 22 Apr 87 23:11 EDT from "David A. Moon" <Moon@scrc-stony-brook.arpa>

I appreciate your point concerning the importance of a smooth fit between CLX
and the Common Lisp way of life. So, I'm inclined to favor the single-field
accessor model which you propose. However, there is one snag which bothers me,
and that's the idea of individually SETF'ing the fields of a window, etc. The
implication seems to be that CLX should generate a server request for each SETF
operation. I don't see how CLX could batch these requests reliably, without
exposing the caching mechanism in its interfaces, and yet I detect an aversion
to interfaces that make control of a cache explicit. Now, I'm convinced that
updating several window attributes at a "whack" will be a common and useful X
operation. So, I'm reluctant to see an approach that will make this operation
unnecessarily costly.

All of the issues and alternatives here have been thoroughly discussed.  My only
contribution to the debate is the following bit of philosophy: that the client
and the server are in different address spaces is a fundamental fact of X
reality, and any CLX model that "pretends" that this is not so is probably a
mistake. Specifically, the single-field accessor model tries to cover up this
fundamental fact, and while it may be possible for CLX to jump through its own
earlobe trying to preserve such a model, it's probably not worth it. 

To me, Scheifler's latest proposal, based on defstructs, strikes the best
balance between ease-of-use and efficiency of implementation, in a model that
recognizes the reality of network packets in an undistorted fashion.

∂23-Apr-87  1513	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: another try at CLX "lots of result values"  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87  15:13:20 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123345; Thu 23-Apr-87 18:11:47 EDT
Date: Thu, 23 Apr 87 18:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: another try at CLX "lots of result values"
To: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>, DDYER@RIVERSIDE.SCRC.Symbolics.COM
cc: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2755183534-3649459@Sierra>,
             <870423115325.8.DDYER@PURPLE.SWW.Symbolics.COM>
Message-ID: <870423181134.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

I guess the conversation between RWS and me in which it was determined
that efficiency was not an issue was not sent to the whole mailing list.
Here "efficiency" means batching of multiple field accesses into a
single server request.  RWS doesn't think this will happen often enough
to be an issue.  I think that it is straightforward and simple to
complexify the implementation so that it can do this batching, without
having to complicate the interface.  Either way, the design of the
interface need not be affected by this efficiency consideration. 
(Incidentally, unless I am confused the proposed interface already
requires this sort of complexification for graphics contexts.)

∂23-Apr-87  1521	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	another try at CLX "lots of result values"   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87  15:20:58 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 23 Apr 87 18:19-EDT
Date: Thu, 23 Apr 87 18:22 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: another try at CLX "lots of result values"
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870422231121.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870423182233.4.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Wed, 22 Apr 87 23:11 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

		  For example, in Common Lisp style I would expect to be able
    to say

      (window-bit-gravity window)

    to obtain the bit-gravity of a window, but instead I have to say

      (window-attributes-bit-gravity (window-attributes window))

Actually, this particular case is just (window-gravity window), but
yes, I have arbitrarily chosen to clump things into a few subsets
and provide multiple-value functions (in addition to the general
structure returning function), rather than (also) providing all of
the individual accessors.

    It's worse if I want to change it.  Instead of

      (setf (window-bit-gravity window) value)

    I have to say [I'm guessing here, because you didn't show how to do
    this at all in your message]

      (let ((wa (window-attributes window)))
	(setf (window-attributes-bit-gravity wa) value)
	(set-window-attributes window wa))

Changing things is with (change-window-attributes window :bit-gravity value)
as specified in the original proposal, rather than (also) having individual setfs.
There is no need to use the structure forms except when you want to get all of
the information out indivisibly.

If people REALLY want all of the individual accessors and setfs, they can certainly
be provided (whether as part of the base proposal or implemented on top).  I don't
particularly care, provided they are not the ONLY mechanism.

    I think the subset-returning functions you added to try to fix this actually
    make the situation worse, because now there are two ways to access some data,
    but only one way to access other data, things are less consistent, and the
    programmer might have to spend a lot more time with his nose buried in a
    manual.

I disagree.  I don't see this as any worse than the fact that Genera, for example,
has :position and :edges as well as :x-offset and :y-offset and :height and :width
and :inside-size and ...  You try and provide interfaces for common cases.

						The window, drawable, and keyboard
    fields are conceptually the same as defstruct slots, except that the storage
    resides in the server machine, not in Lisp memory.  One would expect to be
    able to manipulate them with the same accessor-and-setf syntax that is used
    for defstruct slots.  Furthermore, as far as I can tell, there are no
    synchronization nor efficiency issues that would necessitate special ways to
    read and write more than one field at a time.

Round-trip times are an efficiency issue, and getting consistent values is a
synchronization issue.

    Text-extents and query-pointer are different.
						  The only choices that make sense
    for these two are to return a structure or to return multiple values.  The
    first approach has the advantage of using names instead of positions, but
    involves more conceptual baggage, and has some risk of an efficiency cost.  I
    would personally opt for the second approach, because you are only returning
    eight values and I think that number is manageable.

I don't particularly care about these.  If people would prefer getting rid of
their structure forms and having just one (or more) multiple-value form, that
would be fine with me.

	Is the use of both &optional and &key in text-extents acceptable?

    It is almost always asking for trouble to use &optional and &key in
    the same parameter list.

I agree.  The only question is how to change it.  Should they both be
optional, or both keyword?  Related to this, one person has suggested
that all functions with a singleton &key be changed to have an &optional
instead.  I would like to hear opinions from others.

∂23-Apr-87  1547	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: another try at CLX "lots of result values"    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87  15:47:05 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 23 Apr 87 18:42-EDT
Date: Thu, 23 Apr 87 18:46 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: another try at CLX "lots of result values"
To: Moon@STONY-BROOK.SCRC.Symbolics.COM,
    Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET,
    DDYER@RIVERSIDE.SCRC.Symbolics.COM
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870423181134.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870423184609.7.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Thu, 23 Apr 87 18:11 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    Here "efficiency" means batching of multiple field accesses into a
    single server request.  RWS doesn't think this will happen often enough
    to be an issue.  I think that it is straightforward and simple to
    complexify the implementation so that it can do this batching, without
    having to complicate the interface.  Either way, the design of the
    interface need not be affected by this efficiency consideration. 

Yes (although I may have just indicated to the contrary in a previous
message), I don't think the window/drawable/keyboard requests are
important from a performance point of view, although synchronization
when reading and writing is important.  Basically, I don't think they
are important enough that "natural" interfaces are important; simplicity
(while worrying about synchronization) seems most important.  To me,
this argues against accessor/setf as the only mechanism, and two sets of
mechanism are overkill.

    (Incidentally, unless I am confused the proposed interface already
    requires this sort of complexification for graphics contexts.)

Graphics contexts are a critical part of normal operation; dynamic
binding and caching and the implied complexity are well worth the effort
here.  Also, graphics contexts are NOT intended to be shared by clients
under normal circumstances, so local caching strategies are perfectly
reasonable.

∂23-Apr-87  2102	dcmartin@postgres 	Re: another try at CLX "lots of result values"     
Received: from [128.32.149.1] by SAIL.STANFORD.EDU with TCP; 23 Apr 87  21:02:27 PDT
Received: by postgres (3.2/1.22)
	id AA17962; Thu, 23 Apr 87 21:02:22 PDT
Message-Id: <8704240402.AA17962@postgres>
From: David C. Martin <dcmartin@postgres>
Office: 440 Evans - x2-9585
Home: 2441 Haste St #37, Berkeley, CA 94704 - (415) 843-6470
Fortran: is not backward, NARTROF is backwards.
To: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Cc: Moon@stony-brook.scrc.symbolics.com, cl-windows@sail.stanford.edu
Precedence: special-delivery 
In-Reply-To: Your message of Thu, 23 Apr 87 18:22 EDT 
	<870423182233.4.RWS@KILLINGTON.LCS.MIT.EDU> 
Subject: Re: another try at CLX "lots of result values" 
Date: Thu, 23 Apr 87 21:02:20 PDT
Sender: dcmartin@postgres

Your letter:

    I agree.  The only question is how to change it.  Should they both be
    optional, or both keyword?  Related to this, one person has suggested
    that all functions with a singleton &key be changed to have an &optional
    instead.  I would like to hear opinions from others.

In implementing XCL (not CLX, mind you :-), I found that most of the people
implementing code using the interface preferred to have singleton keywords
as optionals.  I have also found this to be the case considering the plethora
of functions and my forgetfulness.

dcm

∂23-Apr-87  2139	Moon@STONY-BROOK.SCRC.Symbolics.COM 	another try at CLX "lots of result values" 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87  21:39:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123683; Fri 24-Apr-87 00:39:10 EDT
Date: Fri, 24 Apr 87 00:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: another try at CLX "lots of result values"
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870423182233.4.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870424003902.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 23 Apr 87 18:22 EDT
    From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>

	I think the subset-returning functions you added to try to fix this actually
	make the situation worse, because now there are two ways to access some data,
	but only one way to access other data, things are less consistent, and the
	programmer might have to spend a lot more time with his nose buried in a
	manual.

    I disagree.  I don't see this as any worse than the fact that Genera, for example,
    has :position and :edges as well as :x-offset and :y-offset and :height and :width
    and :inside-size and ...  You try and provide interfaces for common cases.

I don't think it's wise to take the current Genera window system as your
standard for quality of program interfaces.  You should be able to do a
lot better.

As for the rest of the "lots of result values" discussion, I've said my
piece.  If you're not listening, that's just an opportunity to poke fun
at the standard later when it's published, so I don't think we should
spend too much more time on this.

∂24-Apr-87  0741	decvax!cvbnet!admin!tbardasz@decwrl.DEC.COM 	Mailing List   
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 24 Apr 87  07:39:57 PDT
Received: from decvax.dec.com by decwrl.dec.com (5.54.3/4.7.34)
	id AA28950; Fri, 24 Apr 87 06:40:56 PST
Received: from admin.uucp (mcae) by cvbnet.uucp (2.0/SMI-2.0)
	id AA02965; Fri, 24 Apr 87 10:17:15 est
Received: by admin.uucp (1.1/SMI-3.0DEV3)
	id AA13161; Fri, 24 Apr 87 10:13:14 EST
Date: Fri, 24 Apr 87 10:13:14 EST
From: decvax!cvbnet!admin!tbardasz@decwrl.DEC.COM (Ted Bardasz)
Message-Id: <8704241513.AA13161@admin.uucp>
To: cvbnet!decvax!decwrl!SAIL.STANFORD.EDU!CL-WINDOWS@decwrl.DEC.COM
Subject: Mailing List


Hello,
     Could you please add me to the mailing list for:

	COMMON LISP WINDOWS

     My mail address is:
	decvax!cvbnet!basie!tbardasz@decwrl.dec.com

     Thank you very much,
	Ted Bardasz at Computervision Corp.

∂24-Apr-87  1024	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	CLX change summary  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Apr 87  10:24:02 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 24 Apr 87 13:22-EDT
Date: Fri, 24 Apr 87 13:26 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX change summary
To: cl-windows@sail.stanford.edu
Message-ID: <870424132602.7.RWS@KILLINGTON.LCS.MIT.EDU>

The following is a summary of changes that have been made to the
original CLX proposal.  The file /pub/clx.lisp, available via anonymous
ftp on milo.lcs.mit.edu, reflects all of these changes.  The only
significant changes that haven't been mentioned before are:

1. various keyword arguments have changed to optional
   (but some have remained keyword either for overall consistency
    or for consistency with a paired function using the keyword form).
2. desire for local caching is now a property of a font object, and
   the cache-p boolean has been removed from the querying functions.

In a subsequent message I will summarize what I think are the
outstanding issues.

new defstructs: window-attributes, drawable-geometry, pointer-info,
		text-extents, keyboard-control

in display-error-handler, the display and error-key arguments to the
handler changed from positional to keyword, the array form of handler
changed to a sequence, and the error-key is passed even when the
handler is a sequence of functions

window-attributes function redefined
added functions: window-kind, window-gravity, window-backing-store,
		 window-colormap, window-map-state, window-event-masks

circulate-window split into circulate-window-up and circulate-window-down

drawable-geometry function redefined
added functions: drawable-depth, drawable-root

store-property renamed to change-property

added functions: intern-atom, find-atom, atom-name

both resource-ids and resource objects allowed as event components in
send-event, send-event-to-pointer-window, and send-event-to-input-focus

query-pointer function redefined
added functions: pointer-position, global-pointer-position

&optional (cache-p t) added to open-font, to determine whether QueryFont
results are retained locally

font-cache-p accessor and setf added

make-font creates with cache-p t

cache-p argument removed from text-extents and text-width

text-extents function redefined
added function: text-bounds

matching-fonts renamed to list-fonts
matching-fonts-and-properties renamed to list-fonts-with-info

accessors and setfs defined for gc components

added function: force-gc-changes

with-gc changed from process-locking semantics to per-process dynamic scope

start and end keywords added to draw-string, draw-string-image,
draw-string16, and draw-string-image16

keyboard-control function redefined

add-access-hosts changed to add-access-host (incorporates protocol change)
rem-access-hosts changed to remove-access-host (incorporates protocol change)

in next-event, the display and event-key arguments to the handler
changed from positional to keyword, the array form of handler changed
to a sequence, and the event-key is passed even when the handler is a
sequence of functions

in event-case, a t/otherwise clause is allowed

&key changed to &optional in following functions:
	set-selection-owner, convert-selection, change-active-pointer-grab,
	allow-events, set-input-focus, draw-points, draw-line, draw-rectangle,
	draw-rectangles, draw-arc, draw-arcs, create-colormap, free-colors

∂24-Apr-87  1232	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	CLX issues
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Apr 87  12:32:16 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 24 Apr 87 15:23-EDT
Date: Fri, 24 Apr 87 15:27 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX issues
To: cl-windows@sail.stanford.edu
Message-ID: <870424152743.4.RWS@KILLINGTON.LCS.MIT.EDU>

The following are the outstanding issues that I am aware of.  I solicit
comments about all of them, and comments about any I have left out.  At
the same time, I solicit "votes" to get an idea of how the proposal
stands (and how many people even care).  The kind of vote I had in mind
is one of:
	1. Good enough, if you fix the following nits
	2. Good enough, if you make the following changes
	3. Mostly good enough, but with the following problems (for which
	   I don't have a proposed solution)
	4. Beyond hope
	5. Don't have time to think about it


There are now individual setfs for gc components, in addition to
change-gc.  It would be nice to eliminate change-gc.  The only thing
standing in the way is being able to batch changes for uncached gcs.  I
propose to solve this problem by redefining what caching means for gcs.
Instead of the cache being (member :off :write-through :write-back),
change it to just a boolean, with the following meaning.  Regardless of
the cache mode, all changes are batched, and only written to the server
on a demand basis, or an explicit call to force-gc-changes.  (I was
never truly convinced that a :write-through cache was all that useful,
so I don't see any real reason to retain it.)  If the cache is off, then
no local copy of the gc state is retained, which means the accessors
always return nil, and setfs are never ignored.  If the cache is on,
then local state is retained, and "redundant" setfs are ignored.

There is a question about whether gc's should be forced to retain dash
lists and clipping rectangle lists, in order to return them via the
corresponding accessors.  My own bias is to allow these accessors to
return nil in this case.

It would appear that most CL implementations do not suffer from consing
lossage for keyword arguments, so I do not believe that is a compelling
reason to change next-event.  However, I now tend to think that
event-case is the more desirable, and perhaps sufficient, interface.
So, I would be willing to consider dropping next-event completely.  Are
there any good arguments for retaining a functional interface?  The only
plausible one I can think of is to have a convenient way to cons up
structures, but a better solution to that might simply be to give in and
also define a set of structures and an explicit function for returning
them.

One minor aspect of event-case: the clauses currently contain a variable
list, from which the corresponding event value names are inferred.
Would it be worth allowing a (keyword var) specifier as for lambda-list
keywords, so that the variable name need not match the value name?

The only other issue about events is whether it should be possible to
specify a timeout value in event-case (and next-event).  Presumably a
time value (in what units?) would replace hang-p, with zero equivalent
to no-hang, and nil equivalent to hang forever.  Presumably a timeout
would simply cause event-case to return nil.  An alternative would be to
just allow an optional timeout to event-listen.

Although I have been forced to argue on the "wrong" side of the debate
about accessors and setfs for window attributes, I do agree that it
would be great if there was a simple semantic (and implementation)
proposal that eliminated structures and multiple-values without causing
synchronization problems.  The same holds true of geometry accessors,
and perhaps even geometry setfs as a replacement for configure-window.
I will continue to give it some thought, but a concrete proposal from
elsewhere ...

I would be willing to eliminate global-pointer-position, and redefine
pointer-position to return 8 values, and eliminate the pointer-info
defstruct (but retain pointer-position as a special case).  I lean
toward liking this better than the structure interface.

I would be willing to eliminate text-bounds, and redefine text-extents
to return 8 values, and eliminate the text-extents defstruct (but retain
text-width as a special case).  I lean toward liking this better than
the structure interface.

I would be willing to redefine keyboard-control to return 7 values, and
eliminate the keyboard-control defstruct.  I lean toward liking this
better than the structure interface.

∂24-Apr-87  1701	moshell%ucf.csnet@RELAY.CS.NET
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 24 Apr 87  17:01:19 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ab00811; 24 Apr 87 19:55 EDT
Received: from ucf.edu by RELAY.CS.NET id ab03052; 24 Apr 87 19:49 AST
Received: by localhost.UUCP (5.51/6.0.UCF)
	id AA12377; Fri, 24 Apr 87 07:53:01 EDT
Date: Fri, 24 Apr 87 07:53:01 EDT
From: Mike Moshell <moshell%ucf.csnet@RELAY.CS.NET>
Posted-Date: Fri, 24 Apr 87 07:53:01 EDT
To: cl-windows@SAIL.STANFORD.EDU

Please remove me from the mailing list; my students are
now monitoring the mailings and will keep me informed. Thanks! 


∂27-Apr-87  1814	Moon@STONY-BROOK.SCRC.Symbolics.COM 	CLX issues   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Apr 87  18:14:20 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 125684; Mon 27-Apr-87 21:13:45 EDT
Date: Mon, 27 Apr 87 21:13 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: CLX issues
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@sail.stanford.edu
In-Reply-To: <870424152743.4.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870427211337.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 24 Apr 87 15:27 EDT
    From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>

    The following are the outstanding issues that I am aware of.

No comment from me on most of the issues, but...

    If the cache is off, then
    no local copy of the gc state is retained, which means the accessors
    always return nil

Returning the wrong value when it's too expensive to compute the right
value is a dangerous policy.  Even if you think that no one in their
right mind would ever call the accessor in this case, some day someone
in their wrong mind will come along, get the NIL, and lose.  I suggest
either making the accessors obtain the right value over the network, at
whatever cost, or else making the accessors signal an error.

    Presumably a
    time value (in what units?) would replace hang-p, with zero equivalent
    to no-hang, and nil equivalent to hang forever.

Common Lisp generally uses seconds, with floating-point or ratio arguments
as the way to access units of time smaller than 1 second.

    I solicit "votes"

I'm going to refrain from voting, because I don't think I know enough about
virtual consoles to be able to give an informed vote.  Right now I'm mostly
participating from the Lisp side rather than the X Windows side.  I haven't
seen any other replies to your message yet, but I sure hope I'm not the only
person on this mailing list!

∂27-Apr-87  2033	ACUFF@SUMEX-AIM.STANFORD.EDU 	CLX Issues; attribute interfaces   
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Apr 87  20:33:18 PDT
Date: Mon, 27 Apr 87 20:33:40 PDT
From: Richard Acuff <Acuff@SUMEX-AIM.STANFORD.EDU>
Subject: CLX Issues; attribute interfaces
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12298000370.69.ACUFF@SUMEX-AIM.STANFORD.EDU>

   I can't claim great familiarity with CLX, but I believe that I agree
strongly with Moon's proposed single function accessors.  Is there any
reason that a wrapper macro couldn't be used to address batching and
synchronization issues?

	-- Rich
-------

∂28-Apr-87  0858	Oren%Tilde%ti-csl.csnet@RELAY.CS.NET 	Re: CLX issues   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 28 Apr 87  08:57:47 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ag00490; 28 Apr 87 11:51 EDT
Received: from ti-csl by RELAY.CS.NET id al00118; 28 Apr 87 11:47 EDT
Received: from SI (si.ARPA) by tilde id AA26527; Tue, 28 Apr 87 10:44:08 cdt
Message-Id: <2755611781-3175100@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Tue, 28 Apr 87  09:43:01 MDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX issues
In-Reply-To: Msg of Fri, 24 Apr 87 15:27 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>

I think the CLX proposal is good enough, with the following comments:

1. I agree with your proposal to eliminate :write-through mode on the GC
   cache.

2. I think the GC cache should retain dash lists and clipping rectangle
   lists.

3. I agree with David Moon that accessor macros should never return an
   incorrect value, they should signal an error.  It would be nice if an
   accessor could get the value over the network, but there's no request
   for doing this (is there?).  Its not clear to me why someone would
   turn the cache off - there's not that much overhead involved.

4. Get rid of NEXT-EVENT  Standards shouldn't have more than one way to
   perform the same operation.  Its easy enough to get the functionality
   of NEXT-EVENT using EVENT-CASE with an otherwise clause.

>  One minor aspect of event-case: the clauses currently contain a variable
>  list, from which the corresponding event value names are inferred.
>  Would it be worth allowing a (keyword var) specifier as for lambda-list
>  keywords, so that the variable name need not match the value name?

5. I thought CLX already did this.  The documentation for EVENT-CASE says:
   ; Macro convenience for a call to next-event with a lexical closure.
   I assumed this ment that the variable list for an event clause was
   a CL lambda list.  Since CL allows (keyword var), EVENT-CASE should
   also.

6. EVENT-CASE needs a timeout option (in seconds).  This is much better
   than forcing applications developers to write non-portable code
   to implement this critical feature.

7. The current solution for window-attributes drawable-geometry and
   keyboard-control is "good enough", but I would prefer a wrapper
   macro around accessor macros.  The accessor macros can be made to
   generate compile-time errors saying they're not inside the wrapper,
   so there's no chance for error.  I still don't understand why a
   wrapper of this kind is "conceptually complex".  It seems to me that
   it would be better to standardize on a single powerful interface, and
   let a toolkit provide structures and commonly used groupings of
   multiple-valued returns.

8. Multiple-Values are probably better than structures for
   query-pointer text-extents and keyboard-control.  If someone really
   wants structures, let them build it as part of a toolkit.

9. The (member :on :off) type on several of the parameters bothers me.
   I understand that this was done to allow NIL to be the default value,
   but it seems to me all this does is simplify the CLX implementation
   at the expense of programmer confusion.  It will be hard to remember
   where to use T and NIL, and where to use :ON and :OFF.

∂28-Apr-87  1054	rfb@h.cs.cmu.edu 	CLX issues  
Received: from H.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Apr 87  10:54:38 PDT
Date: 28 Apr 1987 13:47-EDT 
From: Rick.Busdiecker@h.cs.cmu.edu
To: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
Cc: cl-windows@sail.stanford.edu
Subject: CLX issues
Message-Id: <546630449/rfb@h.cs.cmu.edu>

    From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>

    4. Get rid of NEXT-EVENT  Standards shouldn't have more than one way to
       perform the same operation.  Its easy enough to get the functionality
       of NEXT-EVENT using EVENT-CASE with an otherwise clause.

I disagree, and I think that the CommonLisp language standard sets
quite the opposite precedent.  By the reasoning described above,
CommonLisp shouldn't have Case, If, Unless, and When because it's easy
enough to get the functionality of all of these using Cond.

			Rick

∂29-Apr-87  1331	Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET 	Comments on CLX proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 29 Apr 87  13:31:04 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa00794; 29 Apr 87 16:21 EDT
Received: from ti-csl by RELAY.CS.NET id aa08829; 29 Apr 87 16:15 EDT
Received: from dsg (juliett.ARPA) by tilde id AA01782; Wed, 29 Apr 87 14:29:20 cdt
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 29 Apr 87  14:32:07 CDT
Message-Id: <2755711707-2350331@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Wed, 29 Apr 87  14:28:27 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Comments on CLX proposal


The current CLX proposal is very good; its authors are to be commended for their
hard work. The comments below identify areas where I think some more work is
needed, as well as some areas where I feel more clarification is required. I
also added my comments on the current issues list. Items which represent major
concerns are marked by *.

Note: I found it somewhat difficult to keep track of the latest
document-plus-changes.  I apologize in advance for any comments which are no
longer pertinent to the current document.


TECHNICAL COMMENTS

  1.    It's possible to improve the quality of the CLX language binding. In
        general, a good language binding to a large function set can enhance
        programmer productivity (by increasing the speed and reliability with
        which the correct function call can be composed) and program
        maintainability (by reducing the effort for a code reader to comprehend
        a function call). Here are some specific changes which these principles
        suggest.
        
        o Productivity, Readability: Consistently use &key for all optional
          arguments. The consistency promotes productivity, while the &key
          syntax makes the meaning of the arguments clear. The overriding value
          of maintainability should outweigh any objection to the "typeability"
          of the &key syntax.

        o Productivity: When possible, make the function name identical to the
          corresponding request name. This reduces the total number of names
          which the X programmer has to know and improves the transfer of X
          knowledge from the C domain to the Lisp domain (and vice versa). I
          note that recent document changes seem to have cured most of the
          problems in this area. 

        o Productivity, Readability: Use function and argument names which
          represent their corresponding meanings as exactly as possible. In case
          of a conflict, this consideration should override the use of the X
          request name. Some names which could be improved are:

                display                     Replace with server
                CONDITIONAL-WARP-POINTER    Replace with WARP-POINTER-IF-INSIDE
                KILL-TEMPORARY-CLIENTS      Replace with KILL-TEMPORARY-RESOURCES
                EVENT-LISTEN                Replace with EVENTS-RECEIVED
                NEXT-EVENT                  Replace with PROCESS-NEXT-EVENT
                force-p                     Replace with force-output-p

        o Productivity: When good language usage demands that a function name
          differ from its X request counterpart, adopt a name "transformation
          rule" and apply it consistently. The current binding represents a
          reasonable attempt at this (for example, "GetFoo" always becomes
          "FOO"), but it suffers from inconsistency. The biggest problem occurs
          with "SetFoo" which sometimes becomes (SETF FOO) and other times
          becomes SET-FOO. Another example is the handling of the "ListFoo"
          requests. Even in the touchy case of "SetFoo", I think the binding
          would be improved by picking one rule and sticking to it everywhere. 

          Actually, it seems to me that the X request names themselves have some
          problems in this area. For example, why are some things "ChangeFoo"
          and other things "SetFoo"?

* 2.    A function to return an event to the head of the event queue is needed
        (cp. XPutBackEvent in Xlib v10). This requirement comes from the need to
        support a grammar-driven dialog controller. Is this what
        QUEUE-EVENT-LOCALLY is supposed to do?

  3.    CREATE-WINDOW: parent, x, y, width, and height should probably be
        required arguments (not &key). Alternatively, the defaults used for
        these need to be specified.

* 4.    SEND-EVENT, et al.: A single SEND-EVENT function is preferable because
        this allows a useful parameterization of the operation. For example, it
        would be nice if a function could accept just any old window as an
        argument and SEND-EVENT to it, without having to decide how to dispatch
        to one of SEND-EVENT, SEND-EVENT-TO-POINTER-WINDOW, or
        SEND-EVENT-TO-INPUT-FOCUS. I realize this introduces the technical
        problem of defining a window id value for (INPUT-FOCUS-OF display),
        etc., but this can be dealt with (can't it?).

  5.    TRANSLATE-COORDINATES: My copy of the Xv11 spec indicates that the
        values returned should be (values dst-x dst-y child same-screen-p).

  6.    For simplicity's sake, COPY-GC and COPY-GC-COMPONENTS should be combined
        into a single function:

        (defun copy-gc (src dst &rest keys)
          (declare (type gc src dst)
                   (type (or null (list gc-key)) keys)))

  7.    STORE-COLORS: How about adding, as a convenience feature, the ability to
        specify a color as a name here (as in STORE-COLOR)?

        (type (repeat-seq (integer pixel) ((or stringable color) color)) specs)

  8.    I suggest using another package name, rather than "XLIB" (how about
        "CLX"?). Otherwise, we risk adding unnecessarily to the confusion which
        already confounds discussions of the many bits and pieces of X (e.g.
        "Are you talking about the Lisp Xlib or the C Xlib?"). As with the
        language binding, this is just a matter of finding a name that says what
        is it is and doesn't say what it isn't.

  9.    Even though Xv11 allows a client to manipulate multiple displays, it's
        reasonable to expect that a large majority of clients will use only one
        display. However, several CLX functions require a display argument. This
        suggests the following binding changes to improve CLX programmer
        productivity.

        o Add a function to establish the default display:
                (defun set-default-display (display)
                  (declare (type display display)))

        o For every function/macro with a display argument, move the display
          argument from required to &key. Omitting the :display keyword argument
          specifies the default display.



EDITORIAL COMMENTS

  1.    LIST-PROPERTIES: The value returned should be (sequence xatom).

  2.    NEXT-EVENT: Comments still refer to "flush-p".



QUESTIONS

  1.    WITH-POINTER-GRABBED, WITH-KEYBOARD-GRABBED: How does the macro caller
        know if :success or :invalid-time was returned by the grab?

  2.    What are the other possible values of the :result-type argument? What
        is the effect of this argument?

  3.    ADD-ACCESS-HOSTS, et al.: How is the protocol argument intended to be used?

  4.    EVENT-QUEUE-LENGTH: Is this the same as EVENT-LISTEN, except for the
        value returned when the queue is empty? If so, it doesn't seem
        necessary.

  5.    QUEUE-EVENT-LOCALLY: What exactly is the meaning of the append-p
        argument?

  6.    NEXT-EVENT: What exactly is the meaning of the peek-p argument? What is
        the default value of the handler argument?



ISSUES

  1.    Change gc :cache argument to boolean: Yes.

  2.    Result of accessor for uncached gc: Signal an error.

  3.    Retain dash lists and clip rectangles: Yes.

* 4.    NEXT-EVENT vs. EVENT-CASE: Keep both. Some arguments in favor of
        NEXT-EVENT's handler function(s) are:

        o Some people will find it convenient and useful to modularize event
          handler functions in this way. For example, it might be useful to
          package up a "process a button press" function so it could be called
          in several places; this could be a way to implement event "aliases".
          EVENT-CASE doesn't prevent this kind of modularization, but it's clear
          that NEXT-EVENT is a better fit, stylistically.
        o Handler functions make it easier for a dialog controller to modify
          event processing in response to user input (by "swapping in" new
          handler functions).
        o Handler functions make it easier to implement "out-of-band" events (i.e.
          events that should be processed before and outside of the normal event
          handling loop).

        On the other hand, I think it is correct that many clients with
        relatively simple input processing will find EVENT-CASE preferable.

        I don't see a need to define event structures or functions that create them.

  5.    Allow (keyword var) specifier in EVENT-CASE clauses: Yes.

* 6.    Specify timeout for NEXT-EVENT and EVENT-CASE: Yes! Replace (type
        boolean hang-p) with (type (or null number) timeout), with the timeout
        value given in seconds.

  7.    Handling of many return values for WINDOW-ATTRIBUTES: I support the
        current solution. I think that, in the X world, the single-field accessor
        model is the "wrong" side!

  8.    defstruct vs. multiple-values for POINTER-POSITION, TEXT-EXTENTS:
        Multiple-values are OK in this case, because the information returned is
        inherently short-lived and doesn't deserve cons'ing. Retaining
        GLOBAL-POSITION-POINTER and TEXT-WIDTH as special cases is OK (perhaps
        these could simply be a reordering of the same return values). 

  9.    defstruct vs. multiple-values for KEYBOARD-CONTROL: The defstruct makes
        more sense because of the longer expected lifetime of the information.




∂30-Apr-87  0835	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: "GC"  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87  08:35:47 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 30 Apr 87 11:34-EDT
Date: Thu, 30 Apr 87 11:37 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: "GC"
To: Masinter.pa@Xerox.COM
cc: cl-windows@sail.stanford.edu
In-Reply-To: <870427-103123-4324@Xerox>
Message-ID: <870430113729.0.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: 27 Apr 87 10:29 PDT
    From: Masinter.pa@Xerox.COM

    I think that too many systems (and people) use "GC" as an abbreviation
    for "Garbage Collection" for it to be a standard abbrvation for
    "Graphics Context".

    Is there a chance of changing this?

The abbreviation "GC" is too embedded in Xspeak, and "graphics context"
is too much for verbal communication, to eliminate GC from the
vernacular.  However, it wouldn't bother me if "gc" were changed to
"gcontext" in function and type names.  Is there any support for this?
Would anyone seriously object to the change?

∂30-Apr-87  1130	primerd!doug@enx.prime.pdn 	GC means Garbage Collection
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87  11:30:21 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <AA23787@EDDIE.MIT.EDU>; Thu, 30 Apr 87 14:30:38 EDT
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
	id AA00860; Thu, 30 Apr 87 13:55:59 EDT
Message-Id: <8704301755.AA00860@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 30 Apr 87 13:30:40 EST
Subject: GC means Garbage Collection
To: cl-windows@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 30 Apr 87 13:30:40 EST

I agree that GC should be used for Garbage in the context of LISP.  
Gcontext is a much less ambiguous term.

Doug
(doug@enx.prime.com)

∂30-Apr-87  1231	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	[Masinter.pa@Xerox.COM: Re: CLX issues] 
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87  12:31:05 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 30 Apr 87 15:25-EDT
Date: Thu, 30 Apr 87 15:28 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: [Masinter.pa@Xerox.COM: Re: CLX issues]
To: cl-windows@sail.stanford.edu
Message-ID: <870430152824.1.RWS@KILLINGTON.LCS.MIT.EDU>

Date: 27 Apr 87 12:05 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: CLX issues

My vote is somewhere between
	3. Mostly good enough, but with the following problems (for which
	   I don't have a proposed solution)
	4. Beyond hope


The problems have to do with the confusion between graphics contexts and
windows, the apparently random assortment of window types and
permutations assigned by parameters rather than, say, window class, a
large number of poorly chosen (i.e., not self-descriptive) names.

I think most of my problems are with X rather than CLX, however, i.e.,
perhaps you've done the best you could.


[A footnote from me (RWS): I agree to a certain extent with the
criticism of names being poorly chosen.  When I first started fleshing
out the protocol design on paper, I tried to make it clear to "the
committee" that the names used in the drafts need not bear any
relationship to the names used in programming interfaces.  However, as I
should have expected, we never put any serious effort into naming in the
protocol, and the Xlib designers for better or worse simply picked up
the names and used them, and now there is clear opinion from several
quarters that the Lisp names have to match the C names, to facilitate
language roamers.]

∂30-Apr-87  1422	harris%hplwhh@hplabs.HP.COM 	Re: GC means Garbage Collection     
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87  14:20:32 PDT
Received: from hplms1 by hplabs.HP.COM with TCP ; Thu, 30 Apr 87 13:03:47 pdt
Received: from hplwhh (hplwhh) by hplms1; Thu, 30 Apr 87 13:03:22 pdt
Return-Path: <harris@hplwhh>
Received: from hplwhh.hpl.hp.com by hplwhh ; Thu, 30 Apr 87 13:03:05 pdt
Message-Id: <8704302003.AA00791@hplwhh>
To: cl-windows@sail.stanford.edu
Subject: Re: GC means Garbage Collection 
In-Reply-To: Your message of 30 Apr 87 13:30:40 -0500.
             <8704301755.AA00860@primerd.prime.com> 
Date: Thu, 30 Apr 87 13:02:58 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

I too agree that GC is confusing in the context of lisp.  Gcontext is
better, but how about GS for Graphics State, or GRAPHICS-CONTEXT (I
don't mind typing).

∂30-Apr-87  1606	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Comments on CLX proposal 
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87  16:06:19 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 30 Apr 87 19:04-EDT
Date: Thu, 30 Apr 87 19:07 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Comments on CLX proposal
To: Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2755711707-2350331@Sierra>
Message-ID: <870430190754.1.RWS@KILLINGTON.LCS.MIT.EDU>

[Thanks for the detailed response.]

    Date: Wed, 29 Apr 87  14:28:27 CDT
    From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>

	    o Productivity, Readability: Consistently use &key for all optional
	      arguments. The consistency promotes productivity, while the &key
	      syntax makes the meaning of the arguments clear. The overriding value
	      of maintainability should outweigh any objection to the "typeability"
	      of the &key syntax.

There is clearly mixed opinion on this issue, but there seems to be a slight
preference for having singletons be optional instead of keyword (hopefully
as embodied in the Draft Version 2).

	    o Productivity: When possible, make the function name identical to the
	      corresponding request name.

I will attempt another scan to identify differences, but if there are any in
particular you see, please point them out.

		    display                     Replace with server

Display is not only a recognized (e.g., by X3H3.6) term for this, but is also the
term used in the C interface (and one can imagine an implementation in which the
"server" isn't implemented as such), so I think this change would be inappropriate.

		    CONDITIONAL-WARP-POINTER    Replace with WARP-POINTER-IF-INSIDE
		    KILL-TEMPORARY-CLIENTS      Replace with KILL-TEMPORARY-RESOURCES

I have no objection to these.  Anyone object?

		    EVENT-LISTEN                Replace with EVENTS-RECEIVED

EVENT-LISTEN was chosen for its relationship to LISTEN on a stream, and as such
seems the more appropriate name.

		    NEXT-EVENT                  Replace with PROCESS-NEXT-EVENT

I would rather get rid of NEXT-EVENT altogether, but otherwise have no objection.

		    force-p                     Replace with force-output-p

Anyone object?

	    o Productivity: When good language usage demands that a function name
	      differ from its X request counterpart, adopt a name "transformation
	      rule" and apply it consistently. The current binding represents a
	      reasonable attempt at this (for example, "GetFoo" always becomes
	      "FOO"), but it suffers from inconsistency. The biggest problem occurs
	      with "SetFoo" which sometimes becomes (SETF FOO) and other times
	      becomes SET-FOO. Another example is the handling of the "ListFoo"
	      requests. Even in the touchy case of "SetFoo", I think the binding
	      would be improved by picking one rule and sticking to it everywhere. 

Perhaps you could give me some concrete suggestions for name changes.

	      Actually, it seems to me that the X request names themselves have some
	      problems in this area. For example, why are some things "ChangeFoo"
	      and other things "SetFoo"?

Well, as I pointed out in previous mail, not that much thought went into naming
in the specification...

    * 2.    A function to return an event to the head of the event queue is needed
	    (cp. XPutBackEvent in Xlib v10). This requirement comes from the need to
	    support a grammar-driven dialog controller. Is this what
	    QUEUE-EVENT-LOCALLY is supposed to do?

Yes, that is what the function does.

      3.    CREATE-WINDOW: parent, x, y, width, and height should probably be
	    required arguments (not &key). Alternatively, the defaults used for
	    these need to be specified.

I disagree, making them keyword rather than positional, but still requiring them
to be non-nil and not supplying defaults seems perfectly reasonable to me, and
promotes both readability and ease of use.

    * 4.    SEND-EVENT, et al.: A single SEND-EVENT function is preferable because
	    this allows a useful parameterization of the operation. For example, it
	    would be nice if a function could accept just any old window as an
	    argument and SEND-EVENT to it, without having to decide how to dispatch
	    to one of SEND-EVENT, SEND-EVENT-TO-POINTER-WINDOW, or
	    SEND-EVENT-TO-INPUT-FOCUS. I realize this introduces the technical
	    problem of defining a window id value for (INPUT-FOCUS-OF display),
	    etc., but this can be dealt with (can't it?).

SEND-EVENT takes a window, not a window-id, and hence implies a display.  If
this argument were allowed to be :input-focus or :pointer-window, then an
additional argument would be needed to specify the display.  The original
draft was like this, with display as an additional optional keyword argument,
required only for :input-focus and :pointer-window.  Is that better than
three separate functions?

      5.    TRANSLATE-COORDINATES: My copy of the Xv11 spec indicates that the
	    values returned should be (values dst-x dst-y child same-screen-p).

Hmm, missing type specifications, but good that you pointed it out.  My
intention was to return nil when same-screen-p was false, rather than returning
zeroes and the boolean.  Do you dislike that?

      6.    For simplicity's sake, COPY-GC and COPY-GC-COMPONENTS should be combined
	    into a single function:

	    (defun copy-gc (src dst &rest keys)
	      (declare (type gc src dst)
		       (type (or null (list gc-key)) keys)))

It was felt that having copy-gc copy everything when given no arguments was
counter-intuitive; by all rights it should copy nothing.  Having it reduce
to everthing would almost certainly lead to obscure errors when dealing with
adding/removing things from a rest arg before passing it on to copy-gc.

      7.    STORE-COLORS: How about adding, as a convenience feature, the ability to
	    specify a color as a name here (as in STORE-COLOR)?

	    (type (repeat-seq (integer pixel) ((or stringable color) color)) specs)

I don't particularly object, but what synchronization semantics should it have?
That is, should the function first do lookup-color's and then perform a single
store-colors, or can it break the request up into separate store-colors and
store-color requests?  Does it need to be defined?

      8.    I suggest using another package name, rather than "XLIB" (how about
	    "CLX"?). Otherwise, we risk adding unnecessarily to the confusion which
	    already confounds discussions of the many bits and pieces of X (e.g.
	    "Are you talking about the Lisp Xlib or the C Xlib?"). As with the
	    language binding, this is just a matter of finding a name that says what
	    is it is and doesn't say what it isn't.

I dislike "CLX", given that the "CL" part is both redundant and perhaps wrong (there
isn't that much CL about the interface that it couldn't mostly be used in other
dialects).  Just "X" is too short.  Any other suggestions?  Any other objections
to "XLIB"?

      9.    Even though Xv11 allows a client to manipulate multiple displays, it's
	    reasonable to expect that a large majority of clients will use only one
	    display. However, several CLX functions require a display argument. This
	    suggests the following binding changes to improve CLX programmer
	    productivity.

	    o Add a function to establish the default display:
		    (defun set-default-display (display)
		      (declare (type display display)))

	    o For every function/macro with a display argument, move the display
	      argument from required to &key. Omitting the :display keyword argument
	      specifies the default display.

The point of making resources be compound objects instead of just raw X-ids
was to avoid explicit mention of the display in most operations.  An explicit
display argument only shows up in infrequently used requests.  Complicating
the interface for their benefit is counterproductive.  I should also point
out that the C Xlib has switched over as well from the notion of a current
display to making it required in every call.


    QUESTIONS

      1.    WITH-POINTER-GRABBED, WITH-KEYBOARD-GRABBED: How does the macro caller
	    know if :success or :invalid-time was returned by the grab?

It doesn't, except by setting some flag in the body.  I think this is acceptable,
since in most cases either :invalid-time cannot occur, or not executing the body
is sufficient.

      2.    What are the other possible values of the :result-type argument? What
	    is the effect of this argument?

The result-type is used in the (effective) call to make-sequence, and is whatever
is acceptable to make-sequence.

      3.    ADD-ACCESS-HOSTS, et al.: How is the protocol argument intended to be used?

This was changed in Draft Version 2.  Host objects alone are passed, and it is
unspecified how protocol and address are extracted.

      4.    EVENT-QUEUE-LENGTH: Is this the same as EVENT-LISTEN, except for the
	    value returned when the queue is empty? If so, it doesn't seem
	    necessary.

Correct, EVENT-LISTEN at one pointer returned a boolean rather than an integer.
EVENT-QUEUE-LENGTH should be flushed.

      5.    QUEUE-EVENT-LOCALLY: What exactly is the meaning of the append-p
	    argument?

T means to put the event at the tail of the queue, NIL means to put the
event at the head of the queue.

      6.    NEXT-EVENT: What exactly is the meaning of the peek-p argument? What is
	    the default value of the handler argument?

T for peek-p means the event (for which the handler returns non-nil) is not removed
from the queue (it is left in place), NIL means the event is removed.

∂01-May-87  0537	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: CLX issues 
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87  05:37:03 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 May 87 08:35-EDT
Date: Fri, 1 May 87 08:38 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: CLX issues
To: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2755611781-3175100@SI>
Message-ID: <870501083851.8.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Tue, 28 Apr 87  09:43:01 MDT
    From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>

						It would be nice if an [GC]
       accessor could get the value over the network, but there's no request
       for doing this (is there?).

No, there isn't.

				    Its not clear to me why someone would
       turn the cache off - there's not that much overhead involved.

In order to have a gcontext shared by clients in different address spaces,
with loose coupling.  Either there has to be a way to turn off the cache,
or else a way to back-door update the cache without causing the change to
propagate to the server.  The former seems both simpler and preferable.

∂01-May-87  0628	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	attribute/geometry one more time   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87  06:28:02 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 May 87 09:26-EDT
Date: Fri, 1 May 87 09:30 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: attribute/geometry one more time
To: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <12298000370.69.ACUFF@SUMEX-AIM.STANFORD.EDU>
Message-ID: <870501093002.9.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Mon, 27 Apr 87 20:33:40 PDT
    From: Richard Acuff <Acuff@SUMEX-AIM.STANFORD.EDU>

       I can't claim great familiarity with CLX, but I believe that I agree
    strongly with Moon's proposed single function accessors.  Is there any
    reason that a wrapper macro couldn't be used to address batching and
    synchronization issues?

    Date: Tue, 28 Apr 87  09:43:01 MDT
    From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>

    7. The current solution for window-attributes drawable-geometry and
       keyboard-control is "good enough", but I would prefer a wrapper
       macro around accessor macros.  The accessor macros can be made to
       generate compile-time errors saying they're not inside the wrapper,
       so there's no chance for error.

I had also come around to the wrapper notion immediately after sending
out my issues&votes message, and have been discussing it with Moon.
Here is the idea; there are still details to work out.  [If someone
proposed this a while back, I guess I just didn't understand it at
the time.]

There are individual accessors and setfs (as appropriate) for window
attributes and drawable geometries.  There are no scope restrictions
on their use [I think this is very important], and in the normal case
there is no implied caching or batching of calls.  In addition, there
needs to be some way to control caching/batching.  There are four issues:
	1. caching attributes for accessors
	2. caching geometry for accessors
	3. batching attribute changes from setfs
	4. batching geometry changes from setfs

One could attempt to provide independent wrappers for these, but perhaps
a single wrapper is simpler and sufficient:
	(with-cached-state (d) body)
where d is a drawable (window or pixmap).  The meaning is roughly that
within the dynamic scope: all attributes for d are cached at the
execution of the first attribute accessor on d; all geometries for d are
cached at the execution of the first geometry accessor on d; the caches
are used for all subsequent accessors; all attribute and geometry setfs
on d are retained for a batched update on exit.

There are a several questions to be answered.

1. Should this caching/batching be per-process or global?
2. Is the result of a setf visible to a subsequent accessor?  If so,
   does the accessor cause all previous setfs to be forced out to
   the server?  If so, should another full geometry/attribute read
   be performed before the accessor completes (since some setfs may
   simply turn into advisory events at the server, rather than being
   executed)?
3. If with-cached-state forms are nested, and specify the same d,
   does the cache carry across, or is the cache invalidated and
   reloaded on demand both on entry and exit from the nested form?
4. Are the issues related to batching of setfs sufficiently complex
   that it would be simpler to retain change-window-attributes and
   configure-window in addition to individual setfs, and have the
   wrapper form only cause a read-cache for accessors (that wasn't
   affected by setfs)?

If details can be worked out to satisfaction, this seems like a
better approach than the current structure/multipe-value mixture.

∂01-May-87  0747	DLW@ALDERAAN.SCRC.Symbolics.COM 	Comments on CLX proposal   
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 1 May 87  07:46:58 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 77145; Fri 1-May-87 10:22:48 EDT
Date: Fri, 1 May 87 10:23 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Comments on CLX proposal
To: RWS@ZERMATT.LCS.MIT.EDU, Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870430190754.1.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870501102330.7.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Thu, 30 Apr 87 19:07 EDT
    From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>

	  8.    I suggest using another package name, rather than "XLIB" (how about
		"CLX"?). Otherwise, we risk adding unnecessarily to the confusion which
		already confounds discussions of the many bits and pieces of X (e.g.
		"Are you talking about the Lisp Xlib or the C Xlib?"). As with the
		language binding, this is just a matter of finding a name that says what
		is it is and doesn't say what it isn't.

    I dislike "CLX", given that the "CL" part is both redundant and perhaps wrong (there
    isn't that much CL about the interface that it couldn't mostly be used in other
    dialects).  Just "X" is too short.  Any other suggestions?  Any other objections
    to "XLIB"?

I think "XLIB" is a good choice.  It's true that there could be confusion
between the Lisp XLIB and the C XLib.  But I think this is outweighed by the
benefits of making it clear that both of these things are instances of the
same level of abstraction and modularity.  In other words, there really IS a
Lisp one and a C one, and the naming should reflect that reality in order to
make clear the relationship between the two.

∂01-May-87  1305	Moon@STONY-BROOK.SCRC.Symbolics.COM 	attribute/geometry one more time 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 May 87  13:05:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 129679; Fri 1-May-87 16:05:08 EDT
Date: Fri, 1 May 87 16:04 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: attribute/geometry one more time
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870501093002.9.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870501160458.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 1 May 87 09:30 EDT
    From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>

	    (with-cached-state (d) body)

    There are several questions to be answered.

Here are my personal opinions.

If this thing is truly for synchronization, not just for caching,
I think the name should be changed.  Perhaps with-copied-state
or with-local-copy would be better.  Someone can probably think
of a better name than those.

    1. Should this caching/batching be per-process or global?

with-xxx things are just about always per-process.

    2. Is the result of a setf visible to a subsequent accessor?  If so,
       does the accessor cause all previous setfs to be forced out to
       the server?  If so, should another full geometry/attribute read
       be performed before the accessor completes (since some setfs may
       simply turn into advisory events at the server, rather than being
       executed)?

This is a toughy.  The criterion should be that accessors and setfs
behave consistently, regardless of whether they are inside a
with-cached-state.  So here's what I think:

The caching/batching is for sequences of only reads or only writes.  Any
transition between reading and writing is like exiting the wrapper form
and entering it again.  Thus the first read in a sequence forces batched
changes then fetches the state from the server and caches it.  The first
write in a sequence invalidates this cache and starts batching changes. 
Exiting a with-cached-state forces batched changes.

Thus the answers to your questions would be yes, yes, and yes.

    3. If with-cached-state forms are nested, and specify the same d,
       does the cache carry across, or is the cache invalidated and
       reloaded on demand both on entry and exit from the nested form?

For reads, it is invisible whether the cache is carried across or
invalidated and reloaded.  I don't think it matters which you do.  For
writes, the batched changes should be sent to the server when any
with-cached-state is exited, even nested ones.

    4. Are the issues related to batching of setfs sufficiently complex
       that it would be simpler to retain change-window-attributes and
       configure-window in addition to individual setfs, and have the
       wrapper form only cause a read-cache for accessors (that wasn't
       affected by setfs)?

I don't think the issues are so complex if you think of
  (with-cached-state (d)
    (setf (drawable-x d) a)
    (setf (drawable-y d) b))
and
  (configure-window d :x a :y b)
as two equivalent syntaxes for the same thing.  (I'm sure I have made
programming errors here, ignore them).  The complex issues are more for
implementors than for callers, so I wouldn't say they are much of a
problem.

∂01-May-87  1705	Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET 	Re: Comments on CLX proposal 
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 1 May 87  17:05:25 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac07948; 1 May 87 19:45 EDT
Received: from ti-csl by RELAY.CS.NET id ao23636; 1 May 87 19:38 EDT
Received: from dsg (juliett.ARPA) by tilde id AA04567; Fri, 1 May 87 17:25:51 cdt
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Fri, 1 May 87  15:14:08 CDT
Message-Id: <2755886529-12853913@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Fri, 1 May 87  15:02:09 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: Comments on CLX proposal
In-Reply-To: Msg of Thu, 30 Apr 87 19:07 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>


	>    o Productivity: When good language usage demands that a function name
	>      differ from its X request counterpart, adopt a name "transformation
	>      rule" and apply it consistently. The current binding represents a
	>      reasonable attempt at this (for example, "GetFoo" always becomes
	>      "FOO"), but it suffers from inconsistency. The biggest problem occurs
	>      with "SetFoo" which sometimes becomes (SETF FOO) and other times
	>      becomes SET-FOO. Another example is the handling of the "ListFoo"
	>      requests. Even in the touchy case of "SetFoo", I think the binding
	>      would be improved by picking one rule and sticking to it everywhere. 
	>
	>Perhaps you could give me some concrete suggestions for name changes.

I suggest the following transformation rules.

  1. ChangeFoo and SetFoo --> change-foo. An alternative would be to adopt
     consistently the defsetf form. However, I think the setf/accessor model is
     wrong for client operations on a (remote) server database. The specific
     changes would be:

	ChangeAccessControl: change-access-control (replaces defsetf)
	ChangeCloseDownMode: change-close-down-mode (replaces defsetf)
	SetFontPath        : change-font-path (replaces defsetf)
	SetInputFocus      : change-input-focus (replaces set-input-focus)
	SetKeyboardMapping : change-keyboard-mapping (replaces defsetf)
	SetPointerMapping  : change-pointer-mapping (replaces defsetf)
	SetScreenSaver     : change-screen-saver (replaces set-screen-saver)
	SetSelectionOwner  : change-selection-owner (replaces set-selection-owner)

  2. ListFoo --> foo.  An alternative would be list-foo, but the term "list" is
     too suggestive (?!) in a Lisp binding; in fact, each of these functions is
     capable of returning a list or not, depending on the :result-type
     argument. The specific changes would be:

	ListExtensions	   : extensions (replaces list-extensions)
	ListFontsWithInfo  : fonts-with-info (replaces list-fonts-with-info)
	ListFonts	   : fonts (replaces list-fonts)
	ListProperties	   : properties (replaces list-properties)

hat could use improvement is QUEUE-EVENT-LOCALLY, since "locally"
is superfluous and the name doesn't suggest "add an event at either end of the
queue". But this isn't easy to do! Some possibilities are: put-event-queue,
enqueue-event, queue-event.





	>    * 4.   SEND-EVENT, et al.: A single SEND-EVENT function is
        >           preferable because this allows a useful parameterization of
        >           the operation. For example, it would be nice if a function
        >           could accept just any old window as an argument and
        >           SEND-EVENT to it, without having to decide how to dispatch
        >           to one of SEND-EVENT, SEND-EVENT-TO-POINTER-WINDOW, or
        >           SEND-EVENT-TO-INPUT-FOCUS.  I realize this introduces the
        >           technical problem of defining a window id value for
        >           (INPUT-FOCUS-OF display), etc., but this can be dealt with
        >           (can't it?).
        >
	>SEND-EVENT takes a window, not a window-id, and hence implies a display.  If
	>this argument were allowed to be :input-focus or :pointer-window, then an
	>additional argument would be needed to specify the display.  The original
	>draft was like this, with display as an additional optional keyword argument,
	>required only for :input-focus and :pointer-window.  Is that better than
	>three separate functions?

Not really, since this still doesn't support the parameterization described
above. How about, instead, changing the type of window-id to be (or integer
:input-focus :pointer-window)? This would allow a window object representing
"the input focus of display A" to be built and used just like any other. The
send-event function would be responsible for detecting this kind of window and
building the appropriate request.


	>5.    TRANSLATE-COORDINATES: My copy of the Xv11 spec indicates that the
	>      values returned should be (values dst-x dst-y child
	>      same-screen-p).
	>
	>Hmm, missing type specifications, but good that you pointed it out.  My
	>intention was to return nil when same-screen-p was false, rather than
	>returning zeroes and the boolean.  Do you dislike that?

No, sounds OK to me.


	>7.    STORE-COLORS: How about adding, as a convenience feature, the ability to
	>      specify a color as a name here (as in STORE-COLOR)?
	>
	>I don't particularly object, but what synchronization semantics should it have?
	>That is, should the function first do lookup-color's and then perform a single
	>store-colors, or can it break the request up into separate store-colors and
	>store-color requests?  Does it need to be defined?

I presume that RGB names will be things like "red" and "burnt-siena" and not
things like "background-color" (the latter sort ought to be identified by pixel
values, not RGB's).  Thus, since the RGB associated with a name can be expected
to change very slowly or not at all, synchronization should not be a critical
issue. I think either of the implementation techniques you describe could be
used, and that the semantics of store-colors need not be defined to preclude
either one.



	>8.    I suggest using another package name, rather than "XLIB" (how about
	>      "CLX"?). Otherwise, we risk adding unnecessarily to the confusion
	>      which already confounds discussions of the many bits and pieces of
	>      X (e.g. "Are you talking about the Lisp Xlib or the C Xlib?"). As
	>      with the language binding, this is just a matter of finding a name
	>      that says what is it is and doesn't say what it isn't.
	>
	>I dislike "CLX", given that the "CL" part is both redundant and perhaps wrong (there
	>isn't that much CL about the interface that it couldn't mostly be used in other
	>dialects).  Just "X" is too short.  Any other suggestions?

How about XLISP? LIX (Lisp Interface to X)? CLIX (C*mm*n Lisp Interface to X)?



	>9.    Even though Xv11 allows a client to manipulate multiple displays, it's
	>      reasonable to expect that a large majority of clients will use only one
	>      display. However, several CLX functions require a display argument. This
	>      suggests the following binding changes to improve CLX programmer
	>      productivity.
	>
	>      o Add a function to establish the default display:
	>      (defun set-default-display (display)
	>      (declare (type display display)))
	>
	>      o For every function/macro with a display argument, move the display
	>      argument from required to &key. Omitting the :display keyword argument
	>      specifies the default display.
	>
	>The point of making resources be compound objects instead of just raw X-ids
	>was to avoid explicit mention of the display in most operations.  An explicit
	>display argument only shows up in infrequently used requests.  Complicating
	>the interface for their benefit is counterproductive.  I should also point
	>out that the C Xlib has switched over as well from the notion of a current
	>display to making it required in every call.

To me, the optional :display argument looks like a net simplification.  It is
certainly simpler for one-display clients (the 80% case), while for n-display
clients, (foo :display A) is not appreciably more complex than (foo A).  The
chief argument in favor of this approach has nothing to do with "typeability".
Rather, the idea is to increase programmer productivity by relieving him from
having to know which functions require a display argument and which don't in the
case where he shouldn't have to repeatedly identify the display anyway.  I
imagine Xlib wanted to avoid a modal specification of "the current display",
since this can cause difficulties for a n-display client.  However, unlike Xlib,
we can get away with this without having to go strictly modal; implicit
references to the default display could be freely intermixed with explicit
display references.



	>1.    WITH-POINTER-GRABBED, WITH-KEYBOARD-GRABBED: How does the macro caller
	>      know if :success or :invalid-time was returned by the grab?
	>
	>It doesn't, except by setting some flag in the body.  I think this is acceptable,
	>since in most cases either :invalid-time cannot occur, or not executing the body
	>is sufficient.

But if the caller expects that :invalid-time cannot occur and it *DOES* occur,
then this is bug which should not go undetected. Also, the body can have
arbitrary side-effects:

	(with-pointer-grabbed
		(delete-file "foo"))

	(create-file "foo")

so it can be important to know whether the body was executed or not. I would
prefer to see these macros return a simple boolean or :success/:invalid-time.

∂01-May-87  2109	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Comments on CLX proposal
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 May 87  21:09:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 130105; Sat 2-May-87 00:09:40 EDT
Date: Sat, 2 May 87 00:09 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Comments on CLX proposal
To: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
cc: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2755886529-12853913@Sierra>
Message-ID: <870502000912.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

Frankly, most of your proposed improvements sound to me like
disimprovements that would make the interface more confusing for
programmers and harder to use.  I suppose what this shows is that it is
all a matter of taste, but I wonder how other members of the cl-windows
mailing list feel.

∂02-May-87  0808	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	NIL in CLX
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87  08:08:27 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 2 May 87 11:06-EDT
Date: Sat, 2 May 87 11:10 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: NIL in CLX
To: cl-windows@sail.stanford.edu
Message-ID: <870502111031.8.RWS@KILLINGTON.LCS.MIT.EDU>

A few people have said they would prefer the gcontext accessors to
signal an error rather than return the "wrong" value.  After I thought
about this, I finally realized what was meant.  The original plan I had
for gcontext components was that NIL was never a legal value.  This is
true of everything but (I see now) the clip-mask, for which an empty
sequence is legal (if unusual, since it effectively disables all
graphics output, which is different from :none, which is a full-drawable
clip).  [An empty dashes sequence is not legal.]  My intent was that
accessors would return NIL to indicate "unknown", rather than
signalling, because checking for NIL seems more convenient than handling
signals.

Note that even if a gcontext has caching enabled, it won't always be
possible for the accessors to return a correct value.  This is true of
the default tile, stipple, and font values (I suppose :default could be
returned, but I don't really think setf should accept :default), but
also any copying from an uncached to a cached gc will "infect"
components of the cached gc with unknown values.

Related to this is the fact that I have defined create-window,
create-gc, and with-gc (and others) so that passing a keyword argument
as NIL is the same as not passing it.  That is, NIL means "ignore me".
I thought this was important for create-window and create-gc, because I
have been burned by wanting to provide a function at a higher level that
accepts some or all of the same keyword arguments, and then pass them
down; either you have to propagate knowledge of default values, or you
have to use a rest argument or some other hackery.  Making a few values
:on, :off, and :none seemed worth it to preserve NIL as an ignore value.

I would like to hear comments on all of this.  Is it useful to retain
NIL as "ignore" and "unknown"?  The void clip-mask is the only conflict
that I can see.  If these uses of NIL are removed, then all instances of
:none could be changed to NIL except in clip-mask, and all instances of
(member :on :off) could be changed to boolean, and presumably gcontext
accessors would be defined to signal for unknown components.

∂04-May-87  1218	Oren%Tilde%ti-csl.csnet@RELAY.CS.NET 	Re: NIL in CLX   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 4 May 87  12:18:14 PDT
Received: from relay2.cs.net by RELAY.CS.NET id af26489; 4 May 87 12:52 EDT
Received: from ti-csl by RELAY.CS.NET id ac08987; 4 May 87 12:47 EDT
Received: from SI (si.ARPA) by tilde id AA11314; Mon, 4 May 87 11:07:28 cdt
Message-Id: <2756131580-3224533@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Mon, 4 May 87  11:06:20 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: NIL in CLX
In-Reply-To: Msg of Sat, 2 May 87 11:10 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>

>  I have been burned by wanting to provide a function at a higher level that
>  accepts some or all of the same keyword arguments, and then pass them
>  down; either you have to propagate knowledge of default values, or you
>  have to use a rest argument or some other hackery.  Making a few values
>  :on, :off, and :none seemed worth it to preserve NIL as an ignore value.

I agree that there needs to be some way of passing a value that says
"use the default".

>  I would like to hear comments on all of this.  Is it useful to retain
>  NIL as "ignore" and "unknown"?

Yes.
I'm used to thinking of NIL as false or the empty-list.  However, if CLX
consistently uses nil for "ignore" and "unknown", its OK with me.  Doing
this is probably better than using a :DEFAULT keyword everywhere.

  LaMott

∂04-May-87  1819	Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET 	Re: NIL in CLX
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 4 May 87  18:19:04 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa01432; 4 May 87 21:02 EDT
Received: from ti-csl by RELAY.CS.NET id aw11524; 4 May 87 20:54 EDT
Received: from dsg (juliett.ARPA) by tilde id AA19317; Mon, 4 May 87 15:53:07 cdt
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 4 May 87  11:08:33 CDT
Message-Id: <2756138629-529754@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Mon, 4 May 87  13:03:49 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: NIL in CLX

Your idea of using NIL as the "ignore" or "use the default" value for
keyword arguments is a good one. Also, your observation about the
potential for "infection" of cached gcontexts has persuaded me that it's
proper for accessors to return NIL rather than signal an error.

∂04-May-87  1820	Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET 	Re: attribute/geometry one more time   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 4 May 87  18:20:18 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ad01432; 4 May 87 21:02 EDT
Received: from ti-csl by RELAY.CS.NET id ba11524; 4 May 87 20:55 EDT
Received: from dsg (juliett.ARPA) by tilde id AA19710; Mon, 4 May 87 16:01:26 cdt
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 4 May 87  13:54:14 CDT
Message-Id: <2756141652-711382@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Mon, 4 May 87  13:54:12 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: attribute/geometry one more time

Well, every time it comes around, it gets better!  The latest notion
(i.e.  setf/accessors, no implied caching or batching, with-xxx wrapper
macro), *plus* the issue resolutions suggested by Moon (i.e.
write-/read-only caching/batching, per process) sounds good to me.  I
can support this proposal because it satisfies one of my main concerns:
that the interface should not try to distort the Xreality of separate
client/server address spaces and network requests.

In fact, assuming the semantics proposed by Moon, there is a very close
correspondence (I think it will typically be one-to-one) between a
with-xxx wrapper call and an X request. This suggests that a good name
for the wrapper might be something like "with-single-request". Perhaps a
more accurate name would be "with-minimum-requests".

∂05-May-87  1223	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: Comments on CLX proposal  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 May 87  12:22:56 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 5 May 87 15:20-EDT
Date: Tue, 5 May 87 15:22 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: Comments on CLX proposal
To: Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2755886529-12853913@Sierra>
Message-ID: <870505152206.0.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Fri, 1 May 87  15:02:09 CDT
    From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>

						 I think the setf/accessor model is
	 wrong for client operations on a (remote) server database. The specific
	 changes would be:

	    ChangeAccessControl: change-access-control (replaces defsetf)
	    ChangeCloseDownMode: change-close-down-mode (replaces defsetf)
	    SetFontPath        : change-font-path (replaces defsetf)
	    SetKeyboardMapping : change-keyboard-mapping (replaces defsetf)
	    SetPointerMapping  : change-pointer-mapping (replaces defsetf)

The general opinion seems to be that the accessor/setf model is preferable overall,
so I would rather not change these.

	    SetInputFocus      : change-input-focus (replaces set-input-focus)
	    SetScreenSaver     : change-screen-saver (replaces set-screen-saver)

The only reason these aren't setfs is that CL doesn't support multiple values.
The bug is with CL, and I would rather leave the names "set-".  The "change-"
names are intended to convey that it is not a wholesale replacement of contents.

	    SetSelectionOwner  : change-selection-owner (replaces set-selection-owner)

This one can in fact be recast as a setf:

(defun set-selection-owner (display selection owner &optional time))
=>
(defsetf selection-owner (display selection &optional time) (owner))

and I guess I would prefer that, if there are no objections.

	    ListExtensions	   : extensions (replaces list-extensions)
	    ListFontsWithInfo  : fonts-with-info (replaces list-fonts-with-info)
	    ListFonts	   : fonts (replaces list-fonts)
	    ListProperties	   : properties (replaces list-properties)

I don't know what to do here.  Some argue the names should match the protocol,
others argue the names should match the C Xlib, others argue the names should
make sense.  I don't care, as long as everyone is happy, which is unlikely.
For comparison, the C Xlib names are XListExtensions, XFontNamesWithInfo,
XFontNames, and XListProperties.

    hat could use improvement is QUEUE-EVENT-LOCALLY, since "locally"
    is superfluous and the name doesn't suggest "add an event at either end of the
    queue". But this isn't easy to do! Some possibilities are: put-event-queue,
    enqueue-event, queue-event.

Happy to drop the -LOCALLY.


	SEND-EVENT ...

	   How about, instead, changing the type of window-id to be (or integer
    :input-focus :pointer-window)? This would allow a window object representing
    "the input focus of display A" to be built and used just like any other. The
    send-event function would be responsible for detecting this kind of window and
    building the appropriate request.

:input-focus and :pointer-window aren't reasonable anywhere outside of SEND-EVENT.
It would be unacceptable to have to check for this elsewhere.  It seems to me
the only possible changes are to 1) allow a keyword as the window and require
an additional display argument in that case or 2) allow some funny object (like
a list containing a keyword and a display) in the window position.  I guess I
like 1) better than 2), but I have no strong feelings about 1) versus the current
three functions.

	STORE-COLORS ...

			 Thus, since the RGB associated with a name can be expected
    to change very slowly or not at all, synchronization should not be a critical
    issue.

The synchronization is not with the RGB for "aqua" changing, but with whether the
colormap got changed in one or multiple steps (which can cause visual glitches).

	   I think either of the implementation techniques you describe could be
    used, and that the semantics of store-colors need not be defined to preclude
    either one.

I guess that is fine with me, since it is an extension of the fundamental interface.

    How about XLISP? LIX (Lisp Interface to X)? CLIX (C*mm*n Lisp Interface to X)?

I think XLIB is just fine.

    To me, the optional :display argument looks like a net simplification.  It is
    certainly simpler for one-display clients (the 80% case), while for n-display
    clients, (foo :display A) is not appreciably more complex than (foo A).  The
    chief argument in favor of this approach has nothing to do with "typeability".
    Rather, the idea is to increase programmer productivity by relieving him from
    having to know which functions require a display argument and which don't in the
    case where he shouldn't have to repeatedly identify the display anyway.

I will rephrase my previous statement, that the functions making up perhaps 90% of
all syntactic calls don't take a display argument anyway; complicating the interface
for the other functions just doesn't seem worth it.  If you argued about defaulting
the window or gcontext argument, that would then cover more interesting territory,
but again I would argue against it.

	WITH-<DEVICE>-GRABBED ...

    But if the caller expects that :invalid-time cannot occur and it *DOES* occur,
    then this is bug which should not go undetected. Also, the body can have
    arbitrary side-effects:

	    (with-pointer-grabbed
		    (delete-file "foo"))

	    (create-file "foo")

    so it can be important to know whether the body was executed or not. I would
    prefer to see these macros return a simple boolean or :success/:invalid-time.

Not returning what the body returns seems like a very bad idea.  If there isn't
sufficient consensus, these two macros could just be eliminated, since they are
merely unwind-protect convenience (plus periodic but unspecified retry, which
might be either a reason to keep or eliminate them, depending on your point of
view).

∂05-May-87  1255	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: NIL in CLX 
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 May 87  12:55:18 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 5 May 87 15:52-EDT
Date: Tue, 5 May 87 15:54 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: NIL in CLX
To: Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2756138629-529754@Sierra>
Message-ID: <870505155411.5.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Mon, 4 May 87  13:03:49 CDT
    From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>

    Your idea of using NIL as the "ignore" or "use the default" value for
    keyword arguments is a good one. Also, your observation about the
    potential for "infection" of cached gcontexts has persuaded me that it's
    proper for accessors to return NIL rather than signal an error.

There is still the problem of what to do with the empty sequence as a
valid clip-mask, which as a list is NIL, which isn't "ignore" or
"default".  Do we just special case this one thing with an svar in
CREATE-GC and WITH-GC?

∂06-May-87  0911	Oren%Tilde%ti-csl.csnet@RELAY.CS.NET 	Re: NIL in CLX   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 May 87  09:10:57 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac13750; 6 May 87 12:01 EDT
Received: from ti-csl by RELAY.CS.NET id an22650; 6 May 87 11:54 EDT
Received: from SI (si.ARPA) by tilde id AA10121; Wed, 6 May 87 09:09:37 cdt
Message-Id: <2756297339-9696988@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Wed, 6 May 87  09:08:59 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: NIL in CLX
In-Reply-To: Msg of Tue, 5 May 87 15:32 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>

>  Date: Tue, 5 May 87 15:32 EDT
>  From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
>
>  This hasn't answered the question of what to do about NIL as a valid clip-mask.

A NIL clip-mask doesn't seem very interesting or useful, so I would not
make it easy to get.  I would do:
  (declare (type (or null (member :none :disable-graphics) pixmap rect-seq) clip-mask)

If someone REALLY wants to use a null clipping rectangle list, let them do:
  (change-gc gc :clip-mask (or clipping-rectangles :disable-graphics))

I think this is better than violating the "Nil is ignore" convention.
Using a "svar" for clip-mask would make it too easy to accidently set a
null clipping rectangle list.

  -LaMott

P.S. Perhaps you can think of a better keyword than :disable-graphics

∂06-May-87  0916	Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET 	send-event: one function or three?
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 May 87  09:16:32 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac13790; 6 May 87 12:06 EDT
Received: from ti-csl by RELAY.CS.NET id ay22650; 6 May 87 12:01 EDT
Received: from dsg (juliett.ARPA) by tilde id AA13011; Wed, 6 May 87 10:38:35 cdt
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 6 May 87  10:38:41 CDT
Message-Id: <2756302713-4357676@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Wed, 6 May 87  10:38:33 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: send-event: one function or three?

I've thought about this some more and no longer have any objections to
the following one-function interface.

(defun send-event (window event-key event-mask &rest args
		   &key display propagate-p &allow-other-keys)
  (declare (type window (or window :input-focus :pointer-window))
	   (type event-key event-key)
	   (type event-mask event-mask)
	   (type display (or null display))
	   (type boolean propagate-p)))

I can see the rationale for the three-function interface, in terms
of tidying up the argument lists. But, I feel that the one-function
interface has the important advantage of uniformity -- a function can
send events to any destination without special casing or extra
dispatching logic.

∂06-May-87  1205	unido!gmdzi!LISPM-2.GMD!@lispm-1.gmd.hws 	Info about CLX and X   
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 6 May 87  12:05:37 PDT
Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP 
	id AA13570; Wed, 6 May 87 15:04:16 EDT
Received: by unido.uucp with uucp; 
	  Wed, 6 May 87 15:50:49 +0100
Received: by gmdzi.UUCP id AA03055; Wed, 6 May 87 10:46:02 -0100
Received: from LISPM-2.GMD by LISPM-1.GMD via CHAOS with CHAOS-MAIL id 1454; Wed 6-May-87 10:44:08-CET
Date: Wed, 6 May 87 10:44 CET
From: "Heinz W. Schmidt" <unido!gmdzi!LISPM-2!hws@seismo.CSS.GOV>
Subject: Info about CLX and X
To: gmdzi!LISPM-1!cl-windows@seismo.CSS.GOV
Cc: gmdzi!LISPM-2!hws@seismo.CSS.GOV
In-Reply-To: <870415113622.1.RWS@KILLINGTON.LCS.MIT.EDU>
Message-Id: <870506104407.5.HWS@LISPM-2.GMD>

Please tell me how I can get info about CLX.

I've followed the postings in this group for some days but need
more complete info to follow up. In particular:
 Is there a specification/documentation available for CLX?
 Does CLX interface to X10 or X11?
 How is CLX related to SUN NeWS? (And what is the state of NeWS development?).

We have SUN3s (LUCID CL 2 is available but X not yet) and SYMBOLICS' (Rel 7) and
work with an own simple interface to windows/menus/mouse (written in CL and
FLAVORS) for improving portability of our CL code.
The SUN CL is available only since a few days now and we are starting to implement
this interface on SUN's. Does anybody out there have experience with 
developing LISP programs on SYMBOLICS (and maybe SUN) which use windows and should
be *portable* to SUNs?

∂06-May-87  1329	dcmartin@postgres 	Re: Info about CLX and X  
Received: from [128.32.149.1] by SAIL.STANFORD.EDU with TCP; 6 May 87  13:29:21 PDT
Received: by postgres (3.2/1.22)
	id AA02816; Wed, 6 May 87 13:27:58 PDT
Message-Id: <8705062027.AA02816@postgres>
From: David C. Martin <dcmartin@postgres>
Office: 440 Evans - x2-9585
Home: 2441 Haste St #37, Berkeley, CA 94704 - (415) 843-6470
Fortran: is not backward, NARTROF is backwards.
To: "Heinz W. Schmidt" <unido!gmdzi!LISPM-2!hws@seismo.css.gov>
Cc: cl-windows@sail.stanford.edu
Precedence: special-delivery 
In-Reply-To: Your message of Wed, 6 May 87 10:44 CET 
	<870506104407.5.HWS@LISPM-2.GMD> 
Subject: Re: Info about CLX and X 
Date: Wed, 06 May 87 13:27:56 PDT
Sender: dcmartin@postgres

I don't think this will reach you Heinz, so I am sending it to the whole list.

I have a package called XCL which provides the X version 10 C language 
X library functions w/ some extensions in Common LISP.  It currently runs
on ExCL from Franz, Inc and Kyoto Common LISP - I have not yet gotten a Lucid
port done, but it shouldn't be too hard (I have the documentation to do it, 
just haven't gotten around to it).

The code contains support for everything in the C language library w/ the
exception of color and resource id -> user data structures.  It is available
by public ftp from ingres.Berkeley.EDU in ~ftp/bool/xcl (including 
documentation and demos).  If you can't get to the Internet, then a tape can
be sent (although we haven't yet done it, it can be done.. I think it would
cost about $100).

Hope this helps.

dcm

∂08-May-87  0611	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	change-pointer-control rational argument
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 May 87  06:11:45 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 8 May 87 08:36-EDT
Date: Fri, 8 May 87 08:38 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: change-pointer-control rational argument
To: cl-windows@sail.stanford.edu
Message-ID: <870508083829.1.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Thu, 7 May 87  12:08:50 CDT
    From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
    
    change-pointer-control declares the acceleration parameter to be:
       (type (or null (member :default) rational) 
    
    I think it would be better to make this 
       (type (or null (member :default) number) 
    
    and have change-pointer-control rationalize it if a float is passed in.

Seems rational to me.

∂08-May-87  1258	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	setf'ing device mappings 
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 May 87  12:58:34 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 8 May 87 15:55-EDT
Date: Fri, 8 May 87 15:57 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: setf'ing device mappings
To: cl-windows@sail.stanford.edu
In-Reply-To: <2756388727-15187199@SI>
Message-ID: <870508155730.3.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Thu, 7 May 87  10:32:07 CDT
    From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>

    CLX defines the following:

    (defsetf keyboard-mapping (display) (map)
      (declare (type display display)
	       (type (sequence integer) map)))

    (defsetf pointer-mapping (display) (map)
      (declare (type display display)
	       (type (sequence integer) map)))

    Its traditional for SETF to return the value that's passed in.  However,
    the X requests SetKeyboardMapping and SetPointerMapping both return a
    status (member :success :busy).  Do you expect CLX to wait and retry,
    and/or signal an error when :busy status is returned, or does SETF
    return the status?

I intended that the setf signal a device-busy error.

∂08-May-87  1307	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: NIL in CLX 
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 May 87  13:06:55 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 8 May 87 16:00-EDT
Date: Fri, 8 May 87 16:01 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: NIL in CLX
To: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2756297339-9696988@SI>
Message-ID: <870508160155.4.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Wed, 6 May 87  09:08:59 CDT
    From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>

    If someone REALLY wants to use a null clipping rectangle list, let them do:
      (change-gc gc :clip-mask (or clipping-rectangles :disable-graphics))

    P.S. Perhaps you can think of a better keyword than :disable-graphics

Yes, I would prefer to not introduce the keyword at all and let them do:

(change-gc gc :clip-mask (or clipping-rectangles (make-array 0)))

[Of course change-gc is going away, but this is true of create-gcontext and
 with-gcontext.]

∂08-May-87  1327	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	timeout in event-case    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 May 87  13:27:44 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 8 May 87 16:25-EDT
Date: Fri, 8 May 87 16:26 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: timeout in event-case
To: cl-windows@sail.stanford.edu
Message-ID: <870508162657.8.RWS@KILLINGTON.LCS.MIT.EDU>

I was changing hang-p to timeout in process-event (aka next-event) and
event-case (specified as a number in seconds), and realized that there
is a semantic question.  Should the waiting only apply if the queue is
initially empty and only until the queue goes non-empty, or should it
apply until some non-nil value is returned? (Or be an option, yech.)
The former is easier to do in bsd Unix (pass the argument to the select
system call).  The latter seems correct, but is more expensive, since
(last I knew) select didn't return the time remaining on success.  This
means doing gettimeofday system calls, which substantially increases the
overhead.  Comments?

By the way, most issues now seem pretty much resolved.  I've been
side-tracked with other things, but I hope to send out a new draft and
diffs before the 15th.

∂09-May-87  0538	RAM@C.CS.CMU.EDU 	timeout in event-case 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 May 87  05:37:54 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sat 9 May 87 08:37:13-EDT
Date: Sat, 9 May 1987  08:37 EDT
Message-ID: <RAM.12300982889.BABYL@>
From: Rob MacLachlan <RAM@λλ>
To:   Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: timeout in event-case
In-reply-to: Msg of 8 May 1987  16:26-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>


I have no objection to having a wait with timeout return before the
full time has elapsed.  Timeouts are generally of an advisory nature
anyway.  If the user wants to wait a specific amount of time, he can
always keep track of the elapsed time by using get-internal-real-time.

  Rob

∂11-May-87  1651	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	CLX draft 3 revisions    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87  16:51:38 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 11 May 87 19:33-EDT
Date: Mon, 11 May 87 19:35 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX draft 3 revisions
To: cl-windows@sail.stanford.edu
Message-ID: <870511193549.4.RWS@KILLINGTON.LCS.MIT.EDU>

A separate message will contain Draft Version 3 of the CLX proposal.
It is also available via anonymous ftp to milo.lcs.mit.edu.

Below is a (hopefully complete) summary of revisions from Version 2.

A few things (like with-state) no doubt still have unsatisfactory names,
but hopefully we are converging on semantics.  I am currently working
with the C Xlib owner to see if we can be consistent there.

note especially: window-priority setf, selection-owner setf,
		 gcontext-clip-mask and setf

gc renamed to gcontext uniformly

:graphics-exposures renamed to :exposures in gcontext-key

display-image-info split out into display-image-lsb-first-p,
display-bitmap-format, and display-pixmap-formats

image-info defstruct split into bitmap-format and pixmap-format

missing default-char added to font-info

defstructs for window-attributes, drawable-geometry, pointer-info, text-extents,
and keyboard-control removed

display-vendor-id renamed to display-vendor

attempt at semantic clarification in with-display

:win-gravity renamed to :gravity in create-window
:backing-bit-planes renamed to :backing-planes in create-window

new accessors:
  window-visual, window-class, window-gravity, window-bit-gravity,
  window-backing-store, window-backing-planes, window-backing-pixel,
  window-save-under, window-colormap, window-colormap-installed-p,
  window-map-state, window-all-event-masks, window-event-mask,
  window-do-not-propagate-mask, window-override-redirect

new setfs:
  window-gravity, window-bit-gravity, window-backing-store, window-backing-planes,
  window-backing-pixel, window-save-under, window-event-mask,
  window-do-not-propagate-mask, window-override-redirect, window-colormap,
  window-cursor

new accessors:
  window-root, window-depth, window-x, window-y, window-width, window-height,
  window-border-width, pixmap-root, pixmap-depth pixmap-width, pixmap-height,
  drawable-root, drawable-depth, drawable-x, drawable-y, drawable-width,
  drawable-height, drawable-border-width

new setfs:
  window-x, window-y, window-width, window-height, window-border-width,
  window-priority

new state-hacking form added: with-state

change-window-attributes, window-attributes, and related multiple value
attribute functions removed

save-set-insert renamed to add-to-save-set

save-set-delete renamed to remove-from-save-set

configure-window removed

drawable-geometry, drawable-size, and drawable-rectangle removed

list-properties return value refined to (sequence keyword)

set-selection-owner recast as a setf

send-event-to-pointer-window and send-event-to-input-focus removed

send-event revised to allow :pointer-window and :input-focus as window,
with display keyword argument required

missing display argument added to ungrab-pointer

with-pointer-grabbed and with-keyboard-grabbed removed

query-pointer changed to return multiple values

global-pointer-position changed to return root window as third value

translate-coordinates defined to return nil when src and dst on different screens

conditional-warp-pointer renamed to warp-pointer-if-inside

text-extents changed to return multiple values

text-bounds removed

text16-extents and text16-width added

:graphics-exposures renamed to :exposure in create-gcontext and with-gcontext

:cache changed to cache-p in create-gcontext, and caching semantics revised

change-gc removed

accessor and setf for clip-mask revised

clear-to-background renamed to clear-area

draw-string-image renamed to draw-image-string

draw-string-image16 renamed to draw-image-string16

stringable added as legal color in store-colors

device-busy error defined for keyboard-mapping and pointer-mapping setfs

keyboard-control changed to return multiple values

acceleration changed from rational to number in change-pointer-control

optional timeout value in seconds added to event-listen

next-event renamed to process-event

force-p renamed to force-output-p in process-event and event-case

hang-p changed to timeout in seconds in process-event and event-case

(keyword var) form allowed in event-case arguments

queue-event-locally renamed to queue-event

event-queue-length removed

event-code changed to event-key in queue-event

∂11-May-87  1655	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	it really was version 3 ...   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87  16:55:18 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 11 May 87 19:41-EDT
Date: Mon, 11 May 87 19:43 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: it really was version 3 ...
To: cl-windows@sail.stanford.edu
Message-ID: <870511194336.7.RWS@KILLINGTON.LCS.MIT.EDU>

... despite the comment internally that labelled it Version 2.

∂12-May-87  0506	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	CLX 3: part 1 of 2 [First attempt bounced with "message too large"]   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 May 87  05:06:11 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 12 May 87 08:03-EDT
Date: Tue, 12 May 87 08:05 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX 3: part 1 of 2 [First attempt bounced with "message too large"]
To: cl-windows@sail.stanford.edu
Message-ID: <870512080534.8.RWS@KILLINGTON.LCS.MIT.EDU>

;;; -*- Mode: LISP; Syntax: Common-lisp; Package: (XLIB (CL)); Base: 10; Lowercase: Yes -*-

;; Draft Version 3

;; Author:
;;	Robert W. Scheifler
;;	Laboratory for Computer Science
;;	545 Technology Square, Room 418
;;	Cambridge, MA 02139
;;	rws@zermatt.lcs.mit.edu

;; Contributors:
;;	Dan Cerys, Texas Instruments
;;	Scott Fahlman, CMU
;;	Kerry Kimbrough, Texas Instruments
;;	Chris Lindblad, MIT
;;	Rob MacLachlan, CMU
;;	Mike McMahon, Symbolics
;;	David Moon, Symbolics
;;	LaMott Oren, Texas Instruments
;;	Daniel Weinreb, Symbolics
;;	John Wroclawski, MIT
;;	Richard Zippel, Symbolics

;; Note: all of the following is in the package XLIB.

;; Note: various perversions of the CL type system are used below.
;; Examples: (list elt-type) (sequence elt-type)

(proclaim '(declaration arglist values))

;; Note: if you have read the Version 11 protocol document or C Xlib manual, most of
;; the relationships should be fairly obvious.  We have no intention of writing yet
;; another moby document for this interface.

;; Types employed: display, window, pixmap, cursor, font, gcontext, colormap, color.
;; These types are defined solely by a functional interface; we do not specify
;; whether they are implemented as structures or flavors or ...  Although functions
;; below are written using DEFUN, this is not an implementation requirement (although
;; it is a requirement that they be functions as opposed to macros or special forms).
;; It is unclear whether with-slots in the Common Lisp Object System must work on
;; them.

;; Windows, pixmaps, cursors, fonts, gcontexts, and colormaps are all represented as
;; compound objects, rather than as integer resource-ids.  This allows applications
;; to deal with multiple displays without having an explicit display argument in the
;; most common functions.  Every function uses the display object indicated by the
;; first argument that is or contains a display; it is an error if arguments contain
;; different displays, and predictable results are not guaranteed.

;; Each of window, pixmap, cursor, font, gcontext, and colormap have the following
;; five functions:

(defun make-<mumble> (display resource-id)
  ;; This function should almost never be called by applications, except in handling
  ;; events.  To minimize consing in some implementations, this may use a cache in
  ;; the display.  Make-gcontext creates with :cache-p nil.  Make-font creates with
  ;; cache-p true.
  (declare (type display display)
	   (type integer resource-id)
	   (values <mumble>)))

(defun <mumble>-display (<mumble>)
  (declare (type <mumble> <mumble>)
	   (values display)))

(defun <mumble>-id (<mumble>)
  (declare (type <mumble> <mumble>)
	   (values integer)))

(defun <mumble>-equal (<mumble>-1 <mumble>-2)
  (declare (type <mumble> <mumble>-1 <mumble>-2)))

(defun <mumble>-p (<mumble>-1 <mumble>-2)
  (declare (type <mumble> <mumble>-1 <mumble>-2)
	   (values boolean)))

;; The following functions are provided by color objects:

;; The intention is that IHS and YIQ and CYM interfaces will also exist.  Note that
;; we are explicitly using a different spectrum representation than what is actually
;; transmitted in the protocol.

(defun make-color (&key red green blue &allow-other-keys)	; for expansion
  (declare (type (number 0 1) red green blue)
	   (values color)))

(defun color-rgb (color)
  (declare (type color color)
	   (values red green blue)))

(defun color-red (color)
  ;; setf'able
  (declare (type color color)
	   (values (number 0 1))))

(defun color-green (color)
  ;; setf'able
  (declare (type color color)
	   (values (number 0 1))))

(defun color-blue (color)
  ;; setf'able
  (declare (type color color)
	   (values (number 0 1))))

(deftype resource-id () 'integer)

(deftype drawable () '(or window pixmap))

;; Atoms are accepted as strings or symbols, and are always returned as keywords.
;; Protocol-level integer atom ids are hidden, using a cache in the display object.

(deftype xatom () '(or string symbol))

(deftype stringable () '(or string symbol))

(deftype fontable () '(or stringable font))

;; Nil stands for CurrentTime.

(deftype timestamp () '(or null integer))

(deftype bit-gravity () '(member :forget :static :north-west :north :north-east
				 :west :center :east :south-west :south :south-east))

(deftype win-gravity () '(member :unmap :static :north-west :north :north-east
				 :west :center :east :south-west :south :south-east))

(deftype grab-status ()
  '(member :success :already-grabbed :frozen :invalid-time :not-viewable))

(deftype boolean () '(or null (not null)))

;; An association list.

(deftype alist (key-type-and-name datum-type-and-name) 'list)

;; A sequence, containing zero or more repetitions of the given elements,
;; with the elements expressed as (type name).

(deftype repeat-seq (&rest elts) 'sequence)

(deftype point-seq () '(repeat-seq (integer x) (integer y)))

(deftype seg-seq () '(repeat-seq (integer x1) (integer y1) (integer x2) (integer y2)))

(deftype rect-seq () '(repeat-seq (integer x) (integer y) (integer width) (integer height)))

;; Note that we are explicitly using a different angle representation than what
;; is actually transmitted in the protocol.

(deftype angle () `(number ,(* -2 pi) ,(* 2 pi)))

(deftype arc-seq () '(repeat-seq (integer x) (integer y) (integer width) (integer height)
				 (angle angle1) (angle angle2)))

(deftype event-mask-class ()
  '(member :key-press :key-release :owner-grab-button :button-press :button-release
	   :enter-window :leave-window :pointer-motion :pointer-motion-hint
	   :button-1-motion :button-2-motion :button-3-motion :button-4-motion
	   :button-5-motion :button-motion :exposure :visibility-change
	   :structure-notify :resize-redirect :substructure-notify :substructure-redirect
	   :focus-change :property-change :colormap-change :keymap-state))

(deftype event-mask ()
  '(or integer (list event-mask-class)))

(deftype pointer-event-mask-class ()
  '(member :button-press :button-release
	   :enter-window :leave-window :pointer-motion :pointer-motion-hint
	   :button-1-motion :button-2-motion :button-3-motion :button-4-motion
	   :button-5-motion :button-motion :keymap-state))

(deftype pointer-event-mask ()
  '(or integer (list pointer-event-mask-class)))

(deftype device-event-mask-class ()
  '(member :key-press :key-release :button-press :button-release :pointer-motion
	   :button-1-motion :button-2-motion :button-3-motion :button-4-motion
	   :button-5-motion :button-motion))

(deftype device-event-mask ()
  '(or integer (list device-event-mask-class)))

(deftype modifier-key ()
  '(member :shift :caps-lock :control :mod-1 :mod-2 :mod-3 :mod-4 :mod-5))

(deftype modifier-mask ()
  '(or (member :any) integer (list modifier-key)))

(deftype state-mask-key ()
  '(or modifier-key (member :button-1 :button-2 :button-3 :button-4 :button-5)))

(deftype gcontext-key ()
  '(member :function :plane-mask :foreground :background
	   :line-width :line-style :cap-style :join-style :fill-style :fill-rule
	   :arc-mode :tile :stipple :ts-x :ts-y :font :subwindow-mode
	   :exposures :clip-x :clip-y :clip-mask :clip-ordering
	   :dash-offset :dashes))

(deftype event-key ()
  '(member :key-press :key-release :button-press :button-release :motion-notify
	   :enter-notify :leave-notify :focus-in :focus-out :keymap-notify
	   :exposure :graphics-exposure :no-exposure :visibility-notify
	   :create-notify :destroy-notify :unmap-notify :map-notify :map-request
	   :reparent-notify :configure-notify :gravity-notify :resize-request
	   :configure-request :circulate-notify :circulate-request :property-notify
	   :selection-clear :selection-request :selection-notify
	   :colormap-notify :client-message))

(deftype error-key ()
  '(member :access :alloc :atom :colormap :cursor :drawable :font :gcontext :id-choice
	   :illegal-request :implementation :length :match :name :pixmap :property
	   :value :window))

(deftype draw-direction ()
  '(member :left-to-right :right-to-left))

(defstruct bitmap-format
  (unit <unspec> :type (member 8 16 32))
  (pad <unspec> :type (member 8 16 32))
  (lsb-first-p <unspec> :type boolean))

(defstruct pixmap-format
  (depth <unspec> :type integer)
  (bits-per-pixel <unspec> :type (member 4 8 16 32))
  (pad <unspec> :type (member 8 16 32)))

(defstruct visual-info
  (id <unspec> :type integer)
  (class <unspec> :type (member :static-gray :static-color :true-color
				:gray-scale :pseudo-color :direct-color))
  (red-mask <unspec> :type integer)
  (green-mask <unspec> :type integer)
  (blue-mask <unspec> :type integer)
  (bits-per-rgb <unspec> :type integer)
  (colormap-entries <unspec> :type integer))

(defstruct screen
  (root <unspec> :type window)
  (device <unspec> :type integer)
  (width <unspec> :type integer)
  (height <unspec> :type integer)
  (width-in-millimeters <unspec> :type integer)
  (height-in-millimeters <unspec> :type integer)
  (depths <unspec> :type (alist (integer depth) ((list visual-info) visuals)))
  (root-depth <unspec> :type integer)
  (root-visual <unspec> :type integer)
  (default-colormap <unspec> :type colormap)
  (white-pixel <unspec> :type integer)
  (black-pixel <unspec> :type integer)
  (min-installed-maps <unspec> :type integer)
  (max-installed-maps <unspec> :type integer)
  (backing-stores <unspec> :type (member :never :when-mapped :always))
  (save-unders-p <unspec> :type boolean)
  (event-mask-at-open <unspec> :type integer))

;; To allow efficient storage representations, the type char-info is not
;; required to be a structure.

(defun char-left-bearing (char-info)
  (declare (type char-info char-info)
	   (values integer)))

(defun char-right-bearing (char-info)
  (declare (type char-info char-info)
	   (values integer)))

(defun char-width (char-info)
  (declare (type char-info char-info)
	   (values integer)))

(defun char-ascent (char-info)
  (declare (type char-info char-info)
	   (values integer)))

(defun char-descent (char-info)
  (declare (type char-info char-info)
	   (values integer)))

(defun char-attributes (char-info)
  (declare (type char-info char-info)
	   (values integer)))

;; The list contains alternating keywords and integers.

(deftype font-props () 'list)

(defstruct font-info
  (name <unspec> :type string)
  (direction <unspec> :type draw-direction)
  (min-char <unspec> :type integer)
  (max-char <unspec> :type integer)
  (min-byte1 <unspec> :type integer)
  (max-byte1 <unspec> :type integer)
  (min-byte2 <unspec> :type integer)
  (max-byte2 <unspec> :type integer)
  (all-chars-exist-p <unspec> :type boolean)
  (default-char <unspec> :type integer)
  (min-bounds <unspec> :type char-info)
  (max-bounds <unspec> :type char-info)
  (ascent <unspec> :type integer)
  (descent <unspec> :type integer)
  (properties <unspec> :type font-props))

(defun open-display (host &key (display 0) protocol)
  ;; A string must be acceptable as a host, but otherwise the possible types for host
  ;; and protocol are not constrained, and will likely be very system dependent.  The
  ;; default protocol is system specific.  Authorization, if any, is assumed to come
  ;; from the environment somehow.
  (declare (type integer display)
	   (values display)))

(defun display-protocol-version (display)
  ;; Values are integers.
  (declare (type display display)
	   (values major minor)))

(defun display-vendor (display)
  ;; Values are string and integer
  (declare (type display display)
	   (values name release)))

(defun display-image-lsb-first-p (display)
  (declare (type display display)
	   (values boolean)))

(defun display-bitmap-formap (display)
  (declare (type display display)
	   (values bitmap-format)))

(defun display-pixmap-formats (display)
  (declare (type display display)
	   (values (list pixmap-formats))))

(defun display-roots (display)
  (declare (type display display)
	   (values (list screen))))

(defun display-keyboard (display)
  (declare (type display display)
	   (values integer)))

(defun display-pointer (display)
  (declare (type display display)
	   (values integer)))

(defun display-motion-buffer-size (display)
  (declare (type display display)
	   (values integer)))

(defun display-max-request-length (display)
  (declare (type display display)
	   (values integer)))

(defun close-display (display)
  (declare (type display display)))

(defun display-error-handler (display)
  (declare (type display display)
	   (values handler)))

(defsetf display-error-handler (display) (handler)
  ;; All errors (synchronous and asynchronous) are processed by calling an error
  ;; handler in the display.  If handler is a sequence it is expected to contain
  ;; handler functions specific to each error; the error code is used to index the
  ;; sequence, fetching the appropriate handler.  Any results returned by the handler
  ;; are ignored; it is assumed the handler either takes care of the error
  ;; completely, or else signals. For all core errors, the keyword/value argument
  ;; pairs are:
  ;;    :display display
  ;;    :error-key error-key
  ;;    :major integer
  ;;    :minor integer
  ;;    :sequence integer
  ;;    :current-sequence integer
  ;; For :colormap, :cursor, :drawable, :font, :gcontext, :id-choice, :pixmap, and
  ;; :window errors another pair is:
  ;;    :resource-id integer
  ;; For :atom errors, another pair is:
  ;;    :atom-id integer
  ;; For :value errors, another pair is:
  ;;    :value integer
  (declare (type display display)
	   (type (or (sequence (function (&rest key-vals)))
		     (function (&rest key-vals)))
		 handler)))

(defmacro define-condition (name base &body items)
  ;; just a place-holder here for the real thing
  )

(define-condition request-error error
  display
  major
  minor
  sequence
  current-sequence)

(defun default-error-handler (&rest key-vals)
  ;; The default display-error-handler.
  ;; It signals the conditions listed below.
  )

(define-condition resource-error request-error
  resource-id)

(define-condition access-error request-error)

(define-condition alloc-error request-error)

(define-condition atom-error request-error
  atom-id)

(define-condition colormap-error resource-error)

(define-condition cursor-error resource-error)

(define-condition drawable-error resource-error)

(define-condition font-error resource-error)

(define-condition gcontext-error resource-error)

(define-condition id-choice-error resource-error)

(define-condition illegal-request-error request-error)

(define-condition implementation-error request-error)

(define-condition length-error request-error)

(define-condition match-error request-error)

(define-condition name-error request-error)

(define-condition pixmap-error resource-error)

(define-condition property-error request-error)

(define-condition value-error request-error
  value)

(define-condition window-error resource-error)

(defmacro with-display ((display) &body body)
  ;; This macro is for use in a multi-process environment.  It provides exclusive
  ;; access to the local display object for multiple request generation.  It need not
  ;; provide immediate exclusive access for replies; that is, if another process is
  ;; waiting for a reply (while not in a with-display), then synchronization need not
  ;; (but can) occur immediately.  Except where noted, all routines effectively
  ;; contain an implicit with-display where needed, so that correct synchronization
  ;; is always provided at the interface level on a per-call basis.  Nested uses of
  ;; this macro will work correctly.  This macro does not prevent concurrent event
  ;; processing; see with-event-queue.
  )

(defun display-force-output (display)
  ;; Output is normally buffered; this forces any buffered output.
  (declare (type display display)))

(defun display-finish-output (display)
  ;; Forces output, then causes a round-trip to ensure that all possible errors and
  ;; events have been received.
  (declare (type display display)))

(defun display-after-function (display)
  ;; setf'able
  ;; If defined, called after every protocol request is generated, even those inside
  ;; explicit with-display's, but never called from inside the after-function itself.
  ;; The function is called inside the effective with-display for the associated
  ;; request.  Default value is nil.  Can be set, for example, to
  ;; #'display-force-output or #'display-finish-output.
  (declare (type display display)
	   (values (or null (function (display))))))

(defun create-window (&key parent x y width height (depth 0) (border-width 0)
		      (class :copy) (visual :copy)
		      background border gravity bit-gravity
		      backing-store backing-planes backing-pixel save-under
		      event-mask do-not-propagate-mask override-redirect
		      colormap cursor)
  ;; Display is obtained from parent.  Only non-nil attributes are passed on in the
  ;; request: the function makes no assumptions about what the actual protocol
  ;; defaults are.  Width and height are the inside size, excluding border.
  (declare (type window parent)
	   (type integer x y width height depth border-width)
	   (type (member :copy :input-output :input-only) class)
	   (type (or (member :copy) visual) visual)
	   (type (or null (member :none :parent-relative) integer pixmap) background)
	   (type (or null (member :copy) integer pixmap) border)
	   (type (or null win-gravity) gravity)
	   (type (or null bit-gravity) bit-gravity)
	   (type (or null (member :not-useful :when-mapped :always) backing-store))
	   (type (or null integer) backing-planes backing-pixel)
	   (type (or null event-mask) event-mask)
	   (type (or null device-event-mask) do-not-propagate-mask)
	   (type (or null (member :on :off)) save-under override-redirect)
	   (type (or null (member :copy) colormap) colormap)
	   (type (or null (member :none) cursor) cursor)
	   (values window)))

(defun window-root (window)
  (declare (type window window)
	   (values window)))

(defun window-x (window)
  ;; setf'able
  (declare (type window window)
	   (values integer)))

(defun window-y (window)
  ;; setf'able
  (declare (type window window)
	   (values integer)))

(defun window-width (window)
  ;; setf'able
  ;; Inside width, excluding border.
  (declare (type window window)
	   (values integer)))

(defun window-height (window)
  ;; setf'able
  ;; Inside height, excluding border.
  (declare (type window window)
	   (values integer)))

(defun window-depth (window)
  (declare (type window window)
	   (values integer)))

(defun window-border-width (window)
  ;; setf'able
  (declare (type window window)
	   (values integer)))

(defun window-class (window)
  (declare (type window window)
	   (values (member :input-output :input-only))))

(defun window-visual (window)
  (declare (type window window)
	   (values integer)))

(defsetf window-background (window) (background)
  (declare (type window window)
	   (type (or (member :none :parent-relative) integer pixmap) background)))

(defsetf window-border (window) (border)
  (declare (type window window)
	   (type (or (member :copy) integer pixmap) border)))

(defun window-gravity (window)
  ;; setf'able
  (declare (type window window)
	   (values win-gravity)))

(defun window-bit-gravity (window)
  ;; setf'able
  (declare (type window window)
	   (values bit-gravity)))

(defun window-backing-store (window)
  ;; setf'able
  (declare (type window window)
	   (values (member :not-useful :when-mapped :always))))

(defun window-backing-planes (window)
  ;; setf'able
  (declare (type window window)
	   (values integer)))

(defun window-backing-pixel (window)
  ;; setf'able
  (declare (type window window)
	   (values integer)))

(defun window-save-under (window)
  ;; setf'able
  (declare (type window window)
	   (values (member :on :off))))

(defun window-event-mask (window)
  ;; setf'able
  (declare (type window window)
	   (values integer)))

(defun window-do-not-propagate-mask (window)
  ;; setf'able
  (declare (type window window)
	   (values integer)))

(defun window-override-redirect (window)
  ;; setf'able
  (declare (type window window)
	   (values (member :on :off))))

(defun window-colormap (window)
  (declare (type window window)
	   (values (or null colormap))))

(defsetf window-colormap (window) (colormap)
  (declare (type window window)
	   (type (or (member :copy) colormap) colormap)))

(defsetf window-cursor (window) (cursor)
  (declare (type window window)
	   (type (or (member :none) cursor) cursor)))

(defun window-colormap-installed-p (window)
  (declare (type window window)
	   (values boolean)))

(defun window-all-event-masks (window)
  (declare (type window window)
	   (values integer)))

(defun window-map-state (window)
  (declare (type window window)
	   (values (member :unmapped :unviewable :viewable))))

(defsetf window-priority (window &optional sibling) (mode)
  ;; A bit strange, but retains setf form.
  (declare (type window window)
	   (type (or null window) sibling)
	   (type (member :above :below :top-if :bottom-if :opposite) mode)))

(defmacro with-state ((drawable) &body body)
  ;; Allows a consistent view to be obtained of data returned by GetWindowAttributes
  ;; and GetGeometry, and allows a coherent update using ChangeWindowAttributes and
  ;; ConfigureWindow.  The body is not surrounded by a with-display.  Within the
  ;; indefinite scope of the body, on a per-process basis in a multi-process
  ;; environment, the first call within an Accessor Group on the specified drawable
  ;; (the object, not just the variable) causes the complete results of the protocol
  ;; request to be retained, and returned in any subsequent accessor calls.  Calls
  ;; within a Setf Group are delayed, and executed in a single request on exit from
  ;; the body.  In addition, if a call on a function within an Accessor Group follows
  ;; a call on a function in the corresponding Setf Group, then all delayed setfs for
  ;; that group are executed, any retained accessor information for that group is
  ;; discarded, the corresponding protocol request is (re)issued, and the results are
  ;; (again) retained, and returned in any subsequent accessor calls.

  ;; Accessor Group A (for GetWindowAttributes):
  ;; window-visual, window-class, window-gravity, window-bit-gravity,
  ;; window-backing-store, window-backing-planes, window-backing-pixel,
  ;; window-save-under, window-colormap, window-colormap-installed-p,
  ;; window-map-state, window-all-event-masks, window-event-mask,
  ;; window-do-not-propagate-mask, window-override-redirect

  ;; Setf Group A (for ChangeWindowAttributes):
  ;; window-gravity, window-bit-gravity, window-backing-store, window-backing-planes,
  ;; window-backing-pixel, window-save-under, window-event-mask,
  ;; window-do-not-propagate-mask, window-override-redirect, window-colormap,
  ;; window-cursor

  ;; Accessor Group G (for GetGeometry):
  ;; window-root, window-depth, window-x, window-y, window-width, window-height,
  ;; window-border-width, pixmap-root, pixmap-depth pixmap-width, pixmap-height,
  ;; drawable-root, drawable-depth, drawable-x, drawable-y, drawable-width,
  ;; drawable-height, drawable-border-width

  ;; Setf Group G (for ConfigureWindow):
  ;; window-x, window-y, window-width, window-height, window-border-width,
  ;; window-priority
  )

(defun destroy-window (window)
  (declare (type window window)))

(defun destroy-subwindows (window)
  (declare (type window window)))

(defun add-to-save-set (window)
  (declare (type window window)))

(defun remote-from-save-set (window)
  (declare (type window window)))

(defun reparent-window (window parent x y)
  (declare (type window window parent)
	   (type integer x y)))

(defun map-window (window)
  (declare (type window window)))

(defun map-subwindows (window)
  (declare (type window window)))

(defun unmap-window (window)
  (declare (type window window)))

(defun unmap-subwindows (window)
  (declare (type window window)))

(defun circulate-window-up (window)
  (declare (type window window)))

(defun circulate-window-down (window)
  (declare (type window window)))

(defun drawable-root (drawable)
  (declare (type drawable drawable)
	   (values drawable)))

(defun drawable-depth (drawable)
  (declare (type drawable drawable)
	   (values integer)))

(defun drawable-x (drawable)
  (declare (type drawable drawable)
	   (values integer)))

(defun drawable-y (drawable)
  (declare (type drawable drawable)
	   (values integer)))

(defun drawable-width (drawable)
  ;; For windows, inside width, excluding border.
  (declare (type drawable drawable)
	   (values integer)))

(defun drawable-height (drawable)
  ;; For windows, inside height, excluding border.
  (declare (type drawable drawable)
	   (values integer)))

(defun drawable-border-width (drawable)
  (declare (type drawable drawable)
	   (values integer)))

(defun query-tree (window &key (result-type 'list))
  (declare (type window window)
	   (type type result-type)
	   (values (sequence window) parent root)))

(defun change-property (window property data type format
			&key (mode :replace) (start 0) end transform)
  ;; Start and end affect sub-sequence extracted from data.
  ;; Transform is applied to each extracted element.
  (declare (type window window)
	   (type xatom property type)
	   (type (member 8 16 32) format)
	   (type sequence data)
	   (type (member :replace :prepend :append) mode)
	   (type integer start)
	   (type (or null integer) end)
	   (type (or null (function (t) integer)) transform)))

(defun delete-property (window property)
  (declare (type window window)
	   (type xatom property)))

(defun get-property (window property
		     &key type (start 0) end delete-p (result-type 'list) transform)
  ;; Transform is applied to each integer retrieved.
  (declare (type window window)
	   (type xatom property)
	   (type (or null xatom) type)
	   (type integer start)
	   (type (or null integer) end)
	   (type boolean delete-p)
	   (type type result-type)
	   (type (or null (function (integer) t)) transform)
	   (values data type format bytes-after)))

(defun rotate-properties (window properties &optional (delta 1))
  ;; Postive rotates left, negative rotates right (opposite of actual protocol request).
  (declare (type window window)
	   (type (sequence xatom) properties)
	   (type integer delta)))

(defun list-properties (window &key (result-type 'list))
  (declare (type window window)
	   (type type result-type)
	   (values (sequence keyword))))

;; Although atom-ids are not visible in the normal user interface, atom-ids might
;; appear in window properties and other user data, so conversion hooks are needed.

(defun intern-atom (display name)
  (declare (type display display)
	   (type xatom name)
	   (values integer)))

(defun find-atom (display name)
  (declare (type display display)
	   (type xatom name)
	   (values (or null integer))))

(defun atom-name (display atom-id)
  (declare (type display display)
	   (type integer atom-id)
	   (values keyword)))

(defun selection-owner (display selection)
  (declare (type display display)
	   (type xatom selection)
	   (values (or null window))))

(defsetf selection-owner (display selection &optional time) (owner)
  ;; A bit strange, but retains setf form.
  (declare (type display display)
	   (type xatom selection)
	   (type (or null window) owner)
	   (type timestamp time)))

(defun convert-selection (selection type requestor &optional property time)
  (declare (type xatom selection type)
	   (type window requestor)
	   (type (or null xatom) property)
	   (type timestamp time)))

(defun send-event (window event-key event-mask &rest args
		   &key propagate-p display &allow-other-keys)
  ;; Additional arguments depend on event-key, and are as specified further below
  ;; with declare-event, except that both resource-ids and resource objects are
  ;; accepted in the event components.  The display argument is only required if the
  ;; window is :pointer-window or :input-focus.
  (declare (type (or window (member :pointer-window :input-focus)) window)
	   (type event-key event-key)
	   (type event-mask event-mask)
	   (type boolean propagate-p)
	   (type (or null display) display)))

(defun grab-pointer (window event-mask
		     &key owner-p sync-pointer-p sync-keyboard-p confine-to cursor time)
  (declare (type window window)
	   (type pointer-event-mask event-mask)
	   (type boolean owner-p sync-pointer-p sync-keyboard-p)
	   (type (or null window) confine-to)
	   (type (or null cursor) cursor)
	   (type timestamp time)
	   (values grab-status)))

(defun ungrab-pointer (display &key time)
  (declare (type display display)
	   (type timestamp time)))

(defun grab-button (window button event-mask
		    &key (modifiers 0)
			 owner-p sync-pointer-p sync-keyboard-p confine-to cursor)
  (declare (type window window)
	   (type (or (member :any) integer) button)
	   (type modifier-mask modifiers)
	   (type pointer-event-mask event-mask)
	   (type boolean owner-p sync-pointer-p sync-keyboard-p)
	   (type (or null window) confine-to)
	   (type (or null cursor) cursor)))

(defun ungrab-button (window button &key (modifiers 0))
  (declare (type window window)
	   (type (or (member :any) integer) button)
	   (type modifier-mask modifiers)))

(defun change-active-pointer-grab (display event-mask &optional cursor time)
  (declare (type display display)
	   (type pointer-event-mask event-mask)
	   (type (or null cursor) cursor)
	   (type timestamp time)))

(defun grab-keyboard (window &key owner-p sync-pointer-p sync-keyboard-p time)
  (declare (type window window)
	   (type boolean owner-p sync-pointer-p sync-keyboard-p)
	   (type timestamp time)
	   (values grab-status)))

(defun ungrab-keyboard (display &key time)
  (declare (type display display)
	   (type timestamp time)))

(defun grab-key (window key &key (modifiers 0) owner-p sync-pointer-p sync-keyboard-p)
  (declare (type window window)
	   (type boolean owner-p sync-pointer-p sync-keyboard-p)
	   (type (or (member :any) integer) key)
	   (type modifier-mask modifiers)))

(defun ungrab-key (window key &key (modifiers 0))
  (declare (type window window)
	   (type (or (member :any) integer) key)
	   (type modifier-mask modifiers)))

(defun allow-events (display mode &optional time)
  (declare (type display display)
	   (type (member :async-pointer :sync-pointer :reply-pointer
			 :async-keyboard :sync-keyboard :replay-keyboard)
		 mode)
	   (type timestamp time)))

(defun grab-server (display)
  (declare (type display display)))

(defun ungrab-server (display)
  (declare (type display display)))

(defmacro with-server-grabbed ((display) &body body)
  ;; The body is not surrounded by a with-display.
  )

∂12-May-87  0507	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	CLX 3: part 2 of 2  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 May 87  05:06:45 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 12 May 87 08:04-EDT
Date: Tue, 12 May 87 08:06 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX 3: part 2 of 2
To: cl-windows@sail.stanford.edu
Message-ID: <870512080611.9.RWS@KILLINGTON.LCS.MIT.EDU>


(defun query-pointer (window)
  (declare (type window window)
	   (values x y same-screen-p child mask root-x root-y root)))

(defun pointer-position (window)
  (declare (type window window)
	   (values x y same-screen-p)))

(defun global-pointer-position (display)
  (declare (type display display)
	   (values root-x root-y root)))

(defun motion-events (window &key start stop (result-type 'list))
  (declare (type window window)
	   (type timestamp start stop)
	   (type type result-type)
	   (values (repeat-seq (integer x) (integer y) (timestamp time)))))

(defun translate-coordinates (src src-x src-y dst)
  ;; If src and dst are not on the same screen, nil is returned.
  (declare (type window src)
	   (type integer src-x src-y)
	   (type window dst)
	   (values dst-x dst-y child)))

(defun warp-pointer (dst dst-x dst-y)
  (declare (type window dst)
	   (type integer dst-x dst-y)))

(defun warp-pointer-if-inside (dst dst-x dst-y src src-x src-y
			       &optional src-width src-height)
  ;; Passing in a zero src-width or src-height is a no-op.  A null src-width or
  ;; src-height translates into a zero value in the protocol request.
  (declare (type window dst src)
	   (type integer dst-x dst-y src-x src-y)
	   (type (or null integer) src-width src-height)))

(defun set-input-focus (display focus revert-to &optional time)
  ;; Setf ought to allow multiple values.
  (declare (type display display)
	   (type (or (member :none :pointer-root) window) focus)
	   (type (member :none :parent :pointer-root) revert-to)
	   (type timestamp time)))

(defun input-focus (display)
  (declare (type display display)
	   (values focus revert-to)))

(defun query-keymap (display)
  (declare (type display display)
	   (values (bit-vector 256))))

(defun open-font (display name &optional (cache-p t))
  ;; Font objects may be cached and reference counted locally within the display
  ;; object.  This function might not execute a with-display if the font is cached.
  ;; The protocol QueryFont request happens on-demand under the covers.  If cache-p
  ;; is nil, QueryFont results are never cached locally.
  (declare (type display display)
	   (type stringable name)
	   (type boolean cache-p)
	   (values font)))

(defun font-cache-p (font)
  ;; setf'able
  (declare (type font font)
	   (values boolean)))

(defun font-font-info (font)
  (declare (type font font)
	   (values font-info)))

;; For each component (<name> <unspec> :type <type>) of font-info,
;; there is a corresponding function:

(defun font-<name> (font)
  (declare (type font font)
	   (values <type>)))

(defun font-property (font name)
  (declare (type font font)
	   (type keyword name)
	   (values (or null integer))))

(defun font-char-infos (font)
  (declare (type font font)
	   (values (array char-info))))

(defun font-char-info (font char)
  (declare (type font font)
	   (type integer char)
	   (values (or null char-info))))

(defun font-char16-info (font first-byte second-byte)
  (declare (type font font)
	   (type integer first-byte second-byte)
	   (values (or null char-info))))

(defun close-font (font)
  ;; This might not generate a protocol request if the font is reference counted
  ;; locally.
  (declare (type font font)))

(defun text-extents (font string)
  (declare (type (or font gcontext) font)
	   (type string string)
	   (values width ascent descent left right font-ascent font-descent direction)))

(defun text16-extents (font array &key bytes-p)
  ;; If bytes-p is nil, then array should be an array of integers to be treated as
  ;; 16-bit quantities, otherwise array should be a string of even length, treated as
  ;; first-byte/second-byte pairs.
  (declare (type (or font gcontext) font)
	   (type array array)
	   (type boolean bytes-p)
	   (values width ascent descent left right font-ascent font-descent direction)))

(defun text-width (font string)
  (declare (type (or font gcontext) font)
	   (type string string)
	   (values integer)))

(defun text16-width (font array &key bytes-p)
  ;; If bytes-p is nil, then array should be an array of integers to be treated as
  ;; 16-bit quantities, otherwise array should be a string of even length, treated as
  ;; first-byte/second-byte pairs.
  (declare (type (or font gcontext) font)
	   (type array array)
	   (type boolean bytes-p)
	   (values integer)))

(defun list-fonts (display pattern &key (max-fonts 65535) (result-type 'list))
  (declare (type display display)
	   (type string pattern)
	   (type integer max-fonts)
	   (type type result-type)
	   (values (sequence string))))

(defun list-fonts-with-info (display pattern &key (max-fonts 65535) (result-type 'list))
  (declare (type display display)
	   (type string pattern)
	   (type integer max-fonts)
	   (type type result-type)
	   (values (sequence font-info))))

(defun font-path (display &key (result-type 'list))
  (declare (type display display)
	   (type type result-type)
	   (values (sequence (or string pathname)))))

(defsetf font-path (display) (paths)
  (declare (type display display)
	   (type (sequence (or string pathname)) paths)))

(defun create-pixmap (&key width height depth drawable)
  (declare (type integer width height depth)
	   (type drawable drawable)
	   (values pixmap)))

(defun pixmap-root (pixmap)
  (declare (type pixmap pixmap)
	   (values pixmap)))

(defun pixmap-depth (pixmap)
  (declare (type pixmap pixmap)
	   (values integer)))

(defun pixmap-width (pixmap)
  (declare (type pixmap pixmap)
	   (values integer)))

(defun pixmap-height (pixmap)
  (declare (type pixmap pixmap)
	   (values integer)))

(defun free-pixmap (pixmap)
  (declare (type pixmap pixmap)))

(defun create-gcontext (&key drawable function plane-mask foreground background
			     line-width line-style cap-style join-style fill-style fill-rule
			     arc-mode tile stipple ts-x ts-y font subwindow-mode
			     exposures clip-x clip-y clip-mask clip-ordering
			     dash-offset dashes
			     (cache-p t))
  ;; Only non-nil components are passed on in the request, but for effective caching
  ;; assumptions have to be made about what the actual protocol defaults are.  For
  ;; all gcontext components, a value of nil causes the default gcontext value to be
  ;; used.  For clip-mask, this implies that an empty rect-seq cannot be represented
  ;; as a list.  Note:  use of stringable as font will cause an implicit open-font.
  ;; Note:  papers over protocol SetClipRectangles and SetDashes special cases.  If
  ;; cache-p is true, then gcontext state is cached locally, and changing a gcontext
  ;; component will have no effect unless the new value differs from the cached
  ;; value.  Component changes (setfs and with-gcontext) are always deferred
  ;; regardless of the cache mode, and sent over the protocol only when required by a
  ;; local operation or by an explicit call to force-gcontext-changes.
  (declare (type drawable drawable)
	   (type (or null boole-constant) function)
	   (type (or null integer) plane-mask foreground background line-width
				   ts-x ts-y clip-x clip-y dash-offset)
	   (type (or null (member :solid :dash :double-dash)) line-style)
	   (type (or null (member :not-last :butt :round :projecting)) cap-style)
	   (type (or null (member :miter :round :bevel)) join-style)
	   (type (or null (member :solid :tiled :opaque-stippled :stippled)) fill-style)
	   (type (or null (member :even-odd :winding)) fill-rule)
	   (type (or null (member :chord :pie-slice)) arc-mode)
	   (type (or null pixmap) tile stipple)
	   (type (or null fontable) font)
	   (type (or null (member :clip-by-children :include-inferiors)) subwindow-mode)
	   (type (or null (member :on :off)) exposures)
	   (type (or null (member :none) pixmap rect-seq) clip-mask)
	   (type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)) clip-ordering)
	   (type (or null (or integer (sequence integer))) dashes)
	   (type (or null integer) dash-offset)
	   (type boolean cache)
	   (values gcontext)))

;; For each argument to create-gcontext (except clip-mask and clip-ordering) declared
;; as (type <type> <name>), there is an accessor:

(defun gcontext-<name> (gcontext)
  ;; The value will be nil if the last value stored is unknown (e.g., the cache was
  ;; off, or the component was copied from a gcontext with unknown state).
  (declare (type gcontext gcontext)
	   (values <type>)))

;; For each argument to create-gcontext (except clip-mask and clip-ordering) declared
;; as (type (or null <type>) <name>), there is a setf for the corresponding accessor:

(defsetf gcontext-<name> (gcontext) (value)
  (declare (type gcontext gcontext)
	   (type <type> value)))

(defun gcontext-clip-mask (gcontext)
  (declare (type gcontext gcontext)
	   (values (or null (member :none) pixmap rect-seq)
		   (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)))))

(defsetf gcontext-clip-mask (gcontext &optional ordering) (clip-mask)
  ;; Is nil illegal here, or is it transformed to a vector?
  ;; A bit strange, but retains setf form.
  (declare (type gcontext gcontext)
	   (type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)) clip-ordering)
	   (type (or (member :none) pixmap rect-seq) clip-mask)))

(defun force-gcontext-changes (gcontext)
  ;; Force any delayed changes.
  (declare (type gcontext gcontext)))

(defmacro with-gcontext ((gcontext &key
			  function plane-mask foreground background
			  line-width line-style cap-style join-style fill-style fill-rule
			  arc-mode tile stipple ts-x ts-y font subwindow-mode
			  exposures clip-x clip-y clip-mask clip-ordering
			  dashes dash-offset)
			 &body body)
  ;; Changes gcontext components within the dynamic scope of the body (i.e.,
  ;; indefinite scope and dynamic extent), on a per-process basis in a multi-process
  ;; environment.  The body is not surrounded by a with-display.  If cache-p is nil
  ;; or the some component states are unknown, this will implement save/restore by
  ;; creating a temporary gcontext and doing copy-gcontext-components to and from it.
  )

(defun copy-gcontext-components (src dst &rest keys)
  (declare (type gcontext src dst)
	   (type (list gcontext-key) keys)))

(defun copy-gcontext (src dst)
  (declare (type gcontext src dst))
  ;; Copies all components.
  )
	   
(defun free-gcontext (gcontext)
  (declare (type gcontext gcontext)))

(defun clear-area (window &key (x 0) (y 0) width height exposures-p)
  ;; Passing in a zero width or height is a no-op.  A null width or height translates
  ;; into a zero value in the protocol request.
  (declare (type window window)
	   (type integer x y)
	   (type (or null integer) width height)
	   (type boolean exposures-p)))

(defun copy-area (src gcontext src-x src-y width height dst dst-x dst-y)
  (declare (type drawable src dst)
	   (type gcontext gcontext)
	   (type integer src-x src-y width height dst-x dst-y)))

(defun copy-plane (src gcontext plane src-x src-y width height dst dst-x dst-y)
  (declare (type drawable src dst)
	   (type gcontext gcontext)
	   (type integer src-x src-y plane width height dst-x dst-y)))

(defun draw-point (drawable gcontext x y)
  ;; Should be clever about appending to existing buffered protocol request, provided
  ;; gcontext has not been modified.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y)))

(defun draw-points (drawable gcontext points &optional relative-p)
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type point-seq points)
	   (type boolean relative-p)))

(defun draw-line (drawable gcontext x1 y1 x2 y2 &optional relative-p)
  ;; Should be clever about appending to existing buffered protocol request, provided
  ;; gcontext has not been modified.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x1 y1 x2 y2)
	   (type boolean relative-p)))

(defun draw-lines (drawable gcontext points &key relative-p fill-p (shape :complex))
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type point-seq points)
	   (type boolean relative-p fill-p)
	   (type (member :complex :non-convex :convex) shape)))

(defun draw-segments (drawable gcontext segments)
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type seg-seq segments)))

(defun draw-rectangle (drawable gcontext x y width height &optional fill-p)
  ;; Should be clever about appending to existing buffered protocol request, provided
  ;; gcontext has not been modified.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y width height)
	   (type boolean fill-p)))

(defun draw-rectangles (drawable gcontext rectangles &optional fill-p)
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type rect-seq rectangles)
	   (type boolean fill-p)))

(defun draw-arc (drawable gcontext x y width height angle1 angle2 &optional fill-p)
  ;; Should be clever about appending to existing buffered protocol request, provided
  ;; gcontext has not been modified.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y width height angle1 angle2)
	   (type boolean fill-p)))

(defun draw-arcs (drawable gcontext arcs &optional fill-p)
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type arc-seq arcs)
	   (type boolean fill-p)))

;; The following image routines are bare minimum.  It may be useful to define some
;; form of "image" object to hide representation details and format conversions.  It
;; also may be useful to provide stream-oriented interfaces for reading and writing
;; the data.

(defun put-raw-image (drawable gcontext data
		      &key (start 0) depth x y width height (left-pad 0) format)
  ;; Data must be a sequence of 8-bit quantities, already in the appropriate format
  ;; for transmission; the caller is responsible for all byte and bit swapping and
  ;; compaction.  Start is the starting index in data; the end is computed from the
  ;; other arguments.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type (sequence integer) data)
	   (type integer start depth x y width height left-pad)
	   (type (member :bitmap :xy-pixmap :z-pixmap) format)))

(defun get-raw-image (drawable &key data (start 0) x y width height (plane-mask -1) format
				    (result-type '(vector (unsigned-byte 8))))
  ;; If data is given, it is modified in place (and returned), otherwise a new
  ;; sequence is created and returned, with a size computed from the other arguments
  ;; and the returned depth.  The sequence is filled with 8-bit quantities, in
  ;; transmission format; the caller is responsible for any byte and bit swapping and
  ;; compaction required for further local use.
  (declare (type drawable drawable)
	   (type (or null (sequence integer)) data)
	   (type integer start x y width height plane-mask)
	   (type (member :xy-format z-format) format)
	   (values (sequence integer) depth visual)))

(defun draw-string (drawable gcontext x y string &key (start 0) end)
  ;; For 8-bit indexes only.
  ;; Should be clever about appending to existing buffered protocol request, provided
  ;; gcontext has not been modified and char-infos are cached.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type string string)
	   (type (or null integer) end)))

(defun draw-text (drawable gcontext items)
  ;; For 8-bit indexes only.
  ;; Items is a flat sequence containing both triples and pairs of the form:
  ;; (integer x) (integer y) (string string)
  ;; :font (fontable font)
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type sequence items)))

(defun draw-string16 (drawable gcontext x y array &key bytes-p (start 0) end)
  ;; Should be clever about appending to existing buffered protocol request, provided
  ;; gcontext has not been modified and char-infos are cached.  If bytes-p is nil,
  ;; then array should be an array of integers to be treated as 16-bit quantities,
  ;; otherwise array should be a string of even length, treated as
  ;; first-byte/second-byte pairs.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type array array)
	   (type boolean bytes-p)))

(defun draw-text16 (drawable gcontext items &key bytes-p)
  ;; Items is a flat sequence containing both triples and pairs of the form:
  ;; (integer x) (integer y) (array array)
  ;; :font (fontable font)
  ;; If bytes-p is nil, then array should be an array of integers to be treated as
  ;; 16-bit quantities, otherwise array should be a (sub)string of even length,
  ;; treated as first-byte/second-byte pairs.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type sequence items)
	   (type boolean bytes-p)
	   (type (or null integer) end)))

(defun draw-image-string (drawable gcontext x y string &key (start 0) end)
  ;; For 8-bit indexes only.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type string string)
	   (type (or null integer) end)))

(defun draw-image-string16 (drawable gcontext x y array &key bytes-p (start 0) end)
  ;; If bytes-p is nil, then array should be an array of integers to be treated as
  ;; 16-bit quantities, otherwise array should be a (sub)string of even length,
  ;; treated as first-byte/second-byte pairs.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y)
	   (type array array)
	   (type boolean bytes-p)
	   (type (or null integer) end)))

(defun create-colormap (visual window &optional alloc-p)
  (declare (type integer visual)
	   (type window window)
	   (type boolean alloc-p)
	   (values colormap)))

(defun free-colormap (colormap)
  (declare (type colormap colormap)))

(defun copy-colormap-and-free (colormap)
  (declare (type colormap colormap)
	   (values colormap)))

(defun install-colormap (colormap)
  (declare (type colormap colormap)))

(defun uninstall-colormap (colormap)
  (declare (type colormap colormap)))

(defun installed-colormaps (window &key (result-type 'list))
  (declare (type window window)
	   (type type result-type)
	   (values (sequence colormap))))

(defun alloc-color (colormap color)
  (declare (type colormap colormap)
	   (type (or stringable color) color)
	   (values pixel screen-color exact-color)))

(defun alloc-color-cells (colormap colors &key (planes 0) contiguous-p (result-type 'list))
  (declare (type colormap colormap)
	   (type integer colors planes)
	   (type boolean contiguous-p)
	   (type type result-type)
	   (values (sequence pixel) (sequence mask))))

(defun alloc-color-planes (colormap colors
			   &key (reds 0) (greens 0) (blues 0)
				contiguous-p (result-type 'list))
  (declare (type colormap colormap)
	   (type integer colors reds greens blues)
	   (type boolean contiguous-p)
	   (type type result-type)
	   (values (sequence pixel) red-mask green-mask blue-mask)))

(defun free-colors (colormap pixels &optional (plane-mask 0))
  (declare (type colormap colormap)
	   (type (sequence integer) pixels)
	   (type integer plane-mask)))

(defun store-color (colormap pixel spec &key (red-p t) (green-p t) (blue-p t))
  (declare (type colormap colormap)
	   (type integer pixel)
	   (type (or stringable color) spec)
	   (type boolean red-p green-p blue-p)))

(defun store-colors (colormap specs &key (red-p t) (green-p t) (blue-p t))
  ;; If stringables are specified for colors, it is unspecified whether all
  ;; stringables are first resolved and then a single StoreColors protocol request is
  ;; issued, or whether multiple StoreColors protocol requests are issued.
  (declare (type colormap colormap)
	   (type (repeat-seq (integer pixel) ((or stringable color) color)) specs)
	   (type boolean red-p green-p blue-p)))

(defun query-colors (colormap pixels &key (result-type 'list))
  (declare (type colormap colormap)
	   (type (sequence integer) pixels)
	   (type type result-type)
	   (values (sequence color))))

(defun lookup-color (colormap name)
  (declare (type colormap colormap)
	   (type stringable name)
	   (values screen-color true-color)))

(defun create-cursor (&key source mask x y foreground background)
  (declare (type pixmap source)
	   (type (or null pixmap) mask)
	   (type integer x y)
	   (type color foreground background)
	   (values cursor)))

(defun create-glyph-cursor (&key source-font source-char mask-font mask-char
				 foreground background)
  (declare (type font source-font)
	   (type integer source-char)
	   (type (or null font) mask-font)
	   (type (or null integer) mask-char)
	   (type color foreground background)
	   (values cursor)))

(defun free-cursor (cursor)
  (declare (type cursor cursor)))

(defun recolor-cursor (cursor foreground background)
  (declare (type cursor cursor)
	   (type color foreground background)))

(defun query-best-cursor (width height display)
  (declare (type integer width height)
	   (type display display)
	   (values width height)))

(defun query-best-tile (width height drawable)
  (declare (type integer width height)
	   (type drawable drawable)
	   (values width height)))

(defun query-best-stipple (width height drawable)
  (declare (type integer width height)
	   (type drawable drawable)
	   (values width height)))

(defun query-extension (display name)
  (declare (type display display)
	   (type stringable name)
	   (values major-opcode first-event first-error)))

(defun list-extensions (display &key (result-type 'list))
  (declare (type display display)
	   (type type result-type)
	   (values (sequence string))))

(defun keyboard-mapping (display &key (result-type 'list))
  (declare (type display display)
	   (type type result-type)
	   (values (sequence integer))))

(define-condition device-busy error)

(defsetf keyboard-mapping (display) (map)
  ;; Can signal device-busy.
  (declare (type display display)
	   (type (sequence integer) map)))

(defun change-keyboard-control (display &key key-click-percent
				bell-percent bell-pitch bell-duration
				led led-mode key auto-repeat-mode)
  (declare (type display display)
	   (type (or null (member :default) integer) key-click-percent
						     bell-percent bell-pitch bell-duration)
	   (type (or null integer) led key)
	   (type (or null (member :on :off)) led-mode)
	   (type (or null (member :on :off :default)) auto-repeat-mode)))

(defun keyboard-control (display)
  (declare (type display display)
	   (values key-click-percent bell-percent bell-pitch bell-duration
		   led-mask global-auto-repeat auto-repeats)))

(defun bell (display &optional (percent-from-normal 0))
  ;; It is assumed that an eventual audio extension to X will provide more complete
  ;; control.
  (declare (type display display)
	   (type integer percent-from-normal)))

(defun pointer-mapping (display &key (result-type 'list))
  (declare (type display display)
	   (type type result-type)
	   (values (sequence integer))))

(defsetf pointer-mapping (display) (map)
  ;; Can signal device-busy.
  (declare (type display display)
	   (type (sequence integer) map)))

(defun change-pointer-control (display &key acceleration threshold)
  ;; Acceleration is rationalized if necessary.
  (declare (type display display)
	   (type (or null (member :default) number) acceleration)
	   (type (or null (member :default) integer) threshold)))

(defun pointer-control (display)
  (declare (type display display)
	   (values acceleration threshold)))

(defun set-screen-saver (display timeout interval blanking exposures)
  ;; Setf ought to allow multiple values.
  ;; Timeout and interval are in seconds, will be rounded to minutes.
  (declare (type display display)
	   (type (or (member :default) integer) timeout interval)
	   (type (member :yes :no :default) blanking exposures)))

(defun screen-saver (display)
  ;; Returns timeout and interval in seconds.
  (declare (type display display)
	   (values timeout interval blanking exposures)))

(defun activate-screen-saver (display)
  (declare (type display display)))

(defun reset-screen-saver (display)
  (declare (type display display)))

(defun add-access-host (display host)
  ;; A string must be acceptable as a host, but otherwise the possible types for host
  ;; are not constrained, and will likely be very system dependent.
  (declare (type display display)))

(defun remove-access-host (display host)
  ;; A string must be acceptable as a host, but otherwise the possible types for host
  ;; are not constrained, and will likely be very system dependent.
  (declare (type display display)))

(defun access-hosts (display &key (result-type 'list))
  ;; The type of host objects returned is not constrained, except that the hosts must
  ;; be acceptable to add-access-host and remove-access-host.
  (declare (type display display)
	   (type type result-type)
	   (values (sequence host) enabled-p)))

(defun access-control (display)
  ;; setf'able
  (declare (type display display)
	   (values boolean)))

(defun close-down-mode (display)
  ;; setf'able
  ;; Cached locally in display object.
  (declare (type display display)
	   (values (member :destroy :retain-permanent :retain-temporary))))

(defun kill-client (display resource-id)
  (declare (type display display)
	   (type resource-id resource-id)))

(defun kill-temporary-clients (display)
  (declare (type display display)))

(defun make-event-mask (&rest keys)
  ;; This is only defined for core events.
  ;; Useful for constructing event-mask, pointer-event-mask, device-event-mask.
  (declare (type (list event-mask-class) keys)
	   (values integer)))

(defun make-event-keys (event-mask)
  ;; This is only defined for core events.
  (declare (type integer event-mask)
	   (values (list event-mask-class))))

(defun make-state-mask (&rest keys)
  ;; Useful for constructing modifier-mask, state-mask.
  (declare (type (list state-mask-key) keys)
	   (values integer)))

(defun make-state-keys (state-mask)
  (declare (type integer mask)
	   (values (list state-mask-key))))

(defmacro with-event-queue ((display) &body body)
  ;; Grants exclusive access to event queue.
  )

(defun event-listen (display &optional (timeout 0))
  (declare (type display display)
	   (type (or null number) timeout))
  ;; Returns the number of events queued locally, if any, else nil.  Hangs waiting
  ;; for events, forever if timeout is nil, else for the specified number of seconds.
  )

(defun process-event (display &key handler timeout peek-p discard-p force-output-p)
  ;; If force-output-p is true, first invokes display-force-output.  Invokes handler
  ;; on each queued event until handler returns non-nil, and that returned object is
  ;; then returned by process-event.  If peek-p is true, then the event is not
  ;; removed from the queue.  If discard-p is true, then events for which handler
  ;; returns nil are removed from the queue, otherwise they are left in place.  Hangs
  ;; until non-nil is generated for some event, or for the specified timeout (in
  ;; seconds, if given); however, it is acceptable for an implementation to wait only
  ;; once on network data, and therefore timeout prematurely.  Returns nil on
  ;; timeout.  If handler is a sequence, it is expected to contain handler functions
  ;; specific to each event class; the event code is used to index the sequence,
  ;; fetching the appropriate handler.  Handler is called with raw resource-ids, not
  ;; with resource objects.  The arguments to the handler are described further below
  ;; using declare-event.
  (declare (type display display)
	   (type (or (sequence (function (&rest key-vals) t))
		     (function (&rest key-vals) t))
		 handler)
	   (type (or null number) timeout)
	   (type boolean peek-p)))

(defmacro event-case ((display &key timeout peek-p discard-p force-output-p)
		      &body clauses)
  (declare (arglist (display &key timeout peek-p discard-p force-output-p)
		    (event-or-events ((&rest args) |...|) &body body) |...|))
  ;; If force-output-p is true, first invokes display-force-output.  Executes the
  ;; matching clause for each queued event until a clause returns non-nil, and that
  ;; returned object is then returned by event-case.  If peek-p is true, then the
  ;; event is not removed from the queue.  If discard-p is true, then events for
  ;; which the clause returns nil are removed from the queue, otherwise they are left
  ;; in place.  Hangs until non-nil is generated for some event, or for the specified
  ;; timeout (in seconds, if given); however, it is acceptable for an implementation
  ;; to wait only once on network data, and therefore timeout prematurely.  Returns
  ;; nil on timeout.  In each clause, event-or-events is an event-key or a list of
  ;; event-keys (but they need not be typed as keywords) or the symbol t or otherwise
  ;; (but only in the last clause).  The keys are not evaluated, and it is an error
  ;; for the same key to appear in more than one clause.  Args is the list of event
  ;; components of interest; corresponding values (if any) are bound to variables
  ;; with these names (i.e., the args are variable names, not keywords, the keywords
  ;; are derived from the variable names).  An arg can also be a (keyword var) form,
  ;; as for keyword args in a lambda lists.  If no t/otherwise clause appears, it is
  ;; equivalent to having one that returns nil.
  )

(defmacro declare-event (event-codes &rest declares)
  ;; Used to indicate the keyword arguments for handler functions in process-event
  ;; and event-case.  All process-event handlers can have (display display) and
  ;; (event-key event-key) as keyword arguments, and an event-case clause can also
  ;; have event-key as an argument.
  (declare (arglist event-key-or-keys &rest (type &rest keywords))))

(declare-event (:key-press :key-release :button-press :button-release)
	       (resource-id window root)
	       ((or null resource-id) child)
	       (boolean same-screen-p)
	       (integer x y root-x root-y state time)
	       ;; for key-press and key-release, code is the keycode
	       ;; for button-press and button-release, code is the button number
	       (integer code))

(declare-event :motion-notify
	       (resource-id window root)
	       ((or null resource-id) child)
	       (boolean same-screen-p)
	       (integer x y root-x root-y state time)
	       (boolean hint-p))

(declare-event (:enter-notify :leave-notify)
	       (resource-id window root)
	       ((or null resource-id) child)
	       (boolean same-screen-p)
	       (integer x y root-x root-y state time)
	       ((member :normal :grab :ungrab) mode)
	       ((member :ancestor :virtual :inferior :nonlinear :nonlinear-virtual) kind)
	       (boolean focus-p))

(declare-event (:focus-in :focus-out)
	       (resource-id window)
	       ((member :normal :while-grabbed :grab :ungrab) mode)
	       ((member :ancestor :virtual :inferior :nonlinear :nonlinear-virtual
			:pointer :pointer-root :none)
		kind))

(declare-event :keymap-notify
	       (resource-id window)
	       ((bit-vector 256) keymap))

(declare-event :exposure
	       (resource-id window)
	       (integer x y width height)
	       (boolean last-p))

(declare-event :graphics-exposure
	       (resource-id drawable)
	       (integer x y width height major minor)
	       (boolean last-p))

(declare-event :no-exposure
	       (resource-id drawable)
	       (integer major minor))

(declare-event :visibility-notify
	       (resource-id window)
	       ((member :unobscured :partially-obscured :fully-obscured) state))

(declare-event :create-notify
	       (resource-id window parent)
	       (integer x y width height border-width)
	       (boolean override-redirect-p))

(declare-event :destroy-notify
	       (resource-id event-window window))

(declare-event :unmap-notify
	       (resource-id event-window window)
	       (boolean configure-p))

(declare-event :map-notify
	       (resource-id event-window window)
	       (boolean override-redirect-p))

(declare-event :map-request
	       (resource-id parent window))

(declare-event :reparent-notify
	       (resource-id event-window window parent)
	       (integer x y)
	       (boolean override-redirect-p))

(declare-event :configure-notify
	       (resource-id event-window window)
	       (integer x y width height border-width)
	       ((or null resource-id) above-sibling)
	       (boolean override-redirect-p))

(declare-event :gravity-notify
	       (resource-id event-window window)
	       (integer x y))

(declare-event :resize-request
	       (resource-id window)
	       (integer width height))

(declare-event :configure-request
	       (resource-id parent window)
	       (integer x y width height border-width)
	       ((or null resource-id) above-sibling))

(declare-event :circulate-notify
	       (resource-id event-window window)
	       ((member :top :bottom) place))

(declare-event :circulate-request
	       (resource-id parent window)
	       ((member :top :bottom) place))

(declare-event :property-notify
	       (resource-id window)
	       (keyword atom)
	       ((member :new-value :deleted) state)
	       (integer time))

(declare-event :selection-clear
	       (resource-id window)
	       (keyword selection)
	       (integer time))

(declare-event :selection-request
	       (resource-id window requestor)
	       (keyword selection target)
	       ((or null keyword) property)
	       (integer time))

(declare-event :selection-notify
	       (resource-id window)
	       (keyword selection target)
	       ((or null keyword) property)
	       (integer time))

(declare-event :colormap-notify
	       (resource-id window)
	       ((or null resource-id) colormap)
	       (boolean new-p installed-p))

(declare-event :client-message
	       (resource-id window)
	       ((member 8 16 32) format)
	       ((sequence integer) data))

(defun queue-event (display event-key &rest args &key append-p &allow-other-keys)
  ;; The event is put at the head of the queue if append-p is nil, else the tail.
  ;; Additional arguments depend on event-key, and are as specified above with
  ;; declare-event, except that both resource-ids and resource objects are accepted
  ;; in the event components.
  (declare (type display display)
	   (type event-key event-key)
	   (type boolean append-p)))

∂13-May-87  1626	Oren%Tilde%ti-csl.csnet@RELAY.CS.NET 	RE: CLX draft 3 revisions  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 13 May 87  16:25:55 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac01023; 13 May 87 19:23 EDT
Received: from ti-csl by RELAY.CS.NET id ae09454; 13 May 87 19:17 EDT
Received: from SI (si.ARPA) by tilde id AA27584; Wed, 13 May 87 16:48:28 cdt
Message-Id: <2756929653-5689439@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Wed, 13 May 87  16:47:33 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: RE: CLX draft 3 revisions

Since you've got:
  drawable-depth, drawable-root, drawable-x, drawable-y, drawable-width,
  drawable-height, drawable-border-width

How about getting rid of:
  window-depth, window-root, window-x, window-y, window-width,
  window-height, window-border-width
and
  pixmap-depth, pixmap-root, pixmap-width, pixmap-height

  -LaMott

∂13-May-87  1901	harris%hplwhh@hplabs.HP.COM 	Re: CLX draft 3 revisions 
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 13 May 87  19:01:30 PDT
Received: from hplms1 by hplabs.HP.COM with TCP ; Wed, 13 May 87 18:57:20 pdt
Received: from hplwhh (hplwhh) by hplms1; Wed, 13 May 87 18:56:16 pdt
Return-Path: <harris@hplwhh>
Received: from hplwhh.hpl.hp.com by hplwhh ; Wed, 13 May 87 18:55:42 pdt
Message-Id: <8705140155.AA02460@hplwhh>
To: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
Cc: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, cl-windows@SAIL.STANFORD.EDU,
        harris%hplwhh@hplabs.HP.COM
Subject: Re: CLX draft 3 revisions 
In-Reply-To: Your message of Wed, 13 May 87 16:47:33 -0500.
             <2756929653-5689439@SI> 
Date: Wed, 13 May 87 18:55:35 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

> Since you've got:
>   drawable-depth, drawable-root, drawable-x, drawable-y, drawable-width,
>   drawable-height, drawable-border-width
> 
> How about getting rid of:
>   window-depth, window-root, window-x, window-y, window-width,
>   window-height, window-border-width
> and
>   pixmap-depth, pixmap-root, pixmap-width, pixmap-height
> 
>   -LaMott

With the advent of generic functions, I don't see why we need to
prefix these accessors with their types anyway.  Why not just: DEPTH,
ROOT, X, Y, WIDTH, HEIGHT, and BORDER-WIDTH?  (I know X and Y aren't
very good function names, so how about LEFT and TOP with slots renamed
accordingly.)  In the mean time (before generic-functions are
available), these functions can be built from typecase statements.

Warren

P.S.  CLOS committee -- why all this :accessor-prefix stuff?  Since
methods always do the "right thing" we need no longer resort to clever
naming schemes in order that our programs do the right thing.  Surely
a concept such as HEIGHT is the same regardless of whether we're
talking about windows, fonts, displays, etc.

∂13-May-87  2117	Gregor.pa@Xerox.COM 	Re: CLX draft 3 revisions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 May 87  19:49:19 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 13 MAY 87 19:48:07 PDT
Date: 13 May 87 19:47 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: CLX draft 3 revisions 
In-reply-to: Warren Harris <harris%hplwhh@hplabs.HP.COM>'s message of
 Wed, 13 May 87 18:55:35 PDT
To: harris%hplwhh@hplabs.HP.COM
cc: Oren%Tilde%ti-csl.CSNet@relay.cs.net, RWS@ZERMATT.LCS.MIT.EDU,
 cl-windows@SAIL.STANFORD.EDU,
 CL-Object-Oriented-Programming@SAIL.STANFORD.EDU
Message-ID: <870513-194807-3030@Xerox>
Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error.


Well in fact, many people would say that surely a concept such as
'height' is NOT the same when talking about different sorts of things.

For example:

(height (make-instance 'elm-tree))              ;in FEET

(height (font-ref *default-hardcopy-font* #\a)) ;in INCHES

(height (make-instance 'window))                ;in PIXELS

They are really quite different.


Now some people are willing to overload the single generic function
height to be able to have all these different meanings.

Other consider that bad style, and would have window-height be a
generic-function which returns the height of any kind of window;
hardcopy-height be the generic-function which returns the height of
anything that can be sent to a hardcopy stream etc.

 It is clear that both of these positions are reasonable.  In fact, when
you want to do it one way versus another depends on lots of factors like
the size of the module you are working on.  Whether the symbols in
question will be exported or imported etc.

:accessor-prefix in CLOS is designed to make it easy to program in
either of those styles.

Note that using (:accessor-prefix nil) is the way to get the behavior
you like. 

∂14-May-87  0854	cperdue@Sun.COM 	Re: CLX draft 3 revisions   
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 14 May 87  08:54:38 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2)
	id AA09631; Thu, 14 May 87 08:51:07 PDT
Received: from clam.sun.uucp by snail.sun.com (3.2/SMI-3.2)
	id AA28978; Thu, 14 May 87 08:50:41 PDT
Received: by clam.sun.uucp (3.2/SMI-3.0DEV3)
	id AA12964; Thu, 14 May 87 08:55:42 PDT
Date: Thu, 14 May 87 08:55:42 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8705141555.AA12964@clam.sun.uucp>
To: Gregor.pa@Xerox.COM, harris%hplwhh@hplabs.HP.COM
Subject: Re: CLX draft 3 revisions
Cc: CL-Object-Oriented-Programming@SAIL.STANFORD.EDU,
        Oren%Tilde%ti-csl.CSNet@relay.cs.net, RWS@ZERMATT.LCS.MIT.EDU,
        cl-windows@SAIL.STANFORD.EDU

  Well in fact, many people would say that surely a concept such as
  'height' is NOT the same when talking about different sorts of things.
  
  For example:
  
  (height (make-instance 'elm-tree))              ;in FEET
  
  (height (font-ref *default-hardcopy-font* #\a)) ;in INCHES
  
  (height (make-instance 'window))                ;in PIXELS

Looks more like an issue of units than an issue of datatype to me.

∂14-May-87  0900	harris%hplwhh@hplabs.HP.COM 	Re: CLX draft 3 revisions 
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 14 May 87  09:00:11 PDT
Received: from hplms1 by hplabs.HP.COM with TCP ; Thu, 14 May 87 08:57:56 pdt
Received: from hplwhh (hplwhh) by hplms1; Thu, 14 May 87 08:57:34 pdt
Return-Path: <harris@hplwhh>
Received: from hplwhh.hpl.hp.com by hplwhh ; Thu, 14 May 87 08:57:17 pdt
Message-Id: <8705141557.AA02962@hplwhh>
To: Gregor.pa@Xerox.COM
Cc: Oren%Tilde%ti-csl.CSNet@relay.cs.net, RWS@ZERMATT.LCS.MIT.EDU,
        cl-windows@SAIL.STANFORD.EDU,
        CL-Object-Oriented-Programming@SAIL.STANFORD.EDU
Subject: Re: CLX draft 3 revisions 
In-Reply-To: Your message of 13 May 87 19:47:00 -0700.
             <870513-194807-3030@Xerox> 
Date: Thu, 14 May 87 08:57:10 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

Thanks for your response.  I hadn't thought about accessors like
HEIGHT differing by their units, but differing in concept (e.g. one
application's generic-function DISPLAY which takes a window and
returns its associated display object, and another application's
DISPLAY which takes an object, and a stream and draws the object).  I
didn't really consider the former as requiring different accessors,
but the latter should obviously be separated by packages,
accessor-prefixes or individual names for the two operations.  My gut
feeling was that prefixes shouldn't be used unless needed because they
ruin the genericness of the accessor (why should I have separate
functions for ELM-TREE-HEIGHT, PERSON-HEIGHT and FONT-HEIGHT?).  But
perhaps you're right -- why confuse the user.

Warren

∂14-May-87  1054	Gregor.pa@Xerox.COM 	Re: CLX draft 3 revisions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 May 87  10:54:47 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 MAY 87 10:47:15 PDT
Date: 14 May 87 10:44 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: CLX draft 3 revisions 
In-reply-to: Dan Carnese <CARNESE@SPAR-20.ARPA>'s message of Thu, 14 May
 87 10:21:55 PDT
To: CARNESE@SPAR-20.ARPA
cc: harris%hplwhh@hplabs.hp.com, Gregor.pa@Xerox.COM,
 Oren%Tilde%ti-csl.CSNet@relay.cs.net, RWS@ZERMATT.LCS.MIT.EDU,
 cl-windows@SAIL.STANFORD.EDU,
 CL-Object-Oriented-Programming@SAIL.STANFORD.EDU
Message-ID: <870514-104715-3566@Xerox>

    From: Dan Carnese <CARNESE@SPAR-20.ARPA>
    Subject: Re: CLX draft 3 revisions 

    A basic problem with function names that include class names,
    such as font-height, is that it is bad for extensibility.  When
    subclasses of the existing class are defined, e.g., adobe-font,
    users of those subclasses will have to remember which ancestor
    class must be used to construct the name of the function.  This
    makes such systems more difficult to learn and increases the
    incidence of trivial but annoying programming errors.

Don't think of names like window-height as including the name of a
class.  You should think of these as including the name of a protocol
(eg the window protocol).

Notice that the :accessor-prefix option in CLOS has no default value.
In particular, it doesn't default to the name of the class followed by a
"-".  This was done to explictly avoid any automatic mapping from
class-names to accessor-prefix.

As for packages, they may sometimes be helpful for this problem.  But as
I said in my earlier message, it depends on lots of things, like the
size of the module.  For example, one could imagine a graphics package
which had lots of different kinds of windows and lots of different kinds
of graphics objects.  Within the GRAPHICS package, it might be
appropriate to have 2 generic functions, window-height for all kinds of
windows and graphics-object-height for all kinds of graphics objects.

∂14-May-87  1031	CARNESE@SPAR-20.ARPA 	Re: CLX draft 3 revisions   
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87  10:31:05 PDT
Date: Thu 14 May 87 10:21:55-PDT
From: Dan Carnese <CARNESE@SPAR-20.ARPA>
Subject: Re: CLX draft 3 revisions 
To: harris%hplwhh@hplabs.hp.com
cc: Gregor.pa@XEROX.COM, Oren%Tilde%ti-csl.CSNet@RELAY.CS.NET,
    RWS@ZERMATT.LCS.MIT.EDU, cl-windows@SAIL.STANFORD.EDU,
    CL-Object-Oriented-Programming@SAIL.STANFORD.EDU
In-Reply-To: <8705141557.AA02962@hplwhh>
Message-ID: <12302345450.16.CARNESE@SPAR-20.ARPA>


    Date: Thu, 14 May 87 08:57:10 PDT
    From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

    Thanks for your response.  I hadn't thought about accessors like
    HEIGHT differing by their units, but differing in concept (e.g. one
    application's generic-function DISPLAY which takes a window and
    returns its associated display object, and another application's
    DISPLAY which takes an object, and a stream and draws the object).  I
    didn't really consider the former as requiring different accessors,
    but the latter should obviously be separated by packages,
    accessor-prefixes or individual names for the two operations.  My gut
    feeling was that prefixes shouldn't be used unless needed because they
    ruin the genericness of the accessor (why should I have separate
    functions for ELM-TREE-HEIGHT, PERSON-HEIGHT and FONT-HEIGHT?).

The need to distinguish is clear.  The question is which language structure
is appropriate to realize the distinction.  

A number of concepts, such as height and width, can be viewed as "the same"
for a number of different clx objects.  Thus, it makes sense to use one
symbol to denote the concept, and thus to have one function name apply to a
number of different clx classes.  By placing such symbols in the clx
package, different applications are not precluded from using symbols with
the same name, e.g., arboretum:height, to identify different concepts.

A basic problem with function names that include class names, such as
font-height, is that it is bad for extensibility.  When subclasses of the
existing class are defined, e.g., adobe-font, users of those subclasses
will have to remember which ancestor class must be used to construct the
name of the function.  This makes such systems more difficult to learn and
increases the incidence of trivial but annoying programming errors.

A possible reason for retaining class-specific accessor names is to achieve
maximal efficiency.  If that is indeed the case, then both the "generic"
functions and the class-specific functions should be available.

-- Dan
-------

∂14-May-87  1207	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	re: geometry accessors   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87  12:07:49 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 14 May 87 15:07-EDT
Date: Thu, 14 May 87 15:07 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: re: geometry accessors
To: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2756929653-5689439@SI>
Message-ID: <870514150711.2.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Wed, 13 May 87  16:47:33 CDT
    From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>

    Since you've got:
      drawable-depth ...

    How about getting rid of:
      window-depth ...
    and
      pixmap-depth ...

I figured this would generate comments.  At least I know people are
still reading and listening.

If you want to think of the drawable-<mumble>s as the generic functions,
that's fine.  If you want to drop the "drawable-" prefix, I guess we can
argue about that.  Since I think of drawables as different from other
things (like fonts), I would rather retain the prefix.  So all we are
really arguing about is whether the type specializations to window and
pixmap should exist.  I don't have (and haven't heard) any particularly
strong arguments either way.  The specializations do serve as an
indication that the drawable- functions are the union of functionality.
That is, pixmaps don't really have x, y, and border-width, but "natural"
values have been defined.

Performance of the generic functions in non-CLOS is not a big issue
(although typecase on structure types is pretty expensive in some
implementations), since all graphics functions take drawables already.
But I haven't been convinced yet that CLOS integration with respect to
subtyping, etc. is very important either.  That is, CLX objects for the
most part seem better suited as instance variables in higher-level
objects, rather than as base types.

∂14-May-87  1216	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: CLX draft 3 revisions  
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 14 May 87  12:16:27 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 81714; Thu 14-May-87 14:29:13 EDT
Date: Thu, 14 May 87 14:28 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: CLX draft 3 revisions 
To: CARNESE@SPAR-20.ARPA, harris%hplwhh@hplabs.hp.com
cc: Gregor.pa@XEROX.COM, Oren%Tilde%ti-csl.CSNet@RELAY.CS.NET, RWS@ZERMATT.LCS.MIT.EDU,
    cl-windows@SAIL.STANFORD.EDU, CL-Object-Oriented-Programming@SAIL.STANFORD.EDU
In-Reply-To: <12302345450.16.CARNESE@SPAR-20.ARPA>
Message-ID: <870514142801.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No

    Date: Thu 14 May 87 10:21:55-PDT
    From: Dan Carnese <CARNESE@SPAR-20.ARPA>

    A basic problem with function names that include class names, such as
    font-height, is that it is bad for extensibility.  When subclasses of the
    existing class are defined, e.g., adobe-font, users of those subclasses
    will have to remember which ancestor class must be used to construct the
    name of the function.  This makes such systems more difficult to learn and
    increases the incidence of trivial but annoying programming errors.

Right.  This is exactly why CLOS does not use the class name as the
accessor prefix.  Instead, the writer of the defclass has to specify the
prefix, and the intention is that the prefix be specified according to
the protocol that the class implements, rather than the name of the
class.

∂14-May-87  1354	harris%hplwhh@hplabs.HP.COM 	Re: geometry accessors    
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 14 May 87  13:54:36 PDT
Received: from hplms1 by hplabs.HP.COM with TCP ; Thu, 14 May 87 13:53:01 pdt
Received: from hplwhh (hplwhh) by hplms1; Thu, 14 May 87 13:52:37 pdt
Return-Path: <harris@hplwhh>
Received: from hplwhh.hpl.hp.com by hplwhh ; Thu, 14 May 87 13:52:16 pdt
Message-Id: <8705142052.AA03263@hplwhh>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: geometry accessors 
In-Reply-To: Your message of Thu, 14 May 87 15:07:00 -0400.
             <870514150711.2.RWS@KILLINGTON.LCS.MIT.EDU> 
Date: Thu, 14 May 87 13:52:03 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

> But I haven't been convinced yet that CLOS integration with respect to
> subtyping, etc. is very important either.  That is, CLX objects for the
> most part seem better suited as instance variables in higher-level
> objects, rather than as base types.

I see no reason why CLX objects can't be the starting point for higher
level functionality.  I've spent the last few months doing just that
-- defining increasingly higher levels of window types from an
object-oriented extension to the structures provided by the C Xlib.
I've found that my primitive type, basic-window (basically the same as
a CLX window), can be specialized into windows with scroll-bars,
windows which contain graphical-object buffers, emacs-buffer-windows,
etc.  I would hope that CLX is being designed with exactly this
functionality in mind -- the ability to allow its primitive data types
to be specialized.  This is exactly what is missing from C Xlib, which
is why the programmer is forced to either define "higher-level
objects" which contain Xlib structs or design specific functions for
manipulating application specific window configurations.  This is
hardly a reusable or efficient (in terms of programmer time) solution.
It's rare that you find an application that simply wants a window with
borders -- often times there are subwindows with special relationships
between them.  Specifying and specializing these relationships is a
perfect candidate for object-oriented programming.  Just take a look
at the Symbolics window system.

Warren

P.S.  My window library uses :accessor-prefix nil!

∂14-May-87  1359	CARNESE@SPAR-20.ARPA 	Re: CLX draft 3 revisions   
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87  13:59:08 PDT
Date: Thu 14 May 87 13:45:40-PDT
From: Dan Carnese <CARNESE@SPAR-20.ARPA>
Subject: Re: CLX draft 3 revisions 
To: cl-windows@SAIL.STANFORD.EDU,
    cl-object-oriented-programming@SAIL.STANFORD.EDU
In-Reply-To: <8705140155.AA02460@hplwhh>
Message-ID: <12302382544.16.CARNESE@SPAR-20.ARPA>


    Date: Wed, 13 May 87 18:55:35 PDT
    From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

    > Since you've got:
    >   drawable-depth, drawable-root, drawable-x, drawable-y, drawable-width,
    >   drawable-height, drawable-border-width
    > 
    > How about getting rid of:
    >   window-depth, window-root, window-x, window-y, window-width,
    >   window-height, window-border-width
    > and
    >   pixmap-depth, pixmap-root, pixmap-width, pixmap-height
    > 
    >   -LaMott

    With the advent of generic functions, I don't see why we need to
    prefix these accessors with their types anyway.  Why not just: DEPTH,
    ROOT, X, Y, WIDTH, HEIGHT, and BORDER-WIDTH?  (I know X and Y aren't
    very good function names, so how about LEFT and TOP with slots renamed
    accordingly.)  In the mean time (before generic-functions are
    available), these functions can be built from typecase statements.

    Warren

    P.S.  CLOS committee -- why all this :accessor-prefix stuff?  Since
    methods always do the "right thing" we need no longer resort to clever
    naming schemes in order that our programs do the right thing.  Surely
    a concept such as HEIGHT is the same regardless of whether we're
    talking about windows, fonts, displays, etc.

Two issues are raised here: how should specific pieces of clx functionality
be named and what good are accessor prefixes anyway?  I was addressing the
former, not the latter.  My claim was that for the above-named functions, a
single "X" in the clx package can reasonably represent the functionality of
"drawable-X", "window-X", and "pixmap-X".

As far as the appropriateness of prefixes, I think it's fair to say that
their use is a matter of personal style.  Since many people do find
prefixes useful, it is entirely appropriate to have them be a language
feature.  But I think it's also fair to say that if there were better
integration between the realizations of "class", "package", and "module" in
Common Lisp, the use of prefixes would be far less widespread.  I'm sure
this will happen -- it just hasn't happened yet.
-------

∂14-May-87  1439	schultz@nrl-aic.ARPA 	Please remove...  
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87  14:38:55 PDT
Return-Path: <schultz>
Received: Thu, 14 May 87 17:18:56 edt by nrl-aic.ARPA id AA22697
Date: Thu, 14 May 87 17:18:56 edt
From: Alan Schultz <schultz@nrl-aic.ARPA>
Message-Id: <8705142118.AA22697@nrl-aic.ARPA>
To: CARNESE@SPAR-20.ARPA
Cc: cl-windows@SAIL.STANFORD.EDU,
        cl-object-oriented-programming@SAIL.STANFORD.EDU
In-Reply-To: Dan Carnese's message of Thu 14 May 87 13:45:40-PDT <12302382544.16.CARNESE@SPAR-20.ARPA>
Subject: Please remove...

I don't know whose responsible, but I should not be on this mailing list.
Please remove me. (Sorry for sending this to everyone, but I'm not sure
who to tell.) --Alan C. Schultz

∂18-May-87  0456	RWS@ZERMATT.LCS.MIT.EDU 	geometry accessors and etc.   
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 May 87  04:55:10 PDT
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 51171; Mon 18-May-87 07:54:35 EDT
Date: Mon, 18 May 87 07:55 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: geometry accessors and etc.
To: cl-windows@sail.stanford.edu
Message-ID: <870518075508.9.RWS@KILLINGTON.LCS.MIT.EDU>

I'm not sure I have heard a consensus on this issue.  There seem to be
those that think a prefix is desirable, and those that think it is
unnecessary (or undesirable) but apparently don't have violent
objections to it.

So, my interpretation is that the drawable-<mumble> accessors should
stay, the window-<mumble> and pixmap-<mumble> accessors should go, and
the window-<mumble> setfs should be renamed to drawable-<mumble> setfs,
but with the argument explicitly declared as window, rather than
drawable.

Is this acceptable?


Anyone want to tell me what NIL should do in the gcontext-clip-mask setf?

Have we basically reached closure on all major issues?  minor issues?

BTW, a generous person has apparently made considerable progress on a
public implementation.  More details as they become available.

∂18-May-87  1256	MMcM@STONY-BROOK.SCRC.Symbolics.COM 	Re: geometry accessors 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 May 87  12:56:26 PDT
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 142668; Mon 18-May-87 15:50:27 EDT
Date: Mon, 18 May 87 15:49 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: geometry accessors 
To: Warren Harris <harris%hplwhh@hplabs.HP.COM>
cc: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <8705142052.AA03263@hplwhh>
Message-ID: <870518154932.3.MMCM@OWL.SCRC.Symbolics.COM>

    Date: Thu, 14 May 87 13:52:03 PDT
    From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

    I see no reason why CLX objects can't be the starting point for higher
    level functionality.  I've spent the last few months doing just that
    -- defining increasingly higher levels of window types from an
    object-oriented extension to the structures provided by the C Xlib.

I must concur with RWS on this.  As I've tried to point out in earlier
messages, you mustn't confuse the X window with the higher level
application window, which I've called a window stream.  The former is
just a handle for a piece of hierarchical real-estate inside the virtual
console.  Its behavior is pretty much constrained by that protocol.  It's
the latter whose behavior you wish to refine.

The X window is a valid piece of state of the window stream, as are the
graphics state block (GContext), TTY cursor position, mapping from
abstract character attributes to fonts, output history, and so on.
As such it makes sense being an instance variable, not the basic flavor.

If you wish to allow for situations such as a window manager running
only within the X context, then you cannot expect it to have access to
any higher level window semantics, because the window stream may not be
within its address space.  If, on the other hand, you assume that the
window manager should access the window stream (perhaps only when
possible), or that a method on the window stream should be the first
agent in the sequence for client-side event processing, then you have
instituted a design philosophy which in my opinion does not belong in
this lowest layer.

		   Specifying and specializing these relationships is a
    perfect candidate for object-oriented programming.  Just take a look
    at the Symbolics window system.

I should also point out that the message passing LISP machine window
system has a big pitfall.  One must be crystal clear on the contract of
those messages, i.e. on the window protocol.  In some cases, this is
done reasonably well; for example, there is a proper distinction between
:SET-EDGES and :CHANGE-OF-SIZE-OR-MARGINS.  However, no such factoring
out has been done for :EXPOSE.  This makes the interposition of
application specific behavior problematic, and quite subject to the
whims on flavor method combination.  For similar reasons, I object to
the methodology in some window systems of building cursor-following
graphics by means of daemons on the fundamental graphics methods.  By
doing so, you completely muddle the contract of those methods, and almost
guarantee that 50% of the graphics library routines you might want to
call won't work in your window.

I feel no particular shame in admitting any of this, as it was almost
ten years ago when a few of us designed the CADR "new" window system. 
We are coming up on the time when we can learn from our experiences and
do better.

∂21-May-87  1437	harris%hplwhh@hplabs.HP.COM 	Re: geometry accessors    
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 21 May 87  14:36:39 PDT
Received: from hplms1 by hplabs.HP.COM with TCP ; Thu, 21 May 87 11:54:20 pdt
Received: from hplwhh (hplwhh) by hplms1; Thu, 21 May 87 11:53:05 pdt
Return-Path: <harris@hplwhh>
Received: from hplwhh.hpl.hp.com by hplwhh ; Thu, 21 May 87 11:50:29 pdt
Message-Id: <8705211850.AA09659@hplwhh>
To: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Warren Harris <harris%hplwhh@hplabs.HP.COM>,
        Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>,
        cl-windows@SAIL.STANFORD.EDU, harris%hplwhh@hplabs.HP.COM
Subject: Re: geometry accessors 
In-Reply-To: Your message of Mon, 18 May 87 15:49:00 -0400.
             <870518154932.3.MMCM@OWL.SCRC.Symbolics.COM> 
Date: Thu, 21 May 87 11:50:23 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

It seems to me that you're making an argument against object-oriented
programming, not low-level window system protocols.  The major thesis of
you message seems to state that since you can't guarantee the semantics of
a specialized method you shouldn't allow them.

Whether or not CLX is implemented in an object oriented fashion is
irrelevant to the functionality we wish to accomplish with it.  However, I
see no cause for restricting the user from augmenting or modifying the
semantics of CLX via object-oriented programming if he so desires.  By
permitting this we eliminate the need to define yet another low-level
protocol -- the root of the "window-stream" object hierarchy.

As far as the window manager goes, I thought it was a client just like any
other application, making requests to the server.  The X server is what
exists in another address space, and has its own notion of what a window is
(defined by X11).  I thought we were just trying to define a library of
routines which also made requests to this server. If the user wants to
define higher level library calls via object-oriented programming, let him.
At some level shouldn't they all filter down into well-defined requests to
the server?  And if he wants to define specialized event handler methods
(like for expose-window) why shouldn't this also be permitted.  Unlike the
lisp machine window system, the server is protected from unruly clients.

∂22-May-87  1333	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: geometry accessors   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 May 87  13:33:29 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 22 May 87 16:25-EDT
Date: Fri, 22 May 87 16:26 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: geometry accessors 
To: harris%hplwhh@hplabs.HP.COM, MMcM@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <8705211850.AA09659@hplwhh>
Message-ID: <870522162618.2.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Thu, 21 May 87 11:50:23 PDT
    From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

    It seems to me that you're making an argument against object-oriented
    programming, not low-level window system protocols.  The major thesis of
    you message seems to state that since you can't guarantee the semantics of
    a specialized method you shouldn't allow them.

I could be confused, but ...

It seems to me the disagreement is fairly simple to state.  It would
seem that you believe it is OK if the "next layer up" remains X-specific
in both windowing and graphics.  Others, I believe, are arguing that the
next layer up should explicitly be X-independent.  It ought to work
equally well as an interface to other (existing) "window systems".  X
has its own "peculiar" way of looking at the world, and it isn't
necessarily the way a programmer wants to see it.  For example, the
general borders notion found in the lispm window systems might be best
achieved with nested windows in X, and it might be desirable to abstract
out the existence of these "extra" windows.  Other examples relating to
graphics have previously been cited.  All of these seem to be generally
characterized by the desire to take multiple X objects and make them a
single object at the next higher level, and this new object isn't
clearly an implementation-subtype of any single X object.

I suspect that more explicit expression on both sides about what the
next layer up should or shouldn't be would help a lot.

∂25-May-87  1503	MMcM@STONY-BROOK.SCRC.Symbolics.COM 	Re: geometry accessors 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 May 87  15:02:39 PDT
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 151212; Mon 25-May-87 17:58:29 EDT
Date: Mon, 25 May 87 17:58 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: geometry accessors 
To: Warren Harris <harris%hplwhh@hplabs.HP.COM>, Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <8705211850.AA09659@hplwhh>,
             <870522162618.2.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870525175823.1.MMCM@OWL.SCRC.Symbolics.COM>

    Date: Thu, 21 May 87 11:50:23 PDT
    From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

    It seems to me that you're making an argument against object-oriented
    programming, not low-level window system protocols.  The major thesis of
    you message seems to state that since you can't guarantee the semantics of
    a specialized method you shouldn't allow them.

That isn't what I meant to say at all.  You can indeed guarantee the
semantics of a specialized method -- and in fact it is crucially
important to the correct functioning of the window system as an
integrated whole that you do so.  For this reason, it is terribly
important that you get the modular layers straight.

									By
    permitting this we eliminate the need to define yet another low-level
    protocol -- the root of the "window-stream" object hierarchy.

I want to stress the important of defining that root of the
window-stream object hierarchy.  I am afraid that failing to do so by
letting it just lie on top of CLX will cause problems down the road.
You should not eliminate the need to define the protocol.

		       I thought we were just trying to define a library of
    routines which also made requests to this server. If the user wants to
    define higher level library calls via object-oriented programming, let him.

I agree with all this.  It's more or less what I was attempting to say.
The point is that the object orientation should be recognized as a
higher level library and not confused as an extension of the client
semantics which are 100% dictated by the protocol definition.

    Date: Fri, 22 May 87 16:26 EDT
    From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>

	Date: Thu, 21 May 87 11:50:23 PDT
	From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

	It seems to me that you're making an argument against object-oriented
	programming, not low-level window system protocols.  The major thesis of
	you message seems to state that since you can't guarantee the semantics of
	a specialized method you shouldn't allow them.

    I could be confused, but ...

    It seems to me the disagreement is fairly simple to state.  It would
    seem that you believe it is OK if the "next layer up" remains X-specific
    in both windowing and graphics.  Others, I believe, are arguing that the
    next layer up should explicitly be X-independent.  It ought to work
    equally well as an interface to other (existing) "window systems".  X
    has its own "peculiar" way of looking at the world, and it isn't
    necessarily the way a programmer wants to see it.  For example, the
    general borders notion found in the lispm window systems might be best
    achieved with nested windows in X, and it might be desirable to abstract
    out the existence of these "extra" windows.  Other examples relating to
    graphics have previously been cited.  All of these seem to be generally
    characterized by the desire to take multiple X objects and make them a
    single object at the next higher level, and this new object isn't
    clearly an implementation-subtype of any single X object.

Yes.  That is a more direct statement of one of my points.  As I have
pointed out in previous messages, a higher level window stream is not
only a combination of a X window and a graphics context, it is also
often more than one X windows (in particular a subtree).  Also, the
integration of streams and windowing need not preclude implementation in
low-level imagine protocols other than X11.

    I suspect that more explicit expression on both sides about what the
    next layer up should or shouldn't be would help a lot.

Let me try to be clear on what I am saying about object-oriented CLX.  I
have no particular objection to it.  It is perfectly valid programming
practice to eschew structures altogether.  My point is just that you
have to be exactly as clear on the semantics of the protocols on the
next higher levels are you are on the lowest CLX levels.  For this
reason, and the general desire to make the higher levels independent of
their implementation in terms of the lower, I don't see much gain by
making CLX windows be EQ to window streams.

∂25-May-87  1927	@Riverside.SCRC.Symbolics.COM,@DIAL|16177312506,@NUMBER-2.MMCM.Symbolics.COM:MMcM@NUMBER-2.MMCM.Symbolics.COM 	Re: geometry accessors  
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 25 May 87  19:26:59 PDT
Received: from NUMBER-2.MMCM.Symbolics.COM (DIAL|16177312506) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 127841; 25 May 87 22:13:01 EDT
Date: Mon, 25 May 87 22:00 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: geometry accessors 
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870522162618.2.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870525220051.5.MMCM@NUMBER-2.MMCM.Symbolics.COM>

    Date: Fri, 22 May 87 16:26 EDT
    From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
    I suspect that more explicit expression on both sides about what the
    next layer up should or shouldn't be would help a lot.

I am sending this along separately because of the problems I know some
people have with following complex dialogues.

At the risk of boring everyone by saying exactly what I've said before
and nothing new, here is my understanding of the pieces that go into
making up the window system component of a modern LISP system.

(1) The semantic definition of the virtual console.  This is exactly
what X v11 is.  It defines concepts like mapped or input focus.  It is
done independently of any particular language binding because of the
need (a) for different interconnection paradigms, both networked and
local and (b) for the peaceful coexistence of windows controlled by
different language modules on the same workstation.

(2) The LISP language binding of (1).  This is exactly what CLX is.  It
maps the abstract data structures of X into the (less abstract) data
structures of LISP.  It maps the abstract control structures of X into
the control structures of LISP.

(3) The semantic definition of an integration of streams (as defined in
chapters 21 and 22 of Steele) and windows (as abstract pieces of real
estate) and objects (as defines by CLOS).  This defines concepts such as
cursor position or newline height.

(4) The mapping of (3) onto (2).  This is not a substitute for getting
(3) right by itself.  It serves as an implementation guide.  It can be
either in the form of documentation or an actual semi-portable
implementation itself.

(5 and beyond) An integration of procedural graphics, and user interface
management systems with the layers described above.  I won't go into
this any further, since it will only confuse the issue.

Some notes on these points:

- I am not arguing against object-oriented programming.  It is the ideal
tool for getting this job done.  I cannot imagine doing it without
something like CLOS.  I despair at the proposed definition of things
like X Toolkit because it can only grope at a true object orientation
within the confines of portable C.  But object orientation is not an
excuse for not defining protocols clearly.  It must be used as a means
toward good modularity, not a bypass around all modularity.

- I am not opposed to low-level windowing standards.  I feel that most
programmers, given the choice, would program at the proper level of
abstraction, namely in terms of the higher level stream-oriented
windows.  However, the existence of the higher level is not an
indictment of the lower level.  The latter is essential for getting the
former right.  Sometimes even an application must program in the lower
levels.  When it does so, it necessarily gives up some amount of
portability by latching onto some implementation's concepts.  This is
not always operating system dependence, it can also be low-level window
system dependence, as X against some other proprietary system, e.g. NewS.

- The existence of the standard LISP language binding for X v11, in the
form of CLX, does not preclude other virtual consoles within LISP.
Entirely analogously, the existence of a FORTRAN binding for GKS does
not preclude a FORTRAN binding for PHIGS.  CLX says how to access an X
server from LISP, assuming a priori that you have decided that this is
the means you desire for virtual console control (for instance because
that is the only means the system you are using provides).

- The existence of a well defined window stream interface does not
preclude an application interfacing directly to the lower virtual
console layer instead.  Some systems may make this more difficult than
others, by for instance having a window manager that requires an onto
mapping from X windows to window streams.

- There is a boundary at the root of the window stream protocol below
which semantics are not defined inside that layer.  For instance, window
streams define how to access a character stream intended as input for a
particular window stream.  They may not define how to multiplex the
shared resource of the workstation keyboard among the possible window
streams.  This boundary corresponds approximately to the highest layer
of the virtual console.  However, it does not limit the amount of work
that can be done by means of the lower layers directly.

- The modular separation I am proposing of CLX / window streams / UIMS
is not identical to the separation between of the C XLib / X Toolkit.
One thing that should be kept in mind is that it is not necessary to
agree on the complete semantics of any layer to recognize what layer a
particular functionality belongs in.  For example, I would put a
function for choosing from a pop-up/pull-down menu in the UIMS category.
However, I am quite sure that we could agree on a function name and
calling sequence for it long before much of anything else in that
category.  We should not be compelled to misplace it into the window
stream layer just because we want to agree on it earlier on.

- Using separate objects to represent data objects within the virtual
console from window streams makes the modular separation crystal clear.
Defining a protocol for the simplest window stream involves no
duplication of effort, because where one protocol leaves off the other
takes up.

- I do not see an unambiguous identity between any single pair of
objects in the two layers.

- I find the need for the object system compelling for any
implementation of window streams.  I do not find such compelling need
for the case of CLX itself, because the semantics are so well restricted
by the protocol definition.
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: geometry accessors 
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870522162618.2.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Fri, 22 May 87 16:26 EDT
    From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
    I suspect that more explicit expression on both sides about what the
    next layer up should or shouldn't be would help a lot.

I am sending this along separately because of the problems I know some
people have with following complex dialogues.

At the risk of boring everyone by saying exactly what I've said before
and nothing new, here is my understanding of the pieces that go into
making up the window system component of a modern LISP system.

(1) The semantic definition of the virtual console.  This is exactly
what X v11 is.  It defines concepts like mapped or input focus.  It is
done independently of any particular language binding because of the
need (a) for different interconnection paradigms, both networked and
local and (b) for the peaceful coexistence of windows controlled by
different language modules on the same workstation.

(2) The LISP language binding of (1).  This is exactly what CLX is.  It
maps the abstract data structures of X into the (less abstract) data
structures of LISP.  It maps the abstract control structures of X into
the control structures of LISP.

(3) The semantic definition of an integration of streams (as defined in
chapters 21 and 22 of Steele) and windows (as abstract pieces of real
estate) and objects (as defines by CLOS).  This defines concepts such as
cursor position or newline height.

(4) The mapping of (3) onto (2).  This is not a substitute for getting
(3) right by itself.  It serves as an implementation guide.  It can be
either in the form of documentation or an actual semi-portable
implementation itself.

(5 and beyond) An integration of procedural graphics, and user interface
management systems with the layers described above.  I won't go into
this any further, since it will only confuse the issue.

Some notes on these points:

- I am not arguing against object-oriented programming.  It is the ideal
tool for getting this job done.  I cannot imagine doing it without
something like CLOS.  I despair at the proposed definition of things
like X Toolkit because it can only grope at a true object orientation
within the confines of portable C.  But object orientation is not an
excuse for not defining protocols clearly.  It must be used as a means
toward good modularity, not a bypass around all modularity.

- I am not opposed to low-level windowing standards.  I feel that most
programmers, given the choice, would program at the proper level of
abstraction, namely in terms of the higher level stream-oriented
windows.  However, the existence of the higher level is not an
indictment of the lower level.  The latter is essential for getting the
former right.  Sometimes even an application must program in the lower
levels.  When it does so, it necessarily gives up some amount of
portability by latching onto some implementation's concepts.  This is
not always operating system dependence, it can also be low-level window
system dependence, as X against some other proprietary system, e.g. NewS.

- The existence of the standard LISP language binding for X v11, in the
form of CLX, does not preclude other virtual consoles within LISP.
Entirely analogously, the existence of a FORTRAN binding for GKS does
not preclude a FORTRAN binding for PHIGS.  CLX says how to access an X
server from LISP, assuming a priori that you have decided that this is
the means you desire for virtual console control (for instance because
that is the only means the system you are using provides).

- The existence of a well defined window stream interface does not
preclude an application interfacing directly to the lower virtual
console layer instead.  Some systems may make this more difficult than
others, by for instance having a window manager that requires an onto
mapping from X windows to window streams.

- There is a boundary at the root of the window stream protocol below
which semantics are not defined inside that layer.  For instance, window
streams define how to access a character stream intended as input for a
particular window stream.  They may not define how to multiplex the
shared resource of the workstation keyboard among the possible window
streams.  This boundary corresponds approximately to the highest layer
of the virtual console.  However, it does not limit the amount of work
that can be done by means of the lower layers directly.

- The modular separation I am proposing of CLX / window streams / UIMS
is not identical to the separation between of the C XLib / X Toolkit.
One thing that should be kept in mind is that it is not necessary to
agree on the complete semantics of any layer to recognize what layer a
particular functionality belongs in.  For example, I would put a
function for choosing from a pop-up/pull-down menu in the UIMS category.
However, I am quite sure that we could agree on a function name and
calling sequence for it long before much of anything else in that
category.  We should not be compelled to misplace it into the window
stream layer just because we want to agree on it earlier on.

- Using separate objects to represent data objects within the virtual
console from window streams makes the modular separation crystal clear.
Defining a protocol for the simplest window stream involves no
duplication of effort, because where one protocol leaves off the other
takes up.

- I do not see an unambiguous identity between any single pair of
objects in the two layers.

- I find the need for the object system compelling for any
implementation of window streams.  I do not find such compelling need
for the case of CLX itself, because the semantics are so well restricted
by the protocol definition.


∂02-Jun-87  1238	@RELAY.CS.NET:Oren%Tilde@TI-CSL.CSNET 	font-char-info  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 2 Jun 87  12:38:38 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac14189; 2 Jun 87 12:48 EDT
Received: from ti-csl by RELAY.CS.NET id ac24086; 2 Jun 87 12:46 EDT
Received: by tilde id AA00347; Tue, 2 Jun 87 10:44:42 CDT
Message-Id: <2758635907-4127499@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Tue, 2 Jun 87  10:45:07 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: cl-windows@SAIL.STANFORD.EDU
Subject: font-char-info

FONT-CHAR-INFO is defined to return a CHAR-INFO structure.  If font
char-info's are stored as a vector of unnamed structures, it will take 5
words per character.  If char-info's are stored packed in an array, only
3 words per character are used, but 5 words would have to be consed up
by FONT-CHAR-INFO to return the data, and FONT-CHAR-INFOS gets really
ugly. How about adding a font parameter to the "char-" accessors:

(DEFUN char-width (font char &optional second-byte)
  (declare (type font font)
	   (type (or integer character (member :min :max)) char)
	   (type (or integer character) second-byte) ;; for 16 bit fonts
	   (values integer)))

(DEFUN char-ascent (font char &optional second-byte) ...)
(DEFUN char-descent (font char &optional second-byte) ...)
(DEFUN char-left-bearing (font char &optional second-byte) ...)
(DEFUN char-right-bearing (font char &optional second-byte) ...)
(DEFUN char-attributes (font char &optional second-byte) ...)

Note that these will take a character type, where the original CLX
functions only took integers.  We could get rid of font-char-info,
font-char-infos, font-char16-info, font-min-bounds font-max-bounds,
font-info-min-bounds and font-info-max-bounds.

Also, how about getting rid of the font-info structure, and
font-font-info.  This seems like a useless abstraction, since
there are font-<name> accessors for all the font-info fields.

  LaMott

∂03-Jun-87  0126	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: [LaMott Oren <Oren@Tilde.ti>:  font-char-info]   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 3 Jun 87  01:26:53 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aj24084; 3 Jun 87 4:22 EDT
Received: from ti-csl by RELAY.CS.NET id ah28693; 3 Jun 87 4:17 EDT
Received: by tilde id AA09550; Tue, 2 Jun 87 15:00:58 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 2 Jun 87  15:03:55 CDT
Message-Id: <2758651286-3361190@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Tue, 2 Jun 87  15:01:26 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: [LaMott Oren <Oren@Tilde.ti>:  font-char-info]
In-Reply-To: Msg of Tue, 2 Jun 87  10:49:34 CDT from LaMott Oren <Oren@Tilde.ti>

Good thinn'n, Baba Louie! Agreed on each of your suggestions (font parameter for
char- accessors, use of character type parameters, consolidation of 8- and
16-bit char set accessors, and elimination of font-info defstruct.)

∂03-Jun-87  0729	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	font-char-info 
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87  07:06:20 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 3 Jun 87 10:05-EDT
Date: Wed, 3 Jun 87 10:05 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: font-char-info
To: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2758635907-4127499@SI>
Message-ID: <870603100518.3.RWS@KILLINGTON.LCS.MIT.EDU>

    FONT-CHAR-INFO is defined to return a CHAR-INFO structure.

Just to be clear, it isn't required to be a structure (in the sense of
defstruct), just an object with accessor-like functions.

								If font
    char-info's are stored as a vector of unnamed structures, it will take 5
    words per character.

In a system supporting 32-bit fixnums, if the font-char-infos array were
abstracted to something with an aref-like function, then char-infos
could be stored as a (cdr-coded) list, 3 words per char-info, and a
char-info could just be the appropriate nthcdr of the list.

Alternatively, the CLX implementation could assign a unique index
(across all open displays) to each active font, and a char-info could be
a fixnum encoding the font index and the index into the packed array of
char-info metrics.

    (DEFUN char-width (font char &optional second-byte)
      (declare (type font font)
	       (type (or integer character (member :min :max)) char)
	       (type (or integer character) second-byte) ;; for 16 bit fonts
	       (values integer)))

Do you really want character, or just string-char?

Making second-byte optional is either confusing or "wrong".  For a
matrix (e.g., Japanese) font, it can still be useful to elide one index
when it is zero, but the normal one to elide is first-byte, not
second-byte.  That is, Latin-1 is normally embedded in a matrix font
with first-byte = zero.  This either means that your definition doesn't
usefully support such one-byte indexing on a matrix font, or else the
required arg changes interpretation between first-byte and second-byte,
depending on whether the optional arg is present.

Another problem, which I now notice is also true of the existing CLX
interface, is that the X protocol allows you to query font information
given a gcontext, without knowledge of the embedded font id.  There
needs to be an interface to this mechanism.  Allowing a gcontext in your
function above will get us into caching and cache-invalidation problems.
In the existing proposal, one can simply add a function

(defun gcontext-font-info (gcontext)
  (declare (type gcontext gcontext)
	   (values font-info (array char-info))))

    Also, how about getting rid of the font-info structure, and
    font-font-info.  This seems like a useless abstraction, since
    there are font-<name> accessors for all the font-info fields.

The font-info structure is necessary because of list-fonts-with-info,
and also because of the need to query font-info via a gcontext.

I'm not completely against getting rid of char-info as an object, but I
don't think the right alternative has been hit upon yet.  Rather than
abstracting char-info accessors into the font object, perhaps it would
be better to abstract the array of char-infos into a char-metrics object
and place the accessors on that.  We would still have to argue about
whether (or integer character) and an optional arg were preferable to
multiple accessors.  The min-bounds and max-bounds in a font-info would
still have to be provided, I guess as 12 font-info accessors.  One could
instead try to fold min/max into the char-metrics, but
list-fonts-with-info only returns min/max, not the other metrics,
although I suppose one could make sense of a char-metrics object that
contained min/max information but was otherwise zero length.

(defun char-width (char-metrics char)
  (declare (type char-metrics char-metric)
	   (type integer char)		; (or integer string-char)?
	   (values integer)))

(defun char16-width (char-metrics first-byte second-byte)
  (declare (type char-metrics char-metric)
	   (type integer first-byte second-byte)
	   (values integer)))

(defun font-font-info (font)
  (declare (type font font)
	   (values font-info)))

(defun font-char-metrics (font)
  (declare (type font font)
	   (values char-metrics)))

(defun gcontext-font-info (gcontext)
  (declare (type gcontext gcontext)
	   (values font-info char-metrics)))

(defun font-info-min-width (font-info)
  (declare (type font-info font-info)
	   (values integer)))

(defun font-info-max-width (font-info)
  (declare (type font-info font-info)
	   (values integer)))

or perhaps?

(defun font-info-char-width (font-info &optional min-p)

or perhaps?

(defun char-bounding-width (char-metrics &optional min-p)
  (declare (type char-metrics char-metrics)
	   (values integer)))

∂03-Jun-87  1215	@RELAY.CS.NET:Oren%Tilde@TI-CSL.CSNET 	Re: font-char-info   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 3 Jun 87  12:13:08 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac00400; 3 Jun 87 15:06 EDT
Received: from ti-csl by RELAY.CS.NET id ad01795; 3 Jun 87 15:02 EDT
Received: by tilde id AA04688; Wed, 3 Jun 87 12:29:05 CDT
Message-Id: <2758728555-9693923@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Wed, 3 Jun 87  12:29:15 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: font-char-info
In-Reply-To: Msg of Wed, 3 Jun 87 10:05 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>

Since the only way you can get char-metrics (or char-info) is from a
font, why not pass in a font instead, eliminating the char-metrics
object?  Instead of 6 more functions, why not an optional argument?
How about:

(DEFUN char-width (font char &optional (first-byte 0))
  ;; FIRST-BYTE is ignored for 8 bit fonts
  (declare (type font font)
	   (type (or integer string-char) char)
	   (type integer first-byte)
	   (values integer)))

I can't imagine anyone needing the min without needing the max also, so
how about:

(defun font-width (font)
  (declare (type (or font font-info gcontext) font)
	   (values max min)))

>  Another problem, which I now notice is also true of the existing CLX
>  interface, is that the X protocol allows you to query font information
>  given a gcontext, without knowledge of the embedded font id.  There
>  needs to be an interface to this mechanism.  Allowing a gcontext in your
>  function above will get us into caching and cache-invalidation problems.

It seems to me that the "caching and cache-invalidation problems" are
easy to solve.  When the font for a gcontext isn't known, a font object
with a null font-id and name (with valid font-info) can be put in the
gcontext cache.  For safety, a hack could be put into gcontext-font to
return NIL when the cached font doesn't have a font-id.  Isn't this
caching required for text-extents anyway?

I was hoping to simplify the font structures.  It seems really messy to
have to deal with 3 kinds of structures (font font-info and char-metrics
or char-info) to get information about a single abstraction.  Since
list-fonts-with-info is the only thing that exposes the font-info
structure, how about letting it return a sequence of font structures
(with null font-id's), and extending open-font to let name be a
fontable.

If you're worried about efficency, I was assuming that text-extents
would use an internal char-metrics structure directly rather using
char-width and friends.  It seems to me that char-width (& friends)
won't be used much, and they should be simple to use.

  - LaMott

∂03-Jun-87  1316	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: font-char-info  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87  13:15:50 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 3 Jun 87 15:58-EDT
Date: Wed, 3 Jun 87 15:58 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: font-char-info
To: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2758728555-9693923@SI>
Message-ID: <870603155820.2.RWS@KILLINGTON.LCS.MIT.EDU>

    Since the only way you can get char-metrics (or char-info) is from a
    font, why not pass in a font instead, eliminating the char-metrics
    object?

Because you can get them "from a font" without actually having the
font object/id in your hand, by indirecting through a gcontext.

    (DEFUN char-width (font char &optional (first-byte 0))
      ;; FIRST-BYTE is ignored for 8 bit fonts
      (declare (type font font)
	       (type (or integer string-char) char)
	       (type integer first-byte)
	       (values integer)))

The only thing bad about this is that the arguments are backwards.
One would expect "first-byte" to come "first", that's all.

    I can't imagine anyone needing the min without needing the max also, so
    how about:

    (defun font-width (font)
      (declare (type (or font font-info gcontext) font)
	       (values max min)))

Max is useful without min.  Dunno about min alone.  Given that in most
other places we've worked hard to eliminate MVs, doesn't seem right to
put them in here.

		    When the font for a gcontext isn't known, a font object
    with a null font-id and name (with valid font-info) can be put in the
    gcontext cache.  For safety, a hack could be put into gcontext-font to
    return NIL when the cached font doesn't have a font-id.

If you create "funny" font objects, then you have to check for them
everywhere fonts are used.  One shouldn't be able to pass such a font to
draw-text.  I suppose one could use generic functions to get around this
(except when don't want to require that) or hack around it by declaring
things as "(or font funny-font)" versus "font", but it doesn't taste
quite right to me.

							      Isn't this
    caching required for text-extents anyway?

No.  If the font in the gcontext isn't known, you fall back on the
QueryExtents protocol request, which accepts a gcontext.

    I was hoping to simplify the font structures.  It seems really messy to
    have to deal with 3 kinds of structures (font font-info and char-metrics
    or char-info) to get information about a single abstraction.

Note that I proposed flushing char-info, and perhaps even merging
char-metrics into font-info.  I'm just not convinced font-info should be
the same thing as font.  I guess I don't consider a "funny font" as any
cleaner than an extra abstraction or two.

								   Since
    list-fonts-with-info is the only thing that exposes the font-info
    structure, how about letting it return a sequence of font structures
    (with null font-id's), and extending open-font to let name be a
    fontable.

This just seems like a hack.

    If you're worried about efficency, I was assuming that text-extents
    would use an internal char-metrics structure directly rather using
    char-width and friends.

Like you (I think), I'm more worried about representation efficiency
than access, but I also don't want a hack interface.

			     It seems to me that char-width (& friends)
    won't be used much, and they should be simple to use.

If they aren't used much, simplicity doesn't matter.  However, I think
it's too early to tell whether text-width and text-extents will be the
canonical use.

∂03-Jun-87  1550	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: font-char-info
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 3 Jun 87  15:50:42 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa02448; 3 Jun 87 18:41 EDT
Received: from ti-csl by RELAY.CS.NET id aj02907; 3 Jun 87 18:33 EDT
Received: by tilde id AA12228; Wed, 3 Jun 87 17:02:58 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 3 Jun 87  17:06:47 CDT
Message-Id: <2758744970-8989885@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Wed, 3 Jun 87  17:02:50 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: font-char-info
In-Reply-To: Msg of Wed, 3 Jun 87 10:05 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>


Regarding the following proposed accessor(s):

    (DEFUN char-width (font char &optional second-byte)
      (declare (type font font)
	       (type (or integer character (member :min :max)) char)
	       (type (or integer character) second-byte) ;; for 16 bit fonts
	       (values integer)))

You're right -- the string-char data type should be used instead of character.



	>For a
	>matrix (e.g., Japanese) font, it can still be useful to elide one index
	>when it is zero, but the normal one to elide is first-byte, not
	>second-byte.  That is, Latin-1 is normally embedded in a matrix font
	>with first-byte = zero.  This either means that your definition doesn't
	>usefully support such one-byte indexing on a matrix font, or else the
	>required arg changes interpretation between first-byte and second-byte,
	>depending on whether the optional arg is present.

Good point, although the current CLX doesn't support such ellipsis at all. Here,
at least, we have a chance, and with the proper interpretation of "first", we
can allow the ellipsis without confusion. Something like:

    (DEFUN char-width (font least-significant-byte
	                    &optional most-significant-byte))





	>The font-info structure is necessary because of list-fonts-with-info

Hmm, you're right again.


Well, it took me some head scratching to get through all of this, but I now
think I see some of these questions in terms of the familiar trade-off between
interface smoothness and implementation complexity. On the one hand, it seems
that char-info (or char-metrics) could be eliminated as distinct object types.
After all, the char-info's are functionally dependent on the font (or gcontext)
object.  It seems natural to think of char metric stuff (e.g.  char-width) as a
function of two variables , rather than as a composition of two functions (e.g.
(char-width (font-char-metrics font) char)). On the other hand, (char-width
gcontext font) seems to require one of the following alternatives:

	1. Char-info's for the gcontext are queried, used, then thrown away.
	   This looks like an intolerable performance problem.
	2. A cache associating char-info's with gcontext must be maintained,
	   apart from but synchronized with the (optional) gcontext cache. This
	   looks a little twisty.

Dunno what's best.

∂04-Jun-87  1530	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: font-char-info
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Jun 87  15:30:24 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 164249; Thu 4-Jun-87 18:27:48 EDT
Date: Thu, 4 Jun 87 18:27 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: font-char-info
To: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>, LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>,
    Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2758744970-8989885@Sierra>
Message-ID: <870604182740.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 3 Jun 87  17:02:50 CDT
    From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>

    Regarding the following proposed accessor(s):

	(DEFUN char-width (font char &optional second-byte)
	  (declare (type font font)
		   (type (or integer character (member :min :max)) char)
		   (type (or integer character) second-byte) ;; for 16 bit fonts
		   (values integer)))

    You're right -- the string-char data type should be used instead of character.

I disagree.  It would be a serious mistake to allow either character or
string-char here.  The whole concept of "character" at the CLX level is
different from the Common Lisp concept of "character", and they should not
be confused.  What X and CLX call a "character" is an index into a specific
font, selecting a specific pattern to be drawn on the screen, and has no
meaning without the context of that font.  What Common Lisp calls a
"character" is at a much higher level of modularity and has meaning in the
absence of any font or window context.

When the Common Lisp WRITE-STRING function is called, with its second
argument a stream that connects to an X window, there must be a translation
from the Common Lisp characters in the string to the X font(s) and indices
into those fonts.  We know from the way CLX is defined that this
translation happens in the caller of CLX, not inside CLX.  It's only a
coincidence if in some simple cases the translation from Common Lisp
character object to X character number happens to be the Common Lisp
function CHAR-CODE; in general the translation will be more complex, and no
particular translation can be built into CLX.  This becomes especially
clear when you realize that in general the translation is to both a
character number and a font, not to just a character number; therefore
anything that takes a font as an argument cannot be the right level of
modularity to perform the translation.

	(DEFUN char-width (font least-significant-byte
				&optional most-significant-byte))

I sure can't understand why everyone thinks these functions have to
receive two bytes as separate arguments when the character number is
larger than 255.  Why not make the arguments be a font and a character
number, and leave it to the CLX implementation to figure out how to
encode the character number as bytes for transmission?

I don't have anything to add to the main part of the discussion, about
the issues derived from the fact that the X protocol allows separate
access to the font metrics and the font bit-patterns.

∂04-Jun-87  2132	RWK@YUKON.SCRC.Symbolics.COM 	Re: font-char-info  
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 4 Jun 87  21:31:49 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 219256; Fri 5-Jun-87 00:05:47 EDT
Date: Fri, 5 Jun 87 00:05 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: font-char-info
To: cl-windows@SAIL.STANFORD.EDU
cc: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>,
    LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>, Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
In-Reply-To: <870604182740.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870605000536.1.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

I agree with everything Moon said about CLX dealing in fonts and
indexes into those fonts, and not characters or string-chars.  It
seems that the range of these indexes should be determined by the
size of the font, and not by 8 bits.

However, before CLX can be useful, we need interfaces at a higher
level that translate from characters (including the CHAR-FONT field
if any) into fonts and indexes.  As MMcM points out, we can define
a few things at another layer of abstraction, without having to
agree on that entire higher layer.

For example:

(defun char-font-and-index (character stream)
  (declare (type string-char character)
	   (type display-stream stream))
  (values font index))

where a DISPLAY-STREAM is something which may convey both knowledge
about the mapping between the local idea of characters and the
foreign fonts, and perhaps some dynamic state in systems which have
concepts like "current font".  I'm not certain it wants to be a stream.

If we're ambitious, we could also define functions DRAW-CHAR and
DRAW-STRING.  These would call CHAR-FONT-AND-INDEX, and call the
appropriate 8-bit or 16-bit drawing functions from the CLX level,
as needed.

My point is that, while Moon's comments are 100% on the mark, that
it doesn't mean you're left with something useless or even awkward.
It's just a necessary building-block to build the tools we REALLY
want.

∂05-Jun-87  0527	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: font-char-info  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87  05:27:18 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 5 Jun 87 08:26-EDT
Date: Fri, 5 Jun 87 08:26 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: font-char-info
To: Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2758744970-8989885@Sierra>
Message-ID: <870605082624.2.RWS@KILLINGTON.LCS.MIT.EDU>

	    >For a
	    >matrix (e.g., Japanese) font, it can still be useful to elide one index
	    >when it is zero, but the normal one to elide is first-byte, not
	    >second-byte.  That is, Latin-1 is normally embedded in a matrix font
	    >with first-byte = zero.  This either means that your definition doesn't
	    >usefully support such one-byte indexing on a matrix font, or else the
	    >required arg changes interpretation between first-byte and second-byte,
	    >depending on whether the optional arg is present.

    Good point, although the current CLX doesn't support such ellipsis at all. Here,
    at least, we have a chance, and with the proper interpretation of "first", we
    can allow the ellipsis without confusion. Something like:

	(DEFUN char-width (font least-significant-byte
				&optional most-significant-byte))

I don't want to harp on this too much, but I doubt the "without
confusion".  The Japanese we've talked with are quite adamant about the
way they think.  Either you ignore them (which is unwise), or you
provide an interface that matches the way they think (it is unlikely you
can change the way they think on this issue).  They don't think in terms
of "least significant" and "most significant".  They don't think in
terms of 16-bit values.  They very definitely think in terms of "first
byte" and "second byte".  The protocol is (re)designed around this way
of thinking, except in a very few cases where it was felt to not matter
(the default-char in a font, the glyph indexes in CreateGlyphCursor).
Even so, we get complaints that things are named PolyText"16" instead of
PolyText"2B".

Naming the arguments as you suggest won't eliminate confusion.  Naming
them "second-byte" and "first-byte" will, but having them in the "wrong"
order seems likely to cause confusion.  I suggest that separate
(one-byte versus two-byte) accessors are the only good solution.

∂05-Jun-87  0904	FAHLMAN@C.CS.CMU.EDU 	font-char-info    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87  09:04:30 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 5 Jun 87 12:03:56-EDT
Date: Fri, 5 Jun 1987  12:03 EDT
Message-ID: <FAHLMAN.12308098410.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: font-char-info
In-reply-to: Msg of 5 Jun 1987  08:26-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>


    The Japanese we've talked with are quite adamant about the
    way they think.  Either you ignore them (which is unwise), or you
    provide an interface that matches the way they think (it is unlikely you
    can change the way they think on this issue).  They don't think in terms
    of "least significant" and "most significant".  They don't think in
    terms of 16-bit values.  They very definitely think in terms of "first
    byte" and "second byte".  The protocol is (re)designed around this way
    of thinking, except in a very few cases where it was felt to not matter
    (the default-char in a font, the glyph indexes in CreateGlyphCursor).
    Even so, we get complaints that things are named PolyText"16" instead of
    PolyText"2B".

Is Kanji the only likely client for a font that has more than 256
characters?  I believe that there are some other alphabets that fall
into this category and also some made-up symbol systems that might want
to be dealt with as fonts and character strings.  It seems to me that
the principal abstraction CLX should provide is a font of arbitrary
size, indexed by an integer whose legal range is a function of that
font.

It is a trivial matter (best handled at the next level up?) to provide a
translation function from the "natural" representation for any given
alphabet into the single-integer value to be used with a certain font.
For Japanese, this is presumably (+ (* 256 first-byte) second-byte).
For an "alchemy symbols" alphabet, it might be something rather
different.

I won't object if CLX actually provides the Japanese interface as a
generally-useful utility, but I don't think we should let their
particular way of thinking about characters control the design of the
basic interface to fonts, any more than we should dictate that all fonts
must correspond directly to ASCII.

-- Scott

∂05-Jun-87  1142	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: font-char-info  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87  11:42:12 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 5 Jun 87 14:40-EDT
Date: Fri, 5 Jun 87 14:40 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: font-char-info
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870604182740.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870605144033.0.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Thu, 4 Jun 87 18:27 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

		 It would be a serious mistake to allow either character or
    string-char here.  The whole concept of "character" at the CLX level is
    different from the Common Lisp concept of "character", and they should not
    be confused.

I agree in principle, but I'm not sure I agree in practice.  Note that
the CLX draw functions (e.g., draw-string) take strings as arguments.
My intention was that the CHAR-CODEs be used, not that CLX do
translation.  If draw-string uses string-chars, it isn't clear to me why
metric accessors shouldn't as well (although I happen to not
particularly care in the accessor case).  You might argue that
draw-string ought to be renamed and ought to take an array of integers,
and I might agree that such a function should also exist, but strings
seem like they will be a very common medium of exchange, and you don't
want to introduce transformation inefficiencies unless you absolutely
have to.  One can perhaps argue that the fonts are likely to be chosen
so that their glyph indexing matches CHAR-CODE, or that in the majority
of cases CHAR-CODE will tend to match ASCII.  None of this is absolute,
of course, but neither are they that unlikely.

	    (DEFUN char-width (font least-significant-byte
				    &optional most-significant-byte))

    I sure can't understand why everyone thinks these functions have to
    receive two bytes as separate arguments when the character number is
    larger than 255.  Why not make the arguments be a font and a character
    number, and leave it to the CLX implementation to figure out how to
    encode the character number as bytes for transmission?

Perhaps my (by now previous) mail will have explained it.  I, too, took
a "what difference does it make?" attitude about this in the initial
protocol specification, thinking it could be plastered over by the
language interfaces.  The fact remains that many Japanese don't see it
this way.  I have trouble clearly explaining why, and I feel
uncomfortable trying to argue their position, and the more I say the
bigger foot I'm likely to stick in my mouth.

∂05-Jun-87  1206	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	font-char-info 
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87  12:05:52 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 5 Jun 87 15:04-EDT
Date: Fri, 5 Jun 87 15:04 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: font-char-info
To: Fahlman@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12308098410.BABYL@C.CS.CMU.EDU>
Message-ID: <870605150425.1.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Fri, 5 Jun 1987  12:03 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    Is Kanji the only likely client for a font that has more than 256
    characters?  I believe that there are some other alphabets that fall
    into this category and also some made-up symbol systems that might want
    to be dealt with as fonts and character strings.

I certainly don't claim to be an expert in this area, but there
definitely are other large-alphabet languages, and the matrix encoding
with "first-byte/second-byte" semantics is (through ISO) pretty much
standard.  General "large fonts" in this country are (I think) not so
common right now, but some people I have talked to think they will be
soon.  However, for them, I don't see any clear cut about linear versus
matrix encoding (which is one reason why X provides support for both in
the >256 case).

    It is a trivial matter (best handled at the next level up?) to provide a
    translation function from the "natural" representation for any given
    alphabet into the single-integer value to be used with a certain font.

Well, this gets back to representation in compound objects as well.  The
Japanese want their "draw-kanji-string" function to take a string of
bytes (of even length), and interpret them in order as first/second
bytes.  You don't want to convert pairs into singletons, have them
possibly byte-swapped, and then converted back to pairs, you want
interfaces all the way through to treat them the same.

    I won't object if CLX actually provides the Japanese interface as a
    generally-useful utility, but I don't think we should let their
    particular way of thinking about characters control the design of the
    basic interface to fonts, any more than we should dictate that all fonts
    must correspond directly to ASCII.

The fact that you view a font as linear (indexed in whatever manner by
"an integer") is a bias.  This seems pretty much a Lilliputian argument
versus a Blefuscuian one; I don't see that our culture is "right" just
because it can be show to achieve the opposite "end".

∂05-Jun-87  1946	RWK@YUKON.SCRC.Symbolics.COM 	Not about font-char-info 
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 5 Jun 87  19:46:12 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 219835; Fri 5-Jun-87 21:53:10 EDT
Date: Fri, 5 Jun 87 21:52 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Not about font-char-info
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: Fahlman@C.CS.CMU.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870605150425.1.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870605215252.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: Fri, 5 Jun 87 15:04 EDT
    From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
    The fact that you view a font as linear (indexed in whatever manner by
    "an integer") is a bias.  This seems pretty much a Lilliputian argument
    versus a Blefuscuian one; I don't see that our culture is "right" just
    because it can be show to achieve the opposite "end".

I disagree.  It's a matter of modularity.  Concepts and objects
being passed around should be one-to-one.  If you want to package
the low-byte and high-byte into a "matrix-font-address" object,
then I'll agree; it's just my biases that say I'd rather just have
an integer and a flat font.

This first-byte second-byte stuff is all about encoding JIS Kanji
characters into 7-bit and 8-bit byte files and data streams.  I don't
read Kanji, but I haven't seen anything to suggest it says you have to
use 8-bit bytes in your programs.

The Japanese problem is one of letting the underlying communications
protocol leak out into the higher layers.  But I must admit they have
cause.  If you had to think about 6802 characters, (yes, that's the
number for JIS Kanji Level 2) you'd find it easier to find them in a 2-D
table.  In almost everything you do, you have to deal with the encoding,
because most systems they are using have a string 8-bit bias.  (Not to
mention PDP-10 & -20's with their 7-bit bias).  Just to look up the
codes in a table, you'd have to split them out into the two bytes,
since all the tables of characters are organized that way.

So I have sympathy, but I still think it's the wrong approach.  If you
think about CLX as a layer between CL, where you deal with characters,
not bytes, and X, where you're dealing with bytes on the net, you have
to ask yourself, "self, where do these bytes come from?"  And where do
you use them?  The answer is that you asked the same agent that got you
the font, and the only thing you can do with them is give them to the
network connection that agent was describing.  If you go and put them in
a file, they could have another meaning.  Perhaps *this* font was really
not Kanji at all, but Sumerian or something.

But that said, I can see a great deal of convenience to be had for a
person used to working with the JIS/ISO encoding schemes for Kanji
to see the two byte values while developing and debugging his system
built on CLX.  For example, he may be comparing it with what his non-Lisp
tools tell him was in the file.  (I've been fortunate enough to never
have to use Kanji on a non-Lisp system, so our use of a 6802-long font
has never seemed the problem; it was the JIS/ISO representation that
has seemed the problem.  Your Gulliver's Travels scenario at work here.)

My recommendation is to adopt flat fonts AS THE MODEL.  That is, the
standard interfaces all treat all fonts as flat.  However, provide
a set of ALTERNATE interfaces which use the same fonts in the
first-byte second-byte model.  Document this second interface as being
for the convenience of humans who have been raised on the JIS/ISO model.
(Note that the ISO standard does not apply here at all, this is just
to make life easier).  Document that it adds no additional functionality
and can be written trivially in terms of the other interface.  Don't
mandate the use of one or the other in any particular situation.


∂05-Jun-87  1947	RWK@YUKON.SCRC.Symbolics.COM 	Re: font-char-info  
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 5 Jun 87  19:47:08 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 219837; Fri 5-Jun-87 22:00:26 EDT
Date: Fri, 5 Jun 87 22:00 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: font-char-info
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870605144033.0.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870605220016.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: Fri, 5 Jun 87 14:40 EDT
    From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>

	Date: Thu, 4 Jun 87 18:27 EDT
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

		     It would be a serious mistake to allow either character or
	string-char here.  The whole concept of "character" at the CLX level is
	different from the Common Lisp concept of "character", and they should not
	be confused.

    I agree in principle, but I'm not sure I agree in practice.  Note that
    the CLX draw functions (e.g., draw-string) take strings as arguments.
    My intention was that the CHAR-CODEs be used, 
This is clearly wrong.  CHAR-CODES don't have anything to do
with indexes in fonts.  Nowhere in CLtL does it even suggest
they might.
						  not that CLX do
    translation.  If draw-string uses string-chars, it isn't clear to me why
    metric accessors shouldn't as well (although I happen to not
    particularly care in the accessor case).  You might argue that
    draw-string ought to be renamed and ought to take an array of integers,
    and I might agree that such a function should also exist, but strings
    seem like they will be a very common medium of exchange, and you don't
    want to introduce transformation inefficiencies unless you absolutely
    have to.  One can perhaps argue that the fonts are likely to be chosen
    so that their glyph indexing matches CHAR-CODE, or that in the majority
    of cases CHAR-CODE will tend to match ASCII.  None of this is absolute,
    of course, but neither are they that unlikely.

I don't think you can scale this argument up to multiple character-sets
implemented with separate, distinct fonts for each character-set.  The
CL idea of "font" cannot be used to implement separate character-sets
without introducing lots of bugs due to CL's specification for comparison
operations and so on ignoring the CHAR-FONT field.  Thus you would have
an equivalence between a kanji character and a Greek letter and the letter
A.  Clearly not right.  The character-set has to be encoded into the
CHAR-CODE.  But if CHAR-CODE is the mapping from the character to the
index, that means ALL character-sets must live in a single font!  Hardly
a reasonable requirement.  So yes, I would say it is highly unlikely that
CHAR-CODE will match the glyph index.

∂08-Jun-87  1637	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	wither characters   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Jun 87  16:36:53 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 8 Jun 87 19:36-EDT
Date: Mon, 8 Jun 87 19:36 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: wither characters
To: cl-windows@sail.stanford.edu
Message-ID: <870608193615.9.RWS@KILLINGTON.LCS.MIT.EDU>

Let's see if I can summarize a bit:

The idea of using or depending on characters at the CLX level is less
than desirable to many people, for both semantic reasons and for
portability (CL doesn't require a 16-bit char-code-limit).  It is more
desirable to stick strictly to an integer interface, and leave character
translation to the next higher level.

Besides the metric accessors, this affects

	text-extents
	text-width
	draw-string
	draw-text
	draw-image-string

and their 16-bit/2-byte relatives:

	text16-extents
	text16-width
	draw-string16
	draw-text16
	draw-image-string16

There is disagreement about whether the integer interface should expose
the matrix encoding (even if only optionally).  I might be convinced
about hiding two-byteness at the character level; I'm less sure there
are compelling arguments at this "rawer" integer level, except that it
seems to simplify the interface (viz., the "16" functions don't need a
bytes-p argument).

I guess I'm tentatively willing to go this direction (integer only, with
matrix hidden).  Are there any dissenters?

∂08-Jun-87  1724	RAM@C.CS.CMU.EDU 	wither characters
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Jun 87  17:23:50 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 8 Jun 87 20:23:11-EDT
Date: Mon, 8 Jun 1987  20:23 EDT
Message-ID: <RAM.12308975727.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
DTo: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: wither characters
In-reply-to: Msg of 8 Jun 1987  19:36-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>

    Date: Monday, 8 June 1987  19:36-EDT
    From: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
    Re:   wither characters

    Let's see if I can summarize a bit:

    The idea of using or depending on characters at the CLX level is less
    than desirable to many people, for both semantic reasons and for
    portability (CL doesn't require a 16-bit char-code-limit).  It is more
    desirable to stick strictly to an integer interface, and leave character
    translation to the next higher level.

I think that it would be a bad idea to put this functionality in the
elusive (and possibly illusory) "next higher level".  It is silly to
make your standard more portable by pushing implementation dependent
details into the user's code, when the reason for the standard is to
allow portable code to be written.

There should be a standard mechanism for displaying standard
characters.  If the implementation supports interesting non-standard
characters, then the same mechanism should also do a reasonable job of
displaying them.  I suggest that DRAW-STRING continue to exist, and
that it use 8 or 16 bit operations depending on whether the string is
fat or not.

  Rob

∂09-Jun-87  1038	Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET 	Re: font-char-info 
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 9 Jun 87  10:38:10 PDT
Received: from [128.89.1.80] by RELAY.CS.NET id ah00253; 9 Jun 87 13:26 EDT
Received: from ti-csl by RELAY.CS.NET id ad00559; 9 Jun 87 13:17 EDT
Received: by tilde id AA01774; Tue, 9 Jun 87 11:41:32 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 9 Jun 87  11:42:50 CDT
Message-Id: <2759244032-9000637@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Tue, 9 Jun 87  11:40:32 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Cc: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, cl-windows@SAIL.STANFORD.EDU
Subject: Re: font-char-info
In-Reply-To: Msg of Fri, 5 Jun 1987  12:03 EDT from "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

	>It seems to me that the principal abstraction CLX should
	>provide is a font of arbitrary size, indexed by an integer
	>whose legal range is a function of that font.  It is a trivial
	>matter (best handled at the next level up?) to provide a
	>translation function from the "natural" representation for any
	>given alphabet into the single-integer value to be used with a
	>certain font.  For Japanese, this is presumably (+ (* 256
	>first-byte) second-byte).

I'm inclined to agree with this point of view. However, since separate functions
for drawing out of 8-bit and 16-bit character sets are already ensconsed in the
Xv11 protocol, Japanese CLX'ers ought to be able to map directly to the
protocol, while the more uniform font abstraction advocated above ought to be
implemented within or upstream of CLX.

I accept the arguments of Moon and others that the translation of a CL character
into a CLX font-and-index will happen upstream and that char-width et al. should
therefore not accept character type arguments. RWS, I'll defer to your
understanding of Japanese requirements. From your description, it sounds like
ellipsis of the most-significant byte will not be important to Japanese users
anyway.

∂09-Jun-87  1358	@RELAY.CS.NET:Oren%Tilde@TI-CSL.CSNET 	Re: wither characters
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 9 Jun 87  13:58:36 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa02116; 9 Jun 87 16:52 EDT
Received: from ti-csl by RELAY.CS.NET id aa01478; 9 Jun 87 16:46 EDT
Received: by tilde id AA02685; Tue, 9 Jun 87 12:18:53 CDT
Message-Id: <2759246377-10272632@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Tue, 9 Jun 87  12:19:37 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: cl-windows@SAIL.STANFORD.EDU
Subject: Re: wither characters
In-Reply-To: Msg of Mon, 8 Jun 1987  20:23 EDT from Ram@c.cs.cmu.edu

>  Date: Mon, 8 Jun 1987  20:23 EDT
>  From: Ram@c.cs.cmu.edu
>  Subject: wither characters
>  
>      Date: Monday, 8 June 1987  19:36-EDT
>      From: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
>      Re:   wither characters
>  
>      Let's see if I can summarize a bit:
>  
>      The idea of using or depending on characters at the CLX level is less
>      than desirable to many people, for both semantic reasons and for
>      portability (CL doesn't require a 16-bit char-code-limit).  It is more
>      desirable to stick strictly to an integer interface, and leave character
>      translation to the next higher level.
>  
>  I think that it would be a bad idea to put this functionality in the
>  elusive (and possibly illusory) "next higher level".  It is silly to
>  make your standard more portable by pushing implementation dependent
>  details into the user's code, when the reason for the standard is to
>  allow portable code to be written.

AMEN! Why should CLX make life difficult for its users? I don't buy the
argument that "CHAR-CODES don't have anything to do with indexes in
fonts".  Fonts aren't ordered randomly, and neither are CL char-codes.
Both are usually ASCII, and for good reasons.

In any case, the solution shouldn't be to disallow the use of character
objects (in strings or otherwise).  How about adding an optional
translation table in the font object that maps char-codes to font
indices.  That way, the translation can be done at a low level where
extra arrays won't have to be consed up.

;; On IBM machines, the default would be an EBCDIC to ASCII table...
(defparameter *default-font-mapping* nil
  "Char-Code to Font-Index mapping, or NIL for 1 to 1")

(defun open-font (display name &key (cache-p t) (mapping *default-font-mapping*))
  (declare (type display display)
	   (type stringable name)
	   (type boolean cache-p)
	   (type (or null vector) mapping)
	   (values font)))

(defun font-mapping (font)
  ;; setf'able
  (declare (type font font)
	   (values (or null vector))))

I don't care much about the two-byte versus integer issue.  Its as easy to
translate to one as the other.

∂09-Jun-87  1705	RWK@YUKON.SCRC.Symbolics.COM 	wither modularity   
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87  17:05:11 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 221522; Tue 9-Jun-87 20:03:41 EDT
Date: Tue, 9 Jun 87 20:03 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: wither modularity
To: Ram@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12308975727.BABYL@>
Message-ID: <870609200327.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: Mon, 8 Jun 1987  20:23 EDT
    From: Ram@C.CS.CMU.EDU

	Date: Monday, 8 June 1987  19:36-EDT
	From: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
	Re:   wither characters

	Let's see if I can summarize a bit:

	The idea of using or depending on characters at the CLX level is less
	than desirable to many people, for both semantic reasons and for
	portability (CL doesn't require a 16-bit char-code-limit).  It is more
	desirable to stick strictly to an integer interface, and leave character
	translation to the next higher level.

    I think that it would be a bad idea to put this functionality in the
    elusive (and possibly illusory) 
Not elusive or illusory.  As has already been pointed out, we can
create any portion of it we need, just by agreeing.  (Unless you're
claiming that agreement is elusive and possibly illusory.  I might
agree somewhat, but if so, why are we bothering with *this* level?)

				    "next higher level".  It is silly to
    make your standard more portable by pushing implementation dependent
    details into the user's code, when the reason for the standard is to
    allow portable code to be written.
But that's exactly you're proposing to do by using characters;
pushing implementation dependent details into the user's code.

The whole point of this exersize is to encapsulate the inherent
implementation dependencies (i.e. the nature of the fonts available),
and separate it out from the implementation-independent interface to
the communication protocol.

    There should be a standard mechanism for displaying standard
    characters.  If the implementation supports interesting non-standard
    characters, then the same mechanism should also do a reasonable job of
    displaying them.  I suggest that DRAW-STRING continue to exist, and
    that it use 8 or 16 bit operations depending on whether the string is
    fat or not.

If you read what I wrote, you'll see that I proposed a function which
takes standard (*and* non-standard) characters, and displays them.  And it
figures out the best way of doing it.  And it is part of the next-higher level.
And it is written in terms of this level, plus a function which converts from
characters to a font and an index.

It seems to me that what we bytes-instead-of-characters people are
arguing for is simply clear modularity and complete functionality,
not for taking away any convenience.  There's no reason you have to
have the low-level interfaces be easy to use in a high-level way, when
you can have the high-level interfaces.

      Rob


∂09-Jun-87  1739	MMcM@STONY-BROOK.SCRC.Symbolics.COM 	Higher levels
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87  17:39:12 PDT
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 168834; Tue 9-Jun-87 20:36:54 EDT
Date: Tue, 9 Jun 87 20:36 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Higher levels
To: Ram@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12308975727.BABYL@>
Message-ID: <870609203644.9.MMCM@OWL.SCRC.Symbolics.COM>

If all layers higher than CLX elude us, how will programs do
WRITE-STRING or READ-CHAR from the windows they create?


I am afraid that once again some unwarranted assumptions are slipping in.

- that aspects of the interface @i(implementation) that are necessarily
system specific, such as scroll bars, **MORE** or other special handling
at the end of a screenful, cursor blinkers, and so on preclude any
agreement on the @i(specification).

- that the impossibility of completely specifying a stream interface to
windows necessarily leaves the poor programmers stuck with just the
lowest level bare X interface.

∂09-Jun-87  1803	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: wither characters  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 9 Jun 87  18:03:19 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa03829; 9 Jun 87 20:24 EDT
Received: from ti-csl by RELAY.CS.NET id aa02593; 9 Jun 87 20:16 EDT
Received: by tilde id AA14680; Tue, 9 Jun 87 17:57:35 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 9 Jun 87  17:50:15 CDT
Message-Id: <2759266063-10324292@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Tue, 9 Jun 87  17:47:43 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: wither characters
In-Reply-To: Msg of Mon, 8 Jun 87 19:36 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>

Integers vs. characters: 
  While I agree that the CLX text/font functions should accept integers/integer
  vectors and shouldn't depend on characters/strings, I wonder if there is any
  objection to their *optional* use of character/string arguments?  That is, for
  programming convenience, any of these functions could accept a
  character/string, automatically converting it to integer(s) using CHAR-CODE.
  Wouldn't this permit a productive convenience without really blurring the
  distinction between the CL and X concepts of a character?  Wouldn't this also
  permit CLX to mesh with the upstream translation of CL character objects into
  font/index pairs?

Matrix vs. linear character indexing: 
  Given the Japanese requirements for first-byte/second-byte interfaces and the
  existence of such interfaces already in the Xv11 protocol, I feel that CLX
  should also provide matrix indexing interfaces.  It seems silly to *require*
  unnecessary packing/unpacking of char2b's. Someone (Fahlman?) indicated
  that other CLX users might not be satisfied with the conventional conversion
  from 16-bit integer to first-byte/second-byte; matrix indexing would appeal
  also to such users. I guess I'm arguing for draw-string16, etc. with :bytes-p,
  as the spec currently says.

∂09-Jun-87  1810	RWK@YUKON.SCRC.Symbolics.COM 	Re: wither characters    
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87  18:09:46 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 221574; Tue 9-Jun-87 21:07:51 EDT
Date: Tue, 9 Jun 87 21:07 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: wither characters
To: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2759246377-10272632@SI>
Message-ID: <870609210739.7.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: Tue, 9 Jun 87  12:19:37 CDT
    From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>

    >  I think that it would be a bad idea to put this functionality in the
    >  elusive (and possibly illusory) "next higher level".  It is silly to
    >  make your standard more portable by pushing implementation dependent
    >  details into the user's code, when the reason for the standard is to
    >  allow portable code to be written.

    AMEN! Why should CLX make life difficult for its users? I don't buy the
    argument that "CHAR-CODES don't have anything to do with indexes in
    fonts".  Fonts aren't ordered randomly, and neither are CL char-codes.
    Both are usually ASCII, and for good reasons.

"Usually" ain't good enough to build a standard on.  On our system,
CHAR-CODE's are not ASCII, and in fact, the high 8 bits are assigned
in order of loading of the individual character-set.  Is that random
enough for you?

I can guarentee you that if you don't deal with the font ordering
issue, incompatibilities are going to make life a LOT harder for
CLX users and the users of what CLX's users build.

    In any case, the solution shouldn't be to disallow the use of character
    objects (in strings or otherwise).  How about adding an optional
    translation table in the font object that maps char-codes to font
    indices.  
What about the CHAR-CODE's that don't map to this font, but instead to
some other font?  I.e. what if this font implements the standard character
set, but the char-code involved is for a Kanji character?

By the time you've chosen the font, it's too late to be dealing with
CHAR-CODE's.

	      That way, the translation can be done at a low level where
    extra arrays won't have to be consed up.
The higher level wouldn't have to cons up arrays on the fly.

    ;; On IBM machines, the default would be an EBCDIC to ASCII table...
    (defparameter *default-font-mapping* nil
      "Char-Code to Font-Index mapping, or NIL for 1 to 1")

    (defun open-font (display name &key (cache-p t) (mapping *default-font-mapping*))
      (declare (type display display)
	       (type stringable name)
	       (type boolean cache-p)
	       (type (or null vector) mapping)
	       (values font)))

    (defun font-mapping (font)
      ;; setf'able
      (declare (type font font)
	       (values (or null vector))))

    I don't care much about the two-byte versus integer issue.  Its as easy to
    translate to one as the other.


∂09-Jun-87  2122	RAM@C.CS.CMU.EDU 	Higher levels    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Jun 87  21:22:43 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Wed 10 Jun 87 00:22:00-EDT
Date: Wed, 10 Jun 1987  00:21 EDT
Message-ID: <RAM.12309281349.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To:   Mike McMahon <MMcM@SCRC-STONY-BROOK.ARPA>
Cc:   cl-windows@SAIL.STANFORD.EDU
Subject: Higher levels
In-reply-to: Msg of 9 Jun 1987  20:36-EDT from Mike McMahon <MMcM at STONY-BROOK.SCRC.Symbolics.COM>


I question the meaningfulness of defining a "level" which can only be
used to define another "level".  I will go along with the widely
expressed belief that "nobody will want to use CLX directly", but I
think that it should be possible to write programs that run without
modification in any Common Lisp that supports CLX.  If there is a
standard mechanism for displaying standard characters, then
programs that run in the intersection of Common Lisp and common X will
port without difficulty.  There are major applications that fall in
this category, for example the Hemlock text editor.

I guess that Hemlock is in some sense a "higher level" and perhaps
even a "toolkit" (heaven forbid).  You can use these terms if they
make you feel better, but it doesn't change the issues at all.  There
are many programs that are perfectly happy living directly on top of
CLX as long as there is some way to display characters in a window.  I
certainly don't buy arguments that I should wait for a "stream
oriented higher level".  Only a truly warped mind would perceive
incremental bitmap redisplay as being stream oriented.

If it is really true that nobody will directly use CLX, then its only
reason for existence is to allow portable "toolkits" to be written.
It seems that we should be giving some consideration to what these
"higher layers" will want.

  Rob

∂09-Jun-87  2304	Masinter.pa@Xerox.COM 	multi-byte characters and Japanese   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jun 87  23:04:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 87 22:59:06 PDT
Date: 9 Jun 87 22:58 PDT
From: Masinter.pa@Xerox.COM
Subject: multi-byte characters and Japanese
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <870609-225906-2187@Xerox>

The Japanese working group on character encoding sent out a mailing on
18 May to common-lisp@sail.stanford.edu proposing a way of dealing with
Japanese characters in Common Lisp. This proposal did not talk about
multiple bytes, high-bytes and low-bytes, but rather, extending
char-code-limit to be able to handle Japanese.

It would seem most reasonable, if one is worrying about encoding
Japanese characters, to attempt some compatibility with that proposal,
wouldn't you think?

∂10-Jun-87  1553	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	the character of characters   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Jun 87  15:53:35 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 10 Jun 87 18:26-EDT
Date: Wed, 10 Jun 87 18:23 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: the character of characters
To: cl-windows@sail.stanford.edu
Message-ID: <870610182346.5.RWS@KILLINGTON.LCS.MIT.EDU>

The issues surrounding characters vs. integers and linear vs. matrix
will be highest on my list of things to bring up before X3J13 at the end
of June (I've asked to make a presentation, to get their feedback).

Ignoring the matrix part, I wonder if we could get around the character
vs. integer part by generalizing the interface even further, along the
following lines:

(defun draw-string (drawable gcontext x y sequence &key (start 0) end (transform 'identity))
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type sequence sequence)
	   (type (or null integer) end)
	   (type (function (t) integer) transform)))

(Ignore whether draw-string is still a good name.)  That is, it takes in
a sequence of "things" and a function that turns "things" into (8-bit
font) indexes.  [Please don't suggest that transform also return a
font.]  Compiler and/or run-time optimizations could take care of special
cases like
	(array (unsigned-byte 8)) with identity
	string with char-code
	...

Similar generalizations could be applied to draw-string16, etc.

∂10-Jun-87  2125	MMcM@STONY-BROOK.SCRC.Symbolics.COM 	Higher levels
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87  21:25:30 PDT
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169874; Wed 10-Jun-87 20:19:11 EDT
Date: Wed, 10 Jun 87 20:19 EDT
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Higher levels
To: Ram@C.CS.CMU.EDU
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12309281349.BABYL@>
Message-ID: <870610201910.0.MMCM@OWL.SCRC.Symbolics.COM>

Doubting levels that only implement higher levels could be taken as an
argument against microcoding, ISO/OSI, compilers, and RISC
architectures, among other things.  I think I see your point, though.

I agree that a text editor often has large pieces that can be used as
toolkits.  I am not sure that this lessens my point, though.

A bitmap screen redisplay sounds like a client of a object-oriented
stream interface to me.  The generic hierarchical one we have certainly
makes great use of actor encapsulation.

When building a program with the highest degree of portability,
several possibilities are open, for instance in how that program
interfaces to the terminal driver's BitBlt/RasterOp capabilities
necessary for getting redisplay done.
 (1) implement in CLX and make the program available to all the systems
which support that, which we can assume will be a large number as time
goes on.
 (2) supply a separate module of system dependent functions which must
be conditionally linked in depending on the environment.
 (3) make the primitive shifting operations generic operations on streams.

Now strategy (3) walks a fine line between wanting to make the operation
higher level, thereby capturing your intentions more closely, and
insulating yourself as much as possible from the operating system
environment and requiring the operating system to supply what is
logically part of a particular application program, in this case a text
editor.  For this reason, it appears harder to pin down than just the
bare bones console real-estate manager.  But in the long run, it is this
which leads to a easier development of a wider range of applications.

No one is proposing that you wait until everything is done to get your
work done.  Just that you and everyone else might benefit from trying to
take the perspective:  which part of what I have here really should be
part of the stream protocol?

∂10-Jun-87  2126	Moon@STONY-BROOK.SCRC.Symbolics.COM 	the character of characters 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87  21:26:37 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169941; Wed 10-Jun-87 22:29:12 EDT
Date: Wed, 10 Jun 87 22:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: the character of characters
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
cc: cl-windows@sail.stanford.edu
In-Reply-To: <870610182346.5.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870610222906.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 10 Jun 87 18:23 EDT
    From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>

    Ignoring the matrix part, I wonder if we could get around the character
    vs. integer part by generalizing the interface even further, along the
    following lines:

    (defun draw-string (drawable gcontext x y sequence &key (start 0) end (transform 'identity))
      (declare (type drawable drawable)
	       (type gcontext gcontext)
	       (type integer x y start)
	       (type sequence sequence)
	       (type (or null integer) end)
	       (type (function (t) integer) transform)))

    (Ignore whether draw-string is still a good name.)  

How about draw-character-sequence?  I'd suggest draw-poly-chars instead,
except that in my out of date copy of the X11 spec "poly text" is something
different (does that still exist?  It looks completely different from
anything in CLX.)

							That is, it takes in
    a sequence of "things" and a function that turns "things" into (8-bit
    font) indexes.  [Please don't suggest that transform also return a
    font.]

I'm afraid I do have to suggest that.  Actually, a better idea is to give
transform a way to say "stop before this character", maybe by returning NIL.
Then draw-string would return three values describing how to continue
the operation: the index into the sequence, x, and y.  The first value would
be NIL if the whole sequence was output.  Of course this isn't strictly
necessary, since one could pre-scan the sequence to find font changes and
then call draw-string on each sub-sequence.  But if you're going to do that,
why bother with the transform funarg at all?  Since there was objection to
just making the caller of draw-string compute a sequence of integers in the
first place, presumably there would be objection to pre-scanning the sequence.					      

A perhaps minor problem with this proposal is that it encourages
programmers to screw themselves by writing :transform #'char-code, which
is not actually portable (although it probably works in more than one
implementation).

Except for those two problems, this sounds like a workable proposal.

∂11-Jun-87  0808	sas@bfly-vax.bbn.com 	Re: the character of characters  
Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87  08:08:01 PDT
Date: Thu, 11 Jun 87 10:04 EDT
From: Seth Steinberg <sas@bfly-vax.bbn.com>
Subject: Re: the character of characters
To: cl-windows@sail.stanford.edu

Forgive my extreme naivite, but I am getting mixed signals from this
character code debate.  

1) One group has designed a very nice, very general interface which
handles characters at their most general and would let me draw words
like "naivite" with the correct umlauts and accents.  They would rather
not have the specification burdened with numerous machine, character
set and language dependencies.  They propose a lower level and want
things like (princ "foo") handled somewhere else.

Their big FEAR: ASCII somehow gets embedded (nay lodged) in CLX.
This defeats portability at the CLX level.

2) The other group would like to be able to draw ASCII (or EBCDIC)
characters in an X window given a location, a font and so on.  They
reason that this seems to be a very common operation given that many
people run CL programs to get output.  Since the language supports
strings and a set of string operations, should CLX support CL string
output.

Their big FEAR: Each CL implementation has its own set of routines to
write characters into X windows.  This defeats portability at the CL
level.

----

My impression is that some higher level character code oriented
primitive should be specified in the CLX description even if its
implementation is not.  This should specify something below EMACS but
safely above the level of actual font indices.  Given certain biases,
it should handle things like #\a and "foo".  If there is enough
interest and knowledge available it should handle Kanji as well.

----

Actually, this kind of looks like what the most recent messages are
iterating in on.

					Baffled in Boston,
						Seth
						sas@bbn.com

∂12-Jun-87  1221	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	the character of characters   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Jun 87  12:21:31 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 12 Jun 87 14:33-EDT
Date: Fri, 12 Jun 87 14:34 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: the character of characters
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-windows@sail.stanford.edu
In-Reply-To: <870610222906.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870612143408.9.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Wed, 10 Jun 87 22:29 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	(defun draw-string (drawable gcontext x y sequence &key (start 0) end (transform 'identity))

    How about draw-character-sequence?

How about draw-glyphs?
					I'd suggest draw-poly-chars instead,
    except that in my out of date copy of the X11 spec "poly text" is something
    different (does that still exist?  It looks completely different from
    anything in CLX.)

There is also draw-text in CLX, which mirrors the PolyText request.  I
would propose giving it a :transform in the same way (but again I don't
know what to do about naming).

							    That is, it takes in
	a sequence of "things" and a function that turns "things" into (8-bit
	font) indexes.  [Please don't suggest that transform also return a
	font.]

    I'm afraid I do have to suggest that.  Actually, a better idea is to give
    transform a way to say "stop before this character", maybe by returning NIL.
    Then draw-string would return three values describing how to continue
    the operation: the index into the sequence, x, and y.  The first value would
    be NIL if the whole sequence was output.  Of course this isn't strictly
    necessary, since one could pre-scan the sequence to find font changes and
    then call draw-string on each sub-sequence.  But if you're going to do that,
    why bother with the transform funarg at all?  Since there was objection to
    just making the caller of draw-string compute a sequence of integers in the
    first place, presumably there would be objection to pre-scanning the sequence.					      

Even if a pre-scan is necessary, the reason for the transform is to
avoid the necessity of copying from the application object (string,
etc.) to some temporary array of integers (where does it come from?)
and then to the output buffer inside CLX; the transform lets (but
doesn't require, of course) CLX go directly from application object to
output buffer.

Pre-scanning is often going to be necessary, e.g. to enforce a right
margin, etc.  There will be a performance trade-off between pre-scanning
and using a lexical closure for the funarg to track the width.  However,
I'm not opposed to allowing the transform return nil to indicate the
end, and having draw-string return the last index.

I don't believe the (x,y) coordinates should be returned, however.  One
major reason is that we don't currently require CLX to have the
per-glyph metrics available locally, and requiring that would cause
extreme problems.  In many cases the application will have to precompute
the width before doing the output, so having CLX do it again is useless.
If you don't want to pre-scan but want to maintain a right margin or
something, a closure as the transform can calculate and retain the
width.

However, related to this is the current comment in draw-string:

  ;; Should be clever about appending to existing buffered protocol request, provided
  ;; gcontext has not been modified and char-infos are cached.

In order to be clever, draw-string does indeed need to know the width of
the string, in order to cache the ending position.  What I would propose
is that draw-string take another keyword argument :width (or perhaps
:ending-x instead) that CLX would *believe* if provided.  If provided,
CLX could be clever about appending a subsequent call onto this one.  If
not provided, CLX might or might not be clever (unspecified; e.g., might
be clever if metrics are known locally).  Thus, we end up with something
like:

(defun draw-glyphs (drawable gcontext x y sequence
		    &key (start 0) end (transform 'identity) width)
  ;; The transform is used to convert an element of the sequence into a
  ;; font index.  The transform is applied to each element of the
  ;; (sub)sequence, until either the transform returns nil or the end of
  ;; the (sub)sequence is reached.  If transform returns nil for an
  ;; element, the index of that element in the sequence is returned,
  ;; otherwise nil is returned.  If width is specified, it is assumed to
  ;; be the pixel width of whatever string of glyphs is actually drawn,
  ;; which will allow for appending the output of a subsequent
  ;; draw-glyphs to the same protocol request, provided gcontext has not
  ;; been modified in the interim.  If width is not specified, appending
  ;; for subsequent draw-glyphs might not occur.  Specifying width is
  ;; simply a hint, for performance.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type sequence sequence)
	   (type (or null integer) end width)
	   (type (function (t) (or null integer)) transform))
	   (values (or null integer)))

I'm unclear about whether returning nil is better than returning (1+ end).

    A perhaps minor problem with this proposal is that it encourages
    programmers to screw themselves by writing :transform #'char-code, which
    is not actually portable (although it probably works in more than one
    implementation).

Well, I think it can be argued that those who want to screw themselves
will do it with or without our encouragement.  If you don't provide a
way, they will just find their own non-portable way to do it.  The fact
that a general mechanism can be abused doesn't bother me.  Rather, in
those cases where the higher level can determine that the characters of
a string all fall into the intersection of the local CL character set
and the character set of the font, being able to transform with
char-code seems like a win.  In some systems, CLX can then directly blit
from the string to the output buffer (e.g., with the aid of displaced
arrays and type conversions).

∂12-Jun-87  1516	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	font and character metrics    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Jun 87  15:16:05 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 12 Jun 87 18:05-EDT
Date: Fri, 12 Jun 87 18:05 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: font and character metrics
To: cl-windows@sail.stanford.edu
Message-ID: <870612180544.2.RWS@KILLINGTON.LCS.MIT.EDU>

It seems to me the best solution about linear vs. matrix for getting at
metrics is to keep the two interfaces separate.  I'm happy for now to
only define the linear interface, and wait until there is clear desire
and need before adding a matrix interface.  Assuming that we make the
transformer change to draw-string, etc., I think it is acceptable to
eliminate explicit character indexing, and force that transformation on
the caller.  To first order, that just means having accessors of the
form:

(defun char-<metric> (font index)
  (declare (type font font)
	   (type integer index)
	   (values integer)))

I'm happy to have separate character metric functions like this, and
eliminate fetching of char-info objects.  (BTW, should this return nil
for an out-of-bounds index, or zero, or signal?)

I'm less sure on whether it is better to handle min- and max-bounds by
allowing :min and :max as an index, or by 12 accessors on the font, or
by retaining a char-info object (perhaps renamed as bounds-info) solely
for this purpose.

In thinking about what to do with font-info objects, I've changed my
mind about the "hackery" of having pseudo- font objects.  We can have
list-fonts-with-info return real font objects, but have the actual
open-font equivalent (to assign it a resource-id) take place dynamically
under the covers at the first use that requires it.  In normal usage
this provides a seamless interface, but it will be necessary to
introduce an illegal-font condition to signal in the case where the
delayed open-font fails (e.g., due to a change in the font path) and on
any subsequent calls that would require using the resource-id.  This
condition should be rare enough that the overall interface seems
acceptable.

As I mentioned in previous mail, the protocol supports the ability to
query all of the font metrics given a gcontext (that contains a font).
If we are to provide this in CLX, then I guess we return a font object
that will likewise cause an illegal-font condition when used improperly.
Since there is already a gcontext-font accessor (returning nil or a
font), we might change it slightly (so that we don't cons up font
objects needlessly):

(defun gcontext-font (gcontext &optional metrics-p)
  ;; If the stored font is known, it is returned.  If it is not known
  ;; and metrics-p is false, then nil is returned.  If it is not known
  ;; and metrics-p is true, then a font is returned containing the
  ;; metric information, but this font will cause an error if used
  ;; in [enumerate the bad ways to use it].
  (declare (type gcontext gcontext)
	   (type boolean metrics-p)
	   (values (or null font))))

Comments on all this, please?

∂12-Jun-87  2047	RWK@YUKON.SCRC.Symbolics.COM 	multi-byte characters and Japanese 
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 12 Jun 87  20:47:30 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223689; Fri 12-Jun-87 23:46:33 EDT
Date: Fri, 12 Jun 87 23:46 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: multi-byte characters and Japanese
To: Masinter.pa@Xerox.COM
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870609-225906-2187@Xerox>
Message-ID: <870612234615.5.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: 9 Jun 87 22:58 PDT
    From: Masinter.pa@Xerox.COM

    The Japanese working group on character encoding sent out a mailing on
    18 May to common-lisp@sail.stanford.edu proposing a way of dealing with
    Japanese characters in Common Lisp. This proposal did not talk about
    multiple bytes, high-bytes and low-bytes, but rather, extending
    char-code-limit to be able to handle Japanese.

    It would seem most reasonable, if one is worrying about encoding
    Japanese characters, to attempt some compatibility with that proposal,
    wouldn't you think?

Unfortunately, it doesn't really relate, because it's dealing with
characters, and doesn't even specify the character-code.  We're dealing
with integers or bytes here.  I don't think their absence in the proposal
has any bearing on CLX, except to highlight the different levels.

∂13-Jun-87  1434	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	more concrete font proposal   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Jun 87  14:34:02 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 13 Jun 87 17:32-EDT
Date: Sat, 13 Jun 87 17:33 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: more concrete font proposal
To: cl-windows@sail.stanford.edu
Message-ID: <870613173320.8.RWS@KILLINGTON.LCS.MIT.EDU>

Putting everything together, the following is an attempt to put together
the various ideas that have been discussed, and provide the complete
font-related interface.  Comments most welcome.

;; Note: font-info defstruct is removed.

(defun open-font (display name)
  ;; Font objects may be cached and reference counted locally within the display
  ;; object.  This function might not execute a with-display if the font is cached.
  ;; The protocol QueryFont request happens on-demand under the covers.
  (declare (type display display)
	   (type stringable name)
	   (type boolean cache-p)
	   (values font)))

;; Note: font-cache-p and setf are removed as no longer sensible (given the
;; inability to extract a font-info object).

(defun discard-font-info (font)
  ;; Discards any state that can be re-obtained with QueryFont.  This is simply
  ;; a performance hint for memory-limited systems.
  (declare (type font font)))

;; This can be signalled anywhere a pseudo font access fails.

(define-condition invalid-font error
  font)

;; Note: font-font-info removed.

(defun font-name (font)
  ;; Returns nil for a pseudo font returned by gcontext-font.
  (declare (type font font)
	   (values (or null string))))

(defun font-direction (font)
  (declare (type font font)
	   (values draw-direction)))

(defun font-min-char (font)
  (declare (type font font)
	   (values integer)))

(defun font-max-char (font)
  (declare (type font font)
	   (values integer)))

(defun font-min-byte1 (font)
  (declare (type font font)
	   (values integer)))

(defun font-max-byte1 (font)
  (declare (type font font)
	   (values integer)))

(defun font-min-byte2 (font)
  (declare (type font font)
	   (values integer)))

(defun font-max-byte2 (font)
  (declare (type font font)
	   (values integer)))

(defun font-all-chars-exist-p (font)
  (declare (type font font)
	   (values boolean)))

(defun font-default-char (font)
  (declare (type font font)
	   (values integer)))

(defun font-ascent (font)
  (declare (type font font)
	   (values integer)))

(defun font-descent (font)
  (declare (type font font)
	   (values integer)))

;; The list contains alternating keywords and integers.

(deftype font-props () 'list)

(defun font-properties (font)
  (declare (type font font)
	   (values font-props)))

(defun font-property (font name)
  (declare (type font font)
	   (type keyword name)
	   (values (or null integer))))

;; For each of left-bearing, right-bearing, width, ascent, descent, attributes:

(defun char-<metric> (font index)
  ;; Note: I have tentatively chosen to return nil for an out-of-bounds index
  ;; (or an in-bounds index on a pseudo font), although returning zero or
  ;; signalling might be better.
  (declare (type font font)
	   (type integer index)
	   (values (or null integer))))

(defun max-char-<metric> (font)
  ;; Note: I have tentatively chosen separate accessors over allowing :min and
  ;; :max as an index above.
  (declare (type font font)
	   (values integer)))

(defun min-char-<metric> (font)
  (declare (type font font)
	   (values integer)))

;; Note: char16-<metric> accessors could be defined to accept two-byte indexes.

(defun close-font (font)
  ;; This might not generate a protocol request if the font is reference
  ;; counted locally or if it is a pseudo font.
  (declare (type font font)))

(defun list-font-names (display pattern &key (max-fonts 65535) (result-type 'list))
  ;; Note: Was called list-fonts, but that name is better used below.
  (declare (type display display)
	   (type string pattern)
	   (type integer max-fonts)
	   (type type result-type)
	   (values (sequence string))))

(defun list-fonts (display pattern &key (max-fonts 65535) (result-type 'list))
  ;; Note: Was called list-fonts-with-info.
  ;; Returns "pseudo" fonts that contain basic font metrics and properties, but
  ;; no per-character metrics and no resource-ids.  These pseudo fonts will be
  ;; converted (internally) to real fonts dynamically as needed, by issuing an
  ;; OpenFont request.  However, the OpenFont might fail, in which case the
  ;; invalid-font error can arise.
  (declare (type display display)
	   (type string pattern)
	   (type integer max-fonts)
	   (type type result-type)
	   (values (sequence font))))

(defun gcontext-font (gcontext &optional metrics-p)
  ;; If the stored font is known, it is returned.  If it is not known and
  ;; metrics-p is false, then nil is returned.  If it is not known and
  ;; metrics-p is true, then a pseudo font is returned.  Full metric and
  ;; property information can be obtained, but the font does not have a name or
  ;; a resource-id, and attempts to use it where a resource-id is required will
  ;; result in an invalid-font error.
  (declare (type gcontext gcontext)
	   (type boolean metrics-p)
	   (values (or null font))))

;; A transform8 produces a single 8-bit index, or nil for termination.

(deftype transform8 () '(function (t) (or null integer)))

;; A transform16 produces nil for termination, (integer nil) for a linear
;; 16-bit index, and (integer integer) for a two-byte matrix index.

(deftype transform16 () '(function (t) (or null integer) (or null integer)))

;; In the functions below, the transform is used to convert an element of the
;; sequence into a font index.  The transform is applied to each element of the
;; (sub)sequence, until either the transform returns nil or the end of the
;; (sub)sequence is reached.  If transform returns nil for an element, the
;; index of that element in the sequence is returned, otherwise nil is
;; returned.

;; In the functions below, if width is specified, it is assumed to be the pixel
;; width of whatever string of glyphs is actually drawn.  Specifying width will
;; allow for appending the output of subsequent calls to the same protocol
;; request, provided gcontext has not been modified in the interim.  If width
;; is not specified, appending of subsequent output might not occur.
;; Specifying width is simply a hint, for performance.  Note that specifying
;; width may be difficult if transform can return nil.


(defun text-extents (font sequence &key (start 0) end (transform 'identity))
  (declare (type (or font gcontext) font)
	   (type sequence sequence)
	   (type transform16 transform)
	   (values width ascent descent left right font-ascent font-descent direction
		   (or null integer))))

(defun text-width (font sequence &key (start 0) end (transform 'identity))
  (declare (type (or font gcontext) font)
	   (type sequence sequence)
	   (type transform16 transform)
	   (values integer (or null integer))))

(defun draw-glyph (drawable gcontext x y index &optional width)
  ;; Use &key for consistency?
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer (x y index))
	   (type (or null integer) width)))

(defun draw-glyphs (drawable gcontext x y sequence
		    &key (start 0) end (transform 'identity) width)
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type sequence sequence)
	   (type (or null integer) end width)
	   (type transform8 transform)
	   (values (or null integer))))

(defun draw-image-glyph (drawable gcontext x y index &optional width)
  ;; Use &key for consistency?
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer (x y index))
	   (type (or null integer) width)))

(defun draw-image-glyphs (drawable gcontext x y sequence
			  &key (start 0) end (transform 'identity) width)
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type sequence sequence)
	   (type (or null integer) end width)
	   (type transform8 transform)
	   (values (or null integer))))

;; Note: I am unsure how to define draw-glyph16 and draw-image-glyph16.

;; Note: a possible alternative to the following would be to provide both
;; :transform8 and :transform16 keyword arguments to draw-glyphs and
;; draw-image-glyphs.

(defun draw-glyphs16 (drawable gcontext x y sequence
		      &key (start 0) end (transform 'identity) width)
  ;; Only differs from draw-glyphs in transform type.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type sequence sequence)
	   (type (or null integer) end width)
	   (type transform16 transform)
	   (values (or null integer))))

(defun draw-image-glyphs16 (drawable gcontext x y sequence
			    &key (start 0) end (transform 'identity) width)
  ;; Only differs from draw-glyphs in transform type.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type sequence sequence)
	   (type (or null integer) end width)
	   (type transform16 transform)
	   (values (or null integer))))

;; Note: I haven't figured out what to do with draw-text (and draw-text16).  It
;; may be that their existing definitions aren't really very useful.  It may be
;; better to provide a function that takes a transform of the form:
;;   (function t (or null integer) (or null font) (or null integer))
;; where the first value is the index, the second is optionally a change in
;; font, and the third is optionally a delta in x coordinate.

∂15-Jun-87  0912	@RELAY.CS.NET:Oren%Tilde@TI-CSL.CSNET 	Re: more concrete font proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 15 Jun 87  09:12:44 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ak00342; 15 Jun 87 11:52 EDT
Received: from ti-csl by RELAY.CS.NET id ag10051; 15 Jun 87 11:17 EDT
Received: by tilde id AA20745; Mon, 15 Jun 87 10:14:41 CDT
Message-Id: <2759757310-3394403@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Mon, 15 Jun 87  10:15:10 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: more concrete font proposal
In-Reply-To: Msg of Sat, 13 Jun 87 17:33 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>

I like the parts of your proposal related to font and char info.  I have
some concerns about using closures for string transformations.  By
having the transformation return NIL when a font change is required, all
you've done is shove the font problem up to the next level.  If I write
a toolkit on top of CLX, it can't be portable, because all the places
that use CLX functions taking transform arguments will have to be
modified (what's the right thing to do when the transform function
returns NIL?).  It sure would be nice if we could agree on how to
display multi-fonted text in CLX, rather than making every toolkit
re-invent it.

I agree with Robert Kerns and Seth Steinberg's suggestions that an
implementation dependent function be specified for translating character
objects into font/index pairs.  I.E.

(deftype font-list () '(or font gcontext (sequence (or font gcontext))))

(defun char-font-and-index (font-list character)
  ;; Implementation dependent function for translating CL character objects
  ;; font-list is a sequence used to provide information about what font
  ;; to use given (char-font character) and (char-code character)
  (declare (type font-list font-list)
	   (type character character)
	   (inline char-font-and-index))
  (values index font))

(defun text-extents (fonts string)
  (declare (type font-list fonts)
	   (type (or string (vector character)) string)
	   (inline char-font-and-index)
	   (values width ascent descent left right font-ascent font-descent direction)))

(defun draw-string (drawable gcontext x y string &key (start 0) end fonts)
  ;; For 8-bit indexes only.
  ;; Should be clever about appending to existing buffered protocol request, provided
  ;; gcontext has not been modified and char-infos are cached.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type (or string (vector character)) string)
	   (type (or null integer) end)
	   (type font-list fonts)
	   (inline char-font-and-index)))

Perhaps a font-list slot could be added to the gcontext object?  This
would ensure that the char-font-and-index function could easily get
a font-list, even when a toolkit maker didn't bother to pass the
font-list parameter around to all the string drawing functions.

∂15-Jun-87  1435	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: more concrete font proposal  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 15 Jun 87  14:35:01 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac02531; 15 Jun 87 16:36 EDT
Received: from ti-csl by RELAY.CS.NET id ac11577; 15 Jun 87 16:31 EDT
Received: by tilde id AA28552; Mon, 15 Jun 87 14:26:39 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 15 Jun 87  14:28:11 CDT
Message-Id: <2759772249-7706533@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Mon, 15 Jun 87  14:24:09 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: more concrete font proposal
In-Reply-To: Msg of Sat, 13 Jun 87 17:33 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>

Handling out-of-bounds index in char-<metric>:
    Signalling an error would be appropriate. Since sufficient info to avoid the
    error is available, an out-of-bounds index is a coding flub.

:max/:min vs separate accessors:
    Agree that separate accessors is better. Better to know the max/min integer
    since this could conceivably be useful in counting or in setting up loops.

&key width for draw-glyph:
    Yes, for consistency's sake.

draw-text
    Seems to me the PolyText request is designed to performed "formatted"
    output, such as multiple columns or fully-justified lines of text (perhaps
    the latter is the real intent of the request). In this case, having
    separate draw-glyph calls rediscover how to append themselves together again
    constitutes a bit of ring-around-the-rosie. Is this a serious problem? The
    :widths approach is actually a superior interface for laying out columns. 

    If fully-justified text output is in sufficient demand to warrant a special
    interface, then I'm not sure if the 3-valued transform you suggested is the
    best way. Better something like the current draw-text, with its precomputed
    sequence of fonts, deltas, and indexes.

∂17-Jun-87  1300	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87  13:00:35 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Jun 87 15:57-EDT
Date: Wed, 17 Jun 87 15:57 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2759757310-3394403@SI>
Message-ID: <870617155712.8.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Mon, 15 Jun 87  10:15:10 CDT
    From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>

    I like the parts of your proposal related to font and char info.  I have
    some concerns about using closures for string transformations.

I don't see that a closure, as opposed to a simple function, is
necessarily involved.  An application dealing with strings, as opposed
to (vector character), doesn't require a closure, it simply requires a
character-set translation.

								    By
    having the transformation return NIL when a font change is required, all
    you've done is shove the font problem up to the next level.

It isn't necessarily a font change, it can also be due to format control
(space, tab, newline, even ~ directives).

								 If I write
    a toolkit on top of CLX, it can't be portable, because all the places
    that use CLX functions taking transform arguments will have to be
    modified (what's the right thing to do when the transform function
    returns NIL?).

I don't understand this at all, and certainly not if the "CLX functions"
you think have to be modified are things like draw-glyphs.  Perhaps you
could give a concrete example?

		    It sure would be nice if we could agree on how to
    display multi-fonted text in CLX, rather than making every toolkit
    re-invent it.

I'm no longer convinced that characters will necessarily be the only
"source" for text output.  This doesn't preclude agreeing on a
character-translation interface, but it can argue against characters
being the only interface.

    I agree with Robert Kerns and Seth Steinberg's suggestions that an
    implementation dependent function be specified for translating character
    objects into font/index pairs.  I.E.

    (deftype font-list () '(or font gcontext (sequence (or font gcontext))))

    (defun char-font-and-index (font-list character)
      ;; Implementation dependent function for translating CL character objects
      ;; font-list is a sequence used to provide information about what font
      ;; to use given (char-font character) and (char-code character)
      (declare (type font-list font-list)
	       (type character character)
	       (inline char-font-and-index))
      (values index font))

I don't see how this has a prayer of working.  An "implementation
dependent" function, as near as I can tell, will be "dependent" on the
particular CL implementation of characters, but cannot be "dependent" on
a particular X server or font set.  That *might* give you a good enough
handle to determine what the local character set is, but as far as I can
tell it doesn't give you *any* clue to what the character sets employed
by the particular fonts are.  I don't know of any way to hide/solve this
problem, except by mandating that CLX will only work with fonts with
particular characteristics.

How many non-lispm CL implementations actually have a non-zero
char-font-limit?  Does anyone really agree on the use of font
attributes?  How can one write portable code in this environment, except
by avoiding character objects?

∂17-Jun-87  1310	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87  13:10:42 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Jun 87 16:10-EDT
Date: Wed, 17 Jun 87 16:10 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2759772249-7706533@Sierra>
Message-ID: <870617161017.9.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Mon, 15 Jun 87  14:24:09 CDT

    draw-text
	Seems to me the PolyText request is designed to performed "formatted"
	output, such as multiple columns or fully-justified lines of text (perhaps
	the latter is the real intent of the request).

Spacing between words is the real intent.

							In this case, having
	separate draw-glyph calls rediscover how to append themselves together again
	constitutes a bit of ring-around-the-rosie. Is this a serious problem? The
	:widths approach is actually a superior interface for laying out columns. 

	If fully-justified text output is in sufficient demand to warrant a special
	interface, then I'm not sure if the 3-valued transform you suggested is the
	best way. Better something like the current draw-text, with its precomputed
	sequence of fonts, deltas, and indexes.

I guess this depends on whether you think the application is likely to keep data
structures in that particular form (which either means the application is fairly
X specific or else the "application" is really an X toolkit that is additionally
buffering output) or simply recompute output on the fly.

∂17-Jun-87  1341	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	re: pseudo fonts    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87  13:41:22 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Jun 87 16:33-EDT
Date: Wed, 17 Jun 87 16:34 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: re: pseudo fonts
To: cl-windows@sail.stanford.edu
Message-ID: <870617163409.0.RWS@KILLINGTON.LCS.MIT.EDU>

    From: anon

    I'm not sure of this pseudo-font stuff.

I agree; I'm not particularly happy with it either.  My hope is that
seeing the stuff written down might lead to some ideas.

					     I guess if it's a strict
    requirement that all protocol facilities be available from the library,
    you need it.  If not, I'd think of supplying a GC as just a convenience
    that could be foregone in this language binding.

The major reason the protocol allows querying via the gcontext is to let
the application get at the "default font" initially stored in the
gcontext; a particularly trivial application could decide to just use
it, without opening a font explicitly.  I don't know if this is a very
compelling argument, or whether it is worth the interface complexity to
mirror it.

Short of eliminating pseudo fonts, I suppose another possibility would
be to retain font-info objects (but not as explicit defstructs), and
change appropriate accessors to accept (or font font-info) as arguments.

∂18-Jun-87  0652	sas@bfly-vax.bbn.com 	Re: more concrete font proposal  
Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 18 Jun 87  06:52:00 PDT
Date: Thu, 18 Jun 87 08:43 EDT
From: Seth Steinberg <sas@bfly-vax.bbn.com>
Subject: Re: more concrete font proposal
To: cl-windows@sail.stanford.edu

Mr. Scheifler has raised a valid point and I believe partially answered
it:

> I don't see how this has a prayer of working.  An "implementation
> dependent" function, as near as I can tell, will be "dependent" on the
> particular CL implementation of characters, but cannot be "dependent" on
> a particular X server or font set.  That *might* give you a good enough
> handle to determine what the local character set is, but as far as I can
> tell it doesn't give you *any* clue to what the character sets employed
> by the particular fonts are.  I don't know of any way to hide/solve this
> problem, except by mandating that CLX will only work with fonts with
> particular characteristics.
>
> ...  Does anyone really agree on the use of font attributes? ...

Since fonts are used for all sorts of things, not just displaying
ASCII, it might be a good idea to recognize this fact and have some
kind of "font attribute" which tells how well the font (or font set,
when necessary) handles displaying ASCII (e.g. :alphanumeric :printing
:national <xxx> (as opposed to ASCII which is American) and so on).
I'll assume that other parties can concentrate on how to display Kanji,
or Hindi, or Space War.

It would be real nice if the windows standard provided some system
independent means of displaying the characters in the Common Lisp
"standard character set" as described in section 2.2 of Steele's Common
Lisp book.  Ah, life was some much simpler in the good old days:

		WRITE (6,23)
	23	FORMAT(14HGOOD OLD DAYS!)

						Seth

∂18-Jun-87  0940	@RELAY.CS.NET:Oren%Tilde@TI-CSL.CSNET 	Re: more concrete font proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 Jun 87  09:40:25 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa07966; 18 Jun 87 11:40 EDT
Received: from ti-csl by RELAY.CS.NET id ab01285; 18 Jun 87 11:31 EDT
Received: by tilde id AA12223; Thu, 18 Jun 87 09:34:16 CDT
Message-Id: <2760014046-3641752@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Thu, 18 Jun 87  09:34:06 CDT
From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: more concrete font proposal
In-Reply-To: Msg of Wed, 17 Jun 87 15:57 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>

>  Date: Wed, 17 Jun 87 15:57 EDT
>  From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
>  Subject: Re: more concrete font proposal
>  
>  								    By
>      having the transformation return NIL when a font change is required, all
>      you've done is shove the font problem up to the next level.
>  
>  It isn't necessarily a font change, it can also be due to format control
>  (space, tab, newline, even ~ directives).

Good point. I forgot about that.

>  								 If I write
>      a toolkit on top of CLX, it can't be portable, because all the places
>      that use CLX functions taking transform arguments will have to be
>      modified (what's the right thing to do when the transform function
>      returns NIL?).
>  
>  I don't understand this at all, and certainly not if the "CLX functions"
>  you think have to be modified are things like draw-glyphs.  Perhaps you
>  could give a concrete example?

Perhaps I'm trying to solve a nonexistent problem. I got the impression
from Moon and Kerns that its probable that a lisp's character set
couldn't be represented with a single font.  For example, #\alpha would
be in a different font from #\a.  If a transform function returns NIL on
the #\alpha character, what's the implementation independent way to
select the font?

>  I don't see that a closure, as opposed to a simple function, is
>  necessarily involved.  An application dealing with strings, as opposed
>  to (vector character), doesn't require a closure, it simply requires a
>  character-set translation.

If a single string-char can reference more than one font, the
translation function must return two values (index and font) and either
has to be a closure, or accept a font-sequence as an argument.

>  ... An "implementation
>  dependent" function, as near as I can tell, will be "dependent" on the
>  particular CL implementation of characters, but cannot be "dependent" on
>  a particular X server or font set.  That *might* give you a good enough
>  handle to determine what the local character set is, but as far as I can
>  tell it doesn't give you *any* clue to what the character sets employed
>  by the particular fonts are.  I don't know of any way to hide/solve this
>  problem, except by mandating that CLX will only work with fonts with
>  particular characteristics.

How can code be portable when the only standard you assume is CLX.
Why can't I assume that X fonts will conform to other standards like
ASCII and the ISO character set.  In addition to coping with random
char-code orderings, must CLX also cope with random font glyph
orderings?  Surely the C Xlib interface doesn't require these
complexities, why should the Lisp interface?

Since char-codes don't always match a standard font glyph ordering
(i.e.  ISO) an implementation dependent translation function is needed.

Since some characters aren't printed (i.e.  #\newline #\tab), the
translation function needs to escape back to a higher level, by
returning NIL.

Since a single font may not have all the glyphs needed for a lisp's
character set, the translation function needs to be a function of a
character and font-sequence, returning an index and font.  Once you've
gone this far, why limit the translation function to string-chars when
its easy to handle full character objects.

Since 80% of the graphics activity of most applications is in writing
text, it would be nice if CLX could do it efficiently.  Thats why I
suggested that there be a single in-line translation function to
eliminate the multiple-valued call/return for every character.

>  		    It sure would be nice if we could agree on how to
>      display multi-fonted text in CLX, rather than making every toolkit
>      re-invent it.
>  
>  I'm no longer convinced that characters will necessarily be the only
>  "source" for text output.  This doesn't preclude agreeing on a
>  character-translation interface, but it can argue against characters
>  being the only interface.

Please give an example where a sequence of integers is better than
a string of characters.

When it comes to non-character fonts (like math symbols or icons) it
seems to me that its just as easy to specify "the font glyph
corresponding to character #\X" (i.e. character objects) as it is to
specify font-index 88 (i.e. integers).

>  How many non-lispm CL implementations actually have a non-zero
>  char-font-limit?  Does anyone really agree on the use of font
>  attributes?  How can one write portable code in this environment, except
>  by avoiding character objects?

With more standards.  Isn't that what the CL-WINDOWS mailing list is
for?

Perhaps its too much to ask that level 2 code above CLX be completely
portable.  If the next level is going to have a file full of
implementation dependent functions that must be translated, then maybe
all this character translation stuff belongs there, rather than CLX
(i.e.  get rid of the transform functions in CLX).  If this is the case,
can we at least restrict text-extents, draw-glyphs, etc.  to vectors,
instead of sequences?  I can't see needing to use lists of characters,
and SVREF is a little faster than ELT.

One way to ensure that nobody programs using only the CLX interface is
to make it impossible to display a string of text (this is the situation
with your last proposal).  I hope that a level 2 proposal can be agreed
upon quickly.

∂19-Jun-87  0325	RWK@YUKON.SCRC.Symbolics.COM 	Re: more concrete font proposal    
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 19 Jun 87  03:24:20 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 227065; Fri 19-Jun-87 06:21:37 EDT
Date: Fri, 19 Jun 87 06:21 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: more concrete font proposal
To: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>
cc: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2760014046-3641752@SI>
Message-ID: <870619062117.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: Thu, 18 Jun 87  09:34:06 CDT
    From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>

    >  Date: Wed, 17 Jun 87 15:57 EDT
    >  From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
    >  Subject: Re: more concrete font proposal

    >  								 If I write
    >      a toolkit on top of CLX, it can't be portable, because all the places
    >      that use CLX functions taking transform arguments will have to be
    >      modified (what's the right thing to do when the transform function
    >      returns NIL?).
    >  
    >  I don't understand this at all, and certainly not if the "CLX functions"
    >  you think have to be modified are things like draw-glyphs.  Perhaps you
    >  could give a concrete example?

    Perhaps I'm trying to solve a nonexistent problem. I got the impression
    from Moon and Kerns that its probable that a lisp's character set
    couldn't be represented with a single font.  For example, #\alpha would
    be in a different font from #\a.  If a transform function returns NIL on
    the #\alpha character, what's the implementation independent way to
    select the font?
Let me explain this a little bit.

In our system, additional character sets can be loaded at any time.
For example, I could load Japanese, or Hebrew, or Cyrillic, and
create character objects in those character sets.

This has several consequences that are relevant to this discussion.

1) CHAR-CODE's usefulness is extremely limited.  It does not
index into fonts, because the CHAR-CODE values have to be dynamically
assigned.

2) As you noted, the set of all characters cannot live in a single
font.  That would require predetermination of all possible characters.

3) As I've noted in earlier messages, a given character must be translated
into a index into a font, not just an index.  For some systems, this
translation could be CHAR-CODE and a constant font, but not for all.

There's a bit more complexity here besides multiple character-sets,
as well.  The choice of font is not only determined by the character-set,
but also by what we call the character-style.  A character style is
a structured object, which is subject to defaulting of NIL components
from a default with per-stream dynamic extent.  A "normal" character
has NIL.NIL.NIL style, which means it takes its defaults from the
stream's current default.  This default can be bound; this is one
common way of doing bold-faced output.  I.e. you can do

(WITH-CHARACTER-STYLE ('(NIL :BOLD NIL) *STANDARD-OUTPUT*)
  (PRINT CODE *STANDARD-OUTPUT*))

to print bold-faced Lisp forms.  The characters didn't change, but
the choice of fonts did.  Yet characters in a string CAN specify
boldness, typestyle (which we call family) or size, on a character
by character basis.  If these properties are not specified, they
come from the default.  So you can take a string with an italicized
word, and display it at different sizes, or at different typefaces.

I've explained somewhat more of this than is actually relevant here,
so that I can make it a bit clearer how it affects what we need from
CLX.

4)  A given STRING-CHAR can (depending on context from the stream)
turn into one of several fonts.

5)  The choice of fonts cannot be determined independent of the
context.  This is one reason we cannot do character interpretation
at the raw CLX level; we need the context from the higher-level
(i.e. the stream).  This can be imported from the higher level
as a closure to do translation; that would be no problem for us.

I guess it's moot whether to consider the function that calls that
function to be at the CLX level or the higher level.  Personally
I'd consider it to be at the higher level, because the boundary
line is a bit clearer if you say "anything dealing with characters
is at the next level up".  But that's just a convenient place to
draw an arbitrary line.  Sort of like a river in geography, or
a state boundary in drawing timezone boundaries.

6) A character and a stream completely determine the choice of font and
the index into the font.

The character supplies the style, the character-set, and the index into
the character-set.  Usually, but not necessarily, the index into the
character-set is the index into the font.  The style is defaulted
against the stream's default.  The font is found by doing a 3-way lookup
on the character-set, the defaulted style, and the stream's output
device (i.e. the model that describes what's on the other end of the X
connection).

7) There is never a need (or opportunity) to separately specify a font.

8) We have no use whatsoever for integers to represent "fonts".  CL was
never clear on whether "fonts" were for implementing character-sets or
for character-styles, anyway.  So we just set CHAR-FONT-LIMIT to 1,
like everybody else.

    >  I don't see that a closure, as opposed to a simple function, is
    >  necessarily involved.  An application dealing with strings, as opposed
    >  to (vector character), 

I get confused, because there is a proposal on the floor (from the
Japanese contingent) for calling what you're calling (VECTOR CHARACTER)
STRING.  What you're calling STRING would be called INTERNAL-THIN-STRING.
What you're calling STRING-CHAR would be called INTERNAL-THIN-CHAR.
This is more than just a name change; the intent is that any application
should be able to deal with what you're calling (VECTOR CHARACTER).
(Ignore the BITS field).

			      doesn't require a closure, it simply requires a
    >  character-set translation.

    If a single string-char can reference more than one font, the
    translation function must return two values (index and font) and either
    has to be a closure, or accept a font-sequence as an argument.

This is true in our implementation.  A font-sequence wouldn't be
any help, there's no ordering of character-styles.  However, a
closure is no problem for us.

    >  ... An "implementation
    >  dependent" function, as near as I can tell, will be "dependent" on the
    >  particular CL implementation of characters, but cannot be "dependent" on
    >  a particular X server or font set.  That *might* give you a good enough
    >  handle to determine what the local character set is, but as far as I can
    >  tell it doesn't give you *any* clue to what the character sets employed
    >  by the particular fonts are.  I don't know of any way to hide/solve this
    >  problem, except by mandating that CLX will only work with fonts with
    >  particular characteristics.

    How can code be portable when the only standard you assume is CLX.
    Why can't I assume that X fonts will conform to other standards like
    ASCII and the ISO character set.  

Because they don't all so conform.  The fonts you have to work with
are the fonts that the server has.  But you can HOPE for it; you
just need a way to find out about it.

				      In addition to coping with random
    char-code orderings, must CLX also cope with random font glyph
    orderings?  
Surely they're not random.  Surely they implement SOME standard.

Unfortunately, X doesn't define or recommend any property on a font that
says just what standard it implements, so I don't see any way to
automatically choose an appropriate translation function.  Just assuming
ASCII or ISO isn't good enough; if I have a Symbolics 3650 and a Fujitsu
something-or-other, and they both support JIS Level 2, using fonts named
JIS12, JIS16, JIS24, or JIS48 on the 3650 and fonts named Japanese10,
Japanese20, and Japanese 30 on the Fujitsu system.  I can set it up
manually, of course, but with a bit more information about the font I
could figure it out automatically, without a priori knowing what a
Fujitsu is.

Similarly, talking to a server that only has fonts implementing EBCDIC,
I can choose a translator that translates to EBCDIC, if I can know about
that, but if I later figure out how to define an ASCII font, I'd like to
be able to switch to using that.  (Even better would be a font that implements
the entire Lispm standard character-set).

(But what do we do when a server has no font that implements a given
character?  Signal a specific condition, and substitute "#" if the
condition isn't handled?  Signal a specific error?)
		
		Surely the C Xlib interface doesn't require these
    complexities, why should the Lisp interface?

How many C clients do you know that deal with multiple character-sets?
That allocate the character-indexes dynamically?  That deal with
characters as first-class objects?

    Since char-codes don't always match a standard font glyph ordering
    (i.e.  ISO) an implementation dependent translation function is needed.

    Since some characters aren't printed (i.e.  #\newline #\tab), the
    translation function needs to escape back to a higher level, by
    returning NIL.

    Since a single font may not have all the glyphs needed for a lisp's
    character set, the translation function needs to be a function of a
    character and font-sequence, returning an index and font.  Once you've
    gone this far, why limit the translation function to string-chars when
    its easy to handle full character objects.
Agreed.

By the way, I'm curious as to what you think this "font-sequence" is
for.  Is it indexed by position of the character in the string, or by
the CHAR-FONT?

Does anyone actually use CHAR-FONT?  If so, can they explain how they
use it?  Are the indexes global?  Do they mean a character is a different
character (in the sense of STRING-EQUAL)?  Do you use them for multiple
languages, or just for different presentation of English characters?

    Since 80% of the graphics activity of most applications is in writing
    text, it would be nice if CLX could do it efficiently.  Thats why I
    suggested that there be a single in-line translation function to
    eliminate the multiple-valued call/return for every character.

[I can't find where you proposed this, to compare our views].
I'd like to see something like this:

(defun make-translate-string (default-style device)
  (labels ((translate-string (font-change string string-start string-end)
	     ;; This is the actual translator function
	     (DECLARE (TYPE FUNCTION FONT-CHANGE)
		      (TYPE STRING STRING)
		      (TYPE INTEGER STRING-START)
		      (TYPE INTEGER STRING-END))
	     (do ((i string-start (1+ i))
		  (char) (char-font) (char-index)
		  (current-font)
		  (buffer) (buffer-start) (buffer-end)
		  (buffer-pointer nil (1+ buffer-pointer)))
		 ((= i string-end))
	       (setf char (aref string i))
	       (multiple-value-setq (char-font char-index)
		 (lookup-font-and-index char device default-style))
	       ;; Handle the exceptional cases.
	       (unless (and (eql current-font char-font)
			    (not (= buffer-start buffer-end)))
		 ;; New font; tell the caller about the new font, and how
		 ;; much of the buffer we've used.  He'll give us back a
		 ;; new buffer, of the right size for this font.
		 (multiple-value-setq (buffer buffer-start buffer-end)
		   (funcall font-change char-font buffer-pointer))
		 (setq current-font char-font)
		 (setq buffer-pointer buffer-start))
	       ;; Translate one character
	       (setf (aref buffer buffer-pointer) char-index))))
    #'translate-string))

The reason I made the translation function call back the caller rather
than return on exceptions is to give the caller a chance to output the
font-changes BEFORE we stick the output into the buffer.

Most implementations, in most situations, wouldn't need to close over
anything, but I illustrated how we need to close over the default style
and the device.

    >  		    It sure would be nice if we could agree on how to
    >      display multi-fonted text in CLX, rather than making every toolkit
    >      re-invent it.
    >  
    >  I'm no longer convinced that characters will necessarily be the only
    >  "source" for text output.  This doesn't preclude agreeing on a
    >  character-translation interface, but it can argue against characters
    >  being the only interface.

    Please give an example where a sequence of integers is better than
    a string of characters.

    When it comes to non-character fonts (like math symbols or icons) it
    seems to me that its just as easy to specify "the font glyph
    corresponding to character #\X" (i.e. character objects) as it is to
    specify font-index 88 (i.e. integers).

What if that index doesn't correspond to a legal character?
This will frequently be the case.  Why should I have to create
bunches of illegal characters just to use CLX?

If there's going to be a character interface at all, why not
have it be the character in question, instead of some standin?
Why not use the math symbol or icon itself?  How does writing
#\X make anything simpler or clearer?

Also, #\X is not portable, even when you're talking about the
same font on the same server in two different client Lisps.

    >  How many non-lispm CL implementations actually have a non-zero
    >  char-font-limit?  
I haven't heard of any.
			 Does anyone really agree on the use of font
    >  attributes?  
I thought a while back a survey was done, and everyone pretty
much areed they were useless.
		    How can one write portable code in this environment, except
    >  by avoiding character objects?

    With more standards.  Isn't that what the CL-WINDOWS mailing list is
    for?

    Perhaps its too much to ask that level 2 code above CLX be completely
    portable.  If the next level is going to have a file full of
    implementation dependent functions that must be translated, then maybe
    all this character translation stuff belongs there, rather than CLX
    (i.e.  get rid of the transform functions in CLX).  

I'm not clear on what kind of portability you're talking about.
Are you talking about code that implements level 2 and uses CLX,
or are you talking about code written using level 2?

I think neither the code implementing Level 1 OR Level 2 can
be portable.

Code written using Level 1 could be portable if there was a way
to find out what protocol a given font on the server side implemented.

Code written using Level 2 would be portable.  But you need a
way to find out what protocol a given font on the server side
implements, in order to write Level 2.

							If this is the case,
    can we at least restrict text-extents, draw-glyphs, etc.  to vectors,
    instead of sequences?  
Yes!
			   I can't see needing to use lists of characters,
    and SVREF is a little faster than ELT.

    One way to ensure that nobody programs using only the CLX interface is
    to make it impossible to display a string of text (this is the situation
    with your last proposal).  
This sounds like a good argument for his proposal.
			       I hope that a level 2 proposal can be agreed
    upon quickly.

How about this?  This is sort of the "lowest level of Level 2", that is,
this brings the basics up to the level of characters, but does not introduce
streams.

;; I'm using the proposed definition of the STRING and STRING-CHAR types.

;;; Actually, this type is implementation dependent.
;;; NIL means to use a global default that makes sense for
;;; this implementation.
;;; Perhaps, instead, this should get merged in with a
;;; higher-level view of a gcontext?
(deftype context () `t)

;;; This needs the display, since it will be involved in determining fonts.
;;; If multiple fonts are used, ascent and descent are computed from a common
;;; baseline.  font-ascent and font-descent are maximized.
(defun text-display-extents (display string &key (start 0) end context)
  (declare (type display display)
	   (type string string)
	   (type context transform)
	   (values width ascent descent left right font-ascent font-descent direction
		   (or null integer))))

;;; This needs the display, since it will be involved in determining fonts.
(defun text-display-width (display string &key (start 0) end context)
  (declare (type display display)
	   (type string string)
	   (type context context)
	   (values integer (or null integer))))

;;; May side-effect on gcontext-font.
(defun display-character (drawable gcontext x y character &key width context)
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type string-char character)
	   (type integer (x y index))
	   (type context context)
	   (type (or null integer) width)))

;;; May side-effect on gcontext-font.
(defun display-string (drawable gcontext x y string
		       &key (start 0) end width context)
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type string string)
	   (type (or null integer) end width)
	   (type context context)
	   (values (or null integer))))

(defun display-image-character (drawable gcontext x y character &key width context)
  (declare (type drawable drawable)
	   (type string-char character)
	   (type gcontext gcontext)
	   (type context context)
	   (type integer (x y))
	   (type (or null integer) width)))

(defun display-image-string (drawable gcontext x y string
			     &key (start 0) end context width)
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type string string)
	   (type context context)
	   (type sequence sequence)
	   (type (or null integer) end width)
	   (values (or null integer))))

;;; [It's late, so I didn't worry about the stuff below.  Whatever the lower-level
;;;  interface does, I would propose a DISPLAY-TEXT, that works on STRING's, takes
;;;  no fonts, and calls DRAW-TEXT or DRAW-TEXT16 as needed.  --RWK]
;; Note: I haven't figured out what to do with draw-text (and draw-text16).  It
;; may be that their existing definitions aren't really very useful.  It may be
;; better to provide a function that takes a transform of the form:
;;   (function t (or null integer) (or null font) (or null integer))
;; where the first value is the index, the second is optionally a change in
;; font, and the third is optionally a delta in x coordinate.

∂19-Jun-87  0339	RWK@YUKON.SCRC.Symbolics.COM 	Re: more concrete font proposal    
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 19 Jun 87  03:38:52 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 227069; Fri 19-Jun-87 06:38:28 EDT
Date: Fri, 19 Jun 87 06:38 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: more concrete font proposal
To: Seth Steinberg <sas@bfly-vax.bbn.com>
cc: cl-windows@sail.stanford.edu
In-Reply-To: The message of 18 Jun 87 08:43 EDT from Seth Steinberg <sas@bfly-vax.bbn.com>
Message-ID: <870619063826.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: Thu, 18 Jun 87 08:43 EDT
    From: Seth Steinberg <sas@bfly-vax.bbn.com>

    Mr. Scheifler has raised a valid point and I believe partially answered
    it:

    > I don't see how this has a prayer of working.  An "implementation
    > dependent" function, as near as I can tell, will be "dependent" on the
    > particular CL implementation of characters, but cannot be "dependent" on
    > a particular X server or font set.  That *might* give you a good enough
    > handle to determine what the local character set is, but as far as I can
    > tell it doesn't give you *any* clue to what the character sets employed
    > by the particular fonts are.  I don't know of any way to hide/solve this
    > problem, except by mandating that CLX will only work with fonts with
    > particular characteristics.
    >
    > ...  Does anyone really agree on the use of font attributes? ...

    Since fonts are used for all sorts of things, not just displaying
    ASCII, it might be a good idea to recognize this fact and have some
    kind of "font attribute" which tells how well the font (or font set,
    when necessary) handles displaying ASCII (e.g. :alphanumeric :printing
    :national <xxx> (as opposed to ASCII which is American) and so on).
    I'll assume that other parties can concentrate on how to display Kanji,
    or Hindi, or Space War.
I guess great minds slide down the same gutter.

One problem I'm not sure how to deal with is fonts that implement a superset
of some standard set.  For example, there are many supersets of ASCII.
Perhaps if the font-type were a list of a standard plus extensions?
I.e. (:ASCII :SYMBOLICS) or (:JIS :LEVEL-2 :NIS-EXTRA-KANJI)

Since there's two chronologically different versions of JIS level 2,
with a few Kanji moved around and substituted, etc, this would allow
them to be distinguished.

    It would be real nice if the windows standard provided some system
    independent means of displaying the characters in the Common Lisp
    "standard character set" as described in section 2.2 of Steele's Common
    Lisp book.  Ah, life was some much simpler in the good old days:
Perhaps the windows standard (X, not CLX) could specify that at least
one font must support ASCII?  Perhaps even specify fixed-width, for
things that need that.  Even give the font a standard name, to make it
easier to find.

∂24-Jun-87  0723	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Jun 87  07:23:12 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 24 Jun 87 10:22-EDT
Date: Wed, 24 Jun 87 10:22 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2760014046-3641752@SI>
Message-ID: <870624102240.8.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Thu, 18 Jun 87  09:34:06 CDT
    From: LaMott Oren <Oren%Tilde%ti-csl.csnet@RELAY.CS.NET>

    How can code be portable when the only standard you assume is CLX.
    Why can't I assume that X fonts will conform to other standards like
    ASCII and the ISO character set.

It is very desirable to have X fonts conform to other standards, but the
problem is the "s" on the end of "standards".  There is no such thing as
"the ISO character set".  There are currently four ISO Latin character
sets.  In the beta release of X11, we've incorporated these, plus
Katakana, Arabic, Cryllic, Greek, Hebrew, and a few non-language
character sets into the keyboard symbol description set; others will
undoubtedly get added in the future.  All of these are candidates for
inclusion in fonts.  And of course, there are plenty of other font
compositions around to muddy the water.  For example, TeX fonts have
their own scheme, Adobe fonts have their own scheme, Symbolics fonts
have their own scheme, etc.

It was an explicit "feature" that the X protocol doesn't mandate font
naming or indexing.  There just isn't a consensus as to how it should be
done.  However, this doesn't preclude a layered standard, and there are
people who have done some thinking about the problem, and hope to work
on a proposal during the next few months.  Anyone interested in
contributing to this effort should feel free to contact me.

				      In addition to coping with random
    char-code orderings, must CLX also cope with random font glyph
    orderings?

They aren't "random", but I am forced to the conclusion that CLX cannot
mandate particular glyph orderings; it must be "policy-free" in this
case, with character translation provided "from above".  That doesn't
preclude providing "standard translations", as long as you can agree on
what the interesting font encodings are.

		Surely the C Xlib interface doesn't require these
    complexities, why should the Lisp interface?

What you see in the C Xlib depends on how naive you are.  The C routines
take in "char *" pointers.  A naive person will view that as equivalent
to a CL string, with an implicit char-code transform.  A more rational
view is that "char" is simply (unsigned-byte 8), with the transformation
already applied before calling Xlib.  The strict equivalent in CLX would
be to only accept (vector (unsigned-byte 8)), but I find the idea of
accepting a transform more appealing.

    Since char-codes don't always match a standard font glyph ordering
    (i.e.  ISO) an implementation dependent translation function is needed.

I really don't see an acceptable way for CLX to "know" how to do the
translation.

    Since a single font may not have all the glyphs needed for a lisp's
    character set, the translation function needs to be a function of a
    character and font-sequence, returning an index and font.

This isn't strictly necessary.  Another way is to have the translation
function return nil when the font changes, and so avoid multiple values.

								Once you've
    gone this far, why limit the translation function to string-chars when
    its easy to handle full character objects.

Indeed, why limit to characters, rather than arbitrary objects?

    Since 80% of the graphics activity of most applications is in writing
    text, it would be nice if CLX could do it efficiently.

Agreed.  In fact, if you want to match current hardware, which can draw
more than 20,000 characters per second, then you've got less than 50
microseconds per character, meaning you need to do it *very*
efficiently.

							    Thats why I
    suggested that there be a single in-line translation function to
    eliminate the multiple-valued call/return for every character.

I'll agree eliminating multiple-values in the normal case is probably
important.  I disagree that there has to be a single in-line function.
There can be a general transform, and if people can agree on a particular
instance of such a transform, then that instance can be optimized:

(defun draw-standard-string (drawable gcontext x y string
			     &key (start 0) end width)
  ;; equivalent to draw-glyphs with :transform #'standard-string-transform,
  ;; and can be implemented that way if an implementation-specific
  ;; optimization is not otherwise provided
  )

The point is that by providing a general base interface, you gain
portability, without precluding system-dependent optimizations.  Perhaps
all you really want is to also define draw-standard-string and
standard-string-transform as part of CLX.  I won't complain, but I think
agreeing on any definition beyond "CL standard character set to ISO
Latin 1" is going to be hard.

    >  I'm no longer convinced that characters will necessarily be the only
    >  "source" for text output.  This doesn't preclude agreeing on a
    >  character-translation interface, but it can argue against characters
    >  being the only interface.

    Please give an example where a sequence of integers is better than
    a string of characters.

For example, an application that wants high-speed redisplay, and is
willing to do the character translation once up front, rather than on
every redisplay.  Or (I hate to keep harping on this) a Kanji
application that must use integers because there isn't a guaranteed
portable char-chode-limit of 65536.

∂24-Jun-87  0844	@EDDIE.MIT.EDU,@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU 	Re: more concrete font proposal
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Jun 87  08:43:40 PDT
Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 
	id <AA01833@EDDIE.MIT.EDU>; Wed, 24 Jun 87 11:36:13 EDT
Date: Wed, 24 Jun 87 11:37 EDT
From: Robert Scheifler <@EDDIE.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: RWK@YUKON.SCRC.Symbolics.COM, Oren%Tilde%ti-csl.csnet@RELAY.CS.NET
Cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870619062117.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-Id: <870624113730.2.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Fri, 19 Jun 87 06:21 EDT
    From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>

    Unfortunately, X doesn't define or recommend any property on a font that
    says just what standard it implements, so I don't see any way to
    automatically choose an appropriate translation function.

This is in fact one possibility that is being considered inclusion in a
layered standard.

    (defun make-translate-string (default-style device)
      (labels ((translate-string (font-change string string-start string-end)
		 ;; This is the actual translator function
		 (DECLARE (TYPE FUNCTION FONT-CHANGE)
			  (TYPE STRING STRING)
			  (TYPE INTEGER STRING-START)
			  (TYPE INTEGER STRING-END))
		 (do ((i string-start (1+ i))
		      (char) (char-font) (char-index)
		      (current-font)
		      (buffer) (buffer-start) (buffer-end)
		      (buffer-pointer nil (1+ buffer-pointer)))
		     ((= i string-end))
		   (setf char (aref string i))
		   (multiple-value-setq (char-font char-index)
		     (lookup-font-and-index char device default-style))
		   ;; Handle the exceptional cases.
		   (unless (and (eql current-font char-font)
				(not (= buffer-start buffer-end)))
		     ;; New font; tell the caller about the new font, and how
		     ;; much of the buffer we've used.  He'll give us back a
		     ;; new buffer, of the right size for this font.
		     (multiple-value-setq (buffer buffer-start buffer-end)
		       (funcall font-change char-font buffer-pointer))
		     (setq current-font char-font)
		     (setq buffer-pointer buffer-start))
		   ;; Translate one character
		   (setf (aref buffer buffer-pointer) char-index))))
	#'translate-string))

    The reason I made the translation function call back the caller rather
    than return on exceptions is to give the caller a chance to output the
    font-changes BEFORE we stick the output into the buffer.

This would seem to *require* a closure for font-change.  If closure
creation or invocation results in consing in typical CL implementations,
this won't be a very desirable interface.  Also, exposing an internal
structure (the buffer) to unrestricted use in "user code" seems
undesirable unless it is critical to performance.  Also, the comment
about the "right" buffer size is somewhat suspect.  First, the X
protocol allows 8-bit indexes for 16-bit fonts; your interface would
seem to always require 16-bit indexes, e.g., even when the effective
character set is Latin 1 but the font happens to have all of JIS.  Also,
the standard X byte stream is based on 8-bit bytes, with 16-bit font
indexes (as opposed to first-byte/second-byte) transmitted most
significant byte first.  Your interface would seem to require an extra
pass over the buffer to byte-swap on some systems, and would also seem
to require either the ability to displace 16-bit arrays onto 8-bit
arrays (which CLtL says "is an error") or an extra buffer and a copy.

    ;; I'm using the proposed definition of the STRING and STRING-CHAR types.

    ;;; Actually, this type is implementation dependent.
    ;;; NIL means to use a global default that makes sense for
    ;;; this implementation.
What is the scope of an "implementation"?  Are there assumptions about
character sets and fonts used?
    ;;; Perhaps, instead, this should get merged in with a
    ;;; higher-level view of a gcontext?
Actually adding a component to the CLX-level gcontext might be
reasonable.
    (deftype context () `t)

Is translate-string above an example of a context?  If not, what is
the relationship, and what are the operations on a context?

    ;;; This needs the display, since it will be involved in determining fonts.
    ;;; If multiple fonts are used, ascent and descent are computed from a common
    ;;; baseline.  font-ascent and font-descent are maximized.
    (defun text-display-extents (display string &key (start 0) end context)
      (declare (type display display)
	       (type string string)
	       (type context transform)
	       (values width ascent descent left right font-ascent font-descent direction
		       (or null integer))))

If translate-string is an example of a context, then the implementation
of this when the metrics are local involves a somewhat useless storing
and fetching of indexes into an intermediate buffer, but I suppose the
output functions are the critical ones for performance.

If translate-string is an example of a context, then I don't see why
text-display-extents and the other functions you listed care what the
type of the string argument is; presumably it is simply up to the caller
(of text-display-extents) to provide an argument that matches the type
expected for the second argument to transform.  It doesn't even need to
be vector, much less have a particular element-type.

    ;;; [It's late, so I didn't worry about the stuff below.  Whatever the lower-level
    ;;;  interface does, I would propose a DISPLAY-TEXT, that works on STRING's, takes
    ;;;  no fonts, and calls DRAW-TEXT or DRAW-TEXT16 as needed.  --RWK]

Your proposed interface essentially subsumes draw-text; the distinction between
draw-glyphs and draw-text was one of allowing embedded font-shifts.

∂24-Jun-87  1056	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	CLX beta changes    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Jun 87  10:55:59 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 24 Jun 87 13:45-EDT
Date: Wed, 24 Jun 87 13:44 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX beta changes
To: cl-windows@sail.stanford.edu
Message-ID: <870624134459.4.RWS@KILLINGTON.LCS.MIT.EDU>

The following reflect changes between the Alpha-Update and the Beta
protocol documents.  The Beta protocol document, and a revisions file,
are available via anonymous ftp to zap.mit.edu; I will mail them to
anyone who wants them but doesn't have ftp access.

Things that get removed:

  device from screen defstruct
  display-keyboard
  display-pointer
  property-error
  keyboard-mapping and setf    (but name reused with different semantics below)

Things that get altered:

  in modifier-key, :caps-lock renamed to :lock
  in get-property, nil is returned for the type when the protocol returns None
  in :exposure and :graphics-exposure events,
    (boolean last-p) is changed to (integer count)

The rest is new:

(defun display-keycode-range (display)
  (declare (type display display)
	   (values min max)))

;; Should this signal device-busy like the pointer-mapping setf, and return a
;; boolean instead (true for success)?  Alternatively, should the
;; pointer-mapping setf be changed to set-pointer-mapping with a (member
;; :success :busy) result?

(defun set-modifier-mapping (display &key shift lock control mod1 mod2 mod3 mod4 mod5)
  ;; Setf ought to allow multiple values.
  (declare (type display display)
	   (type (or null integer) lock)
	   ;; (list integer) is really a list of length 2
	   (type (or null integer (list integer)) shift control
						  mod1 mod2 mod3 mod4 mod5)
	   (values (member :success :busy :failed))))

(defun modifier-mapping (display)
  ;; each value is either nil, a single integer, or a list of two integers
  (declare (type display display)
	   (values shift lock control mod1 mod2 mod3 mod4 mod5)))

;; Either we will want lots of defconstants for well-known values, or perhaps
;; an integer-to-keyword translation function for well-known values.

(deftype keysym () 'integer)

(defun change-keyboard-mapping (display keysyms &key (start1 0) end1 (start2 start1))
  ;; start1/end1 give subrange of keysyms
  ;; start2 is the first-keycode to store at
  ;; are there better argument names?
  (declare (type display display)
	   (type integer start1 start2)
	   (type (or null integer) end1)
	   (type (array keysym 2))))

(defun keyboard-mapping (display &key start end)
  (declare (type display display)
	   (type (or null integer) start end)
	   (values (array keysym 2))))

(declare-event :mapping-notify
	       ((member :modifier :keyboard :pointer) request)
	       (integer start count))	; transform count to end instead?

∂24-Jun-87  1236	RWK@YUKON.SCRC.Symbolics.COM 	Re: more concrete font proposal    
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jun 87  12:36:11 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 229633; Wed 24-Jun-87 15:34:21 EDT
Date: Wed, 24 Jun 87 15:34 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: more concrete font proposal
To: Robert Scheifler <@EDDIE.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU>
cc: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870624113730.2.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870624153416.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: Wed, 24 Jun 87 11:37 EDT
    From: Robert Scheifler <@EDDIE.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU>

	Date: Fri, 19 Jun 87 06:21 EDT
	From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>

	Unfortunately, X doesn't define or recommend any property on a font that
	says just what standard it implements, so I don't see any way to
	automatically choose an appropriate translation function.

    This is in fact one possibility that is being considered inclusion in a
    layered standard.

Sounds good.

	(defun make-translate-string (default-style device)
	  (labels ((translate-string (font-change string string-start string-end)
		     ;; This is the actual translator function
		     (DECLARE (TYPE FUNCTION FONT-CHANGE)
			      (TYPE STRING STRING)
			      (TYPE INTEGER STRING-START)
			      (TYPE INTEGER STRING-END))
		     (do ((i string-start (1+ i))
			  (char) (char-font) (char-index)
			  (current-font)
			  (buffer) (buffer-start) (buffer-end)
			  (buffer-pointer nil (1+ buffer-pointer)))
			 ((= i string-end))
		       (setf char (aref string i))
		       (multiple-value-setq (char-font char-index)
			 (lookup-font-and-index char device default-style))
		       ;; Handle the exceptional cases.
		       (unless (and (eql current-font char-font)
				    (not (= buffer-start buffer-end)))
			 ;; New font; tell the caller about the new font, and how
			 ;; much of the buffer we've used.  He'll give us back a
			 ;; new buffer, of the right size for this font.
			 (multiple-value-setq (buffer buffer-start buffer-end)
			   (funcall font-change char-font buffer-pointer))
			 (setq current-font char-font)
			 (setq buffer-pointer buffer-start))
		       ;; Translate one character
		       (setf (aref buffer buffer-pointer) char-index))))
	    #'translate-string))

	The reason I made the translation function call back the caller rather
	than return on exceptions is to give the caller a chance to output the
	font-changes BEFORE we stick the output into the buffer.

    This would seem to *require* a closure for font-change.  If closure
    creation or invocation results in consing in typical CL implementations,
    this won't be a very desirable interface.  

It only requires a closure in implementations which to close over the
default style or device.  And if they only need to close over the device,
then this closure only need be consed once per device.

This example wasn't for an arbitrary implementation; I expect
most implementations will not need to cons closures for this
at all, or only once per device.  In our case, the closure
wouldn't have to be consed.  I simplified the example a bit;
we don't have to call LOOKUP-FONT-AND-INDEX for every
character, either.  In fact, under this scheme, we would only
have to do function calls on font changes and buffer boundaries.

					       Also, exposing an internal
    structure (the buffer) to unrestricted use in "user code" seems
    undesirable unless it is critical to performance.  

I believe it is critical to performance.  As I noted above,
we don't have to have function calls except on font-shift
or buffer boundaries.  I don't think there's any other way
you can achieve this level of efficiency without giving the
translation function the buffer.  An implementation can choose
to give out a buffer that is an indirect-array to a portion of
his real buffer if it wishes, or even a dummy buffer that it
then copies into the real buffer.

Even if an implementation has AREF and ASET be as slow as
function calls, it is probably faster to do it this way,
because some of the work can be done just once per call
to the translator, or once per font-shift.  You can't do
that kind of optimization when you call once per character.

						       Also, the comment
    about the "right" buffer size is somewhat suspect.  First, the X
    protocol allows 8-bit indexes for 16-bit fonts; your interface would
    seem to always require 16-bit indexes, e.g., even when the effective
    character set is Latin 1 but the font happens to have all of JIS.  

(Bleh, talk about non-standard indexing!)  OK, then give the font-change
callback routine three more arguments:

  (funcall font-change char-font buffer-pointer string i string-end)

so it can do prediction if it wants.  Or see below.

				       Also,
    the standard X byte stream is based on 8-bit bytes, with 16-bit font
    indexes (as opposed to first-byte/second-byte) transmitted most
    significant byte first.  Your interface would seem to require an extra
    pass over the buffer to byte-swap on some systems, and would also seem
    to require either the ability to displace 16-bit arrays onto 8-bit
    arrays (which CLtL says "is an error") or an extra buffer and a copy.

Whatever's appropriate on a given implementation.  There's
nothing wrong with an extra buffer and a copy.  This is
a high-bandwidth communications path between a translation
function and the lower level.  An "extra" buffer is a small
price to pay to cut down on the number of function calls
by approximately 1/buffer-size.

Byte swapping is only an issue if you make it one; i.e. if
you displace 16-bit arrays onto 8-bit arrays.  The real point
of the buffer is not to be a way to get the data directly into
the network packet, but rather to get the data from the
translation function to the transmission routine as efficiently
as possible.  If it's possible in a given implementation to
optimize this to putting bytes directly into network packets,
fine, but that's not the point.

	;; I'm using the proposed definition of the STRING and STRING-CHAR types.

	;;; Actually, this type is implementation dependent.
	;;; NIL means to use a global default that makes sense for
	;;; this implementation.
    What is the scope of an "implementation"?  Are there assumptions about
    character sets and fonts used?

I'm not sure what you're asking.  I didn't know implementations had scopes.
Assumptions character sets and fonts used by whom?  Where?  Huh?

Stabbing in the dark, I'll try explaining some more and hoping I answer
your questions by accident.  (And save one round of messages).  The
purpose of the context is to provide a way for implementations to
contextually modify the interpretation of the characters.  It is
essentially information that the translator function might need, to
translate from characters to fonts & indicies.

In our system, it provides the current-character-style.  In an implementation
that used CHAR-FONTS, it might be an array of fonts.  Probably in both
cases the context would either be a stream, or be derived from a stream.

I don't see how there could be any assumptions about character sets or
fonts, but then I don't understand the question.

	;;; Perhaps, instead, this should get merged in with a
	;;; higher-level view of a gcontext?
    Actually adding a component to the CLX-level gcontext might be
    reasonable.
Well, how does the higher level get its hands on it.  If this
CONTEXT is a stream, then both how did this higher level get
its hands on the GCONTEXT, and how did the GCONTEXT get its
hands on the STREAM, which came from yet a higher level?

I'm not sure I understand the modularity of GCONTEXT's.

	(deftype context () `t)

    Is translate-string above an example of a context?  
That wasn't my intent, but it could serve, with a translator
that just called the context as a function on its arguments.
But see below.
							If not, what is
    the relationship, and what are the operations on a context?

My intent was that the context is used to derive the translation
function.  I didn't think that I needed to specify how it would
be derived, but I missed seeing that that just passed up the
implementation-dependence up a layer.  Part of the purpose of
this layer is to be able to enable users to write
implementation-independent software on top of it.  (That's why
there's a default context).

So, there are just two operations a context needs to support:

(defun get-output-translation-function (context)
  (declare (type context context)
	   (values output-translation-function)))

;;; We forgot about translation on input!  This can safely be
;;; a character-at-a-time unbuffered.

(defun get-input-translation-function (context)
  (declare (type context context)
	   (values input-translation-function)))

	;;; This needs the display, since it will be involved in determining fonts.
	;;; If multiple fonts are used, ascent and descent are computed from a common
	;;; baseline.  font-ascent and font-descent are maximized.
	(defun text-display-extents (display string &key (start 0) end context)
	  (declare (type display display)
		   (type string string)
		   (type context transform)
		   (values width ascent descent left right font-ascent font-descent direction
			   (or null integer))))

    If translate-string is an example of a context, then the implementation
    of this when the metrics are local involves a somewhat useless storing
    and fetching of indexes into an intermediate buffer, but I suppose the
    output functions are the critical ones for performance.
It's not useless.  It's the fastest way to get data from the
translation function to the routine going to interpret the
metrics.  This will be FASTER than if it didn't store into
an intermediate buffer, not SLOWER.

    If translate-string is an example of a context, 
Close enough to make the rest of your comment relevant...
						    then I don't see why
    text-display-extents and the other functions you listed care what the
    type of the string argument is; presumably it is simply up to the caller
    (of text-display-extents) to provide an argument that matches the type
    expected for the second argument to transform.  It doesn't even need to
    be vector, much less have a particular element-type.

This is true.  It makes it harder to specify in this
specification-language, though.  Do you think this is
worth including explicitly as part of the specification
for this layer?

	;;; [It's late, so I didn't worry about the stuff below.  Whatever the lower-level
	;;;  interface does, I would propose a DISPLAY-TEXT, that works on STRING's, takes
	;;;  no fonts, and calls DRAW-TEXT or DRAW-TEXT16 as needed.  --RWK]

    Your proposed interface essentially subsumes draw-text; the distinction between
    draw-glyphs and draw-text was one of allowing embedded font-shifts.

Good.

∂24-Jun-87  1351	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Jun 87  13:51:38 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 24 Jun 87 16:50-EDT
Date: Wed, 24 Jun 87 16:50 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: RWK@YUKON.SCRC.Symbolics.COM
cc: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870624153416.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870624165008.8.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Wed, 24 Jun 87 15:34 EDT
    From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>

			     ;; New font; tell the caller about the new font, and how
			     ;; much of the buffer we've used.  He'll give us back a
			     ;; new buffer, of the right size for this font.
			     (multiple-value-setq (buffer buffer-start buffer-end)
			       (funcall font-change char-font buffer-pointer))

	    The reason I made the translation function call back the caller rather
	    than return on exceptions is to give the caller a chance to output the
	    font-changes BEFORE we stick the output into the buffer.

	This would seem to *require* a closure for font-change.  If closure
	creation or invocation results in consing in typical CL implementations,
	this won't be a very desirable interface.  

    It only requires a closure in implementations which to close over the
    default style or device.  And if they only need to close over the device,
    then this closure only need be consed once per device.

I'm talking about the font-change function, not the translate-string
function.  As you wrote it, it somehow has to encapsulate a buffer and
other state, which sounds like a closure.

∂25-Jun-87  0813	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jun 87  08:12:55 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 25 Jun 87 11:09-EDT
Date: Thu, 25 Jun 87 11:10 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: RWK@YUKON.SCRC.Symbolics.COM
cc: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870624153416.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870625111051.5.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Wed, 24 Jun 87 15:34 EDT
    From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>

	    ;;; Actually, this type is implementation dependent.
	    ;;; NIL means to use a global default that makes sense for
	    ;;; this implementation.
	What is the scope of an "implementation"?  Are there assumptions about
	character sets and fonts used?

    I'm not sure what you're asking.  I didn't know implementations had scopes.
    Assumptions character sets and fonts used by whom?  Where?  Huh?

I was really just trying to figure out whether the default global
context had to have knowledge of "non-standard" character features of
the local CL implementation (e.g., si:char-style), and whether it also
had to have knowledge of the font encodings.  That is, is it written as
part of CLX, or is it written for each (CL, CLX) pair, or can it
actually be written at all.  Anyway, I think I get the picture.

	    ;;; Perhaps, instead, this should get merged in with a
	    ;;; higher-level view of a gcontext?
	Actually adding a component to the CLX-level gcontext might be
	reasonable.
    Well, how does the higher level get its hands on it.  If this
    CONTEXT is a stream, then both how did this higher level get
    its hands on the GCONTEXT, and how did the GCONTEXT get its
    hands on the STREAM, which came from yet a higher level?

    I'm not sure I understand the modularity of GCONTEXT's.

Mostly I'm trying to figure out how to make your mini-level "go away"
(see below), but provide necessary capability in CLX.

    My intent was that the context is used to derive the translation
    function.

    (defun get-output-translation-function (context)
      (declare (type context context)
	       (values output-translation-function)))

So what I had in mind was, if you think of a context as something like a
stream, then the stream will likely contain a gcontext to get its work
done, and the stream can itself compute the translation function and
either store it in the gcontext whenever it needs to change, or bind it
using with-gcontext.  You can then argue about what translation function
to store when a gcontext is initially created, if one isn't specified.

If this is the essential operation on a context for output, then I don't
see why (at the CLX layer) passing in a context is any better than
passing in a translation function.

    ;;; We forgot about translation on input!  This can safely be
    ;;; a character-at-a-time unbuffered.

I've been intentionally ignoring this for now, both to avoid confusion
and while awaiting beta release so that people could see the KEYSYM
stuff.  The input side isn't the inverse of output (it doesn't convert a
font+index into a character), it needs to convert a KEYSYM+bits+???
into a character.

	If translate-string is an example of a context, 
    Close enough to make the rest of your comment relevant...
							then I don't see why
	text-display-extents and the other functions you listed care what the
	type of the string argument is; presumably it is simply up to the caller
	(of text-display-extents) to provide an argument that matches the type
	expected for the second argument to transform.  It doesn't even need to
	be vector, much less have a particular element-type.

    This is true.  It makes it harder to specify in this
    specification-language, though.  Do you think this is
    worth including explicitly as part of the specification
    for this layer?

I don't think it is any harder to specify.  Let me try by giving a
variation on your proposal that incorporates a number of changes:  it
isn't restricted to strings; it does not have contexts, just translation
functions; it eliminates the call-backs within the translator, and
eliminates the buffer limit; it allows delta-x motion by the translator;
it tries to sort out some problems with 8-bit vs. 16-bit indexing; it
allows the translator to convey width information for request chaining;
it raises various questions.


;; I would write a deftype, but it's easier to have argument names:

(defun translate-skeleton (src src-start src-end font dst dst-start)
  ;; dst is guaranteed to have room for (- src-end src-start) integer elements,
  ;; starting at dst-start; whether dst holds 8-bit or 16-bit elements depends
  ;; on context.  font is the current font, if known.  The function should
  ;; translate as many elements of src as possible into indexes in the current
  ;; font, and store them into dst.  The first return value should be the src
  ;; index of the first untranslated element.  If no further elements need to
  ;; be translated, the second return value should be nil.  If a horizontal
  ;; motion is required before further translation, the second return value
  ;; should be the delta in x coordinate.  If a font change is required for
  ;; further translation, the second return value should be the new font.  If
  ;; known, the pixel width of the translated text can be returned as the third
  ;; value; this can allow for appending of subsequent output to the same
  ;; protocol request, if no overall width has been specified at the higher
  ;; level.
  (declare (type sequence src)
	   (type integer src-start src-end dst-start)
	   (type (or null font) font)
	   (type vector dst)
	   (values integer (or null integer font) (or null integer))))

;; There is a question below of whether translate should always be required, or
;; if not, what the default should be or where it should come from.  For
;; example, the default could be something that expected a string as src and
;; translated the CL standard character set to ASCII indexes, and ignored fonts
;; and bits.  Or the default could expect a string but otherwise be "system
;; dependent".  Or the default could be something that expected a vector of
;; integers and did no translation.  Or the default could come from the
;; gcontext (but what about text-extents and text-width?).

(defun text-extents (sequence &key (start 0) end font translate)
  ;; If multiple fonts are involved, font-ascent and font-descent will be the
  ;; maximums.  If multiple directions are involved, the direction will be nil.
  ;; Translate will always be called with a 16-bit dst buffer.
  (declare (type sequence sequence)
	   (type (or null font gcontext) font)
	   (type translate translate)
	   (values width ascent descent left right font-ascent font-descent direction
		   (or null integer))))

(defun text-width (sequence &key (start 0) end font translate)
  ;; Translate will always be called with a 16-bit dst buffer.
  (declare (type sequence sequence)
	   (type (or null font gcontext) font)
	   (type translate translate)
	   (values integer (or null integer))))

;; This controls the element size of the dst buffer given to translate.  If
;; :default is specified, the size will be based on the current font, if known,
;; and otherwise 16 will be used.  [An alternative would be to pass the buffer
;; size to translate, and allow it to return the desired size if it doesn't
;; like the current size.  The problem is that the protocol doesn't allow
;; switching within a single request, so to allow switching would require
;; knowing the width of text, which isn't necessarily known.  We could call
;; text-width to compute it, but perhaps that is doing too many favors?]  [An
;; additional possibility is to allow an index-size of :two-byte, in which case
;; translate would be given a double-length 8-bit array, and translate would be
;; expected to store first-byte/second-byte instead of 16-bit integers.]

(deftype index-size () '(member :default 8 16))

;; In the functions below, if width is specified, it is assumed to be the total
;; pixel width of whatever string of glyphs is actually drawn.  Specifying
;; width will allow for appending the output of subsequent calls to the same
;; protocol request, provided gcontext has not been modified in the interim.
;; If width is not specified, appending of subsequent output might not occur
;; (unless translate returns the width).  Specifying width is simply a hint,
;; for performance.

(defun draw-glyph (drawable gcontext x y elt
		   &key translate width (size :default))
  ;; Returns true if elt is output, nil if translate refuses to output it.
  ;; Second result is width, if known.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y)
	   (type translate translate)
	   (type (or null integer) width)
	   (type index-size size)
	   (values boolean (or null integer))))

(defun draw-glyphs (drawable gcontext x y sequence
		    &key (start 0) end translate width (size :default))
  ;; First result is new start, if end was not reached.  Second result is
  ;; overall width, if known.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type sequence sequence)
	   (type (or null integer) end width)
	   (type translate translate)
	   (type index-size size)
	   (values (or null integer) (or null integer))))

(defun draw-image-glyph (drawable gcontext x y elt
			 &key translate width (size :default))
  ;; Returns true if elt is output, nil if translate refuses to output it.
  ;; Second result is overall width, if known.  An initial font change is
  ;; allowed from translate.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y)
	   (type translate translate)
	   (type (or null integer) width)
	   (type index-size size)
	   (values boolean (or null integer))))

(defun draw-image-glyphs (drawable gcontext x y sequence
			  &key (start 0) end width translate (size :default))
  ;; An initial font change is allowed from translate, but any subsequent font
  ;; change or horizontal motion will cause termination (because the protocol
  ;; doesn't support chaining).  [Alternatively, font changes could be accepted
  ;; as long as they are accompanied with a width return value, or always
  ;; accept font changes and call text-width as required.  However, horizontal
  ;; motion can't really be accepted, due to semantics.]  First result is new
  ;; start, if end was not reached.  Second result is overall width, if known.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type sequence sequence)
	   (type (or null integer) end width)
	   (type translate translate)
	   (type index-size size)
	   (values (or null integer) (or null integer))))

∂25-Jun-87  1028	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jun 87  08:12:55 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 25 Jun 87 11:09-EDT
Date: Thu, 25 Jun 87 11:10 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: RWK@YUKON.SCRC.Symbolics.COM
cc: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870624153416.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870625111051.5.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Wed, 24 Jun 87 15:34 EDT
    From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>

	    ;;; Actually, this type is implementation dependent.
	    ;;; NIL means to use a global default that makes sense for
	    ;;; this implementation.
	What is the scope of an "implementation"?  Are there assumptions about
	character sets and fonts used?

    I'm not sure what you're asking.  I didn't know implementations had scopes.
    Assumptions character sets and fonts used by whom?  Where?  Huh?

I was really just trying to figure out whether the default global
context had to have knowledge of "non-standard" character features of
the local CL implementation (e.g., si:char-style), and whether it also
had to have knowledge of the font encodings.  That is, is it written as
part of CLX, or is it written for each (CL, CLX) pair, or can it
actually be written at all.  Anyway, I think I get the picture.

	    ;;; Perhaps, instead, this should get merged in with a
	    ;;; higher-level view of a gcontext?
	Actually adding a component to the CLX-level gcontext might be
	reasonable.
    Well, how does the higher level get its hands on it.  If this
    CONTEXT is a stream, then both how did this higher level get
    its hands on the GCONTEXT, and how did the GCONTEXT get its
    hands on the STREAM, which came from yet a higher level?

    I'm not sure I understand the modularity of GCONTEXT's.

Mostly I'm trying to figure out how to make your mini-level "go away"
(see below), but provide necessary capability in CLX.

    My intent was that the context is used to derive the translation
    function.

    (defun get-output-translation-function (context)
      (declare (type context context)
	       (values output-translation-function)))

So what I had in mind was, if you think of a context as something like a
stream, then the stream will likely contain a gcontext to get its work
done, and the stream can itself compute the translation function and
either store it in the gcontext whenever it needs to change, or bind it
using with-gcontext.  You can then argue about what translation function
to store when a gcontext is initially created, if one isn't specified.

If this is the essential operation on a context for output, then I don't
see why (at the CLX layer) passing in a context is any better than
passing in a translation function.

    ;;; We forgot about translation on input!  This can safely be
    ;;; a character-at-a-time unbuffered.

I've been intentionally ignoring this for now, both to avoid confusion
and while awaiting beta release so that people could see the KEYSYM
stuff.  The input side isn't the inverse of output (it doesn't convert a
font+index into a character), it needs to convert a KEYSYM+bits+???
into a character.

	If translate-string is an example of a context, 
    Close enough to make the rest of your comment relevant...
							then I don't see why
	text-display-extents and the other functions you listed care what the
	type of the string argument is; presumably it is simply up to the caller
	(of text-display-extents) to provide an argument that matches the type
	expected for the second argument to transform.  It doesn't even need to
	be vector, much less have a particular element-type.

    This is true.  It makes it harder to specify in this
    specification-language, though.  Do you think this is
    worth including explicitly as part of the specification
    for this layer?

I don't think it is any harder to specify.  Let me try by giving a
variation on your proposal that incorporates a number of changes:  it
isn't restricted to strings; it does not have contexts, just translation
functions; it eliminates the call-backs within the translator, and
eliminates the buffer limit; it allows delta-x motion by the translator;
it tries to sort out some problems with 8-bit vs. 16-bit indexing; it
allows the translator to convey width information for request chaining;
it raises various questions.


;; I would write a deftype, but it's easier to have argument names:

(defun translate-skeleton (src src-start src-end font dst dst-start)
  ;; dst is guaranteed to have room for (- src-end src-start) integer elements,
  ;; starting at dst-start; whether dst holds 8-bit or 16-bit elements depends
  ;; on context.  font is the current font, if known.  The function should
  ;; translate as many elements of src as possible into indexes in the current
  ;; font, and store them into dst.  The first return value should be the src
  ;; index of the first untranslated element.  If no further elements need to
  ;; be translated, the second return value should be nil.  If a horizontal
  ;; motion is required before further translation, the second return value
  ;; should be the delta in x coordinate.  If a font change is required for
  ;; further translation, the second return value should be the new font.  If
  ;; known, the pixel width of the translated text can be returned as the third
  ;; value; this can allow for appending of subsequent output to the same
  ;; protocol request, if no overall width has been specified at the higher
  ;; level.
  (declare (type sequence src)
	   (type integer src-start src-end dst-start)
	   (type (or null font) font)
	   (type vector dst)
	   (values integer (or null integer font) (or null integer))))

;; There is a question below of whether translate should always be required, or
;; if not, what the default should be or where it should come from.  For
;; example, the default could be something that expected a string as src and
;; translated the CL standard character set to ASCII indexes, and ignored fonts
;; and bits.  Or the default could expect a string but otherwise be "system
;; dependent".  Or the default could be something that expected a vector of
;; integers and did no translation.  Or the default could come from the
;; gcontext (but what about text-extents and text-width?).

(defun text-extents (sequence &key (start 0) end font translate)
  ;; If multiple fonts are involved, font-ascent and font-descent will be the
  ;; maximums.  If multiple directions are involved, the direction will be nil.
  ;; Translate will always be called with a 16-bit dst buffer.
  (declare (type sequence sequence)
	   (type (or null font gcontext) font)
	   (type translate translate)
	   (values width ascent descent left right font-ascent font-descent direction
		   (or null integer))))

(defun text-width (sequence &key (start 0) end font translate)
  ;; Translate will always be called with a 16-bit dst buffer.
  (declare (type sequence sequence)
	   (type (or null font gcontext) font)
	   (type translate translate)
	   (values integer (or null integer))))

;; This controls the element size of the dst buffer given to translate.  If
;; :default is specified, the size will be based on the current font, if known,
;; and otherwise 16 will be used.  [An alternative would be to pass the buffer
;; size to translate, and allow it to return the desired size if it doesn't
;; like the current size.  The problem is that the protocol doesn't allow
;; switching within a single request, so to allow switching would require
;; knowing the width of text, which isn't necessarily known.  We could call
;; text-width to compute it, but perhaps that is doing too many favors?]  [An
;; additional possibility is to allow an index-size of :two-byte, in which case
;; translate would be given a double-length 8-bit array, and translate would be
;; expected to store first-byte/second-byte instead of 16-bit integers.]

(deftype index-size () '(member :default 8 16))

;; In the functions below, if width is specified, it is assumed to be the total
;; pixel width of whatever string of glyphs is actually drawn.  Specifying
;; width will allow for appending the output of subsequent calls to the same
;; protocol request, provided gcontext has not been modified in the interim.
;; If width is not specified, appending of subsequent output might not occur
;; (unless translate returns the width).  Specifying width is simply a hint,
;; for performance.

(defun draw-glyph (drawable gcontext x y elt
		   &key translate width (size :default))
  ;; Returns true if elt is output, nil if translate refuses to output it.
  ;; Second result is width, if known.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y)
	   (type translate translate)
	   (type (or null integer) width)
	   (type index-size size)
	   (values boolean (or null integer))))

(defun draw-glyphs (drawable gcontext x y sequence
		    &key (start 0) end translate width (size :default))
  ;; First result is new start, if end was not reached.  Second result is
  ;; overall width, if known.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type sequence sequence)
	   (type (or null integer) end width)
	   (type translate translate)
	   (type index-size size)
	   (values (or null integer) (or null integer))))

(defun draw-image-glyph (drawable gcontext x y elt
			 &key translate width (size :default))
  ;; Returns true if elt is output, nil if translate refuses to output it.
  ;; Second result is overall width, if known.  An initial font change is
  ;; allowed from translate.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y)
	   (type translate translate)
	   (type (or null integer) width)
	   (type index-size size)
	   (values boolean (or null integer))))

(defun draw-image-glyphs (drawable gcontext x y sequence
			  &key (start 0) end width translate (size :default))
  ;; An initial font change is allowed from translate, but any subsequent font
  ;; change or horizontal motion will cause termination (because the protocol
  ;; doesn't support chaining).  [Alternatively, font changes could be accepted
  ;; as long as they are accompanied with a width return value, or always
  ;; accept font changes and call text-width as required.  However, horizontal
  ;; motion can't really be accepted, due to semantics.]  First result is new
  ;; start, if end was not reached.  Second result is overall width, if known.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type sequence sequence)
	   (type (or null integer) end width)
	   (type translate translate)
	   (type index-size size)
	   (values (or null integer) (or null integer))))

∂25-Jun-87  1143	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jun 87  08:12:55 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 25 Jun 87 11:09-EDT
Date: Thu, 25 Jun 87 11:10 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: RWK@YUKON.SCRC.Symbolics.COM
cc: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870624153416.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870625111051.5.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Wed, 24 Jun 87 15:34 EDT
    From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>

	    ;;; Actually, this type is implementation dependent.
	    ;;; NIL means to use a global default that makes sense for
	    ;;; this implementation.
	What is the scope of an "implementation"?  Are there assumptions about
	character sets and fonts used?

    I'm not sure what you're asking.  I didn't know implementations had scopes.
    Assumptions character sets and fonts used by whom?  Where?  Huh?

I was really just trying to figure out whether the default global
context had to have knowledge of "non-standard" character features of
the local CL implementation (e.g., si:char-style), and whether it also
had to have knowledge of the font encodings.  That is, is it written as
part of CLX, or is it written for each (CL, CLX) pair, or can it
actually be written at all.  Anyway, I think I get the picture.

	    ;;; Perhaps, instead, this should get merged in with a
	    ;;; higher-level view of a gcontext?
	Actually adding a component to the CLX-level gcontext might be
	reasonable.
    Well, how does the higher level get its hands on it.  If this
    CONTEXT is a stream, then both how did this higher level get
    its hands on the GCONTEXT, and how did the GCONTEXT get its
    hands on the STREAM, which came from yet a higher level?

    I'm not sure I understand the modularity of GCONTEXT's.

Mostly I'm trying to figure out how to make your mini-level "go away"
(see below), but provide necessary capability in CLX.

    My intent was that the context is used to derive the translation
    function.

    (defun get-output-translation-function (context)
      (declare (type context context)
	       (values output-translation-function)))

So what I had in mind was, if you think of a context as something like a
stream, then the stream will likely contain a gcontext to get its work
done, and the stream can itself compute the translation function and
either store it in the gcontext whenever it needs to change, or bind it
using with-gcontext.  You can then argue about what translation function
to store when a gcontext is initially created, if one isn't specified.

If this is the essential operation on a context for output, then I don't
see why (at the CLX layer) passing in a context is any better than
passing in a translation function.

    ;;; We forgot about translation on input!  This can safely be
    ;;; a character-at-a-time unbuffered.

I've been intentionally ignoring this for now, both to avoid confusion
and while awaiting beta release so that people could see the KEYSYM
stuff.  The input side isn't the inverse of output (it doesn't convert a
font+index into a character), it needs to convert a KEYSYM+bits+???
into a character.

	If translate-string is an example of a context, 
    Close enough to make the rest of your comment relevant...
							then I don't see why
	text-display-extents and the other functions you listed care what the
	type of the string argument is; presumably it is simply up to the caller
	(of text-display-extents) to provide an argument that matches the type
	expected for the second argument to transform.  It doesn't even need to
	be vector, much less have a particular element-type.

    This is true.  It makes it harder to specify in this
    specification-language, though.  Do you think this is
    worth including explicitly as part of the specification
    for this layer?

I don't think it is any harder to specify.  Let me try by giving a
variation on your proposal that incorporates a number of changes:  it
isn't restricted to strings; it does not have contexts, just translation
functions; it eliminates the call-backs within the translator, and
eliminates the buffer limit; it allows delta-x motion by the translator;
it tries to sort out some problems with 8-bit vs. 16-bit indexing; it
allows the translator to convey width information for request chaining;
it raises various questions.


;; I would write a deftype, but it's easier to have argument names:

(defun translate-skeleton (src src-start src-end font dst dst-start)
  ;; dst is guaranteed to have room for (- src-end src-start) integer elements,
  ;; starting at dst-start; whether dst holds 8-bit or 16-bit elements depends
  ;; on context.  font is the current font, if known.  The function should
  ;; translate as many elements of src as possible into indexes in the current
  ;; font, and store them into dst.  The first return value should be the src
  ;; index of the first untranslated element.  If no further elements need to
  ;; be translated, the second return value should be nil.  If a horizontal
  ;; motion is required before further translation, the second return value
  ;; should be the delta in x coordinate.  If a font change is required for
  ;; further translation, the second return value should be the new font.  If
  ;; known, the pixel width of the translated text can be returned as the third
  ;; value; this can allow for appending of subsequent output to the same
  ;; protocol request, if no overall width has been specified at the higher
  ;; level.
  (declare (type sequence src)
	   (type integer src-start src-end dst-start)
	   (type (or null font) font)
	   (type vector dst)
	   (values integer (or null integer font) (or null integer))))

;; There is a question below of whether translate should always be required, or
;; if not, what the default should be or where it should come from.  For
;; example, the default could be something that expected a string as src and
;; translated the CL standard character set to ASCII indexes, and ignored fonts
;; and bits.  Or the default could expect a string but otherwise be "system
;; dependent".  Or the default could be something that expected a vector of
;; integers and did no translation.  Or the default could come from the
;; gcontext (but what about text-extents and text-width?).

(defun text-extents (sequence &key (start 0) end font translate)
  ;; If multiple fonts are involved, font-ascent and font-descent will be the
  ;; maximums.  If multiple directions are involved, the direction will be nil.
  ;; Translate will always be called with a 16-bit dst buffer.
  (declare (type sequence sequence)
	   (type (or null font gcontext) font)
	   (type translate translate)
	   (values width ascent descent left right font-ascent font-descent direction
		   (or null integer))))

(defun text-width (sequence &key (start 0) end font translate)
  ;; Translate will always be called with a 16-bit dst buffer.
  (declare (type sequence sequence)
	   (type (or null font gcontext) font)
	   (type translate translate)
	   (values integer (or null integer))))

;; This controls the element size of the dst buffer given to translate.  If
;; :default is specified, the size will be based on the current font, if known,
;; and otherwise 16 will be used.  [An alternative would be to pass the buffer
;; size to translate, and allow it to return the desired size if it doesn't
;; like the current size.  The problem is that the protocol doesn't allow
;; switching within a single request, so to allow switching would require
;; knowing the width of text, which isn't necessarily known.  We could call
;; text-width to compute it, but perhaps that is doing too many favors?]  [An
;; additional possibility is to allow an index-size of :two-byte, in which case
;; translate would be given a double-length 8-bit array, and translate would be
;; expected to store first-byte/second-byte instead of 16-bit integers.]

(deftype index-size () '(member :default 8 16))

;; In the functions below, if width is specified, it is assumed to be the total
;; pixel width of whatever string of glyphs is actually drawn.  Specifying
;; width will allow for appending the output of subsequent calls to the same
;; protocol request, provided gcontext has not been modified in the interim.
;; If width is not specified, appending of subsequent output might not occur
;; (unless translate returns the width).  Specifying width is simply a hint,
;; for performance.

(defun draw-glyph (drawable gcontext x y elt
		   &key translate width (size :default))
  ;; Returns true if elt is output, nil if translate refuses to output it.
  ;; Second result is width, if known.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y)
	   (type translate translate)
	   (type (or null integer) width)
	   (type index-size size)
	   (values boolean (or null integer))))

(defun draw-glyphs (drawable gcontext x y sequence
		    &key (start 0) end translate width (size :default))
  ;; First result is new start, if end was not reached.  Second result is
  ;; overall width, if known.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type sequence sequence)
	   (type (or null integer) end width)
	   (type translate translate)
	   (type index-size size)
	   (values (or null integer) (or null integer))))

(defun draw-image-glyph (drawable gcontext x y elt
			 &key translate width (size :default))
  ;; Returns true if elt is output, nil if translate refuses to output it.
  ;; Second result is overall width, if known.  An initial font change is
  ;; allowed from translate.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y)
	   (type translate translate)
	   (type (or null integer) width)
	   (type index-size size)
	   (values boolean (or null integer))))

(defun draw-image-glyphs (drawable gcontext x y sequence
			  &key (start 0) end width translate (size :default))
  ;; An initial font change is allowed from translate, but any subsequent font
  ;; change or horizontal motion will cause termination (because the protocol
  ;; doesn't support chaining).  [Alternatively, font changes could be accepted
  ;; as long as they are accompanied with a width return value, or always
  ;; accept font changes and call text-width as required.  However, horizontal
  ;; motion can't really be accepted, due to semantics.]  First result is new
  ;; start, if end was not reached.  Second result is overall width, if known.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type sequence sequence)
	   (type (or null integer) end width)
	   (type translate translate)
	   (type index-size size)
	   (values (or null integer) (or null integer))))

∂25-Jun-87  1255	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jun 87  08:12:55 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 25 Jun 87 11:09-EDT
Date: Thu, 25 Jun 87 11:10 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: RWK@YUKON.SCRC.Symbolics.COM
cc: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870624153416.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870625111051.5.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Wed, 24 Jun 87 15:34 EDT
    From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>

	    ;;; Actually, this type is implementation dependent.
	    ;;; NIL means to use a global default that makes sense for
	    ;;; this implementation.
	What is the scope of an "implementation"?  Are there assumptions about
	character sets and fonts used?

    I'm not sure what you're asking.  I didn't know implementations had scopes.
    Assumptions character sets and fonts used by whom?  Where?  Huh?

I was really just trying to figure out whether the default global
context had to have knowledge of "non-standard" character features of
the local CL implementation (e.g., si:char-style), and whether it also
had to have knowledge of the font encodings.  That is, is it written as
part of CLX, or is it written for each (CL, CLX) pair, or can it
actually be written at all.  Anyway, I think I get the picture.

	    ;;; Perhaps, instead, this should get merged in with a
	    ;;; higher-level view of a gcontext?
	Actually adding a component to the CLX-level gcontext might be
	reasonable.
    Well, how does the higher level get its hands on it.  If this
    CONTEXT is a stream, then both how did this higher level get
    its hands on the GCONTEXT, and how did the GCONTEXT get its
    hands on the STREAM, which came from yet a higher level?

    I'm not sure I understand the modularity of GCONTEXT's.

Mostly I'm trying to figure out how to make your mini-level "go away"
(see below), but provide necessary capability in CLX.

    My intent was that the context is used to derive the translation
    function.

    (defun get-output-translation-function (context)
      (declare (type context context)
	       (values output-translation-function)))

So what I had in mind was, if you think of a context as something like a
stream, then the stream will likely contain a gcontext to get its work
done, and the stream can itself compute the translation function and
either store it in the gcontext whenever it needs to change, or bind it
using with-gcontext.  You can then argue about what translation function
to store when a gcontext is initially created, if one isn't specified.

If this is the essential operation on a context for output, then I don't
see why (at the CLX layer) passing in a context is any better than
passing in a translation function.

    ;;; We forgot about translation on input!  This can safely be
    ;;; a character-at-a-time unbuffered.

I've been intentionally ignoring this for now, both to avoid confusion
and while awaiting beta release so that people could see the KEYSYM
stuff.  The input side isn't the inverse of output (it doesn't convert a
font+index into a character), it needs to convert a KEYSYM+bits+???
into a character.

	If translate-string is an example of a context, 
    Close enough to make the rest of your comment relevant...
							then I don't see why
	text-display-extents and the other functions you listed care what the
	type of the string argument is; presumably it is simply up to the caller
	(of text-display-extents) to provide an argument that matches the type
	expected for the second argument to transform.  It doesn't even need to
	be vector, much less have a particular element-type.

    This is true.  It makes it harder to specify in this
    specification-language, though.  Do you think this is
    worth including explicitly as part of the specification
    for this layer?

I don't think it is any harder to specify.  Let me try by giving a
variation on your proposal that incorporates a number of changes:  it
isn't restricted to strings; it does not have contexts, just translation
functions; it eliminates the call-backs within the translator, and
eliminates the buffer limit; it allows delta-x motion by the translator;
it tries to sort out some problems with 8-bit vs. 16-bit indexing; it
allows the translator to convey width information for request chaining;
it raises various questions.


;; I would write a deftype, but it's easier to have argument names:

(defun translate-skeleton (src src-start src-end font dst dst-start)
  ;; dst is guaranteed to have room for (- src-end src-start) integer elements,
  ;; starting at dst-start; whether dst holds 8-bit or 16-bit elements depends
  ;; on context.  font is the current font, if known.  The function should
  ;; translate as many elements of src as possible into indexes in the current
  ;; font, and store them into dst.  The first return value should be the src
  ;; index of the first untranslated element.  If no further elements need to
  ;; be translated, the second return value should be nil.  If a horizontal
  ;; motion is required before further translation, the second return value
  ;; should be the delta in x coordinate.  If a font change is required for
  ;; further translation, the second return value should be the new font.  If
  ;; known, the pixel width of the translated text can be returned as the third
  ;; value; this can allow for appending of subsequent output to the same
  ;; protocol request, if no overall width has been specified at the higher
  ;; level.
  (declare (type sequence src)
	   (type integer src-start src-end dst-start)
	   (type (or null font) font)
	   (type vector dst)
	   (values integer (or null integer font) (or null integer))))

;; There is a question below of whether translate should always be required, or
;; if not, what the default should be or where it should come from.  For
;; example, the default could be something that expected a string as src and
;; translated the CL standard character set to ASCII indexes, and ignored fonts
;; and bits.  Or the default could expect a string but otherwise be "system
;; dependent".  Or the default could be something that expected a vector of
;; integers and did no translation.  Or the default could come from the
;; gcontext (but what about text-extents and text-width?).

(defun text-extents (sequence &key (start 0) end font translate)
  ;; If multiple fonts are involved, font-ascent and font-descent will be the
  ;; maximums.  If multiple directions are involved, the direction will be nil.
  ;; Translate will always be called with a 16-bit dst buffer.
  (declare (type sequence sequence)
	   (type (or null font gcontext) font)
	   (type translate translate)
	   (values width ascent descent left right font-ascent font-descent direction
		   (or null integer))))

(defun text-width (sequence &key (start 0) end font translate)
  ;; Translate will always be called with a 16-bit dst buffer.
  (declare (type sequence sequence)
	   (type (or null font gcontext) font)
	   (type translate translate)
	   (values integer (or null integer))))

;; This controls the element size of the dst buffer given to translate.  If
;; :default is specified, the size will be based on the current font, if known,
;; and otherwise 16 will be used.  [An alternative would be to pass the buffer
;; size to translate, and allow it to return the desired size if it doesn't
;; like the current size.  The problem is that the protocol doesn't allow
;; switching within a single request, so to allow switching would require
;; knowing the width of text, which isn't necessarily known.  We could call
;; text-width to compute it, but perhaps that is doing too many favors?]  [An
;; additional possibility is to allow an index-size of :two-byte, in which case
;; translate would be given a double-length 8-bit array, and translate would be
;; expected to store first-byte/second-byte instead of 16-bit integers.]

(deftype index-size () '(member :default 8 16))

;; In the functions below, if width is specified, it is assumed to be the total
;; pixel width of whatever string of glyphs is actually drawn.  Specifying
;; width will allow for appending the output of subsequent calls to the same
;; protocol request, provided gcontext has not been modified in the interim.
;; If width is not specified, appending of subsequent output might not occur
;; (unless translate returns the width).  Specifying width is simply a hint,
;; for performance.

(defun draw-glyph (drawable gcontext x y elt
		   &key translate width (size :default))
  ;; Returns true if elt is output, nil if translate refuses to output it.
  ;; Second result is width, if known.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y)
	   (type translate translate)
	   (type (or null integer) width)
	   (type index-size size)
	   (values boolean (or null integer))))

(defun draw-glyphs (drawable gcontext x y sequence
		    &key (start 0) end translate width (size :default))
  ;; First result is new start, if end was not reached.  Second result is
  ;; overall width, if known.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type sequence sequence)
	   (type (or null integer) end width)
	   (type translate translate)
	   (type index-size size)
	   (values (or null integer) (or null integer))))

(defun draw-image-glyph (drawable gcontext x y elt
			 &key translate width (size :default))
  ;; Returns true if elt is output, nil if translate refuses to output it.
  ;; Second result is overall width, if known.  An initial font change is
  ;; allowed from translate.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y)
	   (type translate translate)
	   (type (or null integer) width)
	   (type index-size size)
	   (values boolean (or null integer))))

(defun draw-image-glyphs (drawable gcontext x y sequence
			  &key (start 0) end width translate (size :default))
  ;; An initial font change is allowed from translate, but any subsequent font
  ;; change or horizontal motion will cause termination (because the protocol
  ;; doesn't support chaining).  [Alternatively, font changes could be accepted
  ;; as long as they are accompanied with a width return value, or always
  ;; accept font changes and call text-width as required.  However, horizontal
  ;; motion can't really be accepted, due to semantics.]  First result is new
  ;; start, if end was not reached.  Second result is overall width, if known.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type sequence sequence)
	   (type (or null integer) end width)
	   (type translate translate)
	   (type index-size size)
	   (values (or null integer) (or null integer))))

∂25-Jun-87  1309	CS.WERTH@R20.UTEXAS.EDU 	Re: more concrete font proposal    
Received: from R20.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 25 Jun 87  13:08:50 PDT
Date: Thu 25 Jun 87 15:06:50-CDT
From: CS.WERTH@R20.UTEXAS.EDU
Subject: Re: more concrete font proposal
To: RWK@SCRC-YUKON.ARPA
cc: sas@BFLY-VAX.BBN.COM, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870619063826.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <12313385522.18.CS.WERTH@R20.UTEXAS.EDU>

I also plan to attend the Evening Grants Meeting.

J Werth
-------

∂25-Jun-87  1357	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: CLX beta changes   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87  13:56:39 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa06017; 25 Jun 87 14:25 EDT
Received: from ti-csl by RELAY.CS.NET id aa20741; 25 Jun 87 14:16 EDT
Received: by tilde id AA11291; Thu, 25 Jun 87 12:52:54 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 25 Jun 87  12:54:45 CDT
Message-Id: <2760630731-15842445@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Thu, 25 Jun 87  12:52:11 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX beta changes
In-Reply-To: Msg of Wed, 24 Jun 87 13:44 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>


	>(defun set-modifier-mapping (display &key shift lock control
	>				mod1 mod2 mod3 mod4 mod5)

	>;; Should this signal device-busy like the pointer-mapping
	>;; setf, and return a boolean instead (true for
	>;; success)?

Yes, I think this alternative strikes the right balance between
consistency and aptness of interface.



	>(defun modifier-mapping (display)
	>;; each value is either nil, a single integer, or a list of two integers
	>	(declare (type display display)
	>	(values shift lock control mod1 mod2 mod3 mod4 mod5)))

What's the interpretation of assigning a modifier two keycodes?




	>;; Either we will want lots of defconstants for well-known values, or perhaps
	>;; an integer-to-keyword translation function for well-known values.
	>
	>(deftype keysym () 'integer)

I'd vote for defconstants and/or a pair of keyword-to-keysym/keysym-to-keyword
translation functions.  These would be used for setting/inquiring the keyboard
mapping.

It seems that clients have a vital interest in using and maintaining the current
KEYCODE-to-keysym mapping.  To ignore this is not only non-portable (the mapping
is a client's only clue to the significance of the keycodes received from a
remote display), but also may result in a total breakdown of the client's user
interface.  Should not CLX therefore provide more support in this area?
Hopefully, this could be a simple "wheel" that no one would then have to
reinvent. Something like:

(defun keycode-symbol (display keycode modifier-state)
  ;; Return the keycap symbol currently assigned to a display's keycode,
  ;; for the given modifier state.
  ;; Creates (if necessary) and uses a local copy of the keyboard mapping

  (declare (type display display)
	   (type integer keycode)

	   ;; Should return keyword if keysym defconstants are not provided
	   (values keysym-or-keyword)))

(defun handle-mapping-notify (&rest keywords)
  ;; Default event handler for MappingNotify events. Creates (if necessary)
  ;; and updates local keyboard/modifier mappings used to implement
  ;; keycode-symbol
  )

[PS: Isn't it correct that the server directly uses the pointer mapping,
returning only "mapped" button codes?  Likewise, does the server directly use
the modifier mappings, returning modifier state in events accordingly?  If
"yes", then what is a client supposed to do with a MappingNotify event when
(member request (:pointer :modifier))?  If "no", then facilities similar to
above would be needed to allow clients to track these mappings.]

[PPS: What about the relationship between keysyms and font indices?  That is,
the information needed simply (but portably!) to echo keyboard input.  Now that
the keysym registry is available, shouldn't X require fonts to allow clients to
inquire this relationship?]



	>(defun change-keyboard-mapping (display keysyms &key (start1 0) end1 (start2 start1))
	>;; start1/end1 give subrange of keysyms
	>;; start2 is the first-keycode to store at
	>;; are there better argument names?

How about start-from, end-from, and start-to?  By the way, can't keysyms be a
sequence of n-element sequences.  Can't n be > 2?




∂25-Jun-87  1438	CS.WERTH@R20.UTEXAS.EDU 	Re: more concrete font proposal    
Received: from R20.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 25 Jun 87  13:08:50 PDT
Date: Thu 25 Jun 87 15:06:50-CDT
From: CS.WERTH@R20.UTEXAS.EDU
Subject: Re: more concrete font proposal
To: RWK@SCRC-YUKON.ARPA
cc: sas@BFLY-VAX.BBN.COM, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870619063826.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <12313385522.18.CS.WERTH@R20.UTEXAS.EDU>

I also plan to attend the Evening Grants Meeting.

J Werth
-------

∂25-Jun-87  1505	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: more concrete font proposal    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jun 87  08:12:55 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 25 Jun 87 11:09-EDT
Date: Thu, 25 Jun 87 11:10 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: RWK@YUKON.SCRC.Symbolics.COM
cc: Oren%Tilde%ti-csl.csnet@RELAY.CS.NET, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870624153416.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870625111051.5.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Wed, 24 Jun 87 15:34 EDT
    From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>

	    ;;; Actually, this type is implementation dependent.
	    ;;; NIL means to use a global default that makes sense for
	    ;;; this implementation.
	What is the scope of an "implementation"?  Are there assumptions about
	character sets and fonts used?

    I'm not sure what you're asking.  I didn't know implementations had scopes.
    Assumptions character sets and fonts used by whom?  Where?  Huh?

I was really just trying to figure out whether the default global
context had to have knowledge of "non-standard" character features of
the local CL implementation (e.g., si:char-style), and whether it also
had to have knowledge of the font encodings.  That is, is it written as
part of CLX, or is it written for each (CL, CLX) pair, or can it
actually be written at all.  Anyway, I think I get the picture.

	    ;;; Perhaps, instead, this should get merged in with a
	    ;;; higher-level view of a gcontext?
	Actually adding a component to the CLX-level gcontext might be
	reasonable.
    Well, how does the higher level get its hands on it.  If this
    CONTEXT is a stream, then both how did this higher level get
    its hands on the GCONTEXT, and how did the GCONTEXT get its
    hands on the STREAM, which came from yet a higher level?

    I'm not sure I understand the modularity of GCONTEXT's.

Mostly I'm trying to figure out how to make your mini-level "go away"
(see below), but provide necessary capability in CLX.

    My intent was that the context is used to derive the translation
    function.

    (defun get-output-translation-function (context)
      (declare (type context context)
	       (values output-translation-function)))

So what I had in mind was, if you think of a context as something like a
stream, then the stream will likely contain a gcontext to get its work
done, and the stream can itself compute the translation function and
either store it in the gcontext whenever it needs to change, or bind it
using with-gcontext.  You can then argue about what translation function
to store when a gcontext is initially created, if one isn't specified.

If this is the essential operation on a context for output, then I don't
see why (at the CLX layer) passing in a context is any better than
passing in a translation function.

    ;;; We forgot about translation on input!  This can safely be
    ;;; a character-at-a-time unbuffered.

I've been intentionally ignoring this for now, both to avoid confusion
and while awaiting beta release so that people could see the KEYSYM
stuff.  The input side isn't the inverse of output (it doesn't convert a
font+index into a character), it needs to convert a KEYSYM+bits+???
into a character.

	If translate-string is an example of a context, 
    Close enough to make the rest of your comment relevant...
							then I don't see why
	text-display-extents and the other functions you listed care what the
	type of the string argument is; presumably it is simply up to the caller
	(of text-display-extents) to provide an argument that matches the type
	expected for the second argument to transform.  It doesn't even need to
	be vector, much less have a particular element-type.

    This is true.  It makes it harder to specify in this
    specification-language, though.  Do you think this is
    worth including explicitly as part of the specification
    for this layer?

I don't think it is any harder to specify.  Let me try by giving a
variation on your proposal that incorporates a number of changes:  it
isn't restricted to strings; it does not have contexts, just translation
functions; it eliminates the call-backs within the translator, and
eliminates the buffer limit; it allows delta-x motion by the translator;
it tries to sort out some problems with 8-bit vs. 16-bit indexing; it
allows the translator to convey width information for request chaining;
it raises various questions.


;; I would write a deftype, but it's easier to have argument names:

(defun translate-skeleton (src src-start src-end font dst dst-start)
  ;; dst is guaranteed to have room for (- src-end src-start) integer elements,
  ;; starting at dst-start; whether dst holds 8-bit or 16-bit elements depends
  ;; on context.  font is the current font, if known.  The function should
  ;; translate as many elements of src as possible into indexes in the current
  ;; font, and store them into dst.  The first return value should be the src
  ;; index of the first untranslated element.  If no further elements need to
  ;; be translated, the second return value should be nil.  If a horizontal
  ;; motion is required before further translation, the second return value
  ;; should be the delta in x coordinate.  If a font change is required for
  ;; further translation, the second return value should be the new font.  If
  ;; known, the pixel width of the translated text can be returned as the third
  ;; value; this can allow for appending of subsequent output to the same
  ;; protocol request, if no overall width has been specified at the higher
  ;; level.
  (declare (type sequence src)
	   (type integer src-start src-end dst-start)
	   (type (or null font) font)
	   (type vector dst)
	   (values integer (or null integer font) (or null integer))))

;; There is a question below of whether translate should always be required, or
;; if not, what the default should be or where it should come from.  For
;; example, the default could be something that expected a string as src and
;; translated the CL standard character set to ASCII indexes, and ignored fonts
;; and bits.  Or the default could expect a string but otherwise be "system
;; dependent".  Or the default could be something that expected a vector of
;; integers and did no translation.  Or the default could come from the
;; gcontext (but what about text-extents and text-width?).

(defun text-extents (sequence &key (start 0) end font translate)
  ;; If multiple fonts are involved, font-ascent and font-descent will be the
  ;; maximums.  If multiple directions are involved, the direction will be nil.
  ;; Translate will always be called with a 16-bit dst buffer.
  (declare (type sequence sequence)
	   (type (or null font gcontext) font)
	   (type translate translate)
	   (values width ascent descent left right font-ascent font-descent direction
		   (or null integer))))

(defun text-width (sequence &key (start 0) end font translate)
  ;; Translate will always be called with a 16-bit dst buffer.
  (declare (type sequence sequence)
	   (type (or null font gcontext) font)
	   (type translate translate)
	   (values integer (or null integer))))

;; This controls the element size of the dst buffer given to translate.  If
;; :default is specified, the size will be based on the current font, if known,
;; and otherwise 16 will be used.  [An alternative would be to pass the buffer
;; size to translate, and allow it to return the desired size if it doesn't
;; like the current size.  The problem is that the protocol doesn't allow
;; switching within a single request, so to allow switching would require
;; knowing the width of text, which isn't necessarily known.  We could call
;; text-width to compute it, but perhaps that is doing too many favors?]  [An
;; additional possibility is to allow an index-size of :two-byte, in which case
;; translate would be given a double-length 8-bit array, and translate would be
;; expected to store first-byte/second-byte instead of 16-bit integers.]

(deftype index-size () '(member :default 8 16))

;; In the functions below, if width is specified, it is assumed to be the total
;; pixel width of whatever string of glyphs is actually drawn.  Specifying
;; width will allow for appending the output of subsequent calls to the same
;; protocol request, provided gcontext has not been modified in the interim.
;; If width is not specified, appending of subsequent output might not occur
;; (unless translate returns the width).  Specifying width is simply a hint,
;; for performance.

(defun draw-glyph (drawable gcontext x y elt
		   &key translate width (size :default))
  ;; Returns true if elt is output, nil if translate refuses to output it.
  ;; Second result is width, if known.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y)
	   (type translate translate)
	   (type (or null integer) width)
	   (type index-size size)
	   (values boolean (or null integer))))

(defun draw-glyphs (drawable gcontext x y sequence
		    &key (start 0) end translate width (size :default))
  ;; First result is new start, if end was not reached.  Second result is
  ;; overall width, if known.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type sequence sequence)
	   (type (or null integer) end width)
	   (type translate translate)
	   (type index-size size)
	   (values (or null integer) (or null integer))))

(defun draw-image-glyph (drawable gcontext x y elt
			 &key translate width (size :default))
  ;; Returns true if elt is output, nil if translate refuses to output it.
  ;; Second result is overall width, if known.  An initial font change is
  ;; allowed from translate.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y)
	   (type translate translate)
	   (type (or null integer) width)
	   (type index-size size)
	   (values boolean (or null integer))))

(defun draw-image-glyphs (drawable gcontext x y sequence
			  &key (start 0) end width translate (size :default))
  ;; An initial font change is allowed from translate, but any subsequent font
  ;; change or horizontal motion will cause termination (because the protocol
  ;; doesn't support chaining).  [Alternatively, font changes could be accepted
  ;; as long as they are accompanied with a width return value, or always
  ;; accept font changes and call text-width as required.  However, horizontal
  ;; motion can't really be accepted, due to semantics.]  First result is new
  ;; start, if end was not reached.  Second result is overall width, if known.
  (declare (type drawable drawable)
	   (type gcontext gcontext)
	   (type integer x y start)
	   (type sequence sequence)
	   (type (or null integer) end width)
	   (type translate translate)
	   (type index-size size)
	   (values (or null integer) (or null integer))))

∂25-Jun-87  1438	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: CLX beta changes   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87  13:56:39 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa06017; 25 Jun 87 14:25 EDT
Received: from ti-csl by RELAY.CS.NET id aa20741; 25 Jun 87 14:16 EDT
Received: by tilde id AA11291; Thu, 25 Jun 87 12:52:54 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 25 Jun 87  12:54:45 CDT
Message-Id: <2760630731-15842445@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Thu, 25 Jun 87  12:52:11 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX beta changes
In-Reply-To: Msg of Wed, 24 Jun 87 13:44 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>


	>(defun set-modifier-mapping (display &key shift lock control
	>				mod1 mod2 mod3 mod4 mod5)

	>;; Should this signal device-busy like the pointer-mapping
	>;; setf, and return a boolean instead (true for
	>;; success)?

Yes, I think this alternative strikes the right balance between
consistency and aptness of interface.



	>(defun modifier-mapping (display)
	>;; each value is either nil, a single integer, or a list of two integers
	>	(declare (type display display)
	>	(values shift lock control mod1 mod2 mod3 mod4 mod5)))

What's the interpretation of assigning a modifier two keycodes?




	>;; Either we will want lots of defconstants for well-known values, or perhaps
	>;; an integer-to-keyword translation function for well-known values.
	>
	>(deftype keysym () 'integer)

I'd vote for defconstants and/or a pair of keyword-to-keysym/keysym-to-keyword
translation functions.  These would be used for setting/inquiring the keyboard
mapping.

It seems that clients have a vital interest in using and maintaining the current
KEYCODE-to-keysym mapping.  To ignore this is not only non-portable (the mapping
is a client's only clue to the significance of the keycodes received from a
remote display), but also may result in a total breakdown of the client's user
interface.  Should not CLX therefore provide more support in this area?
Hopefully, this could be a simple "wheel" that no one would then have to
reinvent. Something like:

(defun keycode-symbol (display keycode modifier-state)
  ;; Return the keycap symbol currently assigned to a display's keycode,
  ;; for the given modifier state.
  ;; Creates (if necessary) and uses a local copy of the keyboard mapping

  (declare (type display display)
	   (type integer keycode)

	   ;; Should return keyword if keysym defconstants are not provided
	   (values keysym-or-keyword)))

(defun handle-mapping-notify (&rest keywords)
  ;; Default event handler for MappingNotify events. Creates (if necessary)
  ;; and updates local keyboard/modifier mappings used to implement
  ;; keycode-symbol
  )

[PS: Isn't it correct that the server directly uses the pointer mapping,
returning only "mapped" button codes?  Likewise, does the server directly use
the modifier mappings, returning modifier state in events accordingly?  If
"yes", then what is a client supposed to do with a MappingNotify event when
(member request (:pointer :modifier))?  If "no", then facilities similar to
above would be needed to allow clients to track these mappings.]

[PPS: What about the relationship between keysyms and font indices?  That is,
the information needed simply (but portably!) to echo keyboard input.  Now that
the keysym registry is available, shouldn't X require fonts to allow clients to
inquire this relationship?]



	>(defun change-keyboard-mapping (display keysyms &key (start1 0) end1 (start2 start1))
	>;; start1/end1 give subrange of keysyms
	>;; start2 is the first-keycode to store at
	>;; are there better argument names?

How about start-from, end-from, and start-to?  By the way, can't keysyms be a
sequence of n-element sequences.  Can't n be > 2?




∂28-Jun-87  1456	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: CLX beta changes
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Jun 87  14:56:41 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 28 Jun 87 17:54-EDT
Date: Sun, 28 Jun 87 17:56 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: CLX beta changes
To: Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2760630731-15842445@Sierra>
Message-ID: <870628175604.2.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Thu, 25 Jun 87  12:52:11 CDT
    From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>

	    >(defun modifier-mapping (display)
	    >;; each value is either nil, a single integer, or a list of two integers
	    >	(declare (type display display)
	    >	(values shift lock control mod1 mod2 mod3 mod4 mod5)))

    What's the interpretation of assigning a modifier two keycodes?

The modifier reflects the OR of the two keys (e.g., most keyboards have
both left and right shift keys; if either is down, the Shift bit is
set).

    (defun keycode-symbol (display keycode modifier-state)
      ;; Return the keycap symbol currently assigned to a display's keycode,
      ;; for the given modifier state.
      ;; Creates (if necessary) and uses a local copy of the keyboard mapping

      (declare (type display display)
	       (type integer keycode)

	       ;; Should return keyword if keysym defconstants are not provided
	       (values keysym-or-keyword)))

This can interpret the Shift and Lock modifier bits, since the protocol
suggests the way this should be done.  If that is all you intended,
fine.  If you also hoped it would interpret Control and the Mod1-5
modifiers, then we have a problem.

    [PPS: What about the relationship between keysyms and font indices?  That is,
    the information needed simply (but portably!) to echo keyboard input.  Now that
    the keysym registry is available, shouldn't X require fonts to allow clients to
    inquire this relationship?]

I suspect what many applications will want is not your keycode-symbol
function, but rather something that translates keycode+modifiers to a
character object, given a current "context" (as RWK called it).  The
relationship to font indices is determined by the corresponding output
translation.  What kind of default CLX itself provides is probably
closely coupled with your answer for output.  For example, if you
believe CLX should provide something for output that translates the CL
standard character set to ASCII indexes, ignoring fonts and bits, then
it should probably also provide something for input that translates
Latin-1 keysyms to the CL standard character set, probably ignoring
Control and Mod1-5.

It probably is desirable to have a set of fonts that index-match the
least significant byte of the standard keysyms.  It probably is also
desirable for fonts to have some indication of which character
(sub)set(s) they match.  If such things can be agreed upon by the X
community as a whole, then generic translation functions can be defined
that will work most of the time.

    [PS: Isn't it correct that the server directly uses the pointer mapping,
    returning only "mapped" button codes?  Likewise, does the server directly use
    the modifier mappings, returning modifier state in events accordingly?

Yes.
									     If
    "yes", then what is a client supposed to do with a MappingNotify event when
    (member request (:pointer :modifier))?

Most likely you ignore :pointer change.  Whether or not to ignore
:modifier depends on how you interpret Lock and the Mod1-5 bits.  Most
likely you want to know whether Lock has changed from Capslock to
Shiftlock.  For the Mod1-5 bits, there are two philosophies.  One is
that you read their actual keysyms and interpret on that basis (viz.,
what you really care about is whether Meta and Hyper are down, not what
modifier bit they happen to be mapped to).  The other is that you assign
semantic interpretation to "Mod1" independent of what keysym happens to
be engraved on it.  There are arguments on both sides about which
philosophy leads to the more portable and/or easier to document user
interface.

						   By the way, can't keysyms be a
    sequence of n-element sequences.  Can't n be > 2?

Silly me, (array keysym 2) should be (array keysym (* *)) in both
change-keyboard-mapping and keyboard-mapping.  As in the protocol,
"unused" entries are zeroed.  This seemed to me a bit easier to deal
with both in CLX and the application than (vector (vector keysym)), but
I'm willing to be convinced otherwise.

∂29-Jun-87  0702	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: type confusion  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jun 87  07:02:45 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jun 87 10:01-EDT
Date: Mon, 29 Jun 87 10:02 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: type confusion
To: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870628175604.2.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870629100249.4.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Sun, 28 Jun 87 17:56 EDT
    From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>

    Silly me, (array keysym 2) should be (array keysym (* *)) in both
    change-keyboard-mapping and keyboard-mapping.  As in the protocol,
    "unused" entries are zeroed.  This seemed to me a bit easier to deal
    with both in CLX and the application than (vector (vector keysym)), but
    I'm willing to be convinced otherwise.

RWK has correctly pointed out to me that, due to the interesting
"features" of the CL type system, (array keysym (* *)) probably doesn't
convey what is desired, namely "a two-dimensional array that *currently*
contains keysyms", rather than "a two-dimensional array that can *only*
contain keysyms".  So, although (array keysym (* *)) might be reasonable
as the return type for keyboard-mapping, (array * (* *)) is probably the
correct argument type for change-keyboard-mapping.

∂29-Jun-87  1040	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	with-gcontext question   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jun 87  10:38:30 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jun 87 13:36-EDT
Date: Mon, 29 Jun 87 13:38 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: with-gcontext question
To: Oren%Home%ti-csl.csnet@RELAY.CS.NET
cc: clx@ZERMATT.LCS.MIT.EDU, cl-windows@sail.stanford.edu
In-Reply-To: <2760964923-3321382@SI>
Message-ID: <870629133814.7.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Mon, 29 Jun 87  09:42:03 CDT
    From: LaMott Oren <Oren%Home%ti-csl.csnet@RELAY.CS.NET>

		    Do you view WITH-GCONTEXT as binding fields within a GC,
    or as binding the whole GC?

Very definitely as binding individual components.  I had thought this
was clear, but apparently not.  I suppose we could rename it to
with-gcontext-components, to mirror copy-gcontext-components (as
distinct from copy-gcontext), if people think that would help, although
it's a pretty long name.

				 For example, is

    (with-gcontext (gc :font foo)
      (setf (gcontext-tile gc) pixmap)
      ...)

    The same as:

    (with-gcontext (gc)
      (setf (gcontext-font gc) foo)
      (setf (gcontext-tile gc) pixmap)
      ...)

No.  In fact, the with-gcontext in the second example is a no-op.  It
isn't clear to me that a form to bind all components (to their existing
values) is all that useful; that would be sort of like a LET that bound
all extant variables, wouldn't it?

    Its my understanding that if the font in GC is unknown (the default)
    then with-gcontext creates a temporary copy of GC, then sets the new
    font in the copy.  When exiting the with-gcontext, the temporary GC is
    deleted.  How would this be handled for the second case?  Can any
    gcontext setf cause a transition from modified to copied gcontext?

At the beginning of the with-gcontext you need to snapshot a copy of all
components listed as arguments to the form.  If you don't know the
current value of some components, you create (or reuse) a temporary GC
and copy over all listed components for which you don't know the value.
You then do setfs to the new values listed as arguments.  These setfs,
like setfs within the body, modify the original GC, not the partial
copy.  On exit, you copy back (only) those components you saved.

    If these two examples are not equivalent, then does setting the tile in
    the example effectively change the tile in two GC's (the original
    and the temporary copy)?

No.  A gcontext setf never affects the (invisible) copy.

∂29-Jun-87  1122	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: CLX beta changes   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 29 Jun 87  11:22:33 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac26006; 29 Jun 87 13:06 EDT
Received: from ti-csl by RELAY.CS.NET id ae13910; 29 Jun 87 13:02 EDT
Received: by tilde id AA07357; Mon, 29 Jun 87 11:12:14 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 29 Jun 87  11:14:37 CDT
Message-Id: <2760970211-3208787@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Mon, 29 Jun 87  11:10:11 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX beta changes
In-Reply-To: Msg of Sun, 28 Jun 87 17:56 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>

	>I suspect what many applications will want is not your
	>keycode-symbol function, but rather something that translates
	>keycode+modifiers to a character object, given a current
	>"context" (as RWK called it).  The relationship to font indices
	>is determined by the corresponding output translation.  What
	>kind of default CLX itself provides is probably closely coupled
	>with your answer for output.  For example, if you believe CLX
	>should provide something for output that translates the CL
	>standard character set to ASCII indexes, ignoring fonts and
	>bits, then it should probably also provide something for input
	>that translates Latin-1 keysyms to the CL standard character
	>set, probably ignoring Control and Mod1-5.

Agreed. Here's my vote for including these CLX defaults for text
output/input translation. What do you think of also including in CLX a
mechanism for "automatically" tracking the display's current keyboard
mapping in order to maintain the input translation?


	>It probably is desirable to have a set of fonts that
	>index-match the least significant byte of the standard keysyms.
	>It probably is also desirable for fonts to have some indication
	>of which character (sub)set(s) they match.  If such things can
	>be agreed upon by the X community as a whole, then generic
	>translation functions can be defined that will work most of the
	>time.

Are such proposals already in the works? What do you think is the best
way to integrate this capability into the X protocol? Standard
extension request? New required fontprops (e.g. Latin1StartIndex)?

∂29-Jun-87  1149	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: CLX beta changes
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jun 87  11:49:33 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jun 87 14:47-EDT
Date: Mon, 29 Jun 87 14:49 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: CLX beta changes
To: Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2760970211-3208787@Sierra>
Message-ID: <870629144912.1.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Mon, 29 Jun 87  11:10:11 CDT
    From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>

    Agreed. Here's my vote for including these CLX defaults for text
    output/input translation. What do you think of also including in CLX a
    mechanism for "automatically" tracking the display's current keyboard
    mapping in order to maintain the input translation?

My feeling is that we need to stop designing soon and start
experimenting.  Hopefully an initial implementation of most of CLX will
be available within a very few weeks, and people can really start
playing and building some things.  I would like see an "essential"
interface put in place, such that people can start building on it.
Whether some of the things that get built eventually get viewed as part
of CLX or part of a higher-level layer doesn't seem important to me
right now.  To me, the existence and exact functionality of "default"
character i/o translators is something that needs to be worked on, but
shouldn't hold up the show, which is one reason I want text output done
in terms of functional arguments.  The basic stuff needed for input is
even easier; the existence of input translators is necessary, but are
essentially "convenience" routines that can be provided "on top" without
any basic change to the underlying interface (or at least that seems
plausible).

	    >It probably is desirable to have a set of fonts that
	    >index-match the least significant byte of the standard keysyms.
	    >It probably is also desirable for fonts to have some indication
	    >of which character (sub)set(s) they match.  If such things can
	    >be agreed upon by the X community as a whole, then generic
	    >translation functions can be defined that will work most of the
	    >time.

    Are such proposals already in the works? What do you think is the best
    way to integrate this capability into the X protocol? Standard
    extension request? New required fontprops (e.g. Latin1StartIndex)?

As I think I said in an earlier message, a number of people are very
concerned about this issue, and will be attempting to do something about
it.  There are tentative ideas floating around, but no firm proposals
yet.  Anyone interested in (seriously) contributing to the effort is
welcome.  I don't believe at this point that any changes to the protocol
are required.  I think some "layered" standards in terms of font naming
and font properties can go a long way.

∂29-Jun-87  1201	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: draw-image-glyph(s)  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jun 87  12:00:35 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jun 87 14:58-EDT
Date: Mon, 29 Jun 87 15:00 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: draw-image-glyph(s)
To: Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@sail.stanford.edu
In-Reply-To: <2760972786-3363493@Sierra>
Message-ID: <870629150002.2.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Mon, 29 Jun 87  11:53:06 CDT
    From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>

	    (defun draw-image-glyph (drawable gcontext x y elt
			     &key translate width (size :default)))

	    (defun draw-image-glyphs (drawable gcontext x y sequence
			      &key (start 0) end width translate (size :default)))

    Do these functions modify the given gcontext (i.e. change its font) or
    do they make gcontext copies?

    Is it your intention that the implementation of these functions is free
    to choose how far it wants to go in handling font changes?

I want there to be a precise semantics, but I'm not sure exactly what
the best semantics is, given that the underlying protocol requests don't
allow font changes.  I would expect that at least an initial font change
would be allowed, and that it would indeed side-effect the gcontext, not
create a copy.  Whether further font changes are allowed depends on
whether you allow this routine to make text-width calls internally in
order to generate the successive protocol requests.  The question of
horizontal motion is even stickier, since it isn't clear whether the
"white space" should be left unchanged or should be filled with the
background like the rest of the extent.  The combination of these would
lead me to say that only an initial font change should be allowed, but I
welcome suggestions.

∂29-Jun-87  2112	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: draw-image-glyph(s)
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 29 Jun 87  21:12:03 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa00999; 29 Jun 87 21:01 EDT
Received: from ti-csl by RELAY.CS.NET id as16127; 29 Jun 87 20:50 EDT
Received: by tilde id AA13846; Mon, 29 Jun 87 16:37:49 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 29 Jun 87  16:40:17 CDT
Message-Id: <2760989852-4388876@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Mon, 29 Jun 87  16:37:32 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: draw-image-glyph(s)
In-Reply-To: Msg of Mon, 29 Jun 87 15:00 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>


	    (defun draw-image-glyph (drawable gcontext x y elt
			     &key translate width (size :default)))

	    (defun draw-image-glyphs (drawable gcontext x y sequence
			      &key (start 0) end width translate (size :default)))


	>I want there to be a precise semantics, but I'm not sure exactly what
	>the best semantics is, given that the underlying protocol requests
	>don't allow font changes.  I would expect that at least an initial font
	>change would be allowed, and that it would indeed side-effect the
	>gcontext, not create a copy.  Whether further font changes are allowed
	>depends on whether you allow this routine to make text-width calls
	>internally in order to generate the successive protocol requests.  The
	>question of horizontal motion is even stickier, since it isn't clear
	>whether the "white space" should be left unchanged or should be filled
	>with the background like the rest of the extent.  The combination of
	>these would lead me to say that only an initial font change should be
	>allowed.

I'm inclined to agree, since it occurs to me that, in order to achieve the
intended effect of draw-image-glyph(s) in a polyfont context, the wise client
will not actually use draw-image-glyph(s) at all!  The reason: in order to be
sure the previous background is really "erased", he's going to have to blot out
a rectangle using the "current line height" (i.e.  max height over all fonts
used), in which case it will be more efficient to go ahead and use draw-glyphs.

∂30-Jun-87  1023	@RELAY.CS.NET:Oren%Home@TI-CSL.CSNET 	Re: more concrete font proposal 
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 30 Jun 87  10:23:46 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa07377; 30 Jun 87 13:06 EDT
Received: from ti-csl by RELAY.CS.NET id ab20827; 30 Jun 87 13:01 EDT
Received: by tilde id AA17405; Tue, 30 Jun 87 11:36:21 CDT
Message-Id: <2761058205-4024875@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Tue, 30 Jun 87  11:36:45 CDT
From: LaMott Oren <Oren%Home%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: more concrete font proposal
In-Reply-To: Msg of Thu, 25 Jun 87 11:10 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>

I gathered that the intent of your latest proposal is to have translate
function do the copy from a text sequence directly into the X server
request buffer. I just noticed that you have the font parameter to
text-extents and text-width typed (or null font gcontext).  If the font
is NIL there's no pointer to the display object that contains the
buffer(s).  This will require an extra copy, and a resource of
sequences.  How about making font a required parameter:

(defun text-extents (font sequence &key (start 0) end translate)
  (declare (type (or font gcontext) font)
	   (type sequence sequence)
	   (type translate translate)
	   (values width ascent descent left right font-ascent font-descent direction
		   (or null integer))))

∂30-Jun-87  1117	@RELAY.CS.NET:Oren%Home@TI-CSL.CSNET 	Re: more concrete font proposal 
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 30 Jun 87  11:16:59 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ab07473; 30 Jun 87 13:17 EDT
Received: from ti-csl by RELAY.CS.NET id ai20827; 30 Jun 87 13:12 EDT
Received: by tilde id AA15742; Tue, 30 Jun 87 10:53:59 CDT
Message-Id: <2761055643-3870990@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Tue, 30 Jun 87  10:54:03 CDT
From: LaMott Oren <Oren%Home%ti-csl.csnet@RELAY.CS.NET>
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: more concrete font proposal
In-Reply-To: Msg of Thu, 25 Jun 87 11:10 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>

In general, I like your proposal.  However, I don't understand why the
text functions need to accept SEQUENCEs.  Why aren't vectors sufficient?
I don't understand why anyone would cons up a list of characters when
its just as easy and more efficient to make a vector.

∂30-Jun-87  1431	RWS@ZERMATT.LCS.MIT.EDU 	Re: why sequences?  
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Jun 87  14:30:53 PDT
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 60885; Tue 30-Jun-87 17:29:17 EDT
Date: Tue, 30 Jun 87 17:29 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: why sequences?
To: Oren%Home%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2761055643-3870990@SI>
Message-ID: <870630172953.7.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Tue, 30 Jun 87  10:54:03 CDT
    From: LaMott Oren <Oren%Home%ti-csl.csnet@RELAY.CS.NET>

    In general, I like your proposal.  However, I don't understand why the
    text functions need to accept SEQUENCEs.  Why aren't vectors sufficient?
    I don't understand why anyone would cons up a list of characters when
    its just as easy and more efficient to make a vector.

If you think about it, the only way in which CLX itself (as opposed to
the translator passed in) needs to manipulate the sequence object is to
compute the END argument when it isn't explicitly given, i.e., it needs
to do (LENGTH sequence).  This doesn't seem an undue burden, and to me
is a desirable flexibility.  (In fact, one might be tempted to document
that if both start and end are given, then the "sequence" argument need
not even be a sequence, and if LENGTH ever becomes a generic function,
you are home free.)  The other question you can ask, "must the
'standard' translators accept sequences, or are vectors sufficient" is a
perfectly valid question, and it certainly wouldn't bother me if they
only accepted vectors.

∂30-Jun-87  1450	RWS@ZERMATT.LCS.MIT.EDU 	Re: more concrete font proposal    
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Jun 87  14:50:46 PDT
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 60888; Tue 30-Jun-87 17:39:26 EDT
Date: Tue, 30 Jun 87 17:40 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more concrete font proposal
To: Oren%Home%ti-csl.csnet@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2761058205-4024875@SI>
Message-ID: <870630174001.9.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Tue, 30 Jun 87  11:36:45 CDT
    From: LaMott Oren <Oren%Home%ti-csl.csnet@RELAY.CS.NET>

    I gathered that the intent of your latest proposal is to have translate
    function do the copy from a text sequence directly into the X server
    request buffer.

Or at least to allow that to happen.

		    I just noticed that you have the font parameter to
    text-extents and text-width typed (or null font gcontext).  If the font
    is NIL there's no pointer to the display object that contains the
    buffer(s).  This will require an extra copy, and a resource of
    sequences.  How about making font a required parameter:

    (defun text-extents (font sequence &key (start 0) end translate)
      (declare (type (or font gcontext) font)
	       (type sequence sequence)
	       (type translate translate)
	       (values width ascent descent left right font-ascent font-descent direction
		       (or null integer))))

That seems acceptable to me.  An addition might be to make it
(or display font gcontext).

∂16-Jul-87  0708	RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU 	CLX  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Jul 87  07:08:12 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 16 Jul 87 10:05-EDT
Date: Thu, 16 Jul 87 10:06 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX
To: edsel!vesuvius!liz@navajo.stanford.edu
cc: xbeta-sites@ATHENA.MIT.EDU, cl-windows@sail.stanford.edu
In-Reply-To: <8707141656.AA09865@vesuvius.edsel.uucp>
Message-ID: <870716100615.8.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Tue, 14 Jul 87 09:56:12 PDT
    From: edsel!vesuvius!liz@navajo.stanford.edu (Liz Heller)

    Do you know when a public domain CLX implementation will be
    available?

An implementation will be available very soon now for limited alpha
testing.  There was a delay while waiting for the Sun server port to get
fixed, so that some basic testing could get done.  Anyone interested in
alpha testing the code should send me mail ASAP.  I would like to know
what Common Lisp you are going to use, and anything else you think would
help argue your case.  If you aren't an X11 beta site, then I definitely
need to know what you think you're going to do.

		Could you hazard a guess as to how much effort it
    is to implement CLX?

The current sources are about 10K lines of code.  LaMott Oren of Texas
Instruments has been working on the code perhaps half time, I think
since about the beginning of May.

∂23-Jul-87  1410	@ZERMATT.LCS.MIT.EDU,@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU 	Some points on CLX. 
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87  14:09:50 PDT
Received: from KILLINGTON.LCS.MIT.EDU (KILLINGTON.LCS.MIT.EDU) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 64946; 23 Jul 87 17:07:48 EDT
Date: Thu, 23 Jul 87 17:07 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Some points on CLX.
To: lowry%aitg.DEC@decwrl.dec.com
cc: cl-windows@sail.stanford.edu
In-Reply-To: <8707231533.AA11165@decwrl.dec.com>
Message-ID: <870723170733.6.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: Thursday, 23 Jul 1987 08:33:03-PDT
    From: lowry%aitg.DEC@decwrl.dec.com  (David Lowry 225-6290)

    I have some questions and comments about the latest CLX spec.

    1. Why does <mumble>-p take two arguments instead of one?  This
       is a predicate, it returns a boolean.  I'm guessing it's a misprint.

Yes, it's a misprint, thanks.

    2. In the function CREATE-WINDOW, the type of parameters X, Y, Width,
       Height, Depth and Border-Width should really be Fixnum, not Integer.
       This is an obvious case, so are all the places that use X and Y. I
       cannot see any problem limiting these values to at least 2↑15 range
       that CL sets for Fixnums.  Most implementations have a much higher
       range for Fixnums anyway.  This will help in the performance.

Since I work in an environment where the declarations don't matter,
input from others here is helpful.  The problem with your suggestion, I
think, is that if you declare the create-window args as (signed-byte 16)
or some such, then won't callers trying to pass in from variables of
type integer be in error?  Forcing the declarations back on all callers
doesn't seem desirable.

    3. I think the default action of the function CLEAR-AREA should be to
       clear the whole window.  According to the comment on it, if you 
       don't specify the X and Y value, they default to zero, and the 
       function is a no-op.  I think we need a way to easily clear a window.

No, the function is a no-op if width and height are zero, a null width
and height (the defaults) clear to boundary, so the default action is
to clear the whole window.

    4. I found it useful for V10 to have two functions LIST-ALL-DISPLAYS and
       LIST-ALL-WINDOWS.  These would return a copy of a list of all open
       displays, and all created windows, respectively.  For the function
       LIST-ALL-WINDOWS, I think it should have an &optional display parameter 
       that allows the user to specify all the windows existing on a certain
       display, but defaults to all displays.

I'm not sure I understand what list-all-windows does.  All windows
created by this process, or really the entire tree?  If thelatter, you
can easily write it on top of CLX.  Can you say in what way you found
these to be useful?

    5. How is the public implementation coming along?

It just started alpha test at a few sites.


∂23-Jul-87  1711	RAM@C.CS.CMU.EDU 	Some points on CLX.   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87  17:11:43 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 23 Jul 87 20:10:13-EDT
Date: Thu, 23 Jul 1987  20:10 EDT
Message-ID: <RAM.12320769840.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To:   Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Cc:   cl-windows@SAIL.STANFORD.EDU, lowry%aitg.DEC@DECWRL.DEC.COM
Subject: Some points on CLX.
In-reply-to: Msg of 23 Jul 1987  17:07-EDT from Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>

    Date: Thursday, 23 July 1987  17:07-EDT
    From: Robert Scheifler <RWS at ZERMATT.LCS.MIT.EDU>
    To:   lowry%aitg.DEC at decwrl.dec.com
    cc:   cl-windows at sail.stanford.edu
    Re:   Some points on CLX.

    Since I work in an environment where the declarations don't matter,
    input from others here is helpful.  The problem with your suggestion, I
    think, is that if you declare the create-window args as (signed-byte 16)
    or some such, then won't callers trying to pass in from variables of
    type integer be in error?

Declaring an argument to be (signed-byte 16) only requires that all
values actually passed be (signed-byte 16).  It doesn't require that
it be obvious that all calls to the function satisfy this type
constraint.  A compiler would be justified to warn if it can prove the
argument is *not* of the specified type, but if it simply can't tell,
then it must assume the user knows what he is doing.

  Rob

∂24-Jul-87  1433	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Some points on CLX.    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 87  14:33:38 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 198657; Fri 24-Jul-87 14:58:51 EDT
Date: Fri, 24 Jul 87 14:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Some points on CLX.
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, lowry%aitg.DEC@decwrl.dec.com
cc: cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <870723170733.6.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <870724145811.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 23 Jul 87 17:07 EDT
    From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>

	Date: Thursday, 23 Jul 1987 08:33:03-PDT
	From: lowry%aitg.DEC@decwrl.dec.com  (David Lowry 225-6290)

	2. In the function CREATE-WINDOW, the type of parameters X, Y, Width,
	   Height, Depth and Border-Width should really be Fixnum, not Integer.
	   This is an obvious case, so are all the places that use X and Y. I
	   cannot see any problem limiting these values to at least 2↑15 range
	   that CL sets for Fixnums.  

By the way, it's not clear that Common Lisp actually requires fixnums to have
such a range.  The remark on page 14 of Common Lisp: the Language says
"typically", so I don't think it means to constrain all implementations.

				      Most implementations have a much higher
	   range for Fixnums anyway.  This will help in the performance.

I would be strongly opposed to declaring these parameters to be of type
FIXNUM, because the meaning of that is completely implementation-dependent.
If you want to declare them to be a specific subrange of INTEGER, with the
expectation that that will produce more efficient code in some
implementations, that's fine with me.  I'm not sure whether -32768 through
32767 is the most appropriate subrange for these particular parameters;
perhaps some displays have more resolution than that, and perhaps the negative
numbers should be excluded. I suggest being guided by whatever the encoding in
the underlying X.11 protocol is, that way there is no danger of ruling out
valid numbers.

    Since I work in an environment where the declarations don't matter,
    input from others here is helpful.  The problem with your suggestion, I
    think, is that if you declare the create-window args as (signed-byte 16)
    or some such, then won't callers trying to pass in from variables of
    type integer be in error?  Forcing the declarations back on all callers
    doesn't seem desirable.

RAM's comment that changing the declaration in this way will not break
callers is quite true.  Common Lisp's declarations are not strong-typing.

∂27-Jul-87  1810	skh@spice.cs.cmu.edu 	Event-case is ungood.  
Received: from SPICE.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 87  18:10:22 PDT
Date: 27 Jul 1987 21:09-EDT 
From: Steve.Handerson@spice.cs.cmu.edu
To: cl-windows@SAIL.STANFORD.EDU
Subject: Event-case is ungood.
Message-Id: <554432955/skh@spice.cs.cmu.edu>

Event-case is ungood.

It would be nice to be able for a case to
1) notice that this is an event it's interested in, and
2) go ahead and do the appropriate thing, and then
3) Possibly *throw* out of the form after having handled the event
   (impossible in the current scheme)
without having to return some signalling value.
Since the result of the handler is both looked at to see if it handles,
AND is returned by the event-case,
it's hard to return NIL or multiple values without resorting to some hack.

It's obvious from the description that *somewhere*, *someone* has a 
queue of events, and that they can delete from the middle of it.
Making the objects and their deletion from the queue explicit would
solve the above problem nicely; when you handle an event, remove it.
I think it would be worth any problems concerning "invalid pointers"
(so long as it didn't crash my machine) that this might introduce.

I have more ideas concerning this, but I thought I'd post the
problem first and see what people have to say.
Besides, it'll give me time to think (heh heh).

-- Steve

∂28-Jul-87  0738	RWS@ZERMATT.LCS.MIT.EDU 	Event-case is ungood.    
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 87  07:38:36 PDT
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 65765; Tue 28-Jul-87 10:37:52 EDT
Date: Tue, 28 Jul 87 10:38 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Event-case is ungood.
To: Steve.Handerson@spice.cs.cmu.edu, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <554432955/skh@spice.cs.cmu.edu>
Message-ID: <870728103819.1.RWS@KILLINGTON.LCS.MIT.EDU>

    Date: 27 Jul 1987 21:09-EDT 
    From: Steve.Handerson@spice.cs.cmu.edu

    Event-case is ungood.

[Process-event is then just as ungood.]

    It would be nice to be able for a case to
    1) notice that this is an event it's interested in, and
    2) go ahead and do the appropriate thing, and then
    3) Possibly *throw* out of the form after having handled the event
       (impossible in the current scheme)
    without having to return some signalling value.

Do you have a concrete example of wanting to throw?

    Since the result of the handler is both looked at to see if it handles,
    AND is returned by the event-case,
    it's hard to return NIL or multiple values without resorting to some hack.

True.  Do you think it's important?

    It's obvious from the description that *somewhere*, *someone* has a 
    queue of events, and that they can delete from the middle of it.
    Making the objects and their deletion from the queue explicit would
    solve the above problem nicely; when you handle an event, remove it.
    I think it would be worth any problems concerning "invalid pointers"
    (so long as it didn't crash my machine) that this might introduce.

We've been through the event-as-object discussion once before, although
perhaps with a slightly different orientation.  I still think that it is
a very good idea that event objects aren't exposed, leaving the
implementation freedom in reusing resources while avoiding undesirable
"invalid pointer" problems.

    I have more ideas concerning this, but I thought I'd post the
    problem first and see what people have to say.
    Besides, it'll give me time to think (heh heh).

It would be great if there was a way to satisfy you without introducing
yet another whole mechanism.  I suppose we could use an unwind-protect
inside process-event and event-case, and define (or provide an option)
non-local exits to be equivalent to returning non-nil, but it sounds a
bit kludgy.

∂28-Jul-87  1423	@RELAY.CS.NET:Kimbrough%dsg@TI-CSL.CSNET 	Re: Event-case is ungood.   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 28 Jul 87  14:22:59 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ab17861; 28 Jul 87 17:04 EDT
Received: from ti-csl by RELAY.CS.NET id ao00748; 28 Jul 87 16:53 EDT
Received: from dsg by tilde id AA20396; Tue, 28 Jul 87 15:30:11 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 28 Jul 87  15:30:17 CDT
Message-Id: <2763491293-14639720@Sierra>
Sender: KK%Sierra%ti-csl.csnet@RELAY.CS.NET
Date: Tue, 28 Jul 87  15:28:13 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
To: Steve.Handerson@SPICE.CS.CMU.EDU
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: Event-case is ungood.
In-Reply-To: Msg of Tue, 28 Jul 87 10:38 EDT from Robert Scheifler <RWS@zermatt.lcs.mit.edu>

    > It would be nice to be able for a case to
    > 1) notice that this is an event it's interested in, and
    > 2) go ahead and do the appropriate thing, and then
    > 3) Possibly *throw* out of the form after having handled the event
    >    (impossible in the current scheme)
    > without having to return some signalling value.

Impossible? How about something like the following?

(OR 
  (CATCH :abort-event-case

    ;; Try to process the event
    (EVENT-CASE display 
      .
      .
      (<some-event>
        .
        .
	;; ... and then bail out!
	(THROW :abort-event-case nil))
      .
      .
      .))

  ;; Else discard event which caused the throw
  (EVENT-CASE display (otherwise t)))


Clearly, different conventions for the semantics of the THROW could also be 
programmed.

∂03-Aug-87  1410	RWS@ZERMATT.LCS.MIT.EDU 	[snyder%hplsny@hplabs.HP.COM: CLX "objects" proposal]  
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87  14:10:14 PDT
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 66925; Mon 3-Aug-87 17:10:07 EDT
Date: Mon, 3 Aug 87 17:10 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: [snyder%hplsny@hplabs.HP.COM: CLX "objects" proposal]
To: cl-windows@sail.stanford.edu
Message-ID: <870803171012.6.RWS@KILLINGTON.LCS.MIT.EDU>

Subject: CLX "objects" proposal
Reply-To: snyder@hplabs.hp.com
Date: Mon, 03 Aug 87 11:47:17 PDT
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>

--------------------------------------------------------------------------------
Window Objects proposal
3-Aug-87

Disclaimer:

  I am not an X "expert".  I have written one X application using X version
10.  I have not used any X toolkits.  This proposal is not fully developed.
It is a response to Draft Version 3.1 of CLX.

Mechanics:

  I am not on the cl-windows mailing list.  Please cc comments to me at
"snyder@hplabs.hp.com".

Background:

  One of my frustrations in using the C interface to X is the work that I
had to go though to associate my own information with X windows.  What I
eventually wound up doing is creating various data structures corresponding
to different kinds of windows and mapping between these data structures and
X window IDs using the XAssoc facility.  (That's what it's for, right?)
These data structures had a common prefix, which allowed me to write
"generic" window code (such as an event handler).

  In looking at the CLX proposal, I was pleased to see that various
"objects" had been introduced to abstract away from the IDs.  However, in
my opinion, the CLX proposal does not go far enough:

  1. The IDs are not completely hidden: IDs, rather than "objects" are
     passed to event and error handlers.  Thus, at some level above the
     CLX interface it is still necessary to map between IDs and "objects".

  2. The "objects" are not defined in such a way as to permit the
     attachment of user data (e.g., by subclassing).  Thus, if user
     data is to be associated with an X "object", a separate user "object"
     must still be created and a mapping done between the X "object" and
     the user "object".

     (I am less concerned with "method redefinition" than the simple
     ability to extend X "objects" with user data.)

Layers:

  It has been argued that the CLX layer will not be directly used by
applications and therefore need not support extensible data structures.  It
might also be argued that the CLX layer is the "lowest common denominator",
and therefore should not be burdened by such a facility.

  I doubt that there will be a standard higher-level application layer in
the near future.  Multiple application layers over CLX will be created and
experimented with.  Applications will be directly written on CLX either for
portability, for efficiency, or to obtain maximum "control".

  I believe that associating user data with X "objects" is a common need
both for applications layers built on CLX and for applications built
directly on CLX.  Therefore, it is useful for CLX to directly provide this
ability, rather than force every "user" of CLX to implement it.  It is also
more efficient: CLX is already (in some implementations, at least) mapping
between IDs and "objects"; there is no reason to force CLX users to
duplicate this effort.

Proposal:

  1. Change the event and error handler interface to provide "resource objects"
     rather than "resource IDs".

     (I cannot say whether for efficiency an interface in terms of IDs
     should remain.  How often do events get handled without ever
     mapping from the "resource ID" back to the "resource object"?
     For errors, the efficiency is presumably not important.)

     (Would this change enable the creation of an event handler that can
     work on multiple displays?)

  2. Allow the user to create "extended" resource objects (extended in
     the sense that they have additional components defined by the user).
     Extended resource objects are created by functions like CREATE-WINDOW,
     OPEN-FONT, CREATE-PIXMAP, CREATE-GCONTEXT, CREATE-COLORMAP,
     CREATE-CURSOR, and CREATE-GLYPH-CURSOR; these functions must
     take an optional argument that specifies what kind of object to create.
     Obviously, such "extended" objects must be cached so that CLX
     will return the right ones.

How does the user create an "extended" resource object?  Both DEFSTRUCT and
CLOS classes provide an adequate subclassing mechanism for this purpose.
Unfortunately, CLX currently does not define the "representation" of its
resource objects.  Perhaps the right thing to do is decide on DEFSTRUCT
for now and convert to CLOS classes when CLOS becomes established.

If no decision on representation is possible, perhaps CLX can allow both:

  1. Define a <mumble> DEFSTRUCT and a <mumble> CLASS.

  2. Define <mumble>-DISPLAY, etc. to work on both the DEFSTRUCT
     and the CLOS CLASS instances.

  3. Extend the various <mumble>-creating functions to accept an optional
     :INSTANTIATOR argument, which is a function that takes
     keyword arguments :DISPLAY and :ID and returns an appropriate
     (DEFSTRUCT or CLOS) object.  Both DEFSTRUCT and CLOS define
     such object-creating functions.

This awkward situation should work itself out once CLOS becomes established.

A small point: the function name WINDOW-CLASS is poorly chosen, given a
possible extension to CLOS.
--------------------------------------------------------------------------------


∂14-Aug-87  0642	@RELAY.CS.NET:AGHVAMI%ORION@TI-CSL.CSNET 	Common Lisp windows standards    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 14 Aug 87  06:42:51 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ab07247; 14 Aug 87 9:41 EDT
Received: from ti-csl by RELAY.CS.NET id ab17050; 14 Aug 87 9:33 EDT
Received: from ORION by tilde id AA15824; Fri, 14 Aug 87 08:26:01 CDT
Message-Id: <2764935038-3959697@ORION>
Sender: AGHVAMI%ORION%ti-csl.csnet@RELAY.CS.NET
Date: Fri, 14 Aug 87  08:30:38 CDT
From: AGHVAMI%Einstein%ti-csl.csnet@RELAY.CS.NET
To: cl-windows@SAIL.STANFORD.EDU
Subject: Common Lisp windows standards

To Whom It May Concern:

Would you please include my name on the mailing list for CL-windows
standard sub-committee. 


Regards,


Mehdi Aghvami


∂27-Aug-87  0616	marone@nrl-aic.ARPA 	request for addition to mail list 
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 27 Aug 87  06:16:32 PDT
Return-Path: <marone@nrl-aic.ARPA>
Received: Thu, 27 Aug 87 09:15:41 edt by nrl-aic.ARPA id AA08581
Date: Thu, 27 Aug 87 09:15:41 edt
From: Mike Marrone <marone@nrl-aic.ARPA>
Message-Id: <8708271315.AA08581@nrl-aic.ARPA>
To: cl-windows@sail.stanford.edu
Subject: request for addition to mail list

Sorry if this is the wrong address for this type of thing, but its
the only address I have.  I would like to be added to the cl-windows
discussion list.
Thanks,
Mike Marrone
marone@nrl-aic.arpa

∂09-Sep-87  0923	Paul.Birkel@k.gp.cs.cmu.edu 	CLX interface for X11 Toolkit? 
Received: from K.GP.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Sep 87  09:23:42 PDT
Date: Wednesday, 9 September 1987 12:14:36 EDT
From: Paul.Birkel@k.gp.cs.cmu.edu
To: cl-windows@sail.stanford.edu
Subject: CLX interface for X11 Toolkit?
Message-ID: <1987.9.9.16.12.10.Paul.Birkel@K.GP.CS.CMU.EDU>

Anybody given this some thought? Plans? Actions? Delivery date?

Or am I going to have to build a crass foreign function call interface?

paul birkel
pab@k.cs.cmu.edu
(412) 268-3074

∂10-Sep-87  0718	@KILLINGTON.LCS.MIT.EDU:RWS@ZERMATT.LCS.MIT.EDU 	CLX interface for X11 Toolkit? 
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Sep 87  07:17:48 PDT
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA22834; Thu, 10 Sep 87 10:15:08 EDT
Date: Thu, 10 Sep 87 10:16 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX interface for X11 Toolkit?
To: Paul.Birkel@k.gp.cs.cmu.edu, cl-windows@sail.stanford.edu
In-Reply-To: <1987.9.9.16.12.10.Paul.Birkel@K.GP.CS.CMU.EDU>
Message-Id: <870910101643.9.RWS@KILLINGTON.LCS.MIT.EDU>

I guess I don't know of anyone planning a CLX interface.  Either people
are taking the shortsighted view and building a crass FFI to both the C
Xlib and toolkit, or they have decided that CLX has a better interface
than the C Xlib, and that a great deal of the C toolkit intrinsics is
fighting a losing battle to reinvent parts of an object system in C, and
that it can be done in CLOS or comparable quite simply, and that
building widgets directly in Lisp will be a *lot* easier.

My understanding is that TI is working on such a toolkit on top of CLX.
Perhaps one of them could say a few words.

∂10-Sep-87  1607	@RELAY.CS.NET:Oren%Home@TI-CSL.CSNET 	Re: CLX interface for X11 Toolkit?   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 10 Sep 87  16:06:53 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa19681; 10 Sep 87 18:12 EDT
Received: from ti-csl by RELAY.CS.NET id ag03899; 10 Sep 87 18:03 EDT
Received: from SI by tilde id AA07107; Thu, 10 Sep 87 16:26:51 CDT
Message-Id: <2767296479-2009737@SI>
Sender: OREN%SI%ti-csl.csnet@RELAY.CS.NET
Date: Thu, 10 Sep 87  16:27:59 CDT
From: LaMott Oren <Oren%Home%ti-csl.csnet@RELAY.CS.NET>
To: Paul.Birkel@K.GP.CS.CMU.EDU
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX interface for X11 Toolkit?
In-Reply-To: Msg of Wednesday, 9 September 1987 12:14:36 EDT from Paul.Birkel@k.gp.cs.cmu.edu

We're working on a CLX extension that looks like X-Toolkit.  It uses a
minimal portable subset of CLOS (that doesn't have multiple inheritance,
meta-classes, etc.) built on top of defstruct.  Right now, we're trying to
build "intrinsics" that provide the defaulting, input and geometry
management features of X-Toolkit in a lispy way taking advantage of CLOS.
Hopefully we'll be able to publish details here in a couple weeks.  Of
course the real work is in the widgets.  We've only written very simple
widgets to test the concepts in our intrinsics.  We plan on making our
effort public domain, but it will take us awhile to get useful widgets.
We'll be looking for volunteer widget writers after the intrinsics are done.

∂18-Sep-87  1317	franz!frozen!jdi@ucbarpa.Berkeley.EDU   
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 18 Sep 87  13:17:21 PDT
Received: by ucbarpa.Berkeley.EDU (5.58/1.25)
	id AA21667; Fri, 18 Sep 87 13:19:30 PDT
Received: from frozen by franz (5.5/3.14)
	id AA25082; Fri, 18 Sep 87 13:08:33 PDT
Received: by frozen (3.2/3.14)
	id AA05927; Fri, 18 Sep 87 13:07:01 PDT
Date: Fri, 18 Sep 87 13:07:01 PDT
From: franz!frozen!jdi@ucbarpa.Berkeley.EDU (John)
Return-Path: <frozen!jdi>
Message-Id: <8709182007.AA05927@frozen>
To: CL-Windows@sail.stanford.edu



Sorry to put this in the mailing list, but I've sent two messages to
CL-Windows-Request and gotten no response.  My name is John Irwin and
I work for Franz Inc;  I'd like to be added to the mailing list.  I would
also like to hear from anyone who is using or is planning to use CLX with
our Common Lisp.

Thank you,
	-- John Irwin (jdi%franz.uucp@ucbvax.berkeley.edu)

∂20-Sep-87  1842	roman@ATHENA.MIT.EDU 	Re: CLX under KCL?     
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Sep 87  18:42:30 PDT
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA28689; Sun, 20 Sep 87 21:41:36 EDT
Received: by JASON.MIT.EDU (5.45/4.7) id AA09707; Sun, 20 Sep 87 21:41:58 EDT
Message-Id: <8709210141.AA09707@JASON.MIT.EDU>
To: bzs@bu-cs.bu.edu (Barry Shein)
Cc: bug-clx@zermatt.lcs.mit.edu, cl-windows@sail.stanford.edu
Subject: Re: CLX under KCL? 
In-Reply-To: Your message of Sat, 19 Sep 87 00:40:45 -0400.
             <8709190440.AA06027@bu-cs.BU.EDU> 
Date: Sun, 20 Sep 87 21:41:56 EDT
From: Roman J. Budzianowski <roman@ATHENA.MIT.EDU>

Date: Sun, 20 Sep 87 21:24:06 EDT
From: Roman J. Budzianowski <roman>


> Anyone else working on compiling CLX under KCL? Socket.c was fairly
> straightforward if anyone needs it (can't say it's been tested) but
> KCL is choking on some of the macros in macros.lsp. This is all on
> a Sun3/160 (3.4) if that matters. Just wondering if anyone has made
> progress with this while I go cross-eyed over `(this ,@(stuff)). Tx.
>
>	-Barry Shein, Boston University

I have compiled clx under kcl. The problems were related to
'do' macro syntax and to package operations (export).

The real problem with kcl seems to be that there is no easy way
to build stream interface to tcp/ip. The streams in the kcl
are internally implemented on top of FILE C structure and use
putc to do writing. Any ideas ?

Roman.


∂21-Sep-87  0728	samalone@ATHENA.MIT.EDU 	Re: CLX under KCL?  
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 Sep 87  07:27:59 PDT
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA05281; Mon, 21 Sep 87 10:27:24 EDT
From: <samalone@ATHENA.MIT.EDU>
Received: by M37-332-7 (5.45/4.7)
	id AA19490; Mon, 21 Sep 87 10:25:44 EDT
Message-Id: <8709211425.AA19490@M37-332-7>
To: Roman J. Budzianowski <roman@ATHENA.MIT.EDU>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX under KCL? 
In-Reply-To: Your message of Sun, 20 Sep 87 21:41:56 -0400.
             <8709210141.AA09707@JASON.MIT.EDU> 
Date: Mon, 21 Sep 87 10:25:39 EDT


> The real problem with kcl seems to be that there is no easy way to build 
> stream interface to tcp/ip. The streams in the kcl are internally
> implemented on top of FILE C structure and use putc to do writing. Any 
> ideas ?

I believe the C function you're looking for is called "fdopen".  It takes a
file descriptor and returns a file pointer.

				--Stuart